Detecting of application component name

Home Forums Discussions General Discussion Detecting of application component name

This topic contains 5 replies, has 2 voices, and was last updated by  Vadim Smirnov 9 years, 6 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #5208

    AndreyK
    Participant

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

    #6634

    Vadim Smirnov
    Moderator

    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.

    #6635

    AndreyK
    Participant

    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?

    #6636

    Vadim Smirnov
    Moderator

    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

    #6637

    AndreyK
    Participant

    @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…

    #6638

    Vadim Smirnov
    Moderator

    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.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.