Arch limitation

[ghost]

Not issue, just a quick note which worth noting:

You can only apply this if you're building & running on the same arch as your OS, which means you can't just start a 32bit target on your 64bit host. Neither whether your compiled herpaderper is 32 or 64bit. At least according to my observation.

As far as I yet researched the target process is created with a 64bit image type by default. You would have to somehow specify at the process creation to make it a wow64 process. I've got no idea how by the way ;)

[Hallavera]

I had been banging my head against VisualStudio for days with this. I thought I must have done something wrong somewhere however I guess the issue is hardcoded. Im not good enough at C++ to write something that solves this. Anyone have any idea on a workaround? Did you manage to figure out a solution?

[jxy-s]

In order to create a wow64 process on a modern OSes, I believe you need to call NtCreateUserProcess. The way of creating a wow64 process using NtCreateProcessEx (e.g. specifying the section) may not be possible on modern OSes. I'd have to spend more time reversing the process creation path in the kernel to understand if/how it's possible.

Using NtCreateUserProcess here, while possible, will result in the Ps process create notify routine triggering sooner than desired since NtCreateUserProcess will do the thread insertion on the callers behalf. I'm not aware of a way to get NtCreateUserProcess to skip the thread insert. Perhaps it's possible. If it was, then you may be able to use NtCreateUserProcess here instead, obscure the image file backing the section, then insert the thread to trigger the notify routine in the kernel. Another note, NtCreateUserProcess will open the file and create the section, then close it. Which may trigger some security products to do the analysis of the write on IRP_MJ_CLEANUP.

The differentiating factor between this and other similar techniques in its class is the juggling to manipulate when inspection may be preformed by a security product (e.g. IRP_MJ_CLEANUP or Ps notify routines). NtCreateProcessEx provides a convenient way to preform that juggling. However, an area of research I think would be interesting is around NtCreateUserProcess. Understanding what might be manipulated there to preform similar juggling is, to my knowledge, an untapped area.

So in summary: NtCreateUserProcess might be viable for this technique if:

1. The initial thread insert may be skipped.
2. IRP_MJ_CLEANUP is not invoked through NtCreateUserProcess, or the IRP_MJ_CLEANUP that is invoked does not trigger analysis (as it wouldn't actually have written to the file) and the on-write scan that might be preformed is delayed until the handle opened (and written through) by the herpaderper closes triggering an IRP_MJ_CLEANUP.

[leecher1337]

Hi,

I implemented a routine that can create a Wow64 process using NtCreateProcess API and this works fine on Windows 7:
https://github.com/leecher1337/ntvdmx64/blob/master/ntvdmpatch/src/ldntvdm/ldntvdm/createuserproc.c

But when using the same code on Windows 8, it starts the process quite fine, but crashes randomly. I found out that this is always related to the return of the Wow64 CPU by using a syscall. Sometimes a few syscalls work, but after some it always crashes.
I found out that doaing a breakpoint on wow64cpu!ServiceNoTurbo in WinDbg (so the WOW64-dispatcher on the 64bit side) and then continuing for every syscall doesn't lead to crashes, so I suspect some kind of race condition or something like that.

Do you have an idea what I am missing on Win8+ ?