Windows 11 emulation issue and possible fix

[uintmax]

Problem

On Windows 11, the dev branch currently fails to emulate PE binaries compiled with MSVC. It makes a call to abort() before reaching the program's main function.
The master branch does not have this problem yet, because a change has only been made recently. This commit improved Windows emulation by executing the _initterm_e export of ucrtbase.dll. Unfortunately, Windows 11 made some breaking changes in ucrtbase.dll, which causes the early program termination now.

Fix

This problem can be easily fixed by adding kernel32.dll to the key_dlls tuple.

Reason:
_initterm_e gets supplied a pointer to a function which eventually checks for a FLS index stored in the .data section. This however fails, because FlsAlloc has never been called for this index. The main function of ucrtbase.dll would usually make this call to FlsAlloc. However, we never reach that call, because ucrtbase.dll bails out early. This is due to a call to VerifyVersionInfoW, which can not be resolved, because it gets imported via the virtual DLL api-ms-win-core-kernel32-legacy-l1-1-1.dll. The key_dlls tuple responsible for resolving these kinds of imports does not include kernel32.dll yet. This results in the existing hook also not to be called.

Adding kernel32.dll to the key_dlls before kernelbase.dll and ntdll.dll would fix the problem. All Windows and PE tests would work correctly again.
I am however not sure if that's the best solution, considering that just one import needs kernel32.dll for now. On the other hand it may make it more future-proof.

[elicn]

Thanks for the detailed analysis! That for sure saved me a few hours of debugging.
This change indeed solves two failing cases, but we have another one (sality) that keeps failing.

If you are curious, this is how it looks when it fails after jumping [returning, most likely] to the wrong address:

[=] 	 >>>> Second stop address: 0x004055fa
[+] 	0x107fcc30: KeWaitForSingleObject(Object = 0x10dd0, WaitReason = 0, WaitMode = 0, Alertable = 0, Timeout = 0) = 0x0
[+] 	0x1078b070: KeResetEvent(Event = 0x10dd0, Increment = 0xffffcfac, Wait = 0x103cf284) = 0x0
[+] 	0x10eb8590: PsTerminateSystemThread(ExitStatus = 0) = 0x0
[x] 	CPU Context:
...
[x] 	PC = 0xffffcfee

However, when I run it locally it works just fine.
That is what its log shows when I run it locally and turn on trace:
(note the differences between the two runs in KeResetEvent args)

[=]      >>>> Second stop address: 0x004055fa
[+]     000102d0 | 55                       push       ebp                                                      | esp = 0xffffcfd0, ebp = 0xffffcff4
[+]     000102d1 | 8bec                     mov        ebp, esp                                                 | esp = 0xffffcfcc
[+]     000102d3 | 83ec10                   sub        esp, 0x10                                                | esp = 0xffffcfcc
[+]     000102d6 | c745fc00000000           mov        dword ptr [0xffffcfc8], 0x0                              | ebp = 0xffffcfcc
[+]     000102dd | c745f800000000           mov        dword ptr [0xffffcfc4], 0x0                              | ebp = 0xffffcfcc
[+]     000102e4 | 6a00                     push       0x0                                                      | esp = 0xffffcfbc
[+]     000102e6 | 6a00                     push       0x0                                                      | esp = 0xffffcfb8
[+]     000102e8 | 6a00                     push       0x0                                                      | esp = 0xffffcfb4
[+]     000102ea | 6a00                     push       0x0                                                      | esp = 0xffffcfb0
[+]     000102ec | 68d00d0100               push       0x10dd0                                                  | esp = 0xffffcfac
[+]     000102f1 | ff151c0b0100             call       dword ptr [0x10b1c]                                      | esp = 0xffffcfa8
[+]     0x105ab510: KeWaitForSingleObject(Object = 0x10dd0, WaitReason = 0, WaitMode = 0, Alertable = 0, Timeout = 0) = 0x0
[+]     105ab510 | 44                       inc        esp                                                      | esp = 0xffffcfbc
[+]     000102f7 | 68d00d0100               push       0x10dd0                                                  | esp = 0xffffcfbc
[+]     000102fc | ff15180b0100             call       dword ptr [0x10b18]                                      | esp = 0xffffcfb8
[+]     0x106c09e0: KeResetEvent(Event = 0x10dd0, Increment = 0, Wait = 0x455874f0) = 0x0
[+]     106c09e0 | 48                       dec        eax                                                      | eax = 0x0
[+]     00010302 | 833db80d010000           cmp        dword ptr [0x10db8], 0x0                                 |
[+]     00010309 | 7505                     jne        0x10310                                                  | eflags = 0x46
[+]     0001030b | e915010000               jmp        0x10425                                                  |
[+]     00010425 | 6a00                     push       0x0                                                      | esp = 0xffffcfc4
[+]     00010427 | ff150c0b0100             call       dword ptr [0x10b0c]                                      | esp = 0xffffcfc0
[+]     0x10a16250: PsTerminateSystemThread(ExitStatus = 0) = 0x0
[+]     10a16250 | 48                       dec        eax                                                      | eax = 0x0
[+]     0001042d | 8be5                     mov        esp, ebp                                                 | ebp = 0xffffcfcc
[+]     0001042f | 5d                       pop        ebp                                                      | esp = 0xffffcfcc
[+]     00010430 | 90                       nop                                                                 |
[=]      >>>> Third stop address: 0x00010430

