AWESOME REA · EDITORIAL SURVEY

Reverse Engineering Anything: An Evidence-Centered Survey

Methods, evidence and limits across six domains of software reconstruction.

Version 1.0 · · Awesome REA contributors

AI-assisted editorial synthesis. No new experiments; not peer reviewed.

53papers in the snapshot
6domains of reconstruction
8cases compared here
Contents · 15 sections

Abstract

Reverse engineering reconstructs different objects from different evidence: a visual layout from an image, a rule model from interaction, source hypotheses from binary code, or an execution environment around retained firmware. This editorial survey brings together a frozen corpus of 53 papers and eight documented project cases to examine what those reconstructions establish. We organize the literature across websites, games, apps, binaries, firmware and protocols, comparing observation access, reconstructed outputs and acceptance checks. The central argument is that an outcome becomes interpretable only when all three are specified. Visual similarity, a matching build, finite test agreement and successful service startup constrain different properties and cannot be combined into a single recovery score. The selected cases show how original assets, prior source exposure, inherited implementations and cloud dependencies further shape a result. Across domains, the strongest opportunities for clearer evaluation are explicit accounting of supplied information, checks beyond construction-time examples, and separate reporting of structural, visual and behavioral evidence. This synthesis provides a framework for comparing claims and identifying untested boundaries, rather than a ranking of systems. [1] [2] [3]

1. Scope and review method

The literature discussion uses the 53-paper corpus frozen for this version. This synthesis examines what publicly documented reconstruction cases can establish about agent-assisted reverse engineering. The pinned catalog contains 189 resources, including 56 case studies. Eight cases are selected for contrasts in inputs, outputs and checks, not to estimate success rates or rank tools. Conventional matching-decompilation projects provide reference points for evaluating newer agent-assisted workflows; inclusion does not imply AI or REA involvement.

Discovery ledgers are used to track leads and review coverage, not as a sample of reconstruction performance. They include unresolved reports, discussions and tools, so listing counts are not counts of independently verified projects. The eight selected cases provide purposive contrasts within this catalog snapshot; they do not constitute an exhaustive or systematic search.

The analysis uses the catalog’s recorded source reviews: pinned documentation, implementation and test definitions, stated prerequisites, and explicit limitations. Source-reviewed means that supporting material was inspected; it does not mean that the original, reconstruction or tests were executed for this survey. Author-reported results remain attributed. A build recipe, a test definition and a saved passing result are different evidence objects.

Here, an acceptance oracle means a rule, reference, or test used to judge a reconstructed output. For each case, we distinguish the available input, reconstructed output, acceptance check and untested remainder. This prevents a successful intermediate step from silently becoming a claim about an entire product. Source pins and version restrictions matter because later changes can alter the target, validator or dependencies without changing a project’s name.

A useful evidence record separates checks that are defined, eligible, executed and passed. A missing fixture, disabled comparison or absent original file is a coverage gap, not a successful result. Likewise, compilation and startup checks establish different properties from a differential test. Reporting skipped checks and configuration switches alongside successes would make heterogeneous case reports easier to compare without pretending that their denominators are interchangeable.

2. Reconstruction targets and evidence

Reverse engineering begins with an information gap, but the artifact used to bridge that gap varies considerably. A screenshot can support a layout, execution traces can constrain behavior, and implementation access can expose types or dependencies. The reconstructed object may therefore be a page, a transition model, annotated pseudocode, or an environment that runs existing firmware. These objects answer different questions. The same term can therefore cover inversion of visual design, inference of hidden rules, or construction of an executable surrogate around retained code. Input access and the required output must be specified together. [7] [5] [10] [3]

A recurring difficulty is underdetermination: different implementations can explain the same observations. Visual resemblance does not identify business logic; passing sampled executions does not recover original source; and a useful emulator may intentionally simplify hardware. Three distinctions organize the discussion: observed evidence versus supplied specifications, reconstruction versus reuse of existing components, and a measured outcome versus the broader claim it is intended to support. The relevant question is which properties the evidence constrains, and which remain untested. [11] [1] [12]

  1. Available evidenceImages, observations, traces, binaries or source; record access and supplied context.
  2. Reconstruction targetSpecify the layout, code, behavior model or execution environment to produce.
  3. Acceptance oracleIdentify the reference, comparison rule, tested inputs and permitted approximations.
  4. Supported claimReport what matched, what was reused, and which properties remain untested.
Read these four stages as a reporting framework, not a universal reconstruction algorithm. The available evidence constrains the target that can be inferred; the acceptance oracle determines which properties of that target were actually checked.

3. Websites: from appearance to observable workflows

Screenshot-to-code research treats rendered appearance as the main reference. Design2Code combines visual-element and layout measures with human assessment, while Web2Code separates screenshot understanding from HTML generation. DCGen decomposes screenshots into regions; ScreenCoder separates visual grounding, layout planning and code generation. However, a generated button can look correct without implementing any action. Placeholder media and self-contained page snapshots also alter the reconstruction problem, so visual scores should be read with the supplied assets and reference construction in view. [7] [13] [14] [15]

Interactive benchmarks supply or infer additional evidence. Interaction2Code provides before-and-after states for individual transitions; IWR-Bench uses interaction videos and annotated replay sequences. These test observed changes beyond a static screenshot, but IWR-Bench explicitly allows implied backend behavior to be mocked with static JavaScript data. UI2App instead asks models to infer plausible interactions from screenshots and accepts multiple valid implementations under a rubric. These are distinct tasks: reproducing demonstrated transitions and inventing behavior consistent with a design. Neither alone identifies the original server implementation, and cross-route state should not be equated with persistence across sessions. [16] [17] [11]

