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 


How to hack movement speed ?

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine
View previous topic :: View next topic  
Author Message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Wed Feb 10, 2016 12:30 pm    Post subject: How to hack movement speed ? Reply with quote

Hello there,

I am trying to realize a movement speed hack in the game Resident Evil 5 and I want to do it without using Cheat Engine's integrated speedhack function.

Upon research I found some interesting topics regarding this, amongst them this thread


So I am figuring, that the most possible way to alter my characters movement speed would be to find my player coordinate and figure out what instructions access my coords.

There are two smaller problems with this in this game mentioned above:

    There seem to be multiple addresses that store the same coordinates, is there a recommended one I should pick ? For instance, try to find out what accesses that address, that I can also edit the value of to make me teleport ?

    And second: I'm getting a whole list of instructions once I unpause the game. The last 5 in this screenshot appear when I start walking / running






So because of the thread I found above I tried the instruction that looked the same, namely the one with 78 calls
    movss [edi+38],xmm2


This is the Auto Assemble script that I generated which instantly crashed my game. Since I am not good with those script and neither with ASM I would appreciate a quick check if everything is correct.

Code:


define(address,"re5dx9.exe"+878A10)
define(bytes,F3 0F 11 57 38)

[ENABLE]


assert(address,bytes)
alloc(newmem,$1000)

label(code)
label(return)
label(value)

newmem:
addss xmm2 [value]
movss [edi+38],xmm2
jmp return

code:
  movss [edi+38],xmm2
  jmp return

address:
  jmp code
return:

value:
dd (float)1.5
[DISABLE]

address:
  db bytes
  // movss [edi+38],xmm2

dealloc(newmem)




What I also tried, was to get injured in-game, which reduces the running speed (when holding SHIFT) and scan for increased / decreased float values , but I could not find anything interesting.


Dissecting data/structure also seems to be like a big mess in this game which doesn't make it easier. Basically what I did was find player health or coordinates and look at what's at the base address..

I would really appreciate if someone can help me out here. I feel like what I want to realize is not that hard but my limited knowledge stands in my way

_________________
Hyes!


Last edited by sh00ter999 on Wed Feb 10, 2016 12:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Wed Feb 10, 2016 12:48 pm    Post subject: Reply with quote

This will crash the target process:

Code:
address:
  jmp code
return:

value:
dd (float)1.5


You must move the value stuff above the return.

Before you do anything, make sure you are working with proper coordinate values. Two simple ways to check this:

1. Freezing the values locks you in place without any 'ghosting' effect.
2. You can teleport through objects by changing your coordinate value (without getting hung up or stopping short because of the ground or some other object).

Once you are sure that you have the proper coordinate values, you can proceed with finding a proper instruction to work from.

You may have to experiment here, as some of the instructions may handle gravity or some collision check etc..
Back to top
View user's profile Send private message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Wed Feb 10, 2016 1:24 pm    Post subject: Reply with quote

++METHOS wrote:
This will crash the target process:

Code:
address:
  jmp code
return:

value:
dd (float)1.5


You must move the value stuff above the return.


You may have to experiment here, as some of the instructions may handle gravity or some collision check etc..


Thank you for you assistance, ++METHOS.

That makes sense, I moved the value: stuff above the return, no more instant crash.

Quote:
Before you do anything, make sure you are working with proper coordinate values. Two simple ways to check this:

1. Freezing the values locks you in place without any 'ghosting' effect.
2. You can teleport through objects by changing your coordinate value (without getting hung up or stopping short because of the ground or some other object).

Once you are sure that you have the proper coordinate values, you can proceed with finding a proper instruction to work from.


Yeah, I almost thought so already. I made sure to find the proper address now.


    So this is the current status: I have the pointer to one of my characters coordinates that changes while moving around.
    I find out what accesses the address pointed at by my pointer
    I get the same results as in my original post.
    I choose that one instruction that comes up when walking movss [edi+38],xmm2
    I auto assemble that point in memory with the script posted above, including the value: fix
    I use any of the templates, in this case I chose Full Injection I suppose, could this make any impact ?



