[Interest] QML preprocessing

Roland Hughes roland at logikalsolutions.com
Sun Apr 28 20:27:31 CEST 2019

On 4/28/2019 11:31 AM, Konstantin Tokarev wrote:
> 28.04.2019, 19:15, "Roland Hughes" <roland at logikalsolutions.com>:
>> If you are worried about a sensitive value being memory dumped because
>> of a completely insecure scripted language, then don't do it there.
> If some data is copied to memory it can be dumped from there, no matter
> what language are you using. There are no "secure" and "insecure" languages
> in this regard.

Sure there are.



Most importantly, by placing all of the sensitive data used only for 
debug in C++ class methods bounded by #ifdef DEBUG statements, in a 
production release the copy will never happen.

The scarier architectural problem with the original post is the 
console.log() call is calling something to convert a password to "free 
text" rather than dumping a hashed/encrypted version. Most production 
applications never bother with this. They compare a hashed/encrypted 
version of the entered password with the hashed/encrypted version stored 
on disk.

Scripted languages are inherently insecure.  With QML and JavaScript you 
end up with stuff like this in your elf binary.

DefaultButton {
     id: helpButton
     text: qsTr("Help")
     iconSource: helpButton.pressed ? "/Images/help_pressed.png" : 
     iconSizeX: 17
     iconSizeY: 24
     onClicked: {

I found that in a few seconds with Eclipse. Any number of "text" editors 
will let you open and view binaries. The amount of code and logic 
actually exposed to anyone willing to edit a copy of the file is 
immense. Not so with compiled C/C++ or even COBOL for that matter. If 
you are really worried about things like "Password" being found you have 
multiple options.

1) Under Qt use tr("1234") and always have a translation file, even for 
your native language.

2) Under any compiled language build the string programatically from Hex 
strings. FWIW, the Hex values for "Password" are 50 61 73 73 77 6F 72 64

With a scripted language there is little you can do to avoid exposing 
your code. Yes, there is an option to "precompile" QML but it comes with 
significant limitations.


The most significant of which is being tightly bound to the version of 
QML compiled against. For an embedded system where you control the 
universe this could be acceptable. For an app which anyone can download 
and run it is not. If you developed under 5.2 and didn't use anything 
which disappeared in 5.12 you still want the user to be able to run your 
app. The inverse is true as well. Just because you used 5.12 doesn't 
mean you used something which only existed in 5.12.

Under various operating systems (OpenVMS in particular) one can tell the 
compiler for the language of choice to place all string constants within 
a single PSECT or a series of them. In your linker options the named 
PSECT(s) can be flagged with an attribute which excludes them from dump 
utilities. These principals have been around since the 1980s when I 
started programming commercially on big-boy systems. Didn't matter if we 
were working in COBOL, FORTRAN or BASIC, we always had linker option 
files to flag string constant PSECTs as nodump. Even if the midrange or 
mainframe was air-gapped from the world we still did this. Back then we 
were only worried about dial-up access, the Internet did not exist in 
any meaningful way.

With a scripted language you cannot do this. You are at the mercy of the 

It would be interesting to see just how much text survives in 
pre-compiled QML. I would imagine it is a lot. If the QML engine is 
OpenSource then it isn't a difficult task for someone intent on gaining 
passwords via a dump or cache file on disk to find the text "Password" 
and decompile everything around it. They can't get back to the original 
source, but they can get close enough.

Basically, if your application must be secure you cannot use a scripted 

Roland Hughes, President
Logikal Solutions
(630) 205-1593


More information about the Interest mailing list