ProgramDistill shifts emphasis toward behavior: evaluated agents inspect live references through structured browser observations, and submitted code is checked through dependent workflows in a fresh verification environment. Vision2Web also tests workflows, but its full-stack tier supplies written requirements alongside visual prototypes. Dashboard2Code adds active exploration within a particular dashboard framework. Access to text, selectors, DOM information or explicit requirements changes what must be inferred. Comparisons must therefore separate observation access from reconstruction skill. Workflow replay can expose a failed saved edit or an incorrect sequence of actions, while still leaving untested database invariants and visual fidelity outside its guarantees. [2] [18] [19]

4. Games: interfaces, rules and executable world models

Game reconstruction spans several layers that should remain separate. SPRITE converts interface mockups into editable Unity UI assets, addressing hierarchy, visual grounding and basic interaction. GameReplica asks agents to explore rule-driven web games and create runnable HTML replicas. The former reconstructs a presentation layer; the latter attempts to infer rules through interaction. GameReplica uses model judges for its rule, implementation and visual scores. Neither task establishes reconstruction of a commercial native game, its original assets or its complete engine. A plausible interface, a playable implementation and a faithful ruleset are independent achievements, even when a benchmark reports them together. [20] [21]

Executable world models offer another objective: recover enough transition and reward behavior to support planning. WorldCoder refines Python models against experiences and planning constraints, assuming deterministic symbolic environments. Code World Models combines descriptions and recorded trajectories with program synthesis guided by search. Tycho builds and checks programmatic models from unfamiliar game interactions, but can repair, abstain from or bypass a model during play. These designs make reconstruction instrumental to task solving. Consequently, successful play cannot alone show that the learned simulator is correct: an agent may exploit a locally useful approximation or succeed through another part of its control loop. [5] [22] [23]

RevengeBench narrows the unknown object further to executable decision policies, evaluated through held-out action agreement and competitive value. This distinguishes recovering an opponent's policy from rebuilding the environment in which it acts. Across these studies, exploration policy, access to symbolic state or textual rules, and the distribution of tested states determine the difficulty. A promising research direction is to evaluate models on interventions beyond their construction traces, while reporting model fidelity separately from task reward. Deterministic toy worlds and fixed policies provide useful controlled experiments, but do not establish performance on stochastic, partially observed or adaptive game systems. [24] [5] [22]

5. Apps: recovering structure without assuming application logic

Mobile GUI research illustrates how the choice of representation shapes the result. REMAUI uses vision, OCR and layout heuristics to generate Android interfaces. UI2code learns a component hierarchy and skeleton, while ReDraw combines component recognition with a plausible hierarchy drawn from interface examples. Pix2code instead predicts a domain-specific language compiled into platform UI code. These approaches make different trade-offs between visual detail, hierarchy and platform specificity. Their outputs can accelerate implementation, but component or token accuracy is not a measure of recovered application logic. Multiple hierarchies may render similar screens while behaving differently under resizing or interaction. [25] [26] [4] [27]

Moving beyond a single screen introduces navigation as a separate inference problem. DeclarUI combines component extraction and generated declarative code with page-transition graphs that people review and correct. This makes the human contribution part of the method, rather than evidence that transitions were recovered autonomously. UIOrchestra organizes layout description, generation and visual comparison into cooperating agents, but its studied output is static React/CSS. Its mobile-derived reference pairs are human-refined reconstructions, not original app source. The distinction matters when comparing against earlier native Android outputs or claiming that a generated page constitutes an executable native application. [6] [28]

The open problem is how to connect interface recovery to independently specified behavior without silently filling gaps. A screenshot cannot determine authentication rules, synchronization, permissions or off-screen state. Navigation graphs constrain some transitions, yet leave business semantics unresolved. Future comparisons should identify which elements came from images, which were supplied by people, and which were invented by the generator; they should also separate compilation, visual matching and runtime behavior. Artifact availability is an additional dimension: a described method or promised release can support a literature discussion without establishing that its complete implementation has been inspected or reproduced. [6] [28] [4]

6. Binaries: symbols, source hypotheses and behavior

Binary research separates assistance to an analyst from generation of replacement source. DIRE predicts variable names from lexical and structural decompiler information; DIRTY adds learned types and layout cues. ReSym introduces cross-function reasoning to reduce conflicts in symbol and data-structure predictions. These methods recover useful abstractions, but names and types remain hypotheses conditioned on a decompiler and training distribution. Agreement between predictions is weaker than evidence that they match unavailable source. The distinction is consequential: improved readability can help analysis even when it neither changes executable behavior nor yields a compilable replacement. [10] [29] [30]

Assembly-to-C systems make a stronger output commitment. LLM4Decompile studies both generation from assembly and refinement of Ghidra pseudocode, while SLaDe combines neural translation with type completion. Their execution-based evaluations improve on text similarity alone, but the experimental context is essential. SLaDe selects a candidate using finite I/O tests and evaluates functions within their original calling context. Function boundaries, external declarations, compiler settings and candidate selection therefore contribute to the measured result. A test-passing function should not be interpreted as a recovered whole program, and recompilation alone is insufficient evidence of semantic preservation. [31] [1]

