The executable: what it is and where its code lives

Source

docs/executable/overview.md

SHA-256

740f95b0…9b444e74

What we know about Tactics Ogre Reborn.exe as a whole: how it's packed and built, how its code is organized, and which code opens which game file. How the game reads each format is in that format's doc, like filetable.md; how to run the tools is in Ghidra and rea.

Packing

Build

What's in the executable

Every part of the code, one row per system, to choose what to reverse engineer next. Built on 2026-10-10 in two steps: the region map (exe.regions) assigned every function to an address region, then agents read each region's decompiled code (DecompileScript, in local/exe/decomp/) with the indexes and named what it does. Every row is static analysis, so likely at best, and "probably" marks an inference. Rows are grouped by source folder for game code, by namespace for engine code. Sizes are summed from the regions each row covers.

Query for the totals: SELECT count(*), sum(size) FROM exe.functions. Every region has a row; the 29 functions missing from the row sums are the agents' rounding at region edges. The region map alone named 75.9% of the code bytes; reading the code named the rest. That found libraries the map couldn't see: libjpeg 9 (the 190 KB at 0x1401aec50), libvorbis (the 90 KB at 0x14062f230), LZ4 1.9.2, CRI's HCA audio decoder, and Sony's PC pad library. It also corrected the map where it was wrong: 0x14054ffa0 is the C runtime, not Bullet; the regions after 0x140646540 labeled Win32++, system/activity.cpp and bl::fnd are exception-unwind code; and the 144 KB at the start of the code is static initializers that hash shader names.

App and TacosGame

system/

battle/

unit/

event/

worldmap/

worldmap/menu/ (shop)

organize/

menu/

title/

warrenreport/

textseq/

effect/

libra/

bg/

sound/

text/

file/

graphics/

common/

Taco::Framework

unknown

Mx

Focused rendering findings and remaining questions: Rendering.

SQEX::CDev

bl

SQEX::Sd

libraries

runtime

Source modules

The executable's assert and log strings name 98 of its source files, so the functions that use those strings can be grouped by file and game system (exe.source_files, the source files). Each row is a lead (likely at best): a function can carry an inlined helper's string from another file, and only 472 functions reference any source file. The .cpp paths are relative (battle/battledata.cpp), the headers full (taco/framework/menu/menuwindow.h).

Query: SELECT regexp_replace(source_file, '/[^/]+$', '') AS dir, count(DISTINCT function_address) FROM exe.source_files GROUP BY 1.

Which code opens which file

• confirmed: the strings FileTable.EDAT (0x14067dba8), FileTable.bin (0x14067dbb8) and File\FileTable.cpp (0x14067dbd0) are in .rdata; 0x1402b1490 (FileTable_Load) references the first two. Source: rea search_strings and xrefs (Ghidra); grep -a over the executable.
• likely: the game opens its files by group ID and file ID through FileTable_OpenById (0x1402af860), not by name: the only game file names among its strings are Shader.dat, FileTable.bin and FileTable.EDAT. Source: exe.strings matched against every file name in FileTable.bin; how the game reads FileTable.bin.
• likely: FileTable_OpenById takes (this, group, file ID, flags); flags is 0x20 at 60 of its 65 calls. Source: exe.file_open_calls (the decompiler's arguments at each call).
• likely: the format tags pakd, xlce, txte, ashg and MLZ0 appear nowhere in the executable, as text or as a 4-byte constant; sabf appears once, as data. So most loaders don't recognize formats by their tags, and a format's reader is found from the code that opens its files, below. Two compare first bytes one at a time, which neither search finds: 0x1402e62b0 checks a, s, h (unpack an ashg or copy), and 0x14026f4b0 checks p, a, k (a sprite pack) and btx\0 as the u32 0x787462. The text loader's strncmp(entry, "txt", 3) is a third (containers.md). Source: grep -a -b over the unpacked executable; exe.fourcc; ashg.md.

42 of the 65 calls to FileTable_OpenById have a constant group, and 19 of them a constant file ID too (exe.file_open_calls, joined to the decoded FileTable.bin by the exe.file_opens view, The indexes). Where the file ID isn't constant, the call opens some file in that group, chosen at run time. These callers are where each file's loader starts:

Every row but the two 0x258 (Font/) ones, whose calls have no constant group in exe.file_open_calls, is this query over exe.file_opens (2026-10-12, R18, the same 29 rows):

SELECT group_id, coalesce(args[3], 'any') AS file_id, count(DISTINCT path) AS files, min(path) AS first_path,
       string_agg(DISTINCT caller_address, ', ' ORDER BY caller_address) AS opened_from
FROM exe.file_opens WHERE path IS NOT NULL GROUP BY ALL ORDER BY group_id, file_id;

Leads

• The other 23 calls to FileTable_OpenById pass a group the decompiler doesn't see as a constant (a field, or a wrapper's argument); their callers and wrappers would complete the table above. 0x140311b20 passes constant file IDs 0x0, 0x1, 0x2 with a computed group: 200, effect/ (Effects). The two Font/ rows above are such calls: the thunks pass the group, and 0x1402c2110 passes 600 (font.md).
• Which code opens the files that no call here reaches: screenshot/ and most of system/ (effect/ is group 200, opened by 0x140311b20 and 0x140414930, Effects). They may go through FileTable_OpenByName (4 calls) or FileDesc_OpenPath (3 calls), or a wrapper.
• How a loader tells a pakd archive or an xlce table apart without its tag (plan steps 4 and 5).