Cheat Engine

[Geri]

Yes, I got the plugin from the author directly, not downloaded it from some random site, this is why you don't see it elsewhere. And because most programmers hate to write manuals or any documentation (it's their nightmare), I have volunteered to make one for it and upload it for a public place with instructions. This is how it ended up on my site.

[xeratal]

I was thinking of doing something like this in a much, much more primitive way because I was unable to bypass certain integrity checks, then I remembered seeing something like it here, and it worked! Thanks lots

[xeratal]

Hmm, I encountered a strange problem when using this. I'll go straight to the point.

...: jne x
...: <mov ...>
x : <new module which is copied is here>
..
..
..

The problem is that when I stealthedit x, the game crashes. I've even tried jmping straight from the copied x to the original x (i.e. there is no "extra" code deviating from the original other than the jmp) but it still crashes (at some memory location 07a90000 or something like that which isn't even assigned).

Notes:
1) I've used stealthedit in other parts of the game cheating and it worked fine.
2) Game is packed with Thermidia.
3) Stealthediting the previous module (the part before x) works but because of the Thermedia encryption/obfuscation, I can't figure a way to hack the game except directly stealthediting the "x" module.

Any ideas?

[scribly]

Check the page you are editing
Are there any instructions inside that section that jumpo to memory locations OUTSIDE of the module ?
If so, you have to edit the stealthedited region so that it jumps to the correct location

e.g:
The module is in the range of 00400000 to 008a0000
But in the code you have a "jmp 07a90000" somewhere you must 'repair' that instruction in the stealthedit copy because the relative destination will need to be changed (Just reassemble "jmp 07a90000" manually)


---
And keep in mind: Not ALL pages can be stealthedited. If there is a breakpoint on the code which when executed triggers a jump to another location then that page can not be stealthedited since the breakpoint will never trigger (or be in an invalid address)

[xeratal]

Hmm, what you said does make sense and I think it may be applicable to another part of the memory that I tried stealthediting before but would result in instant crashes of the game.

However, for the case I am saying, I think it is a different problem.
As I wrote at the start, I tried placing a jmp back to the original instruction once the exception was called.
So this is how the memory layout would be after editing:
---
ORIGINAL
...: jne x
...: <mov ...>
x : <new module>
..
..
..
---
EDITED
...: jne exception
...: <mov ...>
exception: jmp x
x: <original module>
..
..
..

This was as far as I got to tracing the problem. You can see that no other code is run (unless I am somehow mistaking the way this stealthedit plugin works) besides the jmp back to the original instruction - From my beginner's understanding of assembly, I really don't see how this could affect anything

P.S. the jmp back to the original module was the way I looked at the problem. It's just to show that nothing else is happening (my actual cheat is editing memory somewhere in the middle of the module, but I'm fairly certain fixing this problem would have the same effect on my cheat)

[scribly]

I am not really sure what you are doing or what you mean with "new module"

You are aware that "jne exception" most likely is bigger than the original 2 byte instruction and will overwrite the mov instruction?

[Geri]

Yes, I am a bit confused with your description too. Maybe it would help if you would post the code itself, just that few lines at least.

And the best solution would be to try debugging the code to see where is the error happening and what could be the cause.

[xeratal]

Sorry, I will be more specific this time.
Also, I was referring to "new modules" as that's the term put forth by the plugin - "stealthedit this page (whole module copy)" - but I believe a more precise term would be a "new page".

So after I stealthedit the page, this is what a few lines of code look like in memory...

IN BLACK (unedited code which is just before the new page)

[scribly]

Does it crash when you use stealthedit without making ANY modifications to the copy's memory ? (green mem)

You have to think about the jumps from other locations and instruction sizes. If EIP enters inside the middle of an instruction, random crashes can happen

Just to reiterate, assume the stealthedit registers a redirect from 0048c000 to 20400000: (That affects everything from 0048c000 to 0048cfff)
When 0484C004 gets executed, it jumps to 20400004 and executes that instead
And when 048c008 gets executed, it jumps to 20400008 and executes that instead
So basically, you could rewrite that jump to 0484C004 to "jmp 20400004" instead (in aa: jmp stealtheditregion+4)

[xeratal]

Yes, same problem without any modifications. The jmp was just to illustrate how it seemed like it was crashing without any visible modifications.

But I think I see where you are getting at now.
(Btw <allocated memory> was referring to the copied page, I didn't know how else to put it)

Suppose this is the original page
00xxxxx1 : ...
00xxxxx2 : ...
etc

My understanding of the stealthedit plugin was that it would basically make some kind of exception whenever 00xxxxx1 was called, but it seems I was mistaken and that anywhere from 00xxxxx1 to the end of that page would redirect the flow to the copied page.

That means I was entirely wrong in my approach of thinking that 1 single jmp could show me where the problem was and that only the start of the copied page mattered... sorry, I thought I knew what you were saying at first but I didn't. Darn. And the copied page is huge too

[Geri]

Yes, when you use stealthedit, the whole module will be copied (eg the whole exe file or dll) and the whole page will be re-directed to the copy. In the copy, the black parts before and after the green part are just there to make sure to have a 100% copy, but only the green part is executed. If you want to change a code that isn't marked with blue yet, you have to copy that page too and modify the copy.

As I mentioned in the tutorial, if you use stealthedit instruction, even if you put in just 6 bytes for example, the instruction will copy the whole page anyway.

The right method is to manually select the required codes and make a copy of them in the disassembler view (not in AA). If it is not crashing, fine, then stealthedit is not causing error. If it is crashing, well then you need to figure out why, it could be an exception that is in the original (blue) code which is not executed since you use the copy and it is causing a crash. If stealthedit is working, you can write your AA script to do whatever you want, but that is the last part only, when you are sure that not stealthedit itself is causing the problem.
Some protections may detect this plugin, it isn't 100% undetectable, but it is still quite an edge against most detections.

[xeratal]

Hmm, I've more or less given up on this particular hack since it seems impossible for me to do without an undetected way to debug the program, but I was just wondering if you could explain to me how one would normally fix these kinds of crashes (if possible without debugging)?

I did a quick scan, and there were a whole bunch of interrupts (int 3) throughout the page and I thought that was what was crashing the program (I still think it is even if I don't know exactly how), but also when I looked at other parts which I could stealthedit there were just as many interrupts, and I don't really know how they work so...

[Geri]

You have to solve the debugging problem. I am sure you will find some solution if you look around on the internet.

[Geri]

UPDATE: Added Stealthedit 2 download link and description to the article.

[Igor]

How to stop stealthedit. means if i select 'stealthedit this page' then it will blue then how do i stop this and restore orignal (black color)