Wednesday, January 25, 2012

10 User-Mode Methods of Code Execution/Injection

So before I even start writing any terrible code (which it totally will be, as I haven't written C++ in years) I need to investigate all the ways that one can actually inject code into another process. That, obviously, is the point of this post, to highlight the ten ways that appear to be popular for injecting code into a process and a brief explanation of the method. My goal is to develop at least simple examples of each routine (Maybe not to start, but eventually). I'm going to at least attempt to build a library of the methods so it will be easy to select a method. Anyways, here's the list I came up with, if anyone has any other methods *please* email me or let me know (@_wirepair on twitter) and I'll happily add it to the list and give credit!

AppInit_DLLs Injection 
Description: Using this technique allows you to inject a single, or multiple DLLs into all user-mode processes. This is ridiculously powerful as it allows you to basically inject your code into everything that the user runs. It works by you specifying a list of DLL's separated by a comma or space you wish to load in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

There's a great excerpt from the Microsoft documentation (referenced below) regarding AppInit_DLLs:
 "Today, only a small set of legitimate applications use this mechanism. Unfortunately, a larger set of malware use this mechanism. Applications and malicious software both use AppInit DLLs for the same basic reason, which is to hook APIs"
Due to the abuse, Microsoft built in some code-signing requirements but I don't understand the point as they can just be disabled by setting the RequireSignedAppInit_DLLs key to 0x0.
Required Work: Build a safe DLL that can be loaded into any process without crashing it, hook various API calls.
References: A 30 page Word Document explaining AppInit_DLLs.
References: Simple explanation with registry key information.

Description: I'd basically describe this as the 'polite way' to inject your code into a process and hook a function or API call. While this can be used to install a global hook for all processes, you can also use it for hooking a single thread. Much like AppInit_DLLs this also injects a DLL into a remote process. To remove the hook you simply call UnhookWindowsHookEx (keep in mind this won't remove the DLL from the process).
Required Work: Probably the same amount as AppInit_DLLs.
References: A nice write up from CodeProject.
References: Using Hooks (MSDN)
References: SetWindowsHookEx API from MSDN

CreateRemoteThread & LoadLibrary
Description: This method is starting to look a bit better. Again we're loading a DLL but this time using CreateRemoteThread to force the remote process to do it. This will however require come up with our own method to hook, or modify our target functions/code as well as potentially code for handling inter process communication between the injector and the injected. Also dependent on LoadLibrary to find function names, which may or may not be modified by anti-cheating systems.
Required Work: Quite a bit more work than SetWindowsHookEx, due to custom hooking (and possibly IPC code) required.
References: A nice write up from CodeProject
References: CreateRemoteThread API Call and LoadLibrary API Call from MSDN.

CreateRemoteThread & WriteProcessMemory
Description: So far, this one is my favorite (few left to go though!). Mainly because in this method you're not even injecting a separate DLL but just the code you need. However, you still end up relying on LoadLibrary to find your functions which some anti-cheating systems may have hooked/modified.
Required Work: Depends on code that I create, it appears to be some restrictions when using this technique (with regards to variable count/size). Also may or may not require some IPC code.
References: A nice write up from CodeProject
References: CreateRemoteThread API Call, LoadLibrary API Call and WriteProcessMemory API Call from MSDN.

Exploit Memory Corruption Bug :>
Description: My good ol' friend, Memory Corruption. The idea being that you exploit a buffer overflow/ptr overwrite or something else that allows you to gain control of the program. I'm far more familiar with using techniques like these, but it's kinda silly to go down this route for a local application.
Required Work: Unnecessary
References: The internet

Code Cave
Description: OK now this one is my favorite. Very similiar to CreateRemoteThread & WriteProcessMemory, except you use a different technique for getting your code to execute after injection. The basic flow is: OpenProcess -> VirtualAlloc -> WriteProcessMemory -> Pause Thread -> Get Context -> SetThreadContext -> ResumeThread (starts your code).
Required Work: About the same as CreateRemoteThread & WriteProcessMemory except requires inline'd x86 asm.
References: Nice write up on a forum post from Blizzhackers

