 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
Gniarf
Grandmaster Cheater Supreme
![]() Reputation: 43
Joined: 12 Mar 2012
Posts: 1285
|
 Posted: Sun Mar 10, 2013 3:48 pm Post subject: |
  |
|
| GNIREENIGNE wrote: | | So, you're saying that there are different ID's being used based on the officer type (and) that these ID's may be located at different offsets? |
Different IDs yes, but not different offset. The CharacterID is always PlayerStructure+C.
| GNIREENIGNE wrote: | | How did you determine this? |
I started by finding that the health was accessed with reg+104, so I assumed the PlayerStructure started 0x104 bytes before the health. The I used the structure dissector and manually looked at PlayerStructure for several friends/foes, then I said "Oh a number that looks like a bitmask...", and for enemies it always was in the 0x3* range and something else for me, so I thought it was bitmask and looking at several examples I assumed that each time (Playerstructure+C)&0x20==1 the character was an enemy... Then came IDs like 0x139 which is actually a generic allied general, I added a check later so that each time CharacterID&0x100==1 you get treated as a friend. And the a boss with CharacterID=0 crashed my algorithm. After looking at more values this not-bitmask could take, I started thinking about a character/fighter ID.
Now how to identify a bitmask by sight?
-It can't be read as a float/double
-look at it in HEX. I can't identify a bitmask in decimal.
-There are often lots of 0s
-Bits that are set look like they are "grouped".
-It can be very big number like a pointer, but doesn't point to a valid memory range.
-When comparing over several similar entities, well similar entities means similar properties, which means similar bits set, which means order of greatness and similar placement of zeros. Like most and least significant bits sets, but not much in the middle. For CharacterID everything was on the low order like: 00000139,00000006,0000002A...
Those are only hints, once you get a hunch you have to test it. I can't provide a reliable method, and don't have one myself - after all CharacterID is NOT a bitmask.
| GNIREENIGNE wrote: | | How did you test it? |
Hooked the function that applies damage and made it overwrite the health based on CharacterID&0x20 at first. Gradually I improved the detection to what you saw above until my allies got a ridiculous hp bar and all enemies have an empty one.
Honestly I have no definite proof that this is a character identifier, but my player always has this variable to 6, all generic generals have it in the 0x2A-0x39 range and special generals always correspond to the same value, sometime in tightly increasing order, ie: one of the Sun family has it to 5, another it to 6 (the character I play), and yet another Sun has 7.
| GNIREENIGNE wrote: | | I haven't tested your script, but I wonder if you have tested the result of it. For example, whenever I try to mov 0 into health, the troops cannot be killed. |
It depends on the place you're hooking. If set the health to 0 in the function that applies the damage (AND don't forget to pushfd/popfd, as opposed to what I used to do <_<), 1hit-kills work. If you set the health to 0 in the function that draws the health bar, well, looks like they repop.
But fyi, yes I did one whole mission instant-killing everyone without problems with both godmodes.
| GNIREENIGNE wrote: | | There is an address that controls all actions/sprites, but manipulating that with the health address was not successful. |
That's an interesting find you've got there. Did you manage to shape-shift/polymorph by manually editing that variable? Were you able to switch to any other character or a limited subset of the roster (the ones present on the map + maybe a few others...) ?
In the meantime I made a 2nd godmode, based on the healthbar color. Problem is that the player has no healthbar floating over his head, so this godmode only protects allies...all allies with a blue healthbar.
| Code: | [enable]
alloc(Cave,128)
label(AlliesGod_Hook)
label(ReturnHere)
label(Friendly)
label(Cave_Exit)
registersymbol(AlliesGod_Hook)
aobscan(AlliesGod_aob,80 7C 24 13 00 8B 6C 29 10 74)
//look for:
/*
DW6_WIN_DEMO.EXE+15DEA9 - 69 ED DC000000 - imul ebp,ebp,000000DC
DW6_WIN_DEMO.EXE+15DEAF - 80 7C 24 13 00 - cmp byte ptr [esp+13],00 <-AlliesGod_Hook
DW6_WIN_DEMO.EXE+15DEB4 - 8B 6C 29 10 - mov ebp,[ecx+ebp+10]
DW6_WIN_DEMO.EXE+15DEB8 - 74 5F - je DW6_WIN_DEMO.EXE+15DF19
DW6_WIN_DEMO.EXE+15DEBA - 8B B4 24 6C010000 - mov esi,[esp+0000016C]
DW6_WIN_DEMO.EXE+15DEC1 - 80 BE 4C7A0000 00 - cmp byte ptr [esi+00007A4C],00
*/
AlliesGod_aob:
AlliesGod_Hook:
jmp Cave
ReturnHere:
Cave:
push ebp
push eax
mov ebp,dword [ecx+ebp+10] //read the health bar color INDEX
//the RGBA components are at ebp*4+DW6_WIN_DEMO.EXE+30AEA8
mov eax,[edx+70] //pointer to EntityStructure
cmp ebp,0 //looks like color index=0 means the blue used for allies hp bars
je Friendly
//Enemy:
cmp dword [eax+104],(float)1.0 //if an enemy has less than 1hp, don't freeze his health to 1
jb Cave_Exit //let him die... (comparing floats with cmp->I know what I'm doing)
mov dword [eax+104],(float)1.0 //1hit kill. Don't put 0 (they repop)
jmp Cave_Exit
Friendly:
mov ebp,dword [eax+100] //load max health
mov dword [eax+104],ebp //overwrite current hp with max hp
//mov dword [eax+104],(float)9999999 //marker
Cave_Exit:
pop eax //restore eax
pop ebp //restore ebp
cmp byte ptr [esp+13],00
jmp ReturnHere
[disable]
AlliesGod_Hook:
cmp byte ptr [esp+13],00
dealloc(Cave)
unregistersymbol(AlliesGod_Hook) |
Now you're probably going to scream at me for using cmp to compare floats. Well, suffice to say that the bigger the float, the bigger the float_read_as_an_int, so that works, even taking sign into account.
|
|
| Back to top |
|
 |
