[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)

[excr4sh]

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

Yeah, it has some advantages and some disadvantages, it may be able to avoid some anti-hook tools but it will only work per thread so I think it depends on your needs.

[MalwareTech]

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

Problem solved.

[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 😏

[excr4sh]

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

Problem solved.

yeah that will work for the NtCreateFile function, but what if I call some other function that internally call NtCreateFile?

[MalwareTech]

yeah that will work for the NtCreateFile function, but what if I call some other function that internally call NtCreateFile?

You don't call non native functions within a native hook procedure.

[excr4sh]

You don't call non native functions within a native hook procedure.

Yeah, that is ok or maybe not, one can not always use the native API for example -> CreateProcess, you could implement that function or try it, but creating process involves many issues that are not documented eg initial values of the thread, CSRSS API numbers, CSRSS structures, etc. all that can be implemented by reverse engineering but I do not recommend it, will make my application unsafe, not portable.

Anyway in my project, I use several Win32 functions that might internally call the native API, that's why I decided to modify the value in the TEB so it depends on what type of project you are coding (if it is malware or only as a proof of concept).

[skid i dont know assembly]

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

[MalwareTech]

Yeah, that is ok or maybe not, one can not always use the native API for example -> CreateProcess, you could implement that function or try it, but creating process involves many issues that are not documented eg initial values of the thread, CSRSS API numbers, CSRSS structures, etc. all that can be implemented by reverse engineering but I do not recommend it, will make my application unsafe, not portable.

Anyway in my project, I use several Win32 functions that might internally call the native API, that's why I decided to modify the value in the TEB so it depends on what type of project you are coding (if it is malware or only as a proof of concept).

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

[excr4sh]

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

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

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

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

[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

[MalwareTech]

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 ...

There is no need to call non native functions from a native hook procedure, not to mention it's unsafe.

[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

[excr4sh]

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

Whether or not there, that's not the point of my thread, I created this project as a proof of concept to prove that this is possible.

[G1gg1L3s]

Yeah, that is ok or maybe not, one can not always use the native API for example -> CreateProcess, you could implement that function or try it, but creating process involves many issues that are not documented eg initial values of the thread, CSRSS API numbers, CSRSS structures, etc. all that can be implemented by reverse engineering but I do not recommend it, will make my application unsafe, not portable.

Anyway in my project, I use several Win32 functions that might internally call the native API, that's why I decided to modify the value in the TEB so it depends on what type of project you are coding (if it is malware or only as a proof of concept).

The problem it's unsafe that's what it is .
//
maltech answered :/