Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.
OpenHoops Ghidra analysis
Historical Mac toolchain record. The Mac installation/project paths and native-tool builds below describeOctober12 evidence. Extra Mac research state/Wine were later removed at the user's request. Current Ghidra12.1.4/JDK21.0.12.1+1 work uses the Dell under C:\Users\brent\OpenHoops\deps; the Mac is editing/storage/control only. Do not restore old Mac dependencies or treat the paths below as current prerequisites. See current state.
Current scope (October13,2026): Windows-first deep editing and a public extension API; Mac/Linux compatibility follows later. Earlier native-port goals and next-step proposals in this evidence history are superseded. Technical observations and verification limits remain as recorded.
Ghidra 12.1.4 is installed locally with Temurin JDK 21.0.12.1. Its native decompiler, Sleigh compiler, GNU demanglers and LZFSE utility were built successfully for macOS ARM64. The original PE was imported from a separate, hash-identical working copy. No game process was launched.
The persistent project is /Users/brentlane/Library/Application Support/OpenHoops/ghidra-projects/OpenHoops-original-1.0.1.1.gpr. Keep its adjacent .rep directory with it. A ZIP snapshot of both is retained inside this project's resources/research-tools/project-snapshots/; run metadata records its exact path and SHA-256. Toolchain metadata records package checksums, installed paths, Java version and hashes of the compiled native tools.
Status and limits
The initial import saved successfully and exported 14 selected functions and 120 references. The automatic analysis hit its configured 240-second limit; its analysis report records approximately 295 seconds because the running analyzer did not stop immediately. The saved project is partial, not a completed engine decompilation. Headless log
Ghidra discovered 15,855 function candidates before stopping. This is not a count of reconstructed or verified functions. Warnings include invalid instruction flow, unavailable memory and unresolved switch tables. The six small experiment routines have independently checked boundaries and original-byte comparisons; most of the larger image does not.
All 14 requested decompilations returned pseudocode, but a successful decompiler return does not establish correct types, arguments, boundaries or semantics. For example, the exported update callers omit the lookup argument even though their instructions explicitly clear ECX, and lookup's generated int arithmetic should not be copied into portable C++ with signed overflow. Hand-reviewed instruction behavior remains the evidence for the native experiments.
Caller findings
Addresses below are preferred virtual addresses, not RVAs or file offsets. Structured references and instruction listings preserve the exact Ghidra results and executable identity.
| Target | References found | Interpretation |
|---|---|---|
Year cell 0x1332918 |
6 | Three storage routines, two identified containing functions and one read without an established containing function |
Year getter 0xA27A10 |
20 | Direct calls; several containing functions are still unresolved |
Year setter 0xA27A20 |
1 | Direct call at 0xB3B2C6, inside candidate 0xB3B220 |
Record lookup 0xA09E10 |
88 | Calls/reference sites, including the verified update routines |
Raise-only update 0xA27A40 |
5 | Direct calls; one containing function currently identified at 0xA40470 |
No references to the year reset or unconditional record setter appeared in this partial export. That does not prove they are unused.
The most useful connection is candidate 0xA2C920: it loads the year cell into ECX, sets EDX to 6, pushes 0x3B, 0xB and 1, calls 0x5F7C20, and stores the returned EAX at record zero's +4 field through 0xA09E10. Thus the reconstructed field receives a result computed from a year input. A calendar/date interpretation is plausible but unconfirmed. The constants' meanings and the callee's contract have not been established. Instructions and tentative pseudocode
Candidate 0xA290E0 also passes a year-derived value to 0x5F7C20 and then dispatches through a jump table. Ghidra did not recover that switch fully. Both 0x5F7C20 and another dependency, 0x48FC50, contain bytes that do not currently decode into trustworthy ordinary routines in the file view. Protection, runtime transformation or incorrect analysis boundaries remain investigation possibilities. Do not fabricate date arithmetic to fill this gap.
Candidate 0xCB69F0 has a readable branch that subtracts the low 12 bits of a 16-bit field at object +0x1E from the current year. Its mode-dependent alternate path has additional dependencies. This suggests a year-difference calculation; it does not yet identify the object, field purpose or complete routine contract. Tentative pseudocode
Reproduce and continue
On this macOS ARM64 host with Xcode command-line tools installed:
.venv/bin/python tools/setup_ghidra.py
.venv/bin/python tools/analyze_ghidra.py
Setup verifies the pinned archives before extraction and builds the native tools if absent. The analysis runner checks the original and working-copy executable hashes, copies the Java scripts into the local tool area, imports on first use and processes the existing saved program on subsequent runs. Each successful export produces a project ZIP snapshot. Rerunning continues bounded automatic analysis; the generated export and latest-run logs are replaced. Historical snapshots are kept.
Tool installation is outside the workspace because Java failed to load a native library from this workspace's colon-containing path. The Ghidra project is under Application Support because Ghidra rejects a project path containing a dot-prefixed path component such as .local. Package archives, research outputs and project snapshots remain in the workspace. No system Java default or security settings were changed.
The six entry-point seeds are explicitly named analysis labels, not recovered original symbols. Seed script, export script, runner, installer.
The pinned release requires JDK 21; the development-branch README's JDK 25 requirement does not apply. Sources: Ghidra release, release-specific setup and native build instructions, Temurin release. The exact upstream release metadata is archived in resources/research-tools/.
The unresolved helper remains historical research. Current Ghidra work should target concrete Windows API, rule, roster-launch or presentation boundaries in the working executable. Do not resume unrelated routine recovery or full native-engine reconstruction from this earlier investigation; use the current implementation plan.