6 ms·

There are intellectual property concerns. You are now giving Apple your LLVM IR along with the program symbols. What happens if you have sensitive code in your

There are intellectual property concerns. You are now giving Apple your LLVM IR along with the program symbols. What happens if you have sensitive code in your application that you don't want Apple reverse engineering and having access to? LLVM bitcode also limits the kind of tamper resistance and obfuscation you can put into your apps. Fairplay offers almost no security if your attacker has a jailbroken device. He can simply dump the decrypted app from memory and reverse enegineer it. If you care about protecting your secrets, or preventing your app from being pirated and redistributed on Chinese app stores, you could at least apply fairly sophisticated obfuscation & integrity checks to the app binary. With LLVM bitcode that all becomes much harder, and applying integrity checks to the app becomes impossible. Also, Apple doesn't really need the LLVM bitcode of the app to carry out app thinning. All they really need to do is extract the proper architecture from a FAT binary, and send that to the user's device, instead of the entire FAT binary. It makes me wonder what will they even be using the LLVM bitcode for? Will it become a requirement for all apps submitted to the app store sometime in the future? If so, why?

tptacek 11y ago
There is nothing that the LLVM ARM backend is going to emit that Apple, or most security consultancies, can't trivially reverse engineer.
- nekitamo 11y ago
  Reverse engineering machine code is not trivial if it is obfuscated, has its symbols stripped, and has its ObjectiveC metadata obfuscated/encrypted. LLVM bitcode is much easier to reverse engineer than machine code, and you will be handing Apple all your symbols and metadata as well.
  - dymk 11y ago
    Symbols are obfuscated or removed entirely if you choose to build without them; you don't have to hand Apple your .dSYM if you don't want. I'm not sure what other metadata you're referring to.
    - nekitamo 11y ago
      I am referring to ObjectiveC metadata, which programs like IDA Pro can use to identify function names/parameters, which give valuable insights to reverse engineers. With LLVM bitcode, it doesn't matter if you don't hand over your .dSYM file to Apple, all the symbol information (and more!) is available in the bitcode.
      - tptacek 11y ago
        There is metadata in a fat binary (or in bitcode) that makes reversing more convenient, but there is none that makes reversing possible; reversing raw ARM assembly spat out by a normal compiler backend is always possible. It's 2015. Lack of source code is no longer a meaningful obstacle for attackers.
        nekitamo 11y ago
        I agree, reverse engineering is always possible :) However, reverse engineering with the LLVM bitcode present is much much easier, which is a problem. Also, if Apple requires apps to be submitted as LLVM bitcode, then certain things like integrity checks and certain useful types of obfuscation will become impossible, making apps much easier to reverse engineer, or to pirate and repackage on another app store.
        tptacek 11y ago
        I dispute the claim that bitcode makes this task so much easier that it presents a real threat. Everyone with a financial or policy interest in backdooring Signal can do so on stripped ARM binaries without any trouble.
        nekitamo 11y ago
        Iirc Signal is open source, so anyone can simply insert a backdoor into the source code and compile it, and then distribute the modified binary. However, I'm talking about applications for who the source code is not available. If you properly use integrity checks, signature verification, and obfuscation, you can make repackaging and piracy of applications significantly more difficult. With LLVM bitcode this is no longer the case.
  - tptacek 11y ago
    Symbols don't matter at all. Meanwhile: LLVM's ARM backend is not an obfuscating compiler backend. If you are obfuscating your code, yes, Bitcode is a problem. But Signal is not obfuscated.
    - nekitamo 11y ago
      Sorry, there might be some confusion. This entire time I was referring to code obfuscation/integrity checks, and why bitcode is a problem for people who want to obfuscate their code. I was not referring to apps like Signal at all. As an interesting aside, LLVM's ARM backend can be made into an obfuscating compiler, and furthermore some people have started obfuscating the LLVM bitcode itself: https://github.com/obfuscator-llvm/obfuscator/wiki https://github.com/obfuscator-llvm/obfuscator/wiki http://0vercl0k.tuxfamily.org/bl0g/?p=260 http://0vercl0k.tuxfamily.org/bl0g/?p=260
      - tptacek 11y ago
        Yes, if you were going to write an obfuscator, LLVM would be a good place to start. But, to a first approximation, nobody in the world obfuscates their mobile apps. Actually, I should raise the 'NateLawson alarm; he can probably tell us precisely how many mobile developers obfuscate on either platform.
        NateLawson 11y ago
        Good question. Obfuscation is more common on Android (10% of apps) than iOS (1%), but it's also pretty interesting where it's used most. First, throw out Proguard on Android. That's not really obfuscation, it's an optimizer. Sure it renames variables and removes dead code, but that's only a problem if you have a naive system that relies on class & method names. Proguard is used in 20% of Android apps though. The most common issue with Android is the malleability of its bytecode it inherited from Java. It's common to patch apps or repackage them for other app stores (after swapping advertising API keys). There's no work required to rebase addresses or anything after patching, unlike native code. This drives the need for obfuscation, but also provides a useful springboard for implementing it. We've found that many of the obfuscation schemes on Android are custom. This is because of the liberal policy towards using native code via JNI and the ease of inserting a custom Java classloader. With iOS's code signing and memory protection, you can't write a custom loader in your app that decrypts and executes new code. However, every other obfuscation measure is available in iOS. You can build opaque predicates, mangle control-flow, do arbitrary pointer arithmetic, and lots of things that are impossible in Dalvik. (However, you can just write a thin Java wrapper around your .so in Android and you've got the same capabilities and more.) With LLVM bitcode distribution, you're really potentially losing only one thing in your obfuscation toolbox: self-checksumming. You couldn't due self-modifying code already due to code signing, so nothing changed there. While I haven't implemented it myself, I believe you could still even do self-checksumming via clever use of intrinsics. That is, you carefully lay out the instructions and data and predict what you'll expect to see when it's translated to armv7, v7s, arm64, etc. That's the value you'll check for. http://llvm.org/docs/ExtendingLLVM.html http://llvm.org/docs/ExtendingLLVM.html
deleted 11y ago
[deleted]

tptacek 11y ago

There is nothing that the LLVM ARM backend is going to emit that Apple, or most security consultancies, can't trivially reverse engineer.

nekitamo 11y ago
Reverse engineering machine code is not trivial if it is obfuscated, has its symbols stripped, and has its ObjectiveC metadata obfuscated/encrypted. LLVM bitcode is much easier to reverse engineer than machine code, and you will be handing Apple all your symbols and metadata as well.
- dymk 11y ago
  Symbols are obfuscated or removed entirely if you choose to build without them; you don't have to hand Apple your .dSYM if you don't want. I'm not sure what other metadata you're referring to.
  - nekitamo 11y ago
    I am referring to ObjectiveC metadata, which programs like IDA Pro can use to identify function names/parameters, which give valuable insights to reverse engineers. With LLVM bitcode, it doesn't matter if you don't hand over your .dSYM file to Apple, all the symbol information (and more!) is available in the bitcode.
    - tptacek 11y ago
      There is metadata in a fat binary (or in bitcode) that makes reversing more convenient, but there is none that makes reversing possible; reversing raw ARM assembly spat out by a normal compiler backend is always possible. It's 2015. Lack of source code is no longer a meaningful obstacle for attackers.
      - nekitamo 11y ago
        I agree, reverse engineering is always possible :) However, reverse engineering with the LLVM bitcode present is much much easier, which is a problem. Also, if Apple requires apps to be submitted as LLVM bitcode, then certain things like integrity checks and certain useful types of obfuscation will become impossible, making apps much easier to reverse engineer, or to pirate and repackage on another app store.
        tptacek 11y ago
        I dispute the claim that bitcode makes this task so much easier that it presents a real threat. Everyone with a financial or policy interest in backdooring Signal can do so on stripped ARM binaries without any trouble.
        nekitamo 11y ago
        Iirc Signal is open source, so anyone can simply insert a backdoor into the source code and compile it, and then distribute the modified binary. However, I'm talking about applications for who the source code is not available. If you properly use integrity checks, signature verification, and obfuscation, you can make repackaging and piracy of applications significantly more difficult. With LLVM bitcode this is no longer the case.
- tptacek 11y ago
  Symbols don't matter at all. Meanwhile: LLVM's ARM backend is not an obfuscating compiler backend. If you are obfuscating your code, yes, Bitcode is a problem. But Signal is not obfuscated.
  - nekitamo 11y ago
    Sorry, there might be some confusion. This entire time I was referring to code obfuscation/integrity checks, and why bitcode is a problem for people who want to obfuscate their code. I was not referring to apps like Signal at all. As an interesting aside, LLVM's ARM backend can be made into an obfuscating compiler, and furthermore some people have started obfuscating the LLVM bitcode itself: https://github.com/obfuscator-llvm/obfuscator/wiki https://github.com/obfuscator-llvm/obfuscator/wiki http://0vercl0k.tuxfamily.org/bl0g/?p=260 http://0vercl0k.tuxfamily.org/bl0g/?p=260
    - tptacek 11y ago
      Yes, if you were going to write an obfuscator, LLVM would be a good place to start. But, to a first approximation, nobody in the world obfuscates their mobile apps. Actually, I should raise the 'NateLawson alarm; he can probably tell us precisely how many mobile developers obfuscate on either platform.
      - NateLawson 11y ago
        Good question. Obfuscation is more common on Android (10% of apps) than iOS (1%), but it's also pretty interesting where it's used most. First, throw out Proguard on Android. That's not really obfuscation, it's an optimizer. Sure it renames variables and removes dead code, but that's only a problem if you have a naive system that relies on class & method names. Proguard is used in 20% of Android apps though. The most common issue with Android is the malleability of its bytecode it inherited from Java. It's common to patch apps or repackage them for other app stores (after swapping advertising API keys). There's no work required to rebase addresses or anything after patching, unlike native code. This drives the need for obfuscation, but also provides a useful springboard for implementing it. We've found that many of the obfuscation schemes on Android are custom. This is because of the liberal policy towards using native code via JNI and the ease of inserting a custom Java classloader. With iOS's code signing and memory protection, you can't write a custom loader in your app that decrypts and executes new code. However, every other obfuscation measure is available in iOS. You can build opaque predicates, mangle control-flow, do arbitrary pointer arithmetic, and lots of things that are impossible in Dalvik. (However, you can just write a thin Java wrapper around your .so in Android and you've got the same capabilities and more.) With LLVM bitcode distribution, you're really potentially losing only one thing in your obfuscation toolbox: self-checksumming. You couldn't due self-modifying code already due to code signing, so nothing changed there. While I haven't implemented it myself, I believe you could still even do self-checksumming via clever use of intrinsics. That is, you carefully lay out the instructions and data and predict what you'll expect to see when it's translated to armv7, v7s, arm64, etc. That's the value you'll check for. http://llvm.org/docs/ExtendingLLVM.html http://llvm.org/docs/ExtendingLLVM.html

deleted 11y ago

[deleted]