0

On windows, some system library are always loaded by OS (see Are Win32 applications automatically linked against ntdll.dll?); thus, one should be able to get its base address in PEB.

Hence I am wondering that if it is possible to do something like creating a window with only system calls or Native APIs on windows.

Many thanks.

imakak
  • 113
  • 6
  • It is not. What is the point of this? – Michael Chourdakis Jun 04 '19 at 04:42
  • Well obviously you *can* do it by making the same system calls that the normal DLLs make. The problem with system calls is that there is no stable API / ABI for raw system calls with `syscall`. People have reverse-engineers system-call numbers for various Windows versions, in case you want to mess around with it for local use only. https://j00ru.vexillium.org/syscalls/nt/64/. Presumably most of the normal DLL API functions are thin wrappers around those, but there's no guarantee of that. – Peter Cordes Jun 04 '19 at 04:42
  • 2
    No he cant. A win32 call does not *only* involve system calls, it also does a lot at the user level. He would have to reimplement the whole DLL. – Michael Chourdakis Jun 04 '19 at 04:44
  • 1
    @MichaelChourdakis: Ah, good point. Obviously it's *theoretically* possible to write a program that does the necessary calculations to figure out what args to pass to the system calls. Or blindly hard-codes some working values for a specific window size and so on, that you got from tracing the system calls made by a normal executable. I'm definitely *not* claiming this is useful or a good idea! – Peter Cordes Jun 04 '19 at 04:48
  • Thanks for the quick replies. So do we have any idea about how user32.dll achieve this? – imakak Jun 04 '19 at 04:53
  • 3
    The Win32 API is the native API for user interface elements like windows. – Ross Ridge Jun 04 '19 at 07:09
  • 1
    @imakak see https://doxygen.reactos.org/db/d26/win32ss_2user_2user32_2windows_2window_8c.html#afe583f20e38b281c34a091de847db948 for approximation of what the User32.dll does – xmojmr Jun 04 '19 at 07:22
  • Can you elaborate on the term "Native APIs"? The API exposed by user32.dll are the native APIs. You can load user32.dll at runtime using only the PEB. That's what most malwares do (see for example the malware *FormBook* for an extreme case). AFAIK, handling of the UI is mostly done in user land. – Margaret Bloom Jun 04 '19 at 07:44
  • @Margaret Bloom By the term "native API" I meant the API exported by library loaded by default (for example, KernelBase.dll, Kernel32.dll, ntdll.dll in x64 program). I thought that if user interface was handled in user land on windows, then maybe it is possible to do something like create window without loading the user32.dll, which is not loaded by default. – imakak Jun 04 '19 at 07:59
  • It is *mostly* done but not *entirely* done. So you get the worst possible situation: You are forced to use undocumented syscalls that expect preconditions and formats crafted by undocumented code in user32.dll. – Margaret Bloom Jun 04 '19 at 08:36
  • @Margaret Bloom So currently the best solution will be use LoadLibrary to load whole user32.dll (and all of its dependency, e.g. win32u.dll) in to memory then use API inside it, like what https://www.tophertimzen.com/blog/windowsx64Shellcode/ did? – imakak Jun 04 '19 at 08:59
  • Unless you have a specific reason not to, I'd go with loading user32.dll. If you are concerned with memory usage, I expect Windows to be able to COW user32.dll (though RW data is not shared). If you don't want to trigger any alarm/breakpoint you can map your own copy of user32.dll like [LockPoS does](https://www.cyberbit.com/blog/endpoint-security/new-lockpos-malware-injection-technique/). Possibly adding your reasons will help you get a better answer. – Margaret Bloom Jun 04 '19 at 09:16
  • Thanks for the reply. I would like to avoid loading user32.dll because I would only make use of a little part of it. Because I am not familiar with Windows kernel, I posted this question for seeking a better approach rather than load whole dll. But in case there exist no better solution, maybe I will just simply load user32.dll then. – imakak Jun 04 '19 at 09:28

0 Answers0