DeGPT illustrates the different risks of rewriting existing decompiler output: simplification and naming may aid comprehension, while heuristic semantic checks can miss harmful changes. DecompileBench broadens evaluation to functions from real programs and combines behavioral checks with understandability assessment, but finite fuzzing coverage and model-assisted judgments remain bounded oracles. The useful comparison is thus multidimensional: symbol plausibility, structural readability, compilation, tested behavior and preserved dependencies. Research that reports these separately is easier to interpret than a single decompilation score. Testing beyond the examples used to select or repair an output is especially important for detecting plausible-looking mistakes. [32] [33] [1]

7. Firmware: rebuilding an environment around retained binaries

Firmware rehosting usually retains the target binary and reconstructs the environment it expects. HALucinator identifies hardware-abstraction interfaces and substitutes authored handlers, allowing model fidelity to vary with the analysis objective. Fuzzware operates closer to memory-mapped I/O, using scoped symbolic analysis to identify inputs relevant to firmware logic. Both reduce the burden of complete peripheral emulation through abstraction. That reduction is productive for testing, but it also defines a boundary: omitted hardware behavior, timing or direct memory access (DMA) can change reachable executions, and a crash in the analysis environment may not be physically realizable. [3] [34]

Linux firmware brings another set of dependencies, including files, initialization processes, networking and kernel services. FirmAE uses empirical interventions to overcome execution failures and bring up selected web services. FIRMWELL reconstructs service dependencies through initialization and analysis, while Penguin makes target-specific transformations explicit and editable. These are related attempts to make retained software analyzable, but their success conditions differ. Binding a web port, returning a nonempty response and passing configured service checks establish different observations, not interchangeable definitions of a functioning device. The amount of execution behavior deliberately changed must remain part of the interpretation. [12] [35] [36]

The central research tension is between reachability and fidelity. A permissive model can expose more code while also admitting impossible inputs; a detailed model may demand substantial manual knowledge and still miss a peripheral condition. Useful evaluations should connect accepted service behavior and discovered faults to documented assumptions, then distinguish emulator-only observations from checks on physical devices. This also makes negative results informative: unsupported architectures, incomplete unpacking, missing initialization or failed peripheral models are different failure categories. None of these rehosting achievements alone implies original-source recovery or reconstruction of every device function. [34] [3] [35]

8. Protocols: syntax, semantics and state are different targets

Passive protocol inference learns from messages without observing the implementation. NEMESYS estimates boundaries within individual messages; NetPlier uses relationships across traces to infer type-related fields and clusters; BinaryInferno combines specialized detectors into partial format descriptions. Their assumptions about plaintext, alignment, sample diversity and prior grouping differ. Even the unit of correctness changes: a boundary match, an exactly segmented field and a correctly clustered message answer different questions. Analyst priors and ground-truth preprocessing must be counted as inputs. Partial format recovery can be valuable without identifying all semantics or discovering messages absent from the sample. [37] [38] [39]

Implementation access supplies stronger constraints at a different cost. BinPRE observes instrumented server execution to infer fields and selected semantic categories; ICEPRE follows concrete parser paths and symbolically replays them for syntax inference. NetLifter instead requires annotated C/LLVM input and statically derives grammars with cross-field constraints. These methods cannot be ranked fairly as if they received the same evidence. They also inherit different blind spots: unexercised paths, manual function identification, implementation-ignored fields, and approximation of loops or checksums. Improved fuzzing is evidence of a useful downstream application, not proof that a complete interoperable endpoint has been reconstructed. [40] [41] [42]

State-machine learning asks which sequences of messages lead to distinguishable responses. StateInspector combines active queries with runtime memory evidence, whereas BLE automata learning interacts with physical devices through a predefined set of abstract protocol actions. Both illustrate that state coverage depends on what the harness can send, how outputs are abstracted, and how reset, timing and nondeterminism are handled. These methods do not automatically recover unknown message syntax. Conversely, format inference does not supply an entire state machine. Bringing the two together remains a research problem: a format-valid message can be inappropriate in a particular state, while an omitted input can hide a whole branch of behavior. [43] [44] [38]

9. Agent benchmarks: tasks and access conditions

Agent benchmarks make the allowed investigation process part of the task. CrackMeBench asks for executable-checked solutions to compact binary challenges under a shell interface and a time budget. CREBench separates cryptographic recognition, extraction, wrapper reconstruction and flag recovery. An accepted input, a recovered parameter and a replacement wrapper are different deliverables. Success on these controlled tasks is evidence about those deliverables, rather than recovery of an entire application or arbitrary protected binary. [45] [46]

SRE-Bench uses privately authored programs and protected variants to address contamination, with access through an evaluation service rather than a public task release. Its contamination controls remain an attributed methodology. Humans vs. Machines studies static understanding and navigation without dynamic execution; its larger binary-representation study measures context capacity, not challenge-solving accuracy. Prior source exposure and interface restrictions therefore matter when interpreting human–agent comparisons, independently of the model name. [47] [48]

ProgramBench takes another route: agents query a reference executable and consult documentation, while binary inspection, decompilation and internet access are forbidden during inference. Generated tests evaluate the replacement program over finite inputs. Comparisons across agent studies should record tool permissions, query and resource budgets, test visibility and prior exposure, then align the required submission. Rebuilding behavior from black-box queries is not the same task as identifying a secret, explaining static code or recovering source through disassembly. [49]

