Pith. sign in

REVIEW 4 major objections 6 minor 57 references

TransferFuzz: Fuzzing with Historical Trace for Verifying Propagated Vulnerability Code

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read TransferFuzz claims that the crash history of a known-vulnerable binary can guide fuzzing of any binary reusing its code, producing a proof-of-concept that verifies the propagated vulnerability.

desk verdict TransferFuzz's trace-transfer idea is a real step forward for vulnerability verification, but the 38/38 claim needs a transparent ground-truth protocol and a clear statement about three shortcut-validated cases. read the letter →

arxiv 2411.18347 v1 pith:Z7NQLO6G submitted 2024-11-27 cs.SE

Siyuan Li , Yuekang Li , Zuxin Chen , Chaopeng Dong , Yongpan Wang , Hong Li , Yongle Chen , Hongsong Zhu This is my paper · ORCID
classification cs.SE
keywords vulnerabilitypropagationcodereusetrace-guidedfuzzinghistoricaltracekeybytessimulatedannealingproof-of-conceptgenerationbinaryanalysis
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

TransferFuzz tries to prove that a vulnerability spread by code reuse can be automatically verified in a new binary by transferring the original binary's execution history rather than its proof-of-concept file. The paper's claim is that two artifacts extracted from the known-vulnerable binary—the function call sequence that reaches the crash and the specific input bytes that satisfy branch checks in the reused code—are enough to guide a fuzzer of the target binary to a working proof-of-concept. If this holds, software-security teams can replace similarity-based 'this binary contains the vulnerable code' warnings with 'here is an input that crashes it,' which is what makes the affected-software scope of a CVE actionable. On the paper's dataset TransferFuzz reports perfect precision and recall, verifies all 38 propagated samples, and expands the affected binaries for 15 CVEs from 15 to 53.

What carries the argument

The load-bearing object is the historical trace, defined as two runtime artifacts harvested from the basic binary: a function-level trace (the call sequence from program entry to the crashing function, enriched by fuzzing the basic binary) and key-byte traces (proof-of-concept bytes that taint analysis shows reaching conditional statements inside the reused code). The mechanism that carries the argument is the trace-guided fuzzer built on these artifacts: a Nested Simulated Annealing algorithm maintains one annealing schedule per observed state in the call sequence, so energy flows to seeds that advance along the recorded path while earlier states are never fully abandoned, and Key Bytes Guided Mutation inserts the extracted bytes as a mutation dictionary to bypass branch constraints in the reused code.

What would settle it

Recompile the same reused library with a one-line change that makes the vulnerable path unreachable but keeps function names and crash addresses identical; if TransferFuzz still emits a crashing POC or labels the patched binary as verified, the crash-address oracle and trace-transfer premise are both implicated. Conversely, take a target known to be triggerable from a CVE POC and strip its symbols; if function matching misaligns the trace and the fuzzer cannot reproduce the crash, the claimed recall of 1.0 would not transfer outside the dataset.

Watch

Extended reading notes

Core claim

The central claim is that the vulnerability-triggering behavior of reused code is portable. TransferFuzz records function-level traces by running the CVE-described binary on its proof-of-concept and by directed-fuzzing that binary for additional crash paths; it records key-byte traces by taint-tracking which proof-of-concept bytes flow into conditional branches inside the reused functions. It then aligns the function names or matched functions from the basic binary to the target binary, builds a state machine from the recorded call sequence, and uses nested simulated annealing to schedule fuzzing energy so that the target binary explores the transferred path before wasting effort elsewhere. A dictionary of extracted key bytes is applied during mutation to satisfy the branch checks that would otherwise block deep exploration. The paper's stated result is that this trace-guided process validates all 38 propagated vulnerability samples in its evaluation, matching crashes by address, and does so faster than directed-fuzzing baselines.

Load-bearing premise

The traces taken from the original vulnerable binary still describe the same vulnerability-triggering path after the functions are matched into the target binary: the reused code must behave the same way when called, the key bytes that satisfied its branch checks must still satisfy them, and a crash at the same address is taken as proof of the same bug.

