series

Continuing from part 4, I will be explaining about the detour I use in the cof plugin for day of defeat source. Basically, a detour is just what you would expect. When the actual game code reaches a certain part in the program, it will jump into one of your own newly coded functions to execute some code, then jump back to the original program. When we return control to the original program we can either return at the same place we jumped from, or we can return somewhere later in the program.

In the cof plugin, I setup a detour to replace the original bullet spread code with my own. I did this by setting a jump instruction right before the original jump code, and I returned just after the original shot code. I will illustrate this with a picture.

Basically what we are doing here is substituting our own code for the original. If you look at the cof plugin source from part 3, the code that adds this detour is found in the addCof function. I will explain the parts of it now.

First off we set the starting offset in the binary. This was mostly for optimization, instead of having the scanner search the entire binary image, I have it starting at a specific offset. This offset is far enough in the image to save some time while not going over the area the cone of fire code is likely to reside. Unless you know for a fact that the location will always be beyond this point, I do not suggest this for many projects. You will also notice I set two different values for win32 and linux. In linux I simply use a function to give me the address of a symbol in the file so that becomes my offset. After some experimentation I noticed that linux elf files did not take as kindly to the hard coded offset like windows did.

The next bit of code simply scans the binary for the shot code. After some error checking I offset the address a bit according to OS to run over the mov instruction right before the push -1 instruction (see cof plugin: part 4).

I then make a copy of the memory in that address space to allow for a simple ‘undo’ of the detour, should the server want to turn it off or an error occurs.

Immediately after that I proceed to write my detour. In this case I write it at the exact same point as the push -1 instruction from the last post.

What I ended up doing is moving the address I was going to jump to into a register and then calling a jump on that register. Something similar to:

mov eax, 0×11223344
jmp eax

My memory is a little fuzzy but that is basically what I did. You might be wondering why I did it this way and not just a ‘jmp 0×11223344,’ which is a very good question. See, the jmp instruction itself can only travel x number of bytes away. It can’t go anywhere in memory, across segments for instance. the ‘jmp far’ instruction can, but writing that function on the fly is a pain in the butt. I found an example of this kind of jump on the game deception forums. It allows me to jump where I need to go.

So after we write the jump into memory the legitimate bullet shot code will be sent directly to the address the myCOF() symbol points to. Two versions of this function exists, one for windows and another for linux.

Unfortunately this is where I have to end today so next time I will explain the assembly code, the stamp code, and how to setup the return jump.

So hopefully by now you have a working source plugin that will make your server’s cone of fire a straight line. Today I am going to explain a bit about sigs, and show you the signature needed to find the correct location of the shot code.

A signature, in this case, is a string of bytes that (hopefully) only occur once in a program. This bytes should be very close, if not on top of the location you are trying to edit. For example, the signature I used in my cof plugin to find the correct location is this:

8B0D207454228B01680000803F68000080BFFF5004D95C24108B0D
207454228B11680000803F68000080BFFF5204D9542414D84C2414

If I remember correctly, this string will point my program at the exact location that the code prepares to call the random function from COF Plugin Part 1. Now if you are reading he source code you will see that I actually set many different sigs, one for the shot code, one for the return address, and 2 more for linux. In linux, the code looks a bit different so I needed 2 different sigs.

Now a sig like this, by itself is no more safe then using direct address manipulation. Lets say that 2 months from now a program update comes out and jump locations are changed to accommodate the new code. Lets say, 1000 more bytes of code were added in front of this location, now all of a sudden an address that pointed to the right location in the old version is now different.

There would be no way for our simple program to decide this or not (easily), and the sig scan would pass over the correct location without even knowing it.

By the way, sig scanning is what you use this sig for. What you basically do is start at the beginning of a binary in memory and scan through all the code looking for bytes that match your sig completely. I will post code to do this later.

So, how we improve our simple sig is to add a mask to it. A mask is a wondering thing, it tells the scanner to ignore certain parts of the sig, but still verify that its the correct order of instructions. If you are looking at my source code, you see I setup masks for each of the sigs, in fact, I made the mask and sig one in the same data structure to avoid confusion. I will not bother posting the mask, but here is the sig with the mask overlay to show what the scanning is actually searching for.

8B0D????????????680000803F68000080BF???????????????????????
???????680000803F68000080BFFF????D9??????D8??????

And this, translated into sudo assembly is

mov ???????????
???????
push 1
push -1
????????
????????
????????
????????
????????
push 1
push -1
call ???
fst ????
fmul ????

The question marks represent the bytes the scanner will not look at. In this way, the scanner will only search for this specific sequence of commands, not dealing with any data that can be changing by a recompile.

