![]() The most important with this stuff: Don't give up, even if it totally frustrates you (That's the sole purpose of anti-debug). This should be connected to the anti-debug code, because I assume your int3 is not called when running without debugger. For instance, when Ida breaks at your int3, try to trace back to find from where the code sequence containing the int3 is called. There are of course other possible ways to tackle the problem. In that case, stop in Ida immediately after start, and try - by stepping through your prog - to isolate the location where it is removed. If no, then it has perhaps been removed by some anti-tamper means. Look in Ida if your 0x90 is still there.Start Ida and have a look if the prog can stop at this location.If the int3 is there in your exe file, replace it with your hex editor by a nop (0x90).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). 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. To make IDA Pro use the real binary addresses, rebase the IDB before attaching to. As a result, IDA Pro will try to work with addresses pointing to an invalid memory space. ![]() Look in a hex editor if the int3 (=0xCC) is present in the static exe file. If you attach to a remote GDB server on a system that has ASLR, IDA Pro will not be able to find the location of the examining binary in the memory.If this is not the case, you should describe in some more detail what exactly happens. I assume that you are able to start the program under Ida and and find in memory the int3 location. How you could start to tackle this problem. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |