A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #21030  by Tigzy
 Wed Oct 02, 2013 1:37 pm
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
Capture2.PNG
You do not have the required permissions to view the files attached to this post.
 #21039  by EP_X0FF
 Thu Oct 03, 2013 3:42 am
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.
 #21041  by p4r4n0id
 Thu Oct 03, 2013 6:22 am
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).
 #21042  by Tigzy
 Thu Oct 03, 2013 6:53 am
@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.
 #21043  by EP_X0FF
 Thu Oct 03, 2013 7:18 am
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.
 #21051  by p4r4n0id
 Thu Oct 03, 2013 5:46 pm
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 :)
 #21052  by p4r4n0id
 Thu Oct 03, 2013 5:53 pm
@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 !
 #21060  by EP_X0FF
 Fri Oct 04, 2013 2:15 am
p4r4n0id wrote:@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