Editorial extensions

If this is right

  • If the trace-transfer claim is correct, verifying a propagated vulnerability reduces to replaying guiding information rather than rediscovering the path from scratch; the paper reports most verifications finishing within minutes and several previously untriggerable logic-heavy vulnerabilities becoming triggerable.
  • CVE impact statements can be corrected automatically: the paper reports that 15 vulnerabilities' affected binaries grew from 15 to 53 because a generated proof-of-concept, not a similarity score, confirmed each new target.
  • Target binaries with different input formats than the basic binary are no longer out of reach: only the trace is transferred, so a string-based proof-of-concept from one tool can guide fuzzing of an ELF-reading tool in the same library.
  • The approach acts as a downstream filter for code-reuse detectors, converting their high-recall low-precision findings into verified crashes; on the dataset the reported precision rises from the reuse detector's 0.26 to TransferFuzz's 1.0.

Reading between the lines

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

  • Beyond the paper, the key-byte dictionary is effectively a portable input-to-state map: it might transfer to fork-level regression testing or to patch-presence testing, where the same bytes could decide whether a branch behaves like the vulnerable or the patched version.
  • Section V.D records that without starting from the basic POC, none of the methods—TransferFuzz included—could trigger three CVEs (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330), so the reported recall of 1.0 is defined on the 38 samples actually verified, not on every propagated vulnerability in the dataset.
  • The negative verdicts (reused code reached but no crash) are bounded by the fuzzing budget and by the crash-address oracle; a cleaner evaluation would apply the same pipeline to known-patched binaries to measure how often it wrongly reports or wrongly clears them.
  • A build-level test with the same library compiled under different optimization flags and linked through different callers would isolate whether trace transferability comes from the reused code itself or from the specific binaries in the dataset.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes TransferFuzz, a framework for verifying whether vulnerabilities propagated through code reuse are actually triggerable in a target binary. It extracts two kinds of historical traces from the basic binary and its POC—function call sequences (FCS) and key bytes that influence branch conditions in the reused code—aligns these traces to the target binary via function matching, and uses them to guide fuzzing through a Key Bytes Guided Mutation strategy and a Nested Simulated Annealing energy schedule. The evaluation covers 15 CVEs and 76 binaries, and the paper reports precision 1.0 and recall 1.0, claiming that TransferFuzz 'successfully validated all 38 propagated vulnerability samples,' with verification speeds 2.5 to 26.2 times faster than existing directed fuzzing baselines, and expands the number of affected binaries from 15 to 53.

Significance. If the evaluation is sound, TransferFuzz addresses a real gap: code-reuse and patch-presence detectors identify potentially vulnerable code but do not establish that the vulnerability is reachable and controllable in a new binary, and prior directed fuzzing is slow on complex triggers. The idea of transferring runtime traces from a known vulnerable binary to a code-reusing target is plausible and novel, and the TTE data—10/10 successful runs on multiple cases where baselines fail, with large consistent speedups—provide credible evidence that the approach works on the studied dataset. The paper also makes its prototype and dataset available, which supports reproducibility. However, the headline accuracy claims depend on a manually constructed ground truth whose protocol is not described, and the treatment of true negatives and of three specific CVEs contains internal inconsistencies that must be resolved before the central claim can be accepted.

major comments (4)
  1. [Section V.D and Table 2] The note in Section V.D states that 'without using POCs of basic binary, none of the methods, including TransferFuzz, could generate POCs for three vulnerabilities (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330).' This directly contradicts the claim in Section V.C and in the abstract that TransferFuzz 'successfully validated all 38 propagated vulnerability samples,' because Table 1 lists exactly these three CVEs among the 38 propagated samples (one target each: xpdf, ffmpeg, mozjpeg). The only way to reconcile the two statements is that these three cases were validated by directly using the basic POC—the shortcut that Section V.D explicitly excludes from the RQ2 efficiency comparison. Please report the numbers separately (for example, 35/38 verified by trace-guided fuzzing and 3/38 verified by direct POC reuse) and revise the abstract, Section V.C, and the 'all 38' phrasing accordingly.
  2. [Section V.A] The construction of the ground-truth labels is not described. The sentence 'After manually filtering out 108 false positives' gives no protocol: it does not state whether the manual filtering was based on source-level patch analysis, independent crash reproduction, or the same GDB crash-address check that TransferFuzz uses for verification (Section IV). If the labels and the TransferFuzz oracle share the same crash-address criterion, then the precision and recall values of 1.0 in Table 2 are circular. Please provide a detailed labeling protocol, including the evidence used for each of the 146 candidates, who performed the labeling, and confirmation that the labels were fixed before running TransferFuzz.
  3. [Table 2 and Section V.C] The TN=108 entries for TransferFuzz and for all other methods are not justified by the experimental design. A 12-hour fuzzing run without a crash does not prove that a vulnerability is not triggerable; it only shows that no crash occurred within the budget. The paper itself acknowledges in Section III.A that the outcomes 'reuse code is reached but the vulnerability is not triggered' and 'the reuse code area is not reached' imply only that the vulnerability 'cannot be or is difficult to be triggered,' and that 'further manual verification is required.' Therefore, the TN column should not be presented as 'correctly detected as non-propagated.' Please either provide independent verification for the 108 negative cases or restrict the precision/recall computation to the positive samples and label the no-crash outcomes as 'not triggered within the budget.'
  4. [Section III.B.1] The method's correctness rests on the transferability premise that 'the basic binary and target binary tend to have the same vulnerability triggering path in the reused code area due to having the same code,' together with the assumption that the function-level traces remain valid after FCG alignment. The evaluation does not report how many of the 15 CVEs involved stripped target binaries where function matching relied on LibAM, nor whether any alignment mismatches or reused-code modifications (e.g., recompilation, different call context) were observed. Since a misalignment would lead the fuzzer away from the vulnerability path and could affect both generated POCs and 'cannot trigger' verdicts, please report the alignment results for each case, including how often function names were present and how often LibAM was used.
minor comments (6)
  1. [Section II] The term 'Path Presentation Detection methods' appears to be a typo for 'Patch Presence Detection methods'; please correct it.
  2. [Section V.D] 'cann't' is a typographical error; it should be 'cannot'.
  3. [Section V.C and Section V.F] The name is spelled inconsistently as 'TrasnferFuzz' in several places; please make the spelling uniform throughout.
  4. [Equation (1) and Algorithm 2] The notation '0.5Ti' in Equation (1) is ambiguous; it should be written as 0.5·T_i to make clear that the nested product multiplies 0.5 by each later temperature, and the correspondence between the equation and the loop in Algorithm 2 should be stated explicitly.
  5. [Table 3] The bottom row 'µTTE inc (all binaries)' is unclear about which binaries are included in the aggregate percentage (e.g., only those where the baseline triggered at least one run) and how the percentage is computed from the per-run µTTE values; please define this row precisely.
  6. [Section V.D] The text refers to 'Vul-10' and similar labels, but Table 3 lists entries by number and CVE only; please align the in-text references with the numbering used in the table.

Circularity Check

1 steps flagged · score 6.0 of 10

38/38 verification claim partially reduces to direct reuse of basic-binary POCs; three CVE cases are counted as TransferFuzz TPs although no tool generated their POCs without those POCs.

  1. fitted input called prediction [Section V.D (RQ2) vs. Section V.C and Table 2 (RQ1)]
    "To ensure a fair evaluation of each fuzzer, we did not take shortcuts by directly using POCs from basic binaries, which is different from the settings in RQ1. ... Notably, without using POCs of basic binary, none of the methods, including TransferFuzz, could generate POCs for three vulnerabilities (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330)."

    Section V.C reports 'TransferFuzz successfully validated all 38 propagated vulnerability samples' (TP=38, recall 1.0). Section V.D reveals that in the RQ1 setting, which explicitly allowed the shortcut of directly using basic-binary POCs, three of those samples could not be given POCs by any method, including TransferFuzz, without using the basic binary's POC. Those three TP entries therefore record the input POC itself as validation output rather than a TransferFuzz-generated target POC. Counting input-derived cases as successful predictions makes the 'all 38' claim true by construction for these three cases, not by the historical-trace-guided fuzzing chain. The remaining 35 TP entries are independently generated, so the circularity is partial rather than total.

full rationale

The core mechanism is not equation-level circular: function-level traces and key bytes are extracted from the basic binary's crashing POC and then used to guide mutation on the target binary, with the final crash artifact being an externally checkable target execution. The LibAM self-citation is a precursor component and is not load-bearing for the derivation. The main circular problem is the evaluation accounting for three vulnerabilities: the paper itself states that no method, including TransferFuzz, could generate POCs for CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330 without using the basic binary's POC, and that RQ1 differed by allowing that shortcut. Yet these three are included in the 'successfully validated all 38' claim and in the perfect precision/recall table. For these cases, the validation result is the input POC relabeled as the method's output, so the central claim partially reduces by construction. Separately, the manual filtering protocol for ground-truth labels in Section V.A is not described, so label independence is unverified; this is an evaluation-validity concern rather than a demonstrated circular reduction. Given that 35 of 38 cases still rest on independent fuzzing runs, the partial circularity warrants a score of 6 rather than higher.

Assumptions & free parameters 3 free parameters · 5 assumptions · 3 invented entities

The central claim rests on two families of imported premises: (1) tooling premises inherited from the fuzzing and taint stack (accuracy of PIN taint tracking, GDB stack extraction, LibAM function matching), and (2) transferability premises specific to this paper: that execution traces and condition-satisfying bytes extracted from the basic binary remain valid in the target binary. The framework introduces no fitted global constants; the tunable values are the NSA energy split (0.5) and the adopted AFLGo annealing schedule. The 'invented entities' are operational artifacts (traces, state machines), not unobserved physical entities, and all but the state machines carry direct empirical handles.

free parameters (3)
  • NSA initial energy split ratio = 0.5
    Algorithm 2 and Equation 1 fix the energy split between newly reached and older states at 0.5; chosen by hand, not justified by measurement.
  • Simulated annealing cooling schedule including tx moment = adopted from AFLGo
    Section III.C.1 reuses AFLGo's annealing schedule and transition point tx without recalibration; the schedule determines how quickly energy concentrates on the deepest reached state.
  • Fuzzing time budget = 12 hours
    Section V sets a 12-hour budget for all fuzzers; reported TTE numbers and N.A. entries in Table 3 depend on this cap.
assumptions (5)
  • domain assumption Target and basic binary have the same vulnerability-triggering path in the reused code area (Section III.B.1).
    FCS traces from the basic binary are assumed to align with feasible paths in the target after FCG alignment; if the reused code diverges, the traces mislead fuzzing.
  • domain assumption Function matching (names or LibAM/BCSD) correctly maps basic-binary functions to target-binary functions on stripped binaries (Section III.B.1).
    FCG alignment quality bounds the quality of all downstream guidance; misaligned functions invalidate both state machines and key-byte placement.
  • domain assumption Key bytes that bypass conditional branches unchanged from the POC also satisfy the corresponding branches in the target's copy of the reused code (Section III.B.2).
    KBGM inserts extracted bytes at arbitrary locations in target seeds; validity rests on the target's comparison logic reading those bytes identically.
  • domain assumption A crash at the recorded crash address, checked via GDB (Section IV), certifies the same vulnerability in the target binary.
    Crash-address matching is the verification oracle; it can misattribute a different bug crashing at the same address and cannot certify non-crashing cases.
  • domain assumption PIN-based taint analysis correctly identifies POC bytes that reach comparisons in reused code (Algorithm 1).
    Key-byte extraction quality depends on the taint tracker's precision; imprecise taint either misses key bytes or includes irrelevant ones.
