Hacker News Reader

Comment by rocqua | Hacker News Reader

How does that work with regards to privilege separation. It sounds like bypassing nt.dll might be an exploit vector that is easily forgotten.

View on HN

All of the verification is done on the kernel side of the boundary, all entrance points to the kernel via syscalls are marked using static code analysis so that the kernel never trusts a pointer provided from user-mode, so even if you sysenter yourself, you can't do anything Special

Permission checks are still done in the kernel.

>It sounds like bypassing nt.dll might be an exploit vector that is easily forgotten.

MSFT might be bad, but not that bad.

Just a note, it's not nt.dll, it's ntdll.dll.

Heh, interesting. Any specific reason for the stuttering? Or just arbitrary inconsistent historical decision?

Not sure! My guess is the name would've just felt too short otherwise.

I'll give you a better one. On a 64 bit Windows:

- the 64 bit binaries are stored in C:\Windows\System32

- the 32 bit binaries are stored in C:\Windows\SysWOW64

Haha, I think WOW64 means "Windows [32] on Windows 64" which kind of makes sense if you squint at it just right...

That's a bingo.

I'm guessing it's because module names are sometimes used without the extension and "ntdll" looks better in such a list than "nt".

I think it’s because the kernel’s module name is “nt”. It’ll show up like that in stack traces on occasion.

Reply on news.ycombinator.com