I can execute the script just fine, and my game still runs but no altered movement speed Confused

_________________
Hyes!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Wed Feb 10, 2016 1:35 pm    Post subject: Reply with quote

This is where an understanding of assembly can help. I would start with the instruction that is writing to your value and analyze the code around that instruction or backtrace to see if you can find anything useful. It may take some time to narrow in on the right instruction, but if it were easy, everyone would be doing it. Cool

EDIT:
Probably...

Code:
movss [ebx+38],xmm3


If you analyze the code above this instruction you might see two more instructions:

Code:
addss xmm3,xmm4
addss xmm2,xmm0
That should get you started with something nice. Very Happy

EDIT2:
Click here for cheat sheet. Very Happy
Back to top
View user's profile Send private message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Thu Feb 11, 2016 6:20 am    Post subject: Reply with quote

Wow, you're incredible ++METHOS !!
Thank you so much for your time and effort. Your video shows exactly what I would want to achieve.

I wish I could use your Cheat Table but unfortunately it seems that we are using different game versions, thus it is not working for me.
I am using the Steam Gold Edition Version of the game without Games For Windows Live. When I launch up the game my process is called re5dx9.exe and not Laucher.exe which makes me think you might be running the GFWL version.

Anyhow, me not being able to use your CT means that I have to figure out a way to apply your script to my version.

I have studied it for a while I can pretty much break down most of the assembly, but I am still left with a bunch of questions...

First off, I have taken your suggestion to heart to look above the instruction
Code:
movss [edi+38], xmm2

Notice that it's edi+38 for me and not ebx. Would that play any role ?

Here is a screenshot of what I am seeing and I can't quite find anything like
Code:
addss xmm3,xmm4
addss xmm2,xmm0





Maybe I should stop at this point before writing another wall of text, so I can first figure this out.

Leaving skywalker and Elevation aside, could you or maybe anyone else confirm that I understand this portion correctly:

Code:

newmem_speed:
cmp [player_id_address],ebx
jne @f
cmp [value],0
je @f
mulss xmm0,[value]
mulss xmm4,[value]

@@:
addss xmm2,xmm0
movss xmm0,[ebx+34]
jmp return_speed

value:
dd (float)0

aob_speed:
jmp newmem_speed
nop
nop
nop
nop
return_speed:



Basically newmem_speed: is a point in memory that you declare and find at the top of the script by scanning for a unique set of bytes, right ?

Code:
aobscanmodule(aob_speed,launcher.exe,f3 0f 58 d0 f3 0f 10 43 34)
alloc(newmem_speed,$1000)


