|
Cheat Engine The Official Site of Cheat Engine
|
View previous topic :: View next topic |
Author |
Message |
Bryce1113 How do I cheat? Reputation: 0
Joined: 15 Feb 2024 Posts: 2
|
Posted: Thu Feb 15, 2024 5:56 am Post subject: Need help finding where a value comes from |
|
|
Hey there,
I've got an instruction here that compares eax+08 against 1.
imgur. com/hfzxNp6. png
Eax gets addresses of monsters as soon they're loaded in by the game, if eax+08 is 1 they're activated if it's 0 they're frozen. I'd like to find where these addresses are coming from to make a script that would set 0 in their addresses from the get go.
The issue is it loads a new address every time and I can't really use the Find out what reads/writes to the address since after they're loaded they are only accessed by this comparison.
I've been trying to break & trace but can't seem to find a clear path from where the eax gets its value. What is even [ecx+ebx]? So far I've just found that the ecx register doesn't change its address, pictured below.
imgur. com/SCP82jI. png
Been struggling to make sense of it for a bit, appreciate if you can point me in the right direction
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 140
Joined: 06 Jul 2014 Posts: 4307
|
Posted: Thu Feb 15, 2024 12:02 pm Post subject: |
|
|
ecx is a pointer, and ebx is an offset from the pointed-to address. That's probably an array access.
ecx is the value at [edi+5C], and ebx is edx*4 (from `lea ebx,[edx*4+0]`). edx is the loop value (second image, `mov edx,[esp+14]` / `inc edx` / `mov [esp+14],edx`). It's mostly one big loop, starting at Engine.dll+1CFE60 (the `lea`) and ending at Engine.dll+1CFFC5.
The values [edi+5C] and [edi+60] seem to be pointers to the beginning / end of valid values in the array. If you really want to track this down, you could try to watch those values and see when a new pointer gets added to the array (probably when [edi+60] increases, maybe when the other decreases).
Of course, the object the pointer points to was probably constructed before the pointer to it was added to the array. There's no guarantee the byte at [eax+08] is initialized anywhere near when the pointer gets added to the array. You might end up repeating this process again: analyze the code there to find out where the object came from.
Can you just use a code injection to set it to 0? If that's too intrusive, maybe leave it alone but always take the jump? Inject code at `cmp byte ptr[eax+08],1` and use this:
Code: | newmem:
mov byte ptr[eax+08],0 // maybe comment this out
jmp Engine.dll+1CFFAF |
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
Bryce1113 How do I cheat? Reputation: 0
Joined: 15 Feb 2024 Posts: 2
|
Posted: Mon Feb 19, 2024 1:00 pm Post subject: |
|
|
Thanks for your thorough reply.
I've tried to track it down further but there seems to be lots of layers to go through so I decided to put a pin in it for the time being since I was able to find an easier solution. Will be back to get to the bottom of it some day!
So the crux of the problem for me was that I wanted it to disable enemies just once and then not touch them again so I could manually disable/enable them. Turns out there were some unused offsets that could be used as flags for that so here's what I got. Oh and also eax+08 turned out to be a 4 byte value and there's a difference between player and enemies. (P.S. saw in a Sneaky Mofo's video that you need to pushf before compare)
Smooth sailing so far!
Code: | newmem:
pushf
cmp [eax+10],3
je originalcode
popf
mainbody:
pushf
cmp [eax+08],101
je originalcode
mov byte ptr [eax+08],0
mov [eax+10],3
originalcode:
popf
cmp byte ptr [eax+08],01
jne Engine.dll+1CFFAF
exit:
jmp returnhere |
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 140
Joined: 06 Jul 2014 Posts: 4307
|
Posted: Mon Feb 19, 2024 2:00 pm Post subject: |
|
|
Bryce1113 wrote: | (P.S. saw in a Sneaky Mofo's video that you need to pushf before compare) | No, you don't.
pushf / popf just backs up the lower 16 bits of the EFLAGS register.
The only circumstance in which you would need to do that is if you're injecting at a point where the game is interleaving instructions that don't modify EFLAGS with instructions that read and write to it.
Code: | cmp eax,5 // sets EFLALGS
movsd [edi+310],xmm9 // doesn't modify EFLAGS
jg ... // reads EFLAGS | If you inject at `movsd` here, you need to be careful to not modify EFLAGS.
You're pretty unlikely to see this in practice. In this case, your injection point itself is a `cmp` that sets EFLAGS and a `jne` that reads EFLAGS. Unless you decide to put all your injected code between those two original instructions, there's no reason for you to use pushf.
Even if you do feel the need to use pushf / popf, you shouldn't need to use them more than once: pushf before your code, and popf after your code. Get rid of popf and pushf around the "mainbody" label.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
|
|
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
|
|