Tutorial for creating ASM codes for PS2 with Cheat Engine and pcsx2

[47iscool]

First, hook pcsx2 up to Cheat Engine and set memory range from 0x20000000-0x22000000. Cheat engine can find actual addresses that can be used on a real PS2.

Example address:

Real PS2 RAM 0x00350000
PCSX2 RAM 0x20350000

But you were wondering how to make ASM codes right? Simple, I'll explain. RE4 as the example game:

1. Find your value, in this case ammo.


2. Open up the memory viewer and set a write (or read) breakpoint on the address.


3. Fire your weapon and look at the ESI register. That is what you want right there. Also remember to add a 2 to the beginning of of the address.


4. Most of the time you will need to go back a few addresses to get something that works, usually a JAL. The ammo address it gave me was 00120010. So to get it to work I added this in CE's list: 20120008 00000000. Also note that the address will not take effect immediately.

To see if if works, BEFORE you change the ASM value make a save state. After you've made a save state freeze the code in CE's list after you've changed the value and reload the save state. In this example the code gives you infinite ammo.


One last thing: Make sure to use the VEH debugger or it may crash when attaching the debugger.

[Hacc]

EIP! I announce you as the ambassador of Cheat Engine. You've been ESP active with it lately. <- CE what I did there! :P

All joking aside, a nice little guide you have there. I think that ESI register is the RA in MIPS. You subtract 8 from the RA after the game halts, and it's usually a JAL, too. You do know that there is a debugger in PCSX2 now, right? I haven't tried it yet. Still static debugging over here.

[47iscool]

EIP! I announce you as the ambassador of Cheat Engine. You've been ESP active with it lately. <- CE what I did there! :P

All joking aside, a nice little guide you have there. I think that ESI register is the RA in MIPS. You subtract 8 from the RA after the game halts, and it's usually a JAL, too. You do know that there is a debugger in PCSX2 now, right? I haven't tried it yet. Still static debugging over here.

I'm assuming you mean real address right?

Anyways, the great thing about pcsx2 is that the RAM addresses never change so if it freezes you can get right back to it after restarting or reloading a save state. And no I didn't know that that it had a debugger now.

Honestly though if I could use CE's debugging features on every emulator I would.

[Hacc]

No; RA for Return Address.

Indeed it is. The new debugger was released a few months ago and is updated over time (check the Orphis SVN page for PCSX2).

I'm certain that you would.

[lee4]

can post a link to this debugger build?

I see no debugger on Orphisbot page

[47iscool]

No; RA for Return Address.

Indeed it is. The new debugger was released a few months ago and is updated over time (check the Orphis SVN page for PCSX2).

I'm certain that you would.

I doubt theirs can beat CE's debugger, no offense to them as it is a great emulator. Dolphin on the other hand while it runs faster on some games it isn't to stable when loading save states for some games. Namely those that use the mmu.

[Hacc]

can post a link to this debugger build?

I see no debugger on Orphisbot page

PCSX2 needs to be compiled with the "DEBUG" flag from the source. I'll link one a bit later from a friend. You can request one from Blyss over at the PCSX2 forums, though: Source:

http://forums.pcsx2.net/Thread-PCSX2-GIT-Weekly-Builds

I doubt theirs can beat CE's debugger, no offense to them as it is a great emulator. Dolphin on the other hand while it runs faster on some games it isn't to stable when loading save states for some games. Namely those that use the mmu.

It seems to work pretty fine. koolaidman over at Jul has had success with it so far:

http://jul.rustedlogic.net/thread.php?id=17183

That thread reminded me about some MMX7 hacks I made long ago.

[lee4]

PCSX2 needs to be compiled with the "DEBUG" flag from the source.

That is useless then.

I'll link one a bit later from a friend.

Please do

You can request one from Blyss over at the PCSX2 forums.

No thanks.

[Pyriel]

How does the VEH debugger work? What I'm seeing in your screen shots leads me to believe that the data being communicated back is passed out of their exception handler, and you're not actually peeking into PCSX2 directly when the breakpoint hits. If that's the case, you're viewing a snapshot of information that's 2-3 degrees removed from what would actually happen on a PS2. It seems useful in this context, I'm just thinking there might not be an easy way to use this technique for more complex codes. Certainly you've had to resort to a small amount of targeted hunting-and-pecking to make a simple code.

How do you know what you're replacing is "usually a JAL"? I don't see anything that resembles a PS2 write operation in the screenshots, nor do I see an x86 op that immediately screams store. Can you provide a shot of the PS2 memory indicated by the PC/ESI register, i.e., +/- about 40 bytes around 0x20120010?

