NtCall - A stable workaround for hooked APIs

This can easily be adapted by looking up the Indexes of other functions.
If you see something that can be improved let me know.

Code:

#include <Windows.h>
#include <stdio.h>

LONG __declspec(naked) NtCall(DWORD FunctionIndex,DWORD ClassIndex,...)
{
	__asm
	{
		push ebp
		mov ebp,esp
		mov eax,FunctionIndex
		mov ecx,ClassIndex
		lea edx,[ebp+0x10]
		call fs:[0xC0]
		add esp,0x4
		leave
		retn
	}
}

#define NtTerminateProcess(ProcessHandle,ExitStatus) NtCall(0x29,0x0,ProcessHandle,ExitStatus)
#define NtUserSendInput(nInputs,pInput,cbSize) NtCall(0x1082,0x0,nInputs,pInput,cbSize)
#define NtDeleteFile(ObjectAttributes) NtCall(0x0B2,0x0,ObjectAttributes)
#define NtReadVirtualMemory(ProcessHandle,BaseAddress,Buffer,NumberOfBytesToRead,NumberOfBytesRead) NtCall(0x3C,0x0,ProcessHandle,BaseAddress,Buffer,NumberOfBytesToRead,NumberOfBytesRead)
#define NtWriteVirtualMemory(ProcessHandle,BaseAddress,Buffer,NumberOfBytesToWrite,NumberOfBytesWritten) NtCall(0x37,0x0,ProcessHandle,BaseAddress,Buffer,NumberOfBytesToWrite,NumberOfBytesWritten)
#define NtOpenProcess(ProcessHandle,DesiredAccess,ObjectAttributes,ClientId) NtCall(0x23,0x0,ProcessHandle,DesiredAccess,ObjectAttributes,ClientId)
#define NtClose(Handle) NtCall(0x0C,0x0,Handle)
#define NtWaitForSingleObject(ObjectHandle,Alertable,TimeOut) NtCall(0x1,0x0D,ObjectHandle,Alertable,TimeOut)
#define NtDelayExecution(Alertable,DelayInterval) NtCall(0x31,0x6,Alertable,DelayInterval)
#define NtProtectVirtualMemory(ProcessHandle,BaseAddress,NumberOfBytesToProtect,NewAccessProtection,OldAccessProtection) NtCall(0x4D,0x0,ProcessHandle,BaseAddress,NumberOfBytesToProtect,NewAccessProtection,OldAccessProtection)
#define NtAllocateVirtualMemory(ProcessHandle,BaseAddress,ZeroBits,RegionSize,AllocationType,ProtectionType) NtCall(0x15,0x0,ProcessHandle,BaseAddress,ZeroBits,RegionSize,AllocationType,ProtectionType)
#define NtFreeVirtualMemory(ProcessHandle,BaseAddress,RegionSize,FreeType) NtCall(0x1B,0x0,ProcessHandle,BaseAddress,RegionSize,FreeType)

// Using NtTerminateProcess for an example
int main()
{
	printf("Terminating self in one second\n");
	Sleep(1000);
	NtTerminateProcess(GetCurrentProcess(),-1);
	printf("You should never see this message\n");
	getchar();
}

Seems nice. I might be using them.

If they have the function checked, this won't make a difference & it would be slower than calling the ring3 function because of the indirection... & tbh this looks copy and pasted, you're not subtracting 4 from the stack but you're adding 4, you have a leave command in there but there is no enter, you have a return near command but not the size of the parameters... this just is not a viable option to be honest.

Originally Posted by ~FALLEN~

If they have the function checked, this won't make a difference & it would be slower than calling the ring3 function because of the indirection... & tbh this looks copy and pasted, you're not subtracting 4 from the stack but you're adding 4, you have a leave command in there but there is no enter, you have a return near command but not the size of the parameters... this just is not a viable option to be honest.

Do you even know assembly? Not trying to hate, but it seems like you have no idea what you're talking about.

