[TUTORIAL] Auto-Assembler and SSE Mnemonics

Submit Tutorials Related to Memory Hacking Software

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

[TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby CoMPMStR » Thu Sep 17, 2009 1:07 pm

I've gotten a little bored with my GTA4 projects so I started hacking some more games. I've been using this method for quite awhile now so I decided to post a little tutorial for those who hack games with SSE mnemonics.

Some tools you will need:
- MHS (...!)
- Simple .NET Disassembler (a little disassembler I created thanks to the cheat engine source that supports SSE byte codes)

This tutorial assumes that you know how to search for values so I will not go in depth on that, there are plenty of others for that. I will say that I am using Wolfenstein v1.0 for this tutorial and will show how to get infinite ammo that's using SSE mnemonics then put it into an auto assembler script to use in MHS.

Note: If you are searching for the ammo, it's a float value instead of long. And I used the MP40 (the gun first acquired at the beginning of the game), with a full clip it has 32 shots.

Determine the function location and identify the ASM mnemonic - wrote:After you find the ammo address, right click on the entry in the list and select "Find What Accesses This Address".

Image

After that, go back into the game for a few seconds to let the debugger work, then ALT+Tab back to MHS. For this situation, it will be the address that has the most hits (although it may not always be the same for every game). So right click the address in the disassembler auto-hack window then select Go To->In Current Tab. For simplicity sake, the static address I'm referring to is gamex86.dll+38B090 or 0B22B090. Note that the module changes on each game start so you may get a completely different hex address than I've gotten, the module+offset combination should still be the same as long as you have the same game version.

Image

Now that you have the function location, it's time to see what the code disassembly actually is. So now you need to open the hex editor and enter the address for the function that you just found in the disassembler.

Image

Now you need to copy all the bytes of the function as Hex Text.

Image

Once the bytes are copied to the clipboard you can switch over to the Simple .NET Disassembler program and paste the bytes in the left textbox (under the button) then click the button; you can enter the address if you choose but it's not necessary for this situation.

Image

You can see in the disassembly that the two incorrect code mnemonics are REPE MOVSS XMM0,[ECX+38] and COMISS XMM0,[0B422140] but for this particular case the only concern is the first.

Image

Now you must be wondering "How am I supposed to turn this into infinite ammo?" and you're about to find out. First since every weapon should have a max ammo amount, you need to try to find the address for it. To do this you need to go back to the hex editor and enter the current ammo address (this is to check if the max ammo value is stored somewhere near the current ammo value).

Image

Luckily, if you look 4 bytes after the current ammo value, you find the max ammo value only 1 float distance away (ie: 4 bytes).

Image

So since [ECX+38] is the current ammo value, [ECX+3C] would be the max ammo value; great now you can set up the auto assemble script.


Writing the auto assembler script - wrote:First you need to declare some things: a label, a fullaccess request, and a memory allocation. So at the top of the auto assemble text you should have this:

Code: Select all
label(ammoret)
fullaccess(gamex86.dll+38B090, 5)
alloc(infammo, 90)


Now that you have the declarations written, you can continue with the [enable] and [disable] sections. Under [enable] all you need is a jmp call followed by the allocated code cave then the return jump back to the original code, but how is this done? Easy:

Code: Select all
[enable]
jmp infammo

infammo:
push eax
mov eax, dword ptr [ECX+3C]
mov dword ptr [ECX+38], eax
pop eax
db 0xF3 0x0F 0x10 0x41 0x38
jmp ammoret


If you're looking at this like wtf then continue reading. This code simply says that it will jump to the new location, push eax onto the stack (because you don't know what value it holds or what is its use, all you know is that it isn't used in the code you're modifying), copy the max ammo value into the eax register, copy the eax register (which now contains the max ammo value) to the current ammo value, then pops the value eax had previously back into the proper register. For this situation you might not need the push and pop mnemonics but it's a good habit to get into, it will definately avoid any unnecessary game crashes.