invented entities (3)
  • function-level traces (FCS) independent evidence
    purpose: Guide target-binary fuzzing along vulnerability-relevant call paths
    Measured artifacts from GDB and directed fuzzing of the basic binary; a re-run can reproduce them.
  • key-bytes traces independent evidence
    purpose: Dictionary for bypassing branch constraints in reused code
    Extracted via PIN taint analysis; observable by re-running Algorithm 1.
  • nested simulated annealing state machines
    purpose: Energy scheduling over per-path state machines during fuzzing
    A scoring mechanism inside the fuzzer; its parameters and state progression are not externally measurable.

how reviews work

0 comments
Cite this review

Pith. "Pith review of TransferFuzz: Fuzzing with Historical Trace for Verifying Propagated Vulnerability Code." pith.science (2026). https://pith.science/paper/Z7NQLO6G

@misc{pith2026241118347,
  author       = {Pith},
  title        = {Pith review of: TransferFuzz: Fuzzing with Historical Trace for Verifying Propagated Vulnerability Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Z7NQLO6G}},
  note         = {Machine review of arXiv:2411.18347}
}
read the original abstract

Code reuse in software development frequently facilitates the spread of vulnerabilities, making the scope of affected software in CVE reports imprecise. Traditional methods primarily focus on identifying reused vulnerability code within target software, yet they cannot verify if these vulnerabilities can be triggered in new software contexts. This limitation often results in false positives. In this paper, we introduce TransferFuzz, a novel vulnerability verification framework, to verify whether vulnerabilities propagated through code reuse can be triggered in new software. Innovatively, we collected runtime information during the execution or fuzzing of the basic binary (the vulnerable binary detailed in CVE reports). This process allowed us to extract historical traces, which proved instrumental in guiding the fuzzing process for the target binary (the new binary that reused the vulnerable function). TransferFuzz introduces a unique Key Bytes Guided Mutation strategy and a Nested Simulated Annealing algorithm, which transfers these historical traces to implement trace-guided fuzzing on the target binary, facilitating the accurate and efficient verification of the propagated vulnerability. Our evaluation, conducted on widely recognized datasets, shows that TransferFuzz can quickly validate vulnerabilities previously unverifiable with existing techniques. Its verification speed is 2.5 to 26.2 times faster than existing methods. Moreover, TransferFuzz has proven its effectiveness by expanding the impacted software scope for 15 vulnerabilities listed in CVE reports, increasing the number of affected binaries from 15 to 53. The datasets and source code used in this article are available at https://github.com/Siyuan-Li201/TransferFuzz.

Figures

Figures reproduced from arXiv: 2411.18347 by the authors.

Figure 1
Figure 1. Propagated vulnerability code. Red nodes are vulnerability information [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. A motivation example. The red node is the vulnerability function of CVE-2016-4487. Gray nodes are functions known to be on the vulnerability [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The workflow of TransferFuzz. execute the corresponding POC on the basic binary to collect run-time FCS as function-level traces to guide the subsequent fuzzing of the target binary. In addition, we find the path that triggers a vulnerability may not be single. Therefore, we also run a generic directed fuzz on the basic binary to collect more paths that may trigger the vulnerability. All the paths with run￾time info… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: State machine diagram in NSA algorithm. Ej =    Q i>j 0.5Ti if j = 0, (1 − 0.5Tj ) · Q i>j 0.5Ti if j > 0. (1) Within this context, Ej denotes the energy of the j th state, while Tj represents the temperature parameter [20] for the j th state, calculated using the…
Figure 5
Figure 5. Figure 5: CPU and Memory Usage. The green bars represent CPU Usage, while [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 36 canonical work pages

  1. [1]

    “github.” 2023, https://github.com/

    work page 2023

  2. [2]

    Sourceforge

    “Sourceforge.” 2023, https://sourceforge.net/

    work page 2023

  3. [3]

    “Vcpkg.” 2023, https://vcpkg.io/

    work page 2023

  4. [4]

    Synopsys 2022 open source security and risk analysis report

    Synopsys, “Synopsys 2022 open source security and risk analysis report.” 2022, https://www.synopsys.com/software-integrity/resources/ analyst-reports/open-source-security-risk-analysis.html

    work page 2022

  5. [5]

    LibAM: An Area Matching Framework for Detecting Third-party Libraries in Binaries

    S. Li, Y . Wang, C. Dong, S. Yang, H. Li, H. Sun, Z. Lang, Z. Chen, W. Wang, H. Zhuet al., “Libam: An area matching framework for detect- ing third-party libraries in binaries,” arXiv preprint arXiv:2305.04026 , 2023

    work page Pith review arXiv 2023

  6. [6]

    “Cve,” 2023, https://cve.mitre.org/

    work page 2023

  7. [7]

    “Nvd,” 2023, https://nvd.nist.gov/

    work page 2023

  8. [8]

    Identifying open- source license violation and 1-day security risk at large scale,

    R. Duan, A. Bijlani, M. Xu, T. Kim, and W. Lee, “Identifying open- source license violation and 1-day security risk at large scale,” in Proceedings of the 2017 ACM SIGSAC Conference on computer and communications security, 2017, pp. 2169–2185

    2017

Show all 57 references
  1. [9]

    B2sfinder: detecting open-source software reuse in cots software,

    Z. Yuan, M. Feng, F. Li, G. Ban, Y . Xiao, S. Wang, Q. Tang, H. Su, C. Yu, J. Xu et al. , “B2sfinder: detecting open-source software reuse in cots software,” in 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 2019, pp. 1038–1049

    2019

  2. [10]

    A large-scale empirical analysis of the vul- nerabilities introduced by third-party components in iot firmware,

    B. Zhao, S. Ji, J. Xu, Y . Tian, Q. Wei, Q. Wang, C. Lyu, X. Zhang, C. Lin, J. Wu et al. , “A large-scale empirical analysis of the vul- nerabilities introduced by third-party components in iot firmware,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Softwa...

    2022

  3. [11]

    Neural network- based graph embedding for cross-platform binary code similarity detec- tion,

    X. Xu, C. Liu, Q. Feng, H. Yin, L. Song, and D. Song, “Neural network- based graph embedding for cross-platform binary code similarity detec- tion,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security , 2017, pp. 363–376

    2017

  4. [12]

    Jtrans: Jump-aware transformer for binary code similarity detection,

    H. Wang, W. Qu, G. Katz, W. Zhu, Z. Gao, H. Qiu, J. Zhuge, and C. Zhang, “Jtrans: Jump-aware transformer for binary code similarity detection,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , 2022, pp. 1–13

    2022

  5. [13]

    Asteria: Deep learning-based ast-encoding for cross-platform binary code similarity detection,

    S. Yang, L. Cheng, Y . Zeng, Z. Lang, H. Zhu, and Z. Shi, “Asteria: Deep learning-based ast-encoding for cross-platform binary code similarity detection,” in 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) . IEEE, 2021, pp. 224–236

    2021

  6. [14]

    Libdi: A direction identification framework for detecting complex reuse relationships in binaries,

    S. Li, C. Dong, Y . Wang, W. Liu, W. Wang, H. Li, H. Zhu, and L. Sun, “Libdi: A direction identification framework for detecting complex reuse relationships in binaries,” in MILCOM 2023-2023 IEEE Military Communications Conference (MILCOM) . IEEE, 2023, pp. 741–746

    2023

  7. [15]

    Third-party library dependency for large-scale sca in the c/c++ ecosystem: How far are we?

    L. Jiang, H. Yuan, Q. Tang, S. Nie, S. Wu, and Y . Zhang, “Third-party library dependency for large-scale sca in the c/c++ ecosystem: How far are we?” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis , ser. ISSTA 2023. New York, N...

    2023 doi

  8. [16]

    Precise and accurate patch presence test for binaries,

    H. Zhang and Z. Qian, “Precise and accurate patch presence test for binaries,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 887–902

    2018

  9. [17]

    Pdiff: Semantic-based patch presence testing for downstream kernels,

    Z. Jiang, Y . Zhang, J. Xu, Q. Wen, Z. Wang, X. Zhang, X. Xing, M. Yang, and Z. Yang, “Pdiff: Semantic-based patch presence testing for downstream kernels,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security , 2020, pp. 1149–1163

    2020

  10. [18]

    Libvdiff: Library version difference guided oss version identification in binaries,

    C. Dong, S. Li, S. Yang, Y . Xiao, Y . Wang, H. Li, Z. Li, and L. Sun, “Libvdiff: Library version difference guided oss version identification in binaries,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering , ser. ICSE ’24. New York, NY , USA...

    2024

  11. [19]

    Towards practical binary code similarity detection: Vulnerability verification via patch semantic analysis,

    S. Yang, Z. Xu, Y . Xiao, Z. Lang, W. Tang, Y . Liu, Z. Shi, H. Li, and L. Sun, “Towards practical binary code similarity detection: Vulnerability verification via patch semantic analysis,” ACM Trans. Softw. Eng. Methodol. , vol. 32, no. 6, sep 2023. [Online]. Available: https...

    2023 doi

  12. [20]

    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

    2017

  13. [21]

    Binary-level directed fuzzing for {Use-After-Free} vulnerabilities,

    M.-D. Nguyen, S. Bardin, R. Bonichon, R. Groz, and M. Lemerre, “Binary-level directed fuzzing for {Use-After-Free} vulnerabilities,” in 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020) , 2020, pp. 47–62

    2020

  14. [22]

    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

    2022

  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

    2022

  16. [24]

    Octopocs: automatic verifica- tion of propagated vulnerable code using reformed proofs of concept,

    S. Kwon, S. Woo, G. Seong, and H. Lee, “Octopocs: automatic verifica- tion of propagated vulnerable code using reformed proofs of concept,” in 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) . IEEE, 2021, pp. 174–185

    2021

  17. [25]

    {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

    2023

  18. [26]

    {FuzzGuard}: Filtering out unreachable inputs in directed grey-box fuzzing through deep learning,

    P. Zong, T. Lv, D. Wang, Z. Deng, R. Liang, and K. Chen, “{FuzzGuard}: Filtering out unreachable inputs in directed grey-box fuzzing through deep learning,” in 29th USENIX security symposium (USENIX security 20) , 2020, pp. 2255–2269

    2020

  19. [27]

    Facilitating vulnerability assessment through poc migration,

    J. Dai, Y . Zhang, H. Xu, H. Lyu, Z. Wu, X. Xing, and M. Yang, “Facilitating vulnerability assessment through poc migration,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security , ser. CCS ’21. New York, NY , USA: Association for Computing ...

    2021

  20. [28]

    Optimization by simulated annealing,

    S. Kirkpatrick, C. D. Gelatt Jr, and M. P. Vecchi, “Optimization by simulated annealing,” science, vol. 220, no. 4598, pp. 671–680, 1983

    1983

  21. [29]

    {AFL++}: Combin- ing incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “ {AFL++}: Combin- ing incremental steps of fuzzing research,” in 14th USENIX Workshop on Offensive Technologies (WOOT 20) , 2020

    2020

  22. [30]

    Redqueen: Fuzzing with input-to-state correspondence

    C. Aschermann, S. Schumilo, T. Blazytko, R. Gawlik, and T. Holz, “Redqueen: Fuzzing with input-to-state correspondence.” in NDSS, vol. 19, 2019, pp. 1–15

    2019

  23. [31]

    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), 2023, pp. 2693–2707

    2023

  24. [32]

    “Gdb.” 2023, https://www.gnu.org/software/gdb/

    2023

  25. [33]

    “Pin.” 2023, https://software.intel.com/sites/landingpage/pintool/docs/98 484/Pin/html/index.html

    2023

  26. [34]

    Automata-guided control-flow-sensitive fuzz driver generation

    C. Zhang, Y . Li, H. Zhou, X. Zhang, Y . Zheng, X. Zhan, X. Xie, X. Luo, X. Li, Y . Liuet al., “Automata-guided control-flow-sensitive fuzz driver generation.” in USENIX Security Symposium , 2023, pp. 2867–2884

    2023

  27. [35]

    A survey of binary code fingerprinting approaches: Taxonomy, methodologies, and features,

    S. Alrabaee, M. Debbabi, and L. Wang, “A survey of binary code fingerprinting approaches: Taxonomy, methodologies, and features,” ACM Computing Surveys (CSUR) , vol. 55, no. 1, pp. 1–41, 2022

    2022

  28. [36]

    A survey of binary code similarity,

    I. U. Haq and J. Caballero, “A survey of binary code similarity,” ACM Computing Surveys (CSUR) , vol. 54, no. 3, pp. 1–38, 2021

    2021

  29. [37]

    Finding software license violations through binary code clone detection,

    A. Hemel, K. T. Kalleberg, R. Vermaas, and E. Dolstra, “Finding software license violations through binary code clone detection,” in Proceedings of the 8th Working Conference on Mining Software Repos- itories, 2011, pp. 63–72

    2011

  30. [38]

    Libdx: A cross-platform and accurate system to detect third-party libraries in binary code,

    W. Tang, P. Luo, J. Fu, and D. Zhang, “Libdx: A cross-platform and accurate system to detect third-party libraries in binary code,” in 2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 2020, pp. 104–115

    2020

  31. [39]

    Similarity of binaries through re- optimization,

    Y . David, N. Partush, and E. Yahav, “Similarity of binaries through re- optimization,” in Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation , 2017, pp. 79–94

    2017

  32. [40]

    Viva: Binary level vulnerability identification via partial signature,

    Y . Xiao, Z. Xu, W. Zhang, C. Yu, L. Liu, W. Zou, Z. Yuan, Y . Liu, A. Piao, and W. Huo, “Viva: Binary level vulnerability identification via partial signature,” in 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2021, pp. 213– 224

    2021

  33. [41]

    {BinSim}: Trace-based semantic binary diffing via system call sliced segment equivalence checking,

    J. Ming, D. Xu, Y . Jiang, and D. Wu, “ {BinSim}: Trace-based semantic binary diffing via system call sliced segment equivalence checking,” in 26th USENIX Security Symposium (USENIX Security 17) , 2017, pp. 253–270

    2017

  34. [42]

    Bingo: Cross-architecture cross-os binary search,

    M. Chandramohan, Y . Xue, Z. Xu, Y . Liu, C. Y . Cho, and H. B. K. Tan, “Bingo: Cross-architecture cross-os binary search,” in Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering , 2016, pp. 678–689

    2016

  35. [43]

    Safe: Self-attentive function embeddings for binary similarity,

    L. Massarelli, G. A. D. Luna, F. Petroni, R. Baldoni, and L. Querzoni, “Safe: Self-attentive function embeddings for binary similarity,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 2019, pp. 309–329

    2019

  36. [44]

    {MVP}: Detecting vulnerabilities using {Patch-Enhanced} vulnerability signatures,

    Y . Xiao, B. Chen, C. Yu, Z. Xu, Z. Yuan, F. Li, B. Liu, Y . Liu, W. Huo, W. Zou et al. , “ {MVP}: Detecting vulnerabilities using {Patch-Enhanced} vulnerability signatures,” in 29th USENIX Security Symposium (USENIX Security 20) , 2020, pp. 1165–1182

    2020

  37. [45]

    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

    2019

  38. [46]

    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, ...

    2015

  39. [47]

    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...

    2022

  40. [48]

    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

    2019

  41. [49]

    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

    2019

  42. [50]

    Westworld: Fuzzing- assisted remote dynamic symbolic execution of smart apps on iot cloud platforms,

    L. Luo, Q. Zeng, B. Yang, F. Zuo, and J. Wang, “Westworld: Fuzzing- assisted remote dynamic symbolic execution of smart apps on iot cloud platforms,” in Annual Computer Security Applications Conference, 2021, pp. 982–995

    2021

  43. [51]

    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

    2021

  44. [52]

    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

    2019

  45. [53]

    {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

    2017

  46. [54]

    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

    2020

  47. [55]

    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

    2020

  48. [56]

    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

    2019

  49. [57]

    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

    2018

Pith tools

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