++METHOS
I post too much
![]() Reputation: 92
Joined: 29 Oct 2010
Posts: 4197
|
| Posted: Sun Mar 10, 2013 7:43 pm Post subject: |
|
|
| Gniarf wrote: | | Different IDs yes, but not different offset. The CharacterID is always PlayerStructure+C. |
Hmm. I took a look at this, but I have no way to determine if it is player ID or not (I'll have to do some tests to see if this address will work). I tried altering the value, but the character's behavior did not change; nothing seemed to change (i.e. the character was still an enemy unit that could be harmed by the hero player, and was still being attacked by my troops etc.). If what you are saying is true, then a simple "compare" and "jump if greater-than" should do the trick here (assuming enemy ID and ally ID fall within a certain range of values, respectively). I don't know how high/low the values go, so that would take some testing.
| Gniarf wrote: | | I started by finding that the health was accessed with reg+104, so I assumed the PlayerStructure started 0x104 bytes before the health. The I used the structure dissector and manually looked at PlayerStructure for several friends/foes, then I said "Oh a number that looks like a bitmask...", and for enemies it always was in the 0x3* range and something else for me, so I thought it was bitmask and looking at several examples I assumed that each time (Playerstructure+C)&0x20==1 the character was an enemy... Then came IDs like 0x139 which is actually a generic allied general, I added a check later so that each time CharacterID&0x100==1 you get treated as a friend. And the a boss with CharacterID=0 crashed my algorithm. After looking at more values this not-bitmask could take, I started thinking about a character/fighter ID. |
I have not had time to test this, but if the ID actually represents character/fighter ID, then performing a compare here may be problematic.
| Gniarf wrote: | It depends on the place you're hooking. If set the health to 0 in the function that applies the damage (AND don't forget to pushfd/popfd, as opposed to what I used to do <_<), 1hit-kills work. If you set the health to 0 in the function that draws the health bar, well, looks like they repop.
But fyi, yes I did one whole mission instant-killing everyone without problems with both godmodes. |
Strange. The code must be different for the demo version, then. The only instruction suitable that I have found (and I have tested them all) is this:
| Code: | | 004F5662 - F3 0F11 40 04 - movss [eax+04],xmm0 |
I don't always push/pop, but I'll try it out some more to see if it will make a difference. Thanks.
| Gniarf wrote: | | GNIREENIGNE wrote: | | There is an address that controls all actions/sprites, but manipulating that with the health address was not successful. |
That's an interesting find you've got there. Did you manage to shape-shift/polymorph by manually editing that variable? Were you able to switch to any other character or a limited subset of the roster (the ones present on the map + maybe a few others...) ? |
I should not have used the term sprite here, as that is not correct - sorry. The values actually represent actions. The values for the actions are similar (sometimes, exactly the same) for all characters...which is actually pretty fun to toy with (e.g. making everyone constantly bow when you are near).
| Gniarf wrote: | | In the meantime I made a 2nd godmode, based on the healthbar color. |
I'd like to know how you went about finding the healthbar color. Did you find the address that holds this value?
| Gniarf wrote: | | Problem is that the player has no healthbar floating over his head, so this godmode only protects allies...all allies with a blue healthbar. |
If you found the address that holds the color (or no color), you can just do a compare against pink/orange...or, jump for anything greater than zero, I suppose.
| Gniarf wrote: | | so that works, even taking sign into account. |
I took a look at your code. Unfortunately, with the version that I am working with, the code is different. It could be that I am doing something wrong with my scripting, I don't know. Getting one-hit-kill is not a problem, as I just edit my attack address. However, it would be nice to figure this out. My primary reason is so that I can cripple the enemy troops or create an instant death code. I can cripple all players already, but I can't instant-kill them without hitting them. I also can't filter out friendly troops (although, I haven't tried your ID address yet). I guess, one thing at a time. I'll try the ID address that you found and test it out. If I can find a reliable way to differentiate between enemy/ally without relying on my own hack, that would be good. Then I can focus on these other features that I'd like to implement.
Thanks, again.
|
|
| Back to top |
|
|
Gniarf
Grandmaster Cheater Supreme
![]() Reputation: 43
Joined: 12 Mar 2012
Posts: 1285
|
| Posted: Mon Mar 11, 2013 1:47 am Post subject: |
|
|
| GNIREENIGNE wrote: | | Gniarf wrote: | | Different IDs yes, but not different offset. The CharacterID is always PlayerStructure+C. |
Hmm. I took a look at this, but I have no way to determine if it is player ID or not (I'll have to do some tests to see if this address will work). I tried altering the value, but the character's behavior did not change; nothing seemed to change (i.e. the character was still an enemy unit that could be harmed by the hero player, and was still being attacked by my troops etc.). |
Nothing changes on my side either when I edit the CharacterID.
| GNIREENIGNE wrote: | The only instruction suitable that I have found (and I have tested them all) is this:
| Code: | | 004F5662 - F3 0F11 40 04 - movss [eax+04],xmm0 |
I don't always push/pop, but I'll try it out some more to see if it will make a difference. |
Looks like we have the same hackpoint. When you said entities become unkillable, did you mean that they "die" and 1-2s later a new one "pops" from the corpse, or did you mean that they just take hits but never fall down?
In the latter case your problem is with pushfd/popfd -> save and restore the results of the previous cmp operation. The cmp is just above your hackpoint, the je just after.
| GNIREENIGNE wrote: | | I'd like to know how you went about finding the healthbar color. Did you find the address that holds this value? |
*cracks neck* Some tracing, and a lot of luck:
-took some schmuck's health, looked at all functions that read this value.
-since max hp is at PlayerStructure+100, I replaced one by one all functions that read hp so that they read max hp until I found one that make people have a full bar, but doesn't actually modify their health.
that was a
| Code: | | cvttss2si ecx,[ecx+00000104] |
-then I traced what happens in this function until I landed on:
| Code: | cvtpd2ps xmm0,xmm0
movss [ecx+00000090],xmm0
movss [ecx+00000094],xmm3 |
The movss [ecx+90] was storing something derived from my current health, I traced what happened to it and ended stuck in a function that stretches 2D elements. So out of curiosity I took a look at the other movss which seems to store th bar tickness.
-traced what happened to the tickness, landed on:
| Code: | fsub dword ptr [esp+10]
mov esi,[esp+58]
fmulp st(1),st(0)
fstp dword ptr [esp+10]
fld dword ptr [esp+10]
fadd dword ptr [esp+20]
fstp dword ptr [esp+30]
fld dword ptr [esp+30]
fstp dword ptr [esp+28]
fld dword ptr [esp+60]
fstp dword ptr [esp]
push eax
push ecx
lea eax,[esp+1C]
call 005E8420
pop esi
add esp,4C
ret |
-traced what happened to esp+10,28,30 and got my first hit within that call 005E8420.
-I've probably tried disabling the function (put a ret c at the beginning) to see what impact it had on hp bars->they disappeared. At some point I looked at its arguments and saw something like FF6C4D5E. A value like this could be a color index (FF for the alpha component) and cannot be a pointer. At least it's just a number, so let's fiddle with it. Replaced the push eax above with something that does push FF000000, went ingame and saw everyone had a black healthbar-> W00T. Also made an experiment with red, to confirm.
-then I proceeded to tracing where that eax comes from: passed as argument, surprise me.
-In the parent function you will cross:
| Code: | mov eax,[ebx+1C]
...
push eax (the RGBA color) |
-so color is stored at ebx+1C, which was an address in the same range that the various PlayerStructures.
-Out of curiosity I looked at ebx+1c in the structure dissector: lots of strings in there (g_vColor, g_fCenterV,...)... But also there seemed to be a color every 0x34 bytes (identified by their 0xFF****** look) so I thought is was an array of healthbar colors, like officer n uses HpBarColor[n], that meant that colors were not reallocated when an entity is destroyed.
-So I asked to find out what writes the color, and found:
| Code: | mov edx,[esp+08]
mov eax,[edx*4+DW6_WIN_DEMO.EXE+30AEA8]
mov [ecx+00000084],eax<-writes the color |
-traced where the only argument came from. The parent function has:
| Code: | cmp byte ptr [esp+13],00 <-doh, my hack point!
mov ebp,[ecx+ebp+10]
...
push ebp |
Now why did I stop there instead of searching where ecx and ebp come from?
Well DW6_WIN_DEMO.EXE+30AEA8 is just a collection of color templates, and what color to pick comes directly from the parent function, so the function that selects whether an entity has a blue or red bar is that parent function (=where my hack point is) or one of its parent. I don't really need to find the IFF check since I can make one based on the color index, all I needed now was to link the colors to their corresponding PlayerStructure. So I was looking at my registers hoping to find a pointer to some PlayerStructure. Luckily my entity data was always allocated in the 0D000000 range, so each time I saw a register in that range I put its value in the structure dissector. Well I put edx at my hack point in the dissector, but it didn't point to a PlayerStructure. I desperately tried a few pointers and stumbled on one that pointed to something that looked a lot like the PlayerStructures I had been staring at all day: 2 pointers at the beginning, one big bitmask, something that was in the CharacterID range, a valid float at offset +0x100 (max hp) followed by 2 copies of a smaller float (current hp), that was it, jackpot!
-Hooked this piece of code to see what I could do out of it, well it turns out that the hp bar color is written way more often than just when creating/destroying entities - good for me.
| GNIREENIGNE wrote: | | If you found the address that holds the color (or no color), you can just do a compare against pink/orange...or, jump for anything greater than zero, I suppose. |
Nope the function that I hooked only handled the floating bars above people's head. The hero's bar in the lower/left is handled by another function. I put a conditional breakpoint in my hook that was supposed to break whenever the hero's Playerstructure comes through it, regardless of color, and it never broke.
| GNIREENIGNE wrote: | | Thanks, again. |
You're welcome. It feels good talking to someone competent for a change.
|
|
| Back to top |
|
|
++METHOS
I post too much
![]() Reputation: 92
Joined: 29 Oct 2010
Posts: 4197
|
| Posted: Mon Mar 11, 2013 2:59 am Post subject: |
|
|
| Gniarf wrote: | | When you said entities become unkillable, did you mean that they "die" and 1-2s later a new one "pops" from the corpse |
This. Exactly.
| Gniarf wrote: | -took some schmuck's health, looked at all functions that read this value.
-since max hp is at PlayerStructure+100, I replaced one by one all functions that read hp so that they read max hp until I found one that make people have a full bar, but doesn't actually modify their health.
that was a
| Code: | | cvttss2si ecx,[ecx+00000104] |
-then I traced what happens in this function until I landed on:
| Code: | cvtpd2ps xmm0,xmm0
movss [ecx+00000090],xmm0
movss [ecx+00000094],xmm3 |
The movss [ecx+90] was storing something derived from my current health, I traced what happened to it and ended stuck in a function that stretches 2D elements. So out of curiosity I took a look at the other movss which seems to store th bar tickness.
-traced what happened to the tickness, landed on:
| Code: | fsub dword ptr [esp+10]
mov esi,[esp+58]
fmulp st(1),st(0)
fstp dword ptr [esp+10]
fld dword ptr [esp+10]
fadd dword ptr [esp+20]
fstp dword ptr [esp+30]
fld dword ptr [esp+30]
fstp dword ptr [esp+28]
fld dword ptr [esp+60]
fstp dword ptr [esp]
push eax
push ecx
lea eax,[esp+1C]
call 005E8420
pop esi
add esp,4C
ret |
-traced what happened to esp+10,28,30 and got my first hit within that call 005E8420.
-I've probably tried disabling the function (put a ret c at the beginning) to see what impact it had on hp bars->they disappeared. At some point I looked at its arguments and saw something like FF6C4D5E. A value like this could be a color index (FF for the alpha component) and cannot be a pointer. At least it's just a number, so let's fiddle with it. Replaced the push eax above with something that does push FF000000, went ingame and saw everyone had a black healthbar-> W00T. Also made an experiment with red, to confirm.
-then I proceeded to tracing where that eax comes from: passed as argument, surprise me.
-In the parent function you will cross:
| Code: | mov eax,[ebx+1C]
...
push eax (the RGBA color) |
-so color is stored at ebx+1C, which was an address in the same range that the various PlayerStructures.
-Out of curiosity I looked at ebx+1c in the structure dissector: lots of strings in there (g_vColor, g_fCenterV,...)... But also there seemed to be a color every 0x34 bytes (identified by their 0xFF****** look) so I thought is was an array of healthbar colors, like officer n uses HpBarColor[n], that meant that colors were not reallocated when an entity is destroyed.
-So I asked to find out what writes the color, and found:
| Code: | mov edx,[esp+08]
mov eax,[edx*4+DW6_WIN_DEMO.EXE+30AEA8]
mov [ecx+00000084],eax<-writes the color |
-traced where the only argument came from. The parent function has:
| Code: | cmp byte ptr [esp+13],00 <-doh, my hack point!
mov ebp,[ecx+ebp+10]
...
push ebp |
Now why did I stop there instead of searching where ecx and ebp come from?
Well DW6_WIN_DEMO.EXE+30AEA8 is just a collection of color templates, and what color to pick comes directly from the parent function, so the function that selects whether an entity has a blue or red bar is that parent function (=where my hack point is) or one of its parent. I don't really need to find the IFF check since I can make one based on the color index, all I needed now was to link the colors to their corresponding PlayerStructure. So I was looking at my registers hoping to find a pointer to some PlayerStructure. Luckily my entity data was always allocated in the 0D000000 range, so each time I saw a register in that range I put its value in the structure dissector. Well I put edx at my hack point in the dissector, but it didn't point to a PlayerStructure. I desperately tried a few pointers and stumbled on one that pointed to something that looked a lot like the PlayerStructures I had been staring at all day: 2 pointers at the beginning, one big bitmask, something that was in the CharacterID range, a valid float at offset +0x100 (max hp) followed by 2 copies of a smaller float (current hp), that was it, jackpot!
-Hooked this piece of code to see what I could do out of it, well it turns out that the hp bar color is written way more often than just when creating/destroying entities - good for me. |
I have to be honest with you...some of the things that you mention above are beyond my current knowledge/ability. Most of my past experience involved Ollydbg, reversing apps. Writing codes for Cheat Engine is a little different. Needless to say, I haven't done much with the trace function feature in Cheat Engine.
| Gniarf wrote: | | GNIREENIGNE wrote: | | Thanks, again. |
You're welcome. It feels good talking to someone competent for a change. |
I assure you, between you and I, I am a beginner by comparison. I am learning more, so thank you.
|
|
| Back to top |
|
|
foxfire9
Advanced Cheater
![]() Reputation: 0
Joined: 23 Mar 2012
Posts: 57
|
| Posted: Fri Mar 15, 2013 8:06 pm Post subject: |
|
|
One question, how can you tell that the ID is static or dynamic?
Here's an example, I tried overwriting the codes by a code injection but when you mix it with another code injection the ID changes. Is this true?
I heard this by someone I forgot what thread in that time, I tried googling it back but no result related to this site.
|
|
| Back to top |
|
|
Gniarf
Grandmaster Cheater Supreme
![]() Reputation: 43
Joined: 12 Mar 2012
Posts: 1285
|
| Posted: Fri Mar 15, 2013 9:07 pm Post subject: |
|
|
| foxfire9 wrote: | | One question, how can you tell that the ID is static or dynamic? |
Ah, by "dynamic" you meant that PlayerID is 1 in one game, and when you go to another map PlayerID is 5 (wouldn't surprise me in a RTS or unreal tournament-like FPS), well, that happens when the player isn't "special" compared to its opponents. For example in a strategy game human controlled factions and CPU controlled ones are similar: same buildings, same units, same costs, same powers... it's just that the thing giving the orders is different. If you don't see any obvious similarity (or have no idea), assume a constant PlayerID until proven wrong.
| foxfire9 wrote: | | Here's an example, I tried overwriting the codes by a code injection but when you mix it with another code injection the ID changes. Is this true? |
Is it true that you tried overwriting [...]? Hmm...Probably?
Is it true that the ID changes when you overwrite the "codes" (=IDs I assume)? In most cases yes, unless you overwrite with the value it already had.
Is it true that when you enable a second hack, you overwrite the IDs with a different value than when this 2nd hack wasn't enabled? How could I know given the information you provided? It all depends on what that 2nd hack is supposed to do, but it sure as hell looks strange; it looks more like there is a bug somewhere in those hacks.
|
|
| Back to top |
|
|
foxfire9
Advanced Cheater
![]() Reputation: 0
Joined: 23 Mar 2012
Posts: 57
|
| Posted: Sat Mar 16, 2013 9:12 pm Post subject: |
|
|
I tried one (1) offset for comparison relating on both hacks under the same Script but somehow I can't tell the difference nor feel it's affecting.
The Game was C&C Generals ZH.
|
|
| Back to top |
|
|
Gniarf
Grandmaster Cheater Supreme
![]() Reputation: 43
Joined: 12 Mar 2012
Posts: 1285
|
| Posted: Sun Mar 17, 2013 5:41 am Post subject: |
|
|
| foxfire9 wrote: | | I tried one (1) offset for comparison relating on both hacks under the same Script |
I don't understand what you meant there.
Looking at Recifense's table he uses a pointer to differentiate between friend or foe.
Normally you should be able to remake his hack using the structure spider if you compare HealthAddress-0x10.
|
|
| Back to top |
|
|
foxfire9
Advanced Cheater
![]() Reputation: 0
Joined: 23 Mar 2012
Posts: 57
|
| Posted: Sun Mar 17, 2013 8:27 pm Post subject: |
|
|
| The cmp code.
|
|
| Back to top |
|
|
++METHOS
I post too much
![]() Reputation: 92
Joined: 29 Oct 2010
Posts: 4197
|
| Posted: Tue Mar 26, 2013 5:13 pm Post subject: |
|
|
Gniarf,
I know this thread is old, but I wanted to update you on this game since I am done with it and have released a trainer for it.
I was never able to find the instruction that handled the color of the health bar, as you did. To be honest, I didn't even try looking for it because I feel that it may be beyond my current skill level. There are still a few features in Cheat Engine that I haven't even looked at, to be honest. I will have to spend more time learning the other features for future games. Also, I tested the initial address that you found that determined character ID. Unfortunately, I could not use it because it was the ID of the character, which could be high or low, even if the character was enemy or friendly. That, and because you could play as any major character, the friend/foe aspect would change. However, I did determine that the base address was the ID for human/computer, and that was good enough to use for the scripts that I wanted to write - without having to rely on a manipulated address, such as health. Since I didn't need this ID for one-hit kills, it wasn't a problem.
Anyway, I just wanted to thank you again for your help. 
|
|
| Back to top |
|
|
Telecide
Cheater
![]() Reputation: 0
Joined: 30 Sep 2012
Posts: 42
|
| Posted: Sat Jul 26, 2014 11:00 am Post subject: |
|
|
Hi y'all. I'm messing with this too. Just wondering if anyone can tell where I'm going wrong. I have this generic script I think Dark Byte helped me with a while ago that I modify slightly to check player id. Sometimes it works beautifully and other times it crashes
My guess is the something is going wrong with flags. I try to do an injection right before the original code, which in this case pops the value in the fpu stack into the memory address. I figured just before that happens I'll discard the value on the top of the stack and replace it with the max value for that parameter, and popfd right before the original fstp command so hopefully flags would be as they're supposed to. Crashes immediately. 
The player id seems to be [[esi+24]+48c] or [[esi+28]+48c]. +24 and +28 are the same pointer.
| Code: |
[ENABLE]
alloc(energy_newmem,2048)
label(energy_returnhere)
label(energy_originalcode)
label(energy_exit)
label(energy_savedAOB)
registersymbol(energy_savedAOB)
aobscan(searchedAOB,DC 86 84 00 00 00 DD 9E 84 00 00 00)
energy_newmem: //this is allocated memory, you have read,write,execute access
//place your code here
pushfd
pushad
lea edx,[esi+28]
mov edx,[edx]
test edx,edx // make sure edx =/= 0
je energy_originalcode
mov edx,[edx+48c]
cmp edx,00000001 //check if player
jne energy_originalcode
fstp st(0) //throw away current energy value
fild [esi+200] //load max energy
popad
popfd
fstp qword ptr [esi+00000084]
jmp exit
energy_originalcode:
popad
popfd
fstp qword ptr [esi+00000084]
energy_exit:
jmp energy_returnhere
searchedAOB+6:
energy_savedAOB:
jmp energy_newmem
nop
energy_returnhere:
[DISABLE]
energy_savedAOB:
db DD 9E 84 00 00 00
unregistersymbol(energy_savedAOB)
dealloc(energy_newmem)
|
The weird thing is I'm using almost exactly the same code for fuel here and it seems to work fine.
| Code: |
[ENABLE]
alloc(fuel_newmem,2048)
label(fuel_returnhere)
label(fuel_originalcode)
label(fuel_exit)
label(fuel_savedAOB)
registersymbol(fuel_savedAOB)
aobscan(searchedAOB,dc 6e 7c dd 5e 7c dc 86 84 00 00 00 dd 9e 84 00 00 00)
fuel_newmem: //this is allocated memory, you have read,write,execute access
//place your code here
pushfd
pushad
lea edx,[esi+28]
mov edx,[edx]
test edx,edx
je fuel_originalcode
mov edx,[edx+48c]
cmp edx,00000001
jne fuel_originalcode
popad
popfd
//fstp st(0)// since st(1) is the value we want to be on top
fsubr qword ptr [esi+7C] // pops st(0) and st(1), subtracts st(1)-st(0), and pushes the result
fstp st(0)
fild [esi+1f0] //load max fuel
fstp qword ptr [esi+7C]
jmp fuel_exit
fuel_originalcode:
popad
popfd
fsubr qword ptr [esi+7C]
fstp qword ptr [esi+7C]
fuel_exit:
jmp fuel_returnhere
searchedAOB:
fuel_savedAOB:
jmp fuel_newmem
nop
fuel_returnhere:
[DISABLE]
fuel_savedAOB:
db dc 6e 7c dd 5e 7c
unregistersymbol(fuel_savedAOB)
dealloc(fuel_newmem)
|
|
|
| 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
