1

We are distributing a software module for iOS online. Since, Apple is advocating bitcode and even making it mandatory for apps on some devices (watchOS/tvOS) - forcing us to deliver this software module (static library) with bitcode.

The concern is how secure bitcode is from anyone to reverse engineer and decompile (like java bytecode) and how to protect against it? It is easy for anyone to download libraries from the website and extract bitcode (IR) from it and decompile. Some valuable information on it here

https://lowlevelbits.org/bitcode-demystified/

Bitcode maynot be concern for apps as apple will strip it but definitely appears to be a concern for static libraries.

Any insights?

mesibo
  • 3,970
  • 6
  • 25
  • 43
  • 1
    So you're worried about clients to which you deliver static libraries, and that they might reverse-engineer your code and steal your IP? – Duncan C Nov 18 '17 at 22:31

2 Answers2

9

As the link notes "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’" Yep. Totally true.

Also, if you ship non-bitcode libraries, a "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’"

Also, if you ship non-bitcode apps, a "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’"

There is no situation where this is not true. Tools as cheap as Hopper (my tool of choice, but there are also some cheaper solutions) and elaborate as IDA can decompile your functions into passable C code.

If you're working with Cocoa (ObjC or Swift), you have made it even easier to reverse engineer because it's so easy to dynamically introspect Cocoa.

This is not a solvable problem. Both apps and libraries can try to employ obfuscation techniques, but they are complex, fragile, and typically require significant expense or expertise (and often both). In any case, you will need to continually improve your obfuscation as people break it. This is fairly pointless for a library, since there's very little you could re-protect once it leaks, but you can try.

It will leak. That's not solvable. Bitcode doesn't change a whole lot about that. It might be somewhat simpler to read IR than ARM assembly, but not that much, and certainly not if the thing you're protecting is small (like a small algorithm or a key).

There are some obfuscation vendors out there. Product recommendations are off-topic for Stack Overflow (because they attract spam), but search for "ios obfuscation" and you'll find them. In this space, since it's just "tricky hiding" (not security or encryption) you generally get what you pay for. Open source solutions make little sense, since the whole point is to be tricky and hide how you're doing it. I've worked with some open source obfuscation libraries that make it easier to extract secrets from your code (because they're trivial to reverse, and their use marks the parts of the code where you're hiding things).

If this is important to your business plan, then budget for that, and expect it to introduce some challenging bugs, and expect it to be broken anyway (but maybe take longer).

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
-1

@Rob Napier, you are wrong in comparing orange to apple. Reading assembly code or disassembling with IDA is world apart compared to reading code generated by decompiling intermediate code. Bitcode is totally a nuisance

Jim
  • 338
  • 1
  • 14
  • 4
    This appears to be a comment on Rob Napier's answer. It would therefore be appropriate to make it a comment to Rob Napier's answer, using the 'add a comment' link at the bottom of his post. It is not an answer to the question posed, so it is inappropriate as an answer. – Tommy Nov 19 '17 at 04:24
  • Agreed this should be a comment. Also, I read a lot of Hopper-generated pseudo-C, and also a lot of `swiftc -O -emit-ir` (and often just Hopper-generated disassembly). IR can be a bit easier, but it's not a dramatic difference, especially on optimized code, to reverse engineering small pieces of code (and most of the interesting stuff usually boils down to a small piece of code). I'm not even very good at reverse engineering, and Cocoa apps are still pretty transparent. The group of people for whom IR is readable, but assembly isn't is pretty small IMO (and that's the question). – Rob Napier Nov 20 '17 at 03:41
  • 2
    It's ridiculous that stackoverflow is not allowing new members to post comments but they can answer. – Jim Nov 20 '17 at 07:32