Then you compare ebx (What're its contents?) to player_id_address that you retrieve further down in the script. Without going indepth here, what is player_id_addresse's use here ? Does it have to do with determining which one is Player1, as the pointer is pointing to the player 1 base and the partner base alternately?

So if the comparison does not match, you jump forward to the @@: bit. Else you compare value to 0 (which you can set in the Cheat Engine address list). If Value is still 0 you jump to @@: as well, otherwise (say, value is 5) you multiply the contents of the xmm0 and xmm4 registers by value, right ?

Does this mean that the code at @@: is the original piece of code.. ?

And aob_speed: at the end declares what to do at the entry point after scanning the array of bytes, namely jump to our own, new piece of code.


I am embarrassed to ask for any more of your patience but your help would be greatly appreciated.

It would be very nice and - more desirable - to figure out how to do it on my own and take the new knowledge with me, but maybe it would be less complicated to just tell me how exactly you got those three array of bytes for the aob scan and then I should be able to apply your CT 1:1


I will make sure to expand my knowledge further regarding all this, while someone submits a reply (or not Razz)

_________________
Hyes!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Thu Feb 11, 2016 1:02 pm    Post subject: This post has 1 review(s) Reply with quote

sh00ter999 wrote:
unfortunately it seems that we are using different game versions, thus it is not working for me.
-Yeah, I saw that. The code should be similar enough to figure something out, I think.

sh00ter999 wrote:
First off, I have taken your suggestion to heart to look above the instruction
Code:
movss [edi+38], xmm2

Notice that it's edi+38 for me and not ebx.
-Use the instruction that, if changed to no operation, will not allow your character to walk from your current position.

sh00ter999 wrote:
Here is a screenshot of what I am seeing and I can't quite find anything like
Code:
addss xmm3,xmm4
addss xmm2,xmm0
-Once you find the appropriate instruction that when nop'd, doesn't allow your character to move, you should see something similar. You may have to experiment some by injecting some code at the addss xmm?,xmm? instructions. When you inject, you can quickly test by doing this:

Code:
//code
addss xmm?,xmm?
addss xmm?,xmm?
addss xmm?,xmm?
//originalcode
...basically just performing more addition in order to see if your speed increases.

sh00ter999 wrote:
Leaving skywalker and Elevation aside
-I just added that for fun. Very Happy

sh00ter999 wrote:
Basically newmem_speed: is a point in memory that you declare and find at the top of the script by scanning for a unique set of bytes, right ?
-It's just like any script that you let CE build for you. By default, it's just newmem. We use the AOB to find the injection point and use the label 'newmem' (or whatever) to serve as our address in memory to jump to for our codecave. We allocate memory and define our lable accordingly. I added the _suffix tags because I was combining 3 different scripts.

sh00ter999 wrote:
Then you compare ebx (What're its contents?)
-If you notice, ebx, at this instruction, is the register that is being used to handle our coordinates. [ebx+30], [ebx+34] and [ebx+38]...X, Z and Y axis (or whatever), respectively. That register may change, depending on where you inject, but the offsets will be the same (usually).

sh00ter999 wrote:
to player_id_address that you retrieve further down in the script. Without going indepth here, what is player_id_addresse's use here ? Does it have to do with determining which one is Player1, as the pointer is pointing to the player 1 base and the partner base alternately?
-The third injection is solely for the purpose of establishing a filter so that the flash/skywalker scripts ONLY affect our hero player. The third injection point was found by right-clicking on one of the coordinate values and looking to see what accesses it. From there, you can right-click inside the debugger window that pops up to check to see if the opcodes access any other addresses. It will show you how many addresses are being accessed, which will allow you to select an instruction that is ONLY accessing that address and nothing else. You can return to your game and play for a moment to see if the numbers change. If you do that, you may notice that at least one of the instructions is ONLY accessing your hero's coordinates and nothing else. By injecting at that instruction, you can store the value of edx (or whatever register) that contains the address/base address of your hero's coordinates. You can use that as an ID for your other scripts.

By the way, I haven't tested anything on this target, but since you have a filter for hero player coordinates, this will allow you to add additional features...such as stop everyone except hero player from being able to move (or only allow them to move really slowly...or really fast, if you're in to that)...make everyone except hero player go in the air...teleport scripts...vacuum scripts etc. etc.. You can also add additional filters so that your partner is or isn't affected. Cool

sh00ter999 wrote:
So if the comparison does not match, you jump forward to the @@: bit. Else you compare value to 0 (which you can set in the Cheat Engine address list). If Value is still 0 you jump to @@: as well, otherwise (say, value is 5) you multiply the contents of the xmm0 and xmm4 registers by value, right ?
-Yes. We add the extra compare because we don't want the code to multiply our speed by 0 when the script is activated, which is what the value of 'value' will be when our script is activated.

sh00ter999 wrote:
Does this mean that the code at @@: is the original piece of code.. ?
-Basically.

sh00ter999 wrote:
And aob_speed: at the end declares what to do at the entry point after scanning the array of bytes, namely jump to our own, new piece of code.
-Again, just more basic stuff that I altered slightly.

sh00ter999 wrote:
but maybe it would be less complicated to just tell me how exactly you got those three array of bytes for the aob scan and then I should be able to apply your CT 1:1
-Sure.

Speed:
Find player coordinates. Check to see what is writing to it. NOP the instructions until you find the one that will prohibit movement. From there, analyze code above to determine where speed is being set. Experiment. In this case, two values had to be manipulated (instead of one, like most games). I think there are more in this case, but they're not needed.

Skywalker:
Find player coordinates. Determine which coordinate is Y axis (or, elevation axis). Set it to a higher value and freeze it so that your character is in the air. Right-click on it to see what is writing to it. NOP the instructions until your character stops flickering and/or gravity is canceled etc..

Player ID:
See above.
Back to top
View user's profile Send private message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Fri Feb 12, 2016 10:41 am    Post subject: Resident Evil 5 Vacuum hack, Movementspeed hack This post has 1 review(s) Reply with quote

++METHOS, thank you so much for your thorough answer, yet again. You are a GOD

You were a huge help and I finally managed to realize the same kind of movementspeed hack.
It took me lots of trial and error and experimenting but I learned a good bunch about ASM and finally succeeded in this.

Quote:
Use the instruction that, if changed to no operation, will not allow your character to walk from your current position.


You were right. Initally, the address I had found with my most reliable pointer would work when freezing in the address list, but when nop'ing the instruction in memory view, I could still walk around, so it was clearly the wrong one.
I was a bit stubborn and hesitant to re-scan for my coordinates, that's what stood in my way in the beginning.


Quote:
You may have to experiment some by injecting some code at the addss xmm?,xmm? instructions. When you inject, you can quickly test by doing this:


Code:
//code
addss xmm?,xmm?
addss xmm?,xmm?
addss xmm?,xmm?
//originalcode   


...basically just performing more addition in order to see if your speed increases.



This was a very valuable tip. Thanks for that. I used this to quickly experiment and find out which register stored my position.
But this is also where I encountered my second big hardship. I wouldn't have to experiment so damn long if I had just read the assembly carefully enough. Like you pointed out, you need to multiply two values / xmm registers to increase speed in this game. So by experimenting I was able to find speed for one axis and alter it by injecting at that point in memory but struggled to get the other axis work properly so I could move back/forth and left/right with increased speed. Again, my mistake was that I did not look at the assembly careful at all. I ended up thinking I had to do two script injections at two points in memory and I even ended up modifying things around the height even though I could've easily made out the differences by looking at the offsets Confused


Creating this, I kept going back and forth between what I had written and your Cheat Table script and at first, I did not understand how you could realize increased speed for both axes with only one injection and how you would know which two xmm-registers to multiply. You had something like
Code:
mulss xmm0,[value]
mulss xmm4,[value]

And I kept adding them together like you hinted,

Code:
code:
  addss xmm3,xmm4
  addss xmm3,xmm4
  movss xmm4,[re5dx9.exe+CBD700]
  jmp return



Code:
code:
  addss xmm2,xmm0
  addss xmm2,xmm0
  movss xmm0,[ebx+34]
  jmp return



which worked fine but was very unelegant.

Anyhow, even though we have different game versions it's the same two registers which I have to multiply, and the answer was here all along:




As one can see, the highlighted instruction is where I landed after checking what wrote to either my X or Z coordinate. And above are the desired addss instructions. Something at ebx+50/54/58 (ebx=playerbase) is being filled into the registers xmm0, xmm3, xmm4. And by adding the address manually, I checked to see that the value at those ebx+50 etc. was always 1.0f. Some multiplication is going on (contents of xmm2 * 1.0f). Then the players X-coordinate at ebx+30 is being moved into the xmm2 register and the contents of xmm0 is being added to our x-coordinate which is now stored in xmm2.

I tried to use a shortcut by editing ebx+50 because I had no idea what those were for exactly, but as it turns out they are related the model scale or something Very Happy

So it's clear now that this is where we want to modify the instruction. In order to increase our walking speed we just have to edit the 'something' that is being added to our coordinates each time we move. This is how I finally realized that you have to multiply xmm0 and if you follow that same procedure, xmm4 for the Z-Coordinate.

Now I am not entirely sure with this, but I think I just happened to have 'luck' the first time I tried it. Namely, the Auto Assembly script has to be injected at the lowest of all the entries to ensure you can alter everything in one go.
So coming from the bottom to the top, I chose the first addss for injection, and if I modify xmm0 and xmm4 at that point I would get the results I want. But I assume if I had inserted my script at the X-Coordinate (addss xmm2,xmm0) then my edits to xmm4 would have been overwritten/further altered, for instance by the upcoming mulss xmm4,xmm5. So I could have run into the scenario of running faster along the Z-Axis than along the X-Axis, do I get this right?

Long story short this is how I finally found out that you just had to multiply xmm0 and xmm4 with a desired value to get the movementspeed hack going.


Quote:
If you notice, ebx, at this instruction, is the register that is being used to handle our coordinates. [ebx+30], [ebx+34] and [ebx+38]...X, Z and Y axis (or whatever), respectively. That register may change, depending on where you inject, but the offsets will be the same (usually).

Oh man, that makes sense of course. Thanks for clarifying that. I should've known Embarassed

Quote:
The third injection is solely for the purpose of establishing a filter so that the flash/skywalker scripts ONLY affect our hero player. The third injection point was found by right-clicking on one of the coordinate values and looking to see what accesses it. From there, you can right-click inside the debugger window that pops up to check to see if the opcodes access any other addresses. It will show you how many addresses are being accessed, which will allow you to select an instruction that is ONLY accessing that address and nothing else. You can return to your game and play for a moment to see if the numbers change. If you do that, you may notice that at least one of the instructions is ONLY accessing your hero's coordinates and nothing else. By injecting at that instruction, you can store the value of edx (or whatever register) that contains the address/base address of your hero's coordinates. You can use that as an ID for your other scripts.


Oh, wow. Now by reading that your script makes much more sense. I did not know about this debugger feature, yet. That's pretty darn useful, thanks! That's a really clever way to filter shared functions.
Using this information I was also able (after some trial and error) to find a unique instruction that only accesses my hero's address. After comparing again it turns out I found the same as you (which was kind of motivating Very Happy )

Thank you so much for your all of your help; I almost decided not to post this thread because I figured I wouldn't be able to realize it in the end Laughing


Quote:
By the way, I haven't tested anything on this target, but since you have a filter for hero player coordinates, this will allow you to add additional features...such as stop everyone except hero player from being able to move (or only allow them to move really slowly...or really fast, if you're in to that)...make everyone except hero player go in the air...teleport scripts...vacuum scripts etc. etc.. You can also add additional filters so that your partner is or isn't affected.


That's very interesting, the first thing I could think of when reading this was a vacuum script exactly.
Last year I attempted to hack this game for a bit but I gave up at some point when trying to make 3D radar for all enemies in the map. My problem was that I didn't (and still don't) know how to find all the enemy entities location realiably, other than manually scanning for each one seperately Embarassed
But now, with this new filtering method I am confident that it can't be that hard to realize a vacuum script.

I started off with creating a simple freeze all enemies in place, worked nicely.

I wrote something like this into my speed script to test it real quick
Code:
[ENABLE]
aobscanmodule(INJECT,re5dx9.exe,F3 0F 58 D0 F3 0F 10 43 34) // should be unique
alloc(newmem,$1000)

registersymbol(value)

label(code)
label(return)
label(value)
label(freeze)
label(zero)

newmem:
  addss xmm2,xmm0
  movss xmm0,[ebx+34]
  jmp return

freeze:
  mulss xmm4,[zero]
  mulss xmm0,[zero]
  jmp newmem

zero:
db 0

code:
  cmp [player_id], ebx
  jne freeze
  cmp [value],0
  je newmem
  mulss xmm4,[value]
  mulss xmm0,[value]
  jmp newmem

value:
dd (float)0.0

INJECT:
  jmp code
  nop
  nop
  nop
  nop
return:
registersymbol(INJECT)


(Screenshot for better readability)

Very dirty and ugly script, I know. My big question though, is, whether there is a more elegant way to realize the ..
Code:
mulss xmm4,[zero]

.. without having to declare and an extra label, just to store one zero? Or is this the way to go ?


I tested vacuum like this:

Code:
[ENABLE]

aobscanmodule(Vac,re5dx9.exe,F3 0F 11 5B 38 EB) // should be unique
alloc(newmem,$1000)

label(code)
label(return)

newmem:
cmp [player_id], ebx
je code
movss xmm2,[player_id+30]
movss xmm0,[player_id+34]
movss xmm3,[player_id+38]

code:
  movss [ebx+38],xmm3
  jmp return

Vac:
  jmp newmem
return:
registersymbol(Vac)


and came up with a result that looked like this:


(Playing the bonus game type here, called Mercenaries)

Now, apparently not only living and moving entities use those coordinate functions, climbable ladders, that electricity box, collectable timers, treasure chests, doors, cars, trees, junk etc. They all are affected by it.

This may not be a biggie yet, just gotta find another sort filter, maybe try to find the entity by finding it by its health or something.

What I found disturbing is the fact that I inteded all of those things to teleport to my coordinates, but they seem very scattered around.
I am almost sure the error lies in the
Code:
[player_id+30]

