Games

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.