4 ms·
Kernel32.dll is loaded into all Windows processes by default, so you actually can have a valid, working Windows binary with 0 entries in the import table. See h
by rfl890 11mo ago
Kernel32.dll is loaded into all Windows processes by default, so you actually can have a valid, working Windows binary with 0 entries in the import table. See here[1] for a "Hello world" program written as such.
[1]: https://gist.github.com/rfl890/195307136c7216cf243f7594832f4bfc https://gist.github.com/rfl890/195307136c7216cf243f7594832f4...
- matheusmoreira 11mo agoThat's interesting. How does it work? PEB *peb = (PEB *)__readgsqword(0x60); LIST_ENTRY *current_entry = peb->Ldr->InMemoryOrderModuleList.Flink->Flink; It just obtains a pointer to the loader's data structures out of nowhere? Is this actually supported by Microsoft or are people going to end up in a Raymond Chen article if they use this?
- rfl890 11mo agoIt's in no way supported by Microsoft (and is flagged by most anti-viruses), it was just to demonstrate that kernel32.dll is available for "free" in all programs. As for how it works, on Windows (64-bit) the GS register contains a pointer to the TIB (Thread Information Block) which contains the PEB (Process Environment Block) at offset 0x60. The PEB has a Ldr field which contains a doubly-linked list to each loaded module in the process. From here I obtain the requested module's base address (here kernel32.dll), parse the PE headers to find the function's address and return it.
- matheusmoreira 11mo agoThat's actually amazing. Similar to the way Linux's vDSO is used. I'm disappointed that it's not supported and regarded as suspicious...