How do I tell the scrip that this is a pointer to my coordinate, feel like it interprets the player_id+30 plainly, just as if I were to add the address manually to the address list and enter player_id+30 in the normal address input field, instead of ticking Pointer and adding it with an offset accordingly Confused


Maybe someone could elaborate that Smile

I appologize dearly for the long wall of text again, I did not intend to babble for so long Neutral

_________________
Hyes!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Fri Feb 12, 2016 2:10 pm    Post subject: Re: Resident Evil 5 Vacuum hack, Movementspeed hack Reply with quote

Good work. Very Happy

sh00ter999 wrote:
I started off with creating a simple freeze all enemies in place, worked nicely.... ...My big question though, is, whether there is a more elegant way to realize the...
Code:
mulss xmm4,[zero]

.. without having to declare and an extra label, just to store one zero? Or is this the way to go ?
-There are several ways you can do it. But this being an oddball case, it may be better to just inject at the instruction that is handling the coordinates and just NOP it with a filter.

sh00ter999 wrote:
I tested vacuum like this:
...
What I found disturbing is the fact that I inteded all of those things to teleport to my coordinates, but they seem very scattered around.
-Here is a vac template that you can go by. It's for a 2D game and it's a bit dated, but you should be able to figure something out. If not, just ask. I will be glad to help. This will allow you to freely set the vac location, move away, and turn the vacuum on/off whenever you want. Of course, you can change it to do whatever you want.

Regarding inanimate objects getting vac'd...this may not be avoidable, depending on the game. You may have to filter them out, or, find a better instruction that is ONLY accessing coordinates for living objects. You just have to check to see if one is available. Usually, there is. Additionally, if you're going to create a vac/teleport cheat, you'll want to use one of the instructions that is accessing coordinates several times per second, that way, your cheat will be instant without having to move first, or have a delay etc..

EDIT:
By changing the injection point for player ID and making a few adjustments, we can filter out both, the hero and the sidekick. With this script, you can increase speed for both hero and sidekick while also freezing all of the zombies in place. Very Happy
Back to top
View user's profile Send private message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Fri Feb 12, 2016 5:53 pm    Post subject: Reply with quote

Thank you! I couldn't have done it without you Cool

Quote:
There are several ways you can do it. But this being an oddball case, it may be better to just inject at the instruction that is handling the coordinates and just NOP it with a filter.


Whoops, yeah you are right, makes much more sense. NOP'ing in that case completely slipped my mind.


Quote:
Here is a vac template that you can go by. It's for a 2D game and it's a bit dated, but you should be able to figure something out. If not, just ask. I will be glad to help. This will allow you to freely set the vac location, move away, and turn the vacuum on/off whenever you want. Of course, you can change it to do whatever you want.


That's a really nice template, definitely helped. I downloaded the game and tested the script for a bit. Sure enough that 2D game seems kind of fun too Very Happy

