PSP:Patching the executable (BOOT.BIN)

From Gitaroo Pals
Jump to navigation Jump to search

So, you have some cheat codes or assembly hacks, and you want to apply them directly to your Gitaroo Man Lives! ISO. Here's how.

Introduction

In short:

  • EBOOT.BIN is encrypted = bad for patching
  • BOOT.BIN is not encrypted = good for patching (if you follow the instructions)


In all versions of Gitaroo Man Lives! (Japan, US, Korea, and Europe), the game runs an encrypted executable called EBOOT.BIN. Modifying this encrypted executable is not great for patching purposes because:

  • Even minor changes may change the data of the entire EBOOT.BIN's data (due to the need to decrypt and re-encrypt)
  • Therefore, patching EBOOT.BIN directly (e.g. with xdelta) is not only inefficient, it's problematic for legal reasons (your patch may contain the entire EBOOT.BIN instead of just your changes)

However, there is a better way! BOOT.BIN is the unencrypted version of EBOOT.BIN, also contained in all versions of the game. However, this file is normally unused. To make the game run BOOT.BIN, follow step 1 below.

Creating an ISO patch that modifies the executable

1. Make the game use BOOT.BIN instead of EBOOT.BIN

This method should work on real hardware and is patch-friendly (for both space & legal reasons).

In short, we use UMDGen's relinking feature to make EBOOT.BIN point to BOOT.BIN:

  1. Open your ISO in UMDGen
  2. Navigate to PSP_GAME/SYSDIR (ignore the UPDATE folder)
  3. Right-click BOOT.BIN. Choose File RelinkerUse Selected File as Source
  4. Right-click EBOOT.BIN. Choose File RelinkerRelink to Source

Now, EBOOT.BIN and BOOT.BIN will both point to the same unencrypted file.

Emulator note: Emulators are more forgiving than real hardware. It may be enough to simply delete EBOOT.BIN, but it probably won't work on a real PSP.

2. Modify your BOOT.BIN

