Recreating Geri's tutorials and articles before his site got wiped out. Wealth of information in it!
-----
This will be just a very short tutorial because this thing is very easy if You have read my previous tutorials already. Before You start reading, I will tell You that this tutorial will not help You to bypass online anti-cheat protections and stuff like that, it will only help You cheating in some offline single player games.

Sometimes it happens that a game is using dirty techniques to check that the game codes are unchanged. This means if You use code injection, You will get caught by the program's security check and the game will most likely crash. More and more games are using these techniques to defend their codes, including all games which are using the Games for Windows Live feature. This short tutorial will show You how can You deal with checks like this in minutes. It isn't hard if You know how to use a debugger and how are functions working but if You don't know yet, I recommend to read one of my previous tutorials, Basic encryptions, debugging, backtracing and some info on the stack .

Ok let's get started. I will use BlazBlue: Calamity Trigger as a target process and Cheat Engine 6.0 ( http://www.cheatengine.org/ ) to cheat in the game. This game is not complicated, You can easily run it in a window, anyone with very limited experience should be able to make a cheat for it, but if You use code injection, the game will crash. It is using the Games for Windows Live (GFWL) feature, that means it is using a dll, called xlive.dll as any other GFWL game. You can try to follow me with any GFWL game, the videos will hopefully help You to understand what am I doing, even if You don't have this one.

Some preparations

I have made only one cheat for BlazBlue, unlimited health. The health is a simple integer, easy to find. What You need to know about Xlive is that it doesn't only protect the game against code injection but also has some tricks to detect debuggers. Fortunately CE 6 has very nice debugger options which will help us greatly to remain undetected.

1. If You are using a 32-bit operating system, open the CE settings, choose Debugger options and select the "Use kernelmode debugger option". Also click on the checkbox for "Use Global Debug routines". This will make the debugger totally undetected for xlive and You have solved the issue.

2. If You are using a 64-bit operating system, use the VEHdebugger. It is not as undetected as the "kernelmode debugger" and it will happen sometimes that Your game will crash, but nothing terrible. Just restart the game if You have crashed and that's it.

If You have found the health, find out what is accessing to it and You will find a code which is accessing to both player's health. This code for me is

00488410 - 8B 81 48080000 - mov eax,[ecx+00000848]

I tell You that [ecx+28] is the player ID for the charachters so if [ecx+28]=0, then the player is Player1. If [ecx+28]=1, the health is for Player2. Now You could easily make Your cheat for the game, just check that [ecx+28] is 0 and change the health. Awesome we have made the cheat but if You try it out, the game will crash max in a few minutes when the security check discovers Your tempering with the code.

There is one more step that I highly recommend to do in every case when You will analyze codes. Open the memory view, select the Tools option and use the Dissect code option to let CE analyze the code. Usually You would use this option on the game itself but You will see that our enemy is hiding in the xlive.dll, not in the exe, so this time click on "Include system modules", select xlive.dll from the list and wait until the analyzis is complete. If it is done, just close the window.

Here is a video on what have I done so far. These are important preparations so don't miss any step or You will fail in later steps.

Finding the evil eye

Now we have to figure out how is xlive checking the codes. It is reading the memory where the game codes can be found, then it is creating a hash from the gathered data and if the hash is not matching with the original hash, then it will take the neccessary steps to spoil our fun. What is important for us, that it is reading the codes to search for any changes in the code. To find the code which is reading the memory, all You have to do is find out what is accessing to the address where our code is stored. Our code is:

00488410 - 8B 81 48080000 - mov eax,[ecx+00000848]

Now all we have to do is set a data breakpoint on 00488410 to see what is accessing to it. We have done this a thousand times with values like health etc, the only difference is that now we are checking the address of the game code to see what is accessing to it. If everything is set, play the game and sooner or later, a code will pop up. It wasn't difficult I guess, now we have the code which is reading the memory, add it to our code list and save our progress. You can see that this code is in the xlive.dll, I told You already that the enemy is hiding in this sector. The code for me is this:

012EAF84 - 8B 0A - mov ecx,[edx]

On the video, I have just named it "This code is reading the memory and check the codes". So here is the video for this second part.

Time to fight back

Ok we have the location of the enemy, now it is time to strike. You have probably realized by now that the evil eye is not always active so there is obviously some point where the program decide to start the check or not. Be on a lookout for conditional jumps that may jump over our function. What I am looking for is something like this:

conditional jump over the next function
a function to read the memory
other stuff

Now let's set a breakpoint on the code which is reading the memory and play. As soon as You see that the xlive.dll has stopped, You can remove the breakpoint and hit F9 to enable the program to run. What we have needed is the list of return points that popped up in the lower right corner of CE when xlive has stopped. If You have not done it so far, it is time to run the Dissect code feature which was suggested in the first step. Ok now we start backtracing as we have done already in the previous tutorial where I have explained backtracing and functions.

