Skip to main content

Module jump_table

Module jump_table 

Source
Expand description

Build a subsecond::JumpTable from old vs new symbol tables.

This is the diffing brain of Tier 1: given the original binary’s symbols and the freshly-linked patch dylib’s symbols, walk the ones that exist in both and produce the address-to-address map that subsecond::apply_patch will use to rewrite call sites.

What we don’t try to do here:

  • Resolve undefined symbols. Those have address 0 in either side; including them would lie to the runtime.
  • Touch data symbols. Hot-patching globals would race the program, which is harder than function hot-patching and not on the I4g critical path.
  • Touch zero-sized symbols. These are typically PLT stubs and compiler-introduced markers; no actual code to swap.
  • Special-case weak symbols. They get a warning so the dev loop can surface ambiguity, but the entry is still emitted — subsecond will pick whichever the dynamic linker chose.

Structs§

DiffReport
Names of symbols that exist in old and were dropped in new. Reported alongside the JumpTable so the dev loop can warn the user that calls into one of those would crash after a patch.
PatchPlan
Result of build_jump_table: the subsecond payload + a human-readable diff summary.

Functions§

build_jump_table
Compose a JumpTable from old (the live binary’s symbol table, parsed once and cached) and new (the freshly-built patch dylib’s symbol table). new_lib is the on-device path the runtime will dlopen; aslr_reference and new_base are what subsecond uses to correct for ASLR slide.