2

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.

Improve this question

1 Answer 1

Reset to default
4

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.

Improve this answer
4
  • 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
    Commented Apr 20, 2014 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
    Commented Apr 20, 2014 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
    Commented Apr 20, 2014 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
    Commented May 13, 2014 at 15:51

Your Answer

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

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