And here is one for the flash website:

For the most curious: no, I do not speak Japanese, and I did need to use Google Translate and DeepL a lot in spite of how much I despise MTL translations. Nevertheless, I consider knowing enough about the TGM series to have produced a faithful enough translation. I might get in touch with an actual translator who speaks Japanese once I come up with automated tools that would make it easier to insert text into the game/move it around.

The process mainly involved looking at Japanese/Shift-JIS strings inside of wxMEdit and writing Latin/ASCII text instead. I was pretty lucky that the game allowed to use both text encodings interchangeably, or at the same time if I wanted it to be so. Nowadays, there are a few tools that facilitate the romhacking/modding process of an Xbox360 game.

I – Unencrypting the executable (xextool)

By default, Xbox360 .xex files will most likely be encrypted, as developers would probably wish to protect their retail games.

This is not a problem for us though, as the CLI software xextool can easily decrypt them, and even decompress them in case of compressed games.

xextool -c u default.xex #Uncompresses the file
xextool -c c default.xex #Compress modified file
xextool -e u default.xex #Decrypt the file
xextool -e e default.xex #Ecnrypt modified file

The resulting decrypted file has text that can be read through. Since the game uses the Shift-JIS encoding, rather than HxD or any other editor that would only have ASCII and a few Latin charsets, we will use wxMEdit. Make sure you go to View > Encoding and select Shift-JIS from there!

II – Analyzing the executable (Ghidra)

Ghidra is an open-source (and free) reverse engineering tool developed by the NSA. This tool allows to “decompile” an executable, and convert its binary data into human-readable pseudocode, as well as many other features. We will use it to locate all of the strings the executable contains, as well as the locations they’re referenced to/used in the program. Due to the astronomical amount of features it presents, as well as the not-so-friendly interface of the program, I would recommend watching/reading a tutorial that explains how it works before getting your hands on the program by yourself. Hilltop’s video is a pretty good start in my opinion. h0x91B is also good, though most of his videos are in Russian and non-subbed.

By default, it couldn’t do much with a .xex file, as it’s mostly used on PC-based executables and architectures in order to help with reversing a virus. Fortunately enough, Ghidra features the ability to create and install custom extensions, making possible the analysis of any architecture, console, or device, that would have such extensions developed.

For the Xbox360, XexLoaderWV is the go-to solution. After installing the extension, drag-and-dropping a .xex executable unto Ghidra’s window will allow it to be analyzes. After the analysis is done, Ghidra should point your cursor towards the game’s entry point. We want to go to Search > Encoded Strings… and look for Shift-JIS encoded text. By default it limits the minimal length to 5 characters, I recommend decreasing it all the way down to 3, or even 2 (though that will recognize some data related to code as SJIS strings so beware). Press “Create All” once the strings have been identified. They will now be shown under the section Window > Defined Strings, and clicking any string will show where in the executable it is located.

III – Modifying the executable (wxMEdit)

Ghidra has the ability of analysing the executable, and even “Patching Instructions” in case you want to “modify” the game’s behaviour/data and see how it alters the code’s flow. Nevertheless, it never touches the actual .xex file. To modify it, if you don’t make your own scripts, you will need to use a Hex Editor to meet your ends.

As you might have noticed, something is amiss between what Ghidra tells us, and what we’d see in the actual file. Even though our file is less than 8MB (4MB in TGM Ace’s case), the starting address of every string here is beyond 0x80000000, which makes it harder to see the association between what we see in Ghidra and what we see in a Hex Editor. In order to solve that, take a random string you’ve found before, then locate it in both your executable and ghidra. Substract ghidra’s position from the one you’ve found in the hex editor, and you get the offset you’ll need to apply when carrying over you analysis knowledge to the actual executable.

At this point, you will probably ask me why we installed a 500MB tool for cybersec developers when we could just find all of the game’s strings in our hex editor. The first reason, is comfort. With Ghidra, the chance of missing a string is pretty low, all you have to do is scroll through the Defined Strings list and you will be good to go. By using a hex editor alone, you rely on your reading skills to make sure nothing was skipped, which can make you lose plenty of time on the long term.

The second reason, more serious, is that by using Ghidra’s analysis tools, you can detect the pointers (variables that store the address of something) and the chunks of code that refer to a string’s location. In the case of Tetris: The Grand Master Ace this knowledge is pretty important as the pointers related to the strings will decide where our strings begin. What this means, is that if I expect a string at position 0x10 and another at position 0x20, then unless I modify my second string’s pointer afterwards, my first string can never be larger than 15 bytes.

Changing the second string’s pointer so it would expect to find something at position 0x30 instead would allow me to write 16 more bytes into the first one, so it is important to be able to identify, and manipulate those pointers in order to not be limited by the game’s default behaviour.

