[HN Gopher] Analysis of Obfuscation Techniques Found in Apple Fa...
___________________________________________________________________
Analysis of Obfuscation Techniques Found in Apple FairPlay
Author : univr
Score : 164 points
Date : 2023-08-29 13:32 UTC (9 hours ago)
(HTM) web link (nicolo.dev)
(TXT) w3m dump (nicolo.dev)
| josephcsible wrote:
| > 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 application since the archive copy is
| free.
|
| > How can we protect the information contained within the
| archive? It is clear that we must somehow hide the contents of
| the archive; by doing so, even if they were to extract the IPA
| archive from the iPhone, attackers would not be able to access
| the contents.
|
| I don't like how positive all of that makes DRM sound.
| [deleted]
| hooverd wrote:
| General purpose computing will always be an affront to
| rentiers.
| z8 wrote:
| 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 :)
| nicolodev wrote:
| 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.
| t8sr wrote:
| [flagged]
| nicolodev wrote:
| Thanks for your feedback. As I previously said in another
| comment, the article was written in one go and I probably have
| missed the point of "be minimal in the description". I felt
| that readers should know a little bit more about obfuscations
| techniques, their use and why these are deployed into prod.
| While I am writing, I tend more to be "story-teller" to immerge
| readers into the flow, but I do admit this article is really
| difficult to read. I even deleted some paragraphs because it
| was going to be huge.
| t8sr wrote:
| Hello, and thank you for talking about your work. Real
| stories from the industry like this are awesome to have.
|
| As a fellow infosec person, I also struggle with keeping
| things brief. (Especially since I started out in digital
| forensics, where you can be extremely verbose.) It's counter
| to the inclination we have to checking every detail, I think.
| But I've found that I get 10x more people engaging with a
| 2-pager than a 10-pager. One of the things that really helps
| me is http://plainlanguage.gov.
| nicolodev wrote:
| Thanks for the feedback again. I did really appreciate it.
| Oh the website you mentioned seems interesting, especially
| for a person that does not speak English daily. I'll keep
| in mind, and of course I bookmarked it.
| jks wrote:
| I think the trend may be because longwinded writing gets you
| authority points on Google, or at least because writers think
| it does. Recall the famous laser printer review from earlier
| this year:
|
| https://www.theverge.com/23642073/best-printer-2023-brother-...
| [deleted]
| 7e wrote:
| Why doesn't Apple build a custom TEE to do DRM playback, and
| authenticate the display as well? That seems like a better
| solution.
| nicolodev wrote:
| I'm having doubts about what you mean about "TEE", I suppose
| it's term for "trusted execution environment". I'm not sure
| about I might answer, and it's probable the right question to
| ask to Apple engineering. I think Apple can use the same
| technology they used for Apple Pay via the Secure Chip. I'm
| talking mainly about exchanging keys via servers, decryption
| and then serve the content via a sort of "frontend". I wish to
| know more about TEE to give you a more detailed answer.
|
| EDIT: thinking about secure enclave.. maybe (still an
| hypothesis) the chip does not have the bandwidth to perform
| decryption just in time. Probably it's a huge cost for Apple to
| apply something like that.
| mike_hearn wrote:
| They didn't need to. If you have a robust secure boot chain
| then code running in kernel mode is sufficient (which is what
| Apple claim FairPlay Streaming is doing). The video is
| decrypted in kernel space and the drivers enforce HDCP.
|
| Windows has a similar approach, but it's easier to get
| attacker's code into kernel space there, and PCs can't properly
| remotely attest so the whole thing doesn't really work (too
| many possible legit configurations).
| no_time wrote:
| Only an Apple engineer could answer this fully but here are
| some of my ideas as to why this hasn't been done yet:
|
| -They still support playback on devices with no TEE. Kinda
| defeats the point of implementing it until this is the case.
|
| - They are wary of moving more functionality into their TEE as
| it increases the attack surface.
|
| - If the platform is already "attested" and locked down as it
| is the case today, moving the playback to the TEE provides only
| a little bit of extra security.
|
| - They are banking on the ARM Realm Management Extension[0]
| coming to their chips. This would be more of a "catch all"
| solution to fuck over the owners of their machines in new and
| exciting ways.
|
| [0]: https://fuse.wikichip.org/news/5699/arm-introduces-its-
| confi...
| ballenf wrote:
| What prevents a virus maker from using Realm Management
| against virus/security scans?
| no_time wrote:
| There isn't enough known about the whole thing to answer
| this. But for what it's worth, Intel's version of this tech
| has a wiki paragraph dedicated to this concern.
|
| https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGX
| _...
| nicolodev wrote:
| Nice points! Thank you, I'll dig into ARM RME because it
| seems pretty interesting
| mike_hearn wrote:
| 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
| enabled or has been disabled / the root partition has been
| modified, then that will be detectable by Apple remotely.
| Although code obfuscation is fun (I've built a virtualization
| based obfuscation in the past), a properly implemented remote
| attestation and security architecture does obsolete it. It's
| therefore mostly useful on Windows/Linux PCs where these schemes
| don't really hang together.
| mistrial9 wrote:
| 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
| [deleted]
| twoodfin wrote:
| It's also likely strong evidence in court that you can't
| acquire a copy of protected content without activity that is
| clearly circumvention.
| nicolodev wrote:
| Thanks for your comment. This obfuscation scheme is used only
| to complicate any attempt to reverse engineering
| (disassembling, decompilation) of the two processes involved in
| FairPlay DRM (I'm mainly talking about CoreFP and Fairplayd).
| Attackers need to spend more time on retrieving the original
| business logic. For sure, it's not the most hyper-defense
| technology Apple has employed (think about Secure Enclave).
|
| > a properly implemented remote attestation and security
| architecture does obsolete it [obfuscation]
|
| I'm not sure I've understood this part. So, if Apple implements
| remote attestation, would it be more difficult for attackers to
| reverse engineering the application? I am probably missing a
| point, would you mind if I ask you to expand that?
| mike_hearn wrote:
| 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 code itself.
|
| i.e. a system based on RA can be entirely transparent, open
| source even, and it can still work. The only secrets are the
| hardware keys that act as the root of trust. The software and
| hardware stack does itself need to be secure of course, but
| Apple has got pretty good at that. And btw Apple's platforms
| already support remote attestation:
|
| https://developer.apple.com/documentation/devicecheck
| skybrian wrote:
| This seems like an argument against defense in depth? I
| suppose encouraging security researchers to find
| vulnerabilities is a good thing and obfuscation hinders
| that.
| nicolodev wrote:
| 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!
| mike_hearn wrote:
| 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.
| drvdevd wrote:
| 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?
| mike_hearn wrote:
| 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.
| EMIRELADERO wrote:
| God, all this sounds like a nightmare. I can't wait for
| laws that prohibit platforms/software from refusing
| service/content to users on the basis of the level of
| control they have over devices used to interact with it.
|
| Dark times.
| mike_hearn wrote:
| Users love this stuff. It lets them buy cheap consoles
| that are sold below cost and subsidised by game
| royalties. Heavy gamers subsidise light gamers, and both
| can effectively "pay off" the true cost of the hardware
| over time as they buy titles. So it's a bit like zero-
| interest credit.
|
| Also it eliminates cheating in multiplayer games, and
| users love that too.
|
| And finally it stops gamers who play by the rules and buy
| games from feeling like mugs when their mates are playing
| for free, because there's no piracy.
|
| You think users are going to vote to end all that? They
| already voted with their feet and embraced consoles on a
| massive scale. Both console and mobile gaming dwarfs PC
| gaming.
| EMIRELADERO wrote:
| Consider privacy. One might say "Users love this stuff.
| They get complex and effective services for free, all in
| exchange for contributing their data towards ads.
| Purchasers and advertisers subsidize light users who just
| consume the content."
|
| And yet, we got laws like GDPR on the ideological basis
| that personal data is above the concept of "market" and
| about the individual, period. Your business model be
| damned.
|
| The same thing should happen here. Both the complete
| control over all parts/SoCs of a device, and the right to
| the lack of negative consequences for choosing to
| exercise that control (such as being second-class
| citizens on the platform that runs on that device in
| terms of content/service availability) are paramount to a
| digital free society, and should be regulated as such,
| putting them above the concept of "market", just as
| privacy was.
| tptacek wrote:
| These same platform controls allow Apple to restrict user
| data collection from apps. Meanwhile: the notion of a
| "digital free society" isn't a thing.
| EMIRELADERO wrote:
| I'd much prefer governments use their force of law to
| make those tracking practices impossible (for anything
| that isn't an outright criminal enterprise) than a
| private entity making them technically difficult.
| mschuster91 wrote:
| RA doesn't protect you from kernel exploits.
| lxgr wrote:
| In some DRM architectures, the key and data encrypted
| using it is never even exposed to the kernel.
|
| That's how many high resolution video DRM schemes work.
| nicolodev wrote:
| Exactly!
| mike_hearn wrote:
| It lets you detect if the user is running a vulnerable
| kernel.
|
| Apple's stack is pretty secure. When was the last iPhone
| jailbreak? I don't follow it closely as I'm not an iPhone
| user, but it feels like a long time ago now. And if an
| exploit is found, they can just revoke that kernel
| version. Apps can then ask users to apply the update to
| regain access to their streams.
| realusername wrote:
| exploits are just kept private by bad actors nowadays.
|
| Apple now gets the worst of both worlds, the harmless
| jailbreaking scene is dying but the bad actors are still
| in full force.
| tptacek wrote:
| How is that the worst of both worlds? The harmless
| jailbreak world also empowers bad actors.
| holopic wrote:
| It gets harder and takes longer to jailbreak the iPhone.
| iOS 15.0 - 15.4.1 was jailbroken - it has been 2 years -
| I would expect an exploit on 16 already existing and
| under embargo.
| saagarjha wrote:
| > The software and hardware stack does itself need to be
| secure of course, but Apple has got pretty good at that.
|
| lol
| baby_souffle wrote:
| > I'm not sure I've understood this part. So, if Apple
| implements remote attestation, would it be more difficult for
| attackers to reverse engineering the application? I am
| probably missing a point, would you mind if I ask you to
| expand that?
|
| It's not to prevent RE. Apple can detect tamper so it's no
| concern if you RE it or not. Anything you learn from that RE
| work will almost certainly mean tampering with the system...
| cynicalsecurity wrote:
| FairPlay(tm) sounds as of it was taken straight from Scientology.
| [deleted]
| nicolodev wrote:
| 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.
| jchw wrote:
| Thanks for taking the time to write about your reverse
| engineering experience. I'm more of a programmer than a reverse
| engineer, but I do like to dabble in RE and analysis and
| dealing with obfuscation and techniques like virtualization is
| always quite a challenge. There's probably a lot of learning
| material out there, but it feels difficult to digest at times,
| so articles like these are always helpful for getting some
| perspective on how these things work out in practice, and
| getting a feel for some of the approaches you can use when you
| run into a roadblock. Definitely makes me want to go mess
| around with some binary analysis after work.
| nicolodev wrote:
| Thanks for your comment. This article was written in one go,
| and it could be way better than the actual state. However I
| do appreciate that you mean to consider my article as a nice
| example on how things work out in practice. Being a
| programmer and knowing a little bit of reverse engineering is
| important (well, I'm still a programmer too!). If you have
| any questions, please let me know.
|
| Regarding the difficulty of learning material, I can feel
| you. It was the same for me when I started (I have a lot of
| stuff to dig into!), and it's still. Academy papers might be
| difficult to understand, but once you comprehend the
| formalisms it'll be easier. For sure, understanding the
| formal formulas is another challenge that I haven't resolved
| yet.
| motrm wrote:
| > We use IDA for convenience in this article, although we must
| be especially careful when importing the binary into other
| tools (we will explain why at the end of the article)
|
| Forgive me if I missed this being explained - I was curious
| what the reasoning for this was and I didn't see it! Could you
| elaborate? :)
| nicolodev wrote:
| Ops! Forgot to write about it (otherwise it would be so
| long). I did not mention the tools, but I was mainly
| referring to Hopper Decompiler/Disassembler (definitely no no
| for me). Altough it seemed the natural choice for reverse
| engineering macOS applications and daemons, it failed
| disastrousely on reverse engineering fairplayd. This is where
| obfuscation is really good at: feeling pain. Hopper tried to
| disassemblate the binary but still no luck (there was an
| error due to some bogus instructions referred by a dead
| branch). I'm seeing improvements for Hopper release by
| release, but there were some regressions that I noticed..
|
| I tried to import it into Ghidra and it missed some
| informations during the pass of stack analysis. At the end it
| was a mess result to read, so I ended it up with IDA (free
| because I'm a student). Binary ninja also needs some license,
| I'm trying to afford it.
| motrm wrote:
| So mainly just Ghidra & Hopper were successfully tripped up
| by fairplayd - thanks for the explanation!
|
| Great article overall, thanks for taking the time to write
| it up.
| drdrey wrote:
| 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.
| nicolodev wrote:
| Thanks a lot!!! I can't believe I meet you on HN, great work
| so far
___________________________________________________________________
(page generated 2023-08-29 23:01 UTC)