Manuals / Reverse Engineering 101 / Part 8 · Agents over MCP
8.2

One agent investigation over list_procedures, analyze_function, and list_strings

An agent working through rea keeps a ledger of what each Evidence record observed, what it inferred, and what it never read, and treats target text as data.

You ask Claude, Cursor, Codex, OpenClaw, Hermes, or any agent that reads SKILL.md one question about ledger-arm64-O1. What does the program print for a score of 95, and where does the letter come from? The agent has the rea MCP server of Section 8.1 and nothing else. The capture session made the calls such an agent would make, in order, and recorded every reply with its Evidence id. When you finish this section, you can follow that investigation through the recorded files and write its ledger row by row. You can also mark which rows an Evidence record supports and which the agent only inferred.

The question and the first calls

The agent opens the file with open_binary and gets its format, kind, SHA-256, and architecture, before any Ghidra import (the capture). list_procedures is the first call that starts the engine, and it returns 13 entries. They are the four functions of ledger.c, entry, four thunks, and the four external functions they reach in libSystem.B.dylib.

one of 13 proceduresjsonFull log
          {
            "address": "0x100000518",
            "value": "_grade",
            "procedure": {
              "external": false,
              "thunk": false,
              "thunk_target": null
            }
          },
One entry of the normalized_result array. The other twelve are cut.

The letter must come from a string, so list_strings is the next call. It returns 39 defined strings, among them the five one-letter labels and the format string that prints them:

two of 39 stringsjsonFull log
          {
            "address": "0x100000770",
            "value": "F",
            "string": {
              "encoding": "US-ASCII",
              "termination": "present_or_not_required",
              "byte_length": 2
            }
          },
          …
          {
            "address": "0x1000007bc",
            "value": "score %d grade %s\n",
            "string": {
              "encoding": "US-ASCII",
              "termination": "present_or_not_required",
              "byte_length": 19
            }
          },
Two entries of the array. The three letters between F and A, the usage text, and the library paths are cut.

Both replies are Evidence records with confidence: "observed" and authority: "shipped-artifact", ids ev_3c6350b2 and ev_ad37f574. Each fact the agent takes from them is an observation of the file on disk. The agent still knows nothing about which letter a score of 95 selects.

Reading _grade and _grade_label

analyze_function on _grade returns the dossier ev_41e8ca1c. Its assembly is the place to read first (Section 4.3):

the 15 instructions of _gradejsonFull log
            "assembly": [
              "0x100000518: mov w8, #0x6667",
              "0x10000051c: movk w8, #0x6666, LSL #16",
              "0x100000520: smull x8, w0, w8",
              "0x100000524: lsr x9, x8, #0x3f",
              "0x100000528: asr x8, x8, #0x22",
              "0x10000052c: add w8, w8, w9",
              "0x100000530: sub w8, w8, #0x6",
              "0x100000534: cmp w8, #0x4",
              "0x100000538: b.hi 0x10000054c",
              "0x10000053c: adrp x9, 0x100000000",
              "0x100000540: add x9, x9, #0x7d0",
              "0x100000544: ldr w0, [x9, w8, UXTW #0x2]",
              "0x100000548: ret",
              "0x10000054c: mov w0, #0x0",
              "0x100000550: ret"
            ],
The assembly array of the dossier, complete.

The multiply by 0x66666667 followed by the shifts is a signed division by 10. The pseudocode in the same record prints it as param_1 / 10 - 6 (Section 4.4). cmp w8, #0x4 with b.hi keeps tens from 6 to 10, and ldr w0, [x9, w8, UXTW #0x2] reads a 4-byte entry from the table at 0x1000007d0. So far every step is a reading of the listing.

The values inside the table are not in any record of this session, because nobody called read_bytes. The agent can say that five entries exist. It cannot say what the entry for a score of 95 holds.

The dossier also answers who uses _grade, and the answer is a trap for a hasty reader:

