microwave89 / rtsectiontest Goto Github PK

If code is being injected into a few special Metro UI processes such as SearchUI.exe or similar ones, the attempt fails with status "STATUS_UNSUCCESSFUL" (0xC0000001).

The root cause of the problem is possibly a special suspend mechanism employed by the Metro style Windows versions (8 +) which suspend these processes in a matter such that they do not awake even if they are resumed manually. Process resume was attempted by either using Process Hacker or calling NtResumeProcess from within the parent injector process.
Process Hacker shows a suspend counter of 1 in every thread in the Metro UI process. This counter does not move if one attempts to resume the process or the selected thread.
The process cannot be resumed even if SystemEventsBroker service as well as Shell Infrastructure Host is suspended, therefore it is unlikely to get suspended in a fast, periodical manner (e.g. every 20 ms). Known "special"-suspended processes include the following: microsoftedge.exe, microsoftedgecp.exe, shellexperiencehost.exe and searchui.exe. In fact the suspend mechanism also causes youtube.com music play to stop if the Edge browser is being minimized (see google results for something like "microsoft edge stops music play").

The injection issue arises from the fact that the thread whose execution we triggered, and which is supposed to execute our hijack code, becomes "special"-suspended before he even "sees" a single user mode instruction. Hence, the thread cannot be hijacked, and since the hijacking location remains patched after the "patch success sensing" timeout occurs (NtDelayExecution) the injection is deemed unsuccessful and thus the pristine ntdll.dll function is restored.
Furthermore the worker thread counter is not being adjusted and so creation of further worker threads fails since there already exist the desired count of workers. If the process is once resumed by clicking on start button the new thread is being accounted for and the worker thread counter is adjusted accordingly.
Otherwise if a notepad.exe instance is being suspended and then an injection attempt is made it succeeds and remote code is executed. Here a minor problem occurs, namely the process is being suspended twice but the bootstrap code resumes only once. So only the injected code is being executed but not the whole process. A solution for that particular issue includes to query the suspend counter and resume the process until it has decreased to zero.

A an idea for a solution to address the "special"-suspend issue is pending.
Maybe there are alternative ways to suspend (and in turn resume) a process such as calling NtXxx with ThreadExecutionState information?

Due to both interfacing with the ABI and use of self-modifying code some assembly is needed.
A decision needs to be made whether and which part of the low level code can be rewritten in C.

Some x86 processes crash after injection. Possibly, a 32-bit LdrInitializeThunk is being executed, however, the 64-bit one got patched.

A possible solution includes patching the 32-bit routine too, and then doing HGate stuff to gather 64-bit execution.

The function NtSetInformationWorkerFactory, used to trigger code execution, is detected by WIN64AST for Win 10 by m5home, in "Behavior Monitor". Detection result is open thread handle with full access (which I never did!!) as well as creating a remote thread in target process (which I NEVER did too and what this rtsectionproject is ACTUALLY supposed to avoid in the first place!)

A solution seems to be yet another WorkerFactory function which was tested successfully on explorer.exe and notepad.exe. With new function the worker must NOT return to work after hijacking.
Only NtSetInformationWorkerFactory is detected, no NtDuplicateObject.

Unfortunately, I did not recognize any earlier that Microsoft made the impossible happen and changed the 64-bit (!!) NtXxx system call interface in ntdll.dll starting with Windows 10 Build 10525.
You can find further thoughts on this on twitter of Alex Ionescu. Also note the internet entries, though only sparse, about Windows Technical Preview 10525 breaks Google Chrome.

As the injection technique I'm employing in the rtsectiontest project directly relies on the assumption of a generic never-changing layout of those ntdll.dll syscall stubs (after all it wasn't changed for decades), any Windows version >= 10525 (and consequently the "Fall update") will break the project.
I'm thorougly sorry for that and I will see if the hijack entry point can be written more generic still without performing version checks... :/

Despite change of the system call stubs there wasn't a change in the RT section so there can still be injected ~3.5 KB of remote code. The worker factory API wasn't changed either, hence thread creation/control is possible with Windows 10 586 too.