News for hackers. Stuff that matters.
Re:“How I discovered an Easter egg in Android's security” by peter_d_sherman on Friday April 05, 2019 @03:51PM (#19586345)
Hi Andrei, first of all, great story! Sorry about your Google interview (if I ran a tech company and interviewed you I'd have hired you in a heartbeat!). You apparently had to deal with a prima donna, egocentric, rank-and-file programmer/interviewer, whose opinions about your value as a potential hire can be summed up as "does the candidate know exactly the same things as me in the very narrow technical sub-niche area in which I work?". You do not want to work for such a person. You want to work with (not for) people with much broader minds (Paul Graham, Joel Spolsky, ?) than that.

Now, that aside, let's talk about what Google is probably doing.

The way to understand it is to understand a very significant problem.

Let's say that I am Netflix, for example. And my goal is to prevent people from pirating all of my great (and costly) video content.

If the content is unencrypted, then it's easy for people to pirate those streams.

But now, what if we encrypt the content using one globally-used encryption method?

Well, if we encrypt it that way, the decryption code must be part of whatever client program is being used... a smart pirate could potentially reverse engineer the client program, and extract (and use) the decryption code. Once that's done then "the cat's out of the bag" proverbially speaking, that is, the same code can be re-used, and all of Netflix's streams can now be pirated by whoever wants to pirate them.

We could encrypt each stream using a standard encryption algorithm, but with a different key each time. This is somewhat better, but that assumes that the key can't be recovered somehow, which is a terrible assumption.

So what's the best solution?

Why not use an obscure, unique encryption algorithm for each stream, and have the client download different decryption code each time, for each stream?

This way, if the code used to decrypt one stream gets leaked to everybody, everybody can't use it to decrypt their custom-encrypted streams!!!

How do you implement this?

On the client side, you implement a virtual machine which is going to do the decryption. Then you send the unique virtual machine code which implements the unique decryption algorithm for the one and only one stream you're going to send!

You do this each and every time, with a different, unique decryption algorithm for each stream.

This, or something like this, is what this code appears to be doing. (It might not be for a video stream, it might be for any data that Google might want to keep encrypted, for any reason... heck if someone really wanted to go crazy they could encrypt nested VM code inside of encrypted nested VM code -- and this could go on to N levels deep! <g>)

(You discovered this by disassembling the code; I figured this out years ago (because I might need this for a future business) by looking at the problem->solution->problem->etc. chain...)

Either way, you don't want to work for that guy at Google.

Take my word for it, you're Google-smart, even if Google doesn't think so.

Re:“How I discovered an Easter egg in Android's security” by hcs on Friday April 05, 2019 @08:45PM (#19588416)
But you still have to send the decryption algorithm, right? It's essentially a funkier key?
Re:“How I discovered an Easter egg in Android's security” by esrauch on Saturday April 06, 2019 @11:57AM (#19591366)
Yeah, the main difference is that usually these vms can be deliberately written to be nonportable to things like emulators and headless browsers, making it a lot harder to just execute the same code at scale.