Tuukka Turunen

Qt Weekly #26: Protecting your application against hacking

Published Tuesday February 17th, 2015
7 Comments on Qt Weekly #26: Protecting your application against hacking
Posted in Biz Circuit & Dev Loop, Licensing, Security

Open-source applications are open by nature, indented and encouraged for tweaking, hacking and further development. For a business critical application or a device there sometimes is desire to make it closed and prevent modifications. 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: legal means, securing the application and external protection. I concentrate into a few easily achievable and simple ways to make reverse engineering of a Qt based application difficult, not into making a binary fully secure or protected against tampering or copying. If the system needs to be fully secure, it has to be achieved by different means that making reverse engineering harder.

Legal means

Whereas the applications and devices using the open-source licensed Qt should be open for hacking and playing around, it is possible to prevent such when using a commercial license of Qt. One of the most important legal protection means provided by the commercial license of Qt is to forbid modifications and reverse engineering – and using various methods to prevent these. It is quite typical that the end user license agreement of an application or device states that reverse engineering is forbidden, which is allowed for commercial license. However for an application or a device created with the open-source licensed Qt it is not allowed to prevent reverse engineering or modifications, neither in the end user license agreement nor by making it difficult. In addition to legal protection the commercial license of Qt makes it possible to use various technical means to secure your application or device.

Securing the application

As it is allowed to legally prevent modifications and reverse engineering when a commercial license of Qt is used, it is also possible to take actions to prevent these. Static linking is one of the easiest ways of protection as it prevents changing the Qt binary used by the application and also makes reverse engineering harder. With static linking the application and Qt libraries are combined into the same binary. A possible hacker needs to take much more demanding and time consuming ways to modify the behaviour 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 Linux and Mac this can be done with strip command. After the symbol table is removed from the statically linked binary, it is quite well protected against reverse engineering. These steps are easily done and do not require modifying your Qt application source code, thus static linking and removing the symbols can be regarded as the most efficient way to obfuscate the binary and to make reverse engineering difficult.

If use of dynamic linking is needed, some protection against simply changing the dynamically linked Qt library to a new version can be gained via using libinfix to change the library names (e.g. change libQt5Core to stgElse). Another approach is to change the used namespace with configure option –qtnamespace. Namespacing Qt puts all classes inside a defined namespace resulting, for example, QString being called someNewName::QString. In addition to using libinfix and namespaces it is also possible to use a generic c++ obfuscator for Qt applications. The protection gained by using all these means to a dynamically linked library is typically weaker than using static linking. When considering the level of obfuscation, it should be noted that no matter how much the code is obfuscated, it is still eventually possible to reverse engineer.

For Qt Quick applications it is recommended to use Qt Quick Compiler if there is desire to protect the QML parts of the application. While the application logic, and thus typically the most critical parts to protect, is usually done with c++ and therefore always compiled to binary, it is a good further measure to also protect the QML parts of the application. The Qt Quick Compiler compiles QML to binary and protects against reading the QML parts of the application. An additional benefit of the Qt Quick Compiler is improved performance of the application, especially at startup.

External protection

As the Qt application is just like any other binary running in your target operating system and hardware, you can use all generic means available for protection in your environment. Operating system may offer means to digitally sign the applications, as is typically the case with the applications distributed via application stores. There are also many different products available to provide security for application binary, and these typically work for Qt applications as well.

For embedded devices some protection is gained even without any special security hardware, as it is often difficult to get access to and modify software embedded into a physical device. The most efficient protection is to have hardware containing functionality to prevent a modified binary from running (either in the device hardware, or an external one, such as a USB dongle). In some cases it is also possible to leverage another system via a network connection to provide tamper protection. Static linking and obfuscating the binary make reverse engineering difficult, but only the external protection mechanisms of the target hardware and operating system provide full protection.

It should be noted that leveraging external protection typically requires a commercial Qt license, similarly as the other means of preventing user from changing or modifying Qt libraries. LGPLv2.1 is a bit ambiguous when it comes to whether or not the user should be allowed to run the modified application, but it is rather clear that it was the intention. For LGPLv3 it is clearly stated in the license that in addition to being allowed to modify the open-source library the user must be able to run the modified library as part of the system, and that the needed tools to achieve this must to be provided.


If there is a need to create a closed application or a device, the commercial license of Qt is the right choice. With the commercial license it is possible to utilize various means for making it difficult to modify functionality of the application or device built with Qt:

  • Making reverse engineering forbidden in end user license agreement and taking actions to prevent it is allowed when Qt is used with a commercial license.
  • An easy way to protect against modifications and reverse engineering is to use static linking instead of dynamic linking and build Qt into same binary with your application to prevent changing the Qt libraries.
  • When using static linking it is important to use release builds and when needed to manually strip out the symbols before distributing the binary.
  • If dynamic linking is needed, some protection against reverse engineering can be gained by building Qt with different names for libraries using libinfix and changing the used namespace. This mainly protects against user being easily able to change the dynamically linked Qt libraries – the protection against reverse engineering provided by static linking is much better.
  • Using Qt Quick Compiler that compiles QML to binary and protects against reading the Qt Quick parts of the application is an efficient way of further protecting your application.
  • No need to provide possibility to modify software embedded into a device, thus making it possible to use capabilities of the hardware and the operating system to prevent modifications to system software.

In case you want to learn more about the ways to protect your application, feel free to contact us. We can help you to implement protection for your application both via technical and licensing means.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Biz Circuit & Dev Loop, Licensing, Security


Andrew Kastanes says:

Closed source applications dynamically linked with QT libraries (with no change in their source), cannot be released with QT open-source license? According to LGPL the user is able to modify the QT libraries, recompile them and run again the application even if the executable is closed source. However the EULA should allow revererse engineering and haking.

@Andrew: It is possible to make an application using Qt under LGPL and not provide the source code of the application, but to meet the requirements of LGPL the user needs to be able, for example, to replace the open-source Qt libraries with a freely modified version. This is very common and allowed as long as all requirements of the LGPL license are met. Sometimes there is a need to restrict these freedoms. Commercially licensed Qt is better suited, if there is desire to prevent the user from being able to modify the behaviour of the libraries, or to prevent the user from reverse engineering.

Michele says:

Can you share more insights about protection methods against hacking using the open-source libraries?

@Michele: Possible means vary depending on what kind of open-source license you use. For example GPL and LGPL provide many freedoms to the user, including freedom to study how program works and adapt it to specific needs. Protecting an application that used GPL or LGPL functionality can not be done in a way that prevents these freedoms. Some other open-source licenses, such as BSD and MIT, are more suited for use in applications that use technical means to make modifications or reverse engineering difficult. In case of Qt, our recommendation is to have a commercial license and use means such as static linking to protect your application.

koval says:

What about obfuscating the source code and using code-transformation tools to keep the application open-source but hard to reverse engineer and hack?
Could I keep my readable sources in secret and only publish transformed non-readable version?
The end user would be able to build the application against modified version of Qt libraries but would face substantial problems in understanding how the code works.
Would this kind of protection be allowed with open source license?

@koval: I do not think that approach is very efficient in practise. You have to provide the exactly same source code of the open-source library used in your application, so even though you have made it difficult to understand it is still c++ source code and the recipient can leverage it to execute his rights as a user of open-source software.

Cyber Killer says:

Thank you for using the term “hacking” in it’s proper meaning. I don’t agree with the point of the article though (I’m a strong supporter of FLOSS and hackerspace communities), but thanks anyway :-).

Commenting closed.

Get started today with Qt Download now