0

In IDA pro, there is an option to attach to a process using the WinDbg backend.

When I want is to see the process' control flow when the IDA attaches to it.

The only way (that I know) to see the process' flow is to put a breakpoint in a place that I think the process will hit and single-step from there (F8).

If I don't know a place in the process where I can put a breakpoint, then I can't single-step.

How to see the process flow in assembly? hot to breakPoint and debug process that ida attached it?

If I click on suspend(there is not an option named pause) I see that process breaks inside of ntdll rtUserThreadStart. From there, I can't see where the process was before I clicked suspend.

|improve this question
  • I don't understand "If I click on pause I see that assembly enter to BreakPoint function and that not the original fllow". The command it pauses on is exactly the one that one of the thread was executing. – user202729 Jul 30 '18 at 12:08
  • Sorry, I can't click puase , only suspend and there the process enter to ntdll rtUserThreadStart, there I can't see where the process was before I click suspend – pointers Jul 30 '18 at 12:15
  • reverseengineering.stackexchange.com/questions/14649/… – user202729 Jul 30 '18 at 13:05
  • posible dupe: reverseengineering.stackexchange.com/questions/3987/… – Igor Skochinsky♦ Jul 30 '18 at 13:19
  • @IgorSkochinsky that diffrent , When I click on suspend I get the assembly of ntdll rtUserThreadStart , and I looking for the last place in assembly before the assembly jump to ntdll rtUserThreadStart – pointers Jul 30 '18 at 13:32
2

This happens due to way the Win32 debugging API implements process attaching. A new thread with DbgBreakPoint call is injected by the OS to ensure that the process gets stopped, since it could be in unknown state otherwise, and this thread is what you see.

What you can do is inspect the thread list, switch to the main one (usually first in the list), set some breakpoints up in the call stack and resume the process - the debugbreak thread will exit and your process should stop on the breakpoint so you can debug it.

You can also try this approach by blabb.

|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.