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

[47iscool]

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

he just inquiring about your irregular method ps2 hacking

Well, is there any other method to make PS2 ASM codes? And yes I know he's one of the best.

And by the way, as I've mentioned in another post before, this isn't my method. Guess I should have posted that info too.

[lee4]

You talking about Azagthoth's Cheat Engine with PCSX2 Emulator Tutorial
cheat engine 6.1 with pcsx2 tutorial.doc
right?

[47iscool]

You talking about Azagthoth's Cheat Engine with PCSX2 Emulator Tutorial
cheat engine 6.1 with pcsx2 tutorial.doc
right?

That's the one.

[lee4]

you didnt mention about step on last 5 pages of Tutorial
which makes more sense

[47iscool]

you didnt mention about step on last 5 pages of Tutorial
which makes more sense

I kind of rushed through it a bit (when I read it I didn't read all of it). Someone else would be better suited to write an article/tutorial.

[Pyriel]

Now, see in that document Azagthoth gets back what I'd expect to see, i.e., the, "mov [ecx], edx." Your results look nothing like that, and I still sort of expect that's to do with the VEH debugger. I assume what that debugger does is protects the address you specify, and registers its own code as an exception handler for the process. Cheat Engine receives communications from the exception handler; that comes with some overhead, and depending on how well implemented it is, it may or may not be showing you unrelated rubbish in the disassembly.

Looking at the function you NOPed, it appears to be part of a smallish state machine. It may well be related to ammo, but I don't see any code that I would designate as likely candidates for updating the ammo value. The function is little more than a switch statement that stores hard-coded values on the stack. Given the call you NOPed anyway. Other callers could be having it store values in a more permanent way. The function might be related to management of ammunition, but I'm thinking that NOPing it will have unsatisfactory side effects. I would probably look to 0x00128E50 for ammo management as a start.

I don't feel like installing PCSX2 and dragging out a game to test this. I don't own that game anyway, so I'd be working on something else, hoping that the results are comparable.

[47iscool]

The address 0x00128E50 has a value of 27BDFFC0. What value should I change it to?

I set it to 00000000 and nothing happened.

[Pyriel]

Well, I was suggesting the function that begins there as a starting point for analysis, not that specific address. It's just a guess, but you could see what 20128EF8 00000000 does.

Edit: Might be ammo, health, or nothing useful.

[47iscool]

Well, I was suggesting the function that begins there as a starting point for analysis, not that specific address. It's just a guess, but you could see what 20128EF8 00000000 does.

Edit: Might be ammo, health, or nothing useful.

I didn't notice anything different. Ammo and health still decrease.

BTW you could understand that doc that lee4 posted better than I could.

If you wanted to you could write a better, more detailed guide than I did.

I was trying to simplify things for those who are new to ASM hacking, it may not be the best way to do it but it works most of the time for me. And speaking of JAL's, usually, for most of the games I've hacked, going back about 8 addresses usually show a JAL but not always. Sometimes I've had to go forward to find something that works.

[Pyriel]

Can't say I'm surprised. Your values for Ammo in the screenshots are kind of whacky.

Yeah, this thing may be narrowing you down to the vicinity. I just expect a breakpoint to be either immediately followed or preceded by the operation I wanted it to break on. Maybe a bit further removed if the processor has weird timings for jumps. As far as I can tell, CE's VEH debugger landed you who knows where, but possibly in the vicinity of something helpful. If Hacc or somebody else has the game and a desire to look into this, maybe my questions can be answered. Otherwise, I think there's a huge disclaimer on this that it takes a bit of guesswork and may not always work as intended.

To be clear, I think it's some limitations of CE and the fact that PCSX2 is an emulator that introduce the uncertainty. Something similar to what you're doing would work perfectly in PCSX2's built-in debugger or on real hardware with a debugger attached.

[Hacc]

Unfortunately, I don't have the game. He can try the 0.9.2 debugger (hopefully it can emulate the game in a usable fashion), or that PCSX2 Breakpoint Tool. I'll link the newer PCSX2 debugger ASAP (I haven't heard from the person yet).

[47iscool]

I have tried the 0.9.2 debugger before, but if IIRC it froze when I tried to set a BP. I gave up on ASM hacking until I found the other tutorial.

Also, even though my PC can't run pcsx2 at full speed, 0.9.2 is even slower. The speed hacks are very helpful.

[lee4]

I'll link the newer PCSX2 debugger ASAP (I haven't heard from the person yet).

that too bad
I hope he reply back soon

[lee4]

Also, even though my PC can't run pcsx2 at full speed, 0.9.2 is even slower. The speed hacks are very helpful.

old pcsx2 0.9.2 need cpu of 3.6 Ghz dualcore.
meanwhile new Pcsx2 1.0+ run on 2.0 GHz Cpu.

[Hacc]

PCSX2 1.2.1 (Debug Build)

This build was built courtesy of Blyss Sarania and given by a good friend. The debug controls readme is located in the "docs" folder. It was built with Visual C++ 2013. You need to install it from here: Visual Studio 2013. You'll also need to install Visual Studio Express 2013 (there should be a way to avoid this, IIRC), as this build requires the following DLLs to launch: msvcr120d and msvcp120d. These DLLs are not allowed to be redistributed, but I'm sure the determined individuals will overcome this with ease.

Good Will Debugging!

Update: the debugger is enabled by default now. Download: http://buildbot.orphis.net/pcsx2/