Is this a good way to get past anti-debugging measures?

Question

This program I am analyzing is full of anti-debugging. It won't even run if most debuggers are loaded before I start the app.

I tried using IDA to static analyze it, but it was written in a OOP language, and has many calls to pointers inside registers; so I keep getting stuck digging in.

So, I'm wondering if it's possible to patch the .exe with code above the calls to record the register values, and maybe the line of the instruction. and then I can see what functions/methods are being called.

I added a bunch of zero bytes to the end of the .exe, and it ran, so it doesn't seem to have any checksum verification.

Will this be possible?

Answer 1

1. I would try to determine the OOP language it was written there might be tools/IDA scripts to help with static analysis
2. I have found the easiest way to reverse this kind of app is using time travel debugging trace (or similar) On Windows platform this is achieved by downloading WinDbg Preview from Windows 10 store. Once downloaded you can copy the files and run them without install to a machine without windows store if required. More info is available at Time Travel documentation. These traces once generated you can then step backwards/forwards instruction by instruction or to breakpoints.

For example I used this command to show the time travel position for all text written to a file I could then click the hyperlink generated to go to exact register/thread/memory state when that text was written to file

bp kernel32!WriteFile "!position;.printf \"%mu\",@rdx;g"

To go forwards use g command, to go backwards g-, to step single instruction forward t and step instruction backwards t-

3. Also consider identifying the anti debugging technique used then hide from it, some examples here.

Answer 2

It depends on what you are trying to achieve:

1. source code extraction (say to replicate it with minor modifications)
2. program patching

For the first case, I normally try to use a non invasive debugger attached after suspending the process. If this does not work, I dump the whole process with SysInternals Process Explorer or WinDbg after suspending the process. The I use Ghidra do analyze the whole dump. I noted that IDA has issues in analyzing those dumps (sometimes peculiar parts are not detected) but you can combine them. This would give you the ability to analyze the code. If the code is self modifying you should use the second approach.

For the second case (and as last resort) I use a specially modified VM to remotely debug the application in non invasive mode. The VM is crafted with a custom rootkit that hides the processes you want (in particular, debuggers), this way you can debug the whole system in kernel mode without being detected.

Answer 3

I think CRC routine is inside code, maybe more than one for different part of code. It's not necessary checksum at the end of whole of file. For example its possible count sum of bytes and compare it with a value inside a register. Do you are debugging win32/64 or android file?