The db command allows you to specify a set of bytes without typing an actual mnemonic, and it works great for something like this where you have a mnemonic that isn't supported. This specific db statement is just the original SSE mnemonic that is being overwritten by the initial jump. Lastly, it will jump back to the original location; even though you haven't specified it yet (I'm getting to it, it comes after the [disable] section).

The [disable] section is really short, basically it just reverts the inital jump back to the original mnemonic it was at first. Then the dealloc function is called to remove the previous memory allocation that was used for the jump:

Code: Select all
[disable]
db 0xF3 0x0F 0x10 0x41 0x38
dealloc(jmpammo)


Finally, you can get to the return jump. At the very bottom of the auto assemble text should be the return jump label, specified as such:

Code: Select all
ammoret:
gamex86.dll+38B095:


The reason for gamex86.dll+38B095 is because the mnemonic you have to overwrite is 5 bytes in length, so 38B090+5 is 38B095. Now before clicking the OK button make sure to tick the box 'Use Auto-Assemble for Locking'.

To sum it up, the complete auto assembler script should look something like this:

Code: Select all
label(ammoret)
fullaccess(gamex86.dll+38B090, 5)
alloc(jmpammo, 90)

[enable]
jmp jmpammo

jmpammo:
push eax
mov eax, dword ptr [ECX+3C]
mov dword ptr [ECX+38], eax
pop eax
db 0xF3 0x0F 0x10 0x41 0x38
jmp ammoret

[disable]
db 0xF3 0x0F 0x10 0x41 0x38
dealloc(jmpammo)

ammoret:
gamex86.dll+38B095:


If you've gotten everything correctly then you should be able to go back into the game and shoot without reloading. Also with this particular hack you will also get all weapons plus infinite grenades. ;) Don't blame me if it doesn't work online!


Thus ends my tutorial. All questions, comments, suggestions, or corrections are welcome. :D I'll do my best with any questions.

~EOT
Image

______________________________________________________
My Utilities:
CT <-> LSSAVE Converter
LSS Visual Dialog Designer
.NET Trainer Helper Library

~Whether you think you can or you think you can't, you're right.

L. Spiro wrote:In my left hand is a red pill. If you take it I will show you the truth. I lost my right hand in the war, so I’m afraid you’re stuck with the red pill.
User avatar
CoMPMStR
(P)ot (I)n (M)y (P)ipe
 
Posts: 451
Joined: Thu Mar 06, 2008 7:50 am
Location: Best Place

Postby WhiteHat » Thu Sep 17, 2009 7:00 pm

Two thumbs up...
Especially, thanks for providing us that disassembler...

Sticky-ed ?
.. to boldly go where no eagle has gone before...
User avatar
WhiteHat
Elang Djawa
 
Posts: 1059
Joined: Fri Jul 21, 2006 12:49 pm
Location: Away for a while...

Postby L. Spiro » Fri Sep 18, 2009 12:57 pm

By now you have surely contributed enough to request a special forum title.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby trialusert » Fri Sep 18, 2009 9:28 pm

Great great great. =)
Also thank you for providing the Diassembler, it happens to be very useful.
Do you also play Wolfenstein: Enemy Territory? I'm working on a bot for that game, so maybe you could help me with some features I'm trying to make
User avatar
trialusert
NULL
 
Posts: 155
Joined: Tue May 20, 2008 6:19 pm

Postby CoMPMStR » Mon Sep 21, 2009 9:22 am

trialusert wrote:Great great great. =)
Also thank you for providing the Diassembler, it happens to be very useful.
Do you also play Wolfenstein: Enemy Territory? I'm working on a bot for that game, so maybe you could help me with some features I'm trying to make


Sorry I don't have Enemy Territory, I just got Wolfenstein because it was one that I didn't get yet. I've been messing with RE5 and GTA4 lately but now I will probably go with NFS:Shift for a bit. :D

I also just released a Trainer Helper Library that's used with .NET. Since I've been using it in my recent trainers, it seems to be pretty handy and working great so I decided to clean it up and see what others have to say about it.

@L. Spiro:
Could you make my forum title, ( P )ot ( I )n ( M )y ( P )ipe? If not then CoMPuTer MAsSteR is fine. ;)
Image

______________________________________________________
My Utilities:
CT <-> LSSAVE Converter
LSS Visual Dialog Designer
.NET Trainer Helper Library

~Whether you think you can or you think you can't, you're right.

L. Spiro wrote:In my left hand is a red pill. If you take it I will show you the truth. I lost my right hand in the war, so I’m afraid you’re stuck with the red pill.
User avatar
CoMPMStR
(P)ot (I)n (M)y (P)ipe
 
Posts: 451
Joined: Thu Mar 06, 2008 7:50 am
Location: Best Place

