PDA

View Full Version : [Tutorial] Basic C DLL


DyslexicCheater
6th November 2005, 05:32
I see people are still using UScript, and it saddens me. So, I guess I'll just have to teach you guys how to write your basic DLL Hook in C because noone is going to take the initiative and go do it themselves (Note, the word "Basic" - This won't give you any protection, but you will have access to everything within RvS' memory space).

Open your desired C/C++ IDE (For the purposes of this tutorial, I will use Microsoft Visual C++ 6). Create a new project and workspace. After that's done, create a new header file called "MyDLL.h". This will be the bulk of our DLL, as it will contain everything that makes it work. Open it in the editor. Now, the first thing that we are going to do is give some commands to the compiler from within our source to help us later during the release process. With that in mind, paste the following into our new header:#if _MSC_VER > 1000
#pragma once
#endif

#define VC_EXTRALEANHere we are telling the compiler that when it parses the headers that we define further on in our code, to only use the most common stuff in them. This saves us file size and speed due to the fact there is less shit to load into memory. Now we need to define the headers we wish to include.#include <windows.h> // Windows System APITo make our hack work, and to avoid having to create a lot of extra stuff on our own, we need access to Windows System API's. Our next task is to setup our macros and our naming conventions. I personally choose to use all capital letters in my conventions.#define FASTCALL __fastcall

#define BOOL bool
#define VOID void

typedef long LONG;
typedef int INT4;
typedef char CHAR;Now that all of that is over with, we can finally start programming our hacks and other other such things. This next function is one I wrote a long time ago to deal with placing function calls within the game's memory that lead to functions in my DLL. It is quite useful - but we will not be making use of it in this example.// This function will place a call instruction at a location of your choice, and optionally
// pad it with NOP instructions. It has 3 parameters. The first is the address at which you
// are placing the call. The second is the address of the function to call. The third is the
// amount of bytes to fill with NOP's. The third parameter accepts NULL as it's value.
// Example: fnPlaceFxnCall(0x508600, (DWORD)&fnStatHack, 4);
VOID FASTCALL fnPlaceFxnCall(DWORD dwAddressToPatch, DWORD dwFxnAddress, DWORD dwPadSize) {
// If the number of bytes to fill is NULL, make it 0.
dwPadSize = dwPadSize == NULL ? 0 : dwPadSize;

BYTE bytCallOperand = 0xE8;
DWORD dwDataBuffer = (FxnAddress - (AddressToPatch + 5));
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)AddressToPatch, 5 + dwPadSize, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [AddressToPatch], bytCallOperand
MOV [AddressToPatch+1], dwDataBuffer
}

for (DWORD x = dwPadSize; x > 0; x--) {
__asm {
MOV BYTE PTR [AddressToPatch+x], 90h
}
}
VirtualProtect((LPVOID)AddressToPatch, 5 + dwPadSize, dwOldProtect, &dwOldProtect);
}We are almost done :). The last thing we need for our DLL in our pre-compiled header is the function that activates our hack(s). Please note, that I haven't played RvS in a year or more, and I'm far too lazy to create a working hack for this example. So, with that out of the way, we will be using my very old (RvS v1.55) Infinite Ammo hack. This way you see how to do it, and at the same time I have less work to do (Again, I cannot stress enough - by using this hack, the end resulting DLL WILL NOT WORK! This is simply for the purposes of showing you the structure of a C DLL Hack).

Now, the part of code we want to change inside RvS is at the address 0x1011FA7A. Here we find the following code:DEC BYTE PTR [EDI]This code tells RvS to decrement (reduce by 1) the byte pointer at the address indicated by the EDI register. This is basically the pointer to the amount of ammo our player possesses. Now, we need to replace the DEC instruction with the NOP instruction (no process). With this information, we can begin to create our hack function.VOID fnAmmoHack() {

}Our first task in our new function is to setup the variables we will use.VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

}Now we have to unprotect the section of memory where the hack will be located (Note, that this step is only for use on Windows NT machines, as they are the only machines that possess this API and the ability to protect memory sections).VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);

}Now we need to replace the 2 bytes of memory where our hack will be located (the DEC instruction with two NOP instructions).VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [dwAmmoAddress], 90h
MOV BYTE PTR [dwAmmoAddress+1], 90h
}

}Now we can finish up the hack by protecting the memory section again like it was before we messed with it.VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [dwAmmoAddress], 90h
MOV BYTE PTR [dwAmmoAddress+1], 90h
}
VirtualProtect((LPVOID)dwAmmoAddress, 2, dwOldProtect, &dwOldProtect);
}

