
“How I discovered an Easter egg in Android's security” - atomlib
https://habr.com/en/post/446790/
======
alvalentini
Love the story. That's quite interesting. Also, I wonder if this thing with
hiding stuff in product to pre-selects possible candidate is something that HR
does to improve recruitment or something that came from the devs.

------
duiker101
Wait, the interviewer asked you to "develop a Base64 algorithm", on the phone?
That's hardcore.

~~~
Boulth
Is it? I guess anyone that read the RFC or saw one implementation can easily
reproduce it from the top of their head. Of course some details can be fuzzy
and it's not that easy under stress but base64 is definitely not rocket
science.

~~~
puzzle
As with most coding questions, the important parts are when you start looking
at corner or edge cases. Or when you refine your initial implementation.

------
ebg13
Side note to Andrei: If you care about keeping your email address hidden in
the screenshot, don't just blur it. Blurring text is not sufficient for
privacy. See for example
[https://news.ycombinator.com/item?id=8078747](https://news.ycombinator.com/item?id=8078747)

------
peter_d_sherman
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.

~~~
hcs
But you still have to send the decryption algorithm, right? It's essentially a
funkier key?

~~~
esrauch
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.

------
ops4c0d3
Awesome read!

