Accepted Papers

React Native applications increasingly ship JavaScript logic as Hermes bytecode, a custom virtual-machine format that is not supported by mainstream reverse-engineering tools. We present HermesLoader, a Ghidra extension that loads Hermes bytecode, lifts it to Ghidra's P-code intermediate representation, and exposes the resulting program through Ghidra's standard disassembly, decompilation, navigation, and cross-reference workflows. The extension combines a SLEIGH specification for Hermes bytecode version 96 with a loader that reconstructs bytecode containers as typed program objects and a small set of Hermes-specific enrichment passes for strings, field-access chains, aggregate literals, and selected function references. We evaluate the implementation on source-generated Hermes bytecode samples compiled under multiple configurations. The lifter implements all 206 opcodes in version 96; our test corpus generates 199 of them and shows broad agreement with the reference hermesc disassembly. Remaining differences are mostly representational, with incomplete recovery of some table-driven control-flow targets as the main semantic limitation. These results show that Hermes bytecode can be integrated into Ghidra as a practical basis for interactive React Native reverse engineering.

Windows packers and malware can execute 64-bit code within 32-bit processes using Heaven's Gate (HG), which switches execution to the 64-bit code segment. Most dynamic binary instrumentation (DBI) frameworks select one architecture per process and therefore cannot trace this transition. Prior work has demonstrated methods for detecting or bypassing individual gates but has not quantified the code executed through HG across protector versions. This measurement helps determine whether a black-box bypass that reproduces a gate's known effects without observing its internal execution provides sufficient behavioral fidelity. We present Janus, a hybrid Pin-Unicorn tracer that detects five HG transition forms, emulates their 64-bit execution windows, preserves state across mode transitions, forwards system calls to the native kernel, and invokes functions in the 64-bit ntdll. In VMProtect 3.10.5, a parallel 64-bit virtual machine produces values that affect subsequent 32-bit execution. A tracer that omits this window cannot recover the complete execution path to the protected program's entry point. In contrast, Themida 3.1.2 uses a 24-instruction window that performs a single system call. A longitudinal analysis of 22 versions of each protector shows that HG appears in only one of the evaluated Themida versions, whereas VMProtect retains and expands its 64-bit execution footprint. Evaluation on ACRID, HijackLoader, and Lumma samples further demonstrates HG tracing across multiple malware families, although some samples required manual neutralization of unrelated anti-analysis mechanisms before reaching the HG path. These results show that cross-architecture instrumentation is needed when subsequent execution depends on state produced within an HG window.

The first steps to analyzing a binary file, especially when using a binary analysis tool, are usually disassembly followed by lifting to an intermediate representation. This translation, from the bytes to a more expressive language, is a crucial part of the process, as it allows humans to reason about the program and tools to analyze it. As a result, any inaccuracy in the lifting can compromise the analysis as a whole. However, in order to test a binary lifter, one needs to understand the assembly language it lifts from. This can be challenging due to complex semantics, undefined behavior, and a lack of ground truth. Moreover, since each tool often comes with its own lifter and IR, an efficient tester needs to be easily reusable across tools. We introduce BiNit, a framework for testing x64 binary lifters. BiNit compares concrete values from instruction executions and their emulated lifted counterparts, making lifter bugs easier to detect and diagnose. We ran BiNit on 7 state-of-the-art tools and identified 35 semantic bugs, showing that semantic lifting errors remain common even in mature binary analysis frameworks.

Large language models are now a standard component of binary reverse-engineering pipelines, which consume decompiler output to drive vulnerability discovery, malware triage, and function summarization, at a cost that reaches thousands of dollars and billions of tokens. Yet, this output is produced for human analysts, not language models, so it carries presentation formatting and decompiler bookkeeping, such as layout whitespace, default placeholder names, and speculative casts, which inflate the token count without providing information the model can use for typical binary-analysis tasks. Because compilation discards the developer's names, types, and structure, much of this text is the decompiler's own synthesis rather than recovered signal, so it can be compressed far more aggressively than authored source code.

