7

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.

Improve this question
1
  • 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, 2013 at 11:50

4 Answers 4

Reset to default
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.

Improve this answer
2
  • 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, 2013 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, 2013 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.

Improve this answer
5
  • 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, 2013 at 6:25
  • @ph0sec yep, the windows loader always loads in kernel32.dll as well, and always at the same address.
    – Avery3R
    May 25, 2013 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, 2013 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, 2013 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, 2013 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).

Improve this answer
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.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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