Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


Changing value that is written every frame

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking
View previous topic :: View next topic  
Author Message
descatal
Newbie cheater
Reputation: 0

Joined: 28 Jul 2019
Posts: 18

PostPosted: Sat Sep 14, 2019 9:53 am    Post subject: Changing value that is written every frame Reply with quote

Hi guys, not sure if I should post this under the Console modding section since this is related to RPCS3 (PS3 emulator hacking), so please forgive me if I posted this in the wrong section.

The game that I am trying to hack has two versions, 1.00 and 1.10 (with DLCs).
On the 1.00 version, there is a 2 byte address responding to every button input the player makes. The button that is important in this context is the messaging/command button (default L1), which when pressed, will change the 2 byte address I mentioned above to (02 00).
The thing is by changing that value from (02 00) to (01 00), the player is able to use some of the CPU-exclusive attacks, which is not normally viable. Turns out there is an instruction that was called every time whenever the player press the messaging/command button, which writes the value (02 00) to the 2 byte, and above the write instruction, there is an OR [rax, 200] instruction which I can be easily modified into 100 using code injection.

Here's the kicker tho, update 1.10 completely hides this instruction away from the address. There's only one address that is constantly trying to write to the address every frame, and upon further investigation, is just a "mover" instruction that moves the (02 00) value from other places. When trying to determine where the (02 00) came from, I tried backtracking the instruction but with no avail. It seems like the value came from a rapidly changing temporary address that is impossible to trace. I tried to find other instruction that is hidden behind the code that writes the (02 00) value by AoB scans, but there's no effect by modifying all the values that has OR [rax, 200] instruction.

So that leaves me with one option, that is trying to change the value and brute force my way into glory. However, with the instruction writing multiple times every frame, when I try to write a debug Lua script that only changes the register when a specific condition is met (value = 02 00), the game lags tremendously (unplayable) while trying to go through all the write function through the lua script.

Now left with no other options, I now turn to this forum to seek help regarding this issue. Thank you for your time.



Untitled3.png
 Description:
All the AoB scan results that I got for searching those OR [eax, 200] function in 1.10 version. None of the instructions are related to the button input address.
 Filesize:  52.64 KB
 Viewed:  6875 Time(s)

Untitled3.png



Untitled2.png
 Description:
Looking inside the "mover" instruction that writes to the 2 byte address in 1.10 version. Note the lack of OR [rax, 200] instruction
 Filesize:  26.5 KB
 Viewed:  6875 Time(s)

Untitled2.png



Annotation 2019-09-14 233224.png
 Description:
The only "mover" instruction that writes to the 2 byte address in 1.10 version, regardless of button input or not.
 Filesize:  4.91 KB
 Viewed:  6875 Time(s)

Annotation 2019-09-14 233224.png



Untitled.png
 Description:
Two of the instructions that is trying to write the 2 byte address on 1.00 version
 Filesize:  8.94 KB
 Viewed:  6875 Time(s)

Untitled.png



Annotation 2019-09-14 230839.png
 Description:
The OR [rax, 200] instruction before the crc32 write below on version 1.00, which can easily be modified to 100 by code injection.
 Filesize:  6.93 KB
 Viewed:  6875 Time(s)

Annotation 2019-09-14 230839.png


Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 138

Joined: 06 Jul 2014
Posts: 4275

PostPosted: Sun Sep 15, 2019 10:16 am    Post subject: Reply with quote

In Untitled3.png, you're only scanning through writable memory. Swap the executable and writable checkboxes (check executable, grey writable). Also, the instruction in v1.10 that uses the immediate 0x200 might not use the same register or the same opcode as was used in v1.0.

The crc32 instruction doesn't write to any address AFAIK. Data breakpoints (i.e. break-on-write) trigger after the instruction has executed, and CE sometimes guesses wrong. Figure out which instruction wrote to it by correlating the value's address with register values at the time of execution.

As for backtracing, you could try scrolling up and/or using CE's "dissect code" feature to find jumps and calls (figure out which instruction wrote to it first). You may need to use Lua if the code lies in dynamically allocated memory. Search for "getDissectCode" for more information.

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
descatal
Newbie cheater
Reputation: 0

Joined: 28 Jul 2019
Posts: 18

PostPosted: Mon Sep 16, 2019 3:01 am    Post subject: Reply with quote

