[hezboula123]

Nice, clean. I like it.

Good job.

Ironically intercepting sys calls on wow64 is more straight forward than on x86. KiFastSystemCall isn't large enough for a five byte relative jump instruction.

I like the idea of not using a LDE for Nt* Functions. You can always guarantee the patch size.

I still cringe at Microsoft generic linked list implementation. oh well.

[hezboula123]

that's true, it requires less than 5-bytes long so you can make it work but that's even possible. I may add it to the project so it work in both 32 and 64b-bit Windows.

Definitely possible. backwards short jumps that lead to relative 4 byte jumps would be a solution.

CONTAINING_RECORD(List, WOW64_SYSCALL_INFO, ListEntry);

Let me guess what this does, considering type of listentry exists in type of wow64_syscall_info this macro finds the corresponding 'list' pointer along with the other data types defined in the type of 'wow64_syscall_info' structure in memory then returns the base (type of wow64_syscall_info)?

I'm guessing since the address of the list entry is +8 of the structure you can just subtract 8 from the pointer, it's essentially what the macro is doing i believe.

Edit:

Just looked up the macro, looks like i was right.

(type *)((char*)(address) -(unsigned long)(&((type *)0)->field)))

[RISC]

Nice, clean. I like it.

Good job.

Ironically intercepting sys calls on wow64 is more straight forward than on x86. KiFastSystemCall isn't large enough for a five byte relative jump instruction.

I like the idea of not using a LDE for Nt* Functions. You can always guarantee the patch size.

I still cringe at Microsoft generic linked list implementation. oh well.

You can make a two byte relative jump to KiIntSystemCall and perform the five byte patch from there. It's more straight forward than X86SwitchTo64BitMode. The only real downside I see to X86SwitchTo64BitMode is that it's relative to the thread's stack. Where as KiFastSystemCall, all the threads rely on a single global function.

[RISC]

You talk about this:
0:000:x86> dt ntdll32!_TEB
+0x000 NtTib : _NT_TIB
+0x01c EnvironmentPointer : Ptr32 Void
+0x020 ClientId : _CLIENT_ID
+0x028 ActiveRpcHandle : Ptr32 Void
+0x02c ThreadLocalStoragePointer : Ptr32 Void
+0x030 ProcessEnvironmentBlock : Ptr32 _PEB
+0x034 LastErrorValue : Uint4B
+0x038 CountOfOwnedCriticalSections : Uint4B
+0x03c CsrClientThread : Ptr32 Void
+0x040 Win32ThreadInfo : Ptr32 Void
+0x044 User32Reserved : [26] Uint4B
+0x0ac UserReserved : [5] Uint4B
+0x0c0 WOW32Reserved : Ptr32 Void

The real Hook is set at wow64cpu!X86SwitchTo64BitMode, WOW32Reserved is a pointer which points to that direction.

Ah, I wasn't reading the code correctly. I thought you were overwriting the pointer itself.

[Only3]

good share if RISC didnt kill it must be hq

[RISC]

Imagine that one thread calls a function that goes through the hook, in my proxy or sub-sequent calls you can make a call to some function of the system such as CreateFile, that call would pass right through NtCreateFile -> FS: [0xC0] -> My hook, proxy function -> and back to CreateFile, This would cause a infinite loop and in most cases, a Stack Overflow that is why I modify the pointer temporarily.

You could easily avoid the infinite loop.
C0h is a pointer to the function.
Original: Nt->C0h->Switch
Yours:Nt->C0h->Hook
Another option:Nt->My Pointer to C0h->C0h->Switch

Where My Pointer simply handles the stack before it reaches X86SwitchTo64BitMode.

The first scenerio which you're doing is the more practical solution since you'd avoid having to replace the pointer in every thread's context. The second scenerio works just as well, where it's not a complete hook, you'd have to return tot he original x86switchto64bitmode once you've dealt with the argument.

[hezboula123]

Code

mov dword ptr fs:[0xC0], edi
      push eax
      call IndexLookupPrint
      mov dword ptr fs:[0xC0], esi

So let's get this straight, if you're going to use any functions such as createfile as you suggested earlier to prevent a catastrophic infinite loop you'd just temporarily switch the pointer
then you'd call createfile under the mov dword ptr fs:[0xc0], edi

Seems like a good solution but what happens if let's say another thread calls any function while your pointer is replaced, you won't get the call.
while 0CH = your actual switch trampoline, it won't touch the hook.

[hezboula123]

