@0xrepnz said:
You can check for signed binaries in Kernel, Windows does it
The discussion here is not about whether it’s possible or not, in kernel mode almost everything is possible but is it the right design choice?
Everyone here simply mentioned it’s not supported, and not worth the effort required to maintain this piece of code… Supporting code that uses undocumented structures + functions that often change is not as simple as “making it work in a test environment”. The signature of this function (CiCheckSignedFile) was changed multiple times, so if you use it you have to adjust your code to the OS version and also keep testing your product against insider builds to make sure the function is not changed so you don’t cause BSODs…
I disagree, by “supported” I`m sure you mean if Microsoft creates documentation and says “we support this”, then it’s “supported”? That’s not how I see it, at all.
There are literally a dozen functions inside NT that haven’t changed (much) since XP, and people still use them. In fact, is it more often better to use “undocumented” functions/functionality for several reasons.
Example: https://social.msdn.microsoft.com/Forums/vstudio/en-US/a084abc6-60c7-476e-92c6-5930856ca70d/win32-getversionex-returns-wrong-informatiion?forum=vcgeneral
Instead of using the “documented” GetVersion(), it is better to use RtlGetVersion() + RtlGetNtVersionNumbers(). No “manifest” needed, no bonanza.
Another example, I use only undocumented functions and system calls in my real life applications; and they are being used by hundreds of users. I simply hate Win32 API, they are slow, can be intercepted easily, etc.
So I really disagree with this “not supported” bonanza, we are 2 decades away from functions listed as “deprecated” on Microsoft website but they are still there, they still work, and that’s that.
As for the ci.dll, the only issue is that Microsoft did not post any documentation about this, hence why people say “not supported”. One developer can simply open ci.dll in IDA and the .pdb is available from Microsoft; making reversing / exporting of these functions quite easy.
Once you created your import .libs, they won’t change. There are many Windows editions released that heavily rely on these functions and Microsoft 100% will not re-invent the wheel and change them.
You can reliably use “undocumented” functions (up to point), but of course you need to understand what you are doing.
@brad_H said:
@Mecanik said:
I am really not going to comment on stuff here, because there would be too much to say.
The least I will say @brad_H is that you are very wrong with many things, especially ObCallbacks and virtualization like VMProtect.
To answer your question:
- You can check for signed binaries in Kernel, Windows does it, always had since VISTA. Look at ci.dll exported function CiCheckSignedFile, it will do everything you want.
- You cannot “secure” IOCTL’s with this, find another method of communication, like shared mapping. Or even simpler, encrypt your data both ways.
To give you a hand, do note that ci.dll has changed a lot until Windows 10 and there is no documentation for this. You have to manually reverse the structs and function parameters, generate the .lib file and link against your driver.
dumpbin /EXPORTS c:\windows\system32\ci.dll
lib /def:ci.def /machine:x64 /out:ci.lib
Enjoy.
Doing this using the ci.dll is a very risky way of doing it considering most of it is undocumented and the structures change vastly from time to time, its basically not a possible solution for a product.
Everything is “risky”, even “documented” functionality. That’s not the point, and that doesn’t stop you from using something that’s already there.
In this case, ci.dll has not changed that much besides new functions being added; structures seem the same since Win 7 (tested) tp Win 10 (tested).