3
$\begingroup$

How is tamper-proofing of software evaluated for effectiveness?

I've been implementing a few algorithms listed within Surreptitious Software: Obfuscation, Watermarking, and Tamperproofing for Software Protection. The algorithms include tamper-proofing of software by means of introspection (or computing a hash at runtime over some region of code).

However, nothing is said about the evaluation of such tamper-proofing algorithms: How are they compared to each other and how are their effectiveness measured?

Searching Google, I've come across few articles discussing the subject. One of the articles made an emperical evaluation, where they asked "hackers" to break their implementation and then measured the time taken.

Does anyone know how to evaluate tamper-proofing at a theoretical level?

$\endgroup$
3
$\begingroup$

Unfortunately, we don't know of any way to reliably measure the effectiveness of software obfuscation schemes (or the security of pretty much anything else). The best we can do is publish the scheme, wait for other researchers to try to attack it, and see what the best attacks that someone has been able to find are.

As you can imagine, there are many limitations and caveats with that approach. How do we know whether anyone has tried to break it, or whether the right people with the right skills have tried? Or maybe there is some devastating attack that no one has thought of yet, but might be discovered tomorrow.

Anyway, that's the approach typically taken in practical work on software obfuscation. There is also theoretical work on software obfuscation, which tries to prove security theorems (under some complexity-theory assumptions about the hardness of some well-studied problems). Unfortunately, at present there is a significant gap between practice and theory. For the most part, the provably secure schemes aren't practical, and the practical schemes aren't provably secure. There are exceptions, but they tend to be very special-purpose -- they can only obfuscate a small class of special programs -- and can't be used to obfuscate an arbitrary program. The theoretical work is very interesting and has made many advances but still has a way to go before we can find a truly practical, provably secure, and general scheme for software obfuscation.

Finally, if you are interested in practical schemes for practical use, let me share one last caveat. My personal perspective is that none of the practical schemes for software obfuscation appear to be terribly secure. They provide a speedbump that will slow down an attacker or require some effort and skill to break, but I would not expect any of them to resist a dedicated, motivated attacker. So, while they're fine if you just want to increase the cost of reverse-engineering, I wouldn't rely on them to hold up to serious attack. That's just my own personal sense and opinion, which others in the field might not agree with.

$\endgroup$
  • $\begingroup$ Thank you very much for the answer. Actually the book has many of the same views as you regarding obfuscation. $\endgroup$ – Shuzheng May 19 '17 at 6:02

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.