How I cracked NQ Vault's “encryption” | Hacker News Reader

How I cracked NQ Vault's “encryption”

ninjadoge24.github.io

279 pointsninjadoge2459 comments

NQ Mobile is not really new to some sloppy ethics.

http://www.forbes.com/sites/afontevecchia/2013/10/24/nq-mobi...

link to original muddywaters research: http://www.muddywatersresearch.com/wp-content/uploads/2013/1...

NQ Mobile buys cheap installs in under developed countries where there are no in app purchases (Or very low).

The same technique is followed by several Chinese mobile companies. I don't think its well understood why these companies are buying installs and where the money is coming from.

Here are the top ten Tool in India. 8 of 10 are by Chinese companies (Primarily by buying Installs. I am not saying all of them but most of them are). India and China have Conflicts. Tools is one category that require scary permissions.

http://i.imgur.com/3JGtnre.png

It is interesting to consider if this was bred from sloppy ethics or ignorance. It would not shock me to find that someone really thought that this is good enough "security".

That being said, those that do not have the skills to realize that this is not sufficient need to reach out to those that do. If you organization does not have security staff, then a contracted audit is necessary. If someone is producing a product and are trying to claim it is secure, ignorance of what secure actually is, is not an excuse.

How are they still trading? I am seriously asking, what sort of thing would cause them to be de-listed?

Hey let's actually do something about this: go to the play store and leave a 1 star review saying something like "this app doesn't encrypt anything, <non-technical explanation>".

https://play.google.com/store/apps/details?id=com.netqin.ps

There are already a couple of comments by people who obviously read this article, please upvote them. I mean, you have to install it but I just told it to install it on a phone that broke years ago ;-)

Edit: formatting

Impossible, requires a G+ account..

So, the app might suck, but where can I rate the play store experience with a single star?

If true, this also shows the TRUSTe privacy seal is worthless. The name implies it's undergone some kind of assessment that showed it's good for privacy when just looking at an encrypted file would immediately show the problem. TRUSTe itself is a bit vague on what they really do.

https://www.truste.com/business-products/dpm-services/#pCert

I can't find NQ in their search tool for certified companies. Perhaps it's been retracted or was never really issued? Maybe I'm looking in the wrong place

https://www.truste.com/consumer-resources/trusted-directory/

Never trust a website just because it has a seal of approval from an organization like TRUSTe.

I routinely perform code and web app audits on companies that proudly bear this seal and find security flaws that will compromise users. The seal means nothing.

Pretty much all the seals you see on the bottom of a website are worthless. Nobody ever does an actual code audit. But it makes the users feel safe, so that's what matters.

https://www.truste.com/business-products/enterprise-privacy-...

It'd be nice to see the fake tech journalists/reviewers issue a retraction, or even Google Play get involved as this is rather much like fraud.

And also, what does the developer even gain from using XOR? In most common frameworks, using, perhaps incorrectly, AES is about the same effort.

I could understand this being a tough position from google's perspective. When talking about how secure something is, one has to consider the threat model - there is not absolute. If the goal is to keep naughty pictures confidential from one's mother - this may indeed be "secure" enough for that situation. Keeping blackmail photos safe from a nation state on the other hand, likely not.

I do not think that we currently have a good way as product creators to specify what secure actually means - and what is more - our customers won't understand the nuance either.

This is in no way trying to excuse passing this "encryption" scheme off as secure.

XOR is the appropriate operation if you're using a stream cipher to generate an arbitrarily long keystream. Or a one-time pad. It also makes random access a lot simpler.

Of course, you do actually need to generate that keystream and not just repeat a short key.

There are very few cases where you should be doing encryption without authentication... and as soon as you're doing authentication you'll be doing more than just xoring with a stream cipher output. :)

I believe they might have done it this way so they can claim 'encrypts a 100gb file in under 100ms!' or something equally dumb.

It is a Chinese company, so it isn't beyond belief that the Chinese government asked them to make the encryption "reversible" and doing it correctly was behind their technical know-how.

I don't know if this falls under fraud. It is a form of encryption, albeit minimal to a ridiculous degree.

A couple summers ago, myself and some fellow interns were considering looking at android file vault applications as a research project. We downloaded a bunch of the top rated free ones and they were all universally crap. I think the most secure one just ran the entire file through a substitution cipher. There were plenty of others that would just swap the file header with something else, or just XOR the file with some constant value. When I read this blog post, all I could think was "Yeah, looks about right".