[47iscool]

How does the VEH debugger work? What I'm seeing in your screen shots leads me to believe that the data being communicated back is passed out of their exception handler, and you're not actually peeking into PCSX2 directly when the breakpoint hits. If that's the case, you're viewing a snapshot of information that's 2-3 degrees removed from what would actually happen on a PS2. It seems useful in this context, I'm just thinking there might not be an easy way to use this technique for more complex codes. Certainly you've had to resort to a small amount of targeted hunting-and-pecking to make a simple code.

How do you know what you're replacing is "usually a JAL"? I don't see anything that resembles a PS2 write operation in the screenshots, nor do I see an x86 op that immediately screams store. Can you provide a shot of the PS2 memory indicated by the PC/ESI register, i.e., +/- about 40 bytes around 0x20120010?

The VEH debugger can be selected in CE's options.

How do I know it's a JAL? Well the JAL value on MIPS is usually starts with "0C"

Also yes, sometimes I have to go a good bit back to find what I'm after. Only in small cases though. Way of The Samurai's walk though walls code I made is one example of going back a good bit to get something that works.

And a shot of some addresses:

And another...


The hardest code I've ever made was a walk though walls and on air at the same time. If not for the walk on air code you would fall right through the ground because of the way the game handles clipping. And that code was made using this method.

It may not be spot on, on what address it gives you, but it's one way of making ASM codes for PS2. And it's pretty simple for someone like me who's only been hacking for a few years now.

[Pyriel]

Yeah, I wasn't asking how to find the VEH debugger in the menus, and I asked, "how do you know it's usually a JAL?" not, "how do you identify a JAL?" When you say "usually", it sounds like you've done some sort of analysis on at least dozens of games.

Here's why I'm questioning it. Quickly glancing through your memory dump, there's not a single write operation there until 0x201200AC. It's possible that the break occurred while emulating inside the MIPS function called two ops before the value in ESI, but you've not done any analysis to know that's true. Furthermore, there's an access (LHU) at 0x20120004, so I'm wondering if the emulator isn't storing back to the address for some reason, and the break is actually occurring after 0x20120004 is interpreted and before 0x2012000C for some reason. (Possible lag in the exception handling?) Or that your screenshot is inaccurate and you set a read breakpoint.

Like I said before, I don't see anything in the x86 disassembly that seems to be storing the new value of ammo at the address you discovered. Maybe it broke after writing, but it give me pause.

If you can provide the ELF, I or someone else can possibly check into it. My thinking at this point is that this method might be inconsistent, depending on how accurate your screenshots are.

[47iscool]

Resident Evil 4 SLUS-21134 ELF file:https://www.firedrive.com/file/76B26703B1D803D7

Anyways, I'm not as experienced as much as you and others are. If it works on a real PS2 then it's a method worth using right?

Also I don't understand what you mean by this:

depending on how accurate your screenshots are

[Pyriel]

Well, your screenshot shows you setting a write breakpoint, but if you actually set an on-access breakpoint, then most of my confusion about the debugger is unwarranted. It's still providing somewhat inaccurate information, but not by as much as it would seem at first glance.

Generally speaking, if it works, it's useful. However, if it's not repeatable then it's not very helpful as a guide for others. Like the guy on CMP back in the day who was using byte and halfword commands to overwrite operations, inadvertently replacing mundane stuff with multimedia operations. For some reason it worked and produced some novel effects, but I wouldn't recommend it as a method.

[47iscool]

Well, your screenshot shows you setting a write breakpoint, but if you actually set an on-access breakpoint, then most of my confusion about the debugger is unwarranted. It's still providing somewhat inaccurate information, but not by as much as it would seem at first glance.

Generally speaking, if it works, it's useful. However, if it's not repeatable then it's not very helpful as a guide for others. Like the guy on CMP back in the day who was using byte and halfword commands to overwrite operations, inadvertently replacing mundane stuff with multimedia operations. For some reason it worked and produced some novel effects, but I wouldn't recommend it as a method.

Why not try it out yourself?

Well I noticed Nolberto82 has made a few ASM PS2 codes. Maybe he found another method that were not aware of. Maybe you should ask him since he's one of the top hackers and knows a lot more about hacking than me.

[lee4]

you are disputing to the one of greatest PS2 ASM hacker Pyriel

he just inquiring about your irregular method ps2 hacking