6

while reading the answers to Can I statically link (not import) the Windows system DLLs? I came up with another question. So:

  1. Is there a way to write a program that has no dependencies (nothing is statically compiled too - it has only my code) and everything is resolved during run-time assuming that kernel32.dll will be loaded/mapped into the process no matter what?
  2. Is my assumption about kernel32.dll correct?

During run-time, I mean using the PEB structure.

  • Keep in mind that the rules about kernel32.dll only apply to the NT platform. Not that I expect anyone to still use 9x/Me, but just in case ;) – 0xC0000022L May 28 '13 at 11:50
9

If you're asking about PE files, and by "no dependencies" you mean "no statically imported DLLs", then yes.

See \yoda\NoImports.exe in https://corkami.googlecode.com/files/BinaryCorpus_v2.zip as an example.

  • Thanks, this is nice and interesting solution and he indeed assumes that the stack has return address into somewhere in kernel32 space (which he explored here) and from there the way is "straightforward" :) – PhoeniX May 25 '13 at 6:45
  • 1
    the more common way these days to resolve the base address of kernel32.dll is to walk the InMemoryOrderModuleList list, since the DLL order hasn't changed even in Windows 7. Technically, you don't need to resolve anything but GetProcAddress(), if you have an export table, because you can use forwarded references to the DLLs of interest, and GetProcAddress() on your own exports will cause Windows to load the DLLs for you. – peter ferrie May 25 '13 at 15:52
3

This isn't a very portable trick, but kernel32.dll is always loaded at the same address when the executable is launched, that means LoadLibraryA and GetProcAddress are always at the same address. You could hard-code those offsets and go from there.

  • So, kernel32.dll will be always loaded into the processes event if the PE image does not reference it anywhere in the code? – PhoeniX May 25 '13 at 6:25
  • @ph0sec yep, the windows loader always loads in kernel32.dll as well, and always at the same address. – Avery3R May 25 '13 at 6:47
  • 1
    @MMavipc regarding the same address is not always right as in the Vista and Win 7 family, the ASLR was introduced to brake this assumption. – PhoeniX May 25 '13 at 6:53
  • 4
    @MMavipc that behavior was introduced in Windows XP, to avoid the crashing problem when a process did not import from kernel32.dll, and so it was not loaded explicitly.@ph0sec that's not exactly correct, either - ASLR applies only to the first time that kernel32.dll (and ntdll.dll, too) is loaded. After that, it is at a common address across all processes. – peter ferrie May 25 '13 at 15:41
  • 2
    @peter ferrie of cause as it is loaded only once and mapped to other processes after that. The thing I was referring here is that you cannot (should not) hard code the kernel32.dll base address into the executable itself. – PhoeniX May 25 '13 at 17:04
2

Yes, a program that has no dependencies is possible.

To imports APi, it needs first to locate kernel32 (via stack+MZ scanning, or PEB) then locate exports (via exports parsing or hard-coded values).

2

Yes.

  1. Find the address of kernel32 using anyone of the known tricks (PEB or any other way)
  2. Implement a simple export section parser and find the address of LoadLibrary and GetProcAddress.
  3. Use those to load any other API you want.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.