[elicn]

Thanks again!

[uintmax]

@elicn you're right, I completely missed the Windows driver tests. I'm glad that you already got it fixed as I am not really familiar with Windows drivers.

While running these tests on my machine, I came across another problem. The driver tests do not seem to work on Python version 3.13.

The problem seems to be related to this issue: #1582
I will dump my findings there.

[elicn]

Well, I did not fix it really but just worked around it by letting it exit slightly earlier. I believe something was wrong with the return address, or maybe the emulation took a different turn. The problem that is works locally, but it fails on Github Actions.

[uintmax]

@elicn I took a look at the driver test and I think I found multiple issues that caused this behaviour and other unexpected behaviour mentioned in the comment of the test.

1. KeResetEvent's function signature is wrong in Qiling's hook.
   KeResetEvent expects one argument, but Qiling's hook includes three. The hook definition has probably been taken from the matching hook definition above, but not changed. Since the function has the stdcall calling convention, Qiling will pop 3 arguments resulting in a corrupted stack, because only 1 pop should have happened. This can be observed in the trace you have posted, ESP is wrongly increased by 12 bytes after the KeResetEvent call.

2. PsTerminateSystemThread does not return according to its documentation. Qiling's hook only returns 0 and the test goes on to the ret instruction afterwards. The original malware would have ended that thread's execution at the PsTerminateSystemThread call.

Although the first two issues corrupted the flow of the execution, this doesn't explain why the test ended up at the same address in the past and why the destination has now changed. The following two issues explain the new end address.

3. The old stop address (0x0001066a) relied on a return address, but the third execution starts directly at the beginning of the function it returns from. So no valid return address has been pushed on the stack (Screenshot of the decompilation).
   We do return to something, because the old stack is kept from the second execution. In the second execution the driver initialization fails at some point, which the test also expects. So the address we return to is some leftover stack value from the second execution.
   Because the ntoskrnl.exe version changed on the GitHub Actions runner and probably differs from your local rootfs there are different leftovers on the stack. This can be seen by comparing a new and an old log from the GitHub Actions runner. ESP has a different value/size after the expected crash of the second execution, meaning that we probably also get a different value when executing ret.
   ctrl+f on new: 2025-10-29T13:20:04.6583300Z [x] esp : 0xffffcfac
   ctrl+f on old: 2025-08-27T15:47:16.0811438Z [x] esp : 0xffffcfd0

4. The driver is x86, but the loaded ntoskrnl.exe is x64 (dllscollector.bat seems to put x64 ntoskrnl.exe in the x86 windows rootfs). This results in the wrong decoding of instructions by Unicorn which expects x86. RtlInitUnicodeString is marked as passthrough in Qiling and gets decoded wrongly in the second execution. This can be seen in the logs of the GitHub Actions runner.

2025-10-29T13:20:04.6617310Z [x] 	Disassembly:
2025-10-29T13:20:04.6625098Z [=] 	109634b7 [ntoskrnl.exe         + 0x4334b7]  c7 01 00 00 00 00    mov                  dword ptr [ecx], 0
2025-10-29T13:20:04.6625723Z [=] 	109634bd [ntoskrnl.exe         + 0x4334bd]  48                   dec                  eax
2025-10-29T13:20:04.6626870Z [=] 	109634be [ntoskrnl.exe         + 0x4334be]  8b d9                mov                  ebx, ecx
2025-10-29T13:20:04.6627725Z [=] 	109634c0 [ntoskrnl.exe         + 0x4334c0]  48                   dec                  eax
2025-10-29T13:20:04.6628601Z [=] 	109634c1 [ntoskrnl.exe         + 0x4334c1]  89 51 08             mov                  dword ptr [ecx + 8], edx
2025-10-29T13:20:04.6629479Z [=] 	109634c4 [ntoskrnl.exe         + 0x4334c4]  48                   dec                  eax
...

It should be:

48 c7 01 00 00 00 00    MOV qword ptr [RCX],0x0
48 8B D9    MOV RBX,RCX
...

Originally the test didn't want to return from the function, but end up at 0x10423.

I guess this location could already not be reached with the ntoskrnl.exe version at that time.
The malware retrieves the NtBuildNumber included in ntoskrnl.exe and compares it to a list of hard-coded build numbers. Depending on the build number it selects a different hard-coded offset, which is later used for a function call. If it does not find the build number in its list it just exits. That's why the given return address has probably been chosen as a temporary fix at that time.
I looked up the hash of the sality driver on VirusTotal and noticed that it was first uploaded in 2010. So ntoskrnl.exe versions released after ~2010, will probably just cause this function to terminate the thread.

I might have made some errors in my analysis, but I think in conclusion it shows why the test is failing.

[elicn]

Thanks again for taking the time to analyze this.
I can probably fix the issues you mention on bullets 1 and 2, but I am not sure where to go with this test because I have no prior knowledge of this malware. Also, I did notice that ntoslkrnl.exe is a 64-bit PE and it quickly fails due to invalid instruction decoding, but I am not sure what we can do with this. One way is to hook the call and replace with it our own implementation, but ideally we would strive to emulate the original program as much as we can.

[uintmax]

I thought about a fix for this too. I think your current fix is already as good as it can get and future-proof, so new ntoskrnl releases should not break the test anymore.