As You can see, CE has dissected our code and showing the destination of calls and jumps. This is very useful. If You keep scrolling up from the code, You will not find what we are looking for but You will reach a code which seems to be some destination for some calls. We have reached the start of the function where the evil eye code is located (in my case, the start of the function is on 012EAF1C). Ok now we go back one step and check out the function which called our function. If You click on the top address in the return point list, You will get there. We are at the place where our function is called. Any sign of some conditional jump? Yes there is one but I don't like the look of it because it is very long so I go higher. Reached the start of the function again, let's see where did it come from. Click on the 2nd address in the return address list. Now this is more interesting, lots of jumps and everything. Just for curiousity, let us check where did this function came from so click on the 3rd address in the return address list. Wow this looks like something I wanted to see so badly. A short conditional jump right over the function. Make sure to save that call and that conditional jump in the code list and save Your table. Now all You have to do is change that je instruction to jmp so it will always jump over the function and xlive will not read the memory. Just enable Your cheat and play as long as You want.

Here is a video for the 3rd part:

Hopefully this tutorial will help a bit if You run into security checks in other games, but if not, You can still use pointers or just simply edit some values with CE. There are tons of other ways to deal with this problem, the main point of this tutorial to see the big picture and learn how to find the codes which are spying on the memory.

Peace!
Geri

For those who are lazy to do this on their own, here are 2 scripts that will do the same job that I have done:

#2 pet29 2011-10-28 15:11
i dont understand why this
game dev and alike act very stupid
no matter how hard they try some
one is going to find some solution
for that kind of problem, in this case
Xlive.dll. Anyway i love all your tuts
and this one is one of the best tuts i
have seen, thank you, it really helped
me a lot. keep the tuts coming:) love it

have a nice day
Idézet

#3 Geri 2011-10-28 19:58
I don't know why are they adding anti-cheat protections to single player games. I have enjoyed all games with cheat codes. No stress just fun. No idea why is it bothering developers if I don't want to finish their games without cheats.
Idézet

#4 dharmang1910 2012-08-22 10:41
Hi geri,
can you please update the script according to new xlive.dll version which is 3.1.99.0?
i've tried all 3 options of your script but my game is crashed....
i've tried this script on mortal kombat arcade kollection please help me ...!!!
Idézet

#5 Geri 2012-08-22 14:42
If you use a cracked game, sometimes the anti-cheat is ripped, so the script will not find it for obvious reasons. I didn't play too many new games recently, so I don't know how or what was changed if something has been changed at all.
Are you using original or cracked version for this game?
Idézet

#6 dharmang1910 2012-09-16 04:38
Hi Geri,
that was ripped mortal kombat arcade collection so may be it possible as you described..but currently i've played dirt 2, in which the exe remain same in original & cracked version but it has newer xlive and crashed in initiation of game if cheatengine is running, so you haven't enough time to run script even to choose process..i've unistalled newer version of xlive & installed old one but game doesn't run & asking for newer one... so you have any idea how to deal with it..??
Idézet

#7 Geri 2012-09-16 07:57
The protection against CE in the Dirt series has nothing to do with Xlive. Xlive is detecting code injection, but Dirt is detecting Cheat Engine itself. If it will detect any running application that has "cheat" in it's name, the game will close. Eg if you open the Cheat Engine website while playing, it will detect the "cheat" word in your browser's header and close the game.

The solution is kinda easy for that. Open the Cheat Engine exe file with a hex editor and replace all "cheat" words with something else. Don't forget to also rename the exe file. Eg when I hacked Dirt 3, I just replaced every "cheat" word with the most random word that came to my mind, which was "brick". So I fired up my Brick Engine and from that point, Dirt didn't detect anything at all.
This protection is not related to Xlive at all. This is the game's own protection, put in by the game developers.
Idézet

#9 Geri 2014-02-15 19:16
Some cracked games don't even have this Xlive protection, because crackers remove it.

When I have made cheats for Dirt 3, I have used these scripts for Xlive and they have worked.
Idézet

#10 Rud 2014-02-16 04:39
Thank you very much. I use license game. But i try on crack game too. Maybe it couse i use Dirt 3 V 1.2, Geri what version of dirt 3 you used when create cheat? I think maybe these patches transport this bytes to another place. I use your trainer for game Dirt 3, very nice, but when i try to make myself in (exe) format, it dont run. I replace all word "cheat" in (exe) file of cheat engine and rename (exe) file. But if i make trainer in standart cheat engine it will be run, but game clouse, how you found the solution. Thanks.