In my case, there was no need to offset values that much, but from time to time, especially when the initial string was made of no more than three kanji, there was a need to move by 4-5 bytes the addresses of some pointers.

For more advanced romhacks, the game’s assembly can directly be modified if you know what you’re doing, the Xbox360 uses a PowerPC architecture so the instruction set is well-documented, and PowerPC compilers exist in case you want to convert C into X360-compatible assembly rather than writing it by hand. Compiler Explorer gives a good glimpse at how C could be converted to assembly, feel free to play around with the -O compilation options as well.

Once you’ve modified all of your strings, saved the custom executable, and tested the game out, it’s time to distribute the executable. The favoured way of doing so is by grabbing your Delta Patcher and creating your own Delta Patch by using the original .xex file as a starting point. Make sure you encrypt/compress your modified file if the original was, and you’re good to go.

Bonus: Translating the original Flash website (JPEXS + Adobe Flash CS6)

If you ever find some cool flash game or animation that’s japanese-only, it’s pretty “easy” to modify it to your liking. The JPEXS Flash Decompiler comes with a tool that allows you to view all the sprites, texts, and scripts of an .swf animation.

It also allows you to use custom fonts, and/or extend the charset the original file supported.

At last, it allows you to modify the game’s texts and behaviour by editing its’ ActionScript logic, and if that is not enough, you can always export the file as an .FLA and edit whatever else you need with Adobe Flash Professionnal CS6. As it is not the main topic of this blogpost, I will not elaborate on it much, but the short tutorials from Serega A. are pretty good, if we omit the disputable game choice that is used as example.

After applying all of his wise teachings, I was able to (almost) fully translate Arika’s flash website from 2005 into English, although I would lie if I said my translation is perfect, be it semantically or even visually.

Conclusion

Thanks to anyone who has read thus far! If you are interested in more writings about romhacking, modding and whatnot, feel free to check the rest of my blog, although my other postings don’t go into much depth about anything related to actual reverse engineering.

Since we’re approaching the end, allow me to rant a bit about a detail that would’ve saved me a fair amount of time if I knew about it beforehand.

As I already noticed in 2020, PS4 games are encrypted inside .PKG files even once they are installed, and the only way to decrypt them is by booting the game up on the console.

As such, one would think that, in order to mod a PS4 game, we would need to repack the whole Fake PKG and reinstall it each time we modify a file. That’s what I did for my first dozen of tries, and the process was TEDIOUS! Imagine doing the whole process of Part 1 each time a mere file was modified, the waste of time was absolute between the PKG repacking (about 30 minutes), the transfer to USB (5-10 minutes), the actual installation (10 minutes) and finally booting the game up: a whole hour of NOTHING, urgh.

I thought I could finally seek salvation after finding out about PS4 Patch Builder but nope, it was the same, perhaps even worse. In order to use the program I needed a backup of the whole game as a PKG and an Image0 folder with all my modded files, and, for some reason, the program didn’t function if said folder didn’t also have all the other files, which means that I know had the equivalent of two backups occupying my space for nothing! After hitting that Build Package button it would take around half an hour to generate the “Update” PKG so really there wasn’t much benefit to using that method, if not to generate a slightly tinier PKG than before, at the expense of having 3 copies of the game lying on my Hard Drive with no benefits.

Now that this is out of my way, allow me to introduce you to the actual way of modding a PS4 game, the Holy Grail of modding, a technique similar to the Switch’s LayeredFS file replacement: AFR (Application File Redirector)! I will speak exclusively about GoldHEN‘s implementation of it (as a plugin), but it was originally made by theorywrong for the Mira Project.

As its name indicates, while the game is running, AFR replaces the games files with the ones we’ve put in a custom folder, eliminating all needs from repacking the PKG each time we want to edit a file. This method works with disc copies and legit PKGs!

The first thing we need to do is to download the GoldHEN plugins from the GitHub repository. Once downloaded, we need to edit the plugins.ini file to enable the plugins we are going to use, and to tell which games we are going to load the plugins for. As I want to apply the plugins to any game, the file would look like this:

; Note: lines starting with semicolon are for comments.
; Load plugins for any title.

[default]
; Load the AFR plugin 
/data/GoldHEN/plugins/afr.prx

; Load plugins only for Playroom.

[CUSA00001]
/data/GoldHEN/plugins/afr.prx
/data/GoldHEN/plugins/no_share_watermark.prx

With the .ini file modified, it’s time to put the plugins.ini file and the plugins folder in your PS4, into the /data/GoldHEN/plugins/ folder (we can do that by USB or by FTP).

Now, we can run GoldHEN and enable the plugins in the Settings > Debug Settings > Plugins > Enable Plugins Loader section.

For each game we want to modify, we simply need to create a folder bearing the game’s TitleID inside of /data/GoldHEN/plugins/AFR, and place all of our modified files here.

