Get real address of api not nt version
 

Hello guys

As far as I searched, Microsoft decided to redirect api's to nt version from windows 8. Please correct me if it's wrong.

For example if I use GetProcAddress(user32.dll, ShowWindow) the returned address is NtUserShowWindow even using GetProcAddress or LoadLibrary replacement custom code or GetModuleHandle.

https://imgur.com/a/Dkw6O43

So, How can I get the real address of ShowWindow bytes in memory not nt version of this api.

Thank you.

Even earlier they began to do this by redirecting kernel32.dll functions to ntdll.dll
This is done by the PE loader
[imho] There is no way to fix this automatically. [/imho]
In a disassembled text this is done by hand.

Hum, you mean I have to use disassembler library ?

Debugger on your screenshot types real addreses (it founds real imported function by her real address).
Real addresses of imports done with PE-loader of Windows.
In the debugger window it looks fine, but if you insert disassembled text into your project,
then you need to replace the run-time variables with their normal "standard" values. (For compatibility purposes).
Make it by hand, there is no other way
- by hand or with your text editor search&replace script etc.

Actually, I dont want to use debugger or disassembler. I want do it with programming in C++ for detecting the right value or real address

You see the actual real addresses in the debugger window.

Also you can parse PE import table of loaded program at memory
and use equivalent-table of "functions names"
- If you are writing your own application for tracing PE-programs.
But it is difficult.

my goal is create a program to check the bytes for example ShowWindow from memory and compare with user32.dll in system32.

In windows 7 and vista my program works perfectly but in windows 8-10 bytes not equal because of nt address.

Then, as I understand, your program is working fine
- it determines that the bytes of the actual function server
do not match the bytes in the tracked DLL in the system32 directory
?

..
You can previouosly import target function to your program and make alias-table
like this:
;-------------------------------------------------------[ASM]
ECU_TABLE_ITEM STRUC
RealAddress dd ? ;;Real address
TargetFunctionName db 30h dup (?), 0 ;;Function name
ECU_TABLE_ITEM ENDS

imp_equ_table:
imp1 ECU_TABLE_ITEM <?, 'ShowWindow'>
imp2 ECU_TABLE_ITEM <?, 'GetModuleHandle'>
.....etc.
;-------------------------------------------------------[ASM]

- Further work referring to this table.



--add--

PE-loader at new versions of OS can emulate imported function without original dll
(For example, kernel32.dll may be absent, but application with call of kernel32.GetModuleHandleA will work fine)

Thank you dosprog.
Please explain more in detail about alias-table

[ASM] Example
 

Ok, see example:

after that you also have apisets and shims to deal with... you've only hit the tip of the iceberg

It's a fact.

Hello dosprog
Thank you, I checked you example code and I've done this before and the returned addresses for your sample and my program are same but that's what I'm say is not real address.

For example :
In Windows7 if press CTRL+G in debugger and type the ShowWindow we will redirect to real location of code in user32.dll .
in Windows10 if type the ShowWindow we will redirect to an offset that jumped to NtUserShowWindow and if fallow the jump we redirect to real address of ShowWindow API but in NtUserShowWindow.

In Windows7 and Vista if someone wants to hook ShowWindow api I will detect with comparing bytes in memory and file from user32.dll but in Windows10 I can't do it because of NT APIs.
This is my question, How can I detect api hooking in windows10 or How can I get the returned address from NtUserShowWindow.

Please check the attachment.

Effectively following the jumps you will see that NtUserShowWindow resides in win32u.dll

win32u.dll is not exist in System32 folder and I have to know where are these bytes from because ShowWindow API belongs to user32.dll