Rule out alternate Tier2 BCA import callers
This commit is contained in:
parent
e5c4f0b6ac
commit
7769abd618
2 changed files with 18 additions and 0 deletions
|
|
@ -723,6 +723,15 @@ Working rule:
|
|||
`0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still
|
||||
consumes already-materialized bank/template bytes rather than explaining how they became
|
||||
nonzero in the first place.
|
||||
The constructor/import seam is fixed in the same negative way now too: `0x00438c70` allocates
|
||||
the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub),
|
||||
and only then allocates the aux/source pool through `0x0041aa50`, so there is no hidden branch
|
||||
between those two constructors. The only checked caller of source-record importer `0x00414490`
|
||||
is `0x00419788`, and the surrounding `.rdata` proves that strip is the stock
|
||||
`"%1*.bca"` / `".\\Data\\BuildingTypes\\"` scan rather than a map-specific alternate
|
||||
package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA
|
||||
parser?”; it is “which later non-stock writer or projection seam makes live
|
||||
`[candidate+0xba/+0xbb]` diverge after the fixed stock BCA import has already run?”
|
||||
So the honest next queue head is now one step earlier again:
|
||||
recover the non-stock writer or restore-time projection owner that makes some live candidates
|
||||
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue