refs
Tool
tools/triage/refs.py(program, Triage). List every instruction that refers to an address.
Run it with ./gameframe run refs ARGS or python3 tools/triage/refs.py. Source on GitHub.
Its own help
This is the help text in the tool itself, as ./gameframe tool refs prints it.
text
List every instruction that refers to an address. The search reads the raw code bytes, so it
finds hits in any function or in none. Each hit says whether the instruction reads the address,
writes it or takes it as a value.
Usage: refs.py BINARY ADDRESS [ADDRESS ...] [--near N] [--functions functions.tsv] [--json]
BINARY a Windows PE, 32-bit or 64-bit (its executable sections)
ADDRESS a virtual address, such as 0x61aad0 (a table, a global, a function)
--near N also find ADDRESS - N to ADDRESS + N, which loops and fields use (default 0;
8 finds `[table + 4]` and `[table - 4]`)
--functions a Ghidra export's functions.tsv, to name the function each hit is in; a hit in
no function is marked `(no function)`, which is code the export missed
Why: a search of the decompiled text finds only the code Ghidra made functions for. A linear
disassembly stops at the first data inside a code section. Neither can prove "only this
function writes that table". This tool searches the bytes themselves. In 32-bit code it finds
the address as a 32-bit immediate or displacement. In 64-bit code it also finds it as a
RIP-relative displacement. Each hit is decoded backwards, one to ten bytes, until an
instruction holds that operand, so the result does not depend on where a disassembly started.
Output: one line per instruction: its address, read, write or value (an immediate: the address
taken, pushed or compared), the instruction, and the function. Then the count.
It cannot find an address built at run time (a base plus a computed index) or held in data.
`tools/pe/relocs.py` lists the pointers in data. A hit can be data that happens to decode as an
instruction, so check each hit in Ghidra. Needs capstone (.venv).