Originally Posted by CyanideC00kies

Do you even know assembly? Not trying to hate, but seems like you have no idea what you're talking about.

Yes I do, I can write in x86 asm, read it, read binary, write binary, write code in binary, speak in binary, etc, can you? if there is a local variable you subtract from the stack, add at cleanup, if you're talking about the FS register call the nt functions should be standard calls ( __stdcall ) which means that the function itself should do the stack cleanup, not you. You have function parameters, the ret at the bottom should be ret ( 4 times number of parameters here ) as it is the size of params, seeing as a param is a pointer, that's why its 4 * number of params.. Like I said I've been coding for over 6 years, if you want to get into a pissing match then so be it, just know you will lose.

this will work only on 64 bit.. since "fs:[C0]" is a pointer to a wow64 function that will convert 32bit system calls to 64 bits system calls.

^this /too short

Originally Posted by akinator

this will work only on 64 bit.. since "fs:[C0]" is a pointer to a wow64 function that will convert 32bit system calls to 64 bits system calls.

Thanks for pointing that out.

Originally Posted by ~FALLEN~

^this /too short

LOL FALLEN, stop acting like you actually knew that. Your explanation was completely wrong.

Originally Posted by CyanideC00kies

Thanks for pointing that out.

LOL FALLEN, stop acting like you actually knew that. Your explanation was completely wrong.

No it wasn't, 0xC0 is reserved for wow32 if you were to look into the thread information block, process environment block, heap, etc, you would know that.
Better way to do this:

make a class filled with pointers to typedefed nt functions. ex
get module from peb -> search module exports from nt header -> fill class with exports.
It's stealthy and it's a faster, and much more reliable option than this. If you're talking about syscalls then there is much better alternatives than this...
come at me?

Originally Posted by ~FALLEN~

No it wasn't, 0xC0 is reserved for wow32 if you were to look into the thread information block, process environment block, heap, etc, you would know that.
Better way to do this:

make a class filled with pointers to typedefed nt functions. ex
get module from peb -> search module exports from nt header -> fill class with exports.
It's stealthy and it's a faster, and much more reliable option than this. If you're talking about syscalls then there is much better alternatives than this...
come at me?

this way would work only if the exports are getting patched.
if they use a normal hook this would be pointless.

Originally Posted by akinator

this way would work only if the exports are getting patched.
if they use a normal hook this would be pointless.

No you're wrong, you're not understanding the point of the post. Let me explain, assuming this is a syscall wrapper ( which is what it looks like ) a much better alternative would be to fill out a list of syscall numbers and get the os version out of the PEB check the service pack, etc & then use the syscalls based off that. If it wasn't such, he could get module from peb, search exports then wrap them. But to be completely honest it would be more viable to use a driver and just unhook their hooks as anticheat drivers start alongside the anticheat which starts alongside the game. ( If this is the route you want to go that is, like I said there is really no true need for this )

Stop bickering and work together. Instead of acting like douches, you should help each other.

im kinda enjoying it

it seems to be "there way of working it out" the way they know how the old fashioned pissing contest and dang i sure do enjoy the read!!!

Originally Posted by HOOSIER

im kinda enjoying it

it seems to be "there way of working it out" the way they know how the old fashioned pissing contest and dang i sure do enjoy the read!!!

lol yeah, that's actually how most coders get to know each other believe it or not. Someone says something, someone else gives input, person a cant take criticism and yells at person b, person b goes off like yo i gotz a bigger e-penor than youz. Then eventually they contact outside of the place of the argument and get to know one another. That's how i met raiders LOL

Not trying to be mean, but if you guys don't understand what this is doing then you should take a break from MPGH for a bit, and learn some assembly before looking into this hook. Or ask CyanideC00kies, to kindly mark up the source.

NtCall - A stable workaround for hooked APIs

Post a Reply

Similar Threads

Tags for this Thread