Search
 
 

Display results as :
 


Rechercher Advanced Search

Latest topics
» ~=?{The future is here, TastyExploit officially open to the public}?=~
Tue Mar 02, 2010 11:00 pm by Dami

» My first aa script
Tue Mar 02, 2010 7:00 am by wafflemaster

» the real story behind Maverin
Tue Mar 02, 2010 1:33 am by SoundOfDeat

» Random spam
Mon Mar 01, 2010 11:52 pm by Danny1994

» [Request] EMS v56 Exe
Mon Mar 01, 2010 12:39 am by Dami

» [Blacklist] NX-Trading Blacklist.
Mon Mar 01, 2010 12:38 am by Danny1994

» I have a question regarding the meso farmer
Sat Feb 27, 2010 10:30 pm by Dami

» What are you listening to now?
Sat Feb 27, 2010 7:57 pm by Noname111111

» Video(s) Of The Day
Sat Feb 27, 2010 7:37 pm by Noname111111

Navigation
 Portal
 Index
 Memberlist
 Profile
 FAQ
 Search
Affiliates
free forum
 



An In-Depth Tutorial on Auto Assembler: Extended

Go down

An In-Depth Tutorial on Auto Assembler: Extended

Post by Dami on Mon Jan 25, 2010 5:03 am

samuri25404 wrote:An In-Depth Tutorial on Auto Assembler: Extended

INDEX:

i) Intro

1) Taking a closer look at code-caves

2) LoadBinary()

3) A deeper look at flags

4) A deeper look at registers

5) Abusing the Call instruction to modify EIP

6) Define Byte/Word/DWORD

7) Using negative values in assembly

Cool The Stack

9) Using Cheat Engine to debug assembly

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section i: Intro

Well, my purpose for writing this it that there are many tutorials on basic assembler/hacking/whatever, but there's nothing that explains the more advanced stuff. A lot of this stuff that is covered in this tutorial is stuff that I've had to do research on, and it wasn't easy to figure out. A lot of people don't know quite how to research some of this stuff (or really know that it exists/never really thought about it), so I'm compiling it.

Note: This is a more advanced/extended version of my previous tutorial. If you haven't read that one, then I highly suggest you read it here, before continuing. Yeah, some of this will be review, but get over it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 1: Taking a closer look at code-caves

First, let's start off with a definition--what is a codecave?

A codecave is a segment of code placed in a region of unused memory, executed from a statement within the used memory. That's a bit of a mouthful, so let's use an example.

