4 ms·

Anti-Debugging - A Developers View

8 points by jemeshsu 15y ago

demallien 15y ago
Whilst it is true that these techniques can slow down a reverse engineering attack, I doubt that the slow done will be significant in the case of a dedicated pirate. The techniques listed in the paper are aimed at the detection of debugging tools, with the idea of shutting the program down in that case. The trouble is that detection is a very hard task. The methods described fall into two categories - detection of a signature of the offending debugging tool, or detection of a heuristic. Signatures aren't much use - yes, you can quite easily detect the presence of a stock Ollydbg, but you can't easily detect an ollydbg that has been patched to scramble it's signature - and patching programs is what pirates do! Heuristics present another problem altogether. They have the problem that they can return false positives - ok, so you have checked how long an operation took, and it was over the top of the threshold. Unfortunately what you don't know is that I'm encoding video to highly efficient h264 from a raw RED 4k file, with the encoding process given top priority. Heuristics tend to punish legitimate users for dubious protection from pirates. In my previous job I was responsible for anti-piracy measures in our DRM product - I always privileged code obfuscation over tool detection techniques for exactly this reason.
wladimir 15y ago
A good example of "Defective by design". Software should be engineered to facilitate better and easier debugging of issues instead of making it even harder. Administrating a computer is already hard enough without programs purposefully hiding what they are doing. Especially dubious heuristics like timing can cause a headache... a new hardware platform or OS with subtly different timing will cause the program to fail in mysterious ways. Oh and some developers seem to think reverse engineering protection is a substitute for server-side security. Don't even get me started about that... no, you can never trust your client.

8 points by jemeshsu 15y ago

Whilst it is true that these techniques can slow down a reverse engineering attack, I doubt that the slow done will be significant in the case of a dedicated pirate. The techniques listed in the paper are aimed at the detection of debugging tools, with the idea of shutting the program down in that case. The trouble is that detection is a very hard task. The methods described fall into two categories - detection of a signature of the offending debugging tool, or detection of a heuristic. Signatures aren't much use - yes, you can quite easily detect the presence of a stock Ollydbg, but you can't easily detect an ollydbg that has been patched to scramble it's signature - and patching programs is what pirates do! Heuristics present another problem altogether. They have the problem that they can return false positives - ok, so you have checked how long an operation took, and it was over the top of the threshold. Unfortunately what you don't know is that I'm encoding video to highly efficient h264 from a raw RED 4k file, with the encoding process given top priority. Heuristics tend to punish legitimate users for dubious protection from pirates. In my previous job I was responsible for anti-piracy measures in our DRM product - I always privileged code obfuscation over tool detection techniques for exactly this reason.

wladimir 15y ago

A good example of "Defective by design". Software should be engineered to facilitate better and easier debugging of issues instead of making it even harder. Administrating a computer is already hard enough without programs purposefully hiding what they are doing. Especially dubious heuristics like timing can cause a headache... a new hardware platform or OS with subtly different timing will cause the program to fail in mysterious ways. Oh and some developers seem to think reverse engineering protection is a substitute for server-side security. Don't even get me started about that... no, you can never trust your client.