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

11–20 of 56 posts

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#11

Post by nicolodev »

7e wrote: post #6

Why doesn't Apple build a custom TEE to do DRM playback, and authenticate the display as well? That seems like a better solution.

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.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#12

Post by nicolodev »

t8sr wrote: post #9
nicolodev wrote: post #7

Earlier quoted context omitted.

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…

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…

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.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#13

Post by mike_hearn »

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.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#14

Post by nicolodev »

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…

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?

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#15

Post by no_time »

7e wrote: post #6

Why doesn't Apple build a custom TEE to do DRM playback, and authenticate the display as well? That seems like a better solution.

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

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#16

Post by nicolodev »

no_time wrote: post #15
7e wrote: post #6

Why doesn't Apple build a custom TEE to do DRM playback, and authenticate the display as well? That seems like a better solution.

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 th…

Nice points! Thank you, I'll dig into ARM RME because it seems pretty interesting

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#17

Post by twoodfin »

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…

It’s also likely strong evidence in court that you can’t acquire a copy of protected content without activity that is clearly circumvention.

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#18

Post by baby_souffle »

nicolodev wrote: post #14
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…

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…

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

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#19

Post by mike_hearn »

nicolodev wrote: post #14
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…

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…

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

Re: Analysis of Obfuscation Techniques Found in Apple FairPlay

#20

Post by mike_hearn »

7e wrote: post #6

Why doesn't Apple build a custom TEE to do DRM playback, and authenticate the display as well? That seems like a better solution.

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

Post reply on HN