Well "fork over" comes from the system call fork() which creates a new process. "Shell out" as explained by the author means to run an external shell command, which has been implemented in some languages by forking a shell, and then spawning the process. fork() is known as so because it results in a hierarchy where there is a parent process and a child process, and so forth. Shell just seems to be a general term for an interface used to operate an OS. [0] So no, just a coincidence.
Null-A is probably the Van Vogt's most famous book, but others are great as well, I loved "Slan" from the same author : https://en.wikipedia.org/wiki/Slan
didn't expect anyone to mention this book... but it's been a long time favorite of mine. I first read it in my teens, when I was heavily into asimov, vance, dick and other classics :)
Totally different incentive. Spotify only needs protection that's enough of a pain the the ass to make it easier to just get the content from somewhere else or perhaps just pay the $n.99 for it.
Snapchat is full of (supposedly private) information that is not available anywhere else. Attackers will be far more determined.
See links for a bit of reading about how hard it is to break DRM on Spotify or Netflix. They're doing a lot more than Snapchat. The difference between "you just need to reverse engineer the HTTP API to make a 3rd-party client" and "you need to run IDA Pro and PANDA and whatever else" is significant. The latter exploit would have far less reach.
I read through the Spotify article, and if I understood it correctly, you don't need to run QEMU+PANDA to get at the unencrypted stream. That was just the method the author chose to analyze the running code. He tracked every memory read and write made by the CPU, and looked for byte distributions that looked like encrypted data, and found the decryption function at address 00719b84. He then located that code inside the Spotify binary, at 0x0042e2ed.
Once you know that, you don't need to repeat the initial analysis every time. You can just set up a hook to record all the data that flows through that function after it's decrypted.
Yes, that's my understanding as well; my other comment was sloppy. I'm unsure what was meant by "hook," though. Is that something you set up with the target process running under a debugger? That much privilege wouldn't be available to apps in an app store, right?
I meant "hook" in the most vague, hand-wavy sense of the word… anything from attaching a debugger at runtime, to modifying the binary so it automatically saves every song on your desktop. Obviously if you did something like the latter, no extra privilege would be needed.
I wonder how they "confirm[ed] out of email that the keys we exchanged were not intercepted and replaced by your surveillants." Key exchange is the hardest part.
I think the weak link in the chain is only after decryption, but before uncompression (for lossy formats, so books excluded). See, for example, [1] and [2], where the authors look at randomness and entropy measures of I/O to find where the decrypted-but-compressed buffers are.
