Welcome to the UnKnoWnCheaTs - Multiplayer Game Hacks and Cheats.
You have to register before you can post and see and access any of the advanced forum features, please click the register link to proceed to the registration form. To start viewing threads or posts, select a forum that you want to visit from the selection below.
And If you still have any questions just pm me. But please don't pm until you have read all of that...why? Because Im reading it too...and I am very slow at reading.
Didn't really help me man... I'm looking for a way to change that source code into a dll I know the basics already...
It's simple copy and paste it and compile it. Open up Visual studio and goto file/new and select project. Then choose win32 console application. Name it, next/next choose dll and click the box that says empty project. There ya go, now right click on the source files folder and click on add/add new item. Choose .cpp file and name it main. Copy and paste Nov's information in there and then goto the build tab then click on rebuild. If you did everything correctly you shouldn't get any errors or warnings. And if for some off chance you do get errors and warnings.....don't ask about them here...google it...spend 3 weeks trying to find out what the hell a linker error is lol. Like I did, good luck.
Location: In your mom's basement (right next to ya)
Posts: 21
Reputation: 17 Rep Power: 28
Quote:
Originally Posted by dedead3232
It's simple copy and paste it and compile it. Open up Visual studio and goto file/new and select project. Then choose win32 console application. Name it, next/next choose dll and click the box that says empty project. There ya go, now right click on the source files folder and click on add/add new item. Choose .cpp file and name it main. Copy and paste Nov's information in there and then goto the build tab then click on rebuild. If you did everything correctly you shouldn't get any errors or warnings. And if for some off chance you do get errors and warnings.....don't ask about them here...google it...spend 3 weeks trying to find out what the hell a linker error is lol. Like I did, good luck.
Thank you VERY much, I'll test it as soon as I put VS C++ on my PC again.
NtQueryVirualMemory, which is what "VirtualQuery" calls is an NT function that VAC2 calls, even with hiding from usermode,
there is a possibility VAC2 can detect a usermode "hidden" module, by checking if the "MEMORY_BASIC_INFORMATION::Type" flag is set to "MEM_IMAGE" or something like that.
This "MEMORY_BASIC_INFORMATION" is pulled from the Kernel level, you can not hide from this if your module is loaded with LoadLibraryA _AT ALL_ from your userland module.
Manual Mapping will save you, which is why i have been working on it recently, but your memory image will possibly still return "MEM_MAPPED" and may even be detected from there!
Kernel hooking or hooking NT functions on Steam.exe may save you, however, the hooking of NT functions (EAT, IAT, Detour) may be checked, and if you are going to make a kernel hook you might as well just make the entire thing kernel based
@s0beit
doing manual mapping is a lot of work to get everything right, from my personal experience its simpler to avoid the usage of a dll.
I'm sure you know the CreateRemoteThread & WriteProcessMemory thechnique to inject code into a target process. Simply allocate memory for your functions, copy the code to the heap do the fixes for calls and jumps. (like you would do in manual mapping) If you wan't to avoid doing the fixups use function pointers and do relative addressing.
Its a pretty unusual method in gamehacking but there is a lot of information about it related with exploits and rootkits.
KumaT: that is basically what manual mapping is, allocate your module and execute (among other things) its DllMain function after doing all the fixups, so far my loader is working pretty perfectly with the exception of a few final bugs i need to remove.
I don't mean codecaving, you don't allocate memory if you use a code cave you only use existing unused memory to store your code there. ^^
Yes my recomendation is pretty similar to manual mapping of a DLL, but you don't need to map the whole DLL. If you map a DLL there are always things which can be found, like the PE header and other stuff. If your already doing maual mapping you can leave out the overhead of Windows. You only need some memory where your code resides may it be a codecave or some allocated space on the heap.
I try to explain what i mean, the memorylayout is like this
Code:
struct
{
function_pointers; //this is like a IAT
function_pointer_VirtualProtect;
global_variables;
}
function1()
{
do some stuff;
call function_pointer_VirtualProtect;
do some other stuff;
}
function2()
{
call function1;
}
The struct acts as your IAT and data section, the calls and jumps are relative so you dont need to do any fixes. After you injected a thread into your target you do the same as in manual mapping, you fill the function pointers with the addresses you got from GetProcAddress or by manualy searching the EAT.
I have no idea about that specific blocker, however most of them just use PNP exploit and similiar, meaning they dont block VAC from creating & running, just blocks its communication & scanning.
NtQueryVirualMemory, which is what "VirtualQuery" calls is an NT function that VAC2 calls, even with hiding from usermode,
there is a possibility VAC2 can detect a usermode "hidden" module, by checking if the "MEMORY_BASIC_INFORMATION::Type" flag is set to "MEM_IMAGE" or something like that.
Yes VAC:2 walks all pages of memory with VirtualQueryEx looking for pages marked MEM_IMAGE and comparing them against loaded modules. If it finds a mismatch they call GetMappedFileName which detects unlinked modules.
Quote:
This "MEMORY_BASIC_INFORMATION" is pulled from the Kernel level, you can not hide from this if your module is loaded with LoadLibraryA _AT ALL_ from your userland module.
That's right. However one way is to map above 4 gb boundary which requires a 64 bit OS.
Quote:
Manual Mapping will save you, which is why i have been working on it recently, but your memory image will possibly still return "MEM_MAPPED" and may even be detected from there!
Yes manually mapping will save you but on the second portion you're wrong.
Quote:
Kernel hooking or hooking NT functions on Steam.exe may save you, however, the hooking of NT functions (EAT, IAT, Detour) may be checked, and if you are going to make a kernel hook you might as well just make the entire thing kernel based
VAC:2 checks it's "IAT" for hooks and checks their scan code with a checksum after it's been decoded.
Quote:
Originally Posted by KumaT
@s0beit
doing manual mapping is a lot of work to get everything right, from my personal experience its simpler to avoid the usage of a dll.
I'm sure you know the CreateRemoteThread & WriteProcessMemory thechnique to inject code into a target process. Simply allocate memory for your functions, copy the code to the heap do the fixes for calls and jumps. (like you would do in manual mapping) If you wan't to avoid doing the fixups use function pointers and do relative addressing.
Its a pretty unusual method in gamehacking but there is a lot of information about it related with exploits and rootkits.
But please don't pm until you have read all of that...why? Because Im reading it too...and I am very slow at reading.