IAT Hooks
Description: This method requires overwriting target addresses in the Import Address Table (IAT). I assume this method is pretty easy to detect for anti-cheat systems. But it remains popular in malware at least. Also depending on the application, some calls may be using LoadLibrary and GetProcAddress (i.e. calling functions dynamically) which would completely bypass the IAT hook.
Required Work: DC,NGDI (Don't Care, Not Gonna Do It.)
References: A newer approach to IAT Hooking, looks interesting... along with source.
References: PE & COFF Specification
References: Nice blog post on using IAT Hooks for mock apps.

Inline Function Hooking (aka Detours)
Description: The most famous version of this is the Detours library from Microsoft. Only supports 32-bit, unless you feel like dropping $10,000 for 64-bit support. It's a pretty simple approach due to the fact that functions have stub code which can be rewritten without causing problems. For a quick summary on how it works check this excellent post from, no less, a game hacking site!
Required Work: Probably the same as CreateRemoteThread/WriteProcessMemory with a little bit more asm involved.
References: Microsoft Detours Page and a old but good document from MS on how Detours works.

DLL Replacement
Description: Due to the way that windows searches for libraries, it will load any .dll we put in the same path as the executable. This, obviously, can be taken advantage of to load a dll (say d3d9.dll) instead of the one in the system directory. Or we simply rename the one in the system directory. The problem here is that you'd either have to wrap every function or figure out a way to proxy function calls to the real dll. If you think this is crazy, check out what this guy did: He's basically already written a lot of what I'm going to do but I need to learn, not copy & paste so I'm going to go about this my own way. (I still can't get over the awesomeness of his work, even though I've known about it for a few weeks now!)
Required Work: Quite a bit, need to wrap pretty much every function, or figure out a way to proxy function calls to the real DLL.
References: Windows Library Load Order ( >= Win7)

Custom Debugger
Description: Finally, I can create my own debugger by wrapping dbgeng.dll and using various debugger commands and methods to gain execution and inject data/code.
Required Work: Need to learn internals of dbgeng and wrap the necessary interfaces/methods to do what I want. So, a lot of work. Probably no time soon :>.
References: Un-friggen-real list of everything you need to 'Create your own Debugger', seriously awesome list.
References: Using the Debugger Engine (MSDN)
References: Awesome PDF with everything you need to know about WinDBG / dbgeng

Some other things of note; not really an injection 'technique' but for getting managed assembly's into a process: (check out 'how to inject a managed assembly', and CreateRemoteThread, managed style.

Anyways, I think i'm going to play around with some code now, so I may not have any more posts until after the weekend. Stay tuned though!

Saturday, January 21, 2012

DX Debugging and Time To Make The Hookers

While earlier than I had hoped, I think it's time I make at least a basic hooking library. After some consideration I decided I want to make a generic texture hacker. Basically, I want to be able to hook the DirectX create object call and inspect the textures and then hook the SetTexture call to either modify or remove which ever textures I mark. I also would like to be able to export the texture and maybe display it on screen or at least create a hash of it. This would be good because it would enable you to specify simple hashes for textures you want to mark as red or green or whatever you want. So that's where I am at and I assume this will take me a few weeks but what I learn won't be specific to texture hacking and I'll be able to reuse a lot of it in other things. (I'm looking at tackling speed hacks next, then probably aimbots).

So all this was brought about by a few things. First, I think I am doing texture hacks incorrectly. I am concerning myself too much with the application code and not the DirectX library itself. I don't know why I didn't think of this to begin with, but I don't need to find *where* in the game that it loads textures, I just need to set breakpoints on the CreateObject and SetTexture methods from dx9s.dll or whichever DirectX version is being used.

When I had some free time the other day I did a quick search for DirectX debugging which lead me to  information regarding Microsoft's PIX. For those who aren't aware, PIX is a free tool that comes with the DirectX SDK. It's hooks all of the DirectX calls and lets you inspect each object as it's being created. This is obviously of great interest to me as I can find all the textures being loaded. They call the profiling process 'Experiment' which is pbbfftt, but whatever. So you choose the application and select the 'A replayable Direct3D call stream, saved to file' and start the target application. Here's an 'experiment' of the Meshes DirectX sample application.

PIXRun with the rendered tiger

The captured texture

In the second picture you can actually right click on the texture and save to file. Pretty neat way of extracting images/textures directly from a game. Another great thing is I can right click on the texture address and go to 'Object Creation' It will show me the exact DirectX CreateObject call that initialized that texture. It was also worth just going through an entire frame setup to see how and how many calls are actually made just to render that one single stupid friggen tiger. Quite impressive considering you should be getting about 60 frames per second.

So now I want to find the SetTexture call in windbg. Here's a quick windbg session of me finding the SetTexture call in the Meshes DirectX tutorial application.

SetTextures call from Meshes

I initially set the breakpoint where I knew the SetTextures call was from Meshes and followed it in to d3d9.dll. So the method I want is: d3d9!CD3DHal::SetTexture_FP. I can now just set a breakpoint on this method for the Havok demo application. Here's that debugging session:

Finding and setting a breakpoint on d3d9!CD3DHal::SetTexture_FP

So this is all well and good, but there's a lot of set texture calls and I'd like to not have to inspect each one individually. This is why I want to build a quick hooking example that can export the textures and a hash so I can mark each one that I want set to red. If nothing else, this will allow me to brush up on my C++ which is far dustier than I hoped. So yeah, next few posts will demonstrate me flailing around with C++ and hooking. 

Thursday, January 19, 2012

Where I'm at with Havok (I don't know what I'm doing)

So I've been playing around with the Havok 6.0 SDK (very old, but that's what ASS uses) and it comes with a series of demos that shows off the physics and animation engine. The SDK provides the engine itself as a series of static libraries (.lib files) and their associated header files. Since the libraries are static, when I compile the demo it inlines all the functions into the executable. This makes for a very large executable, but luckily it has symbols, so for that I'm grateful.

So I wasn't really sure where to start, except for finding if it even worked with textures. All of the demos are built into a single executable with a menu system for viewing the various examples.

The example menu

The 'Animation/Api/Blending/Additive' example is actually one of the demo's that I found to load textures. Here's, what I assume will be, my next target for modification. 

Just look at her, with her face, I know she secretly wants to be red.

The source for the demo's project is laid out exactly as the menu system, so it's easy to find the code for the above example. The demo does some basic things to render the above. First it loads scene information (background etc). It does this by reading in the hkScene.hkx file and then converts it to it's internal 'scene' representation in it's environment. Next it loads the 'rig' which is another hkx file. I didn't know what a rig was so I asked my friend. He told me that the rig is basically the skeleton of the model for animation. Next it loads the animation information and does something with that (not really sure). Finally, it loads the skin file. Here's that bit of code.

The skin being loaded, and doing stuff.

Yeah, that, makes very little sense to me. I'm not stupid, I realized the engine would encapsulate the rendering, but I was hoping there'd be at least some clear references on rendering or DirectX or something. OK, so I figured that all of the functions and data that I'm concerned with is probably in one of the 300 lib and header files. 

Before that, I decided to load up the executable in IDA Pro to see if I could find any references to DirectX. First, I checked out the imports section of the file and found.... absolutely no references to DirectX. Infact, all I did find was references to OpenGL. But as you can see from the first menu image above, they clearly state that it is using DirectX9 shaders...? So after being stumped for a while I looked at the functions list for any DirectX stuff. All I found was various DirectX matrix and vector functions, but nothing I was familiar with seeing.

The OpenGL imports and limited DirectX functions

So going back to my original idea of looking at the lib files, I go to the lib directory and see if I can find anything related to DirectX, which I did.

The static Havok dx9 library

So I loaded the hkgDx9s.lib file in IDA and was presented with the below screen.

Dx9s's objects

Ok... that's not easy to work with because I can only load one 'obj' per IDA instance. After going through a number of objects I found there was still no references to DirectX functions. So I'm still continuing my search to try to figure out how exactly they wrapped the DirectX stuff. I just need to play a bit more and probably load it in Visual Studio's debugger and shake it to see what falls out. 

I however, will leave that for the weekend.

Monday, January 16, 2012

Hacking Simple DX9 Meshes with WinDBG

I am now able to set the color of an entire mesh to solid red thanks to windbg and knowledge of some dx9 structures. I am however starting to think there's better ways of doing this. First off, the target example only loads a single mesh, if it were to load multiple meshes, I would end up setting them all to red by using this technique. But for the sake of completeness this post will show how I figured out at least one way of doing it. I really think I'm going to have to start writing at least some basic injection code so I can be more flexible in how I am modifying code or data at runtime. I'm just not sure I want to start down that slippery slope just yet.

My target mesh/texture

My target this time was the DX9 SDK example code 'Meshes' which can be found in the following directory <sdk install dir>\Samples\C++\Direct3D\Tutorials\Tut06_Meshes. This example loads the mesh information from an '.x' file via the D3DXLoadMeshFromX function. These 'X'-files (teehee!) contain all the necessary geometry and texture information required to properly render it to the screen. For more information on materials check out this msdn link. Oh and here is the 'X' file, if you're curious:

After it loads the above file, the function creates a pointer to a D3DXMATERIAL structure by calling pD3DXMtrlBuffer's GetBufferPointer method. It uses this variable to extract the material and texture information. This is of obvious interest to us as it may contain default RGB values. Since a mesh can contain a variable number of materials, it loops over the number of materials and assigns the global material variable the extracted information. Here's the code for reference:

The variables that contain our mesh material information

At first I had no idea what was going on in the above code until I noticed the 'Diffuse' and 'Ambient' members of the g_pMeshMaterials structure. Since I learned all that stuff regarding texture maps, I know now that Diffuse basically means 'color stuff I can muck with'.  So as a test I added a number of lines (passed null to the SetTexture call) and re-ran the application:

Added lines (in red box) with the result.

So that's what I want, except I'm not directly injecting code yet, so I can't just stuff assembly into that part of the code. I need to learn what the structures are and do so I can modify the values prior to assignment. Here are the two structures that I'm concerned with; D3DMATERIAL9 and D3DCOLORVALUE:

typedef struct _D3DMATERIAL9 {
    D3DCOLORVALUE   Diffuse;        /* Diffuse color RGBA */
    D3DCOLORVALUE   Ambient;        /* Ambient color RGB */
    D3DCOLORVALUE   Specular;       /* Specular 'shininess' */
    D3DCOLORVALUE   Emissive;       /* Emissive color RGB */
    float           Power;          /* Sharpness if specular highlight */

typedef struct _D3DCOLORVALUE {
    float r;
    float g;
    float b;
    float a;

On my machine a float is 4 bytes. So to get the red color I should only need to modify the first D3DCOLORVALUE struct (Diffuse) to 1.0f for R, and 0.0f for all other colors. I deleted my modifications to the example and recompiled it in Release mode and took a quick peak with IDA Pro.

Setting material struct in IDA.

I also found the SetTexture call in IDA using previously described methods so I can set a break point on that as well. Finally, I loaded up windbg and set breakpoints where necessary. To get access to the structures I'll need to look at the return value of GetBufferPointer(), this is stored in the eax register. That value is actually the d3dxMaterials struct which members I'll need to modify. Here's the contents of the address of eax, which you can see is the D3DMATERIAL9 struct. It had some default values already set which I needed to change.

D3DMATERIAL9's Diffuse struct

I should only have to change these four floats to 1.0f, 0.0f, 0.0f, 0.0f and my texture should be red after I remove it from the SetTexture call. You may recall from my last post that 1.0f in memory is represented as 0x3f800000, so here's my red RGB values in windbg (also note I set green, blue and alpha to 0x00000000).

The new Diffuse struct values.

Next up came null'ing out the material variable in the call to SetTexture. I actually screwed up here and set the wrong address to null, which caused the application to crash. I set what was pointed to edx to null, but didn't notice the instruction below it showing that edx would be used as a look up in conjunction with esi (mov edx,dword ptr [edx+esi*4]). Ah well, no problem, I restarted and tried again this time setting the value at [edx+esi*4] to null.

[edx+esi*4] set to null

After that, I hit continue, which happened three times before I realized I was in a loop, I cleared my breakpoints (which you can see in the command window in the below screen shot) and it rendered my red tiger to the screen.

Mesh set to red via modifying values with windbg.

It always feels good when you accomplish something, however I'm starting to feel really held back by doing everything in a debugger. I've known for a while that I will need to seriously look at code injection and hooking techniques, I just didn't think it would be so soon. It's not that I don't want to do it now, it's that I'm going to really dive into various levels of hooking and injection (think ring0) and I'd like to learn more graphics stuff before I really dive into that. Because my knowledge of the windows kernel is about 0 (and not ring0, literally 0) it's going to take a while. 

Anyways, I think I'm ready to play around with Havok's SDK and see if they have any examples of loading meshes or something. I think that'll bring me real close to being able to do it to the real game I'm looking at. Until then! /me out.

Saturday, January 14, 2012

Floating Points in Assembly

Turns out modifying meshes are a bit more complicated. It seems like I will need to modify some DX3D structs that contain floating point numbers for the RGB values. Turns out, I know very little about how floating points are treated in assembly. This has forced me to spend an hour or two building c++ apps with various floating point values and arithmetic and seeing what it looks like in the debugger. It's funny, this is one of those things you just don't foresee being something you'll need to learn when approaching a new subject. When I was writing memory corruption exploits I pretty much skipped over any floating point junk I saw in the disassembly. I guess I have to learn it now!

So I approached this like I have approached other problems. I created some simple C++ code, compiled it, ran it through a debugger to see what it looked like. I started with a simple bit of code:

int main() {
float x = 1.0f;
float y = 0.5f;
float z = 0.0f;
cout << x << " " << y << " " << z << endl;
return 0;

I figure that should be easy to identify in the assembly. Here's what it looks like in x86-asm:
.text:004114CE                 fld1                  
.text:004114D0                 fstp    [ebp+x]        
.text:004114D3                 fld     ds:__real@3f000000
.text:004114D9                 fstp    [ebp+y]        
.text:004114DC                 fldz                  
.text:004114DE                 fstp    [ebp+z]        
.text:004114E1                 mov     esi, esp
.text:004114E3                 mov     eax, ds:__imp_?endl@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@1@AAV21@@Z ;
.text:004114E8                 push    eax             ; _Val
.text:004114E9                 mov     edi, esp
.text:004114EB                 push    ecx             ; _Val
.text:004114EC                 fld     [ebp+z]
.text:004114EF                 fstp    [esp+0FCh+var_FC]
.text:004114F2                 push    offset asc_417800 ; " "
.text:004114F7                 mov     ebx, esp
.text:004114F9                 push    ecx
.text:004114FA                 fld     [ebp+y]
.text:004114FD                 fstp    [esp+104h+var_104]
.text:00411500                 push    offset asc_417800 ; " "
.text:00411505                 mov     eax, esp
.text:00411507                 push    ecx
.text:00411508                 fld     [ebp+x]
.text:0041150B                 fstp    [esp+10Ch+var_10C]
...<calls the various stream methods for printing>...

I have no idea what these 'f' instructions do as I've never taken the time to learn it. So I head over to the wikipedia page and see that fld1 loads 1.0 into the stack (which at the time I didn't realize meant the FPU stack), and fstp does a 'store and pop' into where [ebp+x] is. It turned out I didn't really know how the FPU worked, so I had to do some general research on it. I can tell already I'm going to become best friends with floats in my game hacking endeavors, so might as well learn it now. During all of this I came across a nice resource on some general FPU information.

I knew the FPU had it's own registers, but I didn't know they were formed into a 'stack'. I certainly didn't know that you couldn't reference the registers directly. Apparently, you have to load values into the st0~st7 registers, do your calculations, then pop it off from the FPU stack and into some memory location. I also learned that any FPU instruction that ends with 'P' basically does the pop automatically.

So let's look at our assembly again and with some comments of what is going on this time.

.text:004114CE                 fld1                    ; load 1.0 onto the FPU stack
.text:004114D0                 fstp    [ebp+x]         ; pop off st0 and store it in [ebp+x]. (where ever that is)
.text:004114D3                 fld     ds:__real@3f000000 ; load from the data segment into st0
.text:004114D9                 fstp    [ebp+y]         ; pop off st0 and store it in [ebp+y]. (where ever that is)
.text:004114DC                 fldz                    ; load 0.0 onto the FPU stack.
.text:004114DE                 fstp    [ebp+z]         ; pop off st0 and store it in [ebp+z]. (where ever that is)
.text:004114E1                 mov     esi, esp
.text:004114E3                 mov     eax, ds:__imp_?endl@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@1@AAV21@@Z ;
.text:004114E8                 push    eax             ; _Val
.text:004114E9                 mov     edi, esp
.text:004114EB                 push    ecx             ; _Val
.text:004114EC                 fld     [ebp+z]         ; load the floating point value from [ebp+z] into st0
.text:004114EF                 fstp    [esp+0FCh+var_FC] ; pop it off st0 and store it in [esp+0FCh+var_FC]
.text:004114F2                 push    offset asc_417800 ; " "
.text:004114F7                 mov     ebx, esp
.text:004114F9                 push    ecx
.text:004114FA                 fld     [ebp+y]         ; load the floating point value from [ebp+y] into st0
.text:004114FD                 fstp    [esp+104h+var_104] ; pop off st0 and store it in [esp+104h+var_104]
.text:00411500                 push    offset asc_417800 ; " "
.text:00411505                 mov     eax, esp
.text:00411507                 push    ecx
.text:00411508                 fld     [ebp+x]         ; load the floating point value from [ebp+x] into st0
.text:0041150B                 fstp    [esp+10Ch+var_10C] ; pop off st0 and store it in [esp+10Ch+var_10C]

Cool, that makes a lot more sense. Seems sort of contrived due to the fact that you can't reference them directly. You see it does a lot of pushing onto FPU stack, then storing in some memory location, then pushing back into st0 and then storing it somewhere else.

So know that I know how it works, I wanted to look at it in a debugger.

1.0f pushed into st0

So there's the fld1 command loading 1.0 into the st0 register. How about fstp?

1.0f pushed onto the stack and popped out of st0

So there you have it, that's how simple float calculations are handled. You'll also notice that 1.0f is 0x3f800000, good to know!

Right, now back to figuring out DirectX's structs and how the hell I can dynamically set an entire mesh to a solid color.

DirectX9 Simple Object Texture Hack via WinDBG

OK so it turns out modifying the texture from the dx9 sdk sample was ridiculously easy. It took me about 5 minutes to read the SDK documentation and figure out what I needed to do. First step was negating the texture from even being mapped to the tutorial's object, in this case, the cylindrical tube. This was done by modifying the d3dx9 device object's SetTexture call to use NULL instead of the g_pTexture variable.

The SetTexture call NULL'd out.

The original cylinder with it's texture (left) the NULL'd out texture (right)

As you can see that gave me the object without the texture, but there are still some colors applied to it (white/grey shading). I want it to be red. The next place I had to modify was the object's vertex buffer. In the tutorial the geometry of the cylinder is calculated along with the pixel's RGB value (denoted by the .color member).

The vertex buffer being built along with RGB assignment.

As you saw in the modification I did before, the top part was white, and the bottom darker. So I had to modify both color members by setting the RGB color to red (0xffff0000). So I saved those changes, recompiled and ran it again.

My red cylinder, created by modifying source.
So that was obviously easy, because well let's face it, I have the stupid source. If we had the source to all the games we hacked... we'll let's just say there'd never be a legitimate client, Ever. So let's see how this all works from assembly. First I need to get the layout of the assembly code; and for that I'll use IDA Pro.
Oh and one quick note I reset the values to the original ones and I built the example in 'Release' so I don't get debug symbols. (Although I still get a lot of extra information that'd normally be stripped from the executable prior to distribution).

The two color constant members in IDA Pro.

Since I can see the function names in IDA Pro, I quickly went to the InitGeometry function and found the two color property constants. I will need to modify these values to the red value. Which means I need to modify the values at 0x00001227 and 0x00001279 to load the 'red' color 0xffff0000 and not their current values. You may wonder why I didn't write 0x00401127 and 0x00401279. This is due to the way that windows loads executables. If you're not familiar with the terms Virtual Address (VA) and Relative Virtual Address (RVA) I strongly recommend you read this excellent post on stackoverflow. Or if you need some bed time reading you could always read the PECOFF documentation from Microsoft.

So I found the color constants, next up is the SetTexture call as I will need to NULL that out. That call is found in the Render function. IDA Pro was kind enough to show me which register gets assigned the g_pTexture variable. However, I'm sure I'll never be this lucky in real life. Otherways of figuring out which function call I need to modify is by looking for other constants around your call being referenced. You'll notice the call right after the SetTexture call (which I commented as such) has three constants and one register pushed: push 4; push 1; push 0; push eax. Going back to my source I can correlate this to the g_pd3dDevice->SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_MODULATE ); call. How? D3DTOP_MODULE = 4, D3DTSS_COLOROP = 1 and the literal 0. But again, I have the source.. so whatever, just throwing that out there.

The SetTexture call that I need to NULL out.

So for the SetTexture call I need to modify the value at 0x000014E0 and set it to NULL prior to the mov into edx call. So I started up WinDBG and started the Texture.exe tutorial app. It immediately complained it couldn't find banana.bmp ( the texture) and quit. Scratching my head for a moment I realized I didn't set the 'start application from this directory' field. So I set it to: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Samples\C++\Direct3D\Tutorials\Tut05_Textures\Release\ and restarted it. After the target application loaded it hit the first chance exception. I opened a memory and disasm window, looked at Textures.exe's base address (in this case 0x013e0000) and added the RVA to it. So as you can see my memory/disasm window's point to 0x013e1227.

The base address and the color value in memory.

From here I could modify the values to red. Which I did.

The value modified to red (0xffff0000).

You'll notice I had to modify it as ff ff 00 00. This is due to how memory is read, and if you don't know about that you might want to find some material on how processes and memory actually work. If you need a book on assembler, I enjoyed Assembly Language for Intel-Based Computers by Kip R. Irvine. I read it a few years ago, so I don't remember much except that I thought it was good at the time.

Now on to Render() to null out the pattern variable. This wasn't as straightforward as I originally thought.

The g_pTexture variable

Crap, I clearly didn't look too closely at the disassembly. It's a move edx, DWORD PTR [addr]. This is a small problem because I can't just set the address to 0x00000000. The reason is it will try to dereference that address. Since 0x00000000 is empty, the application will crash (null ptr anyone?). What I need to find is an address that POINTS To 0x00000000, or I can just set a breakpoint at 013e14e0 (where the mov instruction is) and null out the value that g_pTexture is pointing to after it is properly assigned it's original value.

Set the value of p_gTexture to NULL.

So the breakpoint hit, and I changed the above value at 0x013e3024 to NULL then hit 'g' to see if it worked.

The red cylinder

As you can hopefully see, I made that cylinder my bitch. Granted this is still all very basic in the grand scheme of things, I'm just happy it didn't take that much time to figure out what I needed to do. So steps #1 and #2 are semi-done. Not bad for a few hours on a Saturday! Next up I should try the same techniques against a real object that's loaded from a mesh. That will most likely be a Lot harder.

Friday, January 13, 2012

Best Guess At Dynamically Modifying Textures

Now I need to figure out how the hell I'm going to modify these textures dynamically. I'll admit I'm not exactly sure what I need to do for this. I think I'll go to the directx 9 tutorial on texture/mesh mapping and see if I can modify how that looks via WinDBG first. Once I think I have that figured out, I'll play with the Havok Engine's SDK samples and see if they have any examples of loading meshes/textures. If they do, I should be set. While I think ASS.exe is only using the Havok engine for physics, it may also share the same method for loading meshes/objects/textures. I figure being able to correlate how Havok does it it in source will greatly aid me in doing it in this target game. 

If that doesn't work, I may need to trace the texture from the point of being loaded to when it's rendered. I fear that would take a significant amount of time, so I'm really hoping that it doesn't come to that! 

So here's what I think my process will be:
  1. Build and play around with the DirectX 9 SDK tutorial example code. Try and figure out what values I can flip to have textures 'shut off'.
  2. Attach a debugger and see what modifying the values does. 
  3. Play with the Havok SDKs examples and see if they contain examples with meshes I can modify.
  4. Do the same as #2 but with Havok code.
  5. See if I can find similiar code in ASS.exe, and again attach a debugger while playing and see what flipping bits does!
So yeah, that's my plan for now. If/Once I do all that I will start learning various hooking techniques and see if I can write an injector to allow me to modify it without a debugger! (This is the part I'm really looking forward to to be honest...).

OK time to hack...

Thursday, January 12, 2012

File Based Texture Hack Complete

OK, they don't glow *red* but they glow kinda orangeish, and that's good enough for me. Here's all three stages of the textures; starting with original then semi-modified and finally fully modified.
Original Textures

Diffuse Textures Modified

All Textures Modified

In the final picture there's a few interesting things that are going on. First you'll notice that the 'birds' are not actually red, but a weird orangeish/redish color. My guess is this is due to the emissive texture interacting with the red color causing a softer tone. That or some other shader is doing something to the model. Also you'll notice where I pointed out 'dead' that the bird appears to be the solid red color. If you think about it, the emissive texture is for a 'glow' effect. You'll notice in the original picture that there's some glow to the bird. This is probably to signify that it has some internal energy or power force. Once it's dead they probably shut off this effect as it is dead and shouldn't be emitting energy, hence it no longer glows. (I'm totally assuming this by the way).