10. Representative studies and their evaluation boundaries

The table compares study designs, not scores. Each row identifies what the method receives, what it produces, how the output is assessed and one boundary needed to interpret the assessment. Observation access, original context and human assistance belong in the comparison alongside the algorithm. The selected studies span the six domains and illustrate several method families; they are not a representative sample for estimating field-wide success.

Representative research designs. Inputs and acceptance criteria differ; the rows are not a performance ranking.
StudyInputOutputEvaluationBoundary
Design2Code [7]Webpage screenshotsFrontend codeVisual metrics and human assessmentStatic appearance; backend excluded
Interaction2Code [16]Before/after interaction screenshotsInteractive webpagesAppearance, interaction checks, usabilityIndividual transitions, not complete workflows
ProgramDistill [2]Live reference; structured browser observationsRestored features or reconstructed appsFresh-environment workflow replayFinite behavior coverage; no visual score
SPRITE [20]Game UI screenshotsEditable Unity UI assetsUI benchmark and designer reviewBasic interaction, not gameplay recovery
GameReplica [21]Screenshots and active interactionRunnable HTML game replicasModel-judged rules, implementation, visualsWeb puzzles; no full-engine equivalence
WorldCoder [5]Symbolic observations and goalsPython transition/reward modelsTransition consistency and planningDeterministic symbolic environments
ReDraw [4]Screenshots or mockupsAndroid GUI prototypesAppearance and view hierarchySingle screen; no app logic
DeclarUI [6]Multi-page designs/screenshotsDeclarative mobile UI codeVisual, compilation and transition checksHuman-corrected navigation; backend excluded
UIOrchestra [28]Static mobile UI designsReact/CSS pagesImage/component/code similarityReconstructed references; no native runtime test
DIRE [10]Decompiler outputVariable-name predictionsNaming accuracy on compiled C corpusNaming assistance, not source equivalence
SLaDe [1]Function assemblyC functions with completed typesFinite I/O tests and edit similarityTest-selected candidates; original context
DecompileBench [33]Functions from real programsEvaluated decompiler outputsRuntime checks and model-assisted assessmentFinite fuzzing coverage and judge dependence
HALucinator [3]Firmware plus HAL/library knowledgeRehosted firmware environmentSelected I/O and fuzzing demonstrationsSimplified peripherals; manual models
FIRMWELL [35]Linux firmware services and initializationRecovered service environmentConfigured service-acceptance checksService success is not device equivalence
BinaryInferno [39]Static binary-message samplesPartial field formatsField-boundary precision/recallPlaintext, alignment and grouping assumptions
BinPRE [40]Instrumented binary and messagesFields and selected semanticsField perfection and semantic F1Executed paths; limited detector vocabulary
NetLifter [42]Annotated C/LLVM parserGrammar and field constraintsManual field comparison and fuzzingSource required; checksum approximations
StateInspector [43]Active queries and runtime memoryInput/output state-machine hypotheses (Mealy models)Learned transitions and bounded checksKnown inputs; assumptions about where state is stored

11. Project cases: what the checks establish

Perfect Dark and Super Mario 64 offer comparatively precise output checks: version-specific ROM digests. Yet comparison depends on the build mode. Perfect Dark separates matching IDO builds from nonmatching GCC builds; sm64 disables comparison for some configurations, including iQue in the reviewed CI. A successful build therefore cannot substitute for an enabled, passing comparison. Both require original assets, and Perfect Dark also reuses extracted boot code. Matching does not establish that every output byte was newly reconstructed. [9] [50]

Pocket Tasks instead checks named editing, persistence and replay behaviors. Its overlapping checker and replay sessions cannot be added as independent observations, and disclosed prior source access precludes a blind-reconstruction interpretation. Open Scrantic tests selected engine properties but can skip data-dependent checks; its headless completion test is not original-frame comparison. Deliberate differences may be useful engineering choices, provided they are reported rather than counted as exact recovery. [51] [52]

The rauchg.com case infers a Next.js project from browser-delivered React Server Component (Flight) data. Its reported comparison across 18 routes checks normalized component trees and module references, excluding CSS. A pass does not verify rendered pixels, database writes or unobserved routes. BaoCut Slides supplies an interactive editor and local storage, but its tests do not compare it against the original Claude Slides. Some BaoCut tests use simulated dependencies or skip when the slide compiler has not been built. [53] [54]

These cases separate interface structure, visual appearance, interaction and persistent state. None entails recovery of hidden server source. Behavior-oriented research can add dependent workflow replay, as in ProgramDistill, while still leaving untested database invariants and visual fidelity unresolved. The evaluation should name which layer it observes. [2]

NJFE’s camera-to-desktop bridge sends JPEG frames over custom USB serial transport; it does not provide a standard USB webcam (UVC) interface or recover the original camera application. It reuses the earlier otoscope protocol implementation, while the author credits Claude Code with implementation assistance. TCLimate checks selected cloud-reported states after commands; confirmation does not independently demonstrate compressor or airflow behavior. Reported coverage is limited to the documented region and devices, and does not establish support for other regions or models. [8] [55]