Looking at your work for Secrets of Grindea I could adjust my script again.

Code:

[ENABLE]
aobscanmodule(Vac,re5dx9.exe,F3 0F 11 5B 38 EB) // should be unique
alloc(newmem,$1000)

label(code)
label(return)
label(player_x)
label(player_y)
label(player_z)
label(set_coords)

newmem: //Enable VAC for anything _but_ Player1
cmp [player_id], ebx
je set_coords
push edx
mov edx,[player_z]
mov [ebx+38],edx
mov edx,[player_y]
mov [ebx+34],edx
mov edx,[player_x]
mov [ebx+30],edx
pop edx
jmp code

set_coords:
push eax
mov eax,[ebx+38]
mov [player_z],eax
mov eax,[ebx+34]
mov [player_y],eax
mov eax,[ebx+30]
mov [player_x],eax
pop eax
jmp code

code:
  movss [ebx+38],xmm3
  jmp return

player_x:
dd 0
player_y:
dd 0
player_z:
dd 0

Vac:
  jmp newmem
return:
registersymbol(Vac)


I left out any load/save position functionality because I just wanted to keep it minimalistic for now. Not sure how far I want to take this, but having enemies appear at my position (or a little bit offset from my coords) should suffice.



This works as intended for me, now I still have to find a way to filter all those objects out of the routine Smile

Q: Regarding the script: Why would something like
Code:
mov [ebx+38],[player_id+38]

not compile ? player_id being Player1's base address retrieved in a seperate script. I know this question means that there is something fundamental that I am not yet grasping. I was just wondering, or rather I was a bit surprised that this back and forth loading into eax is the way to go. Why do we need to push eax and load our values into it inbetween every step. Why would
Code:
mov [ebx+38],[player_z] //ebx+38=enemy z-coord

(from the above script) not make sense?

Quote:
Regarding inanimate objects getting vac'd...this may not be avoidable, depending on the game. You may have to filter them out, or, find a better instruction that is ONLY accessing coordinates for living objects. You just have to check to see if one is available. Usually, there is. Additionally, if you're going to create a vac/teleport cheat, you'll want to use one of the instructions that is accessing coordinates several times per second, that way, your cheat will be instant without having to move first, or have a delay etc..


Yeah I think I can do all that. I'll look into it asap.

Quote:
By changing the injection point for player ID and making a few adjustments, we can filter out both, the hero and the sidekick. With this script, you can increase speed for both hero and sidekick while also freezing all of the zombies in place.


That's very neat! I already downloaded the CT and had a glance at it but I will have to take a closer look tomorrow morning when I wake up, now it's sleepy time Smile
This should also allow to easily teleport the sidekick to ourselves on key press, in case she is running off on her own. I would prefer to leave the partners speed unaltered because there is some unintended behavior coming up when increasing the speed. For instance when climbing up a ladder or making a jump over a gap, you fly off many times over which can result in falling out of the map Shocked

_________________
Hyes!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Fri Feb 12, 2016 6:19 pm    Post subject: Reply with quote

Regarding the mov [register+offset],[symbol] - you can't do that. To explain the why, you'll have to ask someone else. Very Happy

Here is a vacuum table, for your reference. I posted a video of it here. You may have to improve the filter...I didn't spend much time on it. I added the coordinate values to the table so you can teleport hero and/or sidekick if you get stuck behind a wall or want to freeze your partner in place or something. I also added the ability to allow you to control the speed for hero and sidekick, separately, and incorporated a switch to freeze zombies in place.
Back to top
View user's profile Send private message
sh00ter999
Advanced Cheater
Reputation: 1

Joined: 17 May 2008
Posts: 89

PostPosted: Sat Feb 13, 2016 11:26 am    Post subject: Reply with quote

That's pretty awesome, really!

I took a look at your script and I learned some new things again.

Some quick questions:

