Protecting app against reverse engineering through static linking

Wowalive

Static linking was just the first step I stumbeled over while grappling with the topic of protecting the app against reverse engineering.

JonB

@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.

SPlatten

@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.

SPlatten

@JonB , if anyone with has a commercial license for Qt then they have a choice of either shared object library linkage or static.

JonB

@SPlatten
Oh, so TQtC supplies punters with already built static libs if that's what they want? I saw stuff saying you had to build static for yourself, but perhaps that didn't take into account having a commercial licence?

SGaist

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

@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

jsulm

@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).

J.Hilk

@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

@J-Hilk , in which case someone at those premises must have built the static libraries from the source.

SPlatten

@SGaist , another reason I have previously gone for static builds is it makes deployment a lot easier without having to be concerned about including all the required shared libraries.

SimonSchroeder

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.

Wowalive

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.

JKSH

@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

@JKSH Thank you. The fact that QtWebEngine does not support static builds speaks against implementing static linking for our app.