How easy is it to reverse compile a QT application, vs. an MFC application?
Hello C++ Gurus,
I have heard incredible things over and over again about Qt on online forums (like its the only C++ platform people should use anymore, and MFC programmers should switch), and I love the idea of creating the first application of my life that works on a system other than Windows, but am worried about Qt's ease of reverse compilability (as compared to MFC's reverse compilability) due to the following two relatively disturbing articles on the web:
How easy is it to reverse compile a production Qt application compiled in release mode (or compiled with whatever other compiler flags or protections can be set from within the Qt development environment)?
Is a production Qt application easier to reverse compile than a production MFC application on Windows?
Is a production Qt application easier to compile on Android, iOS, MacOS, or Linux than a Qt application on Windows, i.e. is there a platform that is a weak link that competitors can use to relatively easily reverse compile a production Qt code?
I plan on using static linking with the commercial license if that makes a difference.
Some background... I am starting a project with a requirement that the code is relatively hard to reverse compile, in order to make it as hard as possible for competitors to copy the logic of the application. I know that all compiled code can be reverse compiled, but I would like it to be as time consuming and painful as possible, and I would like the reverse compiled code to be the worst representation of the code as is possible. I consider C# and Java to be too easy to reverse compile even when the code is obfuscated, whereas I consider MFC applications and native C++ applications adequately hard to reverse compile for my purposes.
Thank you very much in advance,
I won't tell you which is easier to decompile, as I don't know. Most people don't care too much, apparently, even the big players (Google, Skype) use Qt for their software. The meta object system might indeed offer some hints when decompiling, but I am really only guessing here.
To protect your binaries, you can use some third part tools: LLVM obfuscator ("link":https://github.com/obfuscator-llvm/obfuscator) or SafeNet LDK ("link":http://www.safenet-inc.com/software-monetization/sentinel-ldk/).
Thank you for your help and ideas.
Do objects that are not QObjects, and that lack the Q_OBJECT macro, compile without any more meta-data than native C++, or does Qt produce meta-data even for these non-QObjects?
I won't be able to use Qt in a commercial setting ($399/month less for digia, sorry digia) if there isn't a way for some cross-platform Qt code to be as non-reverse-compilable as MFC. Does somebody from digia have any thoughts on this? I really want to use Qt instead of MFC if it's possible to hide most of my hard work.
Thank you in advance,
No, Qt does not inject any magic into C++ code. Actually, even the meta object information is just standard C++ code (the meta object compiler is only a code generator, after all). I think that you are worrying prematurely. And to be sure, you should check yourself with a small test application written in both MFC and Qt.
To get an answer from Digia, please contact them directly. This forum is used mostly by Qt users.
I'm the author of the hackeverything.wordpress.com blog post mentioned above. I've also been reverse engineering code for a lot of years. Most modern object oriented languages have support for runtime type information inspection. If there's support for that sort of thing at runtime then there's always going to be some way to programmatically dig that information out.
For example, Objective-C also includes type information in the binaries and there are programs like "class-dump":http://stevenygard.com/projects/class-dump/ that will basically dump complete header files for the code.
Doing a quick search for MFC and RTTI it seems like MFC code also has runtime type information.
I'm sure someone determined enough could figure that information out as well. The only way to stop reverse engineering is for the code to not be there. So maybe it's possible you keep certain critical logic sections on a server and your desktop app makes calls to it?
Qt is a great toolkit! I certainly wouldn't let reverse engineering concerns stop you from using it. I've been a long time Mac user and seen some really horrible Windows ports to Mac. Qt apps though really seem to work well. So go for it!
scknight and sierdzio,
Awesome posts, thank you so much!
Your perspectives about reverse compilation has helped me accept the unfortunate reality of reverse compilation and go ahead and give Qt a shot.
My entire career since 2000 has been 100% Microsoft development, so I am being extra cautious about making a major commitment of time and money.
For sure MFC does in fact support C++'s RTTI, but if I understand correctly, the Q_OBJECT macro and QObject metadata makes for an easier and more information rich reverse compilation due to the inclusion of plain text class names and class member names in the compiled production exe.
I am going to take scknight's advice and not let it stop me from at least attempting to switch from the Microsoft-only world I've been living in and give Qt a try. Very exciting.
Thank you both for your forum posts, and thank you scknight for your superb article. See you both in the Qt forums!