arXiv CS open access

LOHRE: Execution-Grounded Type Recovery via LLM-Orchestrated Hybrid Analysis

Hao Jiang et al. · arxiv_cs

arXiv CS · Papers

software-architecture software-engineering testing

Documenting stripped binary functions for security analysis requires recovering function interfaces and user-defined type (UDT) layouts from machine code. Existing large language model (LLM)-based methods face two limitations: they lack execution-based validation to detect inferred UDTs inconsistent

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

LOHRE: Execution-Grounded Type Recovery via LLM-Orchestrated Hybrid Analysis

arXiv:2611.14946v1 [cs.SE] 11 Nov 2026

Hao Jiang, Yujie Yang, Tao Li, Chenhui Cui, Liangfeng Xu, Chengjie Liu, Weiping Wen, Rubing Huang, Senior Member, IEEE, and Tsong Yueh Chen, IEEE Fellow, IEEE

Abstract—Documenting stripped binary functions for security analysis requires recovering function interfaces and userdefined type (UDT) layouts from machine code. Existing large language model (LLM)-based methods face two limitations: they lack execution-based validation to detect inferred UDTs inconsistent with actual memory layouts, and may overlook evidence about shared UDTs across functions without direct call relationships. We present LLM-Orchestrated Hybrid Reverse Engineering (LOHRE), a framework that treats inferred UDTs as falsifiable hypotheses and tests them against program execution. LOHRE uses a hypothesize-validate-refine loop to test candidate layouts through paired dynamic slice emulation of baseline and mutated inputs. To reduce the cost of processing lengthy execution histories, the Execution-Depth Heuristic (EDH) compresses paired traces into an execution-depth difference and a summary of the tested field’s observed uses. A cross-function knowledge base aggregates compatible UDT hypotheses and fieldlevel confidence scores to guide testing and hypothesis refinement. We evaluate LOHRE on RealType at four optimization levels and a Windows remote procedure call (RPC) dataset. LOHRE achieves an average UDT Structural accuracy of 57.85% across RealType’s four optimization levels and 35.6% on Windows RPC, outperforming the evaluated static baselines. Disabling dynamic validation reduces accuracy to 19.28% on RealType and 9.2% on Windows RPC. Removing the cross-function knowledge base reduces accuracy to 41.03% on RealType and 10.0% on Windows RPC. Replacing EDH’s compressed feedback with full execution traces reduces recovery accuracy while increasing token use by 3.7 times and runtime by 3.0 times. These results indicate that execution-based validation, compact feedback, and cross-function evidence contribute to accurate and efficient UDT recovery. Supplementary materials are available at https://anonymous. 4open.science/r/LOHRE-230C. Index Terms—binary reverse engineering; user-defined type recovery; large language models; hybrid static-dynamic analysis

I. I NTRODUCTION ECURITY analysis of closed-source software requires recovering high-level information from stripped machine code [1]. A central part of this task is documenting stripped

Hao Jiang, Yujie Yang, Liangfeng Xu, Chengjie Liu and Weiping Wen are with Peking University, Beijing 100871, China (e-mail: haojiang@stu.pku.edu.cn; 2501210755@stu.pku.edu.cn; xuliangfeng26@stu.pku.edu.cn; cheng@stu.pku.edu.cn; weipingwen@pku.edu.cn). Tao Li is with Beihang University, Beijing 100191, China (e-mail: abelli@buaa.edu.cn). Chenhui Cui and Rubing Huang are with Macau University of Science and Technology, Macao SAR 999078, China (e-mail: 3230002105@student.must.edu.mo; rbhuang@must.edu.mo). Tsong Yueh Chen is with Swinburne University of Technology, Melbourne 3122, Australia (e-mail: tychen@swin.edu.au). Tao Li and Weiping Wen are the corresponding authors.

binary functions by recovering their interfaces and userdefined type (UDT) layouts. UDTs, such as structs and unions, describe how fields and nested structures are organized in memory. Without precise UDTs, downstream security tasks such as structure-aware fuzzing have difficulty in constructing valid structured inputs and reaching deeper program states [2]. However, conventional decompilers such as Ghidra and HexRays expose memory accesses through pointer offsets, often leaving analysts to reconstruct the underlying structures by hand. Recent large language model (LLM)-based methods [3–5] automate parts of this task, but two limitations remain central to our setting. First, without execution-based validation, an inferred UDT layout may appear plausible even when it is inconsistent with the program’s memory accesses. Figure 1 illustrates this hallucination risk: Idioms [3] mistakes a hash table for a tree. Second, evidence about a shared UDT may be distributed across functions without direct call relationships, each exposing only part of the layout. Methods that primarily aggregate evidence along call relationships may therefore overlook some of this UDT information [3]. This problem is especially visible in Windows remote procedure call (RPC) services and may also arise when an object’s lifetime spans multiple functions, as in object-oriented systems, plugins, and middleware. We propose LLM-Orchestrated Hybrid Reverse Engineering (LOHRE), a training-free framework for execution-grounded type recovery. LOHRE treats LLMinferred UDT layouts as falsifiable hypotheses and tests candidate layouts through paired dynamic slice emulation. For each test, it executes the target function with a baseline input constructed from the current layout and a mutated input that substitutes an alternative type of equal byte width for a single field. Comparing the two runs helps determine which type better matches the field’s actual usage in the program. However, program execution histories are often long and complex, which can degrade LLM reasoning and increase token costs [6–10]. To address this problem, we propose the Execution-Depth Heuristic (EDH), which compresses paired execution traces into a depth difference and a summary of the selected field’s observed uses. The depth difference provides a heuristic signal about execution progress, as inputs constructed from incompatible layouts may fail early checks. The LLM interprets this signal together with the field’s observed uses and relevant code to refine the hypothesis. To combine scattered evidence, LOHRE maintains a cross-function knowledge base (KB) that aggregates UDT hypotheses with

int hash_find_index(struct hash* h, void* item) { void* cnx; int cnt = 0; int index = h->hash_make_key(item, h->hash_size); cnx = gap_get(h->data, index); while (cnx != NULL) { if (cnt++ > h->hash_size) return -1; if (h->cmp_item(cnx, item) == 0) break; index = hash_next_index(h, index); cnx = gap_get(h->data,index); } if (cnx == NULL) return -1; return index; }

2 3 4 5 6 7 8 9 10 11 12 13

1 2 3 4 5 6 7 8 9 10 11 12 13

(b) Decompiled by Idioms

(a) Source Code 1

__int64 __fastcall test_3(unsigned int *a1, __int64 a2) { unsigned int v4; __int64 v5; __int64 v6; signed int v7; signed int v8; unsigned int v9; __int64 v10; __int64 v11; v4 = (*((__int64 (__fastcall **)(__int64,_QWORD))a1+2))( a2,*a1); v7 = 0; while ( 1 ) { v9 = v4; v10 = sub_180001040(*((_QWORD *)a1 + 1), v4, v5, v6); v11 = v10; if ( !v10 ) return 0xFFFFFFFFLL; v8 = v7++; if ( v8 > (int)*a1 ) return 0xFFFFFFFFLL; if (!(*((unsigned int (__fastcall **)(__int64, __int64)) a1 + 3))(v10, a2)) break; v4 = sub_18000105C(a1, v9); } if ( !v11 ) return (unsigned int)-1; return v9; }

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int tree_find(struct tree* tree, void* data) { int i; int j; void *node; i = tree->compare(data, tree->root); for (j = 0; ; j++) { node = tree_get(tree->nodes, i); if (!node) return -1; if (j > tree->root) return -1; if (!tree->cmp(node, data)) break; i = tree_next(tree, i); } if (!node) return -1; return i; }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

ulonglong Ordinal_3(int *param_1,undefined8 param_2) { int iVar1; ulonglong uVar2; longlong lVar3; int iVar4; uVar2 = (**(code**)(param_1 + 4))(param_2,*param_1); iVar4 = 0; while( true ) { lVar3 = FUN_180001040(*(int **)(param_1 + 2),(int) uVar2); if ((lVar3 == 0) || (*param_1 < iVar4)) break; iVar1 = (**(code **)(param_1 + 6))(lVar3,param_2); if (iVar1 == 0) { if (lVar3 != 0) {return uVar2 & 0xffffffff;} return 0xffffffff; } uVar2 = FUN_18000105c(param_1,(int)uVar2); iVar4 = iVar4 + 1; } return 0xffffffff; }

(d) Decompiled by Ghidra

compatible field offsets and types, retaining their field-level confidence scores. These confidence scores focus later testing on uncertain fields, allowing earlier findings to support further recovery. If analysis of an execution anomaly contradicts an inherited hypothesis, the affected hypothesis is reopened for refinement. The recovered types and inferred behavior are then organized into documentation for the target function. Our main contributions are as follows: We introduce a hypothesize-validate-refine paradigm that treats LLM-inferred UDT layouts as falsifiable hypotheses tested through paired dynamic slice emulation, with observed program behavior guiding subsequent type refinement. • We propose the Execution-Depth Heuristic (EDH), which compresses paired baseline and mutated execution traces into a depth difference and a summary of the tested field’s observed uses to guide type refinement. • We design a cross-function knowledge base that aggregates compatible UDT hypotheses across functions, including those without direct call relationships, retains field-level confidence scores, and supports hypothesis refinement when conflicting execution evidence emerges. • We implement and evaluate LOHRE using the RealType dataset compiled at four optimization levels and a Windows RPC dataset. LOHRE achieves UDT Structural accuracy of 57.85% on RealType and 35.6% on Windows RPC, outperforming the evaluated static baselines. Ablation studies show that dynamic validation, EDH, and the cross-function knowledge base each contribute •

