Pith. sign in

REVIEW 3 major objections 5 minor 56 references

HF-DGF: Hybrid Feedback Guided Directed Grey-box Fuzzing

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read HF-DGF claims that a directed fuzzer guided by control-flow distance, value-flow influence, and slice coverage reproduces real-world crashes 2.56 to 73.75 times faster than five baseline fuzzers.

desk verdict A genuinely new pair of DGF metrics and an honest ablation, but the headline speedup averages hide a favorable-subset problem and need reanalysis before the strong claims are accepted. read the letter →

arxiv 2506.23063 v1 pith:WROY3HUW submitted 2025-06-29 cs.SE

classification cs.SE
keywords directedgrey-boxfuzzinghybridfeedbackvalue-flowanalysiscontrol-flowdistanceselectiveinstrumentationcrashreproductionseedschedulingstatic
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

HF-DGF tries to establish that a directed grey-box fuzzer steered by three complementary runtime signals can reach a targeted bug site faster and then explore the data states around it more thoroughly than fuzzers guided by control-flow distance alone. The three signals are a basic-block-level control-flow distance computed by a backward-stepping algorithm on a virtual interprocedural control-flow graph, a value-flow influence score that measures how strongly executed code modifies target data, and coverage of the statically sliced target-relevant region. The framework couples these signals in seed prioritization and energy allocation to implement what the authors call a reach-then-explore paradigm, and it uses selective instrumentation so that only boundary blocks, sliced blocks, and value-flow-relevant blocks are instrumented. If the claims hold, crash reproduction and patch testing on large C programs would get measurably faster; the reported median time-to-exposure speedups over five baselines range from 2.56 to 73.75 times.

What carries the argument

The load-bearing mechanism is a hybrid feedback scheduler operating on three static-analysis-derived metrics. Control-flow distance is computed per basic block by a backward-stepping algorithm over a virtual interprocedural control-flow graph: call sites are treated as edges, reachable functions are unwrapped to basic-block level, and a seed's distance is the average distance of the boundary blocks in its execution trace. The value-flow influence score is computed from the value-flow graph with field-sensitive Andersen-style pointer analysis: each instruction gets a distance to the target data, each basic block takes the minimum value-flow influence over its instructions, and a seed's score is the sum over executed value-flow-relevant blocks. Slice coverage is the set of target-relevant basic blocks reached, where the slice is the union of a control-flow backward slice and a value-flow backward slice from the target. These three signals are combined in a product energy formula with simulated annealing applied separately to control-flow distance and to value-flow influence, while selective instrumentation limits feedback collection to boundary blocks, sliced blocks, and value-flow-relevant blocks.

What would settle it

Give HF-DGF a program whose value-flow graph is missing one true edge to the target's data, then compare its time-to-exposure against a distance-only fuzzer; if the missing edge does not erase the speedup, the claimed value-flow guidance is not what drives the result.

Watch

Extended reading notes

Core claim

The central claim is that directed fuzzing splits naturally into reaching the target and then exploring the target's state space, and that each phase needs its own feedback signal. HF-DGF computes control-flow distance at basic-block granularity with a backward-stepping algorithm on a virtual interprocedural control-flow graph, so seeds are ranked by structural proximity rather than by function-level call-graph distance. For state-space exploration it defines value-flow influence: instructions that modify or influence target data receive a score based on their value-flow distance to the target, and a seed's score is the accumulated influence of the basic blocks on its execution path; slice coverage then measures how much of the target-relevant sliced region a seed has touched. Selective instrumentation restricts feedback collection to boundary blocks, sliced blocks, and value-flow-relevant blocks, cutting instrumented coverage by roughly 76 percent while preserving vulnerability discovery. On 41 real-world vulnerabilities the prototype reports median time-to-exposure speedups of 5.05 times, 5.79 times, 73.75 times, 2.56 times, and 8.45 times over the five baseline fuzzers, more vulnerabilities triggered within 24 hours, and the lowest code coverage among the fuzzers that did trigger the crash.

Load-bearing premise

The whole speedup rests on the static analysis correctly deciding which code can reach the target and which code shapes the target's data; if that map is wrong, the hybrid feedback steers effort in the wrong direction.

Editorial extensions

