@0xrepnz said:
I did not say that using any undocumented API is wrong… It’s always a trade-off that you need to think about. If there’s a benefit to using the undocumented API, You have to “evaluate the risk” and decide if it’s worth it, as Peter said. Evaluating the risk can be very hard at times and requires YEARS of experience with windows kernel and knowledge about potential issues and edge cases. We just suggested that in this specific case it’s not worth it, You can read my previous comments to understand why it’s not worth it… In my opinion.
OK; we are jumping from one thing to another. Of course you have to evaluate risk, and of course you need years of experience, but it is well worth it for many reasons. The thread asked for signature checking in Kernel… so I have a potential solution. How is this solution taken is up to the OP.
@0xrepnz said:
1 - the “can be intercepted easily” argument is just plain incorrect. Moreover, even if it would be correct, why do you care?
2 - “hate Win32 API” - well, nobody “loves” it… but is it a reason to take the risk?
3 - “they are slow” - Design decisions that are based on “runtime performance” reasons, should be backed by tests. If you perform a test and
observe a performance overhead that is caused by a Win32 API (And, this issue is solved by switching to a undocumented API) this may be a good
reason to use this undocumented API, after evaluating the risk. Simply rejecting ALL the Win32 API because it’s “slow” is not a good reason in my
opinion - this is called “premature optimization”.
1 - you must be joking? “can be intercepted easily” = just put a detour on CreateFile in your current process when you read your license file, LOL.
2 - Yes. Many reasons, too many actually. I`m not going to start listing them, you need to do your own research and see why.
3 - All WinAPI’s are slow, tests have been done, and this is a fact. It is much faster to just call Nt* functions directly from ntdll.dll than using for example Kernel32.dll functions. I won’t go into system calls, which are just amazing in performance and security.
The reality is that Microsoft had to create another layer of functions which are easy to use for newbie developers. I just do not see another reason as these are not cross platform, and they call the same functions from ntdll.dll for decades, and still will.
Example:
HANDLE hFile = CreateFileW(L"banana.txt", GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL);
Much easier than:
HANDLE hFile;
static WCHAR const String [] = L"banana.txt";
static UNICODE_STRING const UnicodeString = RTL_CONSTANT_STRING (String);
OBJECT_ATTRIBUTES obj{};
InitializeObjectAttributes(&obj, &str, OBJ_CASE_INSENSITIVE, NULL, NULL);
IO_STATUS_BLOCK isb{};
NTSTATUS status = NtCreateFile(&hFile, FILE_GENERIC_WRITE, &obj, &isb, 0, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_WRITE, FILE_OPEN_IF, FILE_RANDOM_ACCESS|FILE_NON_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0);
Ya dig?
@0xrepnz said:
This was already reverse engineered: https://github.com/Ido-Moshe-Github/CiDllDemo
The time spent on reverse engineering these functions is not a consideration… Reverse engineering is something you do once, compare it to supporting millions of customer > machines for years and having complicated code in your product.
Glad you Googled and started to understand “hidden” functions used by Microsoft in your Windows for years. However regarding reversing, it is well worth it if you cannot achieve your goal another way? Also, you know that you can create a pattern and find the same function in next releases right?
@0xrepnz said:
Why are you so sure about it? MSFT already changed this specific function in the past, so how can you be sure?
Because I tested? I`m not running my mouth for no reason, I made tests from Win 7 to Win 10. For me it worked completely fine, and I have been only using official images.
@0xrepnz said:
Also, it’s not only whether “it’s going to change or not” - there are caveats to using undocumented APIs… The simplest example is using APC - How are you handling the unload of your driver safely? Are you aware of the synchronization and locking issues?
OK, APC. Perhaps open IDA and see how the function works before making assumptions? From what I saw you just Googled about this and found a repo about it, so how can you be so sure about APC? Regardless, if it doesn’t fit in your “bucket”, just use it in a different matter? Be creative? I mean.
Anyway, I came here with good intentions to help the OP; I`m not going to argue about what’s wrong and what’s good; I will leave that for someone else 