Ok, the hack is done but we're not done yet. Make a new C/C++ source file called "MyDLL.cpp". We need to setup our DLL to handle communications with our target process.#include "MyDLL.h"

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) {
switch (dwReason) {
case DLL_PROCESS_ATTACH:
// The DLL is being loaded into memory. Activate the hacks!
// Call our hack, activating it.
fnAmmoHack();
break;
case DLL_PROCESS_DETACH:
// The DLL is being unloaded from memory. Deactivate the hacks, and clean up!
// We don't need to clean anything up for this DLL.
break;
}

return true;
}

And we're done. Compiler options and settings aren't really a big issue for a small project like this. So, post your questions/comments.

DarkCode
6th November 2005, 05:49
Very nice tutorial, love how you explained everything out for every part of what you did.

Good job, but I'm still using Uscript, its fun to do, its calming, C++ is just a more complicated way of doing a simple function. Remember, the first public Ubot was out only about 1 year ago, and most people have been doing Uscript for less.

DyslexicCheater
6th November 2005, 06:00
C/C++ is not that much more complicated. And it can do much, much more than UScript.

DotProduct
6th November 2005, 06:28
wow darkcode is obviously a dumbass... sick release DC good base for people to work off of or at least learn

RuffianSoldier
6th November 2005, 07:49
Agreed, dtp'

NJ DC

C-X
6th November 2005, 09:20
I see people are still using UScript, and it saddens me. So, I guess I'll just have to teach you guys how to write your basic DLL Hook in C because noone is going to take the initiative and go do it themselves (Note, the word "Basic" - This won't give you any protection, but you will have access to everything within RvS' memory space).

Open your desired C/C++ IDE (For the purposes of this tutorial, I will use Microsoft Visual C++ 6). Create a new project and workspace. After that's done, create a new header file called "MyDLL.h". This will be the bulk of our DLL, as it will contain everything that makes it work. Open it in the editor. Now, the first thing that we are going to do is give some commands to the compiler from within our source to help us later during the release process. With that in mind, paste the following into our new header:#if _MSC_VER > 1000
#pragma once
#endif

#define VC_EXTRALEANHere we are telling the compiler that when it parses the headers that we define further on in our code, to only use the most common stuff in them. This saves us file size and speed due to the fact there is less shit to load into memory. Now we need to define the headers we wish to include.#include <windows.h> // Windows System APITo make our hack work, and to avoid having to create a lot of extra stuff on our own, we need access to Windows System API's. Our next task is to setup our macros and our naming conventions. I personally choose to use all capital letters in my conventions.#define FASTCALL __fastcall

#define BOOL bool
#define VOID void

typedef long LONG;
typedef int INT4;
typedef char CHAR;Now that all of that is over with, we can finally start programming our hacks and other other such things. This next function is one I wrote a long time ago to deal with placing function calls within the game's memory that lead to functions in my DLL. It is quite useful - but we will not be making use of it in this example.// This function will place a call instruction at a location of your choice, and optionally
// pad it with NOP instructions. It has 3 parameters. The first is the address at which you
// are placing the call. The second is the address of the function to call. The third is the
// amount of bytes to fill with NOP's. The third parameter accepts NULL as it's value.
// Example: fnPlaceFxnCall(0x508600, (DWORD)&fnStatHack, 4);
VOID FASTCALL fnPlaceFxnCall(DWORD dwAddressToPatch, DWORD dwFxnAddress, DWORD dwPadSize) {
// If the number of bytes to fill is NULL, make it 0.
dwPadSize = dwPadSize == NULL ? 0 : dwPadSize;

BYTE bytCallOperand = 0xE8;
DWORD dwDataBuffer = (FxnAddress - (AddressToPatch + 5));
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)AddressToPatch, 5 + dwPadSize, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [AddressToPatch], bytCallOperand
MOV [AddressToPatch+1], dwDataBuffer
}

for (DWORD x = dwPadSize; x > 0; x--) {
__asm {
MOV BYTE PTR [AddressToPatch+x], 90h
}
}
VirtualProtect((LPVOID)AddressToPatch, 5 + dwPadSize, dwOldProtect, &dwOldProtect);
}We are almost done :). The last thing we need for our DLL in our pre-compiled header is the function that activates our hack(s). Please note, that I haven't played RvS in a year or more, and I'm far too lazy to create a working hack for this example. So, with that out of the way, we will be using my very old (RvS v1.55) Infinite Ammo hack. This way you see how to do it, and at the same time I have less work to do (Again, I cannot stress enough - by using this hack, the end resulting DLL WILL NOT WORK! This is simply for the purposes of showing you the structure of a C DLL Hack).

Now, the part of code we want to change inside RvS is at the address 0x1011FA7A. Here we find the following code:DEC BYTE PTR [EDI]This code tells RvS to decrement (reduce by 1) the byte pointer at the address indicated by the EDI register. This is basically the pointer the amount of ammo our player possesses. Now, we need to replace the DEC instruction with the NOP instruction (no process). With this information, we can begin to create our hack function.VOID fnAmmoHack() {

}Our first task in our new function is to setup the variables we will use.VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

}Now we have to unprotect the section of memory where the hack will be located (Note, that this step is only for use on Windows NT machines, as they are the only machines that possess this API and the ability to protect memory sections).VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);

}Now we need to replace the 2 bytes of memory where our hack will be located (the DEC instruction with two NOP instructions).VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [dwAmmoAddress], 90h
MOV BYTE PTR [dwAmmoAddress+1], 90h
}

}Now we can finish up the hack by protecting the memory section again like it was before we messed with it.VOID fnAmmoHack() {
DWORD dwAmmoAddress = 0x1011FA7A;
DWORD dwOldProtect = 0;

VirtualProtect((LPVOID)dwAmmoAddress, 2, PAGE_EXECUTE_READWRITE, &dwOldProtect);
__asm {
MOV BYTE PTR [dwAmmoAddress], 90h
MOV BYTE PTR [dwAmmoAddress+1], 90h
}
VirtualProtect((LPVOID)dwAmmoAddress, 2, dwOldProtect, &dwOldProtect);
}

Ok, the hack is done but we're not done yet. Make a new C/C++ source file called "MyDLL.cpp". We need to setup our DLL to handle communications with our target process.#include "MyDLL.h"

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) {
switch (dwReason) {
case DLL_PROCESS_ATTACH:
// The DLL is being loaded into memory. Activate the hacks!
// Call our hack, activating it.
fnAmmoHack();
break;
case DLL_PROCESS_DETACH:
// The DLL is being unloaded from memory. Deactivate the hacks, and clean up!
// We don't need to clean anything up for this DLL.
break;
}

return true;
}

And we're done. Compiler options and settings aren't really a big issue for a small project like this. So, post your questions/comments.

Aaaah... DC is back again :D
Nice tut. dude ;)

RuffianSoldier
6th November 2005, 10:21
Heres an idea - dont quote the whole huge post....

frikos
6th November 2005, 10:30
luckily you did not give up your missionary work ;)
nice tutorial, seems i have to install c++ again

valenti1232289
6th November 2005, 12:26
Very nice tutorial ;) Maybe ill start making a native soon :)

frikos
6th November 2005, 13:01
doh,
i was searching for the new adresses ( if they have changed... )
i found the dma for ammo, but i can't open the "auto hack" feature in tsearch to find the adress which is responsible for the decrease.

anybody knows why i can't enable the dbugger with rvs but with other games? :eek:

KizZamP-
6th November 2005, 14:06
nice job dyslexic ;) i love you so much cause you're the one that convinces everyone to go learn c++...that obviously worked to me.
like dtp would say "pick up a book",which i am doing now.
o btw lion learned me a few things about pe explorer and offsets,so i quite understand a few things in there.
Kizzamp-

luck0r
6th November 2005, 14:46
nice tut there
and yes it saddens me too because ppl are still using uscript

@ frikos
if you have cracked rvs, you can use auto hack and enable debugger

tamimego
6th November 2005, 15:47
I must say DyslexicCheater you've outdone yourself for such a selfish community. Your TMK Stuff is a godsend and I love for that. Though I wasnt in RvS back in your day, this is a new day and age and our paths will hopefully cross multiple times :)

DotProduct
6th November 2005, 15:51
nice tut there
and yes it saddens me too because ppl are still using uscript

@ frikos
if you have cracked rvs, you can use auto hack and enable debugger

what u mean it saddens u people are using uscript... im sorry but u play the game use the game. by the way... to those who arent aware... if u have the basic headers u can hook much easier thanks to native function calls u can do through uscript.

