Hacking PSP debugging

[GarudaKarura]

Hello.
I'm new to this forum as well as new to Psp asm.
I've used the PPSSPP debugger but I have some questions:

1. There's a file located at LBA 611616 corresponding to 611616 x 2048 =1252589568 or 0x4AA90000 in the Iso. I want to set a read breakpoint to know when the game read this address. So which address I should set? I mean PSP address.

2. How to log execution codes with PPSSPP?

Thank you for reading.

 

[flame1234]

There are logging options in PPSSPP. Play with them. Try "verbose" options.

There are the built-in functions called syscalls.
To see them, go to the debugger, click funcs and scroll to the bottom.

You could do it the dumb way:
1) Set breakpoint on sceIOReadAsync syscall. Or something. One of the sceIO syscalls is going to be reading the data in your game. One of the parameters is the LBA.
2) Hit the go button a bunch of times until the data you want is about to be read.
3) Hit "Step Out" and you will be at the point in the program where that data was just loaded. Or you could hit RA and backtrace the function that's specifying LBA, data size, and target position.

The smart way I don't know.

 

[GarudaKarura]

Thank you for replying.
There's a Disassembly windows, and in Funcs tab I don't see the syscall.

Also, when setting a breakpoint, I see only 4 options available: write, write, execution, on changes.
How to set on sceIOReadAsync syscall?

 

[flame1234]

click funcs and scroll to the bottom
you do see the scroll bar, right?

double click on a function to jump the disasm there
double click a disasm instruction to set a breakpoint there (execution breakpoint)

 

[GarudaKarura]

Oh thank you very much. I found it.
Actually I was thinking there's a function called "syscall". Shame on me.

 

[SkyBladeCloud]

Oh thank you very much. I found it.
Actually I was thinking there's a function called "syscall". Shame on me.

Yeah, I was expecting the same when I first used a PSP debugger.
Now if what you need is to see how the program uses a given file, I'd suggest:

-Play on the emulator until that file is loaded, then dump the memory to a file.
-Examine the dump and search for your data on a hex editor.
-Calculate (predict) the memory address your data will be placed on, during the game's execution.
***The PSP's user memory space starts at 0x08800000, so if that's what you dumped, you need to add 0x08800000 to the address you data is on the dump.
-Place a memory breakpoint (read or write, depending on your needs) in the predicted address.
-Restart the game and play again until your file is loaded again.
***Since this time you have a memory breakpoint set, the execution will break on the instruction that reads/writes your file, so you can trace its usage from there.
***If it breaks before, it's obviously because some other memory operation is using that same address, in that case just continue the execution.

Your approach of breaking on sceIOReadAsync should also work (I'd also add a breakpoint on sceIORead, since I'm never sure which one is used at the first try), but it may be a little bit more confusing, since it would break more often. Also, your file is loaded as part of a batch, the syscall has to be executed at least one for each, so you would have to be viewing the memory for each one to make sure it's the file you're looking for.

Hope it helps!

~Sky

 

[GarudaKarura]

Thank you Sky.
I'm using the method as you tell, dump the Memory ram, search the value address + 8800000 then set break point on that address.
However,

-Restart the game and play again until your file is loaded again.

this may not work because the PSP uses dynamic memory so the address changes each time. The best way is to have a save state before searching.

I'm pretty new to the PSP, so if the game snap on break point I set, I must back track the code but how can I tell which LBA was loaded?
Btw, is there any way to log the executed code to a txt file, like many Snes debuggers out there do?

 

[SkyBladeCloud]

Thank you Sky.
I'm using the method as you tell, dump the Memory ram, search the value address + 8800000 then set break point on that address.
However,


this may not work because the PSP uses dynamic memory so the address changes each time. The best way is to have a save state before searching.

...