to LOHRE’s recovery performance. II. BACKGROUND AND M OTIVATION A. The Semantic Gap and the UDT Recovery Problem In a stripped binary, source-level identifiers, comments, and type information are generally unavailable, although the executable code preserves the program’s behavior [1]. Binary function documentation helps bridge this gap by explaining a function’s interface and behavior. Such documentation relies on type recovery to identify the types of function parameters and accessed data. A particularly challenging part of type recovery is UDT recovery, which reconstructs the memory layout of fields and padding. Without this layout, downstream tasks like structure-aware fuzzing struggle to construct valid inputs. Current automated tools can only partially recover UDTs. As Fig. 1 illustrates, Hex-Rays (IDA Pro’s decompiler) and Ghidra surface only pointer-offset accesses. LLM-based methods such as Idioms [3] produce more semantic output but, without validation, can hallucinate entirely incorrect structures. Idioms mistakes a hash table with callbacks for a tree in Fig. 1(b) and introduces unsupported node structures in Fig. 2(c). The source in Fig. 2(a) contains a hash structure whose data field points to a nested gap_array structure. ReSym identifies the top-level hash-table structure but misses the data field, while our LOHRE is able to recover both the top-level HashTable structure and its nested Container structure.

1 2 3 4 5 6 7

struct gap_array { int len; void** Array;}; struct hash { int hash_size; int item_cnt; struct gap_array* data; int (*hash_make_key)(void* item, int hash_size); int (*cmp_item)(void* item1, void* item2); };

(a) Source 1 2 3 4 5 6 7 8 9 10 11

1 2 3 4

(b) ReSym 1 2 3

struct tree { int root; void *nodes; int (*compare)(void *, void *); int (*cmp)(void *, void *); }; struct tree_node { int parent; int left; int right; }; struct tree_data { int data; int parent; int left; int right; };

struct HashTable{ unsigned int Slots; unsigned int Count; HashFunctions* Func; HashFunctions* comp; }

4 5 6 7 8 9 10 11 12 13 14

