Protection of QML code

chall3ng3r · wrote on 15 Oct 2011, 04:06

Hello all,

I have been exploring QML a bit and found it to be really good for development across devices. Loving it so far.

I have a concern about the protection of the QML code we put into our apps. I know many would say that one should mix the code with Qt C++ so the app wont be only QML code, so if anyone copies it, it wont work without the parts from C++.

But I for one can see a developer can make an app or game entirely in QML. Which is pretty good, no need to get into hard C++ parts :)

But as QML files are just packed along, there's no compilation is applied on QML, so any advance user can just use unpacking tools (i.e. SIS and DEB file can be easily unpacked) to get the fully working QML files, and can steal code, crack serial number protection etc.

I know there's one option to put the QML files inside the resource file, so they will be not just plain text files, but then we have to put rest of the app resources inside the same resource file as well, and there's memory errors when we load too much inside one resource file.

My suggestion to the Qt team is to provide a plugin for the Qt SDK, which encrypts the QML files and put them inside a container, and then at runtime, unpack the QML in memory to run them.

Another option is to provide an option to actually cross-compile the QML files against selected platform (Symbian / MeeGo / PC) to make a native binary of the app. When I first read about the QML I thought it was cross-compiling the QML to native.

I personally like the second option of natively compiled binaries as they will provide more performance boost, as well as same level of protection we get from regular C++ compiled apps.

Are there some easy solutions already available to this?

What you guys say?

// chall3ng3r //

raulgd · wrote on 12 May 2012, 16:58

it sucks that nobody answered the question, this is a real and big problem for app distribution.

the resource file schema is a problem, as resource files can be decomposed (under windows at least) and the code can be read, and even a bigger problem if you want to create custom commercial components for QML, then there's no way to protect the IP

paker · wrote on 12 May 2012, 17:14

I think it's because I'm addicted to C++ but I knew this QML thing would go wrong someday.
Nobody thought in the commercial applications.
It would be helpful if there was something like those PHP obfuscators that makes the code unreadable and then somehow eval it at runtime.

Wilk · wrote on 12 May 2012, 21:34

Hello
I think that's not a problem. AFAIK, QML was developed to make it easy to create modern UI. So if you need to implement some "secret" logic, use C++. It won't be hard while you're using Qt.
Another suggestion: if it's possible to use QML code that's stored as QString, then encrypt it and add as a resource. Then add a small function, that decrypts it on app startup.

[quote author="chall3ng3r" date="1318651607"]crack serial number protection etc.[/quote]

I think it's silly to implement serial number protection in QML.

paker · wrote on 12 May 2012, 22:28

I understand your point Wilk, and i agree with it. But it is indeed a good feature to be added in Qt, at least in the commercial version. A company, for example, may not want to use QML because they are afraid of distributing part of the source code with the application.
My boss don't understand how Qt works, and even if i try to explain to him, he would rather use pure C++ than QML to make the UI.

lgeyer · wrote on 13 May 2012, 10:08

Binary QML* is under development.

* support for translating QML into a corresponding binary data structure at compile time (rather than letting the Qt Quick engine do it during application start-up), for IPR protection and reduced application start-up time
[quote author="aalpert" date="1335837663"]Already done ;) . The only thing missing is allowing the compile phase to be run separately to instantiating the scene, so that the binary data can be stored.[/quote]

miroslav · wrote on 23 May 2012, 13:04

In the meantime, you can use the Qt resource system to link the QML files into the program binary. This requires at least some skill to extract the QML files, compared to having them on the file system.

raulgd · wrote on 26 May 2012, 00:11

@Wilk implementing QML UI logic (like custom UI functionality only components) in C++ for protection is impossible as there is no C++ API for accessing QML stuff (that's a controversial hot topic on it's own), so there's no way of doing that

@Lukas where's the info about binary QML? that sounds really nice.

Is it in any official documentation? is there a date or release number (Qt5 perhaps ;) for the implementation of that?

jdavet · wrote on 28 May 2012, 11:09

I'm not sure if IPR protection for QML is really such a big deal.
After all, most non-trivial Qt Quick applications will most likely tightly integrate C++ backend functionality with the QML frontend/UI description. Even if a hacker / power-user extracts the plain-text QML resource from the .exe, he won't be able to do anything useful with it.

The only issue I can imagine is if self-contained algorithms inside the QML (JavaScript functions or GLSL shader effects) need to be protected at all cost.

In any case, if you really want to encrypt/obfuscate your QML, just so it yourself (there should be enough cryptography C++ libraries out there which you can use).
You can probably let your build system automatically do the encryption before embedding the QML files as resources in the executable, and do the decryption in your C++ code and then load the decrypted QML from QString like described here: http://lists.qt.nokia.com/pipermail/qt-qml/2010-November/001771.html