Actually no, the PSP doesn't use ASLR or any kind of random memory protection, so in most cases the addresses are predictable. In fact this is why cheating on PSP only involves one memory address and one value to overwrite. It is true that some games (Star Oncean I/II, IIRC) have anti-cheat methods, so address can't be predicted that easily. In some other cases (such as Dissidia 012) the exact file to be loaded depends on the current date, and since different files have different sizes, the exact placement of the data may be different today and tomorrow... So unless some special trickery is involved, you should be able to predict the address where your file will end up. This is, of course, as long as you do exactly the same on both debugging sessions. For example, if instead of restarting the game, you go back to the main menu and then go where your file is loaded again, the dynamic nature of the memory will indeed place it somewhere else (wherever the PSP finds a free memory block, which in turn depends on the previously executed code...).

Still, a savestate will save you some time, so using it is a good idea

As for your question about the LBA, I don't relly know what you're trying to do. You already know that each UMD sector is 0x800 bytes (2Kb) so it's trivial to know the sector a file is placed in. My guess is that your game uses a custom filesystem (maybe a bigfile + custom format LBA and you want to decode the LBA format??? If that's the case I would place the memory breakpoint on the LBA data, so I could trace the ASM code that calculated offsets and sized on the bigfile).

...

 

[GarudaKarura]

Sorry to ask such basic things. but I'm new to the Mips asm so there're many things I should ask.
What I was mean is: I already located the data in memory, say this dialogue at $9DE0483

I set write breakpoint only because I want to know where the CPU gets the data to write in Ram.

(Actually there's no log file in the PSP folder. Just shown on the debug console)

Then the game snap like this

So it starts writting data to Ram at excution position: $8A75504

MOVE s1, v0

If my understanding not go wrong, this copy valua from register v0 and store it to register s1. Since v0 is 0x00000000 so the s1 becomes zero after that.
From here, how do I know which LBA the data was loaded from?

(Actually I alreay know this dialogue locates at LBA 611616, just want to know through debugged codes)

 

[SkyBladeCloud]

Alright as far as I can see, you memory breakpoint was triggered not by "MOVE s1, v0", but instead by "sceIOReadAsync", so my guess is that the syscall reads data straight from the UMD into a memory block that includes the position specified on your breakpoint. Now the execution breaks a couple of instructions later because this MIPS architecture is pipelined and that "lw" instructions right after the jump to the syscall, is actually executed before the syscall.
Now if you have a look at the PSP MIPS documentation (ot the PPSSPP source code), you'll find the arguments that each syscall takes. IIRC (of course I can't remember all arguments for all syscalls), register $a0 should contain the UMD sector (your LBA) upon reading... Otherwise just have a look at the rest and see if you can find the LBA there.

Another option would be placing an execution breakpoint at the beginning of the routine (zz_un_08a754d8) and trace the execution down until you find where the program gets the LBA from.

Regards:

~Sky

 

[GarudaKarura]

Another problem: this game use a proportional font (variable width font).
Then how to find the vwf address using debugger?
I think it lays in GE debugger but not sure.

For example, when the game draws letter "K" it must look somewhere for the width table and stores this value somewhere in Vram?

 

[flame1234]

It's weird to draw the same thing over and over (that's what this looks like).

Look for the thread that writes the vertex data.
Set your breakpoint on the vaddr. vaddr means vertex address.
You might want to look for the vertex format recipe by stepping through the display list. Looks like "through, ABGR 8888 colors, s16 texcoords, s16 positions"
Basically it tells you whether your texcoords or positions or both are float or s16.
I'm not sure exactly the vertex data format but texcoords appear first and positions last, and x-data before y.

If it doesn't change every frame, you should find it without a problem.

At some point it's adding to x-position, which then gets written in the vertex data. You can find that addition and change it.
You need to explore the code to find out where those values are coming from.
You can probably replace the lookup call with an li to make sure you've identified it correctly.

 

[GarudaKarura]

Thank you very much.
I searched through the memory and found where the coord data the game reads from.

 

[GarudaKarura]

Usually the translation will have more text than original one. So the text file size increase, pushes the address after it forward, causing crashing when played.

For PSX game, I use TOC change to move the text file to unused sectors/LBA.

For PSP, I wonder how can one solve this problem?

 

[GarudaKarura]

I want to track when $t1 is written with a specific value.
For example, $t1 hold an important data to me, which value is 990CD28.

In this case, how do I set the breakpoint that it should snap when this value is written to $t1?