Technically speaking, the order of instructions can also change each recompile, especially if they make changes to the specific cpp file that hold FX_FireBullets. That would force the compiler to recompile the file and possibly alter the order of these commands. However I never said this was a fool proof way to scan, its just the one of the simplest and best ways. The chances of the instructions moving are very low, and if you plan to support this project in any way shape or form during its lifetime its an easy fix to change the sig a bit. In fact, if you have to change it often it is a good thing, you will learn how to make good sigs. So far I have not had to edit this sig since day of defeat source has not had an update since I made the plugin, but its always a possibility. Just remember, if you ever have to reconfigure a sig, make sure to keep it working for the older version as well, that way you can learn what you need to scan for and what you can skip.

So now that you know all about sigs I will post the sig scanner

bool bDataCompare(const BYTE* pData, const BYTE* bMask, const char* szMask)
{
for(;*szMask;++szMask,++pData,++bMask)
if(*szMask==’x’ && *pData!=*bMask )
return false;
return (*szMask) == NULL;
}

DWORD dwFindPattern( DWORD dwAddress, DWORD dwLen, BYTE* bMask, char* szMask)
{
for(DWORD i=0; i < dwLen; i++)
{
if( bDataCompare( (BYTE*)( dwAddress+i ),bMask,szMask) )
return (DWORD)(dwAddress+i);
}

return 0;
}

Fairly simple really, which is why sig scanning is the best cheap form of address retrieval. At each address we run the sig through the data comparer to see if this address matches the sig, if not, we forward to the next address. Not to efficient, but the scans are only done once as the program starts.

After the sig scanning we (hopefully) have the right addresses, if the sig was not found, then we print an error, if the sig was found in another location and we write there, then we break the program and the server crashes. Hopefully neither happen, but once we have the address its just a simple matter of writing our detour, which I will explain next time.

Now that we have the correct addresses for the linux and windows binaries, we will write a program to edit these values during run time. You will want to download the cof plugin’s source to follow along with the examples I provide.

Although the source plugin is very stripped down, there is still a lot going on. I will be citing specific examples inside the file and explaining what it does, there is not really any need to know what anything else does. Also, instead of trying to merge this file with an existing plugin, I will have you work in a brand new server plugin provided by valve in the source sdk. It is called serverplugin_sample in the source sdk. If you do not have the source sdk, then please download the project here.

What we are going to do first is write our mod directly to a hard coded address. In the future I will talk about sigs and scanning and all that, but for a first run this is fine. There are two functions you should familiarize yourself with, and thats VirtualProtect and memcpy. What I understand virtual protect to do, and this was explained to me by someone online, is that it protects an address space from being paged in such a way that memcpy will cause your program to break. From my understanding, virtual protect will force an address to exist in memory while you write to it. If you do not use virtual protect you run the risk of writing memory into the wrong location. Windows is constantly swapping memory in and out of ram to accommodate large programs, and by protecting that address space you guarantee yourself a safe write.

So, to write your shot code directly into the game, add this into the Plugin::Load function.

VirtualProtect([address], 10, PAGE_EXECUTE_READWRITE, &dwBack );

memcpy([address], 0×00000000, size);

memcpy([address]+5, 0×00000000, size);

VirtualProtect([address], 10, dwBack, &dwBack)

You can see an example of this in the writeMemory function of my source code example. dwBack stores the previous access permission for the address, after you write the code using memcpy, just feed dwBack to virtual protect to reset the permissions. [address] is the address you found the correct shot code at. Use the address right after 68 in the hex file. This code will replace 680000803F68000080BF with 68000000006800000000. Doing the same thing you just did with the hex editor, but this time actually doing it at run time.

Make sure to delete the binaries you edited with the hex editor before running the game with this plugin. You want to make sure this works right? When alls said and done you should end up with the same result as the hex edited binaries in a server plugin.

Next time I will show you how to use sigs to scan for the correct address, rather then hard code it and have it break at the first update.

Today we are going to get a little dirty. Modifying binary files is not just time consuming, it is also very very easy to do something wrong. For this part you are going to need a standard hex editor, I use AXE. Use your program to open up the binary server dll.

Note: This article’s purpose is to find the right address in a windows binary file, not the linux file. Thanks to the symbols were already have the right location in linux, this is how to find the correct location in windows.

Note:

A little note about C++, assembly, and hex.

In this file you are going to see a lot of hex bytes, like EB, these are known as byte codes and correspond to an assembly instruction. For instance, EB is the start of a ‘jmp’ instruction, the next five bytes are the address to jump to. You see, when you compile a C++ program, after a little compiler magic you end up with an obj file. Which is basically your C++ program written in assembly. The linker then takes all those obj files and merges them together to form correct jump addresses and function calls.

Now, inside the hex editor you will hopefully see a column with addresses, if not, edit your editors settings or get a new one.

Tab over to IDA and memorize the address you found the first ‘push 3F8000000′ candidate. Go into the hex editor and scroll or jump to the address, you should see ’680000803F68000080BF’ now edit those two push values to read ’68000000006800000000′