Re: [TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby cobr_h » Fri Dec 04, 2009 7:41 am

really cool tutorial.

But from this, I got an question. In every process we have a part of it which holds the code execution and another which holds the data holding. Then, suppose we can't attach the debugger in an application because of maybe anti-cheats on place, but you can read all data and code area.

First, is there an indication when we open the process with MHS, maybe into the internal 'Hex Editor', where we can sepparate the code area from the data area of the proccess? They are not all around the process, right? Code first, data then. Then there should be indications on where the code ends to take place the data area.

Knowing this, I could find 'who changes this address' (or who accesses) by searching for an address from the data area (say the ammo amount at 1F67D2F4) into the code area. So if I find a reference on the code area which says '1F 67 D2 F4' I could then read the two or so offsets right before it (the instruction -- or if it is the second address parameter of the instruction, shift back the correct amount of bytes to get to the instruction I expect it to be). Then if the instruction found is a 'MOV' (move a value from a register to that memory address), am I effectively finding 'who changes this address' without attaching a debugger?

For example, a sequence of bytes on the code which could indicate it would be:
Code: Select all
C6 05 F4 D2 67 1F 01
(as C6 05 is MOV BYTE, then the addy in reverse, and in the end a 'true' -- yes! he has ammo!).

Did I get it, or did I mess up completely?

Then if I could differentiate the code area (ahmmm better instruction area, maybe?) to data area, I could filter correctly a place who changes/accesses addresses and the actual address the data is in, thus being able to set breakpoints without attaching debugger to the process, what can be sometimes useful to avoid trouble with system overload debugging code and hassle to make the debugger not detectable.
cobr_h
Acker
 
Posts: 72
Joined: Wed Dec 02, 2009 6:15 am

Re: [TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby L. Spiro » Fri Dec 04, 2009 1:39 pm

#1: The Hex Editor shows modules (which contain the executable data) as blue.
You can get more information from the Properties page. Code is typically stored in the .text sections.
White areas in the Hex Editor are always data.

#2: You can not search for opcodes that reference non-static data. Your example assumes the data will be in a blue area in the Hex Editor. This will never be the case and your opcode would be more like mov eax, DWORD PTR [eax+3C]. But from here you are left with a guessing game. Which register is it using (both for access and for storage)? DWORD, WORD, or BYTE? What is the offset? Is it mov or lea? The questions are endless.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: [TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby cobr_h » Sat Dec 05, 2009 7:09 am

when I attach to a process, the addresses I can browse with the hex editor are global addresses to the system memory(addresses of the actual pages in ram or not, or addresses relative to the specific application's area)? In other words. If I attach to winmine.exe, the address 00000000 is really the very first page in RAM?

Windows addresses byte from 0 to 4G for the virtual memory system as far as I know (0 to 2^32 on 32-bit based systems divided on blocks of pages, which makes it fit on 2^8 addresses) although you may have only 1G of RAM, the 4G is always addressable. I know you and many know this. Just making up the context.

If I just open the hex editor, it is unable to show anything. When I attach MHS to WinMine and do CTRL+H (hex editor), I am presented with the blue zone you mentioned above, starting at adress 01000000. If I go back from this address I find red zones and some sparse data zones. This means that once MHS attaches to a process, it could read any part of the memory which is not unallocated by the OS, or all that red zones are areas not belonging to the process actually running?.. This question also kind of depends on the first problem of absolute or relative addresses. Is 01000000 to hex editor when attached to winmine.exe the same data if I read directly from the windows' memory pages, or is it mapped to addresses relative to the software?

By the non-contiguous disposition, it really seems to be absolute addresses. But I am wondering if even on winmine there are parts of the program that could not be read by MHS' hex editor.
cobr_h
Acker
 
Posts: 72
Joined: Wed Dec 02, 2009 6:15 am

Re: [TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby L. Spiro » Sat Dec 05, 2009 8:18 am

The MHS Hex Editor can read any address in the process from 0 to 17,179,869,184 gigabytes, however 32-bit operating systems allow usage of only 4 gigabytes.

Windows uses a virtual addressing system. The addresses shown in the Hex Editor are virtual addresses.

Every process has just under 2 gigabytes of RAM available to it in ring 3.

Red zones mean memory that are not allocated by that process. It has nothing to do with other processes.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Re: [TUTORIAL] Auto-Assembler and SSE Mnemonics

Postby CoMPMStR » Sat Dec 05, 2009 8:33 am

The addresses in the hex editor after attaching to a process are addresses only used by that specific process, it has nothing to do with system memory or other running processes.

The blue zone that you are presented with can probably be referred to as static memory. This indicates the memory where a process module is located, 0x01000000 is the base address for winmine.exe. Basically means that the module winmin.exe was loaded at that address in the process's memory, you can see in the Info tab where all the modules used by the process is loaded.

The white zones show memory that has been allocated by the process after it has been loaded. This is dynamic memory and can change each time the process starts, or in the case of strings, each time the value is changed; very seldom this area is considered static. These addresses usually require a complex address to resolve the correct memory location each time the process starts.

The red zones are unallocated memory, this has no use by the process.

@L. Spiro: Can you fix my custom forum name? I just noticed a typo.. :shock: Thanks!
Image

______________________________________________________
My Utilities:
CT <-> LSSAVE Converter
LSS Visual Dialog Designer
.NET Trainer Helper Library

~Whether you think you can or you think you can't, you're right.

L. Spiro wrote:In my left hand is a red pill. If you take it I will show you the truth. I lost my right hand in the war, so I’m afraid you’re stuck with the red pill.
User avatar
CoMPMStR
(P)ot (I)n (M)y (P)ipe
 
Posts: 451
Joined: Thu Mar 06, 2008 7:50 am
Location: Best Place


Return to Tutorials

Who is online

Users browsing this forum: No registered users and 0 guests

cron