We introduce Deflate-D, a deterministic model-free reformatter that reduces this overhead through four cumulative tiers ordered by information loss: two lossless tiers that normalize cosmetic layout and apply structural rewrites, a meaning-preserving tier that compresses machine-generated names and types, and a reductive tier that removes decompiler boilerplate and other low-value detail. Across 109 GNU coreutils binaries, the lossless tiers alone reduce input tokens by roughly a fifth to a third, and the lossy tiers reach up to 61%. To our knowledge, Deflate-D is the first to treat decompiler output as a compression target in its own right, and we show across three downstream tasks that these savings leave task quality largely intact. We release Deflate-D and our benchmark to support reproducible, cost- and latency-aware binary analysis.

We introduce Drtti, an automated static analysis plugin for Ghidra that reconstructs high-level class hierarchies, field layouts, and virtual method tables directly from embedded Run-Time Type Information. Additionally, Drtti can import standard-library symbols from the Interactive Delphi Reconstructor (IDR). We also explore lightweight IDR-independent heuristics, such as x87 FPU instruction fingerprints, as conservative hints for locating mathematical code. We evaluate Drtti on a set of 10 Delphi applications covering Delphi 4 and Delphi 8+ VMT layouts. Results indicate that standard Ghidra analysis mapped 57.57% of executable memory to verified data or instructions on average, while Drtti alone reached 61.15% and Drtti with optional IDR symbols reached 87.66%. These results separate two effects: Drtti provides IDR-independent structural recovery inside Ghidra, while optional IDR symbols mainly add library naming and data context.

Byte-equivalent decompilation seeks source code whose recompilation reproduces the instruction sequence of a target binary. Evolving Exact Decompilation (EED)-style methods cast this task as evolutionary search, but their cost depends on the quality of the initial population. We study whether large language models can improve EED-style search when used as initializers rather than final decompilers. We implement an independent EED-style system and introduce LLM-mixed seeding, which replaces half of the initial population with LLM-generated C candidates. On small C programs reconstructed from the original EED tasks, LLM-mixed seeding improves final normalized instruction-token similarity by 17.90 percentage points over a database-seeded baseline. After controlling for generation-0 similarity and experimental factors, LLM-mixed trials also close more of the remaining gap to 100% similarity. These results suggest that LLM-generated code can provide useful starting points for recompilation-guided evolutionary search.

When a patch removes or weakens a check, it can silently grant an attacker a new capability—a read, a write, an indirect call, a pointer forged from an integer, an unauthorized data access—that was previously unreachable. The question a vulnerability researcher asks of a diff is not “is there a bug?” but “what can an attacker do now that they could not before, and through which path?” Existing analyses do not answer this: taint trackers report that data reaches a sink, and bug detectors match known single-snapshot bug shapes, but neither compares a program before and after a change, and neither treats guard removal—the disappearance of a condition that used to constrain a path—as a first-class event. We present Guarded Flow Paths (GFP), a representation in which every value carries the guard under which it flows, so that a threat is a path from a taintable source to a sensitive use, and an authority-exposing change is a path whose guard drops to unconditional across a patch.

On top of GFP we define a small declarative specification language in which a checker is just a set of sources, sinks, and sanitizers; a single differential primitive (Scope_after ∖ Scope_before over unguarded reachability) then instantiates seventeen bug classes—ten memory-safety/CWE classes and seven OWASP classes including IDOR and authentication bypass, which we show are literally authority analysis—without per-class heuristics. We describe an intra-procedural prototype that lifts LLVM IR to GFP and evaluate it on the seventeen-class suite (fixtures patterned on representative CVEs, including a real OpenSSL excerpt) against Infer, CodeQL, the Clang Static Analyzer, Semgrep, and Coverity. Existing detectors flag many of the underlying classes, but none produces the differential, per-edge-guarded capability delta that GFP makes routine.

Decompilation aims to recover high-level, compilable, and semantically equivalent code from binaries. Traditional decompilers produce pseudo-C that is difficult to read and does not compile, while the recent LLM-assisted approaches generate readable, but semantically incorrect code. LLM-aided iterative recovery is an emerging branch of research, but prior works rely on supplied test suites for semantic recovery. In this work, we present CHISEL, a test suite-free framework to iteratively recover source code from Ghidra-derived pseudo-C. CHISEL uses simple yet effective feedback from a compiler (static analysis) and a coverage-guided fuzzer (differential analysis), augmented by rich observables for grounded divergence detection and feedback, cross-iteration divergence memory, and best candidate retention. We systematically evaluate CHISEL for compilation and semantic recovery, feedback oracle soundness, and iteration overhead on 120 ExeBench functions compiled for the x86-64 architecture, across four optimizations (O0-O3), in both stripped and unstripped variants, using the open-weight Gemma4:31b LLM. CHISEL, with all recommended features, achieves an average of 96.1% re-compilability and 79.8% re-executability rates at an average of 2.1 iterations. Significantly, CHISEL recovers 26% of first-generation execution errors. At the same time, CHISEL's feedback oracle falsely accepts only 9.4% candidates. Lastly, CHISEL performs significantly better than two recent prior work on LLM-assisted decompilation.

Tracers and debuggers are indispensable tools when it comes to software understanding. General-purpose debuggers such as WinDbg and GDB are often the first tool developers turn to for troubleshooting bugs. Specialized tracers such as Wireshark, a network traffic inspector, and eBPF, a Linux kernel tracing and hook system, have greatly improved a non-expert's ability to inspect and understand the technology. In recognition of the essentially of domain-specific tracers, we are introducing Hook Captain (HC), a domain-specific tracer fabrication framework. HC provides a consistent means of defining domain-specific tracers independently from the instrumentation mechanism and runtime in an universal and principled manner. An initial HC prototype has been built to explore HC's underlying concepts and utility.

Nuitka is a Python compiler that translates Python into native binaries via C. Because Nuitka-compiled binaries are incompatible with existing Python decompilers, to the best of our knowledge, no established method exists for recovering semantically equivalent Python source code from them. We exploit Nuitka's characteristic behavior of mechanically converting Python operations into specific helper calls. This reduces recovery to two transformations, boilerplate removal and helper mapping, which we realize within a four-stage pipeline built on the angr binary analysis framework. We evaluate it with a proof-of-concept tool that decompiles actual Nuitka-compiled binaries. Although boilerplate with control structures (e.g., exception handling) is still hard to remove without harming user code, our results show that the method can recover functions composed of multiple operations.

Large language models (LLMs) are increasingly applied to reverse engineering (RE), yet existing benchmarks often collapse those measured capabilities into a single score and confound them with the conditions of measurement, without fine-grained control over the evidence presented, the interaction mode and budget (tokens, tool calls), or the prompt framing (a single priming word can manufacture FPs or guide the model unfairly). Opaque vendor training data also risks memorization, especially for benchmarks built on CTF binaries or other public corpora.

We present llm-re-bench, a framework that aims to address these shortcomings in existing LLM-RE benchmarks through independently controlled axes: multi-modal evidence or artifact (e.g., raw bytes, structured extraction, or derived text); interaction mode and budget (pure-static, non-agentic, or agentic tool use under step/tool caps); and prompt framing (explicit, implicit, vague).

Rather than confounding or collapsing measurements per run, each records fine-grained artifacts—tool-call and step counts, reasoning-vs-visible tokens, and per-dimension scores—surfacing operational differences (disassembly vs. obfuscation detection; single-component vs. whole-binary scope) that aggregate metrics occlude. Runs are deterministically isolated, fully transcribed, and database-ingestible. The framework ships a taxonomy-rich, layered-artifact corpus (including but not limited to obfuscation, algorithm-identification, vulnerability and backdoor detection), which we contrast with recent decompilation, vulnerability, name/type-recovery, agentic-readability, and human-teaming benchmarks.

Binary code similarity detection (BCSD) matches semantically equivalent compiled functions for reverse engineering. Although transformer-based BCSD systems commonly normalize assembly before tokenization, the impact of these choices remains unclear. To bridge this gap, we study 17 normalization strategies that abstract different parts of assembly syntax, including numeric constants, registers, memory operands, punctuation, and jumps. We evaluate these strategies on an x86-64 benchmark spanning multiple compilers, optimization levels, and obfuscation transforms, using three complementary views: retrieval performance, semantic preservation, and linguistic effects. Our results show that assembly normalization is not inherently beneficial for transformer-based BCSD. Raw assembly is already a strong project-level retrieval baseline with a sufficiently expressive encoder, and most abstractions add little or hurt performance. Most notably, numeric abstraction consistently degrades retrieval: immediates are often normalized as build-specific noise, but our results suggest that they carry useful function-level signals. The main risk is therefore not under-normalization, but normalizing away useful signals.