Protecting your application against hacking

Last Tuesday February 17th, 2015 I saw a publication from Mr. Tuuka Turunen entitled Qt Weekly #26: Protecting your application against hacking, where he stated some pitfalls and advised that a paid Qt license as a good way of protecting your software against hacking. Some comments were written, a lot less than I expected for such a vast topic. One that attracted my attention was "Can you share more insights about protection methods against hacking using the open-source libraries?", from a person named Michele. I tried to reply but was unable to do so, so dear Michele, whoever you are, here it goes.

There are ways to avoid tampering that that article didn't mention, as clearly it wants to sell the point that a paid Qt license is better (that may be the case, I'm not opposing to it, and I believe helping the Trolls to pay their bills is the best way to reciprocate everything they've already done for us). But to us cheap hackers who live in very distinct realms where getting a paid Qt license is unfeasible, there are some funny ways (that can be used on the non-LGPL world too) we can protect our beloved programs. I will not delve into specific details, but I used the techniques I mentioned in some projects I was involved with. One is encrypt your binary with  a 4096-bit asymmetric key and wrap it around an executable that decrypts it. You can encrypt the main binary, libraries, plugins, resources and everything else. This solution coupled with obfuscators, symbol strippers, some canaries in code to avoid tampering a running program's memory, homecalling. Those measures will give you a reasonable safety window, allowing you to develop newer versions of your program before people are able to crack an older version. These techniques are not particularly tied to Qt, but can be applied to projects based on it somewhat easily (the paid version doesn't improve this workflow).

About reverse engineering, DMCA already protects people in USA and countries that bow to it. There are countries where such clause may be unenforceable, and people who reverse-engineer are not afraid of legalese, either because they're too small, too big or too far away to care, so if your program is worth reverse engineering, people will try to reverse engineer it, no matter what. So reverseengineeringreturn=softwarevalue/(effort*time). Make it difficult enough, time wasting enough, and crackers will go somewhere else. Make great value software, crackers' efforts will redouble.

As a side note, if you are trying to prevent people from using an unpaid software, remember that piracy has its good side, as it promotes visibility and mindshare. You can use the techniques mentioned here to prevent unauthorized use, but I would rather use them to prevent fellow rivals from knowing the innards that make my app so marvelous, or to prevent crackers from using my application as a vector to spread malware.

Compliments of the season and happy hacking!