GLoGG
6th November 2005, 15:58
nice job dc.. ;) but i love uscript and ima keep it with that ^^
newayz gj bro

-glogg

superdupe
6th November 2005, 17:28
nice tut there
and yes it saddens me too because ppl are still using uscript

@ frikos
if you have cracked rvs, you can use auto hack and enable debugger

your a tard. the only reason why it saddens you is not because your any better than anyone else, its just because you were never any good at uscript...

yes c++ is great but it depends what you want to do with it... for most of our purposes, uscript is just fine

DyslexicCheater
6th November 2005, 18:20
anybody knows why i can't enable the dbugger with rvs but with other games? :eek:

RvS has some crappy debugger protection. Use SoftICE, or OllyDbg. Or just crack the protection (Odds are, the game checks for if SoftICE's VxD's are in use at the time that it is run. As for TSearch, it uses the IsDebuggerPresent() Win32 API.).

As for UScript VS Actually Hacking the Game, if you actually hack the game, you can do much, much more. For example, as long as you are working within the scope of UScript you will never get the chance to deal with sockets. You will never be able to program an "auto-update" feature into your hack. There are so many more possibilities than just who has the prettiest Wallhack or ESP, and when you get to the point where you want to explore them you won't be able to.

Also, notice how my example was far less complicated than some of the code snippets I've seen in recent posts.

luck0r
6th November 2005, 18:41
@super
lol, why should i be good at uscript? im not an pro uscripter, ur pro uscript0r
uscript waste time and dont give much skill in c++, not every game uses uscript.. ( if you dont believe me about skill then forget.. so i know you have never heard about people havin uscript and c++ problem )
and not many possible you can do in uscript example, stun player, crash, etc..
it's cool when dc release base that some ppl can work on it, not just uscript..
thats what i mean too..
people want have something new stuff for rvs and yes
some ppl had problem they cant get to work for mp (serverside)
just because they were doing only uscript
and tnx that im a tard ive never flamed you or anybody on mpc

DotProduct
6th November 2005, 19:33
uscript is teh pwn. why would u wanna crash sumones computer or stun them? im pretty sure that an autoaim will put u in ur place. and anything i know in c++ was learned through coding uscript. and i completely agree with what DC is saying , but this all comes down to preference and frankly i prefer uscript much much more. its simple and complex depending on how much u actually want to get into it

luck0r
6th November 2005, 20:17
Yes, your right too, but in c++ you can do it more than uscript.
ive read somewhere..
A Pro Uscripter User has tried to make c++ base, he got no idea where to start, because it's not same in uscript. He always have to look at msdn how how how to... and takes more more time to code in c++. I mean for making Programms. Another way if he did read bit litt book c++ then he know where to start..

It's better if you write a Native Hook to get more skills, right? :P

tamimego
7th November 2005, 03:42
Also another thing to people starting native, dont say this shit about needing headers. the 432 core files are all you need :) Drewpaul picked up my way of coding without version dependant headers very easily :)

precision1337
7th November 2005, 05:06
LOL. well damn. look at that. i leave for a month and all of a sudden rvs is the shit again. releases and tutorials galore! well DC, although i do wish more people would move to C++, it doesn't really bother me one bit that people use uscript. dtp was right. it's all about how you load it into the game. it's kinda like asking: what's more important? a hack, or the hook that's used to load the hack? that's a pretty nice tutorial though. I guess I'll go ahead and throw in my 2 cents. for those of you looking to go native, download NativeTut.zip from the America's Army forum(it might be in Coding Support subforum) and osgb's Unreal Engine 2 Core Hook 1.2 and Tamimego's uloader source. with a little bit of fiddling around with the headers included in NativeTut.zip, you should be able to compile a native. and i'm not joking either. :laugh: O.O :cool: :smoke: :knockedou

Jurgis
7th November 2005, 05:28
your a tard. the only reason why it saddens you is not because your any better than anyone else, its just because you were never any good at uscript...

yes c++ is great but it depends what you want to do with it... for most of our purposes, uscript is just fine


how is he a tard because somethin saddens him?.... wow


anyway nice release there DC, and sorry people in RVS seem to stray away from the release and flame each other....

Damage Inc.
7th November 2005, 06:52
nice tutorial dc.. unfortunately ive lost all faith in this community breaking
away from .u script because the had everything handed to them..
(excluding some of the older members)

RuffianSoldier
7th November 2005, 07:42
I dont like using stuff people gave me anymore (at least in .u script)- I prefer to come up with and use my own ideas