1

I tried to debug a windows application, but when I debug it with Ida, it stopped on int 3 instruction.

I read that int 3 catch debugger so I cant debug.

How can I cancel this int 3?

How call to int 3?

If I change this hex to nop will it be cancel?

1

Well int 3 is opcode that it's especially meant for the purpose to call debugger.

It is used i.e. for software breakpoint. You could replace them with nop's and you should be good to go. I would though find out why they are being executed in the first place and maybe there is some condition to avoid them being exec'd.

| improve this answer | |
  • How does it work? I saw when I tried to debug with ida I go to int 3 ,is there any function that call to int 3 ? This int 3 it 1 byte, how can I replace it with nop? – Keystone Apr 28 '18 at 17:25
  • nop is also one byte - 0x90 – Paweł Łukasik Apr 28 '18 at 18:48
  • Can you please explain me how it works? The anti debugger add to code int3 soveach time I attach to process I came to int 3? Why? And if I just replace with hex editor the int3 with nop the anti debugger will not catch me? – Keystone Apr 28 '18 at 20:09
  • I think you need to understand how this anti-debugging works in the first płace – Paweł Łukasik Apr 29 '18 at 6:25
  • 1
    Where can I learn it well? – Keystone Apr 29 '18 at 20:11
1

How you could start to tackle this problem. I assume that you are able to start the program under Ida and and find in memory the int3 location. If this is not the case, you should describe in some more detail what exactly happens.

  1. Look in a hex editor if the int3 (=0xCC) is present in the static exe file. For this, you could collect in Ida (on a sheet of paper) the sequence of bytes in memory in the vicinity of the int 3. You should be able to find this byte sequence in the file, but take memory locations into account which might not be present in the static file (due to linking or dynamic memory).
  2. If the int3 is there in your exe file, replace it with your hex editor by a nop (0x90).
  3. Start Ida and have a look if the prog can stop at this location.
  4. Look in Ida if your 0x90 is still there. If no, then it has perhaps been removed by some anti-tamper means. In that case, stop in Ida immediately after start, and try - by stepping through your prog - to isolate the location where it is removed.

This is just an example how to start. There are of course other possible ways to tackle the problem. For instance, when Ida breaks at your int3, try to trace back to find from where the code sequence containing the int3 is called. This should be connected to the anti-debug code, because I assume your int3 is not called when running without debugger.

The most important with this stuff: Don't give up, even if it totally frustrates you (That's the sole purpose of anti-debug).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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