Protecting app against reverse engineering through static linking
-
Hi,
i'am following a guide to protect our app against reverse engineering. As one of the easiest ways of protection static linking is listed. With static linking the application and Qt libraries are combined into a single binary which prevents simple swapping the Qt binaries used by the application and thus makes reverse engineering harder.But I've absolutely no idea how to achive that static linking for my application, especially no "easy" way. Do i need to build Qt from Source for that?
The reason for my concern about obfuscating is, that a big part of our application is readable in plain text when opening the .exe with a Texteditor, especially the resources.
Hope you can help me or give me some advices on how you protect your sourcecode.
Greetings,
PS: Ofc I'am using Qt commercial licence.
-
Hi,
i'am following a guide to protect our app against reverse engineering. As one of the easiest ways of protection static linking is listed. With static linking the application and Qt libraries are combined into a single binary which prevents simple swapping the Qt binaries used by the application and thus makes reverse engineering harder.But I've absolutely no idea how to achive that static linking for my application, especially no "easy" way. Do i need to build Qt from Source for that?
The reason for my concern about obfuscating is, that a big part of our application is readable in plain text when opening the .exe with a Texteditor, especially the resources.
Hope you can help me or give me some advices on how you protect your sourcecode.
Greetings,
PS: Ofc I'am using Qt commercial licence.
@Wowalive said in Protecting app against reverse engineering through static linking:
The reason for my concern about obfuscating is, that a big part of our application is readable in plain text when opening the .exe with a Texteditor, especially the resources.
If this is so, how do you think static linking will affect/alter that?
-
Static linking was just the first step I stumbeled over while grappling with the topic of protecting the app against reverse engineering.
@Wowalive
Well it won't do anything about being able to see your resources. You would have to start by not supplying resources, or external resource files, without encrypting them. Which makes resources unusable in your code, other than as a means to distribute encrypted binary data which would have to be unencrypted in memory, if the relevant Qt calls do not demand a file/resource for whatever operation.But I've absolutely no idea how to achive that static linking for my application, especially no "easy" way. Do i need to build Qt from Source for that?
I don't think TQtC distributes static builds, at least not for Windows; and usually when people do not say anything about platform in their questions they assume Windows.... So I imagine, yes, you would need to build Qt statically from source yourself. I stand to be corrected if I am wrong about this.
There are many hits if you Google for
qt static libraries, e.g. https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW and many others. -
@Wowalive, If your executable is written in a compiled language then the source code is never visible in the compiled executable. The only part of your application that would be readable is plain text used by the application.
Static linking only makes your executable larger and if you are using functions that other applications call in the DLL then its a waste of space.
Anyone wishing to reverse engineer your work would have to do significantly more than just replacing a DLL.
The binary is not human readable. It would require someone with a disassembler and a good understanding of the target assembly language to start reverse engineering.
-
@Wowalive
Well it won't do anything about being able to see your resources. You would have to start by not supplying resources, or external resource files, without encrypting them. Which makes resources unusable in your code, other than as a means to distribute encrypted binary data which would have to be unencrypted in memory, if the relevant Qt calls do not demand a file/resource for whatever operation.But I've absolutely no idea how to achive that static linking for my application, especially no "easy" way. Do i need to build Qt from Source for that?
I don't think TQtC distributes static builds, at least not for Windows; and usually when people do not say anything about platform in their questions they assume Windows.... So I imagine, yes, you would need to build Qt statically from source yourself. I stand to be corrected if I am wrong about this.
There are many hits if you Google for
qt static libraries, e.g. https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW and many others. -
@JonB , if anyone with has a commercial license for Qt then they have a choice of either shared object library linkage or static.
-
The Qt Company does not provide static builds.
Perhaps commercial customer can request them but to the best of my knowledge it's not part of the CI.
Some of the reasons (educated guess) for not providing static builds beside the size, additional build targets, tests and thus load on the people and infrastructure is that there are constraints for the GPL and LGPL that makes the use of static builds less than practical.
-
The Qt Company does not provide static builds.
Perhaps commercial customer can request them but to the best of my knowledge it's not part of the CI.
Some of the reasons (educated guess) for not providing static builds beside the size, additional build targets, tests and thus load on the people and infrastructure is that there are constraints for the GPL and LGPL that makes the use of static builds less than practical.
-
@SPlatten said in Protecting app against reverse engineering through static linking:
the libraries were already built
But by whom? I don't think the Qt Online/offline installer provides static libs (not even for commercial users).
-
@SPlatten said in Protecting app against reverse engineering through static linking:
@JonB , @SGaist , Where I have been at clients with commercial licenses I have used static builds and I'm pretty sure the libraries were already built, this was using 5.12
as a commercial user myself I can say, with certainty, the qt company does not provide out of the box static Qt builds. The only exception here is iOS where dynamic linking is nearly impossible and the QtC therefore doesn't provide dynamic linked libraries
-
@SPlatten said in Protecting app against reverse engineering through static linking:
@JonB , @SGaist , Where I have been at clients with commercial licenses I have used static builds and I'm pretty sure the libraries were already built, this was using 5.12
as a commercial user myself I can say, with certainty, the qt company does not provide out of the box static Qt builds. The only exception here is iOS where dynamic linking is nearly impossible and the QtC therefore doesn't provide dynamic linked libraries
-
@J-Hilk , in which case someone at those premises must have built the static libraries from the source.
-
We use static linking (Qt self compiled on Windows) because we had trouble with deployment using DLLs (people tend to screw it up).
The only reason I see for using static builds for obfuscating your code is that you can strip symbols from your binaries. In static builds the computer does not have to know the function names. DLLs need them so you can look up functions by their names. Therefore, you cannot strip DLLs of their symbols. In this way your code could provide a lot of information to reverse engineers if you use meaningful function names and use short functions.
I suppose that Qt itself is not a trade secret. So, I don't see a point in statically linking Qt. You want your own code disguised and not calls to third-party code. This means you only need to make sure that your own code is statically linked and does not include function names. Not sure how the latter is done on Windows, though.
-
Ok thanks for your replies. For me it seems that the efford-benefit ratio is not that high for using static linking as a protection against reverse engineering.
Especially our app runs on all platforms (Linux, MacOs, iOS, Windows, Android) and it seems that I have to build Qt from Sources for all platforms, right? Correct me when I'm wrong, but imho static linking isn't that easy to implement in my case and must be constantly maintained.Furthermore I have read that there is no way to statically link when using WebEngine. Is this still a fact? We are using Qt 5.15 LTS and WebEngine is a main part of our application.
If my assumptions are correct, i tend to turn to other methods of obfuscation/protection.
-
Ok thanks for your replies. For me it seems that the efford-benefit ratio is not that high for using static linking as a protection against reverse engineering.
Especially our app runs on all platforms (Linux, MacOs, iOS, Windows, Android) and it seems that I have to build Qt from Sources for all platforms, right? Correct me when I'm wrong, but imho static linking isn't that easy to implement in my case and must be constantly maintained.Furthermore I have read that there is no way to statically link when using WebEngine. Is this still a fact? We are using Qt 5.15 LTS and WebEngine is a main part of our application.
If my assumptions are correct, i tend to turn to other methods of obfuscation/protection.
@Wowalive said in Protecting app against reverse engineering through static linking:
I have to build Qt from Sources for all platforms, right?
Right.
Furthermore I have read that there is no way to statically link when using WebEngine. Is this still a fact?
Yes: https://doc.qt.io/qt-6/qtwebengine-platform-notes.html#building-qt-webengine-from-source
-
@Wowalive said in Protecting app against reverse engineering through static linking:
I have to build Qt from Sources for all platforms, right?
Right.
Furthermore I have read that there is no way to statically link when using WebEngine. Is this still a fact?
Yes: https://doc.qt.io/qt-6/qtwebengine-platform-notes.html#building-qt-webengine-from-source