Detecting of application component name

[AndreyK]

Hi! 🙂

I have some question about how can I resolve name of component which trying to interact with network? For process name determination I use PsGetCurrentProcessId(), but how can I resolve name of component (*.dll etc.) in detected process? There is some idea about using PsGetCurrentThread – but about next steps there is not any ideas 🙄 ….

[Vadim Smirnov]

You can parse the user mode stack of the calling thread. On the top of the stack is usually ntdll.dll and so on.

However, if you are trying to detect Trojan module then it can be a bit complex. It is possible to work with TDI directly thus bypassing most of the user mode network modules. It is event possible to bypass ntdll.dll by replicating necessary system calls in Trojan module. In this case Trojan DLL will be on top of the stack. This makes the task of parsing the call stack quite complex.

[AndreyK]

Thanks for idea! 🙂

Could You give some “key-words” for searching, some starting point for invastigating this question? Some functions name which will help in understanding of stack parsing methods?

[Vadim Smirnov]

The task is very similar to what debugger does when it shows you the call stack. You can try to search for open source debugging tools. Also debugging relative books should be helpful. Personally I like this one http://www.amazon.com/Advanced-Debugging-Addison-Wesley-Microsoft-Technology/dp/0321374460

[AndreyK]

@SerpentFly wrote:

The task is very similar to what debugger does when it shows you the call stack. You can try to search for open source debugging tools. Also debugging relative books should be helpful. Personally I like this one http://www.amazon.com/Advanced-Debugging-Addison-Wesley-Microsoft-Technology/dp/0321374460

I had discuss your suggestion about stack parsing on some forums and I have some doubt: for stack parsing I need debug symbols of investigating components – so I understand from Internet invastigating that stack parsing isn’t easyest way…

[Vadim Smirnov]

I had not sad that this is easy, but there is no other way to track the module which actually called the system service.

Luckily for the actual winsock calls the stack is easy to restore (number and types of parameters are known) up to the calling module.

[Author]

Posts