Patching FFVIIHook for FFVII Rebirth on Mac with Claude Code

Square Enix shipped Final Fantasy VII Rebirth update v1.005 on June 3, 2026 and it broke FFVIIHook, the mod that gives you a dev console, INI overrides, and a bunch of other quality-of-life things. The update itself was mostly about making the game easier: Streamlined Progression with unlimited HP/MP, a New Game Head Start option that lets you begin with level 65 characters, and AMD FSR support. Nice additions. Also a broken mod. The mod author hadn’t pushed an update yet, and I was not about to just wait. So I spent a weekend going deeper into reverse engineering than I probably should have, with Claude Code doing most of the heavy lifting.

TL;DR

If you just want the patched DLL without reading my weekend diary, head over to the ffviihook-patcher repo on GitHub. Grab the patched dxgi.dll, follow the README, rename it to xinput1_3.dll, and drop it into your game’s binaries folder.

This was built and tested on my Mac running FFVII Rebirth via Crossover. If you’re on the same setup, check my FFVII Rebirth on macOS settings post first. Use this at your own risk. It worked for me, but I am not a reverse engineer and this is completely vibecoded.

Why FFVIIHook Breaks After Updates

FFVIIHook works by hooking into specific functions inside ff7rebirth_.exe. To know where those functions live in memory, the mod embeds a version table keyed to the PE timestamp of the exe. When Square Enix ships an update, the exe timestamp changes and all the function addresses shift around. The mod sees an unrecognised timestamp and disables itself with an “unsupported game version” error.

The fix is conceptually simple: find where the functions moved to in the new exe and add a new version entry to the DLL. Simple in concept. Less simple in practice when you have never used a decompiler before.

Loading the Files into Ghidra

I had heard of Ghidra before but never actually used it. It’s a free reverse engineering tool from the NSA (yes, really) that can decompile binaries into something resembling readable code.

Getting it running on Apple Silicon took a bit of setup since you have to build the native components yourself, but nothing that a bit of Googling couldn’t sort out.

The approach was to load both the old and new ff7rebirth_.exe in Ghidra and compare them. For each function that FFVIIHook needs to hook, you take a signature from around the old address and scan the new exe to find where it moved. Most of the 17 function offsets landed with a straightforward signature scan. A couple of them had been heavily rewritten and needed a different approach.

The Hard One: 655 Call Sites

One offset, code[4], was a complete nightmare. The function prologue had been rewritten enough that a simple byte signature scan produced no unique match. Claude Code suggested an xref voting approach: find every place in the old exe that called this function, then locate those same call sites in the new exe by matching the surrounding code context. Whichever candidate address gets the most votes wins.

Sounds elegant. The problem was there were 655 call sites. The voting process was slow, and the first few candidates it returned were wrong. I knew they were wrong because the game would crash on launch and the CrashContext.runtime-xml file would tell me exactly which address faulted.

So the workflow ended up being: run the patcher with a candidate, launch the game, wait for the crash, read the crash log, feed the faulting address back to Claude Code, and let it narrow down the search. Brute force by crash report. It was not elegant but it eventually worked.

When It Finally Clicked

At some point the “dev console loaded” message appeared and the game launched cleanly with the FPS counter visible in the corner. That screenshot below is from the moment I knew the patch was good.

The Claude Code session that got us there was a fun read in hindsight. A lot of “this is the one” followed by crashes, then eventually the actual win.

How Did We Do vs the Official Patch?

After emoose shipped the official dxgi_new.dll for the May 2026 build, I did a binary diff to see how close we got.

The short answer: functionally identical. All 217 exports match. All 20 version-entry slot values match exactly — same RVAs, same constants. The dev console and INI loading both work correctly.

The longer answer: we missed two things.

The first is a 512-byte block in the .data section. The official release includes an instruction-length and trampoline relocation table that we never generated. It encodes which x86 opcodes the hook engine needs to handle specially when copying function prologues — things like short jumps, RIP-relative instructions, VEX prefixes, and return markers. It lives in writable memory so the hook engine can update it at runtime. Our patch skips this entirely. The hook still works because the specific functions being hooked don’t trigger those edge cases, but it’s a gap.

The second is slot[29] at address 0x5089618 — an additional hook or patch address in the official entry that we never found. We don’t know what it does. The game runs fine without it, but it’s sitting there in the official build doing something we haven’t identified.

So: good enough to work, not byte-perfect. If you want the full picture of what the mod is doing, the official release is the authoritative version.

What I Actually Learned

I went into this knowing almost nothing about binary patching or decompilers. I came out the other side knowing just enough to be dangerous. The main things that actually helped:

Crash logs are your best friend. The CrashContext.runtime-xml file that FFVII Rebirth generates on crash contains the faulting address, which tells you immediately whether a candidate offset is wrong. Without that feedback loop the xref voting approach would have taken forever.

Ghidra’s decompiled output is readable enough that you don’t need to understand x86-64 assembly deeply to follow along. You can compare two versions of a function side by side and see roughly what changed.

Claude Code is genuinely good at this kind of binary analysis work. I provided the context and the crash feedback, it did the scanning and scripting. I couldn’t have done it without it.

Final Thoughts

The patcher supports the May 2026 build of FFVII Rebirth (exe timestamp 0x6a16ced2). If Square Enix ships another update, the script will print a warning and you’ll need to repeat the offset-finding process. The README has a full walkthrough of how to do that.

The repo is at github.com/peaz/ffviihook-patcher. All credit for the original FFVIIHook mod goes to emoose. I just patched it for a build they hadn’t got to yet.