If everything was done correctly, we will see the difference each time we boot up the games with AFR enabled.

There are a few ways of distributing our modded data to the public, each with their pros and cons:

• The most user-friendly way would be by repackaging the whole game and uploading the PKG on the internet: anyone with a jailbroken console could install it, but it’s not only expensive in terms of space usage (we upload the whole game), but also obviously clearly illegal (we upload the whole game). I would not recommend using that as an option, especially if you want your mod project to be publicly available.

• Another way would be by generating a custom update so we would only need to distribute the files that we modified through a Fake PKG. Unfortunately, this method requires the user to dump their game and reinstall it as a Fake PKG, which isn’t optimal.

• The best compromise between legality and ease of use would be the AFR we mentionted before: we only need to distribute the edited files, which the user can then copy to their console in the /data/GoldHEN/plugins/AFR/CUSAXXXXfolder.

• Even better legally, by using Delta Patching tools, such as xdelta or xdelta3, instead of distributing the files directly, you can distribute patches that will modify the original files with the new data, which means the user would have to own their own dump, and that we don’t technically upload any (usable as a standalone) illegal content.

• Another advantage is is that by only distributing the patched part of a file, we can drastically reduce the size of the patch we are going to share! Be warned though, this method requires the user to apply the patches by themselves before obtaining the modded file, and that an xdelta patch (to my knowledge) is applied to a single file, which, in case of a patch that modifies a lot of files,would make us generate the patches one by one, and the user would also need to apply them one by one! (these cons could be solved by making Bash/Powershell/Python… scripts that handle the patching for the user, as xdelta handles CLI with no problem.)

And thus, our long guide finally comes to an end. Now, we are able to jailbreak a ps4 console, dump any game we want, modify its contents (we covered the case of a Unity game) and run the patched contents on the console as easily as possible. Thank you for reading this blog, I will come back for more Sony-oriented romhacking articles soon!

The game was made with Unity. As such, its mostly comprised of .assets files, just like the PC version, with one particularity: the heaviest (and most important) assets have been compressed within a .psarc archive, a proprietary format used by Sony games since the PS3 era.

In 2020, I used a tool named Karameru to extract the .psarc archives. This time I used Noesis, a tool widely-used to preview 3D models from different formats, but also for extracting some types of archives, which .psarc is part of.

Once the archive is extracted, we can treat its contents like a usual Unity game folder. Unfortunately, this means more extracting and repacking but it won’t be a problem, as this time we have the whole Unity modding community behind our back!

My favorite tool for extracting Unity .assets files is AssetStudio, a software that has been faithful to me since 2019, when I first used it on the PC version of the game. It’s very easy of use for previewing and extracting the contents within the archives, but it unfortunately does not support reimporting/repacking.

Once the files we want are extracted, we can edit them to our leisure. I won’t elaborate much on this part, but one thing I can say is that AssetStudio does its best to convert the assets into commonly-used formats: .txt/.json files for the TextAsset files, .png files for the Texture2D ones, .wav for the AudioClip… Surely, we won’t have much research works to find software able to work with these file formats!

Anyway, after editing the extracted filed to our will, we will reimport them with a russian tool called UnityEX (YandexDisk mirror). Just like AssetStudio, it’s a tool I got familiar with in 2019, when I worked with the PC version. It has been helpful enough for me to donate to its developer in order to get all the features of the program, such as the Unity 2020-2021 support (more on that on the official forum thread), but we can work with the freeware version as well, since the game has been compiled with Unity‘s 2016-2017 SDK!

Unlike AssetStudio, UnityEX only opens one file at a time, which doesn’t matter since all the content we need is stored within the resources.assets file. When we open an archive within UnityEX, we can extract the files by right-clicking them, then by pressing “Extract with convert or Raw”: this will convert a file to a more common extension if it’s known (like AssetStudio does), or leave it as-is.

By hitting the “Import all files” button in UnityEX, the program will look all the files from the folder mentioned above, compare the filenames to the ones within the opened .assets archive, then replace each matching occurence. Any .png file is automatically converted into a .tex Texture2D file, then reinserted in the archive. If the program finds a filename that doesn’t correspond to anything in the archive, it will give a warning and askip if we want to continue anyway.

Now that the resources.assets has been edited, it’s time to do the whole process… Backwards! First, we need to repack the folder containing the extracted .assets files back to a .psarc file. This time, instead of Karameru, I used Total Commander, a freeware file manager which had the benefit of supporting .psarc repacking thanks to a third-party plugin by BEKETATA.

And… that’s it! Now, we have our modded archive.psarc file, ready to get inserted back into the game. As there are multiple ways of doing that, which both take a fair amount of time and dedication, I will document them in a final post, one that will get more focused on the PS4-side manipulation than the PC one.