So how did I remove the bumpiness and cause the crazy glow? Let's take a look at our individual textures in a side by side comparison.

The emissive texture, I assumed lighter colors would cause more glow so I made it all white.

The normal texture, I took the original background color and set the entire map to it.

The specular texture, made it all the background color. Maybe I should have made this white for shininess?

The diffuse texture, made it friggen red.

As you can see it was a total hack job. I just assumed if I made each texture a solid color of the background it would be enough to see a glowing texture without shadows. I was mostly right, there's probably some shaders that the engine is applying to the models that I can't modify via the textures alone. Which is actually going to bring me into the next stage. 

Modifying the files on disk, while the easiest route, is an easy way to get busted by anti-cheat services that most online games use these days. Most of these services do some sort of checksum'ing on their files via their launcher application. If it detects any invalid checksums (i.e. files modified or corrupt) it downloads replacements from the patch server. It also may or may not report the incident so they can verify if someone is cheating or not. 

The other thing to note is that it's pretty lame from a technical standpoint. It was great learning all this stuff, but I don't want to open gimp to hack a game, it's kinda gimpy... (pardon it's late). 

I think at this point I'd like to figure out how to change textures dynamically, while the game is running. For this I'll need to head back into debugger land. My next post will be detailing how I think I should approach changing textures via the debugger. After which I'll post my progress and finally a summary (if i'm successful) of how my initial thoughts actually ended up working out for me.

