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 pi

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.