Relevant xkcd: https://xkcd.com/937

"Google it up if you want to: NQ Vault. I don't wanna link it form here."

Please do link it, if only to put your readers 1 click away from giving it bad but honest ratings. Do this also for search engines to find and associate your post with the app. Such bad software needs to be exposed. So here it is: https://play.google.com/store/apps/details?id=com.netqin.ps

Give a man the assumption he is safe and he will lower his guard. There is no reason to not believe the algorithm used is intentionally marketed as safe but is in fact not. From the top of my head I can think of numerous three-to-four character organizations which would benefit from people thinking they have secured their data when they in fact have not.

> I can think of numerous three-to-four character organizations which would benefit

But this encryption is laughably simple. Those organizations would probably encourage at least somewhat better security. From their point of view the best possible situation is if they can read the data but non-state actors can't.

The Play Store page basically implies that the kid is seven-timing his GF. Interesting.

I noticed the app got updated today... Wonder what the bug fix was

Maybe someone know better alternatives? I would like to hide/lock some images (bank passwords card images).

hahhaha (sadness)

Using XOR is terrible. The fact that they only apply it to the first 128 bytes of the file is even worse.

I think the author is overreact / grandstand, it's not fair to say this app encrypted nothing - I decompiled the code and found it at least does encrypted the SMS/Call logs data, using AES. Secondly,maybe only XOR the front 128bit for video/image files is not secure enough, but anyone who has a brain knows that, considering the computing power of most Android phone, using strong algorithm to encrypt a whole media(e.g. video) file is hardly realistic, even unwise -- unless you can tolerate a long decrypting decrypting process before playing a video. BTW, I read through the description of Vault Google Play page, there is nothing says it sales the ability of encrypt data, it just claims to "Hide some xxx on your phone" -- for that purpose XOR is enough

Don't most popular video formats essentially store certain frames as complete images, and then store frame to frame differences to cover the video between frames?

If so, I wonder how effective it would be to encrypt just the complete frames, leaving the frame differences for the in between frames unencrypted?

That would not be very semantically secure; while you could not see exactly what the original image was, you could still make out the movement. That would sort of be the analog of the ECB penguin on moving pictures.

I think actually there is nothing worse than using XOR, full stop.

XOR is not, by itself, a problem. Heck, the most secure encryption method on the entire planet, the one time pad[1], is just an XOR of some secret bytes with a plaintext. XOR is also one of two fundamental building blocks of the current state-of-the-art AES-256 encryption algorithm[2] (the other being a series of bit shifts).

The problem here is deriving something so simple from the key, and only applying it to the first 128 bytes. This is unforgivably dumb, when there are perfectly serviceable encryption services available as part of open source libraries, such as the aforementioned AES-256 algorithm.

[1]: http://en.wikipedia.org/wiki/One-time_pad [2]: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Th...

XOR is only one implementation of one time pad, it is also commonly used with modular addition. If you do it with letters then it effectively becomes a Vigenère cipher with a long key.

The one-time-pad is a special case of any number of poly-alphabetic substitution ciphers, XOR just being one that happens to be implemented on lots of silicon. Considering this is all about an app that has very short keys (a few numeric digits) it's perfectly legitimate to criticise the use of a substitution cipher as they are especially poor when used with short keys compared to real crypto libraries that will use that short key as the passphrase for a real key.

Well it's not the XOR that's special, it's the secret part that is. Without the value being secret, it might as well not be encrypted.

When I said XOR I meant XOR with a one-byte key on every character of input. e.g.

    char* xor_encrypt(char* input, char key) {
        int i;
        int m = sizeof(input);
        output = (char*)malloc((int) m + 1);
        
        for (i = 0; i < m; i++) {
            output[i] = input[i] ^ key;
        }
        output[m] = 0;
        
        return output;
    }

A challenger appears:

http://www.cryptofails.com/post/87697461507/46esab-high-qual...

you could put a couple of NULLs in front of the file so its unreadable and claim its encrypted :)

Hey don't diss xor. If the key is at least as long as the message and is used once, it's unbreakable.

Well, to decrypt the xor'd data you need to keep the key around. So either you a) memorize the entire one-time pad for every file, or b) you encrypt the one-time pads with AES.

Now you have two encryption problems.

If only there was a way of generating a pseudorandom stream of bytes with which to XOR against based on a shorter randomly generated key...

That's the famous one-time-pad :)

Reply on news.ycombinator.com