5 ms·

Analysis of Obfuscation Techniques Found in Apple FairPlay

200 points by univr 3y ago

nicolodev 3y ago
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 3y ago
  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 3y ago
    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.
- drdrey 3y ago
  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 3y ago
    Thanks a lot!!! I can't believe I meet you on HN, great work so far
- motrm 3y ago
  > 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 3y ago
    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 3y ago
      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.
      - nicolodev 3y ago
        Ghidra was somehow usable, I got several crashes with Hopper. One question for more expert people than me: does Hopper employ any telemetry inside its demo version? Some issues I discovered were fixed in two days and I did not report them.
t8sr 3y ago
[flagged]
- nicolodev 3y ago
  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 3y ago
    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 http://plainlanguage.gov.
    - nicolodev 3y ago
      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 3y ago
  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-laser-wi-fi-its-fine https://www.theverge.com/23642073/best-printer-2023-brother-...
- deleted 3y ago
7e 3y ago
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 3y ago
  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.
- no_time 3y ago
  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-confidential-compute-architecture/ https://fuse.wikichip.org/news/5699/arm-introduces-its-confi...
  - nicolodev 3y ago
    Nice points! Thank you, I'll dig into ARM RME because it seems pretty interesting
  - ballenf 3y ago
    What prevents a virus maker from using Realm Management against virus/security scans?
mike_hearn 3y ago
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.
- nicolodev 3y ago
  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?
  - baby_souffle 3y ago
    > 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...
  - mike_hearn 3y ago
    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 https://developer.apple.com/documentation/devicecheck
josephcsible 3y ago
> 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 3y ago
  [deleted]
- hooverd 3y ago
  General purpose computing will always be an affront to rentiers.
z8 3y ago
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 3y ago
  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.
cynicalsecurity 3y ago
FairPlay™ sounds as of it was taken straight from Scientology.
- deleted 3y ago
  [deleted]

200 points by univr 3y ago

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 3y ago
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 3y ago
  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.
drdrey 3y ago
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 3y ago
  Thanks a lot!!! I can't believe I meet you on HN, great work so far
motrm 3y ago
> 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 3y ago
  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 3y ago
    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.
    - nicolodev 3y ago
      Ghidra was somehow usable, I got several crashes with Hopper. One question for more expert people than me: does Hopper employ any telemetry inside its demo version? Some issues I discovered were fixed in two days and I did not report them.

t8sr 3y ago

[flagged]

nicolodev 3y ago
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 3y ago
  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 http://plainlanguage.gov.
  - nicolodev 3y ago
    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 3y ago
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-laser-wi-fi-its-fine https://www.theverge.com/23642073/best-printer-2023-brother-...
deleted 3y ago

7e 3y ago

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 3y ago
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.
no_time 3y ago
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-confidential-compute-architecture/ https://fuse.wikichip.org/news/5699/arm-introduces-its-confi...
- nicolodev 3y ago
  Nice points! Thank you, I'll dig into ARM RME because it seems pretty interesting
- ballenf 3y ago
  What prevents a virus maker from using Realm Management against virus/security scans?

mike_hearn 3y ago

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.

nicolodev 3y ago
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?
- baby_souffle 3y ago
  > 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...
- mike_hearn 3y ago
  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 https://developer.apple.com/documentation/devicecheck

josephcsible 3y ago

> 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 3y ago
[deleted]
hooverd 3y ago
General purpose computing will always be an affront to rentiers.

z8 3y ago

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 3y ago
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.

cynicalsecurity 3y ago

FairPlay™ sounds as of it was taken straight from Scientology.

deleted 3y ago
[deleted]