 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
sh00ter999
Advanced Cheater
 Reputation: 1
Joined: 17 May 2008
Posts: 89
|
 Posted: Thu Aug 08, 2019 8:41 am Post subject: Resident Evil 2 Remake: No Reload Cheat |
 |
|
Hey, I'm using a version of RE2 that isn't compatible with Steam or any Cheat Table or Trainer released so far (a handful of features work, but some tables will just straight up crash my game on script start-up).
This means that I have to find some useful cheats myself, but I am having major difficulties with this game so far.
Not sure if it's because it uses 64-bit architechture or because it's a modern engine, but I can't even find working pointers for the most basic things. From what I saw from other tables, I would need to find three to four level pointers to have some robust addresses that I can reuse.
Anyhow, enough with the preface. I want to realize a No Reload cheat that works across all of my weapons. Finding the individual ammo values for every single one of my weapons and freezing them is easy enough, but not effective at all if I have to rescan for all guns after each reset.
I found that the ammo is being accessed by the following instruction, where rax+20 stores the current ammo value.
My Assembly game is not the best, but I had hoped to find something that indicates a decrease by 1 function. Hopefully, all the necessary information in the assembly bit shown in the image.
If I straight up nop the I do get the inteded effect, but with some unintended bugs: For instance, if I reload an empty weapon, my ammo vanishes and the gun stay at 0 shots in the clip (makes sense if I nop that instruction). When I store and pick up guns from the in-game chest, then on taking a weapon out of it, it sets its ammo 1, which is not that bad since it's still frozen, but I'd like to write a script to modify the code in such a way that it makes sure that Current Ammo = Max Clip Size.
I'm almost sorry for asking because I don't know basic ASM, but I had hoped that I could make it with the assistance of someone a bit more experienced than myself 
Once that is taken care of, I might have some other things on my list that are causing trouble. Let's see.
_________________
Hyes! |
|
| Back to top |
|
 |
ParkourPenguin
I post too much
 Reputation: 147