Checks are documented or author-reported; this survey did not execute them. Full entry links retain prerequisites, source pins and licensing limits.
CaseInputOutputCheckLimits
Perfect Dark [9]Original ROM; reconstructed CN64 ROM with extracted assetsPer-version MD5 manifestsMatching mode; reused boot code; not rerun
Super Mario 64 [50]Versioned original ROMRebuilt N64 ROMConditional SHA-1 comparisonComparison disabled for some CI/configuration paths
Pocket Tasks [51]Authored reference; prior source accessStandalone Node implementationExpected outputs and captured-session replayFinite, overlapping scenarios; not a blind trial
Open Scrantic [52]Original executable and resource filesRust screensaver engineUnit checks; scene-completion testData-dependent skips; no original-frame oracle
rauchg.com reconstruction [53]Captured Flight outputInferred Next projectNormalized route trees and module mappingCSS and hidden backend paths excluded
BaoCut Slides [54]Author-described Claude Slides adaptationEditor, host and local deck storeImplementation and reported Web-flow checksSubstitutes/skips; no original-service parity check
NJFE [8]Camera UDP; prior otoscope workUSB-serial bridge and desktop viewerAuthor-reported live frame decodingOne reported device; not UVC or original protocol discovery
TCLimate [55]Prior protocol work; cloud requestsSelected macOS AC controlsReported cloud-state confirmationRegion/model limits; physical effects not independently established

12. Reliability and attribution

An acceptance check defines the scope of a result. If candidates are selected using the same finite tests later reported as success, held-out checks are especially valuable: SLaDe, for example, selects the first I/O-passing beam candidate within the original calling context. That is stronger than compilation alone, but weaker than all-input equivalence. [1]

Attribution requires a separate record of what the human, model, prior project and reference system supplied. Open Scrantic explicitly names REA and Claude Code; BaoCut’s support for agent engines does not identify which model produced its adaptation. Reused assets, pre-existing protocol logic and prior source exposure must remain visible. Likewise, a code license does not transfer rights to original ROMs, fonts or hosted services. These dependencies affect reproducibility as well as interpretation. [52] [54]

These reports are also insufficient for causal claims about agent productivity. A reconstruction may combine human analysis, inherited implementations, generated code and target-specific fixes. Without comparable baselines and recorded interventions, success cannot be assigned to one model or tool. Future studies should separate discovery effort from implementation effort, report failed attempts and resource budgets, and distinguish assistance during reconstruction from agent functionality merely supported by the finished application.

13. Research questions

The literature and case comparisons suggest an agenda centered on evidence that can distinguish competing reconstructions. The following questions concern evaluation design and reporting, rather than promised improvements from a particular model.

  • Can versioned, held-out traces test unseen sequences, errors and restarts without exposing their expectations during reconstruction? Publish validator changes separately from candidate changes.
  • Can evaluations distinguish reused assets and code from newly inferred behavior, and report source exposure and human interventions alongside model identity and tool versions?
  • Can tests independently observe physical effects, durable state and visual output, instead of relying on one successful API response or structural comparison?
  • Can small redistributable fixtures expose skipped checks, unsupported versions and deliberate deviations, enabling replication without distributing proprietary assets or assuming access to mutable cloud services?
  • How much of a reconstruction survives a new target version, device variant or compiler setting? Report regressions separately from adaptation work, with the original acceptance conditions retained.

14. Limitations of this synthesis

This is a purposive editorial synthesis of a fixed collection, not a systematic review or a pooled performance analysis. The source records cover different publication stages, artifact revisions and degrees of access. Documentary inspection supports the distinctions discussed here but does not replace experiment reproduction. The selected cases expose methodological contrasts; their frequency in this survey says nothing about how common or successful those approaches are in practice.

15. Conclusion

Across the six domains, reconstruction is best understood through the relationship between evidence, intended output and acceptance oracle. The practical value of an approximation can be substantial even when its claim is narrow. Explicit input access, reuse, version boundaries and test coverage make that value easier to assess. A shared reporting framework can connect work on interfaces, code, behavior and environments while preserving the distinctions that give each result its meaning.

References

Corpus membership and reference records are frozen at the snapshot shown above. All 53 papers are retained in the bibliography, including entries not cited in the narrative; the eight selected cases are also included. Linked collection entries may be updated separately. Changes to this survey’s paper corpus, reference metadata or bibliographic dates require a new version and date.

Download the paper references · BibTeX ↓

  1. SLaDe: A Portable Small Language Model Decompiler for Optimized Assembly
    Jordi Armengol-Estapé; Jackson Woodruff; Chris Cummins; Michael F. P. O'Boyle. 2024. IEEE/ACM CGO 2024. Conference paper.
  2. ProgramDistill: From Interactive Web Apps to Verifiable Reference-Guided SWE Tasks
    Jeonghye Kim; Minseon Kim; Young Jin Kim; Matheus Pereira; Marc-Alexandre Côté; Alessandro Sordoni; Xingdi Yuan; Zhengyan Shi. 2026. arXiv. Preprint.
  3. HALucinator: Firmware Re-hosting Through Abstraction Layer Emulation
    Abraham A Clements; Eric Gustafson; Tobias Scharnowski; Paul Grosen; David Fritz; Christopher Kruegel; Giovanni Vigna; Saurabh Bagchi; Mathias Payer. 2020. USENIX Security 2020. Conference paper.
  4. Machine Learning-Based Prototyping of Graphical User Interfaces for Mobile Apps
    Kevin Moran; Carlos Bernal-Cárdenas; Michael Curcio; Richard Bonett; Denys Poshyvanyk. 2020. IEEE Transactions on Software Engineering. Journal article.
  5. WorldCoder, a Model-Based LLM Agent: Building World Models by Writing Code and Interacting with the Environment
    Hao Tang; Darren Key; Kevin Ellis. 2024. NeurIPS 2024. Conference paper.
  6. DeclarUI: Bridging Design and Development with Automated Declarative UI Code Generation
    Ting Zhou; Yanjie Zhao; Xinyi Hou; Xiaoyu Sun; Kai Chen; Haoyu Wang. 2025. Proceedings of the ACM on Software Engineering. Journal article.
  7. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering
    Chenglei Si; Yanzhe Zhang; Ryan Li; Zhengyuan Yang; Ruibo Liu; Diyi Yang. 2025. NAACL 2025. Conference paper.
  8. NJFE: a Soulear camera protocol bridge for desktop inspection
    Project documentation; sources reviewed 2026-10-17.
  9. Perfect Dark: matching Nintendo 64 decompilation
    Project documentation; sources reviewed 2026-10-18.
  10. DIRE: A Neural Approach to Decompiled Identifier Naming
    Jeremy Lacomis; Pengcheng Yin; Edward J. Schwartz; Miltiadis Allamanis; Claire Le Goues; Graham Neubig; Bogdan Vasilescu. 2019. ASE 2019. Conference paper.
  11. UI2App: Benchmarking Visual Interaction Inference in Executable Web Application Generation
    Grace Man Chen; Litao Guo; Yifan Wu; Yiyu Chen; Yenchi Tseng; Sicheng Liu; Yuyu Luo; Ying-Cong Chen. 2026. arXiv. Preprint.
  12. FirmAE: Towards Large-Scale Emulation of IoT Firmware for Dynamic Analysis
    Mingeun Kim; Dongkwan Kim; Eunsoo Kim; Suryeon Kim; Yeongjin Jang; Yongdae Kim. 2020. ACSAC 2020. Conference paper.
  13. Web2Code: A Large-scale Webpage-to-Code Dataset and Evaluation Framework for Multimodal LLMs
    Sukmin Yun; Haokun Lin; Rusiru Thushara; Mohammad Qazim Bhat; Yongxin Wang; Zutao Jiang; Mingkai Deng; Jinhong Wang; Tianhua Tao; Junbo Li; Haonan Li; Preslav Nakov; Timothy Baldwin; Zhengzhong Liu; Eric P. Xing; Xiaodan Liang; Zhiqiang Shen. 2024. NeurIPS 2024 Datasets and Benchmarks. Conference paper.
  14. Divide-and-Conquer: Generating UI Code from Screenshots
    Yuxuan Wan; Chaozheng Wang; Yi Dong; Wenxuan Wang; Shuqing Li; Yintong Huo; Michael Lyu. 2025. Proceedings of the ACM on Software Engineering. Journal article.
  15. ScreenCoder: Advancing Visual-to-Code Generation for Front-End Automation via Modular Multimodal Agents
    Yilei Jiang; Yaozhi Zheng; Yuxuan Wan; Jiaming Han; Qunzhong Wang; Michael R. Lyu; Xiangyu Yue. 2026. EMNLP 2026. Conference accepted.
  16. Interaction2Code: Benchmarking MLLM-based Interactive Webpage Code Generation from Interactive Prototyping
    Jingyu Xiao; Yuxuan Wan; Yintong Huo; Zixin Wang; Xinyi Xu; Wenxuan Wang; Zhiyao Xu; Yuhang Wang; Michael R. Lyu. 2025. ASE 2025. Conference paper.
  17. IWR-Bench: Can LVLMs reconstruct interactive webpage from a user interaction video?
    Yang Chen; Minghao Liu; Yufan Shen; Yunwen Li; Tianyuan Huang; Xinyu Fang; Tianyu Zheng; Wenxuan Huang; Cheng Yang; Daocheng Fu; Jianbiao Mei; Rong Wu; Licheng Wen; Xuemeng Yang; Song Mao; Qunshu Lin; Zhi Yu; Yongliang Shen; Yu Qiao; Botian Shi. 2026. ICLR 2026. Conference paper.
  18. Vision2Web: A Hierarchical Benchmark for Visual Website Development with Agent Verification
    Zehai He; Wenyi Hong; Zhen Yang; Ziyang Pan; Mingdao Liu; Xiaotao Gu; Jie Tang. 2026. ICML 2026. Conference paper.
  19. Dashboard2Code: Evaluating Multimodal Models on Reconstructing Interactive Dashboards
    Tianhao Niu; Ziyu Han; Qiguang Chen; Shiqi Zhou; Baocai Shan; Hengjie Fang; Qingfu Zhu; Wanxiang Che. 2026. ACL 2026. Conference paper.
  20. SPRITE: From Static Mockups to Engine-Ready Game UI
    Yunshu Bai; RuiHao Li; Hao Zhang; Chien Her Lim; Ming Yan; Mengtian Li. 2026. CHI EA 2026 (poster/extended abstract). Conference paper.
  21. GameReplica: A Benchmark for Black-Box Visual Game Replication by Vision-Language Agents
    Boyu Qiao; Zixin Tang; Xiaoshuai Hao; Wenbo Li. 2026. arXiv. Preprint.
  22. Generating Code World Models with Large Language Models Guided by Monte Carlo Tree Search
    Nicola Dainese; Matteo Merler; Minttu Alakuijala; Pekka Marttinen. 2024. NeurIPS 2024. Conference paper.
  23. Tycho: Active Abstraction with Programmatic World Models for ARC-AGI-3
    Jens Lehmann; Andrei Aioanei; Sahar Vahdati. 2026. arXiv. Preprint.
  24. RevengeBench: Reverse Engineering Code-Space Policies from Behavioral Experiments
    Babak Rahmani; Sebastian Dziadzio; Joschka Strüber; Sergio Hernández-Gutiérrez; Matthias Bethge. 2026. arXiv. Preprint.
  25. Reverse Engineering Mobile Application User Interfaces with REMAUI (T)
    Tuan Anh Nguyen; Christoph Csallner. 2015. ASE 2015. Conference paper.
  26. From UI Design Image to GUI Skeleton: A Neural Machine Translator to Bootstrap Mobile GUI Implementation
    Chunyang Chen; Ting Su; Guozhu Meng; Zhenchang Xing; Yang Liu. 2018. ICSE 2018. Conference paper.
  27. pix2code: Generating Code from a Graphical User Interface Screenshot
    Tony Beltramelli. 2018. EICS 2018. Conference paper.
  28. UIOrchestra: Generating High-Fidelity Code from UI Designs with a Multi-agent System
    Chuhuai Yue; Jiajun Chai; Yufei Zhang; Zixiang Ding; Xihao Liang; Peixin Wang; Shihai Chen; Wang Yixuan; Yanping Wang; Guojun Yin; Wei Lin. 2025. Findings of EMNLP 2025. Conference paper.
  29. Augmenting Decompiler Output with Learned Variable Names and Types
    Qibin Chen; Jeremy Lacomis; Edward J. Schwartz; Claire Le Goues; Graham Neubig; Bogdan Vasilescu. 2022. USENIX Security 2022. Conference paper.
  30. ReSym: Harnessing LLMs to Recover Variable and Data Structure Symbols from Stripped Binaries
    Danning Xie; Zhuo Zhang; Nan Jiang; Xiangzhe Xu; Lin Tan; Xiangyu Zhang. 2024. ACM CCS 2024. Conference paper.
  31. LLM4Decompile: Decompiling Binary Code with Large Language Models
    Hanzhuo Tan; Qi Luo; Jing Li; Yuqun Zhang. 2024. EMNLP 2024. Conference paper.
  32. DeGPT: Optimizing Decompiler Output with LLM
    Peiwei Hu; Ruigang Liang; Kai Chen. 2024. NDSS 2024. Conference paper.
  33. DecompileBench: A Comprehensive Benchmark for Evaluating Decompilers in Real-World Scenarios
    Zeyu Gao; Yuxin Cui; Hao Wang; Siliang Qin; Yuanda Wang; Zhang Bolun; Chao Zhang. 2025. Findings of ACL 2025. Conference paper.
  34. Fuzzware: Using Precise MMIO Modeling for Effective Firmware Fuzzing
    Tobias Scharnowski; Nils Bars; Moritz Schloegel; Eric Gustafson; Marius Muench; Giovanni Vigna; Christopher Kruegel; Thorsten Holz; Ali Abbasi. 2022. USENIX Security 2022. Conference paper.
  35. User-Space Dependency-Aware Rehosting for Linux-Based Firmware Binaries
    Chuan Qin; Cen Zhang; Yaowen Zheng; Puzhuo Liu; Jian Zhang; Yeting Li; Weidong Zhang; Yang Liu; Limin Sun. 2026. NDSS 2026. Conference paper.
  36. Target-Centric Firmware Rehosting with Penguin
    Andrew Fasano; Zachary Estrada; Luke Craig; Ben Levy; Jordan McLeod; Jacques Becker; Caden Kline; Elysia Witham; Cole DiLorenzo; Ali Bobi; Dinko Dermendzhiev; Tim Leek; Wil Robertson. 2025. Workshop on Binary Analysis Research (BAR) 2025. Conference paper.
  37. NEMESYS: Network Message Syntax Reverse Engineering by Analysis of the Intrinsic Structure of Individual Messages
    Stephan Kleber; Henning Kopp; Frank Kargl. 2018. 12th USENIX Workshop on Offensive Technologies (WOOT 18). Conference paper.
  38. NetPlier: Probabilistic Network Protocol Reverse Engineering from Message Traces
    Yapeng Ye; Zhuo Zhang; Fei Wang; Xiangyu Zhang; Dongyan Xu. 2021. NDSS 2021. Conference paper.
  39. BinaryInferno: A Semantic-Driven Approach to Field Inference for Binary Message Formats
    Jared Chandler; Adam Wick; Kathleen Fisher. 2023. NDSS 2023. Conference paper.
  40. BinPRE: Enhancing Field Inference in Binary Analysis Based Protocol Reverse Engineering
    Jiayi Jiang; Xiyuan Zhang; Chengcheng Wan; Haoyi Chen; Haiying Sun; Ting Su. 2024. ACM CCS 2024. Conference paper.
  41. ICEPRE: ICS Protocol Reverse Engineering via Data-Driven Concolic Execution
    Yibo Qu; Dongliang Fang; Zhen Wang; Jiaxing Cheng; Shuaizong Si; Yongle Chen; Limin Sun. 2025. Proceedings of the ACM on Software Engineering (ISSTA 2025). Journal article.
  42. Lifting Network Protocol Implementation to Precise Format Specification with Security Applications
    Qingkai Shi; Junyang Shao; Yapeng Ye; Mingwei Zheng; Xiangyu Zhang. 2023. ACM CCS 2023. Conference paper.
  43. The Closer You Look, The More You Learn: A Grey-box Approach to Protocol State Machine Learning
    Chris McMahon Stone; Sam L. Thomas; Mathy Vanhoef; James Henderson; Nicolas Bailluet; Tom Chothia. 2022. ACM CCS 2022. Conference paper.
  44. Fingerprinting and analysis of Bluetooth devices with automata learning
    Andrea Pferscher; Bernhard K. Aichernig. 2022. Formal Methods in System Design. Journal article.
  45. CrackMeBench: Binary Reverse Engineering for Agents
    Isaac David; Arthur Gervais. 2026. arXiv. Preprint.
  46. CREBench: Evaluating Large Language Models in Cryptographic Binary Reverse Engineering
    Baicheng Chen; Yu Wang; Ziheng Zhou; Xiangru Liu; Juanru Li; Yilei Chen; Tianxing He. 2026. COLM 2026. Conference paper.
  47. The Next Challenge for Agentic Cybersecurity: A Realistic, Contamination-Free Reverse Engineering Benchmark
    Jeremy Spence; Nicholas Assaderaghi; Feng Xiao; Jinhao Zhu; Nikil Ravi; Xiangyu Qi; Matthew Jagielski; Raluca Ada Popa; Eric Wallace; Guannan Wei; Yangruibo Ding; Zhuo Zhang. 2026. arXiv. Preprint.
  48. Humans vs. Machines: A Comparison With AI Agents in Software Reverse Engineering
    Samuele Doria; Stefano De Rosa; Ruoyu Wang; Zion Leonahenahe Basque; Eleonora Losiouk; Simone Aonzo. 2026. arXiv. Preprint.
  49. ProgramBench: Can Language Models Rebuild Programs From Scratch?
    John Yang; Kilian Lieret; Jeffrey Ma; Parth Thakkar; Dmitrii Pedchenko; Sten Sootla; Emily McMilin; Pengcheng Yin; Rui Hou; Gabriel Synnaeve; Diyi Yang; Ofir Press. 2026. NeurIPS 2026. Conference accepted.
  50. Super Mario 64: ROM reconstruction with explicit comparison gates
    Project documentation; sources reviewed 2026-10-17.
  51. Pocket Tasks: reconstructing task state and persistence
    Project documentation; sources reviewed 2026-10-17.
  52. Open Scrantic: reconstructing the Johnny Castaway screensaver engine
    Project documentation; sources reviewed 2026-10-18.
  53. rauchg.com: rebuilding an RSC blog from captured Flight output
    Project documentation; sources reviewed 2026-10-17.
  54. BaoCut Slides: adapting an interactive web editor
    Project documentation; sources reviewed 2026-10-17.
  55. TCLimate: reconstructing selected TCL Home cloud controls
    Project documentation; sources reviewed 2026-10-18.
  56. WebUIBench: A Comprehensive Benchmark for Evaluating Multimodal Large Language Models in WebUI-to-Code
    Zhiyu Lin; Zhengda Zhou; Zhiyuan Zhao; Tianrui Wan; Yilun Ma; Junyu Gao; Xuelong Li. 2025. Findings of ACL 2025. Conference paper.
  57. Decompile-Bench: Million-Scale Binary-Source Function Pairs for Real-World Binary Decompilation
    Hanzhuo Tan; Xiaolong Tian; Hanrui Qi; Jiaming Liu; Zuchen Gao; Siyi Wang; Qi Luo; Jing Li; Yuqun Zhang. 2025. NeurIPS 2025 Datasets and Benchmarks. Conference paper.
  58. JsDeObsBench: Measuring and Benchmarking LLMs for JavaScript Deobfuscation
    Guoqiang Chen; Xin Jin; Zhiqiang Lin. 2025. ACM CCS 2025. Conference paper.
  59. CASCADE: LLM-powered JavaScript Deobfuscator at Google
    Shan Jiang; Pranoy Kovuri; David Tao; Zhixun Tan. 2026. ICSE-SEIP 2026. Conference paper.
  60. SK2Decompile: LLM-based Two-Phase Binary Decompilation from Skeleton to Skin
    Hanzhuo Tan; Weihao Li; Xiaolong Tian; Siyi Wang; Jiaming Liu; Jing Li; Yuqun Zhang. 2026. ICLR 2026. Conference paper.
  61. Automatic Wireless Protocol Reverse Engineering
    Johannes Pohl; Andreas Noack. 2019. 13th USENIX Workshop on Offensive Technologies (WOOT 19). Conference paper.

Cite this survey

An online editorial survey, prepared with AI assistance. It has not undergone peer review and reports no new experiments. Use your browser’s Print command to save a PDF.

@misc{awesome-rea-survey-2026,
  author = {{Awesome REA contributors}},
  title = {{Reverse Engineering Anything: An Evidence-Centered Survey}},
  year = {2026},
  version = {1.0},
  url = {https://awesomerea.org/survey/},
  note = {Online editorial survey; corpus snapshot 2026-10-18; no new experiments}
}

Catalog snapshot used in this survey · Suggest a correction