News:

11 March 2016 - Forum Rules

Main Menu

Finding the script in a PSP game

Started by Majorbear, February 12, 2023, 09:12:09 PM

Previous topic - Next topic

Majorbear

Hi, I'm trying to find the text for the Japanese PSP game Super Robot Taisen OG Saga Masoukishin I: The Load of Elementa. I'm kinda new to this, but I did do some nes texting editing for practice.  I want to aleast do a translation of the menus for the game.  I try searching for key words in some of the bin files with a hex editor but no luck.  All the files in the ISO are bin files that I not sure how to open then.

Majorbear

Now that I did more research and learning,  I see that hacking psp iso is very different from nes and snes rom.  I'm still looking thought the game files to find where the menu or texts is for the game.  I read somewhere that I might need to extract the data from the bin files I found in the game.  These are the files in the USRDIR folder of the game.  When I look in files in the hex editor the texts show up unreadable.



How do extract the data from them?  I tried using the Quickbms program but it doesn't have a script for this game. 

[Unknown]

They could be compressed, encrypted, or it could be the menu text is actually only in images.  I'd recommend using PPSSPP and its GE debugger to see how the menu is being drawn by clicking "Step Prim" on that screen.

-[Unknown]

Bunkai

Have you tried tools like astrogrep and monkey moore?

Those help a lot for finding plain text in files.

Monkey moore only works with a file at a time, but with astrogrep you can do folders. (I used those in my projects to find the text)
Curiosity leads to knowledge,
be curious.

Majorbear

Sorry for not updating my progress so long (irl stuff), but thanks Unknown for the advise for where to look for menu text in the game.  I'm using the PPSSPP debugger to see how text is the is load in the game, and I hope to find its location soon.

Also thanks you as well to Bunkai.  I saw your thread about you working on the Digivice PSP game, and I think it will help me with my project as well.  I hope by my next update I finally have some text change or make some progress.  It been an interesting journey so far.

Also how to add images to my posts?  Last time I tried it didn't show up.

Majorbear

After weeks of researching I still cannot find the texts in this the game.  I tried many different methods and still no success of getting to the text.

One of the first thing I tried was using "AstroGrep" to search for any ingame text in the bins files for the game and nothing came up.  I also decrypt the eboot and still found nothing about the text in it.  So I mess around with the debugger and I think I found a texture that the game might loads the text from for the menus, but I don't know which bin file its in.
https://ibb.co/BKZb2kH[/img

But that's all the progress I made far.  So I'm still lost on where to find the texts or menus in the game files.  Does anyone know any other way for me locate the texts or menus?

Bunkai

#6
Quote from: Majorbear on April 27, 2023, 06:31:31 PMAfter weeks of researching I still cannot find the texts in this the game.  I tried many different methods and still no success of getting to the text.

One of the first thing I tried was using "AstroGrep" to search for any ingame text in the bins files for the game and nothing came up.  I also decrypt the eboot and still found nothing about the text in it.  So I mess around with the debugger and I think I found a texture that the game might loads the text from for the menus, but I don't know which bin file its in.

https://ibb.co/BKZb2kH


But that's all the progress I made far.  So I'm still lost on where to find the texts or menus in the game files.  Does anyone know any other way for me to locate the texts or menus?

From that screenshot of yours, that's the uncompressed font, should be complete in a file, you can make a table out of it, but if you haven't found any text is most likely because it's compressed

I tried to take a look at the files and this is what I got from a quick look:

https://ibb.co/vcXBRSx


- Movie folder contains the video scenes, you can work with them using this:
(I tested it working)
https://github.com/Bunkai9448/NHL-07_public/tree/main/Video-pmf

- As you already said, the eboot is compressed, and you'll need deceboot if you eventually want to work with it (haven't seen much at first sight, but I'm far from good at this)

- The at3 file is a sound for the game's miniature, if you want, you can work with it using this:
(I tested this working too)
https://github.com/Bunkai9448/NHL-07_public/tree/main/Soundtrack-info

[Everything I said above was tested with this game iso files, crc32 66b342f4]

I hope this helps.

PS: to make images appear embeded put the full url with the image extension, like this
[ img ]https: //imgbb .com/vcXBRSx .png [ /img]
But without spaces
Curiosity leads to knowledge,
be curious.

Majorbear

#7
Thanks for the tip about the text may be compress in the files.  To make sure, I took a look at the first scene in the game with the debugger.


