Protect your Qt code form hacking

Open-source applications are open by nature, indented and encouraged for tweaking, hacking and further development. For a commercial, business critical, application or a device there often is a desire to make it closed and prevent modifications. Protecting against reverse engineering and tampering is important especially when the application or device processes valuable content, licenses, IPR or monetary transactions. Because of the dual licensing, Qt offers a commercial license option that is well suited for making closed applications and devices allowing many ways of protection. Everything can be hacked, but it is possible to make hacking your Qt based application or device difficult.

For the purposes of this blog post, I have divided the ways to protect your application into three categories: securing the application, external protection and legal aspects of protecting against hacking. I have blogged about this topic three years ago, but as the topic is still very relevant, I decided to re-visit it.

In this post, I concentrate on a few easily achievable and simple ways that everyone can do to make the reverse engineering of a Qt based application more difficult. If there are specific reverse engineering or tampering related risks in your system, for example related to processing licenses, valuable content or media, proprietary algorithms or financial transactions, then you may want to consider additional security controls for tamper resistance. Some of these more advanced anti-hacking techniques are discussed in the upcoming part 2 or this blog post series (planned for February).

Securing the application

A commercial Qt license makes it legal to prevent modifications and reverse engineering, therefore it is also possible to take actions to prevent these. Static linking is one of the easiest ways of protection as it prevents simple swapping the Qt binaries used by the application and thus makes reverse engineering harder. With static linking the application and Qt libraries are combined into a single binary. A possible hacker needs to take much more demanding and time-consuming ways to modify the behavior of the system compared to dynamically linked application.

When using static linking a good further measure to protect against reverse engineering is to strip symbol names away from the binary. Depending upon the compiler you use this is either automatically done for release builds, or can be done as an extra step for the statically linked binary. For example, MSVC automatically removes symbol names from a statically linked Windows release binary. On …read more



Leave a Reply

Your email address will not be published. Required fields are marked *