Tuesday, January 10, 2012


I think this day and age it is pretty safe to say that No one learns on their own. I am lucky enough to have one of my best friends be a 3d artist for a game company. Naturally, over the past few weeks we've increased our communication. If you remember in the last post I modified the textures to bright red and yellow. But as you can see in the image, it still looks actually kinda good. It has some sort of reflection and looks 'bumpy' and generally 3d'ish (if that's a word).
The 'bird' with my awesome modifications, still looking 3d'ish.

I've just been continuing my DirectX studies when I finally asked my friend about all of these other DDS files that are clearly not simple color textures. Now, I've played enough games and talked to my friend enough to have heard terms like 'bump mapping' and 'height maps'. But I never knew what the hell they looked like or how the data stored. Turns out this ASS game stores them in individual DDS files. So let's go back to our 'birds' character folder and see what other map files it has.

All the texture files for the bird character.

After opening each texture in GIMP and trying my best to explain what I was looking at to my friend, I realized it would be much quicker to just send him the stupid file.  The file I sent him was '' and he explained that these textures are subjective and could be created entirely for a specific effect. He also explained that some people abide by a naming convention. You'll notice that each part has either a '_d','_e','_n' or '_s' suffix. This (in some cases) denotes the type of texture. Apparently these four types are the basis of any model. Let's take a closer look at each one.

Diffuse texture map, this is used for defining the colors of the texture.

Normal map, this is used for defining the 'bumpiness' of the texture.

Emissive map, this is used for areas that will be lit up/glow.

Specular Map, this is used for showing the 'shininess' of the object. 

If you want a bit more of an explanation with some samples check here. The emissive map didn't really make sense to me until I realized it's the same thing as a self-illumination or glow map. Normal maps are by far the most important (for 3d art anyways) because that's what makes the object look 'real' by giving the model some depth. Normal maps are apparently the way of doing bump mapping these days. There's a great image that shows the importance of Normal maps taken from wikipedia
A complex mesh, then a simplified mesh with normal mapping applied. (image from wikipedia)

Do you see those numbers in the caption? 4 MILLION TRIANGLES to generate that first image. It is then reduced down to 500 triangles and has the normal map applied to it. That's 3,999,500 LESS triangles your CPU/GPU has to compute, all because a normal map is applied and makes it look like it has proper depth and shadows.

So I want my modified model to glow red so it's much easier to find on the screen. My next step will be figuring out how to create or modify the emissive/glow map. Also I'll probably try to modify the normal map to make the character look boring and have no depth or shadows, that should also make it easy to spot. Until next time!

Sunday, January 8, 2012

Texture Mapping Round #2

It's the weekend, I have a bit more free time to look at this. I don't like feeling like an idiot so I was determined to figure out why my textures weren't loading. The deleting of game files and having it not crash was a pretty big sign that something was going on. I assumed it might be caching. To determine what files are actually opened by the game process I reloaded the game and looked at the file list in Process Monitor.

(procmon.exe) The original asset file was still being loaded, d'oh!

As you can see in the above image, it turned out when I 'renamed' the original asset file I left the '.bin' extension. Clearly the application is just looking at any .bin file in that directory, extracting and loading it. It wasn't a caching problem, it was just continuing to load the original files! So this time I renamed the original  data_10_char.bin file to data_10_char.bxx and  in the same directory created the modified data_10_char.bin asset archive with the replaced DDS files. I gave it a red body and yellow legs so it should be pretty easy to tell if it worked.

The original asset (left) and my modified version (right).

It totally worked. One thing you may notice is that the surface still looks 'glossy'. There's a number of other DDS files that I think have to do with mapping and reflection which I didn't modify. I don't really know just yet how to disable those effects simply by modifying the texture, but I'll look into it later. At least now I know I can change the textures! Now, back to learning more DirectX.