1.) I know how you have found the instruction to distinguish between hero and partner but how did you figure to look in EDI (or any register in that point in memory) to find out that the edi holds 1 for when the partner is accessing the instruction and 0 when it's the hero ? I know you can easily check those things in the debugger -> More Information window but I am asking is this also a go-to thing to do in other games ? Found this filter very clever Smile

2.) How did you go about finding these vacuum filters ?

Code:
cmp [esi+198],ffffffff
je originalcode_vac
cmp [esi+160],ffffffff
je originalcode_vac


I have messed with it for hours now but I still have no clue. what's esi+198 and how did you come up with it ? And what exactly are you comparing it to there? Some similar procedure as when you were filtering partner/hero ?


On a small side note: You were right, the vac does not work with all kind of enemies that appear further up in the game, but as far as I am concerned it doesn't really matter Razz Just wanted to explore the nature of a vacuum hack and mess with it for a bit which I've had enough off (in this game at least Very Happy)


Since we are in a movementspeed hack thread I wanted to get rid of this last question.
It's regarding the game Final Fantasy XII for the PS2, played on the PCSX1.4.0 emulator:
Do you think that it could cause trouble because of the fact it's an emulation ?

I found a coordinate address that when frozen blocks movement on one axis and when I NOP the according instruction I am solidly frozen in place ( no movement possible ). So I am thinking this is the place where I should modify my speed.


Could you look at these opcodes and take a guess at what could be done? All my experimenting got me stuck under the map or elevating in the sky on movement (I'm almost positive I was editing x/z and not y)

_________________
Hyes!
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Sat Feb 13, 2016 2:03 pm    Post subject: Reply with quote

sh00ter999 wrote:
1.) I know how you have found the instruction to distinguish between hero and partner but how did you figure to look in EDI (or any register in that point in memory) to find out that the edi holds 1 for when the partner is accessing the instruction and 0 when it's the hero ? I know you can easily check those things in the debugger -> More Information window but I am asking is this also a go-to thing to do in other games ?
Yes. More methods can be found here.

sh00ter999 wrote:
2.) How did you go about finding these vacuum filters ?
-Data structure dissection. Study the last step of the CE tutorial.

sh00ter999 wrote:
On a small side note: You were right, the vac does not work with all kind of enemies that appear further up in the game
-Keep in mind, some zombies won't teleport right away. If you try to shoot them, nothing happens. If you kill some of the zombies in the vac pile, they will eventually end up there and you can kill them. It seems that the visual components of the character object aren't getting moved right away. I don't know why this occurs...maybe a fail-safe by developer to avoid lag. This may be the reason why you are experiencing issues (I really don't know, as I've only played with this game for a handful of minutes, at most).

sh00ter999 wrote:
Since we are in a movementspeed hack thread I wanted to get rid of this last question.
It's regarding the game Final Fantasy XII for the PS2, played on the PCSX1.4.0 emulator:
Do you think that it could cause trouble because of the fact it's an emulation ?
-It can. It depends on the emulator. Some emulators have their own, built-in debugger. Finding good signatures can be a pain.

sh00ter999 wrote:
So I am thinking this is the place where I should modify my speed.
-Every game is different. While some, cookie-cutter scripts can be used, the methods aren't always the same. The code is rarely the same. But, that's a good thing, as it presents itself as a new puzzle to solve. Anyway, you just have to dig in and figure it out. The more you do these things, the better you'll get. But some targets will still be a pain, no matter how good you get, as things are always evolving.
Back to top
View user's profile Send private message
UltimatePanther
Newbie cheater
Reputation: 0

Joined: 04 Jun 2015
Posts: 13
Location: Ontario, Canada

PostPosted: Thu Jun 30, 2016 12:35 am    Post subject: About Skywalker and Speed Reply with quote

Speed: so you said plauer speed could be altered by finding player coordinates. I found my Z Coordinate and i don't know what do from there. The instruction is mov [rbx+000005FC],eax.

Skywalker: I have the Y coordinate but when i freeze the y coordinate in mid air, my character doesn't walk, he gets into a falling position and i can't make him walk or anything.

_________________
Cheat Engine
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine 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