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.

Let’s imagine you have a PS1 game you love, perhaps a game of your childhood even, and you wanted to listen to the game’s soundtrack without booting it up. You look the game up on YouTube, and the only upload for the OST is a 128kbps 240p video from 2009 that probably sounds like this:

OK, if YouTube uploads don’t have a good quality, maybe the official albums do ? So you go on VGMDB, look the game up, and… No dice, the game isn’t on the website, or perhaps it is, but only with fan remixes.

In this situation, only one possible solution remains: GameRipping! There are two types of gamerips: the ones which record the audio, either from an emulator, or even the console itself; and the ones which extract the audio from the game’s files.

I will exclusively talk about the second one, but if you want to record the audio from a game, you’d better make sure both your recording software/hardware and your audio input are accurate (lots of old Sega Genesis/Megadrive gamerips sounded different than the original hardware because they were recorded in an emulator that didn’t play the sounds accurately).

When it comes to gameripping on the PS1, there are two possible outcomes: the game stores the music in the CD-DA format, which means it’s possible to rip the audio from it with a usual AudioCD ripping tool (such as Exact Audio Copy, see this guide), or it stores the music inside a proprietary PS1 format (.XA, .VB/.VH streams, etc…).

In case of the latter, we can use a helpful PS1 ripping tool known as jpsxdec. This tool’s purpose is to parse all the data contained within a disc (as an .iso), and then locate any video, image, or audio from the game.

The usage of this tool is far from complicated: pressing “Open and Analyze File” will open an explorer window where we need to select the ISO we want to rip. Once a disc has been selected, theprogram will then show all the files it contains, with the type of media contained within said file if it’s known.

By pressing on the “+” button next to a file, we can inspect its contents closely, such as with .XA files that contain multiple audio tracks. If we tick the checkbox next to a file, it will be saved to a certain directory when we hit the “Save All Selected” button in the bottom-right corner.

Aaaand… That’s it, really. If we go to the directory we saved our files to, it will show them as intended.

Some games might play additionnal sounds on top of said tracks ingame (often the case with rhythm games such as Paca Paca Passion), or perhaps it will add some post-processing reverb, but in general this will be enough to gamerip the music from a PS1 game.

In order to play gameripped files natively, i.e without converting them to .WAV, we can install foobar2000, as well as all the video game-related components, such as the VGMStream Player, Game Emu Player and PSF Decoder.

As always, thank you for reading this and see you in another post of mine!

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.

In this post, I will go through the steps we must follow in order to play a modded game on a PS4:

• First of all, we need a FAT32 (or exFAT)-formatted USB Drive. 8GB should be enough for The Silver Case but the bigger, the better!

• As of the console, we need a jailbreakable PS4. Firmwares 5.05, 6.72, 7.02, 7.50~7.55 and 9.00 are compatible. If you’re on a lower firmware, you should upgrade to the latest exploitable version. If you’re on a higher firmware, you’re out of lock and need to wait for an exploit to be found. DO NOT TRUST THE “DOWNGRADER” SOFTWARES, IT’S A SCAM!

• If the console is compatible, we will need to run a HEN exploit on boot in order to enable the jailbreak functionnalities. This is done by running webkit exploits either from a local server (self-hosted exploits), or from a website that hosts them (example here). The most well-known HEN enablers are GoldHEN and MIRA, both give access to the functionnalities we need.

• Once the HEN exploit is active, we need to dump the original copy of the game, and it’s updates when needed. In order to do that, BinLoader must be enabled by going in the console’s Settings > Debug Settings > Servers Setting, and then ticking the checkbox here. Once enabled, we can run a Game Dumping exploit (the Karo menu linked earlier has it in the Dumper Group category). The next booted game will be dumped to the USB Drive plugged in the console. This process might take a while, maybe a bit less than an hour, but in the end we obtain a clean folder with all of the game’s files. This step is necessary as all the PS4 games are encrypted within PKG files locked by a passcode, and are only decrypted on runtime.

• At the end of the process, we have a CUSAXXXXX-app folder on your USB Drive. If the game has updates, we will end up with CUSAXXXXX-patch folders as well.

• The next step is rebuilding the dumped games (and updates) into Fake PKGs by using the Fake PKG Tools: we generate a .gp4 file for the base game with gengp4_app.exe, then we open the resulting .gp4 file within orbis-pub-gen.exe and click on the “Build” button on the top right corner. We then repeat the process for all the updates by running gengp4_patch.exe instead.

• We can then install the generated PKG files back on the PS4 by putting them on your USB Drive, then going into “Settings > Debug Settings > Package Installer”.

We are good to go! Now that our game has the default passcode 0000000000000000…0, we can finally install whatever modded files we want over it.

First of all, a lot of games tend to not have an official soundtrack album at all, no matter how famous the compositions might be. Take Ecco The Dolphin: Defender Of The Future as an example: the game is widely-known for its gorgeous music made by Tim Follin & Attila Heger, yet we are still to have an official release, truly a shame.

Secondly, some games had a soundtrack released, but it was not faithful to how it sounded ingame. This is a common occurence with the old releases, such as the Namco GSM collections, or even the obscure Amiga shoot’em’up Apidiya (how Techno Party sounds on the album vs how it sounds ingame, not quite the same).

As such, it is common for game music to be gameripped,a process during which we extract a game’s music straight from the files, in order to have the faithful sound.

This process is rarely a straightforward one, especially when it comes ot old and/or console games, which almost always use either archives or proprietary audio codecs , sometimes to optimize on space, sometimes to obfuscate the data, often both.

That’s when the romhacking/reverse-engineering part comes in! Since the used file formats are proprietary, and usually not readable as is, a great amount of effort has been put by numerous people through time in order to document said formats, and come up with tools that can read the data, and even convert it to more common formats.

Take the Super Nintendo‘s .SPC format for example, which is conceptually not unlike a .MIDI file (don’t take my words on that, I’m not a musician nor a sound engineer). The format has been documented so much that it is now possible to read the audio on your own computer by using one of the dozens of available tools , even if you don’t even own an SNES!

Lastly, I felt the need to mention I’m French. Why that ? Once again, the answer is not hard!

When I play some games, mostly English ones but sometimes Japanese as well ( I don’t speak that language unfortunately), the thought “hmmmm I wish this was translated in French” often comes to my mind. For Japanese games with voice acting, I also often think about making undubbed versions on their western counterparts (i.e modifying the game to use the japanese voices as it wasn’t a standard until the late-PS3 era).

Because of that, I’ve looked unto various games, various file formats, by using a plethora of tools available on ZenHax, Xentax, ROMhacking.net and whatnot, sometimes with mitigated success, but mostly with complete failure at the end of the day.

However! All is not to throw away! Even if I didn’t manage to obtain the results I wanted, I still got to familiarize myself with a plethora of romhacking tools that might end being of use someday, either by myself (once I’ve acquired enough patience and experience), or someone else, who might be more competent, more patient, or simply more stubborn than me.

Such is the purpose of this blog: talking about some tools I used, the way they are supposed to be used and what can be done with them. Prepare for some action (and some ranting), we’re going to break through the formats! (mostly with preexisting tools, but the day might come when I’ll reverse a format by myself…)