Cheat Engine Forum is working again! Yay!
Today is a good day !
Before this, i am very sad about what happen at forum.cheatengine.org , recently it have been targeted by the big company from the game industry (Seems like its due to copyright claims by Bethesda, claiming Cheat Engine is violating the works of companies like Bethesda ect...) [you know the big one can name any reasons]giving Dark Byte the admin and creator of Cheat Engine such a Big problem.
Read more here
{ the site cannot work correctly at that time due to DDos atack }
Besides an amplified DDoS attack also a 'Notice of Infringment' from a representative of Bethesda and others. (is this coincidence ? ................ )
Dark Byte , my thanks to you for all your hard work, i hope all the problem have ben solved.
i am releasing a series of all i learn from forum.cheatengine.org , since it working now i think this will be the final part.
Thanks!
Forge By Games # ForgeByGames
this is the 3rd post i learn
all credit go to , all these from
http://forum.cheatengine.org/viewtopic.php?t=570083{ this site was down due to DDos atack and the other trouble stuff, now it working fine}
writen by
Rydian
Grandmaster Cheater Supreme
Invincibility Code Fixes (Segregating Players/Enemies)
{ You get no damage while your enemies still get damage }
In many cases with making code patches (AOB scripts, injection, what-have-you) for games, the
simplest way to go about making invincibility for the player is to find the code that damages the
player and disable it in one way or another. However for a number of games this will also make
enemies invincible (or whatever the code effect is) and this is undesirable.
This guide will show you three main methods to solve this problem in order of ease. I will be using
Rogue Legacy as the example game and focusing on invincibility, but the basic concepts used here
can apply to almost any other game and code situation. This guide also assumes that you know
the basics of making code edits with CE, otherwise you wouldn't be having this issue.
1 - Target Unique Reads
The basic problem with invincibility codes making monsters invincible too is that the code is shared,
the code you targeted affects all "players" or "entities" or whatever, so when you edit the code it
changes the effect for everything that the code runs on.
So instead of neutering the code that edits your health, take a different approach. Find some
code that reads just your own health, and then edit that code so it also sets your health to full
constantly, overriding other changes to it.
The first thing to do is, as usual, find your health address. This time right-click it and find what
accesses the address. Run around, hit, and be hit by other enemies for a few seconds and
then stop the logging. Check out the instructions, chances are there will be a lot of them.
For this type of case, we want to find one of the codes that's running all the time. It could be a
number of different functions to do this, such as the code that reads your HP in order to draw or
update the health bar on-screen, or code that constantly checks your HP to determine if you died.
We have two opcodes that ran a lot during the short test (the first two), so either of them should
work fine. We'll choose the first one for simplicity here. Click it and click "Show Disassembler"
as usual to bring it up in the memory browser window. The first thing to do is to make sure that
it's an opcode you know enough to edit or overwrite.
If so, then the next step is to make sure that the code only works on us. Right-click the highlighted
line and choose "Find what addresses this code accesses" to bring up a new logging window.
"But Rydian, this is a .NET game, if you click th-" Shhhh. This is a general tutorial so we shouldn't
be relying on things like that which won't give any info for other games. Just follow along as if
the data collector didn't exist because for most games it doesn't and you need to guess+test.
You should run around, hitting other monsters, getting hit, and repeating "SCIENCE HERE, MAKE
WAY FOR SCIENCE HAPPENING" while testing to see if the code edits other addresses. Then check to see if the targeted opcode works on just player data or the data of other things too.
In this case the targeted opcode only reads our health so we're good. In your case if it reads more,
then you'll want to check out other opcodes that do constant reads in order to find one that works.
Anyways once you have code that reads your address and only your address, you can edit it to
overwrite the value what whatever you want depending on what your goal is. Just because the
original purpose was to read doesn't mean you can't tell it to also write, you know.
So like that the game will constantly refill your health, and only do it to your health.
2 - Hack A Different Mechanic
While normally the fastest and most direct method to avoid taking damage in games is to neuter
the function that subtracts from your health, there's other mechanics you can focus on as well.
One of my favorites is "mercy invincibility" and that's what this will focus on. There's other mechanics you can focus on as well if you think outside of the box, but this is often simple enough.
This is a concept in many games where, after getting hit, you have a brief period where you can't
get hit again (a mechanic intended to prevent stunlock on the player). Usually during this period
you'll be flashing or faded out or something, and enemies won't be able to harm you (and in many
cases won't even collide with you). Since this is a mechanic originally designed to prevent
annoyance for the player, this tends to be a mechanic that only applies to the player you're
controlling so that means it will rarely run into the issues that health codes can run into.
So since mercy invincibility lasts a specific amount of time, there must be a value to keep track of it
and game code to set, count down, and check that value. There should also be code that checks to
see if the player is invincible or not when trying to hurt him. So there's two ways to go about this.
For both of the methods, depending on the game you may find it useful to be able to pause and resume the game quickly. If you go into Cheat Engine's settings, in the hotkey settings you can set hotkeys for speedhack values. I tend to set one hotkey for speed 0 and another for speed 1. This means I can press one hotkey to "pause" the game and a second hotkey to resume. This gives plenty of time to scan for short-lived timer values or flags for mercy invincibility.
In this case we'll search for a value that increases when you get hit, and then decreases as the timer for invincibility wears off (and then raises again when you get hit). After some time spent searching, the value has been found!
So there's two ways we could approach this. The first method would be to find what writes to that address and find the code that's responsible for making it count down. This is what I tend to do when I want a quick-and-easy invincibility code, because it's a simple process to find the timer and disable it. So here I ran around and got hit twice, and allowed the timer to count down twice.
And the targeted code is the one we need. It's the one that reduces the timer repeatedly until it's empty, so if you edit that code to no longer write the edited value then once you get hit the first time your invincibility shouldn't wear off anymore. Yayyyy.
Now, what if we wanted to, instead, change the logic? With the quick-and-easy invulnerability code, the player still needs to get hit once to activate it. To see another method of doing it, find what accesses that address and you'll see some comparisons and stuff.
Now there's three of them here, and it's not immediately obvious which is the one we want. One of them might be just for the visual effect, one of them might be a check for setting it off instead of on, etc. So here is where you just need to guess and test. The middle one is the one that fires off when you get hit and it turns on, so that's the correct one in this case and it's the one I'll be targeting. Looking at it...
So it seems to be comparing the invincibility value to 0, and if it's higher than 0 it jumps to some other code instead (JG = "Jump if Greater"). If you edit the jg to be jmp instead, then it will always jump to the other code, so when you contact a monster it'll always think you're invincible and won't damage you! So this is a secondary method of getting invulnerability, editing the check instead of the write.
Now... a different method for invincibility could be to find the code dealing with an "invulnerable" flag.
This will generally be a byte value (but it could be something different of course) and in most cases will be 1 or 0. It could either be "1 for invincible" or "1 for attackable", so check both ways. Get hit, pause the game (either normally or with speedhack) while invulnerable and scan, do a different scan when it wears off, etc. Depending on the game you may have to do an unknown initial value scan and scan for differences.
However in the case of Rogue Legacy, it seems that it only uses the invincibility timer. So instead of the game checking for an invincibility flag, the code checks to see if the timer has any time left in it in order to determine if you're invincible or not. Rogue Legacy isn't the only game that does this, so if the quick and easy invincibility flag search didn't work, you may need to do the above timer method.
3 - Check The Player Structure
This is one of the more traditional ways of using injection to get invincibility for just the player. However it also requires learning more about the game (specifically the entity structure for it) in order to use it effectively, so since it needs more research and work and custom assembly it's the third method listed.
The basic idea is to have the game do a check like "is this a player or an enemy?" by comparing values, and then either continue with the code to cause damage if it's an enemy, or skip over it if it's the player.
This method involves looking at the structure for entities in the game and comparing two instances (which will generally be the player versus an enemy) to find differences. To be able to look at and compare the structures, we should first find the base address of the player structure. To put it simply, for this example it's the player's health minus the health offset. So let's say my current health address in a certain run is 0368A400 and the offset (code that writes/accesses will show this) is +118. Doing some hex math returns 0368A2E8 as the base address for the player. Remember that putting the Windows calculator into scientific mode presents you with a hex selection box you can use to do hex math.
Now that we know the base address of the player, we should open the structure dissect window. In the
memory viewer (CTRL+B), go to Tools - Dissect data/structures. In the new window enter the base
address for the player's data into the box at the upper-left and choose Structure - Define New Structure.
Give it a name like Player (for .NET games like Rogue Legacy it offers to use the actual structure name) and if you're doing this on a different game you'll be asked for a size (the default works) and whether CE should try to auto-fill some of the data (yes). When that's all done you should see a bunch of stats or whatever for the structure you chose. Since this is a .NET game we have it easy and it's all mapped out for us already, but with most games it'll be unlabeled best-guess entries.
The next thing to do is to find the base address... of an enemy. So for this you should find the address
to their health and then subtract the offset (118 for this example) from it. For my run I got an enemy
with a health address of 226F5AD0, so that enemy structure's base address would be 226F59B8. Back in the structure window, go to File - Add extra address. A second text box should pop up next to the first one, put the enemy's base address in here. Then the display should show both data sets.
Green addresses are the same for both the player and enemy, red addresses are different. So using
this display, we can try to figure out which pieces of data (offsets) would be good for a comparison to
determine if the target is the player or an enemy. Again, in .NET games like Rogue Legacy we're
granted a big benefit in that the offsets are labeled and stuff. For other games you'll have to poke
around, see what other things in the structure you can find, and guess+test.
For this tutorial we'll just pretend we poked around a lot and found offset +104 (StepUp) and it seems
to always be the same value for the player (10) but different for enemies. Make sure to check what type of value it is, in this case it's 4byte, gotta' remember that. So now you'll want to go back to making a generic template script for the health code. Find the code that writes health when hit like usual, and when you tell CE to generate the template the code: section should look something like this.
What we want to do is add a check (comparison, cmp) to see if some values are as expected (if the target is the player), and if it's equal skip (je) past the original line of code and jump back to where it continues.
So the first line added is the comparison. Notice how it says "dword" after the cmp? This is to tell AA
how much memory to read and compare. It's very important to note the right size there, because if the
offset in the structure is 1 byte and you're reading 4, the comparison is bound to have false failures.
1 byte = "byte"
2 bytes = "word"
4 bytes = "dword"
8 bytes = "qword"
When it comes to float ("dword") or double ("qword") values, you can do exact comparisons (je or jne).
However doing greater/lesser comparisons may be a bit more complex and/or involve more code.
Also notice that even though I said the value of StepUp is 10 for the player, it checks against A. Remember that AA interprets things as hexadecimal values by default!
The second line is je (jump if equal) to the return location that CE sets up when the script executes.
Anyways, now that the script checks part of the structure against the known value for the player, the code should properly grant you immunity to damage while still letting monsters get damaged. So yay, done!
This guide just covers the basics with a simple example, and if you run into other situations it's expected that you know at least a little assembly since this type of thing usually needs a good understanding of what the game is doing and such.
by
Rydian
Grandmaster Cheater Supreme
==================================================================================
http://forum.cheatengine.org
it will be a big lost, if you gone!
I am so HAPPY that you back, Working FINE !
Great Site!
Thanks!
Forge By Games # ForgeByGames
No comments:
Post a Comment