Timeline for Are jump instructions targeting addresses in ntdll a sign of malware?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2014 at 15:51 | comment | added | peter ferrie | @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). | |
| Apr 27, 2014 at 19:53 | vote | accept | avgvstvs | ||
| Apr 20, 2014 at 22:30 | comment | added | avgvstvs |
@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.
|
|
| Apr 20, 2014 at 22:10 | comment | added | avgvstvs |
@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?
|
|
| Apr 20, 2014 at 14:02 | comment | added | Jason Geffner |
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.
|
|
| Apr 20, 2014 at 4:37 | history | answered | peter ferrie | CC BY-SA 3.0 |