4 ms·

“How I discovered an Easter egg in Android's security”

48 points by atomlib 8y ago

alvalentini 8y ago
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 8y ago
Wait, the interviewer asked you to "develop a Base64 algorithm", on the phone? That's hardcore.
- Boulth 8y ago
  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 8y ago
    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.
- kerng 8y ago
  Pretty simple, easy to understand question. I wouldnt consider this hardcore - but over the phone it doesnt make much sense to ask such questions. Hope there was at least a Zoom or Skype meeting or something.
- localhostdotdev 7y ago
  require 'base64'; Base64.decode64("Z29vZ2xlLXByb29m") very easy /s
ops4c0d3 8y ago
Awesome read!
peter_d_sherman 8y ago
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.
ebg13 8y ago
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

48 points by atomlib 8y ago

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 8y ago

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

Boulth 8y ago
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 8y ago
  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.
kerng 8y ago
Pretty simple, easy to understand question. I wouldnt consider this hardcore - but over the phone it doesnt make much sense to ask such questions. Hope there was at least a Zoom or Skype meeting or something.
localhostdotdev 7y ago
require 'base64'; Base64.decode64("Z29vZ2xlLXByb29m") very easy /s

ops4c0d3 8y ago

Awesome read!

peter_d_sherman 8y ago

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.

ebg13 8y ago

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