[quote author="Raul" date="1337991104"]implementing QML UI logic (like custom UI functionality only components) in C++ for protection is impossible as there is no C++ API for accessing QML stuff[/quote]

Why would you need a "C++ API for accessing QML stuff" for that?

It works the other way around: You can do your UI logic in C++ by implementing full QtQuick components or data-models models in C++, and then access them from QML. And yes, components can be "functionality only", they don't have to render anything.

[quote author="Raul" date="1337991104"]where's the info about binary QML?[/quote]

The statement which Lukas Geyer referenced is a quote from Alan Alpert (part of Nokia's Qt development team), and can be found here: http://qt-project.org/forums/viewreply/84245/

[quote author="Raul" date="1337991104"]Is it in any official documentation? is there a date or release number (Qt5 perhaps ;) for the implementation of that?[/quote]

No, nothing official as far as I can tell, it was just a statement that implementing this would be possible and wouldn't be opposed by the Qt Quick team, however "no-one has gotten around to it".

lgeyer · wrote on 31 May 2012, 05:31

[quote author="jdavet" date="1338203359"][quote author="Raul" date="1337991104"]where's the info about binary QML?[/quote]The statement which Lukas Geyer referenced is a quote from Alan Alpert (part of Nokia's Qt development team), and can be found here: http://qt-project.org/forums/viewreply/84245/[/quote]

Additional bits of information can be found on the mailing list "here":http://www.mail-archive.com/development@qt-project.org/msg03352.html and "here":http://www.mail-archive.com/development@qt-project.org/msg03395.html.

raulgd · wrote on 5 Jun 2012, 22:34

bq. After all, most non-trivial Qt Quick applications will most likely tightly integrate C++ backend functionality with the QML frontend/UI description. Even if a hacker / power-user extracts the plain-text QML resource from the .exe, he won’t be able to do anything useful with it.
The only issue I can imagine is if self-contained algorithms inside the QML (JavaScript functions or GLSL shader effects) need to be protected at all cost.

Not really, as you can see, QML will be all about components (Like desktop, meego or symbian), and if you build commercial components (there's actually market for that on Qt with commercial widgets), then it would be a good idea to protect that IP.

bq. In any case, if you really want to encrypt/obfuscate your QML, just so it yourself (there should be enough cryptography C++ libraries out there which you can use).

If there's a real need for protecting the IP of applications (which I'm pretty sure there is, at least for closed source apps), then why not just having it built in.

Binary QML seems nice, I just hope that other developers using QML will have the need so that it's implemented sooner. I'd help but I wouldn't know where to start, the Qt source code is quite a mouthful.

jdavet · wrote on 6 Jun 2012, 14:43

[quote author="Raul" date="1338935644"]Not really, as you can see, QML will be all about components (Like desktop, meego or symbian), and if you build commercial components (there's actually market for that on Qt with commercial widgets), then it would be a good idea to protect that IP.[/quote]

But do you expect many non-trivial commercial Qt Quick components do be written in pure QML+JavaScript?

Again, note that custom QtQuick components can be written in C++, and for complex components this is actually recommended.

[quote author="Raul" date="1338935644"]Binary QML seems nice, I just hope that other developers using QML will have the need so that it's implemented sooner. I'd help but I wouldn't know where to start, the Qt source code is quite a mouthful.[/quote]

True, unless the people who designed Qt Quick get on board, I suspect it would probably be difficult to add this feature.

In the meantime, another possibility is using a generic executable compressor/obfuscator on the binary that embeds the QML source code: http://en.wikipedia.org/wiki/Executable_compression

raulgd · wrote on 29 Jun 2012, 18:43

[quote author="jdavet" date="1338993791"]
But do you expect many non-trivial commercial Qt Quick components do be written in pure QML+JavaScript?

Again, note that custom QtQuick components can be written in C++, and for complex components this is actually recommended.
[/quote]

I don't expect pure Javascript apps, but I do expect pure QML UIs. And again, as I said before, you should research C++ support, because I see you have no idea that you CANNOT build QML UI with C++, you can't build components, animations or anything in C++, if you want a QML UI, it has to be QML only, so if you build commercial QML components, they can only be written in QML.
I emphasize QML UI, no real business logic there, all of the models will be built in C++, but the UI components can only be QML.

andre · wrote on 2 Jul 2012, 11:49

Sorry, but: no. That is simply not true. Did you even look at the C++ API to create QML components?

lgeyer · wrote on 2 Jul 2012, 12:00

... and the Animation Framework and the State Machine Framework.

mbrasser · wrote on 6 Jul 2012, 05:55

It would be great to see this added as a suggestion on http://bugreports.qt-project.org -- that should give it a better chance of being looked at, scheduled, etc.

Regards,
Michael