Binary Perimeter

Gate-2 evidence pivots for the stripped Zoo Tycoon 2 binary: function entries, variables/data, type identities, vtables, and byte-map coverage. Data files: zt-function-perimeter.tsv, zt-global-perimeter.tsv, zt-type-coverage-reconciliation.tsv, zt-vtable-methods-full.tsv, and zt-byte-range-map.tsv.

Pipeline

  1. Byte range map is the evidence gate by address/range: it records whether each mapped byte or range exists and what it is.
  2. Binary perimeter is the evidence pivot gate: it groups the recorded evidence by functions, variables/data, type identities, vtables, and broad evidence families.
  3. Functional specification is the product and delivery gate: it defines the greenfield Bevy architecture, native pack contracts, original behavior, performance acceptance, and every discrete implementation package.

This page is gate 2. It pivots recovered evidence into function, variables/data, type-identity, and vtable views.

Perimeter Coverage

Each bar below answers one completion question with one denominator. Solid bars use a closed denominator for that question. Striped bars use the currently known perimeter; future discoveries can expand the total. The byte-map bar is limited to the mapped runtime executable image at runtime-parent 0x00400000..0x00a92000. It reports bytes rather than row counts or partition counts.

Perimeter viewDenominatorCurrent splitWhat this answersRemaining uncertainty

Status Vocabulary

StatusMeaning
confirmedaccepted exact function identity/name from a byte-map row whose start equals the function entry
wrapper-indirectedneutralized wrapper callsite, depepper resolver, or rebuilt import-table row
mapped-datanon-.text data rows that the function-list source reported as function-like; not original native function entries
unidentifiedknown function entry with no accepted exact identity/name; structural overlays may still assign middleware, vtable, or domain context

Reading The Work Queue

Function perimeter places accepted function identities, middleware provenance, neutralized wrapper callsite/import rows, and still-unidentified function entries on the same frontier. Accepted and unidentified function entries are split by inferred domain or middleware provenance. Those domains are triage labels. The vtable column records a verified projection from a function entry to an enumerated vtable slot. Every distinct vtable method address is already represented in the function perimeter, so the vtable bar uses the slot-row denominator. Variables/data and type identities combines referenced variables/data with the template-only type rows needed to complete the known type surface.

Variables / Data

The variables/data table is generated from absolute references in .text. Type-cache and identified variable/data names come from byte-map rows; unidentified entries remain raw referenced addresses until a byte-map fact names them. Template-only type identities are the zero-slot rows that have no corresponding type-cache variable. The family column is explanatory grouping only; the name and status still come from the byte map.

Per-Class Method Perimeter

Vtable method rows are generated from enumerated .rdata pointer runs and labelled from byte-map class evidence, early-slot type-getter evidence, constructor/vptr-store evidence, accepted byte-map function rows, and the function perimeter. They are a slot-level method-shape view. Shared stubs and inherited helper bodies can occupy many slot rows while representing one function address; the address-level method body appears in the function perimeter.

Function perimeter

addresssizenameregionstatusprovenancevtable slot rowsexample vtable slotinferred domain

Variables / data perimeter

addresssectionnamestatusfamily