1

When I debug .exe file with IDA, I want to put a breakpoint before the .exe sends a TCP packet.

When I listen with ProcMon I can see that this .exe sends and receives TCP packets.

  1. I look at the .exe file import tab, and put a breakpoint at send function, but that doesn't trigger.
  2. I looking at the line at ProcMon when I see tcp send in stack tab, and see:
frame 0 ,module ntoskrnl.exe  , Location CcMdlWriteAbout + 0x....
frame 1 ,module tcpip.sys , Location tcpip.sys + 0x....
frame 2 ,module tcpip.sys , Location tcpip.sys + 0x....

etc.

How can I find the function in the .exe file that sends TCP packets? I want to put breakpoint there.

Improve this question

1 Answer 1

Reset to default
1

If you can see the send event in ProcMon, just double click it and check the Stack tab to see what API the program used to perform it. Note that the stack trace usually includes the kernel part; you’ll need to skip it and look at the user-mode calls (skip the system libraries too except the one called directly by the process).

Improve this answer
5
  • in ProcMon Stack tab I see only ntosknl.exe , and the rest is .sys Modules
    – joif doi
    Commented Nov 17, 2019 at 13:34
  • @joifdoi there should be some user-mode code in there unless the send actually originates in a driver... which is possible but unlikely
    – Igor Skochinsky ♦
    Commented Nov 18, 2019 at 10:45
  • @IgorSkochinsky what exact stack should we see in ProcMon? AFAIK for example socket.send() in python will call the needed syscall under the hood, and ProcMon will not be able to track what caused the call except it somehow knows debug symbols of program or maybe the app is built without stripping the debug info
    – Ivan
    Commented Dec 26, 2023 at 12:28
  • @Ivan on Windows, raw syscalls are not used by user-mode programs. WS2_32.dll send() will likely be used in such case.
    – Igor Skochinsky ♦
    Commented Dec 27, 2023 at 14:46
  • 1
    @IgorSkochinsky it depends on the program, I reckon. True it may not be syscalls (which are tricky to wield correctly because their numbers vary across patch levels), but it could conceivably be use IOCTLs to talk to \Device\Afd (or similar) and achieve similar functionality as through the usual UM APIs. However, my guess here would be that another module is making the actual call, if the breakpoint on the module itself doesn't trigger. Of course chances are the program behaves differently under a debugger and this being the cause for the bpx not triggering.
    – 0xC0000022L ♦
    Commented Apr 23 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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