Joined: 06 Jul 2014
Posts: 4545
|
|
| Back to top |
|
|
sh00ter999
Advanced Cheater
Reputation: 1
Joined: 17 May 2008
Posts: 89
|
| Posted: Thu Aug 08, 2019 11:56 am Post subject: |
|
|
Ohhh lord, thank you so much ParkourPenguin, through your short answer I was able to learn so much again!
You were dead right with what you suggested.
Removing cmovl with nops didn't trigger and noticable reaction, but replacing it with did the trick!
I'm guessing it's moving the full clip size into the current clip as ammo on every shot, which does exactly what I would want.
https://gfycat.com/happygoluckyagitatedbushbaby
It even completely refills empty weapons from the chest 
I have never used the debugging features of CE so far, but I was able to see what the game stores in RAX and RBX
It should be like this:
RAX = Max Clip Size
RBX = Current Ammo
Another embarassing question: I wasn't able to peak into ebx or eax at all, at least I couldn't find it. Why is that? Feels like I'm missing something (such as a fundamental knowledge of ASM maybe  )
Now I'd like to move on to creating a movement speed as a sequel to this:
https://forum.cheatengine.org/viewtopic.php?t=587623
Do you think it's okay to continue using this thread for questions and answers regarding that?
I'm still having trouble finding the player's coordinates even once, let alone a robust pointer or signature for it. I will check back if I can make some progress. Are there any alternative ways to find player coords more quickly, especially in such a modern and complex game? My attempt is to scan for float values, move around, scan for changes, stand still, scan for unchanged etc... but it takes ages.
I've seen that local player information is often stored closely next to other things, such as Health, but do you think it could apply here as well?
What are the odds I'll find something like reload speed or shot-rate close to my ammo address if I dissect data structures?
Like, I barely know how to use the Structure Dissect properly. Is it even of use in most cases?
In this instance, the address holds the ammo value for a pistol.
Is the best way here trial-and-error, go down the list and watch out for anything that might seem interesting?
I'm sorry for the overload of questions 
_________________
Hyes! |
|
| Back to top |
|
|
ParkourPenguin
I post too much
Reputation: 147
Joined: 06 Jul 2014
Posts: 4545
|
| Posted: Fri Aug 09, 2019 8:13 am Post subject: |
|
|
| sh00ter999 wrote: | | I wasn't able to peak into ebx or eax at all, at least I couldn't find it. |
I'm not sure what you mean by "peak into."
If you want to know where they're getting their values from, you probably won't find it in that code. eax comes from the aforementioned function call- right click that instruction and select "follow" to see that function. ebx looks like it's coming from r8d- a parameter to a function. You'd have to set a breakpoint and step through the ret instruction to see what called this function.
| sh00ter999 wrote: | | Are there any alternative ways to find player coords more quickly, especially in such a modern and complex game? My attempt is to scan for float values, move around, scan for changes, stand still, scan for unchanged etc... but it takes ages. |
Using increased/decreased will probably narrow it down faster. At first you'll guess which direction is increasing,and if you run out of results, then start scanning again with inverted increasing/decreasing logic (it'll likely still be faster than changed/unchanged).
Use hotkeys for next scan types as well (changed in the settings menu). You may want to increase the hotkey delay so you don't accidentally scan twice when you didn't intend to.
As for a pointer, have you tried the pointer scanner? DB's video tutorial on step 8 (YouTube) shows how to use it correctly with multiple pointer maps.
| sh00ter999 wrote: | I've seen that local player information is often stored closely next to other things, such as Health, but do you think it could apply here as well?
What are the odds I'll find something like reload speed or shot-rate close to my ammo address if I dissect data structures?
Like, I barely know how to use the Structure Dissect properly. Is it even of use in most cases? |
I've seen health and coordinates stored in the same structure before. I wouldn't find it surprising in this case, but I wouldn't bet on it either. Perhaps they're stored in two different structures and a pointer links one to the other. Or maybe there's a third structure that has pointers to both. I dunno; it could be any number of scenarios.
Same thing for ammo and fire rate. I'd guess a lot of people find fire rate by poking around in the same structure as the ammo or in structures containing a pointer to the ammo's structure.
| sh00ter999 wrote: | | Is the best way here trial-and-error, go down the list and watch out for anything that might seem interesting? |
Yes, but it takes a good amount of experience (or luck) to spot what's important.
First of all, if that's literally the ammo's address in that image, it's probably not the start of the structure that the ammo is located in. When you look at what's accessing an address, some instructions you'll see will be using an offset to reference the address. For example, 20 in "mov [rax+20],ebx". That 20 is probably how far into the structure the ammo's address is. In other words, the address in rax is probably the start of the structure and, therefore, the address you should put into the structure dissect window.
A very important thing to note is that when you let CE automatically fill in entries in the structure, CE is just guessing value types. Sometimes it does an OK job, and sometimes, it's bad. What you see in that last image is bad. In this case, I'd browse that memory region and do it myself. It's generally not too difficult for someone with experience to differentiate integers, floats, doubles, strings, and pointers just from looking at hex bytes. Checking how the game is accessing a value can also give a good hint if you're stuck (e.g. regarding types of instructions, add = int, addss = float, addsd = double).
After you figure out value types, start looking for semantic meaning in the values. For fire rate, I'd look for floats/doubles between 0.1 and 100 (maybe more) or positive integers if floating point numbers don't look interesting. Checking when a value is accessed and correlating that with what's happening in the game at that time can sometimes give a good hint. When you get curious enough about a value, change it and see what happens.
Again, the value you're looking for may not be in the same structure as the other value you've already found. You may need to look through pointers in that structure to other structures and/or structures containing pointers to that structure.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
|
sh00ter999
Advanced Cheater
Reputation: 1
Joined: 17 May 2008
Posts: 89
|
| Posted: Sat Aug 10, 2019 1:57 pm Post subject: |
|
|
Hey there, first of all thank you again for taking the time to respond to me!
I saw your post earlier, but I didn't want to reply until I had made a bit more progress.
| ParkourPenguin wrote: |
I'm not sure what you mean by "peak into."
If you want to know where they're getting their values from, you probably won't find it in that code. eax comes from the aforementioned function call- right click that instruction and select "follow" to see that function. ebx looks like it's coming from r8d- a parameter to a function. You'd have to set a breakpoint and step through the ret instruction to see what called this function.
|
Ohh I see, thanks for the heads up. I was just wondering if EBX and EAX stores numerical values, because upon setting a breakpoint I was able to see the values within RAX and RBX. They're not the same, right?
| ParkourPenguin wrote: |
Use hotkeys for next scan types as well (changed in the settings menu). You may want to increase the hotkey delay so you don't accidentally scan twice when you didn't intend to.
As for a pointer, have you tried the pointer scanner? DB's video tutorial on step 8 (YouTube) shows how to use it correctly with multiple pointer maps.
|
Thanks for the info! I was using hotkeys, but your approach was definitely yielding fewer addresses faster, after I seemed to have guess in which direction my coordinates would increase/decrease.
I had no idea that DB made video tutorials himself, it seems to be relatively new. I watched it and learned another few things, thanks for that again I wasn't quite using Pointer Scanner very effectively so far, but I think that will change.
| ParkourPenguin wrote: | | First of all, if that's literally the ammo's address in that image, it's probably not the start of the structure that the ammo is located in. When you look at what's accessing an address, some instructions you'll see will be using an offset to reference the address. For example, 20 in "mov [rax+20],ebx". That 20 is probably how far into the structure the ammo's address is. In other words, the address in rax is probably the start of the structure and, therefore, the address you should put into the structure dissect window. |
Oh man, thanks for pointing that out again. It is something I had grasped in the past, but forgot about. Yeah, it makes perfect sense. Of course Rax would be the base address or the beginning of the weapon structure in that example. Another helpful bit of info 
| ParkourPenguin wrote: |
A very important thing to note is that when you let CE automatically fill in entries in the structure, CE is just guessing value types. Sometimes it does an OK job, and sometimes, it's bad. What you see in that last image is bad. In this case, I'd browse that memory region and do it myself. It's generally not too difficult for someone with experience to differentiate integers, floats, doubles, strings, and pointers just from looking at hex bytes. Checking how the game is accessing a value can also give a good hint if you're stuck (e.g. regarding types of instructions, add = int, addss = float, addsd = double). |
And that's another neat trick. Good to know there are ways to find out the data types with reliable accuracy.
I must say that I've given up on finding the player coordinates. I was able to narrow it down to about a hundred left over addresses, but none of them disabled my character from moving in a certain direction when I froze them. Would have been nice to make speed walker script for this game, but I'm as good as done with it, so it doesn't matter anymore.
There is a final issue I had with my no reload script, which would crash my game upon firing any weapon. I can't spot the mistake:
| Code: |
[ENABLE]
aobscanmodule(INJECT,re2.exe,0F 4C D8 48 85 F6) // should be unique
alloc(newmem,$1000,"re2.exe"+E87C9B)
label(code)
label(return)
newmem:
code:
mov ebx,eax
test rsi,rsi
jmp return
INJECT:
jmp newmem
nop
return:
registersymbol(INJECT)
[DISABLE]
INJECT:
db 0F 4C D8 48 85 F6
unregistersymbol(INJECT)
dealloc(newmem)
{
// ORIGINAL CODE - INJECTION POINT: "re2.exe"+E87C9B
"re2.exe"+E87C79: 75 57 - jne re2.exe+E87CD2
"re2.exe"+E87C7B: 48 89 74 24 30 - mov [rsp+30],rsi
"re2.exe"+E87C80: 48 8B 72 18 - mov rsi,[rdx+18]
"re2.exe"+E87C84: 48 85 F6 - test rsi,rsi
"re2.exe"+E87C87: 74 44 - je re2.exe+E87CCD
"re2.exe"+E87C89: E8 52 00 00 00 - call re2.exe+E87CE0
"re2.exe"+E87C8E: 48 8B 4F 50 - mov rcx,[rdi+50]
"re2.exe"+E87C92: 48 83 79 18 00 - cmp qword ptr [rcx+18],00
"re2.exe"+E87C97: 75 34 - jne re2.exe+E87CCD
"re2.exe"+E87C99: 3B C3 - cmp eax,ebx
// ---------- INJECTING HERE ----------
"re2.exe"+E87C9B: 0F 4C D8 - cmovl ebx,eax
"re2.exe"+E87C9E: 48 85 F6 - test rsi,rsi
// ---------- DONE INJECTING ----------
"re2.exe"+E87CA1: 74 09 - je re2.exe+E87CAC
"re2.exe"+E87CA3: 48 8B 46 10 - mov rax,[rsi+10]
"re2.exe"+E87CA7: 48 85 C0 - test rax,rax
"re2.exe"+E87CAA: 75 1E - jne re2.exe+E87CCA
"re2.exe"+E87CAC: 45 33 C0 - xor r8d,r8d
"re2.exe"+E87CAF: 48 8B CF - mov rcx,rdi
"re2.exe"+E87CB2: 41 8D 50 38 - lea edx,[r8+38]
"re2.exe"+E87CB6: 48 8B 74 24 30 - mov rsi,[rsp+30]
"re2.exe"+E87CBB: 48 8B 5C 24 38 - mov rbx,[rsp+38]
"re2.exe"+E87CC0: 48 83 C4 20 - add rsp,20
} |
The signature is robust, I can find it after every game restart, and if I go ahead and manually edit the cmovl to mov eax, ebx it works. I thought I would have to manually insert a nop after the changed instruction, as CE suggest to do if you change it manually in memory viewer, but that didn't quite fix it either
_________________
Hyes! |
|
| Back to top |
|
|
ParkourPenguin
I post too much
Reputation: 147
Joined: 06 Jul 2014
Posts: 4545
|
| Posted: Sat Aug 10, 2019 9:41 pm Post subject: |
|
|
| sh00ter999 wrote: | | I was just wondering if EBX and EAX stores numerical values, because upon setting a breakpoint I was able to see the values within RAX and RBX. They're not the same, right? |
With regards to RAX and EAX- both names refer to the same register, but RAX accesses 64 bits while EAX accesses the lower 32 bits. The same goes for the other general-purpose registers beginning with R and E, except for r8-r15 (they're 64 bit, r8d-r15d are 32-bit).
| sh00ter999 wrote: | | I must say that I've given up on finding the player coordinates. I was able to narrow it down to about a hundred left over addresses, but none of them disabled my character from moving in a certain direction when I froze them. |
Did you try searching for doubles, or just floats?
| sh00ter999 wrote: | | There is a final issue I had with my no reload script, which would crash my game upon firing any weapon. |
I can't spot it either.
Perhaps there's an instruction somewhere that jumps to the test instruction. When that script is enabled, it would jump into the middle of garbage and probably crash. If this is the problem, you can probably find the jump by scrolling up a little, or if you want to be certain, dissect the code in re2.exe (tools menu in memory viewer).
Are you sure the signature is unique in the exe? (scan through all memory, not just writable; right click menu in the executable/writable/CoW area in the main window)
I guess you could set a few breakpoints in that function and see what happens.
Alternatively, you don't need to do a code injection at all. It's perfectly fine to do this:
| Code: | [ENABLE]
aobscanmodule(INJECT,re2.exe,0F 4C D8 48 85 F6)
registersymbol(INJECT)
INJECT:
mov ebx,eax
nop
[DISABLE]
INJECT:
db 0F 4C D8 48 85 F6
unregistersymbol(INJECT)
|
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
|
sh00ter999
Advanced Cheater
Reputation: 1
Joined: 17 May 2008
Posts: 89
|
| Posted: Mon Aug 12, 2019 2:00 pm Post subject: |
|
|
| ParkourPenguin wrote: | | With regards to RAX and EAX- both names refer to the same register, but RAX accesses 64 bits while EAX accesses the lower 32 bits. The same goes for the other general-purpose registers beginning with R and E, except for r8-r15 (they're 64 bit, r8d-r15d are 32-bit). |
Ohhh, now I understand!!  Thanks for clearing that up
| Quote: | | Did you try searching for doubles, or just floats? |
Foolishly, I did only scan for floats, because I saw a video of someone no-clipping and elevating his character (skywalker) with his own cheat table, and I could see that his sole address had been a float. So I kind of tunnel visioned on the assumption that it has to be float, but maybe I should really give double a chance. Who knows, maybe I will be fortunate enough to find something. But in all of my past experiences, player coordinates were always stored in a float. Maybe, since it's a newer game they decided to go with the higher precision doubles? 
| Quote: | | Are you sure the signature is unique in the exe? (scan through all memory, not just writable; right click menu in the executable/writable/CoW area in the main window) |
Only 90% sure. When I scan for AOB in memory viewer I always land in the right spot, which I can edit manually. When I tick the script, it puts the INJECT label at the right spot before execution. I can check, because executing the script alone will not crash the game yet, only upon firing the weapon or managing items (such as picking something up).
If I manually scan for the AOB in Memory Viewer, and by starting at 00000000000000000, do I not scan my entire memory?
https://i.imgur.com/IrgT8XX.png
If I hit search again after I hit my weapon ammo code, I get no more results.
Here's what the script replaces the original code with:
https://i.imgur.com/rsMEUot.png
Then I follow it to the code cave, seems to do what I want
https://i.imgur.com/N0SQbQw.png
I actually had no interest in the part, but since the AOB template included it and it chose to encapsulate both
| Code: | cmovl ebx,eax
test rsi,rsi |
I just added it to make sure not to leave out any instructions.
Then it jumps back where I want it to.
https://i.imgur.com/jZjLT31.png
| Quote: | | Code: | [ENABLE]
aobscanmodule(INJECT,re2.exe,0F 4C D8 48 85 F6)
registersymbol(INJECT)
INJECT:
mov ebx,eax
nop
[DISABLE]
INJECT:
db 0F 4C D8 48 85 F6
unregistersymbol(INJECT)
|
|
I like this version a whole lot more, it's cleaner and it has no unnecessary jumps in memory. Thanks for the snippet. But your script lead to the same result, game crash on weapon fire. Actually, this time it gave me a memory out of reference error.
But that might have been because I first checked and unchecked my own script first. But if my disable section is clean, it should have restored the original code seamlessly?
Edit: Never mind, your script is golden clean. The crash was definitely caused by my bad runner version. It finally works now!!
Thank you once more a thousand times for your assistance!
Gosh, if I can find player coordinates as double later this week in order to speed up my character, that would be heavenly 
_________________
Hyes! |
|
| Back to top |
|
|
ParkourPenguin
I post too much
Reputation: 147
Joined: 06 Jul 2014
Posts: 4545
|
| Posted: Mon Aug 12, 2019 4:07 pm Post subject: |
|
|
| sh00ter999 wrote: | | If I manually scan for the AOB in Memory Viewer, and by starting at 00000000000000000, do I not scan my entire memory? |
I don't know, as I've never used that before. I always use the main window to scan for AoBs.
Given what you've said and shown, I assume the AoB is fine.
What's not fine is where CE is allocating newmem and, by extension, the type of jump assembled by CE. When the destination of the jump is less than 2GB away, it can be assembled in 5 bytes. If it's more than 2GB away, CE needs to do some trickery which results in the jump taking up 14 bytes. Despite your request for the alloc to be within 2GB of re2.exe (third parameter to alloc), it seems like CE ignored that and therefore assembled the longer version instead of the shorter version. ("jmp return" is not jumping where you think it is)
Did you always have the third parameter to alloc there?
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
|
Dark Byte
Site Admin
 Reputation: 465
Joined: 09 May 2003
Posts: 25549
Location: The netherlands
|
| Posted: Mon Aug 12, 2019 4:14 pm Post subject: |
 |
|
Is kernelmode query memory regions is on, there is a fair chance that the preferred base address allocation will fail
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
sh00ter999
Advanced Cheater
Reputation: 1
Joined: 17 May 2008
Posts: 89
|
| Posted: Sun Aug 18, 2019 8:11 am Post subject: |
|
|
| Dark Byte wrote: | | Is kernelmode query memory regions is on, there is a fair chance that the preferred base address allocation will fail |
Yeah, must've been the issue. I had the kernel settings turned on. I deactivated it several times, but it didn't save because I must've crashed often, at least that's what I think. Memory's blurry at this point.
I'm still super confused why I cannot seem to find X, Y and Z coordinates.
I tried everything ranging from float to double to 4bytes.
I was dead sure I could find the Y coordinate easily (elevation) by going up and down a flight of stairs, but both doubles and floats don't return anything usable.
Interestingly, when I do the same method and I scan for 4 byte addresses, I get very few, sometimes even only one result which seems to look like a very long number that only changes when I move. I added it manually, and changed it's type to float, and lo and behold: it's value makes sense for coordinates. In the spot where I am in the game, it's between 10 and 40 depending on where I stand, but freezing it had no effect and I think that's simply not it quite it yet. Pretty insane
_________________
Hyes! |
|
| 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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