struct HashTable { DWORD capacity; // Number of slots DWORD size; // Number of elements Container* container; // Pointer to container hash_func_t hash_func; // Pointer to hash func compare_func_t cmp_func; // Pointer to cmp func }; struct Container { DWORD capacity; // Number of elements in the array DWORD padding; // Alignment padding(4 bytes) void** elements; // Pointer to array of elements }; typedef unsigned int (__fastcall* hash_func_t)(int* key, DWORD capacity); typedef int (__fastcall* compare_func_t)(void* element, int* key);

(d) LOHRE

Fig. 2. Recovery of nested hash-table structures by ReSym, Idioms, and LOHRE.

B. Limitations of Static-Only LLM Methods Existing LLM-based methods generally refine decompiler output [11–13] or perform end-to-end recovery [3–5]. Two limitations affect UDT recovery: unchecked layout predictions and scattered evidence. Unchecked layout predictions. Without execution feedback, an inferred layout may remain plausible even when it is inconsistent with the program’s memory accesses. A field’s width alone may support several types. For example, an 8-byte field could hold a pointer or a 64-bit scalar. The Systematization of Knowledge (SoK) on LLMs for reverse engineering [14] identifies robustness and hallucination mitigation as important but understudied objectives. Figure 1 and Figure 2 provide a concrete example of this failure mode. Scattered evidence in modular binaries. Exported application programming interface (API) functions can access different fields of a shared UDT without calling one another. Call-graph-based aggregation may miss this shared-data relationship and recover incomplete UDTs [3]. The same problem can arise in object-oriented systems, plugin frameworks, and event-driven middleware when an object’s lifetime spans several handlers. Addressing these limitations requires execution-based validation and cross-function evidence reuse. A practical framework must also manage execution feedback efficiently and minimize model preparation costs. Dynamic execution feedback. Dynamic execution feedback can help distinguish competing types when execution reaches an operation that accesses the selected field. For example, observing a field value used as a memory address supports a pointer interpretation, whereas an early return before that use leaves the hypothesis unresolved. Effective validation therefore requires both targeted inputs and fieldspecific execution observations. Execution feedback interpretation. Dynamic execution, however, can produce long execution traces that increase token costs and obscure evidence relevant to a tested field.

A larger context window does not eliminate this difficulty, as studies report degraded performance even within supported input lengths [6, 7, 15]. The feedback should therefore retain the field’s observed uses and relevant execution outcomes in a compact form. Model preparation. Idioms [3], ReSym [4], and LLM4Decompile [5] use models prepared through fine-tuning or domain adaptation. This dependence can require multi-day GPU training and may limit transfer to other architectures or coding styles. These limitations motivate a framework that can use an existing LLM without task-specific fine-tuning. C. Motivation: A Hybrid, LLM-Orchestrated Loop Addressing the two central limitations requires complementary kinds of evidence. Dynamic execution can invalidate a plausible but incorrect layout, while cross-function analysis can recover UDT information that no single function exposes. LOHRE combines these two distinct types of evidence in a hypothesize-validate-refine workflow. LOHRE uses static analysis to propose structural candidates, dynamic emulation to test inputs constructed from them, and EDH to summarize the resulting execution evidence. For example, a decrease in execution depth may reflect an incompatible type or a change in control flow unrelated to that type. LOHRE examines the field’s observed uses and relevant code to interpret this signal and decide how to refine the hypothesis. The knowledge base carries compatible hypotheses and their field confidences across functions, so later observations can extend or revise an earlier interpretation. III. A PPROACH LOHRE implements the loop with four specialized agents: the Coordination Agent, Knowledge Base Agent, Test Case Agent, and Executor Agent (Fig. 3). They interact with two external tools through the Model Context Protocol (MCP) [16]: the Static Analysis MCP and the Dynamic Slice Emulation MCP. This division of responsibilities allows each agent to

Iterative Hybrid Refinement

Coarse-grained static analysis Executor Agent （Static Mode）

Binary

Candidate UDT Retrieval

Inspect Code & Xrefs

Layout-Aware Evidence Matching

Type & Signature Inference

Target Function

Knowledge Base Agent

Decompile Target Function

Test Case Agent

Coordination Agent Assess Field Confidence

Test Context

Select Target Field Build Baseline

Confidence-Guided Merging

Initial Hypotheses Cross-Function Knowledge Base

Same-Width Mutation

Dispatch Test Context Paired Test Inputs

Finish Refinement

Final Documentation Executor Agent (Auto Mode)

Function Summary

Static Analysis MCP

Dynamic Slice Emulation MCP

Function Prototype

Paired Slice Emulation

Static Inspection

Parameter Descriptions

EDH Analysis

Refined Hypothesis

Return Value Semantics

Recovered UDT Layouts

Fig. 3. LOHRE’s workflow for iterative hypothesis testing and documentation.

maintain a compact, task-focused context, thereby curbing the overhead of repeatedly processing accumulated execution histories [10] and mitigating the reasoning degradation caused by excessively long inputs [6, 7]. The framework’s token efficiency is quantified in Section IV-E. Each refinement step uses a concise record linking the selected field and its current hypothesis to the supporting EDH feedback. Evidence locations are retained so that the Executor can inspect the corresponding code when more detail is needed to support a decision. The record thus keeps the working context focused while preserving the basis for checking and revising an earlier interpretation. The supplementary document specifies the four agents’ tasks and reasoning rules. The artifact linked at the end of the abstract provides the prompt catalog, including the full public system texts and shared guidance. A. Workflow Analysis of a target function follows the three stages in Fig. 3. Coarse-grained static analysis. Given a binary and a target function, LOHRE prepares the analysis environment. The Executor Agent in Static mode decompiles the function, inspects code and cross-references, and infers preliminary types and the function signature. These initial hypotheses, together with field-level confidence scores, establish the analysis state for refinement. Iterative hybrid refinement. The Knowledge Base Agent retrieves candidate UDTs, matches layout evidence, and merges compatible hypotheses using their field confidences. The Coordination Agent assesses the resulting confidences and either finishes refinement or selects the lowest-confidence target field. It dispatches a test context containing the selected field and the current analysis information needed to construct a test. The Test Case Agent uses this context to build a baseline input and a same-width mutation, producing paired test inputs in recursively nested [type, content, length] syntax. The Executor Agent in Auto mode performs paired slice emulation, interprets the EDH feedback, and uses static inspection when further evidence is needed. The updated analysis state returns to knowledge synthesis for the next coordination step. Refinement stops when all relevant field confidences reach 0.9 or after 20 paired-test iterations for the function. Final documentation. The Knowledge Base Agent’s report mode formats the latest analysis state into a function sum-

Algorithm 1: Iterative Hybrid Refinement Input: Target function f , iteration cap Nmax = 20, confidence threshold τ = 0.9 Output: Documentation report R 1 D ← E XECUTOR . ANALYZE (f, Static_Only); 2 for i = 1 to Nmax do 3 D ← K NOWLEDGE BASE . SYNTHESIZE(D); 4 dec ← C OORDINATION . ASSESS(D, τ ); 5 if dec.status = Over then 6 break 7

8 9 10

T ← C OORDINATION . DISPATCH(D, dec.mutate field); P ← T EST C ASE . GENERATE(T ); D ← E XECUTOR . ANALYZE(f, Auto, D, P );

return K NOWLEDGE BASE . GENERATE REPORT(f, D);

mary, function prototype, parameter descriptions, return value semantics, and recovered UDT layouts. This state includes the latest Executor result when the iteration cap is reached. B. Agents The four agents handle coordination, cross-function knowledge synthesis and report formatting, paired test-input construction, and hybrid analysis, respectively. Static and Auto are two modes of the same Executor Agent. Coordination Agent. Algorithm 1 summarizes the function analysis shown in Fig. 3. The analysis state D contains the parameter template, UDT hypotheses, function summary, field confidences, and available execution feedback. The relevant confidence entries cover the parameters and UDT members eligible for testing; the selected entry is called the target field in the workflow. After knowledge synthesis, the Coordination Agent checks whether all relevant confidences reach 0.9. If all relevant confidences reach 0.9, the Coordination Agent returns Over; otherwise, it selects the lowest-confidence target field and dispatches the associated test context to the Test Case Agent. The context provides the selected field, current parameter template, UDT hypotheses, function summary, and available execution feedback. These inputs let test construction follow the current interpretation and the conditions revealed by earlier runs. Knowledge Base Agent. During refinement, the Knowledge Base Agent retrieves candidate UDT definitions from

the cross-function knowledge base and compares them with the current hypotheses. It performs layout-aware evidence matching using the structure-aggregation method proposed by HyRES [13]. Field names are compared using general text embeddings (GTE) [17], together with checks on offset alignment and field-type consistency. LOHRE refines HyRES’s layoutoverlap penalty for unresolved layout regions provisionally represented as padding. Overlap in these regions is not penalized, allowing later observations to replace the unresolved bytes with supported members. The agent justifies each merge, rejects inconsistent offsets or field types, and creates a new entry when a hypothesis has no compatible match. Confidence-guided merging prioritizes higher-confidence field information among compatible hypotheses and preserves the associated scores in the resulting definition. The Coordination Agent can then focus testing on the least certain fields, reducing repeated work. If execution analysis identifies an inherited field as the cause of an anomaly, the Executor lowers that field’s confidence and retests the hypothesis. Later functions can thus both extend and correct earlier definitions. For final documentation, the Knowledge Base Agent formats the latest analysis state into the five components shown in Fig. 3: function summary, function prototype, parameter descriptions, return value semantics, and recovered UDT layouts. Test Case Agent. The Test Case Agent receives the test context dispatched by the Coordination Agent and constructs baseline and mutated inputs in [type, content, length] syntax. For a scalar, content holds its value. For a structure pointer, ["struct_pointer", [...], p] contains an ordered list of member triplets, with recursive nesting for structures and arrays. Here, p is the pointer width in bytes, which is 8 on x86-64. The pair is designed to reach an operation that can distinguish the candidate types. The agent identifies the required conditions from the current function summary, input checks, and previous execution feedback. If reaching the operation depends on other arguments or global settings, the Test Case Agent configures those arguments or settings consistently for both runs. A compatible input that previously returned normally can serve as a starting point for testing another field. To form the pair, the agent builds a baseline under the current hypothesis and applies a same-width mutation to the selected field. The mutation tests a competing type suggested by the field’s apparent role while preserving the field’s storage width in bytes. An 8-byte field, for example, may be tested as a 64-bit integer, a double, or a pointer while preserving the surrounding layout. For a pointer input, the agent describes the pointed-to storage using the current UDT definition and recursively nested member triplets. The Dynamic Slice Emulation MCP allocates these objects and binds their addresses when preparing each run. All other arguments, fields, and prepared execution conditions remain consistent across the pair. In subsequent rounds, revised function summaries and execution feedback guide further input adjustments. Executor Agent. In Static mode, exposed as Static_Only in the interface, the Executor decompiles the target function, inspects code and cross-references, and forms initial UDT and parameter hypotheses. Its initial field

confidences are capped at 0.5. In Auto mode, exposed as Auto, it runs the paired test inputs through the Dynamic Slice Emulation MCP and interprets the compressed EDH feedback (Section III-D). Static inspection through the Static Analysis MCP supplies further code evidence when needed. The Executor then updates the UDT interpretation, field confidences, and function summary according to the resulting evidence. Each confidence score expresses the Executor’s current assessment of the supporting evidence, with 0.9 as the acceptance and stopping threshold. When a definition is reused across functions, its field confidences are retained, allowing refinement to concentrate on less certain fields. When EDH feedback leaves competing types unresolved, the Executor can request detailed traces of the baseline and mutated runs to locate where their execution diverges. It then uses static inspection of the corresponding code to explain the divergence and revise the selected field’s assessment and type hypothesis. This analysis may identify an inherited field as the cause of an execution anomaly, even if another field is being tested. In that case, the Executor lowers the responsible field’s confidence and reopens its type hypothesis. The Executor also uses these findings to revise the function summary when they reveal an input condition or clarify the function’s behavior. For instance, if execution stops before using the selected field, the Executor records the blocking input condition to guide subsequent test construction. Execution can also help complete an initial layout by revealing accesses within an unknown region of an identified object. The Executor uses the access offset within that object and the access width to propose a member, preserving the established object size and neighboring members. The proposed member then enters subsequent tests as a tentative hypothesis, allowing refinement to add members suggested by actual accesses as well as revise existing types. Name inference. To describe the roles of recovered parameters and members, the Executor proposes names using static code context and API usage. Execution evidence helps clarify these roles by showing how the function uses the corresponding values. The Executor stores the proposed names alongside the type hypotheses. The Knowledge Base Agent uses these records to assemble the final report. The evaluation then compares these names with reference identifiers to measure name accuracy separately from type accuracy. C. MCP Toolset The Model Context Protocol [16] provides a uniform interface for LLM-tool interaction and allows compatible tool implementations to be substituted. The Static Analysis MCP exposes decompilation, disassembly, and cross-reference queries so that the Executor can inspect the code under a type hypothesis. The Dynamic Slice Emulation MCP tests that hypothesis through paired slice emulation with the constructed inputs and collects the execution evidence needed for EDH analysis. Before execution, the dynamic tool loads the target binary and its dependencies, allocates memory for pointer objects, and places arguments according to the target’s calling convention. To make the comparison meaningful, both runs start

from the same initial conditions, including the loaded image’s global values and any adjustments needed to reach the selected field. Their execution states are separate, preventing memory or resource changes in one run from carrying into the other. During execution, API models or configured replacement functions (stubs) handle external calls, and the tool records the information needed to construct EDH feedback. Once this environment is prepared, execution begins at the target function’s entry and follows its control flow through any called functions. Execution stops when the target returns, an exception occurs, or the execution budget is reached. In LOHRE, dynamic slice emulation denotes this execution of the target function and its callees under prepared inputs and isolated runtime state. Paired slice emulation executes the target once with the baseline input and once with the mutated input under the same prepared conditions. The emulation tool records basic blocks, external calls, and execution outcomes for each run. It also records how the selected field’s value and values derived from it are used in memory accesses, conditions, computations, and API arguments, supplying the observations that EDH summarizes for hypothesis assessment. D. Execution-Depth Heuristic EDH compresses paired execution traces into a depth difference and a short behavior summary for the selected field. This feedback keeps type refinement focused and reduces the cost of processing lengthy execution histories. The depth comparison reflects the input checks that often precede a function’s main logic. An input constructed from an incompatible layout may fail these checks, whereas one constructed from a compatible layout can enable further execution. Figure 4 illustrates this pattern in SSL_CTX_set_alpn_protos, with green marking the main processing path and red marking early-return branches. To quantify this difference, let BM (r) be the set containing the basic-block entry addresses executed during run r in the target’s binary module M . A basic block is a sequence of instructions with no internal branch. We define execution depth as d(r) = |BM (r)| + NAPI (r), where NAPI (r) counts observed external API calls. Each block contributes once, including blocks in callees within the same module. External library internals are outside the block count, while repeated API calls contribute individually. For paired runs, a positive ∆d = d(rmutated )−d(rbaseline ) initially favors the mutation, a negative value favors the baseline, and zero gives no preference from depth. To relate this comparison to the field hypothesis being tested, EDH summarizes how the target uses the selected value. The execution tool first marks the value at its input location in a register or memory. It follows that origin through copies and supported computations, recording derived values and their uses in the target module. When a write occurs, the destination receives the new value’s origin record if the value has been traced to the selected field. Otherwise, the tool clears the old record so that it no longer attributes the destination’s contents to an earlier value. At external calls, known

int SSL_CTX_set_alpn_protos(…) { unsigned char *alpn; if (protos_len == 0 || protos == NULL) { OPENSSL_free(ctx->ext.alpn); ctx->ext.alpn = NULL; ctx->ext.alpn_len = 0; return 0; } if (!alpn_value_ok(protos, protos_len)) return 1; alpn = OPENSSL_memdup(protos, protos_len); if (alpn == NULL) return 1; OPENSSL_free(ctx->ext.alpn); ctx->ext.alpn = alpn; ctx->ext.alpn_len = protos_len; return 0; }

protos_len == 0 || protos == NULL OPENSSL_free(…) Return 0

!alpn_value_ok(…)

OPENSSL_memdup(...)

Return 1

alpn == NULL OPENSSL_free(…)

Return 1

Return 0

Fig. 4. Control flow of OpenSSL’s SSL_CTX_set_alpn_protos.

API declarations associate tracked values with the receiving parameters, distinguishing field values from addresses of field storage. Because repeated execution can generate redundant observations, the tool merges records with the same runtime instruction address, use category, and descriptive attributes. A use category describes the value’s role, such as addressing memory or supplying an API argument. Attributes such as access width and argument position distinguish different uses at the same instruction. Each merged record retains occurrence counts and representative operand values, and matching records are aligned between the runs. Within this summary, address uses and declared API arguments receive priority because they directly constrain interpretation. Conditions and computations provide further distinctions between value types. These records and execution outcomes form the compact behavior summary accompanying the depth difference. The Executor uses this summary to determine whether the depth preference supports the candidate type. For example, a four-byte read establishes an access width, whereas using the value as a memory address supports a pointer interpretation. Passing the selected value to a known integer API parameter can also constrain its interpretation, even when the paired runs have equal depth. The Executor uses these constraints from normally returning runs to refine the candidate. If the uses establish only a broad type category, the more precise declaration remains open to further refinement. When the evidence conflicts or needs further explanation, the recorded code locations guide static inspection and requests for detailed traces. E. Worked Example: One Iteration To illustrate the loop, we trace one iteration on hash_find_index (Fig. 2). The coarse-grained static pass recovers a preliminary HashTable definition with five fields, but the 8-byte field at offset 8 remains uncertain. The function passes this field’s value to FUN_180001040, the hash table’s gap_get helper. This observation establishes the field’s width but leaves open whether its value is a pointer to a nested structure or a 64-bit scalar. The Coordination Agent selects this field for the next test. The Test Case Agent emits paired test inputs using the format described in Section III-B. The baseline encodes the field as ["struct_pointer",[["int",1,4], ["int",2,4],["pointer",arr,8]],8], i.e., a

pointer to a nested Container that mirrors the gap_array layout: a 4-byte length, 4 bytes of alignment padding, and an 8-byte array pointer. The mutation preserves the 8-byte width but encodes the field as ["qword",k,8], a 64-bit scalar. The Executor runs both inputs through the Dynamic Slice Emulation MCP. In the baseline run, FUN_180001040 uses the field as a valid structure pointer, reads len and Array, and returns a live entry. Control then returns to hash_find_index, which continues through comparison and advancement before reaching its success branch. In the mutated run, the field instead contains a 64-bit scalar. When FUN_180001040 uses this value as an address, an invalid memory read stops execution at the first dereference. EDH favors the baseline because it reaches more code, and the behavior summary connects this difference to the tested field: the pointer supports nested-object accesses, whereas using the scalar as an address causes a fault. These observations support the struct_pointer-toContainer interpretation, so the Executor raises the field’s confidence past the threshold. The Knowledge Base Agent then incorporates the hypothesis. This decision follows from paired EDH feedback without consulting per-function ground truth. IV. E VALUATION LOHRE organizes the recovered types and inferred behavior into a report describing the function’s purpose, interface, and UDT layouts. We assess recovery accuracy using the exact-match metrics established by Idioms [3], allowing direct comparison with existing methods. A complementary user study examines whether practitioners find the resulting documentation accurate and useful beyond exact textual matches. Five research questions guide the evaluation: RQ1 How does LOHRE compare with the evaluated baselines on Variable Name, Variable Type, UDT Nominal, and UDT Structural accuracy? RQ2 How does compiler optimization affect LOHRE’s recovery? RQ3 What is the practical quality of LOHRE-generated documentation, as judged by reverse-engineering practitioners? RQ4 What are the individual contributions of dynamic validation, EDH, and the knowledge base? RQ5 How does LOHRE’s complete workflow compare with single-agent frameworks given the same tools? A. Experimental Setup Datasets. We use two complementary corpora. (1) RealType [3], a benchmark with UDT ground truth, well suited to general UDT recovery. To ensure fairness, we match Idioms’ setup exactly (inlining disabled). RealType was compiled at four optimization levels (O0–O3, GNU Compiler Collection (GCC) 9.4.0). (2) Windows RPC, a dataset we assembled containing 4,280 exported and interface functions from 33 Windows 11 (build 26100.6899) System32 binaries. We selected components using Microsoft Open Specifications [18] to cover security, printing, networking, storage, and system management.

These components use handles and nested data structures shared across interface functions. Recovering their complete type definitions therefore requires combining evidence from functions with separate roles, making the corpus suitable for studying scattered evidence. To construct reference annotations, we first obtained version-matched program database (PDB) files from the Microsoft Symbol Server [19]. Their debug symbols identified functions and provided type information where available. Because public PDBs may miss parameter and member types [20], we also consulted declarations in the Win32 API reference [21] and public protocol definitions. We checked these declarations against parameter use and member accesses in the disassembly, drawing on published technical analyses to clarify internal structures. Public RPC specifications declare interface methods and their parameter types in Interface Definition Language (IDL). The Microsoft IDL (MIDL) compiler generates client and server stub code to handle remote calls [22]. Network Data Representation (NDR) metadata describes how this code encodes RPC arguments for transmission, providing evidence about parameter and aggregate representations [23]. Baselines. We compare LOHRE with three LLM-based methods that have runnable artifacts for our corpus. Idioms [3] is a fine-tuned neural decompiler that jointly predicts code and types. For ReSym [4], we use the aligned reproduction supplied by TRex [24]. The TRex authors independently verified the incompleteness of ReSym’s original artifact. LLM4Decompile [5] generates decompiled code but does not explicitly emit structure definitions, so its UDT metrics are marked N/A. We discuss other hybrid type-recovery systems in Section VI. These comparisons evaluate complete systems, whose model backbones and inference budgets differ. Metrics. We adopt Idioms’ metrics [3] to evaluate variable names, variable types, and UDT definitions. Variable Name Accuracy and Variable Type Accuracy measure agreement with the reference variable names and types. For UDTs, the scorer first aligns members by offset and width, then compares the structure size and recursive member types. UDT Structural Accuracy measures whether these layout requirements are met. UDT Nominal Accuracy additionally requires exact membername matches. All name comparisons use exact strings, including capitalization, underscores, and prefixes. Consequently, a semantically equivalent name such as readInput does not match read_input. We retain this rule for consistent comparison with Idioms and ReSym, and use the user study (RQ3) to assess the documentation’s semantic utility. Repeated runs. Every accuracy value reported below is the mean of 8 independent runs. These repetitions characterize run-to-run variability. Implementation and environment. LOHRE is implemented in Python 3.13. In our experimental implementation, the Static Analysis MCP uses Ghidra 11.4.2 [25], and the Dynamic Slice Emulation MCP uses Qiling 1.4.7 [26]. Both tools are accessed through FastMCP. The agents use DeepSeek-V4-Flash [27], and the knowledge base stores text entries separately for each binary. All experiments ran on

Accuracy (%)

LLM4Decompile ReSym (b) Variable Type Acc.

(a) Variable Name Acc.

RPC

40 30 20

10 0

RPC

(d) UDT Structural Acc.

Idioms LOHRE (c) UDT Nominal Acc.

10 O0

RPC

Fig. 5. Recovery accuracy by dataset, optimization level, and metric. 1

TABLE I

T YPE AND NAME RECOVERY ACCURACY ON R EALT YPE AND W INDOWS RPC. Variable Name Acc. (%) Dataset

LLM4Dec.

ReSym

Idioms

Variable Type Acc. (%) LOHRE LLM4Dec.

ReSym

Idioms

UDT Nominal Acc. (%) LOHRE LLM4Dec.

ReSym

Idioms

UDT Structural Acc. (%) LOHRE LLM4Dec.

ReSym

Idioms

LOHRE

Panel A: RealType RealType O0 RealType O1 RealType O2 RealType O3

3.4 3.2 3.9 3.5

28.9 27.6 24.2 23.5

19.8 18.7 17.9 17.8

34.3 32.9 29.7 29.1

13.4 11.4 11.7 10.7

33.2 32.7 32.3 31.5

38.3 34.0 33.3 32.6

58.1 56.6 56.3 54.4

N/A N/A N/A N/A

5.3 4.2 3.9 3.8

6.4 5.6 6.0 5.7

18.5 17.8 16.2 14.3

N/A N/A N/A N/A

24.2 23.5 23.1 22.8

15.0 14.7 13.4 12.3

60.6 58.2 56.5 56.1

RealType Avg. Ratio

3.50 9.00

26.05 1.21

18.55 1.70

31.50 –

11.80 4.78

32.43 1.74

34.55 1.63

56.35 –

N/A N/A

4.30 3.88

5.93 2.82

16.70 –

N/A N/A

23.40 2.47

13.85 4.18

57.85 –

Windows RPC Ratio

12.2 2.51

3.1 9.87

4.2 7.29

30.6 –

18.6 2.25

25.4 1.65

3.5 3.29

0.9 12.78

11.5 –

N/A N/A

13.3 2.68

2.2 16.18

35.6 –

Panel B: Windows RPC 16.7 2.51

Ubuntu 22.04 with an Intel i9-10980XE processor and 128 GB random-access memory (RAM). Two NVIDIA RTX 5060 GPUs were reserved for baseline inference. Execution budget and failure handling. Within the 20iteration budget for each function, every baseline or mutated execution is limited to 100,000 instructions or five seconds. We count an emulation as successful when execution reaches the designated return address, indicating that the function has returned to its caller. Because a normal return may still report an application-level error, we record the return code separately. We also distinguish exceptions, budget exhaustion, and initialization failures when recording unsuccessful executions. When execution provides no usable dynamic evidence, the Executor retains the static hypotheses for documentation without treating environment failures as support for a type. Any revised inputs or field tests remain within the same function’s iteration budget. For transient model-request failures, LOHRE makes at most three transmission attempts per request. B. Overall Performance (RQ1, RQ2) Table I reports the recovery results for each dataset. Bold values mark the highest accuracy, and Ratio gives LOHRE’s accuracy divided by that of the corresponding baseline. N/A marks entries for which the comparison is not applicable. Figure 5 plots these results by metric, with error bars showing one standard deviation above and below LOHRE’s mean across eight runs. Run-to-run variability. Across the 20 combinations of evaluation setting and metric, the standard deviations over eight independent runs fall within the following ranges: σUDT-Struct ∈ [0.7, 2.1] percentage points (pp), σUDT-Nom ∈

41.9 –

N/A N/A

[0.5, 1.8] pp, σVar-Type ∈ [1.0, 2.9] pp, and σVar-Name ∈ [1.1, 3.4] pp. These ranges characterize LOHRE’s run-to-run variability and are small relative to the result gaps in Table I. UDT and variable recovery (RQ1). LOHRE attains the highest accuracy in every reported evaluation setting and metric. Across RealType O0–O3 and Windows RPC, LOHRE’s mean Variable Name accuracy is 2.00× the mean for Idioms, 1.46× that for ReSym, and 5.98× that for LLM4Decompile. For Variable Type accuracy, LOHRE achieves 1.73× the mean for Idioms, 1.72× the mean for ReSym, and 4.06× the mean for LLM4Decompile. For UDT Nominal accuracy, LOHRE achieves 3.18× the mean for Idioms and 3.78× the mean for ReSym. For UDT Structural accuracy, it achieves 4.64× the mean for Idioms and 2.50× the mean for ReSym. We attribute these gains mainly to iterative validation: execution provides evidence for identifying incorrect layouts and refining hypotheses when static code alone leaves them ambiguous. Robustness to compiler optimization (RQ2). On RealType, UDT Structural accuracy decreases from O0 to O3 for Idioms, ReSym, and LOHRE. Idioms drops by 2.7 pp (18.0% relative), ReSym by 1.4 pp (5.8%), and LOHRE by 4.5 pp (7.4%). LOHRE’s relative decrease lies between those of the two static baselines. At O3, however, its accuracy of 56.1% remains more than 2.4× that of the strongest baseline, ReSym at 22.8%. Thus, LOHRE retains its accuracy advantage under aggressive compiler optimization. Performance on Windows RPC. The Windows RPC dataset tests recovery when evidence about a UDT is distributed across functions. LOHRE pairs a general-purpose LLM with MCP tools that test candidate layouts against execution behavior. This lets prior knowledge guide candidate

Professional

TABLE II P ER - FUNCTION TOKEN USE AND RUNTIME DISTRIBUTIONS . Tokens

Intermediate

Basic Mean 8.2 9.2 8.5 7.2 8.2 7.6 8.1 8.5 8.6 5.9 7.1 7.5 8.3 9.1 8.9

Runtime (s)

System

mean

p95

max

mean

p95

max

LLM4Decompile ReSym Idioms LOHRE LOHRE-NoEDH

920 2195 1500 142k 521k

686 1295 783 102k 412k

2376 4796 3183 307k 1274k

4096 8192 4096 1179k 3265k

13.5 2.6 1.9 401 1183

3.6 1.5 1.0 266 814

18.3 5.8 3.7 879 2840

40.5 11.3 8.7 2139 5763

Q2 Q3 Q4

generation while execution provides evidence for refinement. The training-free framework avoids the costs of collecting task-specific training data and adapting a model to the target domain. Idioms and ReSym, whose training corpora omit Windows binaries, perform less well in this setting. LOHRE attains accuracies of 30.6%, 41.9%, 11.5%, and 35.6% for Variable Name, Variable Type, UDT Nominal, and UDT Structural recovery, respectively, corresponding to 1.65×–16.18× the accuracy of the evaluated baselines. Recovery is harder than on RealType because larger UDTs contain rarely accessed fields, and UDT Nominal accuracy requires both a correct structure and exact field names. A single mismatch can therefore cause a recovered definition to fail this metric. Windows also revises internal structures across releases, so a candidate based on pretrained API knowledge may refer to an outdated layout. Two results help explain how LOHRE’s design contributes beyond pretrained API knowledge. On RealType, which provides a GCC-based setting across four optimization levels, LOHRE reaches 57.85% UDT Structural accuracy compared with Idioms’ 13.85%. On Windows RPC, holding the LLM fixed while disabling the knowledge base reduces UDT Structural accuracy from 35.6% to 10.0% (Table III). These observations support the contribution of LOHRE’s analysis workflow and cross-function evidence to recovery. Cost and efficiency. LOHRE incurs higher inference costs than fine-tuned baselines but requires no fine-tuning. Table II summarizes function-level costs using the mean, standard deviation, 95th percentile (p95), and maximum of per-function token use and runtime. It also includes LOHRE-NoEDH, the ablation of EDH’s trace compression described in Section IV-D. For baseline token use, the Max column lists published context limits: 4096 for LLM4Decompile [5] and Idioms [3], and 8192 for ReSym [4]. These entries are capacity specifications, not measured per-function maxima. At DeepSeek-V4-Flash list pricing, LOHRE’s measured token use corresponds to an average cost of $0.03 per function, with documentation produced in 401 s on average. The p95 runtime and estimated cost are 879 s and $0.05 per function, respectively. These costs can be weighed against the effort required for manual analysis when assessing LOHRE’s practical value. C. Documentation Quality (RQ3) We randomly selected ten LOHRE outputs from the evaluated set (five RealType and five Windows RPC) and ran a blind user study with ten participants of varying expertise and experience: three senior reverse engineers with more than three years of experience, three mid-level engineers with approximately two years of experience, and four practitioners with

Q5 1

5 Score

Fig. 6. Documentation ratings across three participant groups. 1

foundational reverse-engineering (RE) knowledge. Following DeGPT [12], each participant rated five aspects of each report on a 1–10 scale (1=completely wrong, 5=neutral, 10=accurate and complete). This produced 500 aspect ratings (10×10×5). Figure 6 displays these aspects as Q1–Q5, corresponding to the function summary, function prototype, parameter descriptions, return-value semantics, and recovered UDT layouts, respectively. Participation in the user study was voluntary, and all participants were informed that their anonymized responses would be used solely for this research. Figure 6 reports the mean ratings for each participant group, with horizontal lines indicating 95% bootstrap confidence intervals. Except for return-value analysis (Q4), all aspects score between 7.2 and 9.2. The lower Q4 ratings reflect a coverage limitation: LOHRE currently infers return-value semantics from a single execution path and may miss alternative return points (Section V-B). Fleiss’ κ ranges from 0.56 to 0.65 across the five questions, indicating moderate to substantial inter-rater agreement. Annotation guidelines and the full perquestion rubrics are provided in the artifact. D. Ablation Study (RQ4) We construct three LOHRE variants to assess dynamic validation, cross-function knowledge reuse, and EDH compression. (i) LOHRE-Static disables dynamic validation entirely. (ii) LOHRE-NoKB disables the cross-function knowledge base. (iii) LOHRE-NoEDH retains dynamic validation but replaces EDH’s compressed feedback with full execution traces supplied to the Executor. In LOHRE-NoEDH, the multi-agent framework, knowledge base, and mutation strategy remain the same. All variants use the same evaluation settings as full LOHRE: RealType at O0–O3 and Windows RPC, with eight runs per setting. Table III reports mean accuracy over eight runs for each evaluation setting. Figure 7 averages those means across five settings: RealType at O0–O3 and Windows RPC. Dynamic validation. Disabling dynamic validation (LOHRE-Static) reduces UDT Structural accuracy by 66.7% on RealType (57.85%→19.28%) and 74.2% on Windows RPC (35.6%→9.2%). The larger relative drop on Windows RPC is consistent with the interaction between validation and knowledge reuse. Execution feedback both helps identify

TABLE III R ECOVERY ACCURACY WITH DYNAMIC VALIDATION , THE KNOWLEDGE BASE , OR EDH DISABLED . Variable Name Acc. (%) Dataset

Static

NoKB

NoEDH

Variable Type Acc. (%) LOHRE Static

NoKB

NoEDH

UDT Nominal Acc. (%) LOHRE Static

NoKB

NoEDH

UDT Structural Acc. (%) LOHRE Static

NoKB

NoEDH

LOHRE

Panel A: RealType RealType O0 RealType O1 RealType O2 RealType O3

27.6 26.1 26.3 24.5

31.3 29.5 28.9 25.7

28.4 27.7 27.1 26.3

34.3 32.9 29.7 29.1

34.8 30.4 28.9 27.7

43.5 42.6 41.8 38.6

38.0 35.3 35.6 34.3

58.1 56.6 56.3 54.4

11.2 10.5 10.1 8.3

13.7 12.8 10.2 9.8

13.0 12.0 10.9 9.4

18.5 17.8 16.2 14.3

22.1 21.4 17.9 15.7

41.8 41.2 40.8 40.3

32.9 30.4 31.2 26.8

60.6 58.2 56.5 56.1

RealType Avg. 26.13 Ratio 1.21

28.85 1.09

27.38 1.15

31.50 –

30.45 1.85

41.63 1.35

35.80 1.57

56.35 –

10.03 1.67

11.63 1.44

11.33 1.47

16.70 –

19.28 3.00

41.03 1.41

30.33 1.91

57.85 –

Windows RPC Ratio

15.8 1.94

13.0 2.35

30.6 –

22.5 1.86

30.0 1.40

2.2 5.23

6.7 1.72

11.5 –

9.2 3.87

10.0 3.56

14.3 2.49

35.6 –

Panel B: Windows RPC 12.4 2.47

LOHRE-Static

LOHRE-NoKB

Average Accuracy (%)

LOHRE-NoEDH

27.0 1.55

LOHRE

53.46

53.40

50 39.30

40 30

31.32 23.38

26.24 24.50

27.12

15.66 17.26 8.98 9.74 10.40

10 0

Variable Name Acc.

Variable Type Acc.

UDT Nominal Acc.

4.8 2.40

TABLE IV R ECOVERY ACCURACY OF LOHRE AND GENERAL - PURPOSE AGENTS ON R EALT YPE -O3. Configuration

34.82

34.04 28.86

41.9 –

UDT Structural Acc.

Fig. 7. Mean ablation accuracy across the five evaluation settings. 1

incorrect hypotheses and provides evidence for combining UDT information across functions. Without it, errors in static hypotheses can persist during aggregation. Knowledge base. Disabling the knowledge base (LOHRENoKB) reduces UDT Structural accuracy from 57.85% to 41.03% on RealType, a 29% drop. The loss is greater on Windows RPC, where accuracy falls from 35.6% to 10.0%, a 72% drop. RealType UDTs are largely local to individual functions, whereas Windows RPC distributes information about shared UDTs across functions. This contrast supports the role of the knowledge base in combining scattered evidence. Execution-Depth Heuristic. Replacing EDH’s compressed feedback with full traces (LOHRE-NoEDH) reduces recovery accuracy on both datasets. On RealType, UDT Structural, UDT Nominal, Variable Type, and Variable Name accuracies are 30.33%, 11.33%, 35.80%, and 27.38%, respectively. LOHREStatic obtains 19.28% UDT Structural, 10.03% UDT Nominal, 30.45% Variable Type, and 26.13% Variable Name accuracy; full LOHRE obtains 57.85%, 16.70%, 56.35%, and 31.50% on the same metrics, respectively. On Windows RPC, LOHRENoEDH obtains 14.3% UDT Structural, 6.7% UDT Nominal, 27.0% Variable Type, and 13.0% Variable Name accuracy; full LOHRE obtains 35.6%, 11.5%, 41.9%, and 30.6% on the same metrics, respectively. Table II also shows a higher cost: mean token use reaches 521k and mean runtime reaches 1183 s, corresponding to 3.7× the token use and 3.0× the runtime of full LOHRE. We attribute this accuracy loss to the difficulty of reasoning over long execution histories [8, 9]. This explanation is supported by studies showing that long inputs can impair the use of relevant evidence even within a model’s supported context window [6, 7, 15]. At the same time, carrying full

DeepSeek Harness Claude Code LOHRE

Name

Type

UDT Nom.

UDT Struct.

24.9 (1.17×) 27.2 (1.07×)

33.2 (1.64×) 48.5 (1.12×)

7.90 (1.81×) 10.3 (1.39×)

21.6 (2.60×) 40.1 (1.40×)

29.1

54.4

14.3

56.1

traces into subsequent turns increases token costs by repeatedly including the accumulated execution history [10]. EDH retains the depth comparison and the field behavior needed to interpret it in a compact validation interface. This compression keeps the evidence for the selected hypothesis within a concise working context. E. LOHRE vs. Single-Agent Framework (RQ5) We compare LOHRE with two single-agent baselines on RealType-O3, both equipped with the same Static Analysis MCP and Dynamic Slice Emulation MCP tools as LOHRE. The DeepSeek Harness [28] is an execution harness specifically designed for DeepSeek models, using native tool invocation on the same DeepSeek-V4-Flash [27] backbone as LOHRE but without LOHRE’s hypothesize-validate-refine loop. Claude Code is a representative state-of-the-art generalpurpose agent framework running in its default configuration on the same task and toolset but with a different backbone (Claude Sonnet 4.6 [29]). Table IV reports the results, with parenthesized values giving LOHRE’s accuracy divided by that of the corresponding baseline. LOHRE achieves higher accuracy than both single-agent baselines on every metric while using fewer tokens. On RealType-O3, the DeepSeek Harness uses the same DeepSeekV4-Flash backbone as LOHRE and consumes 633k tokens per function on average, compared with LOHRE’s 126k, meaning that it uses 5.01× as many tokens. This comparison evaluates LOHRE’s complete workflow and agent organization with the model backbone held fixed. Claude Code provides a complementary comparison with a general-purpose agent framework using Claude Sonnet 4.6. It consumes 571k tokens per function (4.52× LOHRE’s use) and has lower accuracy on every metric, including UDT Structural accuracy of 40.1 versus LOHRE’s 56.1. Together, these results support the value of task-specific hypothesize-validate-refine orchestration.

Context management provides an explanation for the token difference. During dynamic analysis, detailed traces and operational history accumulate, and repeatedly including them in later requests increases token costs [10]. Long inputs can also impair the use of relevant evidence [6, 7, 15]. LOHRE supplies each agent with context focused on its task, limiting the history carried into subsequent requests. This task-focused context may help explain why the same-backbone DeepSeek Harness uses 5.01× as many tokens as LOHRE. V. D ISCUSSION A. Why the Paradigm Works LOHRE is built around a central shift: it treats LLM outputs as falsifiable hypotheses rather than authoritative predictions, using execution feedback to identify inconsistencies and provide refinement signals rather than to prove type correctness. LOHRE tests competing interpretations of the selected field using paired inputs, and EDH compresses the traces into a depth comparison and a summary of the field’s observed uses. The Executor uses this feedback to evaluate the candidate’s plausibility and carry the relevant evidence into subsequent iterations. The lower accuracy of the static-only ablation supports the contribution of dynamic validation to recovery. The knowledge base extends this process across functions that use the same UDT. It carries field hypotheses and their confidences forward, so later tests can concentrate on uncertain fields and extend the recovered definition. If detailed analysis links an execution anomaly to an inherited field, the Executor lowers that field’s confidence and reexamines its interpretation. Dynamic validation and knowledge reuse thus work together: execution supplies empirical evidence for refinement, while the knowledge base lets later functions build on and revise earlier hypotheses. This combination is particularly useful in Windows RPC, where functions without direct call relationships often access different parts of a shared UDT. B. Coverage Boundary and Heuristic Robustness Dynamic validation requires a suitable execution environment for the target function. On RealType, emulation succeeds in 83.8% of cases. In the remaining 16.2%, emulation fails because of runtime-environment problems, such as missing .so dependencies, even though their source code compiles successfully. These cases use static-only analysis and remain in the evaluation, so their results contribute to the reported accuracy. Programs whose source code cannot be compiled are excluded before evaluation. Even when execution is possible, a greater depth can cause EDH to favor an incorrect input if that input enters an error path covering many blocks. Counting each block once within the target module limits the influence of repeated execution and external library internals, but application-level error paths can still reach more blocks. EDH’s behavior summary helps the Executor interpret this depth preference. Figure 8 shows that correct mutations increase depth in 82.4% of RealType cases, while incorrect mutations decrease it in 62.2%. The 9.7% misdirection rate arises when incorrect mutations enter deeper application-level error paths. LOHRE reexamines and

Depth ↑

Depth =

Depth ↓ 6.8% 10.9%

Correct mutation

82.4%

Incorrect mutation

28.0%

62.2%

9.7%

25%

50%

75%

100%

Fig. 8. Distribution of paired-run depth changes on RealType.

corrects the affected hypotheses in 1.61 refinement iterations on average. For the 28.0% of incorrect mutations with unchanged depth, the Executor uses the behavior summary and relevant static code to guide further refinement. When a field affects data without changing control flow, its observed uses can still constrain its type, although they may not establish the precise source declaration [24]. For unaccessed fields, neighboring accesses may reveal an interior gap without identifying its constituent members. Unaccessed trailing fields may leave no evidence of their extent. Coverage also limits parameter and return-value recovery: unused parameters may be omitted from recovered signatures, and the single-path return-value analysis in Section IV-C can miss alternative return points. Even when the relevant behavior is observed, recovered names may describe a field’s role while differing from its source identifier, affecting UDT Nominal accuracy under exact-match scoring. The artifact presents these recovery cases. C. Threats to Validity The evaluation measures exact agreement with reference names and types, so semantically equivalent names can still be scored as incorrect. The user study complements these metrics with practitioners’ judgments of the documentation, and Fleiss’ κ characterizes agreement among their ratings. The eight repeated runs use a fixed DeepSeek-V4-Flash model. The observed standard-deviation bound (≤ 3.4 pp) therefore describes run-to-run variation only under this configuration. A different model checkpoint or decoding configuration may change variability. The datasets cover complementary settings but impose limits on generalization. RealType excludes Microsoft APIs, although overlap with model training data remains possible. Its four optimization levels share one source corpus and compiler, so they test optimization robustness rather than corpus diversity. Windows RPC draws on Microsoft Open Specifications to cover a representative range of protocol components. Dynamic validation is available for the 83.8% of RealType cases in which emulation succeeds. The remaining 16.2% use staticonly analysis and remain in the evaluation. VI. R ELATED W ORK LLMs support program understanding and security analysis [30–35], with approaches ranging from interactive query-

ing [36] to agent-based orchestration [37–39]. Automated testing complements this analysis by generating and selecting inputs that expose program behavior [2, 40, 41]. LOHRE connects analysis orchestration with test generation in a hypothesize-validate-refine loop: paired runs challenge UDT hypotheses, and EDH summarizes feedback for refinement. For code reconstruction, neural decompilation recovers high-level source code from binaries [5, 42], with extensions for particular platforms and deobfuscation [43–45]. Other methods improve decompiler output through identifier recovery, commenting, and restructuring [12, 46–50], or jointly recover code and data structures [3, 51, 52]. CLAP aligns assembly with natural-language explanations [53], while LLM Compiler learns assembly and compiler intermediate representations [54]. Both show how useful semantics can be inferred from low-level code. These advances make binaries easier to interpret, but plausible static predictions can still contain incorrect layouts [14]. Type-recovery methods complement code reconstruction through constraint-based inference [55–57], probabilistic and neural techniques [50, 58–62], and structure inference from observed executions [63, 64]. For quantitative comparison, we evaluate LOHRE against ReSym [4], Idioms [3], and LLM4Decompile [5] because runnable implementations are available for our corpus. TypeForge [11] ranks constraintgenerated types with an LLM but requires decompiler-inferred standard-library signatures unavailable in our setting. Idioms also reports that TypeForge cannot run on the RealTypederived corpus [3]. HyRES [13] supplies LOHRE’s aggregation heuristics, but its public artifact underspecifies normalization, constraint rules, and aggregation settings, preventing a controlled comparison. In modular binaries, a shared UDT may be accessed by functions without direct call relationships, leaving each function with only part of the layout evidence. LOHRE therefore aggregates evidence across these functions and uses execution to refine the resulting UDT hypotheses. It carries field confidences forward to focus testing on uncertain fields and revisits inherited hypotheses when execution analysis reveals conflicts. VII. C ONCLUSION We presented LOHRE, an LLM-orchestrated hybrid analysis framework for execution-grounded type recovery. In LOHRE, paired dynamic slice emulation tests candidate UDT layouts, EDH compresses the resulting execution feedback, and a cross-function knowledge base consolidates compatible evidence. Across RealType and Windows RPC, LOHRE achieves UDT Structural accuracies of 57.85% and 35.6%, respectively, outperforming the evaluated static baselines by 2.47–4.18× and 2.68–16.18×. A practitioner study (Fleiss’ κ 0.56–0.65) indicates that the documentation is perceived as useful. The EDH ablation further shows that compressed feedback supports higher recovery accuracy and lower token use and runtime than full execution traces. Future work will extend EDH’s field behavior summaries to cover external library implementations and evaluate portability across additional LLMs and architectures. The hypothesize-validate-refine

loop could also support function-prototype or protocol-state recovery when candidate interpretations can be tested through observable behavior. R EFERENCES [1] Y. Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, A. Dutcher, J. Grosen, S. Feng, C. Hauser, C. Kruegel, and G. Vigna, “SoK: (State of) The Art of War: Offensive Techniques in Binary Analysis,” in Proceedings of the 2016 IEEE Symposium on Security and Privacy, 2016, pp. 138–157. [2] P. Srivastava and M. Payer, “Gramatron: effective grammar-aware fuzzing,” in Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2021, pp. 244–256. [3] L. Dramko, C. Le Goues, and E. J. Schwartz, “Idioms: A simple and effective framework for turbo-charging local neural decompilation with well-defined types,” in Proceedings of the 33rd Network and Distributed System Security Symposium, 2026. [4] D. Xie, Z. Zhang, N. Jiang, X. Xu, L. Tan, and X. Zhang, “Resym: Harnessing llms to recover variable and data structure symbols from stripped binaries,” in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 4554–4568. [5] H. Tan, Q. Luo, J. Li, and Y. Zhang, “LLM4Decompile: Decompiling binary code with large language models,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024, pp. 3473–3487. [6] A. Modarressi, H. Deilamsalehy, F. Dernoncourt, T. Bui, R. A. Rossi, S. Yoon, and H. Schuetze, “NoLiMa: Long-Context Evaluation Beyond Literal Matching,” in Proceedings of the 42nd International Conference on Machine Learning, 2025, pp. 44 554–44 570. [7] Y. Du, M. Tian, S. Ronanki, S. Rongali, S. B. Bodapati, A. Galstyan, A. Wells, R. Schwartz, E. A. Huerta, and H. Peng, “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval,” in Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Findings of the Association for Computational Linguistics, 2025, pp. 23 281–23 298. [8] M. Gao, Z.-C. Chen, and K.-H. Huang, “The First Drop of Ink: Nonlinear Impact of Distracting Information in Long-Context Reasoning,” in Proceedings of the 43rd International Conference on Machine Learning, 2026, pp. 33 019–33 038. [9] W. Zeng, Y. Huang, and J. He, “LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth,” in Proceedings of the 43rd International Conference on Machine Learning, 2026, pp. 153 347–153 363. [10] H. Kim, “Defensive m2s: Training guardrail models on compressed multi-turn conversations,” https://arxiv.org/abs/2601.00454, 2026. [11] Y. Wang, R. Liang, Y. Li, P. Hu, K. Chen, and B. Zhang, “TypeForge: Synthesizing and Selecting Best-Fit Composite Data Types for Stripped Binaries,” in Proceedings of the 2025 IEEE Symposium on Security and Privacy, 2025, pp. 2847–2864. [12] P. Hu, R. Liang, and K. Chen, “DeGPT: Optimizing Decompiler Output with LLM,” in Proceedings of the 2024 Network and Distributed System Security Symposium, 2024. [13] Z. Sha, H. Shu, H. Wang, Z. Gao, Y. Lan, and C. Zhang, “HyRES: Recovering Data Structures in Binaries via Semantic Enhanced Hybrid Reasoning,” ACM Transactions on Software Engineering and Methodology, vol. 35, pp. 1–28, 2026. [14] X. Hu, Z. Fu, S. Xie, S. H. H. Ding, and P. Charland, “SoK: Potentials and Challenges of Large Language Models for Reverse Engineering,” https://arxiv.org/abs/2509.21821, 2025. [15] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics, vol. 12, pp. 157–173, 2024. [16] “Model Context Protocol Specification,” https://modelcontextprotocol. io/specification/2025-06-18, accessed in 2026. [17] Z. Li, X. Zhang, Y. Zhang, D. Long, P. Xie, and M. Zhang, “Towards general text embeddings with multi-stage contrastive learning,” https: //arxiv.org/abs/2308.03281, 2023. [18] “Microsoft Open Specifications: RPC,” https://learn. microsoft.com/en-us/openspecs/windows protocols/ms-doco/ 711ba788-aa2d-432b-a863-957137b3d6d4, accessed in 2026. [19] “Microsoft Public Symbol Server,” https://learn.microsoft.com/ en-us/windows-hardware/drivers/debugger/microsoft-public-symbols, accessed in 2026.

[20] “Public and Private Symbols,” https://learn.microsoft.com/en-us/ windows-hardware/drivers/debugger/public-and-private-symbols, accessed in 2026. [21] “Windows API Reference,” https://learn.microsoft.com/en-us/windows/ win32/api/, accessed in 2026. [22] “Microsoft Interface Definition Language,” https://learn.microsoft.com/ en-us/windows/win32/midl/midl-start-page, accessed in 2026. [23] “RPC NDR Engine,” https://learn.microsoft.com/en-us/windows/win32/ rpc/rpc-ndr-engine, accessed in 2026. [24] J. Bosamiya, M. Woo, and B. Parno, “TRex: Practical type reconstruction for binary code,” in Proceedings of the 34th USENIX Security Symposium, 2025, pp. 6897–6915. [25] “Ghidra,” https://ghidra-sre.org, accessed in 2026. [26] “Qiling Framework,” https://github.com/qilingframework/qiling, accessed in 2025. [27] DeepSeek-AI, “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence,” https://arxiv.org/abs/2606.19348, 2026. [28] “DeepSeek Harness,” https://github.com/deepseek-ai/deepseek-harness, accessed in 2026. [29] “Claude Sonnet 4.6 System Card,” https://www.anthropic.com/ claude-sonnet-4-6-system-card, accessed in 2026. [30] H. Jelodar, S. Bai, P. Hamedi, H. Mohammadian, R. Razavi-Far, and A. Ghorbani, “Large Language Model (LLM) for Software Security: Code Analysis, Malware Analysis, Reverse Engineering,” https://arxiv. org/abs/2504.07137, 2025. [31] D. Lea, J. Ghawaly, G. Richard III, A. Ali-Gombe, and A. Case, “REx86: A Local Large Language Model for Assisting in x86 Assembly Reverse Engineering,” in Proceedings of the 41st IEEE Annual Computer Security Applications Conference, 2025, pp. 108–122. [32] Z. Sha, H. Wang, Z. Gao, H. Shu, B. Zhang, Z. Wang, and C. Zhang, “llasm: Naming functions in binaries by fusing encoder-only and decoder-only LLMs,” ACM Transactions on Software Engineering and Methodology, vol. 34, pp. 1–22, 2025. [33] N. Hussain, H. Chen, C. Tran, P. Huang, Z. Li, P. Chugh, W. Chen, A. Kundu, and Y. Tian, “VulBinLLM: LLM-powered Vulnerability Detection for Stripped Binaries,” https://arxiv.org/abs/2505.22010, 2025. [34] Y. Zhang, Z. Xu, Z. Lang, C. Liu, Y. Sun, W. Guo, C. Liu, W. Sun, and Y. Liu, “Binstruct: Binary structure recovery combining static analysis and semantics,” in Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering, 2025, pp. 648–660. [35] P. Liu, C. Sun, Y. Zheng, X. Feng, C. Qin, Y. Wang, Z. Xu, Z. Li, P. Di, Y. Jiang, and L. Sun, “LLM-Powered Static Binary Taint Analysis,” ACM Transactions on Software Engineering and Methodology, vol. 34, pp. 1–36, 2025. [36] H. Pearce, B. Tan, P. Krishnamurthy, F. Khorrami, R. Karri, and B. Dolan-Gavitt, “Pop Quiz! Can a Large Language Model Help with Reverse Engineering?” https://arxiv.org/abs/2202.01142, 2022. [37] G. Chen, H. Sun, D. Liu, Z. Wang, Q. Wang, B. Yin, L. Liu, and L. Ying, “ReCopilot: Reverse Engineering Copilot in Binary Analysis,” https://arxiv.org/abs/2505.16366, 2025. [38] M. Shao, H. Xi, N. Rani, M. Udeshi, V. S. C. Putrevu, K. Milner, B. Dolan-Gavitt, S. K. Shukla, P. Krishnamurthy, F. Khorrami, R. Karri, and M. Shafique, “CRAKEN: Cybersecurity LLM agent with knowledge-based execution,” https://arxiv.org/abs/2505.17107, 2025. [39] “DAILA: Decompiler Artificial Intelligence Language Assistant,” https: //github.com/mahaloz/DAILA, accessed in 2026. [40] W. Zhang, J. Chen, S. Cai, K. Wang, Y. Liu, and H. Ding, “A novel seed scheduling scheme using Thompson sampling for coverage-guided greybox fuzzing,” Journal of Systems and Software, vol. 236, p. 112794, 2026. [41] C. Cui, Y. Huang, R. Huang, L. Zhou, R. Wang, and T. Li, “A novel vision-based approach to test sequence generation for mobile GUI testing,” IEEE Transactions on Reliability, vol. 75, pp. 664–678, 2026. [42] N. Jiang, C. Wang, K. Liu, X. Xu, L. Tan, X. Zhang, and P. Babkin, “Nova: Generative Language Models for Assembly Code with Hierarchical Attention and Contrastive Learning,” in Proceedings of the 13th International Conference on Learning Representations, 2025. [43] X. She, Y. Zhao, and H. Wang, “WaDec: Decompiling WebAssembly using large language model,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 481–492. [44] J. Liu, J. Lin, H. Liu, Y. Wang, and J. Jing, “ARMQwen2: Enhancing C Language Decompilation on ARM Platform Using Large Language Model,” in Proceedings of the 21st International Conference on Intelligent Computing, 2025, pp. 221–234. [45] B. Choi, H. Jin, D. H. Lee, and W. Choi, “ChatDEOB: An Effective Deobfuscation Method Based on Large Language Model,” in Pro-

ceedings of the 25th International Conference on Information Security Applications, 2025, pp. 151–163. [46] X. Xu, Z. Zhang, Z. Su, Z. Huang, S. Feng, Y. Ye, N. Jiang, D. Xie, S. Cheng, L. Tan, and X. Zhang, “Unleashing the Power of Generative Model in Recovering Variable Names from Stripped Binary,” in Proceedings of the 32nd Network and Distributed System Security Symposium, 2025. [47] G. Li, X. Shang, S. Cheng, J. Zhang, L. Hu, X. Zhu, W. Zhang, and N. Yu, “Pseudofix: Refactoring distorted structures in decompiled c pseudocode,” in Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering, 2025, pp. 841–853. [48] J. Lacomis, P. Yin, E. J. Schwartz, M. Allamanis, C. Le Goues, G. Neubig, and B. Vasilescu, “DIRE: A neural approach to decompiled identifier naming,” in Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering, 2019, pp. 628–639. [49] K. K. Pal, A. P. Bajaj, P. Banerjee, A. Dutcher, M. Nakamura, Z. L. Basque, H. Gupta, S. A. Sawant, U. Anantheswaran, Y. Shoshitaishvili, A. Doupé, C. Baral, and R. Wang, “‘len or index or count, anything but v1’: Predicting variable names in decompilation output with transfer learning,” in Proceedings of the 2024 IEEE Symposium on Security and Privacy, 2024, pp. 4069–4087. [50] Q. Chen, J. Lacomis, E. J. Schwartz, C. Le Goues, G. Neubig, and B. Vasilescu, “Augmenting decompiler output with learned variable names and types,” in Proceedings of the 31st USENIX Security Symposium, 2022, pp. 4327–4343. [51] W. K. Wong, D. Wu, H. Wang, Z. Li, Z. Liu, S. Wang, Q. Tang, S. Nie, and S. Wu, “DecLLM: LLM-Augmented Recompilable Decompilation for Enabling Programmatic Use of Decompiled Code,” Proceedings of the ACM on Software Engineering, vol. 2, pp. 1841–1864, 2025. [52] Y. Feng, B. Li, X. Shi, Q. Zhu, and W. Che, “ReF Decompile: Relabeling and Function Call Enhanced Decompile,” https://arxiv.org/ abs/2502.12221, 2025. [53] H. Wang, Z. Gao, C. Zhang, Z. Sha, M. Sun, Y. Zhou, W. Zhu, W. Sun, H. Qiu, and X. Xiao, “CLAP: Learning Transferable Binary Code Representations with Natural Language Supervision,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 503–515. [54] C. Cummins, V. Seeker, D. Grubisic, B. Roziere, J. Gehring, G. Synnaeve, and H. Leather, “LLM Compiler: Foundation Language Models for Compiler Optimization,” in Proceedings of the 34th ACM SIGPLAN International Conference on Compiler Construction, 2025, pp. 141–153. [55] J. Lee, T. Avgerinos, and D. Brumley, “TIE: Principled reverse engineering of types in binary programs,” in Proceedings of the 18th Network and Distributed System Security Symposium, 2011. [56] M. Noonan, A. Loginov, and D. Cok, “Polymorphic type inference for machine code,” in Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation, 2016, pp. 27– 41. [57] I. Smith, “BinSub: The simple essence of polymorphic type inference for machine code,” in Proceedings of the 31st International Static Analysis Symposium, 2025, pp. 425–450. [58] Z. Zhang, Y. Ye, W. You, G. Tao, W.-c. Lee, Y. Kwon, Y. Aafer, and X. Zhang, “Osprey: Recovery of variable and data structure via probabilistic analysis for stripped binary,” in Proceedings of the 2021 IEEE Symposium on Security and Privacy, 2021, pp. 813–832. [59] Z. Zhuo and X. Zhang, “Beyond C/C++: Probabilistic and LLM methods for next-generation software reverse engineering,” https://arxiv.org/abs/ 2506.03504, 2025. [60] C. Zhu, Z. Li, A. Xue, A. P. Bajaj, W. Gibbs, Y. Liu, R. Alur, T. Bao, H. Dai, A. Doupé, M. Naik, Y. Shoshitaishvili, R. Wang, and A. Machiry, “TYGR: Type inference on stripped binaries using graph neural networks,” in Proceedings of the 33rd USENIX Security Symposium, 2024, pp. 4283–4300. [61] J. He, P. Ivanov, P. Tsankov, V. Raychev, and M. Vechev, “Debin: Predicting debug information in stripped binaries,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 1667–1680. [62] G. Li, X. Shang, S. Cheng, J. Zhang, L. Hu, X. Zhu, W. Zhang, and N. Yu, “Beyond the edge of function: Unraveling the patterns of type recovery in binary code,” ACM Transactions on Software Engineering and Methodology, 2026. [63] Z. Lin, X. Zhang, and D. Xu, “Automatic reverse engineering of data structures from binary execution,” in Proceedings of the Network and Distributed System Security Symposium, 2010. [64] A. Slowinska, T. Stancescu, and H. Bos, “Howard: A dynamic excavator for reverse engineering data structures,” in Proceedings of the Network and Distributed System Security Symposium, 2011.

LOHRE: Execution-Grounded Type Recovery via LLM-Orchestrated Hybrid Analysis

Analyze & explore related research in Conceptio

Related documents