If this is right

  • If the reported speedups hold, crash reproduction and patch validation on large C programs could be run with a fraction of the current fuzzing budget: median time-to-exposure drops by factors of 2.56 to 73.75 on the benchmark suite.
  • The reach-then-explore split offers a reusable template: use one signal to get to the target, a second to decide which data matters, and a third to track how much of the relevant region has been explored.
  • Selective instrumentation at boundary, slice, and value-flow blocks means that rich multi-signal feedback does not require whole-program instrumentation, which keeps the approach affordable on large binaries.
  • The observation that the fuzzer succeeds with the lowest code coverage suggests target-relevant coverage, not global coverage, is the better measure of directedness for future fuzzing campaigns.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same three-signal decomposition could be carried over to patch testing or to verifying static-analysis warnings, where the target set is a list of sinks rather than a single crash site.
  • The value-flow influence score is a static proxy for data relevance; coupling it with dynamic taint or concolic solving could let the fuzzer satisfy tight value constraints instead of relying on random mutation.
  • The boundary-block distance idea could be ported to binary-only fuzzing by recovering an analogous boundary set from disassembly, accepting coarser pointer reasoning.
  • The paper's own over-tainting discussion points to a concrete refinement: make slicing region-aware so dispatch functions that parse different input regions are not all included in the target-relevant set.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes HF-DGF, a directed grey-box fuzzer that combines three feedback signals for seed scheduling: basic-block-level control-flow distance computed by a backward-stepping algorithm over a virtual inter-procedural CFG, a value-flow influence score derived from SVF value-flow analysis, and slice coverage. To reduce overhead, it instruments only sliced basic blocks, boundary blocks, and value-flow-influencing blocks. The authors evaluate HF-DGF on DAFL's 41 CVE benchmark against AFL, AFLGo, WindRanger, DAFL, and Beacon, reporting average crash-reproduction speedups of 5.05x vs. AFL, 5.79x vs. AFLGo, 73.75x vs. WindRanger, 2.56x vs. DAFL, and 8.45x vs. Beacon, plus claims of more vulnerabilities triggered, lower coverage indicating better directionality, and faster static analysis. An ablation study isolates the contribution of each feedback component.

Significance. If the reported results hold, HF-DGF advances directed grey-box fuzzing by integrating data-flow-guided state-space exploration with control-flow distance, and its selective instrumentation is a promising approach to controlling runtime overhead. The manuscript has concrete strengths: it uses 20 repetitions per benchmark, reports a full 41-CVE table, includes an ablation study, and makes the source code available. The Discussion's candid acknowledgment of the over-tainting limitation on CVE-2017-8395 is also a strength. However, the headline claims are not yet convincingly supported because of the aggregation protocol for time-to-exposure and the non-comparable coverage metric, both detailed below.

