thcrap: A Framework for Translating Windows Games in Memory

Patching in memory rather than repacking the executable

thcrap is described as an almost-generic, easily expandable and customizable framework to patch Windows applications in memory, specifically tailored towards the translation of Japanese games. The in-memory part is the defining choice. Instead of unpacking an executable, modifying its resources and repacking it, thcrap attaches to the running process and changes behaviour from inside. The practical consequences follow from that. A patch can be applied and removed without touching the original files, a patch can be updated by replacing a configuration file rather than a binary, and a patch can target a specific build of the game by fingerprint rather than by version string, since the executable is never rewritten. The readme also notes that the framework can theoretically be used for just about any other patch for these games without going through the Touhou Patch Center site.

The Touhou project is the origin, not the limit

The project was mainly developed to facilitate self-updating, multilingual translation of the Touhou Project games on the Touhou Patch Center, and the naming and topic tags reflect that focus with anime, shmup and the Touhou Project among them. The engine is nevertheless separated from the games it serves, and the module list shows the separation clearly. The main patch engine is thcrap, and the game-specific parts live in plug-ins: thcrap_tsa contains patch hooks for games using the STG engine by Team Shanghai Alice, and thcrap_tasofro contains hooks for various games by Twilight Frontier. A plug-in that knows how a particular engine stores its text and resources supplies the knowledge of what to patch; the engine supplies the mechanism. That split is what makes the framework expandable to another game without rewriting the loader.

JSON patch definitions and recursive merging

All patch configuration data uses JSON, and the readme says this makes the patches themselves open-source by design. By recursively merging JSON objects this gives patch stacking, the ability to apply any number of patches at the same time, sorted by a priority list, with wildcard-based blacklisting of files in certain patches through the run configuration. The design point is worth pausing on. A translation patch is a mapping from the bytes or strings a game uses to the ones you want instead, and a format you can read and write as JSON means a translator can adjust a line of dialogue without a compiler, and a fan translator can publish a patch as a text file in a repository. The priority list is what makes stacking predictable, since two patches may want to translate the same resource and the order decides the winner, and the blacklisting is what lets a patch be disabled for specific files.

The patching primitives, from breakpoints to file hooks

The feature list is where the technical detail sits. Binary hacks provide arbitrary in-memory modifications of the original program, mostly used for custom assembly. Breakpoints call custom DLL functions at any instruction of the original code, and those functions can read and modify the current CPU register state. Multiple sets of sequentially applied binary hacks and breakpoints exist for working around EXE packers and DRM schemes, which is the part that makes a tool like this usable against commercial titles that protect themselves. File breakpoints replace data files in memory with replacements from patches, and wildcard-based file format patching hooks are called on file replacements and can apply patches to data files according to a stackable JSON description. Patches can support multiple builds and versions of a single program, identified by a combination of SHA-256 hashes and EXE file sizes, which is how the framework knows whether a patch applies to the copy you have.

The modules and what each one is for

The module list is explicit about the division of labour. win32_utf8 is a UTF-8 wrapper library around the Win32 API calls required, and it is described as a stand-alone project that can and should be freely used in other applications. thcrap is the main patch engine. thcrap_loader is a command-line loader that calls the injection functions of thcrap on a newly created process, which is what makes a one-shot launch possible without the GUI. thcrap_configure is a GUI wizard for discovering patches, configuring patch stacks and locating supported games. thcrap_update contains the updating functionality, digitally signed automatic updates of thcrap itself and an updater GUI, and the readme notes that thcrap_update.dll can be safely deleted to disable all online functionality. thcrap_bgmmod handles the non-game-specific parts of BGM modding for originally uncompressed PCM music, including codec support and loop point handling, and it is currently statically linked into thcrap_tsa.

Building it on Visual Studio, with a MinGW alternative

A ready-made Visual Studio build configuration covering all modules and their dependencies is provided, and the build starts with the toolchain. Visual Studio Community 2019 or newer is required to build thcrap_configure_v3, and 2017 will work for everything else, and the 2022 edition works if you install the v141 and v141_xp toolsets, where v141_xp is the 2017 compiler with Windows XP compatibility. You need the submodules, so the clone is recursive.

git clone --recursive https://github.com/thpatch/thcrap.git

Then you open thcrap.sln and build, or use msbuild from the Visual Studio command environment.

msbuild /m /p:Configuration=Release

The binaries end up in the bin subdirectory. The repository also ships a Makefile for a MinGW cross-compilation path, with a BUILD64 switch that switches the toolchain prefixes between i686-w64-mingw32 and x86_64-w64-mingw32, and the compiler flags show the same care about the main platform being MSVC, with warnings disabled deliberately to keep the pragmas and typedefs intact.

Signing releases and the automatic update chain

Self-updating is a documented feature, and it is the part of the design that needs a certificate. If the build should be able to update itself, you create a code signing certificate with makecert and convert it with pvk2pfx, and the resulting cert.pfx is used to sign the binaries as part of the build, so the file name should not change. A release archive is signed separately, by converting the private key to a PEM file with OpenSSL and running the release_sign.py script from the scripts directory over the archive. The chain then is: the patcher verifies a signature before it replaces its own files, and the update module is the piece that performs the replacement. Deleting thcrap_update.dll disables all of it, which is a useful property for an offline or curated installation.

Licence, releases and the current state of the project

The licence is the Unlicense, and the repository root holds an UNLICENSE.txt file, which places the code in the public domain. That is a deliberate choice for a community translation framework, and it means a patch author does not have to think about who owns their work. The release history is date-based rather than version-numbered, with releases named 2026-09-04, 2026-09-03 and 2025-12-02, which is a sensible convention for a tool that is expected to track game patches as they appear. The last push was on 2026-10-20 and the repository is not archived, so the code is being worked on. The project is built around the Touhou Patch Center at thpatch.net, has a Discord server, and takes funding through Open Collective, and the homepage carries the same address. For someone evaluating it, the practical entry point is the manual and the patch centre rather than the source.

Editorial conclusion

thcrap fits a localisation hobbyist who wants an unofficial translation of a Japanese Windows game running on a copy they already own, and who is comfortable with a tool that injects into the running process. It is the wrong tool if you need a supported commercial release, and it is the wrong tool if you cannot accept that the game is being modified at runtime rather than patched on disk. Before you rely on it, check the patch you plan to use against the build you have, because patches are identified by SHA-256 hash and executable size.

Frequently asked questions

Official sources

1. License: Unlicense
2. Project website
3. README
4. Releases
5. thpatch/thcrap on GitHub