Protecting app against reverse engineering through static linking
-
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