major comments (3)
  1. [§VI-B, Table II, Abstract] The headline speedup figures (5.05x vs. AFL, 5.79x vs. AFLGo, 73.75x vs. WindRanger, 2.56x vs. DAFL, 8.45x vs. Beacon) are arithmetic means of per-benchmark ratios computed only over the 20 benchmarks where every tool produced a median TTE. This protocol excludes all N.A. rows, including the three cases where HF-DGF itself has N.A. while a baseline succeeds (CVE-2019-9114, CVE-2017-9048, CVE-2018-14498) and several cases where baselines fail; it also leaves the mean dominated by the 33x win on CVE-2017-5969. The paper's own Discussion VII-B concedes over-tainting caused underperformance on CVE-2017-8395, where Table II reports HF-DGF at 3879 s against DAFL's 8 s, a regression not captured by the average. The authors should report a robust summary over all 41 cases (e.g., treating a 24-hour failure as the TTE), median speedup ratios, and a paired significance test (e.g., Wilcoxon signed-rank). Without such a reanalysis, the central empirical claim is not established.
  2. [§VI-C, Fig. 4, Table IV] The RQ2 claim that HF-DGF exhibits the lowest code coverage and therefore superior directionality is confounded by the selective instrumentation strategy. HF-DGF instruments only about 24% of basic blocks for coverage (#Cov-Ins/#BB = 23.96% in Table IV), so its coverage bitmap is defined over a different block set from that of the full-instrumentation baselines; lower measured coverage can be an artifact of a smaller instrumentation domain rather than evidence of focused exploration. Additionally, the 18 targets analyzed in Fig. 4 are chosen as the 'top-performing targets according to the TTE HF-DGF achieved,' which is a selection bias. The coverage comparison should either use an identical instrumentation for all fuzzers or report coverage as a fraction of instrumented blocks, and the target selection should be justified as representative.
  3. [§IV-C, Eqs. (10)-(11)] The energy schedule PHF-DGF in Eq. (10) contains five free constants (10, 1, 0.5, -5, and the exponent base 2) and the product form of Eq. (11) is asserted without sensitivity analysis. Because the evaluation benchmark (DAFL's 41 CVEs) is the same one on which the design appears to have been developed, it is unclear whether these constants are overfit to this particular dataset. A parameter-sensitivity study or at least a discussion of how the constants were chosen is needed to support the external validity of the reported speedups.
minor comments (5)
  1. [Algorithm 1] The title of Algorithm 1 contains a typo: 'Backward-Steping' should be 'Backward-Stepping.'
  2. [Eq. (2)] In the case bb ∈ Entries, the formula uses Depth(bb), which is 0 for any entry block; based on Algorithm 1 (line 13), this should likely be Depth(cs), the depth of the call-site block. Please clarify or correct.
  3. [§VI-B] The text states 'After excluding the 9 cases where no fuzzing tool could obtain a median value,' but Table II appears to mark only 8 rows with an asterisk; the count should be verified.
  4. [§VI-B] The paper refers to 'the 20 benchmarks where all the tools successfully reported a median TTE,' yet by my count of Table II, 19 rows have numeric TTEs for all five ASAN-instrumented tools; please reconcile this discrepancy.
  5. [§IV-A] The term 'virtual ICFG' is used repeatedly but never formally defined; please explain what distinguishes it from a standard interprocedural control-flow graph.

Circularity Check

1 steps flagged · score 4.0 of 10

Crash-reproduction speedups are benchmark-measured and not circular; the 'lowest code coverage' directionality claim is an artifact of selective instrumentation by construction.

  1. self definitional [Abstract; §IV-D (Instrumentation for Coverage Feedback); §VI-C (RQ2); Table IV]
    "Notably, when all fuzzers triggered crashes, HF-DGF exhibited the lowest code coverage, demonstrating superior directionality and efficiency. ... HF-DGF selectively acquires coverage feedback solely from the sliced basic blocks related to the targets. ... In all 18 test cases, HF-DGF exhibited the lowest code coverage ... This shows that even with a narrow exploration scope, HF-DGF did not overlook any of these vulnerabilities."

    Coverage feedback is defined only over sliced basic blocks (Eq. 12-13), and Table IV reports #Cov-Ins/#BB = 23.96%, so the maximum possible measured coverage is structurally capped at that subset. The 'lowest code coverage' observation is therefore a direct consequence of the selective-instrumentation definition, not independent evidence of superior directionality. The crash-reproduction TTE results come from an external 41-CVE benchmark and are not affected; the circularity is limited to the coverage-based supporting claim.

full rationale

The paper's central crash-reproduction claim (e.g., 5.05x faster than AFL, 5.79x faster than AFLGo) is measured against DAFL's external 41-CVE benchmark and is not derived from the feedback equations: the seed-distance formula (Eq. 4), value-flow influence score (Eq. 8), and energy schedule (Eq. 10) feed a fuzzer whose time-to-exposure is then empirically observed. No equation defines TTE in terms of the proposed metrics, so the main speedup result is not circular. The hand-chosen constants in Eq. 10 and the use of the same benchmark for design and evaluation are overfitting/validity concerns, not circularity. Similarly, the headline speedup is computed only over the 20 rows where all tools reported a median TTE and uses the arithmetic mean of per-case ratios, which is a statistical-reporting limitation rather than a circular reduction. One supporting claim does reduce by construction: because HF-DGF instruments only sliced basic blocks, its lower measured code coverage is inherent to the instrumentation definition (Table IV), so it cannot by itself demonstrate superior directionality. Aside from that coverage-based claim, the paper's central empirical derivation is self-contained against an external benchmark.

Assumptions & free parameters 1 free parameters · 4 assumptions · 1 invented entities

The empirical claim rests on static analysis precision, an approximate ICFG distance, a hand-chosen energy schedule, and median TTE as the evaluation metric.

free parameters (1)
  • Energy schedule constants in Eq 10 = 2^10, 0.5, -5
    Hand-chosen scaling constants for the value-flow influence annealing schedule; no sensitivity analysis or held-out tuning is reported, and the same 41-bug benchmark is used for evaluation.
assumptions (4)
  • domain assumption Andersen-style pointer analysis and SVF provide a sound approximation of target-reachable functions and data dependencies.
    Used in Sections IV.A and IV.B to construct the virtual ICFG and value-flow graph; imprecision would corrupt distance and influence feedback.
  • domain assumption The backward-stepping distance formula (Eq 2) approximates the true shortest control-flow path to the target.
    A full path-sensitive ICFG is stated to be impractical, so Algorithm 1 uses an approximation; the paper does not quantify its error.
  • domain assumption Median time-to-exposure over 20 runs is a reliable performance measure without variance or significance testing.
    Section VI-B reports only medians; no confidence intervals or statistical tests are provided.
  • ad hoc to paper The product of three power schedules (Eq 11) improves crash discovery without negative interaction.
    Asserted in Section IV-C and only indirectly validated by ablation; no derivation is given.
invented entities (1)
  • Value-flow influence score (VFS)
    purpose: Quantifies a seed's cumulative influence on target data to guide exploration of the target state space.
    A new fitness metric defined by Eqs 5-9; its utility is supported only by the reported benchmark, with no external falsifiable prediction.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HF-DGF: Hybrid Feedback Guided Directed Grey-box Fuzzing." pith.science (2026). https://pith.science/paper/WROY3HUW

@misc{pith2026250623063,
  author       = {Pith},
  title        = {Pith review of: HF-DGF: Hybrid Feedback Guided Directed Grey-box Fuzzing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WROY3HUW}},
  note         = {Machine review of arXiv:2506.23063}
}
read the original abstract

Directed Grey-box Fuzzing (DGF) has emerged as a widely adopted technique for crash reproduction and patch testing, leveraging its capability to precisely navigate toward target locations and exploit vulnerabilities. However, current DGF tools are constrained by insufficient runtime feedback, limiting their efficiency in reaching targets and exploring state spaces. This study presents HF-DGF, a novel directed grey-box fuzzing framework. Its seed scheduling is guided by a hybrid feedback mechanism integrating control-flow distance, value-flow influence score, and slice coverage. To enable precise control-flow distance feedback, we propose a backward-stepping algorithm to calculate basic block-level seed distances on a virtual inter-procedural control-flow graph (ICFG). For effective state space exploration, we introduce value-flow influence and a corresponding metric, the value-flow influence score. Additionally, to mitigate runtime overhead from hybrid feedback, we adopt a novel selective instrumentation strategy. Evaluations on 41 real-world vulnerabilities show HF-DGF outperforms existing tools: it achieves crash reproduction 5.05 times faster than AFL, 5.79 times faster than AFLGo, 73.75 times faster than WindRanger, 2.56 times faster than DAFL, and 8.45 times faster than Beacon on average. Notably, when all fuzzers triggered crashes, HF-DGF exhibited the lowest code coverage, demonstrating superior directionality and efficiency. It also surpasses AFLGo, WindRanger, DAFL, and Beacon in static analysis efficiency.

Figures

Figures reproduced from arXiv: 2506.23063 by the authors.

Figure 2
Figure 2. Path Selection in HF-DGF. As depicted by the CFGs in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. First, we identify functions reachable to the target location via function call sequences (e.g., functions A, B, C marked in Fig. 3a) using breadth-first traversal on the function call graph, expanding the scope with Andersen-style pointer analysis [26] to handle indirect calls. During traversal, we record call￾site basic blocks (yellow in [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. BitMap Coverage cjpeg swftophp lrzip readelf cxxfilt xmllint objcopy objdump strip nm 101 102 103 Time (s) AFLGo Beacon DAFL HF-DGF [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6 [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: , clarify the performance differences. Points above the axis of y = 0 (the solid red line) indicate that a variant takes longer to trigger crashes than HF-DGF; points below it mean a shorter time is taken. Each technique independently provides positive guidance for HF-…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

56 extracted references · 51 canonical work pages

  1. [1]

    Boosting fuzzer efficiency: An information theoretic perspective,

    M. B ¨ohme, V . J. Man`es, and S. K. Cha, “Boosting fuzzer efficiency: An information theoretic perspective,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering , 2020, pp. 678–689

  2. [2]

    WEIZZ: Automatic grey-box fuzzing for structured binary formats,

    A. Fioraldi, D. C. D’Elia, and E. Coppa, “WEIZZ: Automatic grey-box fuzzing for structured binary formats,” in Proceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis , 2020, pp. 1–13. 13

  3. [3]

    The art, science, and engineering of fuzzing: A survey,

    V . J. Man `es, H. Han, C. Han, S. K. Cha, M. Egele, E. J. Schwartz, and M. Woo, “The art, science, and engineering of fuzzing: A survey,” IEEE Transactions on Software Engineering , vol. 47, no. 11, pp. 2312–2331, 2019, publisher: IEEE

  4. [4]

    Parser-directed fuzzing,

    B. Mathis, R. Gopinath, M. Mera, A. Kampmann, M. H ¨oschele, and A. Zeller, “Parser-directed fuzzing,” in Proceedings of the 40th acm sig- plan conference on programming language design and implementation , 2019, pp. 548–560

  5. [5]

    Learning input tokens for effec- tive fuzzing,

    B. Mathis, R. Gopinath, and A. Zeller, “Learning input tokens for effec- tive fuzzing,” in Proceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis , 2020, pp. 27–37

  6. [6]

    CodeAlchemist: Semantics-aware code generation to find vulnerabilities in JavaScript engines

    H. Han, D. Oh, and S. K. Cha, “CodeAlchemist: Semantics-aware code generation to find vulnerabilities in JavaScript engines.” in NDSS, 2019

  7. [7]

    Superion: Grammar-aware greybox fuzzing,

    J. Wang, B. Chen, L. Wei, and Y . Liu, “Superion: Grammar-aware greybox fuzzing,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) . IEEE, 2019, pp. 724–735

  8. [8]

    NTFuzz: Enabling type-aware kernel fuzzing on windows with static binary analysis,

    J. Choi, K. Kim, D. Lee, and S. K. Cha, “NTFuzz: Enabling type-aware kernel fuzzing on windows with static binary analysis,” in 2021 IEEE Symposium on Security and Privacy (SP) . IEEE, 2021, pp. 677–693

Show all 56 references
  1. [9]

    Razzer: Finding kernel race bugs through fuzzing,

    D. R. Jeong, K. Kim, B. Shivakumar, B. Lee, and I. Shin, “Razzer: Finding kernel race bugs through fuzzing,” in 2019 IEEE Symposium on Security and Privacy (SP) . IEEE, 2019, pp. 754–768

  2. [10]

    {kAFL}:{Hardware-Assisted} feedback fuzzing for {OS} kernels,

    S. Schumilo, C. Aschermann, R. Gawlik, S. Schinzel, and T. Holz, “{kAFL}:{Hardware-Assisted} feedback fuzzing for {OS} kernels,” in 26th USENIX security symposium (USENIX Security 17), 2017, pp. 167– 182

  3. [11]

    SyzDirect: Directed Greybox Fuzzing for Linux Kernel,

    X. Tan, Y . Zhang, J. Lu, X. Xiong, Z. Liu, and M. Yang, “SyzDirect: Directed Greybox Fuzzing for Linux Kernel,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. Copenhagen Denmark: ACM, Nov. 2023, pp. 1630–1644. [Online]. Available: ht...

  4. [12]

    Pulsar: Stateful black-box fuzzing of proprietary network protocols,

    H. Gascon, C. Wressnegger, F. Yamaguchi, D. Arp, and K. Rieck, “Pulsar: Stateful black-box fuzzing of proprietary network protocols,” in Security and Privacy in Communication Networks: 11th EAI Interna- tional Conference, SecureComm 2015, Dallas, TX, USA, October 26-29, 2015, ...

  5. [13]

    State selection algorithms and their impact on the performance of stateful network protocol fuzzing,

    D. Liu, V .-T. Pham, G. Ernst, T. Murray, and B. I. Rubinstein, “State selection algorithms and their impact on the performance of stateful network protocol fuzzing,” in 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2022, p...

  6. [14]

    Snpsfuzzer: A fast greybox fuzzer for stateful network protocols using snapshots,

    J. Li, S. Li, G. Sun, T. Chen, and H. Yu, “Snpsfuzzer: A fast greybox fuzzer for stateful network protocols using snapshots,” IEEE Transac- tions on Information Forensics and Security , vol. 17, pp. 2673–2687, 2022, publisher: IEEE

  7. [15]

    Regression Greybox Fuzzing,

    X. Zhu and M. B ¨ohme, “Regression Greybox Fuzzing,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security . Virtual Event Republic of Korea: ACM, Nov. 2021, pp. 2169–2182. [Online]. Available: https://dl.acm.org/doi/10.1145/3460120.3484596

  8. [16]

    Automated whitebox fuzz testing

    P. Godefroid, M. Y . Levin, D. A. Molnar, and others, “Automated whitebox fuzz testing.” in NDSS, vol. 8, 2008, pp. 151–166

  9. [17]

    DART: Directed automated random testing,

    P. Godefroid, N. Klarlund, and K. Sen, “DART: Directed automated random testing,” in Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation , 2005, pp. 213– 223

  10. [18]

    Crash reproduction via test case mutation: Let existing test cases help,

    J. Xuan, X. Xie, and M. Monperrus, “Crash reproduction via test case mutation: Let existing test cases help,” in Proceedings of the 2015 10th joint meeting on foundations of software engineering , 2015, pp. 910– 913

  11. [19]

    Search-based crash reproduction and its impact on debugging,

    M. Soltani, A. Panichella, and A. Van Deursen, “Search-based crash reproduction and its impact on debugging,” IEEE Transactions on Software Engineering, vol. 46, no. 12, pp. 1294–1317, 2018, publisher: IEEE

  12. [20]

    Taintdroid: an information- flow tracking system for realtime privacy monitoring on smartphones,

    W. Enck, P. Gilbert, S. Han, V . Tendulkar, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “Taintdroid: an information- flow tracking system for realtime privacy monitoring on smartphones,” ACM Transactions on Computer Systems (TOCS) , vol. 32, no. 2, pp. 1–29, ...

  13. [21]

    Directed greybox fuzzing,

    M. B ¨ohme, V .-T. Pham, M.-D. Nguyen, and A. Roychoudhury, “Directed greybox fuzzing,” in Proceedings of the 2017 ACM SIGSAC conference on computer and communications security , 2017, pp. 2329–2344

  14. [22]

    {DAFL}: Directed Grey- box Fuzzing guided by Data Dependency,

    T. E. Kim, J. Choi, K. Heo, and S. K. Cha, “ {DAFL}: Directed Grey- box Fuzzing guided by Data Dependency,” in 32nd USENIX Security Symposium (USENIX Security 23) , 2023, pp. 4931–4948

  15. [23]

    WindRanger: a directed greybox fuzzer driven by deviation basic blocks,

    Z. Du, Y . Li, Y . Liu, and B. Mao, “WindRanger: a directed greybox fuzzer driven by deviation basic blocks,” in Proceedings of the 44th International Conference on Software Engineering , 2022, pp. 2440– 2451

  16. [24]

    Dowser: a guided fuzzer to find buffer overflow vulnerabilities,

    I. Haller, A. Slowinska, M. Neugschwandtner, and H. Bos, “Dowser: a guided fuzzer to find buffer overflow vulnerabilities,” in Proceedings of the 22nd USENIX Security Symposium , 2013, pp. 49–64

  17. [25]

    Selectfuzz: Efficient directed fuzzing with selective path exploration,

    C. Luo, W. Meng, and P. Li, “Selectfuzz: Efficient directed fuzzing with selective path exploration,” in 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 2693–2707

  18. [26]

    Program analysis and specialization for the C pro- gramming language,

    L. O. Andersen, “Program analysis and specialization for the C pro- gramming language,” 1994, publisher: Citeseer

  19. [27]

    Directed Greybox Fuzzing with Stepwise Constraint Focusing,

    X. Li, X. Li, G. Lv, Y . Zhang, and F. Wang, “Directed Greybox Fuzzing with Stepwise Constraint Focusing,” arXiv preprint arXiv:2303.14895 , 2023

  20. [28]

    Hawkeye: Towards a desired directed grey-box fuzzer,

    H. Chen, Y . Xue, Y . Li, B. Chen, X. Xie, X. Wu, and Y . Liu, “Hawkeye: Towards a desired directed grey-box fuzzer,” in Proceedings of the 2018 ACM SIGSAC conference on computer and communications security , 2018, pp. 2095–2108

  21. [29]

    The value flow graph: A program representation for optimal program transformations,

    B. Steffen, J. Knoop, and O. R ¨uthing, “The value flow graph: A program representation for optimal program transformations,” in ESOP’90: 3rd European Symposium on Programming Copenhagen, Denmark, May 15–18, 1990 Proceedings 3 . Springer, 1990, pp. 389–405

  22. [30]

    Practical memory leak detection using guarded value-flow analysis,

    S. Cherem, L. Princehouse, and R. Rugina, “Practical memory leak detection using guarded value-flow analysis,” in Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation, 2007, pp. 480–491

  23. [31]

    SVF: interprocedural static value-flow analysis in LLVM,

    Y . Sui and J. Xue, “SVF: interprocedural static value-flow analysis in LLVM,” inProceedings of the 25th international conference on compiler construction, 2016, pp. 265–266

  24. [32]

    American fuzzy lop,

    M. Zalewski, “American fuzzy lop,” 2017

  25. [33]

    LLVM: A compilation framework for lifelong program analysis & transformation,

    C. Lattner and V . Adve, “LLVM: A compilation framework for lifelong program analysis & transformation,” in International symposium on code generation and optimization, 2004. CGO 2004. IEEE, 2004, pp. 75–86

  26. [34]

    Svf: interprocedural static value-flow analysis in llvm,

    Y . Sui and J. Xue, “Svf: interprocedural static value-flow analysis in llvm,” in Proceedings of the 25th international conference on compiler construction, 2016, pp. 265–266

  27. [35]

    Zalewski

    M. Zalewski. American fuzzy lop. [Online]. Available: https: //lcamtuf.coredump.cx/afl/

  28. [36]

    Beacon: Directed grey-box fuzzing with provable path pruning,

    H. Huang, Y . Guo, Q. Shi, P. Yao, R. Wu, and C. Zhang, “Beacon: Directed grey-box fuzzing with provable path pruning,” in 2022 IEEE Symposium on Security and Privacy (SP) . IEEE, 2022, pp. 36–50

  29. [37]

    AFL++ : Combining incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “AFL++ : Combining incremental steps of fuzzing research,” in 14th USENIX Workshop on Offensive Technologies (WOOT 20) . USENIX Association, Aug

  30. [38]

    What is a Container? | Docker

    Docker, “What is a Container? | Docker.” [Online]. Available: https://www.docker.com/resources/what-container/

  31. [39]

    Driller: Augmenting fuzzing through selective symbolic execution

    N. Stephens, J. Grosen, C. Salls, A. Dutcher, R. Wang, J. Corbetta, Y . Shoshitaishvili, C. Kruegel, and G. Vigna, “Driller: Augmenting fuzzing through selective symbolic execution.” in NDSS, vol. 16, 2016, pp. 1–16, issue: 2016

  32. [40]

    {QSYM}: A practical concolic execution engine tailored for hybrid fuzzing,

    I. Yun, S. Lee, M. Xu, Y . Jang, and T. Kim, “ {QSYM}: A practical concolic execution engine tailored for hybrid fuzzing,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 745–761

  33. [41]

    Angora: Efficient fuzzing by principled search,

    P. Chen and H. Chen, “Angora: Efficient fuzzing by principled search,” in 2018 IEEE Symposium on Security and Privacy (SP) . IEEE, 2018, pp. 711–725

  34. [42]

    {GREYONE}: Data flow sensitive fuzzing,

    S. Gan, C. Zhang, P. Chen, B. Zhao, X. Qin, D. Wu, and Z. Chen, “{GREYONE}: Data flow sensitive fuzzing,” in 29th USENIX security symposium (USENIX Security 20) , 2020, pp. 2577–2594

  35. [43]

    Pata: Fuzzing with path aware taint analysis,

    J. Liang, M. Wang, C. Zhou, Z. Wu, Y . Jiang, J. Liu, Z. Liu, and J. Sun, “Pata: Fuzzing with path aware taint analysis,” in 2022 IEEE Symposium on Security and Privacy (SP) . IEEE, 2022, pp. 1–17

  36. [44]

    {SelectiveTaint}: Efficient Data Flow Tracking With Static Binary Rewriting,

    S. Chen, Z. Lin, and Y . Zhang, “ {SelectiveTaint}: Efficient Data Flow Tracking With Static Binary Rewriting,” in 30th USENIX Security Symposium (USENIX Security 21) , 2021, pp. 1665–1682

  37. [45]

    Oddfuzz: Discovering java deserialization vulnerabilities via structure-aware directed greybox fuzzing,

    S. Cao, B. He, X. Sun, Y . Ouyang, C. Zhang, X. Wu, T. Su, L. Bo, B. Li, C. Ma, and others, “Oddfuzz: Discovering java deserialization vulnerabilities via structure-aware directed greybox fuzzing,” in 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 2726– 2743

  38. [46]

    DDRace: finding concurrency UAF vulnerabilities in Linux drivers with directed fuzzing,

    M. Yuan, B. Zhao, P. Li, J. Liang, X. Han, X. Luo, and C. Zhang, “DDRace: finding concurrency UAF vulnerabilities in Linux drivers with directed fuzzing,” in 32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023. [Online]. Available: https:/...

  39. [47]

    Sequence directed hybrid fuzzing,

    H. Liang, L. Jiang, L. Ai, and J. Wei, “Sequence directed hybrid fuzzing,” in 2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2020, pp. 127– 137

  40. [48]

    SDFUZZ: Target States Driven Directed Fuzzing

    P. Li, W. Meng, and C. Zhang, “SDFUZZ: Target States Driven Directed Fuzzing.”

  41. [49]

    Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs

    C. Cadar, D. Dunbar, D. R. Engler, and others, “Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs.” in OSDI, vol. 8, 2008, pp. 209–224

  42. [50]

    {ParmeSan}: Sanitizer-guided greybox fuzzing,

    S. ¨Osterlund, K. Razavi, H. Bos, and C. Giuffrida, “ {ParmeSan}: Sanitizer-guided greybox fuzzing,” in 29th USENIX Security Symposium (USENIX Security 20) , 2020, pp. 2289–2306

  43. [51]

    Predecessor-aware Directed Greybox Fuzzing

    Y . Zhang, Y . Liu, J. Xu, and Y . Wang, “Predecessor-aware Directed Greybox Fuzzing.” IEEE Computer Society, Oct. 2023, pp. 40–40, iSSN: 2375-1207. [Online]. Available: https://www.computer.org/csdl/ proceedings-article/sp/2024/313000a040/1RjEaeMELbq

  44. [52]

    Fuzzing with data dependency information,

    A. Mantovani, A. Fioraldi, and D. Balzarotti, “Fuzzing with data dependency information,” in 2022 IEEE 7th European Symposium on Security and Privacy (EuroS&P) . IEEE, 2022, pp. 286–302

  45. [53]

    DatAFLow: Toward a data- flow-guided fuzzer,

    A. Herrera, M. Payer, and A. L. Hosking, “DatAFLow: Toward a data- flow-guided fuzzer,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 5, pp. 1–31, 2023, publisher: ACM New York, NY , USA

  46. [54]

    Constraint-guided directed greybox fuzzing,

    G. Lee, W. Shim, and B. Lee, “Constraint-guided directed greybox fuzzing,” in 30th USENIX Security Symposium (USENIX Security 21) , 2021, pp. 3559–3576

  47. [55]

    One fuzz doesn’t fit all: Optimizing directed fuzzing via target-tailored program state restriction,

    P. Srivastava, S. Nagy, M. Hicks, A. Bianchi, and M. Payer, “One fuzz doesn’t fit all: Optimizing directed fuzzing via target-tailored program state restriction,” in Proceedings of the 38th Annual Computer Security Applications Conference, 2022, pp. 388–399

  48. [2020]

    Available: https://www.usenix.org/conference/woot20/ presentation/fioraldi

    [Online]. Available: https://www.usenix.org/conference/woot20/ presentation/fioraldi

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.