1

For fun I downloaded an installer from a "driver downloads" website. I do NOT intend on installing it, but I was interested to check it out just to see what it looked like. I tossed it into Ollydbg (without advancing the pointer) and just browsed the assembly.

There are multiple different calls/jumps/far jumps to various ntdll.addr.

I know ntdll is a pretty low-level library, but I just don't have enough experience in windows x86 disassembly to know what's 'normal'. This is also ostensibly, a driver installer, so it seems reasonable that there would be calls into ntdll. Are jumps like that considered normal behavior? Usually I'm used to seeing calls that expressly name the function... not a specific address in ntdll.

Extra detail/context

The file wasn't packed, but there were a few spots where the full printable ASCII [A-Za-z] appeared in the hex view, which I recall could be a sign that there's base64 encoding/decoding going on somewhere. Maybe shift-ciphers.

For reference, the precise binary I'm peering into is here. Windows 7 64bits. (The installer itself appears to be 32bits... Ollydbg loaded it fine, and IDA free too.)

PEBrowse64 also showed me something possibly suspicious under Resources->STRING->4085.

In this section there appears to be strings set aside for Pageup/Down/Backspace/Esc/Enter keys, which I know could be a sign of a keylogger... but again, I'm new, so I'm unsure.

3

There is a legitimate situation where this can occur, which is called "import forwarding". That is, a DLL (such as kernel32.dll) might export a symbol, for which the implementation is held in another DLL (such as ntdll.dll). A typical example of that is the heap allocation functions: HeapAlloc and HeapFree. If you examine kernel32.dll, you will see that they are redirected to ntdll.RtlAllocateHeap and ntdll.RtlFreeHeap. The reason for this is behavior is probably not particularly interesting (it's to do with maintaining compatibility).

That is not to say that all such cases of direct calls into ntdll.dll are legitimate, but it might explain what you are seeing.

  • In addition to what Peter said, sometimes programs need to use functionality that is exposed by ntdll but not exposed by higher level libraries. For example, if a user-mode application wants to call RtlDecompressBuffer(), it needs to call the function in ntdll directly; there's no higher-level version exposed by Windows. – Jason Geffner Apr 20 '14 at 14:02
  • @Jason, would that result in ollydbg reporting ntdll.addr instead of ntdll.RtlDecompressBuffer? I would think that if the fxn was deliberately exposed by ntdll its public and I should be seeing the fxn name--unless this name can be changed by the loader at runtime? – avgvstvs Apr 20 '14 at 22:10
  • @Jason, Yikes... nm. I think I see what's going on, but why on earth make functions in ntdll private, if its possible to load them anyway with GetProcAddress? Seems counter-intuitive to hiding implementations. – avgvstvs Apr 20 '14 at 22:30
  • @avgvstvs, they're not private if they're exported. They are simply platform-specific. Before everything was based on Windows NT, Windows 95 (for example) could not do everything that NT could do, so functionality was not exposed at a lower level (i.e. in kernel32.dll). – peter ferrie May 13 '14 at 15:51

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.