Say we have this game to hack (isn't that so rare? =P), and a line of instruction, let's say modifies our health. Let's say that instruction is

Code:

sub [esp+50],ecx

What if we want to modify that code to do a couple other weird things. Maybe we've got a variable stored somewhere in the program that we want to set the health to? We use a codecave.

Let's start off by deciding what we want our codecave to do. Let's say that we want it to take the value of 0xDEADBEEF and put that into the health.

Code:

push eax //save the value of eax, so we don't screw anything up
mov eax,[DEADBEEF] //move the value of deadbeef into eax
mov [esp+50],eax //move eax (the value of deadbeef) into our health value
pop eax //restore eax, so nothing gets screwed over

Now we set that up. Let's say that the address of the subtraction instruction was at address 00123456. Our codecave script might look something like this:

Code:

alloc(our_codecave,1024) //one kilobyte is enough space, it's overdoing it, but oh well
label(return)

00123456: //the address of our subtracting instruction, as I mentioned earlier
jmp our_codecave //our segment of code to be executed
return: //I'll explain this later

our_codecave: //let's define it
push eax
mov eax,[DEADBEEF]
mov [esp+50],eax
pop eax //Look familiar?
jmp return //I'll also explain this later

(Just note, that this would not be right, because the sub instruction is only 4 bytes long, but a jmp is 5--check out my other tutorial for information on that.)

Now, I stated that I would explain the return stuff. What that does is helps Cheat Engine to know where to bring your code back. It would be a huge pain to go and calculate where exactly everything would be. Cheat Engine gives this handy little function so that you don't. We label return at "return:", so Cheat Engine marks that specific address in its collection of information, so that when we say "jmp return", it substitutes the address into "return". An example?

Where we label return, it would be 0012345B (00123456 + 5), so Cheat Engine takes this, and goes to the "jmp return", and instead makes it "jmp 0012345b".

And there you have it, a (mostly) working script demonstrating a codecave.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 2: LoadBinary()

What is LoadBinary? To understand that, one would have to look at the code of Cheat Engine:

Code:

1229            begin
1230              binaryfile:=tmemorystream.Create;
1231              try
1232                binaryfile.LoadFromFile(loadbinary[i].filename);
1233                ok2:=writeprocessmemory(processhandle,pointer(testdword),binaryfile.Memory,binaryfile.Size,bw);
1234              finally
1235                binaryfile.free;
1236              end;
1237            end;

(taken from here)

So basically, this is just taking a file with a bunch of bytes (assembly instructions) and sticking them into the process, at the specified address.

Where is this used?

LoadBinary can be used to trick the game into thinking that it is not having its memory modified. For example, the maplestory CRC script from a while back consisted of loading the original bytes of MapleStory into a section of memory (LoadBinary), then when the game checked the memory, it used a codecave (see previous section) to make the game think that nothing was wrong.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 3: A deeper look at flags

First, let's run through a quick use of all of the general flags.

The Carry Flag:

This flag is set (value = 1) when an unsigned overflow occurs. What is that? An unsigned overflow would be something along the lines of 255+5, or 200 + 60 (They both go over the value 255, which is the maximum value of a byte). The flag is cleared (value = 0) when there is no overflow.

The Zero Flag:

This flag is set when the result of an operation is zero (I'll talk about the use of this in compare operations (cmp) later). It is cleared when the result is non-zero.

The Sign Flag:

This flag is set when the result of an operation is negative (1-2). The flag is cleared when a result is positive.

The Overflow Flag:

This flag is similar to the carry flag, except that it is set when a signed overflow occurs (value exceeds -128 or 127).

The Parity Flag:

This one is a little confusing (or at least, it was for me). What you have to remember though, is binary. This flag is set when the resulting bit count is even. For example, if you had the result "4", its binary equivalent would be 100. How many bits does it have? 3 = even, so Parity Flag is cleared. However, if you had 50 as your result (110010), the Parity Flag would be set.

The Adjust Flag:

This flag is set when an overflow occurs in the bottom 4 bits of a result (when doing things with stuff such as BCD).

~~~~~

Now, I'm sure you all are familiar with something along the lines of "TICK ZF!!!"

Ok, so you can use CE to set the zero flag, but what if you want to do it in a script?

Here's a little ghetto way of doing it, by messing with the way ZF works:

Code:

push eax
mov eax,3
cmp eax,3
pop eax

Yeah, it's four lines long, but do you have a better way?

Now, what about the other flags, you ask?

You should be able to figure out how to set others, just remember to reset the registers when you're done (push/pop). Wink

~~~~~~~~~~~~

I mentioned that I would explain how Zero Flag affects the compare instructions, and I suppose I'll do that now.

Now, first of all, you should know how the compare instruction works. This instruction acts like a SUB instruction. For example, if you were comparing 2 and 3

Code:

cmp 2,3

(note that you can't actually do this, but in theory...)

PF, AF, and SF would be set. Let's look at that in depth (going back to our definitions here)

[PF] This doesn't seem like it matters much--but sure, whatever. We've got an even number of bits.

[AF] Overflow, eh?

[SF] Ahh, so the result is negative? Wait, 2-3 = -1, which happens to be a negative value, right?

(I'm using Cheat Engine to debug this, I discuss this later on).

Let's check out another one.

Code:

cmp 4,3

(once again, this cannot actually happen, we're discussing theory)

[PF] One bit, meh, sure.

Let's think about that, though: 4-3 = 1, right? 1 in binary is simply "1", right? Coincidence anyone? =P

~~~~~~~~~~~~

If you think about this, you can really screw up some games. Let's say that the game has a compare to check if you're dead:

Code:

cmp [playeraddress],0

If you take that and make a codecave:

Code:

cmp [playeraddress],0
push eax
mov eax,2
cmp eax,1
pop eax
jmp whatever

You've now cleared the zero flag. Why does that matter?

Let's say that your health is actually 0:

Code:

cmp 0,0

0 - 0 = 0, right? That would set the Zero Flag, telling the game that you're dead. However, if you clear the Zero Flag, the game has no way to tell whether you're dead or not.

~~~~~~~

If you want to learn more about which instructions affect which flags, look at Appendix A, of Volume 1 of the Intel Reference Manuals in my credits.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 4: A deeper look at registers

First, let's go ahead and define the 32 bit registers (the ones most commonly used):

Volume 1 of Intel Reference Manuals wrote:
EAX---Accumulator for operands and results data.

EBX---Pointer to data in the DS segment.

ECX---Counter for string and loop operations.

EDX---I/O pointer.

ESI---Pointer to data in the segment pointed to by the DS register; source pointer for string operations.

EDI---Pointer to data (or destination) in the segment pointed to by the ES register; destination pointer for string operations.

ESP---Stack pointer (in the SS segment).

EBP---Pointer in the data on the stack (in the SS segment).

That should explain that. Why isn't EIP included? I'm going to explain that later.

Now, all of the 8 registers explained above have registers which contain the low 16 bits. To get this, all you would do is remove the "E" from the name. For example, to access the low 16 bits of the EBP register, you would just use "BP"; for the low bits of EDX, you would simply use "DX".

~~~~~~~~~~~

SPECIAL REGISTERS:

There are two special registers, and neither can be modified directly.

What are these two registers? The EIP register (as I mentioned above), and the EFLAGS register.

Let's start off with a definition of each from the manual:

Volume 1 wrote:

EFLAGS Register

The 32-bit EFLAGS register contains a group of status flags, a control flag, and a group of system flags...

...

INSTRUCTION POINTER

The instruction poitner (EIP) register contains the offset in the current code segment for the next instruction to be executed.

Let's elaborate:

First, the EFLAGS register:

This register (as all 32-bit registers) contains 32 bits. What does this mean exactly?

01101010101001010101010100101010

That is 32 bits, or binary digits. Remember that a binary digit can be either one (1) or zero (0).

Most of these bits on the EFLAGS register represent a certain flag. Here's a table representing them.

Code:

 ---------------------------------------------
|    BIT  |        DESCRIPTION      | TYPE  |
|  NUMBER  |                          |      |
|----------|--------------------------|-------|
|    0    |        CARRY FLAG        |  ST  |
|    1    |        RESERVED        |  RE  |
|    2    |        PARITY FLAG      |  ST  |
|    3    |        RESERVED        |  RE  |
|    4    |      AUXILIARY FLAG    |  ST  |
|    5    |        RESERVED        |  RE  |
|    6    |        ZERO FLAG        |  ST  |
|    7    |        SIGN FLAG        |  ST  |
|    8    |        TRAP FLAG        |  ST  |
|    9    |      INTERUPT FLAG      |  SY  |
|  10    |      DIRECTION FLAG    |  CO  |
|  11    |      OVERFLOW FLAG      |  ST  |
|  12    |    I/O PRIVILEGE LEVEL  |  SY  |
|  13    |        NESTED TASK      |  SY  |
|  14    |        RESERVED        |  RE  |
|  15    |        RESUME FLAG      |  SY  |
|  16    |    VIRTUAL-8086 MODE    |  SY  |
|  17    |      ALIGNMENT CHECK    |  SY  |
|  18    |  VIRTUAL INTERUPT FLAG  |  SY  |
|  19    | VIRTUAL INTERUPT PENDING |  SY  |
|  20    |        RESERVED        |  RE  |
|  21    |        RESERVED        |  RE  |
|  22    |        RESERVED        |  RE  |
|  23    |        RESERVED        |  RE  |
|  24    |        RESERVED        |  RE  |
|  25    |        RESERVED        |  RE  |
|  26    |        RESERVED        |  RE  |
|  27    |        RESERVED        |  RE  |
|  28    |        RESERVED        |  RE  |
|  29    |        RESERVED        |  RE  |
|  30    |        RESERVED        |  RE  |
|  31    |        RESERVED        |  RE  |
 ---------------------------------------------

KEY:

ST - Status Flag
RE - Reserved - DO NOT USE
CO - Control Flag
SY - System Flag

You can use this information for when, for example, you want to flip a flag in a script.

If you wanted to flip a flag, you could create a codecave with the following code:

Code:

codecave:
//original instruction here, so you don't mess things up

push eax //save eax, so we don't screw it up

pushf //push EFLAGS onto the stack

pop eax //pop EFALGS off the stack, into eax

//eax now contains the EFLAGS register

or eax,00100000 //set the 6th bit of eax
//6th bit of EAX
//remember, ZF is 6

push eax
popf

nop //just to help check, for debugging purposes (I'll discuss this later)

popf
pop eax

jmp return //go back to wherever you left

Yeah, you could do it the little easy way of screwing with the cmp instruction and what-not, but it's always handy to know more than one method. =P

Plus, this makes you seem smarter. Wink

~~~~~~~~~~~~~~

Now, let's elaborate on the EIP register. First off, THE EIP REGISTER CANNOT BE MODIFIED DIRECTLY. (Read the next section to find out how to mess with it). Let's go back to that definition again:

Volume 1 wrote:
INSTRUCTION POINTER

The instruction poitner (EIP) register contains the offset in the current code segment for the next instruction to be executed.

Little confusing, right?

Basically, the program is divided into different code segments. The EIP register takes the base address of your current code segment, then subtracts it from the next address to be executed. This lets the processor know where to go next.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 5: Abusing the Call instruction to modify EIP

First of all, you have to remember that EIP can't be modified directly.



Now, if you think about this, you could actually do something along the lines of

Code:

label(lolJump)

codecave:
push eax //save eax

call lolJump

lolJump:
pop eax //pop EIP into eax

mov [eax-6],90909090 //eax = &"pop eax" (& = C++ for "address of")
mov [eax-1],90

pop eax

jmp return

And that would execute a db 90 90 90 90 on codecave+1 (the starting of the call statement). With this, you can actually write self modifying code! (Note: This was partially explained in the Volume 1, but someone actually wrote a tutorial on it, and I can't seem to find it, or who it's by. If someone could notify me of who it was, so I could give appropriate credits, I would greatly appreciate it.).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 6: Define Byte/Word/Dword

First off, just so we can clear things up, here's a small table giving you the opcode mnemonics of the three things:

Code:

define byte    db
define word    dw
define dword    dd

These are really simple to understand; all they're really doing are modifying the bytes of the current address. For example, db 90 changes that address to a "nop" command, because "90" is the byte for a nop.

You could also do

Code:

db 83 7d 0c 00

which would be translated into

Code:

cmp dword ptr [ebp+0c],00

Now, note how db has a space between each 2 digits (each byte), watch this

Code:

dw 837d 0c00

Same thing, but different opcode, and note how dw has a space between each 4 digits (each word). And finally:

Code:

dd 837d0c00

Same thing, once again.

You can use these to help shorten your scripts (though it's reccomended to include comments in your script to help people understand what you're doing, because

Code:

cmp dword ptr [ebp+0c],00

is much more understandable than

Code:

dd 837d0c00
)

Here's an example...

Say you want to change the opcode at 0xDEADBEEF to

Code:

xor eax,eax

rather than

Code:

xor eax,ebx

You might make a script:

Code:

[ENABLE]

DEADBEEF:
xor eax,eax

[DISABLE]

DEADBEEF:
xor eax,ebx

or... you could do the following (which also might help for AOB searching, I suppose)

Code:

[ENABLE]

DEADBEEF:
db 31 c0
//xor eax,eax

[DISABLE]

DEADBEEF:
db 31 d8
//xor eax,ebx

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 7: Using negative values in Assembly

To create a negative value in Assembly, all you do is flip the bits and add 1.

Let's go through a couple examples:

What is -1 in assembly?

First, we get the bits of 1:

Code:

00000001

Next, flip them:

Code:

11111110

add one:

Code:

11111111

and change that back to hex, you get

Code:

FF

So the answer to the question "What is -1 in assembly?" is 0xFF.

~~

What about -5?

Take the bits of 5:

Code:

00000101

Flip them

Code:

11111010

add one

Code:

11111011

convert to hex

Code:

FB

And there you go, the answer is 0xFB.

~~

Let's do one last example:

If you wanted to move the value of -10 into al, what would your mnemonic be?

First we find the value of -10d (-10 in decimal) in assembly...

The answer is

F6

(Try to do this one yourself, when you think you have it, highlight this, copy it, and paste it into notepad.)

So your opcode would be

mov al,f6


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 8: The Stack

The stack is a very simple concept. Basically, it's like a pile of values that can be accessed by the esp register. First off, I'll discuss pushing/popping, then I'll discuss using the esp register to access the stack. Pushing/Popping help you first understand the stack, then using esp is a bit more advanced.
If you aren't using esp, then you can do one of two things to mess with the stack, you can push something onto it, or pop something off of it. Push takes a value and puts it on top of the stack; pop takes something off of it and puts that into a value.

For example, let's say that this is our stack:

Code:

1
2
3
4
5
6
7
8
9

If we did the following command

Code:

push 0

then our stack would look like this:

Code:

0
1
2
3
4
5
6
7
8
9

(Going from our original stack)

If we did the following command

Code:

pop eax

our stack would look like this:

Code:

2
3
4
5
6
7
8
9

and eax would contain the value "1"


~~~


Also, a note on this, if you did

Code:

push eax

the top of the stack would not be "eax", it would be whatever was in eax (not the value, but the actual eax).


~~~

Now, for using esp to access the stack:

ESP is the register that points to the top of the stack, so if we had the stack...

Code:

1
2
3
4
5

Then we would have the following equations:

Code:

[esp+ 0] = 1
[esp+ 4] = 2
[esp+ 8] = 3
[esp+12] = 4
[esp+16] = 5

It's not too complicated, but it can be quite tricky when trying to access the parts of the stack. Just FYI, we increment by 4 each time, because each of the different values on the stack are assumed to be 4 bytes in length.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Section 9: Using Cheat Engine to debug assembly

First, you need to find an application to debug, and of course have Cheat Engine installed.

I'm going to be using Minesweeper (just for lack of a simpler program that isn't too simple =P).

Now, before we get into any actual debugging, I'm going to explain to you the theory of it. So you've got this debugger (Cheat Engine) that has the ability to watch all of the registers, flags, and segments, and to step through code one instruction at a time. The way this works is by setting a breakpoint on a certain address; when that address is come to by the actual program, it turns over control to the debugger. The debugger then has the ability to view all of the registers and what-not, and step through code.

What is stepping through code? It pretty much explains itself; all you're doing is going through the addresses one at a time, so you can completely understand what the code is doing to the program.

Now, so you can watch it in action, take the following code and inject it into Minesweeper:

Code:

alloc(codecave,1024)
label(return)

01002ff5:
jmp codecave
nop
return:

codecave:
push eax

mov eax,4
nop

cmp eax,3
nop

cmp eax,4
nop

pop eax

jmp return

Cheat Engine will pop up a message box saying

Code:

The code injection was successfull
codecave=x

Where x is a number (mine is usually 00980000, if it's the first thing injected).

Click ok, and close out of the window. Then browse to the address x (yes, you had to remember it), and you should see your assembly.

What I have there are just some simple instructions that you should know the results of, just so you can simply watch.

Select the top address (x), and click on Debug -> Toggle Breakpoint. Cheat Engine will probably ask you about attaching itself t the process as a debugger, blah blah, just say yes. Address x should turn green, and now go back into Minesweeper and click a tile (to activate that address).

Going back to our theory, let's look at how Minesweeper was doing:

Code:

user clicks
blah blah, time increasing starts
increase time address (01002ff5) says jmp x
goto x
Cheat Engine has breakpoint at x
STOP

and now that's exactly what you have. Minesweeper is frozen (if you try to close it, Windows will pop up telling you that it's Not Responding and some bull shit).

Notice back in Cheat Engine, that some labels have turned red. Those are the things that have changed since the last thing that you've seen (nothing).

Next, click Debug -> Step (F7), and just keep doing that. Watch how the labels change to fit what's going on in the code.

Can you truthfully tell me that that is not amazing? Wink

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Credits:

Intel - Creating the instruction set reference pdfs:

Volume 1
Volume 2

Dark Byte - Creating Cheat Engine, along with Auto Assembly, and helping me out with LoadBinary (PM, though there is the manual, that I forgot about)

x0r - For helping me understand the CRC bypass for MapleStory (forum post here).

This website for helping me out with flags.

Wikipedia - for clearing up something about the parity flag here

src - http://www.forum.cheatengine.org/viewtopic.php?t=222520
avatar
Dami
Dragon
Dragon

Posts : 1414
Join date : 2009-08-10
Age : 28
Location : Finland

Back to top Go down

Re: An In-Depth Tutorial on Auto Assembler: Extended

Post by Jakob on Mon Jan 25, 2010 5:33 am

Nice Job on this Dami . I remember when you helped me understanding AA/ASM at the beginning and I´m very thankfull for that !

Greetz Jakob.

Jakob
New member
New member

Posts : 86
Join date : 2009-12-03

Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum