Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analysis of Obfuscation Techniques Found in Apple FairPlay

nicolo.dev

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#31

Post by mike_hearn »

nicolodev wrote: post #22
mike_hearn wrote: post #19

Earlier quoted context omitted.

RA tells Apple what software stack you're running and that it's not virtualized (genuine hardware device). Therefore, you no longer need software obfuscation because: 1. The software is now tamperproofed (server won't release content key unless the RA contains an expected hash) 2. The memory space is protected from being read from other processes, so there's no need to try and hide the processing of secrets in the co…

Thanks for the detailed explanation. > The software and hardware stack does itself need to be secure of course Oh this is what I'm missing. It's a huge assumption that I wish that can be true!

Is it not true? Not everything needs to be secure, just the right parts. The test is whether you can jailbreak the devices and not be detected by their RA scheme. As far as I know, there's no (public) way to do this.

BTW, this tech isn't new. In practice if you are vertically integrating, it's possible to make things secure enough. Games consoles have been doing this for years. Even in the Xbox 360 era, the use of local exploits was detectable the moment you connected to Xbox Live, and AFAIK Xbox One remains completely unmoddable/unjailbroken even after a decade into its lifespan.

There's a tech talk here by a member of the Xbox team who talk about how they secured it against physical attack:

https://www.youtube.com/watch?v=U7VwtOrwceo

But bear in mind, RA was never the weak point even of the 360.

Making remote attestation secure is a well studied problem in the industry. It's been done several times. You have to be a competent tech firm producing your own hardware/software combos, and you need a competent security team, but there are several companies that meet that criteria and Apple is definitely one of them.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#33

Post by mistrial9 »

mike_hearn wrote: post #13

I'm gonna go out on a limb and suggest that this obfuscation scheme is legacy, and they keep it merely as defense in depth and because it's tested so why not. Modern Macs can do remote attestations from a trusted boot chain all the way up to specific apps, which obviates the need for this sort of obfuscation. The memory spaces will be protected by the operating system as long as SIP is enabled, and if it's not enable…

Dear Sir - a "a properly implemented remote attestation and security architecture" is one aspect of computing, but ironically, Apple Computer built its empire on "personal computers" not military style ID checking.

constant "papers, please" to run My Own Computer is not what I purchased hardware to do.. signed -US Citizen

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#34

Post by nicolodev »

z8 wrote: post #32

Great read! As someone who has spent a good chunk of time looking at FairPlay code in the past, it was interesting to follow someone else’s chain of thought :)

Thank you so much! This comment made my day :) The concept about story-telling was to explain in detail how I thought. Despite that, I do agree with some previous comments, some parts are too much.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#35

Post by hooverd »

josephcsible wrote: post #21

> keeping the decryption key and the whole process secure to avoid the possibility of decrypting the contents of.ipa files to share the contents of an app (perhaps paid for) in the wrong hands > Technically speaking, if there were no protection measures, a person could copy the app installer1 and pass it on to any other person. Result? Loss of revenue on the part of Apple and the developer who published the applicati…

General purpose computing will always be an affront to rentiers.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#36

Post by drvdevd »

mike_hearn wrote: post #31
nicolodev wrote: post #22

Earlier quoted context omitted.

Thanks for the detailed explanation. > The software and hardware stack does itself need to be secure of course Oh this is what I'm missing. It's a huge assumption that I wish that can be true!

Is it not true? Not everything needs to be secure, just the right parts. The test is whether you can jailbreak the devices and not be detected by their RA scheme. As far as I know, there's no (public) way to do this. BTW, this tech isn't new. In practice if you are vertically integrating, it's possible to make things secure enough. Games consoles have been doing this for years. Even in the Xbox 360 era, the use of lo…

So from an attackers perspective nowadays it sounds like focusing on encryption weaknesses and/or hardware issues (e.g. glitching) or firmware vulnerabilities is the right place to look?

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#38

Post by mike_hearn »

drvdevd wrote: post #36
mike_hearn wrote: post #31

Earlier quoted context omitted.

Is it not true? Not everything needs to be secure, just the right parts. The test is whether you can jailbreak the devices and not be detected by their RA scheme. As far as I know, there's no (public) way to do this. BTW, this tech isn't new. In practice if you are vertically integrating, it's possible to make things secure enough. Games consoles have been doing this for years. Even in the Xbox 360 era, the use of lo…

So from an attackers perspective nowadays it sounds like focusing on encryption weaknesses and/or hardware issues (e.g. glitching) or firmware vulnerabilities is the right place to look?

I don't know much about Apple's hardware but at least consoles are secured against both those things. They have anti-glitch circuitry. The boot ROM doesn't even do comparisons against computed hashes, it just extends PCRs with them so it's glitch-proof by design even if the core stability monitoring fails. The Xbox One doesn't even expose most of the keys to software at any point. The keys flow from the hardware parts of the security complex to the RAM decryption/hashing engine via dedicated wires on the SoC.

Also, the entire stack is renewable. Unless you find a bug in the boot ROM they will just patch it and months of work will be toast within days. The boot ROMs are (a) encrypted and (b) very heavily reviewed and pen tested. Again, don't know about Apple but all these modern security architectures are more or less the same. The underlying theory is universal and sound, it just boils down to varying levels of cost / effort / backwards compatibility / generality.

So I'd say there are no right places to look anymore. There's always the potential for bugs in the tiny parts of the systems that act as the roots of trust, but these are small pieces of code and it's possible with enough break/fix cycles and review to make them perfect.

All the above rests on a few assumptions:

• Attackers of limited motivation. Xbox guys set a budget of $600 for hacking a specific console. If you're willing to spend more than that on a physical attack then they accept defeat (i.e. FIB workstations are out of scope).

• Platform vendors with tight control over hardware. PCs are insecure against physical attacks by design due to general disagreement and lack of consensus over whether it really matters / what the threat model is. So there are RA schemes but they're hardly used and mostly sold to enterprises wanting to defend against malware.

• Goal is to defend the whole stack. PC platforms can do RA of isolated worlds, this is how SGX works, and it's in theory secure against physical attack (encrypted memory) but SGX enclaves are very limited in what they can do. In theory you could build a secure path to the GPU, but in practice to do that requires a billion NDAs and only works with some GPUs etc and there's no encrypted path for input devices. On iDevices, consoles and other places with vertical integration that's solvable.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#40

Post by drdrey »

nicolodev wrote: post #2

Thanks for submitting the article! Let me know if anyone has any questions. If you are wondering how Apple obfuscate its software, the answer is simple: they built some extensions for LLVM that applies code transformation directly to LLVM IR. LLVM IR is an intermediate language to represent the code that will be copied in binary.

Great write-up! I was one of the Apple engineers who implemented some of these obfuscations. Fun to see an outside perspective on your work.
Post reply on HN