https://ibb.co/5BZM86W
It seems the game load the text the same way its loads for the menus too.  But I'm mostly focusing on doing the menus to get better at this hacking thing.  So is my next step is to find a way to uncompressed the text and make a table file to find it?  I want to make sure is I'm on the right path to finally start hacking the game.

[Unknown]

Finding the drawing of the letters is a good first step - sometimes menus may have the word as an image, rather than individual letters.  This game may still do that in some places, as a warning.

What I'd do next is:

1. Pause PPSSPP using Break in the Disassembly window.
2. Create a save state.  This will be your "base" save state for searching for the text.
3. In the GE debugger, click Step Prim.  It won't work yet, because the CPU is still in the Break state.  That's okay.
4. After clicking step in the GE debugger, resume the CPU from the Disassembly.
5. Find the draw again (you can use Step Count to skip ahead.)
6. If you accidentally pass it, hit Resume in the GE debugger and Break again from the Dissasembly.  Then load the save state.  Go back to step 3 - make sure you start stepping in the GE debugger first, before you unbreak the CPU.
7. Look at the VADDR above the draw (for example, 09bccf40 in your previous screenshot - but it's likely to vary each frame.)

After you do this, you'll have two useful things:
1. A save state which is likely before the game translated its text into drawing commands.
2. The address of where these drawing commands were written.

We still haven't found the text yet, but we can use these together to search for the text.  This time, it'll be using the Disassembly, so things get a bit trickier:

1. Again, start with the CPU in Break state and the GE debugger resumed.
2. Load your base save state.
3. Click the Breakpoint button and paste the vertex address (VADDR) we got before into the address field.  Size should be 0x50 in this case (that's the size of 4 vertices.)  Uncheck Read - we only care about Write.
4. Now click Go to unbreak the CPU.

When it breaks, if you're lucky, we'll have found where it's writing the vertex data.  You may find Ghidra useful at this point, but you should also look at the "Stack frames" tab in PPSSPP's Disassembly.  It could be that the function you land in is responsible for reading the text, but it could also be the function that called this one (next one in Stack frames.)

The trick I like to do at this point is to use breakpoints even more to verify things:

1. First, go to the Breakpoints tab in the Disassembly and uncheck the breakpoint we added earlier.  This will prevent it from breaking next time it is hit.
2. Next, scroll up in the disassembly window until the color changes above the cursor.  Usually, it'll be on a line that looks like "addiu sp,sp,-0x10" or similar.
3. Double click on that first line within the same color you landed in.  This will set a breakpoint at the start of the function.
4. Click Go and keep doing so to see how often this function is hit.  Usually, after you hit it enough times, you'll hear a bit of sound as the frame advances.
5. You can repeat these steps (starting with loading the save state in the Break state) with a one of the functions higher up the "Stack frames" list.

If you find a function that gets called about as many times as there are words or sentences on the screen, congratulations.  You've most likely found a function very involved in drawing text to the screen.  Armed with your breakpoint at the start of the func:

1. Hit Go until it is hit again.
2. If you're lucky, one of the "argument" registers may directly point to the string in memory.
3. You can check this by right clicking any of the "a0", "a1", etc. registers and selecting "Go to in Memory View".
4. This might work for any of a0-a3 or t0-t3 (technically all 8 are used for function arguments.)
5. Sometimes, the text might not be so obvious as in a register.  In this case, you might have to look at the MIPS code or Ghidra decompile to figure out where the text might be.

Ultimately, if you can find the text in memory, keep in mind it may not be "readable."  For example, it may use a simple "code" where 1 = A, 2 = B, 3 = C, etc.  So the text you find might look like this in a hex viewer:

01 02 03 00

But that might actually mean "ABC".  Since you have the texture, if it uses this strategy, you know what the code is - it's the same order the letters are in the texture.  However, it might actually use "regular" text and translate to the texture's code inside the function.  I've seen games do it both ways, so it just depends.

Once you do find the address the text is at, you can use Memory View and select "Show writes" to see if it can tell you where that data was loaded from - if you're lucky, it can tell you what file.  It doesn't always know, though.  If it doesn't, you can use the same strategy we used to find the author of the vertex data to find what function writes that data into memory.  You'll probably have to use a different base save state through - it probably doesn't load the text every frame, so you'll need to start before a loading scene for that.

This may sound a bit complex, but it's not that hard if you're patient with it.  I find it's usually the fastest method of finding these things.

Another method would be to export the RAM to a file (Memory View -> right click) and look for the text inside there.  This may be faster and is worth trying first, but since we're not certain about the "code" the game uses for text, it depends on getting lucky for that way to work.

-[Unknown]

Majorbear

Using the instructions you gave me, I use the VADDR address of bcc840 => 09bcc840 to search where the text is drawing from.  When I did the breakpoint, its point me to this address:
https://ibb.co/xY5h8ZL

So I assume this is where the text is writing from?  Using this address, I went to the memory viewer like you said and type it in search and I it point me to this location.
https://ibb.co/4KtmdLW

Next thing I tried is export the RAM to file and search for the text in it.  Using AstroGrep I didn't find anything useful in it.  I got a little lost about the part finding the function for the text, but I'm going to try it again to make doing it right.
Hopefully I'm on the right track to finding the text.  Should I be using Ghidra next to find which files have the text in it?
Thank you for all the help Unknown so far.  I have no programmer skills and very new to romhacking, but I really want learn how do this.  I hope if get better it and turn this to my first big project and do a full translation for the game.  Thanks again.

P.S. I'm not very good adding images to my posts

[Unknown]

Did you make sure the breakpoint was "Write" and not "Read"?  It looks like that's after submitting the display list, which probably only read the vertex address.  If that's the first time it tripped, it may mean that the data was written farther back.

You can see immediately above your cursor is "jal zz_sceGeListUpdateStallAddr".  This is how the game tells the GE (the PSP's GPU) that there's more things to draw.

The part where you see "lw a0, 0x18(a0)" is where the game loads some data from memory into a register (basically, a variable.)  But in this case, that data is just the "display list ID".  The way graphic commands are communicated to the GE is using "display lists" which are basically a list of things to draw to the screen.

Ghidra may also be a useful tool.  If you use it, you'll want to use this plugin:
https://github.com/kotcrab/ghidra-allegrex

-[Unknown]

Majorbear

I double check the breakpoint and that's what I was getting, unless I'm doing something wrong.  I have Ghidra install, but I'm not which file to check.  Most the bin files don't have an extension on them when I look at them with a hex editor.  The Eboot have the elf extension in it when I look into it with the hex editor, and I know Ghidra can read it.  So what should be looking for with Ghidra?

Arc_Impulse

I've took a peek into this before in the past, so I can chime in a bit sure, and I believe most of this carries across to the second game as well as they're the same engine. If you want to try editing menu text you can find some over in \USRDIR\MESS.BIN, do a search for "NEXT" and you'll find the text for the label for the "EXP to next level" bit in the in-battle status menu. Same while in the debugger, though you may need to search through multiple copies to find the original. There's more to it than that in terms of proper dumping, but that has bigger issues I'll mention shortly anyway. So the game does support at least ASCII in terms of reading text, though I couldn't say if the half-width sizing is fixed or due to preset widths in any way or not. As an example:


In this case, if you look at the other stuff around that NEXT and example you'll also see that the game isn't using a standard encoding, it's using 0x1F to end strings and taking characters in order of where it appears in the font, which doesn't look to be in the usual order once it hits the kanji (with some exceptions before then as well). So as an example, 0x0100 is a small あ, 0x0101 is regular あ, 0x0102 is small い, and so on. Prior to that on the font is all single byte characters, like 0x95 being half of the MAP icon. Here's an example to show this using the setup from the start of the kana portion of the font:


As such, the main issue is likely in dumping text since I didn't see anything in the files at the time that isn't an image that could be pulled to make a table file. If it's a different encoding, it's not one I know anyways, but I included a bigger version of the font sheet that came up in the graphics debugger Here as well as a more readable version below in case anyone does recognize it as another, unsure on if there's others though. I'd wager it's likely ordered by something like frequency of use however. Worst case scenario, you could look at the font to find out the character order to make a table file for the MK games, which would be less than ideal when it comes to the kanji portion.

Majorbear

Thanks for tips about the text in the game.  The last few weeks I have researching how to use Ghidra and seeing what other skills I was lacking to help with this.  I found out that knowing a little Assembly might help me to use the disassembly in PPSSP better.  The font table you have is also the one I found as well in the game.  The last thing I was working on was trying to find where the table was location in the files.  I found the memory address for it but not what file it's in.  I'll check the file you mention to see if I can find anything else in it.