Each thread has its own TEB:
0:012> ~
0 Id: 668.20c Suspend: 1 Teb: 000000`7efdb000 Unfrozen
1 Id: 668.ea4 Suspend: 1 Teb: 000000`7efd8000 Unfrozen
2 Id: 668.df0 Suspend: 1 Teb: 000000`7efd5000 Unfrozen
3 Id: 668.f78 Suspend: 1 Teb: 000000`7efad000 Unfrozen
4 Id: 668.ac Suspend: 1 Teb: 000000`7efaa000 Unfrozen
5 Id: 668.69c Suspend: 1 Teb: 000000`7efa7000 Unfrozen
6 Id: 668.dbc Suspend: 1 Teb: 000000`7efa4000 Unfrozen
7 Id: 668.c94 Suspend: 1 Teb: 000000`7efa1000 Unfrozen
8 Id: 668.cc4 Suspend: 1 Teb: 000000`7ef9e000 Unfrozen
9 Id: 668.cec Suspend: 1 Teb: 000000`7ef9b000 Unfrozen
10 Id: 668.4b0 Suspend: 1 Teb: 000000`7ef98000 Unfrozen
11 Id: 668.8b8 Suspend: 1 Teb: 000000`7ef95000 Unfrozen
. 12 Id: 668.f9c Suspend: 1 Teb: 000000`7ef92000 Unfrozen

So from what I understand the TEB contains a pointer to the switch function,
So initially you hooked the switch function (pointer obtained from the current thread's TEB).

I understand. Because RISC was suggesting to replace this pointer in every TEB, but instead you hooked the function.

So once you replace the pointer, it's only replaced for that threads TEB. Then you restore it afterwards while every other thread still has the pointer to switch in their TEB.

Code

FS:[0xC0]    4    NT    Reserved for Wow64. Contains a pointer to FastSysCall in Wow64.

Edit:

PEB64: 0x7efdf000
Yeah, the x64 TEB would be used for segment switches from wow64 to obtain the pointer to PEB, and find ntdll's x64 address. Then you'd just create a generic call for _stdcall functions and handle the stack based on an 8 byte alignment (x64)

[Only3]

NTSTATUS safe_NtCreateFile(...)
{
mov eax, [NtCreateFile_id]
xor ecx, ecx
lea edx, [esp+4]
call X86SwitchTo64BitMode
add esp, 4
ret 0x2C
}

Problem solved.

😁 hezboula123 Offline >> closed
he will come back to reply 😏

[skid i dont know assembly]

FordCL. When dumping the arguments from Edx, how do you know the amount of arguments for each ordinal?

[skid i dont know assembly]

There is no function, but you can check ret/retn instruction when analyzing.

Take that function as an example there are many functions that call native API, not only Kernel32 but Advapi32, User32, Ws2_32 ...

You're right, thats exactly what i was thinking. Disassemble the ret/retn instruction and divide by 4 since its stdcall.

---

Why would you be calling CreateProcess from within a hook procedure?

he used that as an example. Regardless his solution works fine

[Microwave89]

FordCL: Tell me a situation in which you need to hook NTAPI of 32 bit processes on x86-64 machines?
If for concealment reasons you'd better forget about it..

Best Regards - Microwave89

[He B TeMy]

I call IsWow64Process function to determinate the type of the process ( 32 or 64-bit ), IsWow64Process requires a handle to the process with PROCESS_QUERY_(LIMITED)_INFORMATION access, but you cannot open a handle with that access right to a process with higher integrity (UAC enabled) than the process is running, that is why it is unable to determinate the type of the process. It's not an error/problem, If I run it with admin rights, it shows the type. I took that screenshot from Windows 7 64-bit.

BTW, 16-bit of what?

He meant 16-bit applications, but you can't run them on x64 systems.

[RISC]

I know a lot more than you do, you are the one that doesn't know what you're talking about or you lack the comprehension skills to even read my posts properly. You act like this is advanced lol.

He did say intercepting system service calls on WoW64 processes. This will not work on 64 bit architectures running 64 bit processes, or 32 bit architectures running 32 or 16 bit processes. The only reason the hook works is because the emulation code has to exit eventually and that's where the hook takes place. If it were to be implemented to work on 16, the concept would be the same, just the code would be slightly different; however, WoW64 process has nothing to do with a 32 bit OS or a 16 bit process on a 32 bit OS.

[RISC]

He did write this too though:

But there are 64 bit Windows XP versions. Which also implement X86SwitchTo64Bit. The hook would work just fine on XP WoW64 processes.