Hacker News new | past | comments | ask | show | jobs | submit login

I'm honestly surprised that noone has commented on the security implications of this, yet. After all, allowing Apple to recompile your "bitcode" essentially means, that the user can in no way validate that the version he's running is the version the developer published. It would be fairly straightforward to perform MITM attacks on apps this way. (And, sure, Android's APKs are faced with quite the same issue - but AFAIK Google doesn't modify your bytecode (yet?))



Apple control the platform. They can patch your app at runtime if they want.


This can't be stated enough. You can have all the fanciest encryption messenger app you like, but it all comes down to - do you trust Apple?


It is said they even do binary level analysis of your app to see no restricted APIs are used.


They could already do that. They sign and encrypt the (plaintext) code segment you submit so they could easily insert a JMP to their own payload at the head of your code any time


They could also just have the kernel do whatever it wants to your program, because they control that too. If you are worried that Apple might tamper with your binaries if given the chance, using an iOS device is pure folly, because they outright control much more important parts of your system (the kernel, the UI libraries, the RNG…).


Why do they encrypt code segment? Signature is essential, of course, but encrypting looks unnecessary.


It's their fairplay DRM implementation that is supposed to prevent piracy.


Apple has a pretty complex boot system in which each stage of the boot process verifies a checksum of the next layer before starting it up. The lowest layer is etched in ROM. Theoretically, if you verify the integrity of the bitcode, and you verify the integry of the bitcode compiler, you should be able to trust the native binary as well.


Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store.

Unless the description is wrong, this looks like Apple could insert any code they want into your binary, without your users noticing.


As others have pointed out - which they can do anyway because they own the entire operating system and application runtime.


Seeing as the only way to run these apps is to get them through the App Store Apple could also just completely replace your app code with whatever they want.

They can also choose to just not validate signatures. If they wanted to MITM your app, this doesn't make it any easier for them as it's already very easy for them to do that.


Well, APK's are signed by the developer. Google would have to replace them on first install.


Signed binaries don't mean anything to someone like Google or Apple who control the host OS (and the hardware).

In both their OS/kernel and in the hardware, Google has the ability to make your app do anything they want to regardless of how you coded it or signed the binary.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: