I need to stop taking such long breaks from hacking, I miss it. :(
But with some free time - mixed in with some personal problems - back I come! Enough with the
depressing thoughts though, time to have some fun!
One of the main things I have noticed over the course of writing this tutorial is the general
lack of information available for CoD4. There are some structures posted on g-d, but in the
scope of things, that is about it. No tutorials, and it seems, very little information - or
attempts - to make memory hacks, instead taking a D3D approach to hacking. Personally, and
excuse me for stealing your words b33r, I have never had the time nor the desire to pick up
DirectX, so we are going to stick to a good old memory ----.
Now although CoD4 is based off the Quake3 engine, it is heavily modified. Gone are the days of
client_mp_x86.dll; instead, CoD4 adopts a very similar engine to Quake 2. You have the main
game code in the .exe with graphics done by the linked d3dx9_34.dll. Granted, this makes
reversing a little harder, but in essence, the same principles from any Quake3 engine game
apply. In direct proof to this point, the majority of this method is based off the same method
that Crx used. So without further ado, let's start.
*I got the game through Steam, so I cannot be positive that the safedisk stuff in CoD4 will
affect anything, but if it does you will either need to download a crack, or learn to reset the
debug ports.*
Since CoD4 is based off the same engine, we can still use the Quake3 SDK to make our job a lot
easier. Open up the SDK, and go to cg_players.c, and scroll down until you find:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
This function is called by CoD4 whenever a new player needs to be added to the screen. If you go
to cg_ents.c, you will see a reference to CG_Player under CG_AddCEntity:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Luckily for us, that string is still in CoD4.
Before you start debugging, navigate to your CoD4 directory(..\call of duty
4\players\profiles\[yourname]), and open up config_mp.cfg. Once it is open, search for
"r_fullscreen"(without the quotes), and change the initial value of one to zero. This will let
us launch CoD4 in a window, so our screen does not freeze when we pop in Olly. With that set,
save the file, and launch CoD4. Once it starts up, hit the tilde key(~) to bring up the console,
and in it type "\devmap mp_crash"(without the quotes).
*If you cannot bring up the console, navigate to Game Options, and change "Enable Console" to
"Yes."*
Once the map loads, join the marines, and again enter the console and type "cg_thirdPerson 1."
Now attach Olly to Call of Duty 4, and switch the view to CoD4's main module(Right click> View>
Module 'im3mp'). Once in there, hit Alt-M to bring up CoD4's memory map. Now search for a binary
string(Right click> Search), and search for "Bad Entity"(without quotes) under ASCII. You should
land here:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Now if you notice, every other string is separated by a series a four periods, so scroll up, and
you will see that the start of the string is actually on 6C83b0h, with '§'. Select that, and hit
Ctrl-R to bring up a list of references to that string, and you should see:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Double-click on the reference to be brought to:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Well, that certainly looks familiar. Go back to the Quake3 SDK, and go to bg_public.h, and
search for "ET_PLAYER." You should come to the entityType_t structure:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
We see that ET_PLAYER is simply an identifier for a constant of one, so go back to Olly, and
scroll up to case one of the switch:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
This looks like it could be our call, so let us nop it out and see what happens(Right click>
Binary > Fill with Nops). Un-pause CoD4, and go back into the game, and you should notice the
lack of your player. Go back to Olly, restore the call(Right click> Undo Selection), and hit
enter on the call at 4354c9h to go to CG_Player.
*Chinese run. I be hungry for some dumplings. I'll work on this later.*
Let's try to find our place in this function. If you look a little down from the top, you should
see:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Go down to the dump, hit Ctrl-G, and navigate to 794470, and you should see it holds the value
one. Well that is certainly suspicious. Go back to CoD4, and in the console, type
"\cg_thirdPerson 0", and navigate back to Olly. Well it changed the value at 794470 to 0,
meaning 794470 must point to cg.renderingThirdPerson, and the code at 4453b0 is actually:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
*I took a two day break. In the past two days I have managed to finish off two twelve-packs of
coke. I'm wired.*
*You can ensure that this is the third person view, but changing the compared value to one; if
you go back to CoD4, you will notice it draws your body over your first person view.*
*Before I continue, it is important to note that I know nothing, and all presented views are
based entirely on conjecture, and not on fact.*
Under the cmp, you will see a conditional jump to 4454fdh:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
If you press enter on the jump, you will see it lands you at the end of the function, where Call
of Duty 4 restores several registers, balances the stack, and then return. We can guess that
this is:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
With that jump, we can guess the code after it retrieves the local renderfx value, and alters
it. To figure out how it works, put a breakpoint on:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Step through several lines, until you get to this:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Well that looks suspicious - eax is being assigned a value held in a static memory address. If
you execute that line, you will see that eax is, in most cases(considering upon execution of
this line, eax holds zero), being assigned the value at 14a9f30h. Go down to the dump, and hit
Ctrl-G, search for 14a9f30h, and you should see it holds the value ACh. Change the value to ABh,
remove your breakpoint, un-pause Call of Duty 4, and you should notice that your model's legs
seem to move very fast. Change it to AAh, and you should see that your model turns into a car!
We have seem to have found the rendexfx variable!
*Sorry, I thought it was really exciting running around as a car.*
Now a few lines down from that, you should notice:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
*You don't have to remove your breakpoint, simply keep stepping through each line until you
reach the above code.*
Step through until the conditional jump, and you should see that esi now holds 0147C260h. Go to
that location in the dump, and it should place in the middle of a structure, that looks similar
to:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
If you change the 40 to 41, you should notice in-game your model's bones get corrupted. It seems
that 0147C260h controls the axis of the model and bone placement!
*That is interesting - and I'm hoping someone will take to time to fully reverse everything -
but back to our original intent.*
If you look at the Quake 3 source, you will see that CG_Player actually adds the player to the
scene by calling CG_AddRefEntityWithPowerups:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Now, unlike the original Quake 3 source, which adds each element of the player in succesion,
Call Of Duty 4 insteads adds them all at once. Knowing this, we need to locate a call with three
or more pushes within the CG_Player function.
*It is far easier to just examine the adjustment to the stack pointer than to add up each push.
We need the stack pointer to be adjusted at least Ch(for three pushes).*
The first calls at 445421h and 44542ch both take two parametres, so those can be safely ruled
out - however, the call at 445487 looks very suspicious, as it takes four parametres(10h). If
you look, you will see the first push occurs on 44546eh(push ecx), so set a hardware breakpoint
on that(Right click>Breakpoint>Hardware on Execution), and Olly should pop. You will see that
ecx holds five - not amazingly helpful, so continue to step through, until you reach
44547fh(push eax). You will see at that time, eax holds dfd40h; if you navigate to the dump, you
see that dfd40h holds a small structure - quite suspicious. Go through the next couple pushes,
until you reach the movs, and you will see that both eax and ecx contain pointers to structures
upon the execution of the call, meaning our call has to look something like:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Well since there is no obvious move of the local renderfx variable to a structure, Call of Duty
4 must be pushing some constant to alert the engine how to draw the object in terms of depth
testing. I am always quite suspicious of random numbers being pushed(wee for guessing), so let
us see what happens when we change the push at 445480h from four to three.
If you go back in game, you will notice we now possess some WTFBBQWALLHAX. Hooray!
----------------------------------Coding Time---------------------------------------
*Some of the base stuff I literally copied and pasted from my previous tutorial since the same ideas apply. This is my apology for being a lazy bum.*
So here I'm probably going to lose a lot of you, because we are going to be coding this in
assembly. I'll give you the chance to hit the back button on your browser...
...for those of you still around, let's start.
* I personally use RadASM, and although I would strongly suggest it, you are free to write the code in whatever you want. I'm using MASM to assemble and link though, so it is likely that some of the code will not work on other ASM packages, although, it shouldn't be too hard to edit. *
First, let's get the shell set up (this is a .DLL for any that didn't guess):
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Next we need to import three functions for writing our code to CoD4: VirtualAlloc, VirtualProtect, VirtualFree. So above the .code section, but below the standard definitions(.386, .model, etc.):
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
*Yes, we could use include \masm32\include\kernel32.inc and include \masm32\include\opengl32.inc, really a matter of personal style. And a little extra space is tacked on when using include files.*
Okay, now on to the actual .DLL, in main, after the @@::
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
* I did give you the chance to leave. If you're going to code in assembly, you better be prepared to write in assembly, not this semi-H.L.A. shit mASM now supports. *
Okay, basic rundown of this code; since this is a .DLL, one of our main concerns is about keeping everything nice and balanced. First we push the base pointer on the stack, the move the stack pointer into the base pointer,which basically tells the running code that the current base of the program is the base of our .DLL, which Mr. Computer needs to know so he(there are no girls on the internet, therefore, computers are always guys) can figure out where to return upon calls, jumps, calculations, etc. The push saves the base pointer on the stack, so that when we leave our function and return, the base is set again to CoD's base pointer. After that we move the data in the base pointer + Ch(12d), which holds the reason for our .DLL being called.
* ebp = base
ebp + 4 = __stdcall DllMain
ebp + 8 = hModule
ebp + 12 = ul_reason_for_call
ebp + 16 = lpReserved *
If the reason is DLL_PROCESS_ATTACH(or 1h), then we want to execute our code, otherwise, we want to leave our .DLL and return execution flow to CoD4(making sure to balance the stack - three parametres = retn CH).
* eax needs to hold the reason for the call at the return of our .DLL, so we preserve it by push'ing it before our function calls, and pop'ing it right before we return. *
Before we can start writing code to our address, we need to first unprotect it, and before we can do that, we need to free up some space to hold the old protection type:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Basically, this allocates four bytes of space(MEM_COMMIT, PAGE_EXECUTE_READWRITE) in the current process for us to play with. We move the address of this space into ebx, since eax is soon to be corrupted by our following calls.
Next, before we can write, we need to unprotect the code 445480h:
*Well, actually since we only need to unprotect one byte, at 445481h technically.*
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Now with our data unprotected, we can finally write to it:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
With our hook now written, it is time to tidy everything up:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
The final code:
کد:
برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید
Inject, and tada!
Well, I must admit that this tutorial took me quite a while to finish. I cannot even remember what the original personal problem I was having was. But oh well. Thanks for reading!
Love,
attilathedud <3
Written for doxcoding.com+deviatedhacking.com, don't post elsewhere without permissions.
P.S. Please don't rip without credits.:(
Shoutouts:
b33r - for being an awesome guy, you should check out his CoD4 wallhack, much better than mine!
antihaxer - for always making me think about hacking by asking me questions, and "encouraging" me to finish this tutorial.
King_Orgy - for being an awesome guy, always helping.
pandas - for teaching me everything I know about assembly, miss you.:(
آکوستیک ، فوم شانه تخم مرغی، صداگیر ماینر ، یونولیت
محتوای مخفی: متن آموزش :
قوانين ايجاد تاپيک در انجمن
.gif "N Aggressive (16)")
.gif "N Aggressive (45)")
نوشته شده توسط MrJamshidy
