Quote Originally Posted by -InSaNe- View Post
I'd much rather do syscalls directly instead of calling wrappers which are most of the time hooked by Anti-Cheats. If you look at the exported Nt_____ functions on ntdll.dll it should be pretty obvious what you should do.

Example: Instead of calling VirtualAlloc(Ex) you can do this and call it instead:

Code:
__declspec( naked )
NTSTATUS NtAllocateVirtualMemory( HANDLE ProcessHandle, PVOID *BaseAddress, ULONG ZeroBits, PULONG AllocationSize, ULONG AllocationType, ULONG Protect ) {
    __asm
    {
        MOV EAX, 0x17;
        CALL fs : [0xC0];
        RETN 0x18;
    }
}


//somewhere...
if( NT_ERROR( NtAllocateVirtualMemory( 
            GetCurrentProcess(), 
            &m_pBuffer, 
            NULL,
            &dwSize,
            MEM_COMMIT | MEM_RESERVE,
            PAGE_READWRITE ) ) ) {
    throw Exceptions::MemoryAllocationException( "Unable to alocate memory for the image" );
}
System calls are a wide field in Windows programming.

Points:

- Call IDs are specific to the computers they're running on ( Meaning you can't just use static numbers )
- x86 processes use the callgate to enter lower rings which can also be hooked ( mov fs:[c0h], mystub ) -- meaning you'll need to directly find the Cpup function that switches to x64 mode and emulate that directly or risk a hook being placed there and detecting you anyway
- On x64 systems, KiFastSystemCall is used directly ( Which can also be hooked ). To emulate it directly, you'll need to do all sort of annoying-ass calculations like determining the stack size needed to pop back to etc.
- Lastly, calling conventions for system calls differ across OSs. Windows 7 and Windows 8/8.1 differ for sure since I did do research on them.

So, yes system calls are a great way to prevent detections against applications that don't employ drivers but there's far too many variables to consider. At best, you'll only be able to make them for your PC since porting will be hell.