Thank you for the help again Parkour.

I tried all three method you asked. My steps might be wrong.

1. Finding Executable and non-Writable addresses - Did not work, the opcodes used might be different as you theorized.

2. May I ask what is a crc32 instruction exactly? I tried making sense of it when I started to hack the game but with no avail. I just treat it as a "move/write/read" instruction since it is so common when I am trying to figure out which address is currently writing/reading from the address of interest.

As for figuring out the address in the instruction, the crc32 r9d,[r8+rax] instruction in Untitled2.jpg is the one that has the correct address to my (02 00) address. So I am fairly confident that the crc32 instruction is responsible for the "writing" of the address.

3. Sorry if I got this wrong, can't find much info on the function online. I tried to use the getDissectCode function with the .dissect(base, size) function on the range and size of the memory region that the instruction is located in, and getReference(address) on the instruction's address, but it returns a nil value. Am I doing anything wrong?

As for scrolling up and finding what writes to the register that writes to the 02 00 address, the instruction of mov r9d, [rcx+000000A8] is the one. However, the address rcx + 000000A8 is a temporary memory area where hundreds of bytes are written every second on the same address, and on top of the fact that the whole section of instruction from 152C1B14 onward runs multiple times per frame to update/populate the surrounding area of the 02 00 address, it is quite hard to trace down what address writes to the rcx + 000000A8 address.
Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 138

Joined: 06 Jul 2014
Posts: 4275

PostPosted: Mon Sep 16, 2019 9:50 am    Post subject: Reply with quote

I found the problem- it's a CE bug. I guess CE isn't aware of the movbe instruction.

descatal wrote:
May I ask what is a crc32 instruction exactly?
It's a cyclic redundancy check. Basically, it uses math to make sure data wasn't accidentally modified by some outside source. However, that's no longer relevant since that's not actually a crc32 instruction.

descatal wrote:
I tried to use the getDissectCode function with the .dissect(base, size) function on the range and size of the memory region that the instruction is located in, and getReference(address) on the instruction's address, but it returns a nil value. Am I doing anything wrong?
Just calling dissect is enough. The disassembler will then be populated with symbols on the left that show where an instruction is being called or jumped from (where relevant). You may want to do the same for the main .exe as well.

descatal wrote:
However, the address rcx + 000000A8 is a temporary memory area where hundreds of bytes are written every second on the same address, and on top of the fact that the whole section of instruction from 152C1B14 onward runs multiple times per frame to update/populate the surrounding area of the 02 00 address, it is quite hard to trace down what address writes to the rcx + 000000A8 address.
It's an emulator, so I'm not surprised it can be difficult.
I'd just scroll up and look for any write to rcx+A8. If something writes to rcx, use that register instead (i.e. mov rcx,rax -> look for rax+A8 from that point up; this can get complicated fast). Also follow any jumps or calls found by dissect code. If you go outside that function, you'll need to know basic calling conventions- at least which registers are used to pass arguments around.
If the emulator is open source, you may want to build and debug it yourself using gdb or some IDE equivalent.

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
descatal
Newbie cheater
Reputation: 0

Joined: 28 Jul 2019
Posts: 18

PostPosted: Sat Sep 21, 2019 6:14 am    Post subject: Reply with quote

Sorry for the late reply, been busy these whole week.

Thank you very much for the reply.

So the crc32 is movbe, that explains a lot, since the bytes in my memory viewer is in big endian. Let's see if this is going to be fixed soon.

I tried your method on back-tracing by dissecting the code, it worked, but I was not able to determine the true nature where the code comes from. Like you said, it gets complicated too quickly, and I have a hard time following each call and jumps.

Fortunately I am able to find a solution to the problem. It is not related to CE, but rpcs3 itself. I uninstalled the game the other day due to some complications and reinstalled it, and after that the "hiding" instructions are gone! I don't know what happened, but the 1.10 version functions exactly the same as 1.00 version now. However, sometimes the "hiding" instruction will appear on some occasion, but restarting the match / game fixes the problem. I just think I got very lucky in terms of going down the rabbit hole of trying to mod a game through emulator.

As for the dissect code you mentioned, I have been able to use it on other endeavors, which I had successfully found the byte I am looking for. So thank you very much for the tip!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites