slinky/docs/re-notes.md

Reverse-engineering notes

Carried over from slinkyfullsrc/SRC.md. None of this is needed to build the module sources.

.slinky0 — engine / module manager

slinky2.decrypted/slinky0.bin is 14 255 293 bytes (.slinky0 of the client image). Region map (verified):

range	content
0x000000–0x77FFFF	native code + data (MSVC CRT/RTTI strings at 0x2d000–0x3c000, engine code; clean x86-64, ~30 % printable)
0x780000–0x8BFFFF	high-entropy (7.99) blob — encrypted/compressed, not consumed by visible code
0x8C0000–0x9FFFFF	sorted (u32 rva, u16 size) table, 213 035 records, covers 0x36300E–0x867551, sizes multiple of 8, dense (≈50 % of the region), deltas 2–16 bytes, overlap → looks like a per-site patch/relocation or checksum map for the code region
0xA00000–0xAA0000	table A, XOR 00 10 00 62 75 86, 109 225 × (u32 off, u16 size); offsets 0x223–0x27FFB4 fit inside the tail block; sizes ∈ {0,8,24,32,…,120}
0xAA0000–0xAB0000	table B, XOR 83 A7 00 10 00 53, same 6-byte record shape
0xAB0000–0xD80000	tail_high.bin — 2 949 120 bytes, entropy 7.98, no standard container/PE; table A indexes into it
0xD80000–0xD984BD	tail_code.bin (~100 KB), mixed code/data

Module-manager data model (recovered from the client image, used by the reconstructed sources):

• Module descriptor in .data (.rdata string pointers + a factory/log function at +0x58). modules_real.json lists all 67 (61 with a GUI cb).
• Per-module settings block in .data, variable stride, begins with three function pointers {gui_cb, register_settings, aux} followed by the widget cfg objects (CfgBool/CfgSlider/CfgRange/CfgEnum/CfgColor/...).
• R_* registration calls are made from the client into the engine manager at DLL init (one reg_<addr> function per module), the W_* calls render the settings pane.

The module-side functions that read the settings and implement each feature are in src/logic/ (see docs/logic.md); they were extracted 1:1 from .text by tools/extract_logic.py.

The manager itself is in client .text, not .slinky0: constructor 0x28000, dispatch 0x285d0, descriptor table 0x14f810. It groups modules by category and by the event callback slots at descriptor+0x48 … +0x1F8, and dispatches the enabled callbacks. See docs/engine.md for the full picture, including the six engine-only modules. .slinky0 has no static RIP-relative references into the client's .rdata/.data/.text (checked: 0 refs), so it receives whatever it needs through runtime-installed pointers.

tail_high.bin

tail_high.bin is still packed. Findings:

• Not a PE, not ZIP/7z/RAR/gzip/zlib/LZMA (standard headers checked).
• Entropy 7.978; byte histogram ≈ uniform; no repeated 24-byte blocks.
• Table A (109 225 records) and the sorted table (213 035 records) both use the same (u32 offset, u16 size) record form, sizes are multiples of 8, and both point into their subject buffers with heavy overlap — this is a site map (patch/relocation/checksum), not a container directory.
• The runtime copy of .slinky0 captured in slinky.dll is byte-identical to the static stream up to 0xC4B658 and zero beyond, i.e. that dump was taken before the engine performed the tail transformation; it gives no plaintext.
• Therefore decryption requires either (a) implementing the protector's per-site transform from the 0x8C0000 table, or (b) a live Wine trace of the first execution that touches slinky0+0xAB0000 (same breakpoint technique that recovered the .slinky2 LZMA streams).

Decrypting tail_high.bin is not required for anything in this tree: the module callbacks/registrations are plain .text, and the registry data model is plain .data. It is required only for the remainder of the engine internals.