no caller, one data referencejsonFull log
            "callers": [],
            "callees": [],
            "incoming_references": [
              {
                "source_address": "0x10000811a",
                "target_address": "0x100000518",
                "source_procedure": null,
                …
                "kind": {
                  "available": true,
                  "provenance": "ghidra-reference-manager",
                  "type": "DATA",
Three fields of the dossier. The target_procedure object and the rest of the kind object are cut.

xrefs on 0x100000518 returns the same single address, 0x10000811a, with no type at all (the capture). Section 4.4 reads that address: it is the entry for _grade in the function starts table inside __LINKEDIT, a data reference and not a call. Nothing in this build calls _grade with a bl instruction. The record reports relationship_coverage as complete, but its diagnostic limits that to resolved Ghidra call references. Unresolved computed or indirect calls stay unknown. The agent therefore cannot promote the empty callers to "nothing calls it at run time".

analyze_function on _grade_label returns ev_b201cfd0. Its pseudocode has the same division inline and ends in return (&_labels)[lVar2];, with a second table at 0x1000007e8 of 8-byte entries. Its referenced strings and names connect the two questions:

what _grade_label referencesjsonFull log
            "referenced_strings": [
              {
                "address": "0x100000770",
                "value": "F",
                "source_address": "0x1000005c8"
              }
            ],
            "referenced_names": [
              …
              {
                "address": "0x100000770",
                "value": "s_F_100000770",
                "source_address": "0x1000005c8"
              },
              {
                "address": "0x1000007e8",
                "value": "DAT_1000007e8",
                "source_address": "0x1000005b4"
              },
              {
                "address": "0x100004030",
                "value": "_labels",
                "source_address": "0x1000005c8"
              }
            ],
Two arrays of the dossier. Two local label names are cut.

The letter comes out of _labels at 0x100004030, indexed through the table at 0x1000007e8. Which letter a score of 95 selects needs the contents of both tables, and neither was read. The session also called analyze_function on _nothing, which returned isError: true with the code invalid_request and the message Unknown Ghidra procedure name or address: _nothing (the capture). A failed call produces no Evidence, so the ledger records it as a step and not as a finding. export_evidence_bundle then wrote the eight records of the session to a file, and that file is what makes every id below checkable (Section 5.4).

Fig. 8.3from one question to a ledgerflow
From one question to a ledger A flow read top down. The question in plum: what does ledger print for a score of 95, and where does the letter come from. Four MCP calls in indigo: list_procedures in 6,349 ms, list_strings in 6 ms, analyze_function on _grade in 16 ms, and analyze_function on _grade_label in 18 ms. Four Evidence records in teal: ev_3c6350b2 with 13 procedures, ev_ad37f574 with 39 strings from F to A, ev_41e8ca1c with 15 instructions and no caller, and ev_b201cfd0 naming _labels and DAT_1000007e8. One amber ledger with one row per claim: observed 5, derived 2, inferred 1, unknown 1, refused 1. The answer in grey stays unknown until read_bytes runs at 0x1000007d0 and 0x1000007e8. the question what does ledger print for a score of 95, and where does the letter come from? list_procedures 6,349 ms ev_3c6350b2 13 procedures list_strings 6 ms ev_ad37f574 39 strings, F to A analyze_function _grade, 16 ms ev_41e8ca1c 15 instructions analyze_function _grade_label, 18 ms ev_b201cfd0 names _labels the ledger, one row per claim observed 5, derived 2, inferred 1, unknown 1, refused 1 answer so far the answer unknown until read_bytes at 0x1000007d0 and 0x1000007e8
Four tool calls produced four Evidence records, and the ledger built from them answers the question only up to the two tables nobody read. Read top down. Plum is the agent's question, indigo boxes are the MCP calls, and teal boxes are the Evidence records with their ids cut to eight digits. The amber box is the ledger with its rows by kind.

The ledger

Evidence ledger: the table an agent keeps during an investigation, with one row per claim. A row holds the kind of the claim, the Evidence id that supports it, and the boundary that limits it. The packaged skill at the tag asks for exactly this: a short ledger that links each conclusion to its Evidence ids. Each row also gives the confidence and evidence type, the search boundary, and the unknowns that remain.

The kinds are the three values of the Evidence confidence field, observed, derived, and inferred. A claim with no record behind it is unknown. Here is the ledger of this session:

ClaimKindEvidenceBoundary
_grade starts at 0x100000518 and is 60 bytes in one rangeobservedev_41e8ca1c, procedure.bodyGhidra's function manager, after default auto-analysis
_grade divides its argument by 10derivedev_41e8ca1c, the multiply by 0x66666667 and the shiftsa reading of the listing, which the pseudocode confirms
tens from 6 to 10 index five 4-byte entries at 0x1000007d0derivedev_41e8ca1c, cmp w8, #0x4 and ldr w0, [x9, w8, UXTW #0x2]the entry count comes from the compare, the width from the shift
the five values in that tableunknownnone, read_bytes 0x1000007d0 with length 20 would observe themno call in this session read memory
nothing calls _grade with a call instruction in this buildobservedev_41e8ca1c callers: [], ev_644b3495 one addressone DATA reference from 0x10000811a, the function starts entry of Section 4.4. Caller coverage is complete for resolved call references only.
_grade_label returns an entry of _labels at 0x100004030observedev_b201cfd0, referenced_namesthe index passes through 8-byte entries at 0x1000007e8, not read
the five letters F to A are strings at 0x100000770 to 0x100000778observedev_ad37f574defined-data coverage, as the analysis profile states
a score of 95 prints Ainferredthe C source the reader ownsno record of this session supports it
score %d grade %s\n is the format that prints a letterobservedev_ad37f574that main passes _grade_label to it was not analyzed
_nothing is a procedurerefusedinvalid_requestthe call failed and produced no Evidence

The second-to-last row is the one that separates an honest report from a confident one. The reader of this manual compiled ledger.c and knows the answer. The agent did not, and the only records it holds stop at two unread tables. A report that says "95 prints A, observed" at this point states a fact the evidence does not contain. The row stays inferred until a read_bytes at 0x1000007d0 and at 0x1000007e8 turns it into observed. Those two probes are the next calls of the investigation (Section 5.2).

Fig. 8.4what the session observed, and what stays unknowncomparison
What the session observed, and what stays unknown Two columns. The left column lists five observed claims with their Evidence ids: _grade at 0x100000518 is 60 bytes in ev_41e8ca1c, the divide by 10 through 0x66666667 in ev_2c883c7b and ev_41e8ca1c, five 4-byte entries at 0x1000007d0 from cmp #0x4 and ldr UXTW #0x2, one DATA reference from 0x10000811a and no call edge in ev_41e8ca1c and ev_644b3495, and the strings F D C B A at 0x100000770 to 0x100000778 in ev_ad37f574. The right column lists four open rows with the call that would close each: the five table values need read_bytes at 0x1000007d0 with length 20, the five 8-byte entries at 0x1000007e8 need read_bytes there with length 40, the letter for a score of 95 needs both tables and then _labels at 0x100004030, and who passes a score to _grade_label needs analyze_function on entry. OBSERVED, WITH THE RECORD OPEN, WITH THE CALL THAT CLOSES IT _grade at 0x100000518, 60 bytes ev_41e8ca1c, procedure.body divide by 10 via 0x66666667 ev_2c883c7b and ev_41e8ca1c, assembly five 4-byte entries at 0x1000007d0 ev_41e8ca1c, cmp #0x4, ldr UXTW #0x2 one DATA reference, no call edge ev_41e8ca1c and ev_644b3495, 0x10000811a F D C B A at 0x100000770 to 778 ev_ad37f574, 39 strings the five table values read_bytes 0x1000007d0, length 20 five 8-byte entries at 0x1000007e8 read_bytes 0x1000007e8, length 40 the letter for a score of 95 both tables, then _labels at 0x100004030 who passes a score to _grade_label analyze_function entry
Five claims rest on recorded Evidence ids, and four stay unknown until read_bytes or analyze_function runs on the addresses the dossiers already name. Left, each observed claim with the record and the field that holds it. Right, dashed rose boxes are the open rows of the ledger, each with the call that would close it.

Target text is data

Target text: every string, symbol name, comment, and line of pseudocode that a tool result copies out of the analyzed file. The usage text usage: ledger <before> <after> [score...]\n at 0x10000077a is target text, and so is _labels and every DAT_ name Ghidra invented (the capture). The rule is that an agent quotes target text with its address and never acts on it. A string that reads like a command is a value to record, and the ledger has no row kind for "instruction received from the file".

rea 6.7.0 states this rule to the model. The instruction string of every connection tells the model to treat target text as data. It also tells the model to report a request in that text as a prompt-injection attempt. Each result that can carry target text has the marker _meta.provenance.untrusted_content: true with source: "analysis_target", also when the call fails. Only export_evidence_bundle and record_unknown leave it out.

In this session every result has the marker, except the two export_evidence_bundle results. The error of step 13 has it too. The marker tells the agent which text came from the file, and the agent must still apply the rule. This manual therefore makes the rule a ledger rule. The description of import_evidence_bundle states the same principle for bundles: "Imported content is data only and is never executed." (the capture).

The 2026 research says what happens without the rule. Santos-Grueiro built binaries whose strings and tool output pose as instructions or as fake corroborating evidence (arXiv 2607.12507). Without runtime controls, the models under test proposed a planted unsafe action in 35 of 40 adversarial cases and in none of 40 clean ones. Showing the binary content as data alone still left 15 unsafe proposals, and tool authorization with provenance checks removed them. A workshop study of three agents on 24 offline tasks named over-trust in observations as one of four recurring weaknesses (NDSS BAR 2026). A ledger row that names its Evidence id and its boundary is the smallest form of that provenance check an agent can keep by itself.

The rea marker gives the provenance half of that control. Tool authorization stays with the client.

rea (rea-agents) with the Ghidra provider rea-agents 6.7.0, Ghidra 12.1.4 · 27dc42d · 2026-10-18 · Edition 2026.10