You'll start with either

  • a CWCheat code you want to apply, or
  • a RAM address (like in PPSSPP's debugger or ps2dis) that you want to change

2a: Check whether your CWCheat code or RAM address will work

(Or you can skip this step and come back only if you notice something wrong in the later steps, whatever.)


Special notes for CWCheat codes:

  • A CWCheat code must start with 0, 1, or 2 to work. (Anything else is a special code type; you'd have to write an assembly hack to replicate the code's effect, which won't be detailed here.)
  • To get the CWCheat address from a code:
    1. Take the left half of the code (e.g. _L 0x2017d594 0x10000003)
    2. Zero the leftmost digit of that part (e.g. 0x2017d5940x0017d594 is the address.)


Check if your CWCheat or RAM address is in one of the tables below. (If it isn't, BOOT.BIN patching will not work; you'll have to find another way.)

Addresses that will work
Game Region CWCheat addresses RAM/PPSSPP addresses BOOT.BIN file offsets
🇺🇲 US 0x00100000 - 0x001b6d73
0x001b739c - 0x001b824f
0x08900000 - 0x089b6d73
0x089b739c - 0x089b824f
0x54 - 0xb6dc7
0xb73f0 - 0xb82a3
🇯🇵 Japan 0x00100000 - 0x001b5727
0x001b5d48 - 0x001b61d3
0x08900000 - 0x089b5727
0x089b5d48 - 0x089b61d3
0x54 - 0xb577b
0xb5d9c - 0xb6be3
🇰🇷 South Korea 0x00100000 - 0x001b57d7
0x001b5df8 - 0x001b6c3f
0x08900000 - 0x089b57d7
0x089b5df8 - 0x089b6c3f
0x54 - 0xb582b
0xb5e4c - 0xb6c93
🇪🇺 Europe 0x00100000 - 0x001b66c3
0x001b6ce4 - 0x001b7b2b
0x08900000 - 0x089b66c3
0x089b6ce4 - 0x089b7b2b
0x54 - 0xb6717
0xb6d38 - 0xb7b7f
Addresses that might work (requires testing)
Game Region CWCheat addresses RAM/PPSSPP addresses BOOT.BIN file offsets
🇺🇲 US 0x001b8250 - 0x001ca9ff 0x089b8250 - 0x089ca9ff 0xb82a4 - 0xcaa53
🇯🇵 Japan 0x001b6b90 - 0x001c8b7f 0x089b6b90 - 0x089c8b7f 0xb6be4 - 0xc8bd3
🇰🇷 South Korea 0x001b6c40 - 0x001c8c60 0x089b6c40 - 0x089c8c60 0xb6c94 - 0xc8cb4
🇪🇺 Europe 0x001b7b2c - 0x001ca31f 0x089b7b2c - 0x089ca31f 0xb7b80 - 0xca373

About the second table ("Addresses that might work"):

  • If your address is in the second table, it might work, or the game may overwrite its value.
    • For example, in the US version, the CWCheat code for Timing Windows 10x 0x201BDFD4 0x0000EA60 uses the address 0x001BDFD4, which is in the second table. You can modify its value in BOOT.BIN, but the game will overwrite it, so your modification will not have any effect.
  • To test, you can either proceed with the BOOT.BIN modification and see if it works in-game, or you can watch the address in PPSSPP's debugger and see if its value gets overwritten.
  • If your address is getting overwritten, you will have to find another way to make your code work. You can start by finding when your address gets overwritten with a new value, trace that new value back until you find where it comes from (go back in time by loading savestates or rebooting), then change the new value at its origin.

2b: Edit the game's original BOOT.BIN

  • From your game's ISO image, extract PSP_GAME/SYSDIR/BOOT.BIN. You can do this with UMDGen, or with various programs that open ISO files.
  • Open the BOOT.BIN in a hex editor. And then...
Using a CWCheat code:

Let's use the example 0x201215cc 0xac680008.

  • To get the BOOT.bin file offset: Get the CWCheat address (left half of the code, zero the leftmost digit) and subtract 0xfffac. This is the location in BOOT.BIN you will modify.
    • Example: 0x201215cc0x001215cc - 0xfffac = 0x21620 is the file offset.
  • To get the new value:
    • First, look at the original CWCheat code (before you zeroed the leftmost digit).
      • If the original CWCheat code started with 0x2, it modifies all 4 bytes. You will use the entire right half of the code. (e.g. ac680008)
      • If the original CWCheat code started with 0x1, it only modifies 2 byte. Take the right half of the code and X out all except the last two bytes. (e.g. XXXX0008)
      • If the original CWCheat code started with 0x0, it only modifies 1 byte. Take the right half of the code and X out all except the last byte. (e.g. XXXXXX08)
      • Example: 0x201215cc 0xac680008 starts with 2, so you will use the entire right half, ac680008.
    • Now, take that right half, with any X-ed out bytes, and reverse the bytes. For example, XXXX0008 becomes 08 00 XX XX.
      • If there are any any X-ed out bytes, don't modify those bytes in the hex editor (leave them as they are).

Now you have the BOOT.BIN file offset and the new value to change it to, go ahead and change it.

Using a RAM/PPSSPP/ps2dis address:
  • To get the file offset: Take the RAM address and subtract 0x88fffac. This is the location in BOOT.BIN you will modify.
    • Example: 0x089215cc - 0x88fffac = 0x21620 is the file offset.
  • To get the new value:
    • You may or may not need to reverse the bytes, depending where you got the value from. Basically, whatever order shows up in PPSSPP's memory viewer is the order you want your modified bytes in BOOT.BIN.
      • In PPSSPP's debugger, if you got your value by using "Copy Instruction (Hex)," you will need to reverse the byte order (e.g. 0e26db9595 db 26 0e). The debugger also comes with a memory viewer that will show bytes already in the correct order.
      • In ps2dis, if you got your value by copying from the Data textbox, you will need to reverse the byte order. ps2dis also comes with a memory viewer that will show bytes already in the correct order.

Now you have the BOOT.BIN file offset and the new value to change it to, go ahead and change it.

3. Insert your modified BOOT.BIN

Drag your modified BOOT.BIN into PSP_GAME/SYSDIR in UMDGen, replacing the old one. Since both EBOOT.BIN and BOOT.BIN point to the same file, both will be replaced.

Todo:

(You can also replace other files like textures, charts... todo, that's for another guide)

4. Create your ISO patch

Use xdelta3 or another such program to create a patch between the original unmodified ISO and your modified ISO. (see the guide Creating an xdelta3 patch)

Alternatives to an ISO patch (e.g. play from UMD)

Q: Is it possible to use a patch while playing from a UMD or unmodified ISO?

Yes. Your options are:

Misc info

Real hardware testing & results

For these tests:

  • I started with an ISO of Gitaroo Man Lives! US and used UMDGen to relink EBOOT.BIN to point to BOOT.BIN
  • Installed the following official/custom firmware combinations on a PSP-1000 console
  • For each firmware combination, I tested whether the game could boot, load, and play at least partway through a stage
  • I used the "Inferno" UMD driver for each test
PRO-B10.fix1 PRO-C2 LME-2.3
OFW 6.20 ✔️ ✔️ ✔️
OFW 6.35 ✔️ ✔️ (no LME
for this OFW)
OFW 6.39 ✔️ ✔️ ✔️ (LME-10.3)
OFW 6.60 ✔️ ✔️ ✔️
OFW 6.61 (no PRO-B10
for this OFW)
✔️ ✔️
  • OFW: official Sony firmware
  • PRO: the PRO custom firmware
  • LME: the Lite version of Minimal Edition custom firmware

No tests were done on older OFW, nor on older CFW such as M33. Also, no testing was done on other consoles (other PSP hardware versions, PSVita, PS3, etc)

Other PSP games

I may be mistaken, but I am led to believe:

  • some early PSP games run an unencrypted executable anyway
  • many later PSP games dummy out BOOT.BIN

For games without a usable BOOT.BIN, I'd suggest one of the following approaches to make a not-legally-dubious patch:

  • Create a patching script that decrypts EBOOT.BIN (e.g. with deceboot), overwrites the original EBOOT.BIN with the decrypted result, and applies the patch to that
  • Use one of the Alternatives (plugins) listed above