Page 1 of 1
Is hooking Native Api functions reliable?
Posted: Sat Apr 01, 2017 8:23 am
I want to hook some Native Api functions from ntdll.dll, more specifically NtCreateFile and NtWriteFile. However, according to MS Documentation
, the NT functions are subject to change from one release of Windows to the next, and possibly even between service packs for each release. This includes function signatures and even deletion of the functions. So, with this in mind, is it reliable to hook these functions as their signature may change? Does madCodeHook provide workaround for this? If no, is there some other workaround?
Re: Is hooking Native Api functions reliable?
Posted: Sat Apr 01, 2017 8:35 am
Most native functions have been around from NT4 up to Windows 10 without any change at all. There are some exceptions where a native function has changed in some way, but usually Microsoft just adds a new API instead of breaking an existing one. E.g. instead of breaking NtCreateThread() MS just added NtCreateThreadEx(). So I don't think you need to worry much about native APIs breaking/changing. Any API that has stayed identical from NT4 to Windows 10 is unlikely to break in the future.
That said, hooking the file system in user land comes with some limitations. The biggest problem is that memory mapped files don't run through any APIs in user land. So if a process calls CreateFile + CreateFileMapping + MapViewOfFile, at that point you lose access to the file read & write operations, because they're done by simply accessing RAM. In user land you cannot hook those read & write accesses. In driver land you can, by writing a little file system filter driver.