calling kernel32.dll function without including windows.h

if kernel32.dll is guaranteed to loaded into a process virtual memory,why couldn't i call function such as Sleep without including windows.h? the below is an excerpt quoting from vividmachine.com

5. So, what about windows? How do I find the addresses of my needed DLL functions? Don't these addresses change with every service pack upgrade?

There are multitudes of ways to find the addresses of the functions that you need to use in your shellcode. There are two methods for addressing functions; you can find the desired function at runtime or use hard coded addresses. This tutorial will mostly discuss the hard coded method. The only DLL that is guaranteed to be mapped into the shellcode's address space is kernel32.dll. This DLL will hold LoadLibrary and GetProcAddress, the two functions needed to obtain any functions add开发者_JS百科ress that can be mapped into the exploits process space. There is a problem with this method though, the address offsets will change with every new release of Windows (service packs, patches etc.). So, if you use this method your shellcode will ONLY work for a specific version of Windows. Further dynamic addressing will be referenced at the end of the paper in the Further Reading section.

---

The article you quoted focuses on getting the address of the function. You still need the function prototype of the function (which doesn't change across versions), in order to generate the code for calling the function - with appropriate handling of input and output arguments, register values, and stack.

The windows.h header provides the function prototype that you wish to call to the C/C++ compiler, so that the code for calling the function (the passing of arguments via register or stack, and getting the function's return value) can be generated.

After knowing the function prototype by reading windows.h, a skillful assembly programmer may also be able to write the assembly code to call the Sleep function. Together with the function's address, these are all you need to make the function call.

---

With some black magic you can ;). there have been many custom implementations of GetProcAddress, which would allow you to get away with not needing windows.h, this however isn't be all and end all and could probably end up with problems due to internal windows changes. Another method is using toolhlp to enumerate the modules in the process to get kernel.dll's base, then spelunks its PE for the EAT and grab the address of GetProcAddress. from there you just need function pointer prototypes to call the addresses correctly(and any structure defs needed), which isn't too hard meerly labour intensive(if you have many functions), infact under windows xp this is required to disable DEP due to service pack differencing, ofc you need windows.h as a reference to get this, you just don't need to include it.

---

You'd still need to declare the function in order to call it, and you'd need to link with kernel32.lib. The header file isn't anything magic, it's basically just a lot of function declarations.

---

I can do it with 1 line of assembly and then some helper functions to walk the PEB file by hard coding the correct offsets to different members.

You'll have to start here:

static void* 
JMIM_ASM_GetBaseAddr_PEB_x64()
{
    void* base_address = 0;
    unsigned long long var_out = 0;

    __asm__(
        " movq %%gs:0x60, %[sym_out]  ; \n\t"
        :[sym_out] "=r"  (var_out) //:OUTPUTS
    );

    //: printf("[var_out]:%d\n", (int)var_out);

    base_address=(void*)var_out;
    return( base_address );
}

Then use windbg on an executable file to inspect the data structures on your machine. A lot of the values you'll be needing are hard to find and only really documented by random hackers. You'll find yourself on a lot of malware writing sites digging for answers.

dt nt!_PEB -r @$peb

Was pretty useful in windbg to get information on the PEB file.

There is a full working implementation of this in my game engine. Just look in: /DEP/PEB2020 for the code.

https://github.com/KanjiCoder/AAC2020

I don't include <windows.h> in my game engine. Yet I use "GetProcAddress" and "LoadLibraryA". Might be in-advisable to do this. But my thought was the more moving parts, the more that can go wrong. So figured I'd take the "#define WIN32_LEAN_AND_MEAN" to it's absurd conclusion and not include <windows.h> at all.