This article will be about the latest release of Cheat Engine, CE 6.0
Some of this info is included in the help file already, but some things has been left out. CE 6 has many new interesting features for beginners and more advanced users alike. This article will cover only the most important changes so feel free to experiment and find new stuff. If You really want to know Cheat Engine better, don't forget to read the helpfile (I have spent enough time to try updating it so if You don't read it, it is Your loss).
I have dedicated countless hours to the testing of Cheat Engine 6 and I know that Dark Byte has worked hard on this new release to bring You the best and the most user friendly all around reverse-engineering/game hacking tool available today. I have requested many options from Him that I have missed from CE 5.6.1 and He was willing to take on the challenge and create them. I was very excited to see these new features in action and once You will see them too, You will feel like the good "old" CE 5.6.1 is obsolete already.
You can download Cheat Engine 6.0 from this page:
The forum is available here:
Feel free to send suggestions and bugreports to Dark Byte (
, forum, bugtracker, any other way ).
Code: Select all
If You wish to support Dark Byte with some money, consider sending a Donation via Paypal or at least install the recommended software which is offered when You install Cheat Engine (the installation is free so You have nothing to loose, these softwares are virus free and they have to follow strict guidelines to take part in the OpenCandy advertisement).
So here are some old but improved features, or completely new features:
In CE 5.6.1, You had the option to choose between the windows debugger and between the kernelmode debugger which has offered some stealth in games that are using protections against debuggers. In CE 6, a 3rd debugging method, VEHdebugger is introduced. VEHdebugger is invisible for most debugger protections and only the toughest protections may notice it. Even though sometimes it is still detected, it is not detected immediately, only after some time. It is fully compatible with 64-bit, so in most cases, VEHdebugger is Your best bet to remain undetected while You are debugging a program. Kernelmode debugging is still available as it offers even more stealth, but experienced users know that kernelmode debugger options should be used as a final solution instead of used by default, because it is harder to close the target process after debugging etc. VEHdebugger however does not have these side effects and can be set as a default debugger to avoid protections.
Find out what addresses this instruction accesses:
This option will set a breakpoint on the code and open a new window. You will see every address that is accessed by the code when the program is running.
The address field contains the address which is accessed by the code. The value field is containing the value of the address at the moment. You can choose the displayed value type from the dropdown menu. The count number shows how many times did the code access to that address. It is good to know how often is the address accessed by a code and monitor it in real-time.
Right-clicking on an address will offer some new options.
Show register states: This will show the value of the registers that were logged when the address has been accessed by the code the first time. In the register window, you can click on F to see the FPU registers and S to see a snapshot from the stack. The Stack View is extremely useful when You are searching for values in the stack.
Browse this memory region will open the memory view at the address and Show as hexadecimal will display the value in hexadecimal.
You can stop the debugger with the Stop button.
Find out what accesses this address:
This option will set a breakpoint on the address and open a new window. You will see every instructions that are accessing to the address while the program is running.
You can see a counter to display how many times has the instruction accessed to the address and you can see the instruction. This is very useful because You can see if a code is used in certain events only and You can also see how frequently it is used. For example You can see that a code is constantly reading Your health 100 times per second if a health bar is visible, but maybe not reading the health when the health bar is not visible. Or You can see that some code is accessing to Your money to display it on certain screens in a game. This way it is much easier to create player-sided cheats and write much better scripts. It also helps to see how the codes are used in real-time and get an idea which codes should be used and which codes not for Your scripts.
The following options are available for the selected instruction.
Replace: Replace the code with NOPs and also add it to the code list.
Show disassembler: Open the disassembler and jump to the code.
Add to the code list: Add the selected addresses to the code list.
More information: Show the code along with the register values that were logged after the code has accessed to the address. You can open the FPU window with F and the Stack View with S.
You can stop the debugger with the Stop button.
In this video, You can see the counter and why is it useful. I check what writes to the address in the tutorial and You can see that every time when You click on Hit me, a code is changing Your health. When You choose what is accessing to the value, You can see that a code is running a few times per second, checking the current value and You can also see that other codes are running only when You click on the Hit me button and Your health is decreasing. This is a very useful info when You are hacking games and You are trying to figure out the purpose of each codes.
While You could use the find out what... features in CE 5.6.1 too, it did not have the option to use manual data breakpoints. Now if You right-click on a value in the memory browser, You can set a data breakpoint to start manual debugging when the address is accessed or written and You can also start a trace to see what happens after the code was accessed/written.
In this video, I show You how to set a data breakpoint, how to remove it and You can also see the trace option. I set a breakpoint on a value and break the process when it is written, then again when it is accessed and finally start a trace if the value is written by a code.
This simple option will analyze the code of the target process and place useful information in the disassembler view. When you see a code, it will be displayed if the code is a destination for call or jump instructions. Of course it will also display the source of the call or jump.
This option is a fine tool to examine or compare data in similar memory regions or structures. It can be used if you wish to compare your charachter's structure with the enemy's structure in an FPS or strategy game, but of course it can be used for other purposes too.
File->New window: This option will open a new dissect window.
File->Import: Import a structure.
File->Export: Export a structure.
File->Save values: Save the content of the window in a file.
File->Add extra address: Add a slot for an extra address for comparing.
View->Change colors: Customize the colors of this tool.
View->Update interval: Customize the value update interval.
Structures: Create a new structure with Define new structure, then give a name and a size for the structure. If you have more than one structure, you can choose the one that you need from here.
Commands: Rename and Delete structure will rename and delete the currently used structure.
Automatically guess offset types will allow CE to guess the type of values in the structure.
If you have added one or more addresses to the window, you can right-click on an address and sort them into groups. This is very useful because you can compare the values in every structure and also see if the values are the same in the same group, or they are different inside the group too (e.g. you can add 2 enemy unit and 2 friendly unit in an RTS game and place the enemies in a different group, thus you will see what is common between friendly units and what is common between enemy units)
If you right-click on an entry in the window, some additional options will be available, such as Memory browse this address, Memory browse this pointer and Add to address list.
You can open the pointer scanner with Memory View->Tools->Pointer scan, or by right-clicking on an address in the address list and choose "Pointer scan for this address".
If you use the first method, you can use File->Open to open a saved pointer list or you can use the Pointer scanner->Scan for pointer option.
If you start a pointer scan, a new window will appear where you can customize the parameters of the scan.
At the top of the window, you can choose to find pointer for an address or for a value. Searching for an address is much faster, so this is the default method.
Below that, you can set the parameters of the scan. Usually you don't need to change the upper part at all, especially if you have no idea what it does.
At the bottom part of the window, there are other options that you may need to change sometimes. The number of scanning threads is adjusted to Your CPU. The number of threads shouldn't be higher than the number of cores in Your CPU. The maximum offset value should be changed only if you suspect that any of the offsets will be larger than 2048 bytes (e.g. an offset like eax+1F48 or similar, which is not so common for most of the values that cheaters are looking for). The max level of the pointer path is 5 by default, but some programs are using even longer pointer paths, so if you didn't find what you were looking for, probably you need to increase the max level.
If you have typed in the address, checked the options and clicked on ok, you will have to choose a name for the pointer list that will be created. Then wait for the scan to finish the job.
If the scanning is done, you will get a huge list of possible pointer paths, but not all of them will work for you if the address will be changed. For now, you have a saved pointer list which can be opened later from the File menu in the Pointer scan window.
Now make sure to change the address of the value, which usually means die in the game, restart your level or restart your game.
Find the value again by scanning for it and you will have the new address.
If your pointer scan window was closed, open the saved pointerlist. Now probably you have noticed that many of the found pointers are pointing to wrong addresses, which means we have to remove the wrong ones.
Now you can use the Pointer scanner->Rescan memory option.
Type in the new address, choose a name for the new pointerlist and CE will filter out the pointers that are pointing to the wrong address.
Now you should have much less pointers in the list but at least they are correct.
It may happen that some of the pointers will fail to work from time to time, in this case, you need to filter them again, until you find reliable pointers which are working for you in every case. Keep rescanning the pointers until you have found one that is perfect for you.
If you wish to add a pointer to the address list, all you need to do is double-click on it in the pointer list and it will be added to your table as a new pointer.
Break and trace:
If you have used the Break and trace option in CE 5.x, you will notice that this option has been improved to be a much more advanced feature in CE 6. First you are able to use break and trace with data breakpoints too. Furthermore, you can set breaking condition and stopping condition for the trace and you also have the option to log the stack to a certain level (4096 bytes are used to make the stack snapshots).
If you see a trace log, you will notice additional, very important changes.
The trace log is displayed as a tree, so you can see calls and returns easily. This way the log is also a structured map of the traced code, which is undoubtedly a huge improvement compared to the previous logs. It will not only help you to navigate, but you can also see where is your code in the tree and how "deep" is the function where it is used. As ret is usually returning after the call that was used to call the function, checking the return points of a trace can reveal the address of the call too. When You are backtracing some process, this will make Your life much easier. Advanced users will probably appreciate this. Right-clicking in the log will offer the collapse and expand tree options.
There are a few additional options like saving the log and searching in the log (which was not possible in earlier versions). Also an improvement that the values on the addresses in the codes are shown.
Clicking on the F button will bring up the FPU register window, and the S button will show the Stack View window. If You right-click in the stack view, you can change the offset display between ebp+* and esp+* which is very useful when you are tracing values in the stack.
This video will show You the new break and trace feature of CE 6. I use the feature on the code which is decreasing Your health in the CE tutorial. You can see how to start the trace, change the condition of the breakpoint if it is neccessary and introduce the trace window. As You can see, if the code is running, CE will trace the instructions and display them in a tree. A function is called at address 00420F4D. This is a very small function only and after a few codes, You can see a ret, which will return to the next instruction after the call. With this example You can see that if You know where is the code returning to, You can also check out where was it called. This is very useful when You are trying to figure out where were certain functions called from as all You need to do is check the return point. Although You can see the returning addresses in the stack, checking out the tree view in the trace will save You from much trouble. At the end, You can also see the Stack View which is (again) extremely useful when You are looking for values in the stack.
A small tutorial for effectively using the new percentage scan and compare to saved scan method:
CE 5.6.1 had the option to search for a % of a value, but it wasn't really useful. Now in CE 6, it has been improved a lot and I will show You now how can You replace the good old decreased/increased changed/unchanged searching methods with a much more sophisticated scanning technique.
Open the CE tutorial and proceed to Step 2.
Open CE and attach it to the tutorial.
Now You have 100 health. We will find this value by using the percentage scan in CE.
Start an unknown initial value scan.
Now click on the hit me button and you loose some health. I have 96 health now.
Click on the Scan type dropdown menu and choose the last option, "Compare to first scan". This means that in the next searches, the values will not be compared to the last search result, but always to the first scan result, which is in our case 100 for our value.
The next step is to choose "Value between..." search and click on the between % checkbox. What will this option do exactly? It will check all values which are x-y% of the value that we use for comparing. At the moment, this means it will scan for values which are x-y% of the first scan result.
Why is this good for us?
We have made the first scan when our value was 100. This value is the 100%. Our value at the moment is 96. It isn't hard to calculate that our value is the 96% of the first scan result.
To find our value, we type in 95 and 97 in the fields so CE will find all values that are 95-97% of the first scan result. Hit next scan and You can see that we have only a few results. Probably You can see that the value is in the list, but just for fun, repeat the process again. Click on "Hit me" a few times.
Now I have 78 health. I need to find the value. 78 is obviously 78% of the first scan result which was 100. So I make a scan with "Value between...", between% and I type in 77 and 79.
Awesome I have found my value already. This example was easy because we have seen the value and we knew that it is not multiplied with any number. You may think this was a stupid example. But wait a minute. What happens if the value is stored in some tricky way, like when it is multiplied with 8 for flash games? Well of course since we have searched for x-y% of the value, it doesn't matter if the values are multiplied, you will find them easily using this method.
With a flash game, it would have worked this way (not in all flash games, but in some of them).
You have 100 health and it is stored like 800 in the memory.
You do a first scan.
Then your health is decreasing to 96 (which is in fact 768 in the memory).
You search for 96% (95-97%).
Then you loose some health again and you see you have 78 health (which is in fact 624 in the memory).
You search for 78% (77-79%) and bingo. You have found your value. Did you know it is multiplied? No. Did you find it just by searching for x percentage of the first scan result which was 100%? Yes, you have found it easily and it would have worked even if the value is multiplied with 200, 1000 or even 4748 in the memory.
I hope you realize that this feature is VERY useful when you don't know if a value is multiplied or not and you have no idea what is the multiplier value. In many cases, this will help to find timers and other tricky values which are usually multiplied.
Here is a video with an example:
And now, we will check what happens if we don't see the exact value that we are looking for.
Proceed to Step 3 in the Tutorial.
You can see a health bar only, but you don't know the exact number. What you see however, is that the health bar is full. This means that the health bar is filled to 100% at the moment.
Now start an unknown initial value search.
Click on Hit me a few times and You loose some health.
Now choose Compare to first scan again, then choose "Value between..." and between %.
Look at your health bar. You have lost some health, try to guess how much % health do you have from the full bar. My bar is filled to about 85-95% so I have about 85-95% of the full health.
Ok, I search for 85-95%.
Click on Hit me again a few times to loose health.
Now my health bar is somewhere between 60 and 80%.
I search for 60-80%.
I have found my value already, but if you don't have it yet, continue searching until you find it.
Why is this useful when you could just simply use increased/decreased search? If you have ever tried to find a graphically displayed timer or a progress bar in some game, where you did not have the option to stop the value and all you could do is to keep searching for decreased value all the time, then think about how easy would have been to just search for the progress bar this way.
Here is a video about this part of the tutorial too:
As a final word, I need to mention that a decreasing health bar or progress bar doesn't mean that the value is decreasing. It may happen that it is constantly increasing until it will reach a certain value. But even in this case, you can still use the % scan, just be a bit clever. Utilize this feature when you are stuck with increased/decreased changed/unchanged value searches, because this will save you many times.
Probably this feature is one of the most useful options in CE 6 for beginners and advanced users alike.