What this does is change the code to push two 0′s instead of a -1 and 1, in effect, making the shot distribution flat on one axis. So what you do now is run day of defeat source with your modded binaries. In order to see any difference you will have to use the “sv_showimpacts 1″ command. Now when you shoot the game will show you where your client bullet landed and where the server bullet landed. If you edited the server correctly the blue dots will form a line and the red dots will form a circle. If not, undo that last edit and move onto the next location.

After you find the correct location its just a simple matter of creating a detour. Which takes us to part 3.

This is the first article in a series I am going to write explaining my COF plugin for day of defeat source. For those unfamiliar with it, heres a basic run down. In day of defeat source, there is no shot distribution as in most games. For instance, half life 2 and counter strike source feature an expanding cone of fire. When your fire a shot the longer you spray the less accurate you become, basically. In day of defeat source however, the area your bullets can land is constant and completely random. Picture flighting with a flashlight, where you and your enemies point your lights at each other and wait for a bullet to hit someone.

Obviously this feature broke day of defeat source, and many professional day of defeat players did not pick up the game, thats where this hack comes in. My plugin successfully detoured the server’s shot distribution code into my own function that gave the bullets some center-weight. So that bullets tended to land where your cross hair was, instead of anywhere in an area around your cross hair.

The idea is hard to convey in written words, but the plugin is of no meaning to this article, just an example.

So first off lets start out with the hardest part of any detour or memory hack, finding the target.

You need a disassembler, hopefully you have one and are used to using it if you have stumbled across this article. Some good ones I can recommend is PE Explorer, win32dasm, and if you can find it, IDA. I use IDA now after using PE Explorer for quite a while, and I highly recommend it.

If you want to follow along with my example you can download an older version of the day of defeat source server windows binary here and the linux binary here.

Now what you need to do is find the section of code you wish to change. In this case, we want to change the shot distribution. Half life source mods comes with two program dll’s, a client.dll and server.dll. As expected the client library controls all actions and events on the client and the server library controls the server. In the case of this hack I had suitable source to use as a reference, namely, the source sdk. So after a bit of research I found that a section of code in shot_manipulator.h handled the shot distribution. Inside I found this:

//———————————————————
// Take a vector (direction) and another vector (spread)
// and modify the direction to point somewhere within the
// spread. This used to live inside FireBullets.
//———————————————————
inline const Vector &CShotManipulator::ApplySpread( const Vector &vecSpread, float bias )
{
// get circular gaussian spread
float x, y, z;

if ( bias > 1.0 )
bias = 1.0;
else if ( bias < 0.0 )
bias = 0.0;

float shotBiasMin = ai_shot_bias_min.GetFloat();
float shotBiasMax = ai_shot_bias_max.GetFloat();

// 1.0 gaussian, 0.0 is flat, -1.0 is inverse gaussian
float shotBias = ( ( shotBiasMax – shotBiasMin ) * bias ) + shotBiasMin;

float flatness = ( fabsf(shotBias) * 0.5 );

do
{
x = random->RandomFloat(-1,1) * flatness + random->RandomFloat(-1,1) * (1 – flatness);
y = random->RandomFloat(-1,1) * flatness + random->RandomFloat(-1,1) * (1 – flatness);
if ( shotBias < 0 )
{
x = ( x >= 0 ) ? 1.0 – x : -1.0 – x;
y = ( y >= 0 ) ? 1.0 – y : -1.0 – y;
}
z = x*x+y*y;
} while (z > 1);

m_vecResult = m_vecShotDirection + x * vecSpread.x * m_vecRight + y * vecSpread.y * m_vecUp;

return m_vecResult;
}

There are a couple options at this point, you can see that there are multiple calls to RandomFloat with the argument -1 and 1, going a bit further we find that these are floating point numbers, and this translate into 3F800000 you can do this translation on a napkin or use FPConvert.

What you can do is search the binary for repetitive push’s of 3F800000 or you can trace the function back and find out the actual (non-inline) functions that call it. In this case there are a few in the standard source tree, however after some experimentation you can find that the FireBullets function is the real deal.

I have you look for “push 3F800000″ because in assembly, when the compiler wants to call a function it first pushes the arguments onto the stack. So what you are really looking for is something like this:

push 3F800000
push BF800000
call ABCDEF00

I said there were a couple options because of this fact, not all programs you try and detour will have linux binaries. In this case, it is simply a matter of disassembling the linux so file and searching for FireBullets, you end up finding a symbol called “FX_FireBullets” which calculates shot distribution. For those who do not know, linux so files usually contain symbol names for each function it has. And these symbol names very nicely correspond to the actual function name.

However if you were going the hard way and had only a windows binary you would have to check every “push 3F800000″ to see if it looks like it would be apart of the source code above. You will probably find multiple locations which takes us to step two.

Part One Conclusion:

Obviously if you are reading this you probably have a vastly different project on your hands that you wish to implement a detour on. The goal of this first post was to try and explain the method for finding the right location in a binary file, no small task considering the size of todays programs. And we are still not done, if you are following this example you will have noticed that there are three or four likely locations for shot calculating, in the next section I will explain how to slowly nail down the correct address using a hex editor.