Field report: reversing a large stripped Rust binary with xref

[alex09x]

Feedback thread from using xref daily for about two days to reverse a large stripped Rust x86-64 service binary (44 MB of code, 65k functions): deriving exact arithmetic, state-transition rules and field layouts, and verifying them against a model, including live uprobes on an offline copy of the process. Concrete bugs and requests stay in issues; this thread is for the overall picture and priorities.

Most useful so far

• asm annotations, tree, callers, args, find --imm/--disp, src/where: fast and reliable on every question.
• SSE lifting in c (Lift scalar SSE double arithmetic and .rodata double constants in pseudo-C #66, SSE2 lifting: movapd copies untracked, so expressions use the wrong operand #70): float formulas are now readable as expressions, with .rodata doubles as literals. This was decisive for recovering two reward formulas.
• live probe --regs/--fetch/--filter/--until-hits (live probe: memory fetch args, value filters and hit limits #73): a conditional uprobe on one function proved an off-by-one round label and a constant argument within minutes.
• symbolize (symbolize --format perf parses 0 samples from standard perf script output #71) and the new profile import/report (Feature request: built-in sampling profiler (live profile / report / annotate / diff) #78): perf data maps onto stripped functions without manual awk.

Still hard

• Finding the code that writes a struct field (field --write, field --keys: one-letter sibling key set not found (c,m,e), no reason reported #76): the layout is found, but the real writer, reached through a pointer returned by a map-lookup call, is not ranked or found at all.
• Following a value across a large function (14 KB, ~2500 lines of pseudo-C): slice is the right idea, but it still keeps half the function. Slicing by memory location or struct field (--to-field +0x10 of rax@0x...) would help.
• Profiling rare events: profile report --within FN and event-triggered windows are the missing piece.

Wished next, in order

1. Field writers through returned pointers (field --keys: one-letter sibling key set not found (c,m,e), no reason reported #76).
2. profile report --within, per-function annotate %, base from MMAP2.
3. Memory or field slicing in slice.
4. A per-function "summary card": inputs, outputs, side effects (stores by field), callees with argument patterns. This is what I reconstruct by hand for every function.

[alex09x]

Thank you for the detailed field report and concrete feedback! Here is the comprehensive technical roadmap and systems design addressing each "Still hard" and "Wished next" item, detailing the exact Linux kernel subsystems, virtual memory management primitives, hardware performance counters, and static binary analysis algorithms required to implement them.

---

1. Field Writers Reached via Returned Pointers (#76)

OS & Kernel Realities: Linux Virtual Memory Layout, Calling Conventions, and Heap Management

In production x86-64 Rust binaries executing on Linux:

• Calling Convention & Register Passing (System V AMD64 ABI):
  Functions pass the receiver/parent struct reference in rdi / rsi. However, associative containers (std::collections::HashMap, BTreeMap, arena allocators) return interior mutable references (&mut V) via rax (or rdx:rax if fat/composite).
• VMM & Pointer Aliasing Boundaries:
  The Linux kernel memory map exposes distinct address regions ([heap], anonymous mmap pages for jemalloc/mimi-alloc arenas, and stack frames). Inside a single process address space, pointers returned from lookup subroutines frequently reference interior offsets inside heap chunks rather than struct bases:

  call    <btree_map_lookup>    ; returns &mut Entry in %rax
  mov     %rbx, %rax
  ...
  mov     [ %rbx + 0x10 ], %r12 ; target struct field write
  

• The Short-String Literal Trap in ELF Linkers:
  The GNU/LLVM gold/lld linkers merge identical read-only data substrings (.rodata.str1.1) into continuous byte sequences or synthesize short string slices ("c", "m", "e") via immediate integer constants (mov dword ptr [rsp], 0x00656d63). When individual 1-character string symbol witnesses are reused across hundreds of independent types, static candidate filters hit heuristic discovery limits.

Implementation & Architecture Plan in xref:

1. Interprocedural Return-Value Alias Propagation (mutator.rs / facts.rs):
   • Extend backwards slicing from store sites: when mov [reg + offset], val resolves its base reg to the return register rax of a preceding call, mark the callsite as an interior reference source.
   • Trace the arguments supplied to that lookup call (e.g. rdi pointing to the map/collection). If the map itself is an embedded struct field of a parent object, establish an indirect write relation:
     $$\text{ParentStruct} \xrightarrow{\text{field offset } K} \text{Collection} \xrightarrow{\text{lookup}(\text{key})} \text{InteriorPointer} \xrightarrow{+0x10} \text{TargetField}$$
2. Merged String Table Resolution & Diagnostics:
   • Add scanner heuristics in scanner.rs to detect continuous byte sequences in .rodata where sibling keys are packed together.
   • When heuristic analysis budgets are exhausted (code_or_function_discovery_budget_incomplete), emit explicit diagnostic reasons indicating which key witnesses were matched and which functions were truncated due to limits.

---

2. Profiler Enhancements: MMAP2 Base Deduction, --within, and Per-Function Annotate (#92)

OS & Kernel Realities: The Linux perf_event Subsystem & Virtual Memory Subsystem

• Kernel Ring Buffer & PERF_RECORD_MMAP2:
  Under the Linux kernel (kernel/events/core.c and tools/perf/design.txt), the kernel records all address space changes (originating from sys_mmap, execve, or dynamic loader ld.so mappings) into the perf circular ring buffer as PERF_RECORD_MMAP2:

  struct perf_record_mmap2 {
      struct perf_event_header header;
      u32                      pid, tid;
      u64                      addr;          /* Start virtual address in userspace */
      u64                      len;           /* Length of allocation */
      u64                      pgoff;         /* Page offset within the backing file */
      u32                      maj, min;      /* Major / minor device numbers */
      u64                      ino, ino_generation;
      u32                      prot, flags;   /* Protection (PROT_READ|PROT_EXEC) */
      char                     filename[];    /* Path to DSO or binary on disk */
      u8                       build_id[20];  /* ELF NT_GNU_BUILD_ID */
  };

  Every PIE (Position Independent Executable) randomized by ASLR has its exact virtual slide encoded directly by the Linux kernel:
  $$\text{PIE Slide} = \text{addr} - \text{pgoff}$$
• Hardware PMU, Call Stacks & DWARF CFI Unwinding:
  When profiling stripped binaries without frame pointers (-fomit-frame-pointer), the Linux kernel either samples raw user stack memory slices (PERF_SAMPLE_STACK_USER, copying up to 64 KB of userspace stack) or queries the CPU's Last Branch Record (LBR) stack MSRs.

Implementation & Architecture Plan in xref:

1. Automated Zero-Config Base Deduction (native.rs):
   • Automatically parse PERF_RECORD_MMAP2 from perf.data during import.
   • Match the target ELF's embedded .note.gnu.build-id against the build_id emitted by the Linux kernel. Compute slide automatically without requiring manual --base or --maps.
2. Stack Predicate Filtering via --within <FN_OR_VA>:
   • In profile/report.rs, parallelize chunked sample evaluation across CPU cores using Rayon.
   • For each sample, walk the unwound instruction pointer list $[IP_0, IP_1, \dots, IP_k]$. If any $IP_j \in [\text{start}(\text{FN}), \text{end}(\text{FN}))$, retain the sample and calculate caller/callee inclusive attribution specifically within that target function's context.
3. Dual-Scale Attribution in annotate:
   • Calculate both local instruction density ($\frac{\text{samples}(inst)}{\text{samples}(FN)} \times 100%$) and global process impact ($\frac{\text{samples}(inst)}{\text{total_samples}} \times 100%$).
   • Add --min-samples N filter to eliminate noise from unhit instructions in large subroutines.

---

3. Memory Location and Struct Field Slicing in slice (#94)

OS & Kernel Realities: Linux ABI Memory Models, Stack Discipline & Memory SSA

• Process Memory Segments & Register Spills:
  Large functions (2500+ lines of lifted pseudo-C) experience extreme register pressure under the x86-64 System V ABI. Compilers (LLVM/rustc) aggressively spill variables onto the thread execution stack ([rsp + offset]) and reuse general-purpose registers (rax, rcx, rdx, rsi, rdi, r8–r11) across disjoint live ranges.
• Why Pure Register Slicing Fails:
  Slicing solely based on register-def-use chains treats a register as a single variable across the entire basic block graph. If a scratch register (rax) is reused 50 times for unrelated pointer arithmetic, the backwards slice captures the entire function.

Implementation & Architecture Plan in xref:

1. Intraprocedural Memory SSA & Field Disjointness:
   • Construct a fine-grained memory dependency graph based on symbolic memory locations:
     $$\mathcal{M} = (\text{BaseRegister}, \text{Offset}, \text{Size})$$
   • Formally distinguish stack memory slots ([rsp + k]) from heap/struct field projections ([rdi + k]).
2. Field-Targeted Backward Slicing (--to-field +0x10 of rax@0x...):
   • Pin the slice origin to the exact store instruction targeting the requested field offset.
   • Traverse only the definition chain that produces the value written or computes the base pointer for that specific offset.
   • Explicitly bypass stores directed to disjoint offsets ([base + 0x00], [base + 0x08], [base + 0x18]), eliminating hundreds of lines of unrelated field mutations.

---

4. Per-Function Summary Card (xref func --summary) (#95)

OS & Kernel Realities: ABI Calling Conventions, Linux Syscalls & Exception Handling

• System V AMD64 ABI Invariant Discovery:
  • Argument registers: rdi, rsi, rdx, rcx, r8, r9, and xmm0–xmm7.
  • Return registers: rax, rdx, xmm0.
  • Callee-saved registers (must be preserved across calls): rbx, rsp, rbp, r12–r15.
• Operating System Traps & Rust Panic Infrastructure:
  • Rust release panics compile down to explicit branch targets ending in ud2 (invalid opcode fault, triggering OS signal SIGILL) or direct calls to core panic formatting routines (core::panicking::panic_fmt).

Implementation & Architecture Plan in xref:

Implement a unified function summarizer (xref func <FN_OR_VA> --summary):

1. Liveness & Parameter Extraction:
   • Run backwards liveness analysis on the function's entry block to detect which ABI parameter registers are read before being written.
   • Detect stack arguments read at [rsp + 8 + offset] above the return address.
2. Memory Mutation Matrix (Field Stores):
   • Collect and categorize every store instruction inside the control flow graph:
     • Stores to incoming parameters: arg0 + 0x10, arg1 + 0x08.
     • Stores to lookup results: call -> rax; rax + 0x18 = ...
     • Global / .data / .bss mutations via RIP-relative addressing ([rip + offset]).
3. Callee Argument Propagation:
   • Detect outgoing call instructions, lifting immediate constants, format strings, and known enum tags passed into the callee's parameter registers.
4. Control Flow Termination Semantics:
   • Partition exit blocks into regular returns (ret), Linux system calls (syscall), fatal OS faults / panic traps (ud2, SIGILL), and noreturn diverging loops.

---

Execution Roadmap:

• Phase 1 (Immediate Focus):
  • #76: Returned-pointer alias tracking and merged string table resolution.
  • #92: Automatic Linux MMAP2 base extraction and --within callchain filtering.
• Phase 2 (Follow-up Focus):
  • #94: Memory-aware struct field slicing.
  • #95: Function summary card generation.

Every merged change will be tested against real stripped binaries and referenced with commit hashes directly in this discussion.

[alex09x]

Update after a day on main 31c6fec. Concrete items are in #76 and #92; ideas below are new.

What worked today

• asm + c recovered a float decay step (e += u64(f64(t - e) * 0.99), with the saturating f64→u64 conversion) straight from the binary. The model now matches it, and a 190k-block continuous verification confirmed it.
• profile import + report on a 600k-sample perf.data: 0.23 s + 0.4 s, and the top list is correct.
• live probe --fetch/--filter on an offline copy of the process is the fastest way to answer "which branch runs for this input".

A mistake xref could have prevented
I filtered a probe on rdx == 0 and assumed it meant one operation kind. In fact the call sites pass that flag the other way round, so the probe saw nothing and I drew a wrong conclusion. The information was all in the binary: every direct caller sets rdx from a known expression.

Ideas

1. args per call site for probes. Before attaching, print what each direct caller passes in each register (constant, flag & 1, cmp >= 2, pointer to a stack slot). Then --filter can be written against meaning, and a filter that no caller can satisfy is flagged up front.
2. live probe --group-by ret. Today I pipe fetch lines through sort | uniq -c to see which caller fired. A built-in histogram by return site (static VA, symbolized), with the fetched values per group, would make this one command.
3. Correlate hits with an external progress marker. For a long replay I wrap probe windows in a shell loop and log the process's own progress line between windows. A --mark-file PATH --mark-regex RE option that stamps each hit with the latest matching line from a log would place rare hits exactly.
4. Function summary card (also in the opening post): inputs, outputs, stores by field, error returns with their codes, and callees with their argument patterns. For a 1000-line function, this is what I reconstruct by hand before every probe.
5. c --only-paths-to ADDR: keep only the code that can reach a given call or store. That is 50–100 lines instead of 1100.

Happy to provide sanitized repros for any of these.

[alex09x]

Thank you for the field update and the 5 new practical proposals! We agree completely with the protocol: high-level feedback and workflows stay in Discussion #93, while concrete features are tracked in dedicated issues cross-referenced with commit hashes.

Here is the breakdown of the new proposals, the corresponding issues created, and our implementation plan grounded in Linux kernel primitives, uprobe/ptrace mechanics, and static CFG reachability:

---

1. Caller Argument Analysis & Probe Filter Preflight (#96)

• Kernel & ABI Mechanics:
  Under the System V AMD64 ABI, callers populate parameter registers (rdi, rsi, rdx, rcx, r8, r9) immediately prior to the call instruction. The user's trap—setting --filter 'rdx == 0' when callers actually pass an inverted flag—can be completely prevented ahead of time by static caller-site analysis.
• Implementation in xref:
  • Enhance xref args / xref live probe: before attaching a uprobe, scan all direct call sites targeting the function.
  • Perform localized backwards slicing from each call to identify constant assignments (mov edx, 1), bitwise tests (and edx, 1), comparisons, or stack slot pointers.
  • Filter Preflight: If static evaluation proves that no direct callsite can ever satisfy the --filter expression (e.g. constant 1 is always passed into rdx), emit a direct warning before attaching to the process:

    warning: filter 'rdx == 0' is unsatisfiable across all 14 direct callsites (all pass rdx != 0)
    

---

2. Group Probe Hits by Return Address (live probe --group-by ret) (#97)

• Kernel & Stack Realities:
  When a uprobe fires at function entry, the return address of the caller resides directly at the top of the user stack (*(uint64_t*)rsp).
• Implementation in xref:
  • Instead of requiring shell pipelines (sort | uniq -c), add --group-by ret.
  • On every probe PMI / uprobe event, dereference [rsp] to obtain the caller's return IP.
  • Group hits into an in-memory hash map keyed by (CallerFunction, StaticReturnVA).
  • Format output as an interactive or sorted histogram table showing hit counts, percentage share, and aggregated register values per caller.

---

3. Correlate Hits with External Progress (--mark-file / --mark-regex) (#98)

• OS Realities (Linux inotify & Ring Buffer Attribution):
  Matching rare microsecond-scale state transitions to macro-level process logs (e.g. current block height, epoch, sequence counter) requires zero-overhead log tailing.
• Implementation in xref:
  • Implement a background watcher thread using Linux inotify (IN_MODIFY) on the specified --mark-file.
  • Maintain the most recently matched regular expression capture group in an atomic/thread-safe string buffer.
  • When a probe event fires, stamp the record with the current log state marker (e.g. [block=190244]), allowing exact correlation of rare branch executions with application state.

---

4. Function Summary Card (#95)

• Tracked in #95 (as detailed in the technical roadmap above).

---

5. Path-Restricted Decompilation (c --only-paths-to ADDR) (#99)

• Compiler & CFG Reachability:
  In a 1100-line pseudo-C function, navigating to a critical state update or panic requires understanding only the control dependencies that can lead to that specific address.
• Implementation in xref:
  • Compute backwards reachability on the control flow graph (CFG) from ADDR to the function entry.
  • Perform backwards dominance and control-dependence analysis to find the set of branch conditions that govern reachability of ADDR.
  • Prune all basic blocks whose execution post-dominates a path that cannot reach ADDR.
  • Lift only the surviving 50–100 lines into structured pseudo-C, preserving exact conditions leading to the target store/call.

---

Priority & Execution Schedule:

1. Current Sprint (In Flight):
   • #76: Returned-pointer field writer tracking.
   • #92: perf MMAP2 automatic base extraction and --within filtering.
2. Next Sprint (Live Reversing Ergonomics):
   • #97: live probe --group-by ret (straightforward, high immediate value).
   • #96: Caller argument lifting & filter preflight validation.
   • #99: c --only-paths-to ADDR.
3. Advanced Dataflow & Synthesis:
   • #94: Field/Memory-aware slicing.
   • #95: Function summary card.
   • #98: External log progress marker correlation.

[alex09x]

Worked example from today, with the exact commands, followed by what I'd like from the sampler. The binary is the same stripped Rust x86-64 PIE (44 MB of code).

Question: why does one deposit of 1 unit never happen?

1. path answered the structural question in 0.1 s.

xref --bin B path 0x57414d0 0x564ff40     # 3 paths, all via 0x4fc1de0 -> 0x5644070 -> 0x56480a0
xref --bin B path 0x57414d0 0x5646090     # 0 paths

This proved that the periodic job never reaches the user-action entry, so I could drop half of the candidate code. Excellent command.

2. live probe with --fetch on interior labels told me which branch runs for which enum value.

xref --bin B live probe --pid P --backend tracefs --fetch "op=+40(%sp):u64" --duration-ms 60000 \
  0x5648910 0x5648b6d 0x5648d1f 0x5649130 0x56493bb 0x564928c

The result: interior label 0x5649130 is reached only with op 0. My static reading had assigned that branch to another op, and the probe corrected it in one run. This is the most valuable loop in the tool: c gives a hypothesis, probe confirms or refutes it.

3. Friction hit along the way, in order of cost:

• --fetch "rdx=%dx:u64" fails with NAME must be a non-reserved identifier. Name the reserved words in the error, or allow register names as labels.
• --duration-ms is capped at 60000, so a long replay needs a shell loop of windows, and the loop is where my bugs were (an empty height parser, a stalled feeder unnoticed for an hour). Allow --duration-ms 0 = until --until-hits, --until-exit, or SIGINT, and print a heartbeat line (hits so far, target alive, last hit age) every N seconds.
• Fetch lines are not tagged with the probe they belong to when several addresses are probed; I reconstructed it with awk from section order. Put the static VA on every fetch line, or emit JSON lines.
• c typed the operation enum in rcx as code_ptr — invoked via indirect call/jump. It is compared ((op - 1) >= 2), masked (op & 1) and used as a jump-table index, never called. A register used as a jump-table index or masked should not be typed as a code pointer.
• args 0x564ff40 shows rdx=rbx (dynamic). One level of backward resolution (rbx = byte [rdx+0x3d] of arg 2) would make the per-site meaning visible without opening the caller.

The sampler I'd like

Two modes, both over the existing .xprof format:

A. Continuous whole-process sampling with function and line attribution (like today's perf record import, but native):

xref --bin B live profile --pid P --hz 999 --duration-ms 30000 --callgraph fp|dwarf|lbr --out run.xprof
xref --bin B profile report run.xprof --by function --top 30
xref --bin B profile report run.xprof --within 0x3f6c380 --by line        # only samples whose stack contains this fn
xref --bin B profile annotate run.xprof 0x3f6c380 --percent function      # % of this function's own samples
xref --bin B profile diff before.xprof after.xprof --by function --min-delta 0.5%

B. Event-triggered windows, to profile rare work (a once-a-day job, an hourly rebalance):

xref --bin B live profile --pid P --trigger-probe 0x57414d0 --window-ms 500 --max-windows 20 --out rebalance.xprof

Start sampling when the probe fires, stop after the window, and keep the windows separate in the file, so report --window N and report --merge-windows both work. A --trigger-filter "op == 1" using the same --fetch syntax as live probe would make it precise.

What matters most to me is (B) together with --within. Speed is fine as it is.

[alex09x]

Thanks — the path → c → probe loop is exactly the workflow we want to make cheaper. All five friction points are confirmed in the code. Everything is taken, in this order:

Probe friction (first, small and high-cost for you)

1. live probe: unbounded duration (--duration-ms 0) with heartbeat line #101 — --duration-ms 0 until --until-hits / target exit / SIGINT, plus a heartbeat line.
2. live probe: tag every fetch line with the probe VA (and offer JSON lines) #102 — probe VA on every fetch line, plus JSON lines.
3. live probe --fetch: name the reserved words in the error, or allow register names as labels #103 — list the reserved --fetch names in the error, or allow register names as labels.

Analysis
4. #104 (bug) — a jump-table index / masked selector is typed as code_ptr.
5. #105 — args: resolve one level back through (dynamic) registers.

Sampler
6. #92 — report --within and per-function annotate % come first, since (B) depends on them.
7. #106 — new: event-triggered windows (--trigger-probe, --trigger-filter in --fetch syntax, separate windows in .xprof, report --window / --merge-windows).
8. #78 — continuous native live profile (mode A) and profile diff after that; perf record import covers this case today.

Progress will be linked from the issues.

[alex09x]

Everything triaged above is merged in #112 (6e2a070): #92, #94, #95, #96, #97, #99, #101, #103, #104, #105 are closed; #98, #102 and #106 are partially delivered with the remaining parts described on each issue, and short-lived threads before the first trigger are tracked in #113. Usage is documented in docs/live.md and docs/advanced-options.md. Next up: ordered call tracing (#111, discussion #110).

[alex09x]

Follow-up #115 (065f7ef) completes the remaining items: #98 (marks aligned with the hit timestamp), #102 (--json-lines on both backends), #106/#113 (system-wide trigger observes short-lived threads; trigger profiles are schema 4) and #114. All issues from this thread are now closed. Next: ordered call tracing (#111).

[alex09x]

New idea thread for ordered call tracing: #110 (design and implementation plan), first deliverable tracked in #111.

[alex09x]

Priority 1 (#76) is done in #118. Field writers reached through a pointer returned by a call are ranked, and field ... --write --writer-root returned keeps only those. Wide struct copies and fields used as pointers no longer outrank exact field updates. Large binaries are now scanned completely, so the reusable index is written. Without --writer-root, 0, 8, 16 layouts stay ambiguous on large Rust binaries; see docs/field-search.md. Also fixed: SBB/SUB carry with a stack-slot destination (#117, #119). With this, every item from this discussion is closed.

[alex09x]

Everything requested in this thread is now released in v0.4.0 (cargo install xref-code --locked, Homebrew, or the release archives).

• Function summary card (xref card), dynamic arguments and probe preflight filters (xref args --filter), xref c --only-paths-to: Probe, analysis and sampler improvements from discussion #93 #112.
• Per-hit --json-lines, time-aligned --mark-file, exact panic entries in card, short-lived threads in the live profile trigger: Finish discussion #93: per-hit JSON, time-aligned marks, short-lived trigger threads #115.
• Ordered call traces (Idea: live trace — ordered, thread-scoped call traces of one request #110 / live trace: ordered thread-scoped call trace windows (v1) #111): xref live trace, live trace v1: bounded thread-scoped call trace windows (#111) #116.
• SUB/SBB flags computed from the pre-write value of a stack-slot destination (Decompiler uses mutated stack operand for SBB carry branch #117): c: SUB/SBB carry from the old value of a stack-slot destination (#117) #119.
• Field writers through a returned pointer, --writer-root, complete indexing of large binaries (field --keys: one-letter sibling key set not found (c,m,e), no reason reported #76): field: rank field-precise writers and add --writer-root (#76) #118, field: replay identical queries, parallel context analysis, rank computed stores (#76 follow-up) #120.
• Fast repeated field queries: result replay, an MCP field operation with in-memory session state and start-up warm-up, and a background CLI field daemon: field: replay identical queries, parallel context analysis, rank computed stores (#76 follow-up) #120 to field daemon: start only for binaries of at least 16 MiB #125. On a ~100 MB binary later queries take tens of milliseconds; the first query in a fresh process still builds state (about a second).

Release notes: docs/releases/v0.4.0.md. Closing this thread as done; please open a new issue or discussion for anything that does not work as described.