[Tigzy]

Hey, I'm making a small part of code that disassemble the first bytes of the EAT/IAT of modules of a loaded process. Nothing new here.
I got a problem with function pointer, because most of the time it's a pointer to a real assembly code, and sometimes it's a pointer to a location in the virtual table.

The main problem is my program tries to disassemble the first bytes, whatever they are, and sometimes those vtable address looks like JMP or CALL statements, raising a flag for inline hook.

How can I do to define the range of the vtable (and thus treat those address as address pointers instead of code) in the loaded module ?
Cheers,

EDIT: Here's what it looks like in IDA

Capture.PNG (24.26 KiB) Viewed 856 times

Capture2.PNG (25.44 KiB) Viewed 856 times

[Tigzy]

For information, I found this link : https://www.osronline.com/showthread.cfm?link=156816
They say that Undecorate symbols can work, but is quite dangerous.

[EP_X0FF]

Skip non-system dlls instead implementing this undecorating kludge. Do you think someone cares about hooks in msvcrt/pure с++/non system dll's for example? Vtable methods can also be hooked differently btw. Have no idea how to determine vtable range unless using sort of probably unreliable heuristics.

[p4r4n0id]

Hi,

An idea from a very good friend of mine: :)

You can validate if it is a vtable function if the target of the call / jmp is inside the specific module. if it is outside of the module you can , in 99% of the cases, assumes it is an inline hook case ( jmps outside the module).

[Tigzy]

@EP_X0FF, yep, totally agree with you. This is what I'm ending to, only look at vital modules (User32.dll, Kernel32.dll, ....)
But for educational purpose, I'll check if I can find some way to exclude C++ names from the analysis.

You can validate if it is a vtable function if the target of the call / jmp is inside the specific module. if it is outside of the module you can , in 99% of the cases, assumes it is an inline hook case ( jmps outside the module).

I'm not sure to understand. There's not jmp or call, you land directly in the vtable by looking at the address pointed by the EAT index.
For inline hooks, yeah this is what I'm doing. But that's not enough, in advanced infections it points to a shellcode on the Heap (outside of any module then) and then it jumps to the malware module. Sometimes it's also completely shellcoded in a code cave. And really hard to detect.

[EP_X0FF]

If you are using for example COM interfaces there can be proxy object instead of direct vtable patching. So calls still will be filtered but no hooks will be set. I don't remember exactly but somewhere on codeproject.com located example I used for BSA sandbox logger COM hooking.

[Tigzy]

Wow, interesting :)

[p4r4n0id]

Hi,

You have mentioned in first post "sometimes those vtable address looks like JMP or CALL", if there is a JMP or CALL my above suggestion will work , if not, no idea how to find vtable range :)

[p4r4n0id]

@EP_X0FF, sorry for being n00b here but can you please explain why you have suggsted the COM proxy? how it will help reducing the FP in function pointers cases?

thx !

[EP_X0FF]

@EP_X0FF, sorry for being n00b here but can you please explain why you have suggsted the COM proxy? how it will help reducing the FP in function pointers cases?

thx !

Nohow, it is just another unobvious way of filtering.
http://www.codeproject.com/Articles/153 ... Interfaces