For app developers, the low-level virtual machine bitcode has been a staple of Apple’s toolchain and the Android Native Development Kit for the past seven years. With the release of the Xcode 14 betasoon to become the standard for iOS and MacOS development starting this year, Apple has done away with the option to build bitcode apps.
This has huge implications for the application security industry, which has largely designed and integrated their approach to code obfuscation around bitcode. Unless security vendors adapt, many apps could face a gaping hole in their security in the not-too-distant future.
What is code obfuscation?
Code obfuscation is a powerful code protection technique and an essential part of application security products. The idea behind obfuscation is to modify an executable so that it is no longer transparent to a hacker, yet remains fully functional.
TO SEE: Mobile Device Security Policy (Tech Republic Premium)
When done effectively, obfuscation makes reverse-engineering a program extremely difficult and is therefore used to protect sensitive intellectual property. For example, obfuscation can be used to hide an algorithm that a company doesn’t want competitors to understand, especially to protect its security code.
In the field of app foreclosure, we use a number of tools to enforce a secure environment in which apps can work. This includes things like hook detection, anti-debug, and anti-tampering, all of which ironically are vulnerable to tampering or removal unless well-hidden. Obfuscation is therefore used to protect these tools.
Obfuscation can be inserted at three different levels: the source-based level, the native binary level, and by far the most dominant approach, the intermediate level. Between many compilers and the native code is an intermediate layer where optimizations are done.
Low-Level Virtual Machine is the best-known example of this. LLVM is a set of compiler and toolchain technologies that can be used to develop a front-end for any programming language and a back-end for any instruction set architecture. LLVM is useful because compilers like Clang or Rustc can target different backends like Linux on X86_64, armv7, iOS and Windows. If an obfuscator can operate at this level, it is easiest to build and maintain because it is not tied to the front-end compiler language or the back-end machine instruction set.
However, there is one drawback: it is often tied to the toolchain. For apps on iOS and MacOS, those that eclipse at the medium level are subject to any changes or major overhauls from Apple’s integrated software development, such as Xcode 14.
What is bit code?
Bitcode is a serialized version of LLVM’s Intermediate Representation.
A major reason for the popular use of LLVM in app development, including bitcode, is that it is open source and available to everyone. This has led many vendors to create obfuscators that run on bitcode. The advantage for them is that they too can target many back-ends and typically multiple front-ends as well. The fact that the LLVM libraries also provide all the APIs necessary for bit code manipulation has further contributed to its dominance.
Apple has previously made use of bitcode within its toolchain because it had different CPU architectures to support it, such as Intel, arm32, and arm64. In some cases, Apple has even mandated that apps be submitted in bitcode format — not machine code. This has allowed Apple to lower the final stage to the machine code for the specific device to be installed on.
How will bitcode be affected by future Xcode releases?
Apple has now reached a point where all of its new hardware uses arm64 and no longer needs LLVM’s flexible backends. Especially at the WWDC 2022 keynote talked about being able to optimize better purely for that architecture, suggesting that the LLVM interlayer may not be used for that purpose in the future.
This has led to a major overhaul in the form of the Xcode 14 beta, with Apple doing away with the option to build bitcode apps. Developers for iOS and MacOS can still use bitcode with a warning, but it will be removed later. Essentially, it’s no longer that easy to produce bitcode apps.
Why is this important and who does it affect?
Future Xcode releases can now prevent security vendors from using bitcode. Obfuscation vendors typically take two approaches to bitcode obfuscation that are affected in different ways.
The first approach is app obfuscation, where the obfuscator works on the entire app in bitcode format, post-build, as an IPA or Xcarchive file. This is a great approach because it means the obfuscator doesn’t have to be tightly integrated into the toolchain and eclipses can work on the entire app rather than on individual modules at once.
The second is a toolchain-integrated approach where the obfuscator replaces or patches components in the Apple toolchain to ensure that it is called during the build process. This can cause maintenance issues, but usually this is a lightweight integration by creating wrappers around the existing clang compiler.
The first approach has now effectively been abolished. Sellers who take advantage of this will likely continue their work for at least another year (with warnings). However, this method is probably prevented in Xcode 15 or 16.
The second approach could also be on shaky ground in the future, as we don’t know if Apple will remove LLVM at some point or prevent access to it in the compiler – possibly even without warning. All vendors currently using an LLVM-based obfuscator for iOS and macOS app protection will be affected by this change.
What does this mean for the future of application security?
Eventually, LLVM will become less useful and may disappear altogether as Apple seeks to leverage its unified architecture for CPU, GPU, and ML accelerators. Xcode 14 already contains toolchain components that compete with LLVM for this. If LLVM goes away, Apple’s platforms could become much harder to protect in the future and therefore fewer vendors will have products available to do that.
It’s very possible that this turmoil threatens the security of many of the apps on the App Store. Whether this happens or not depends on the adaptability of security vendors. Those who take a toolchain-integrated approach are fine for the time being, but run the risk that this approach will be closed without warning in the future.
What is likely is that we will see an increase in the native binary approach to eclipse. The main difference is that this approach to obfuscation is where the built-in machine code is manipulated directly. Not many obfuscators currently use this method as it is extremely difficult to do and may need to support many binary formats and/or CPU instruction sets.
Either way, while the future of code obfuscation may be uncertain, one thing is certain: app developers will need to take a proactive approach, monitor security vendors, and plan accordingly if they want to ensure their apps remain secure.
Andrew Whaley is the Senior Technical Director at Promontory, a Norwegian app security company. With his extensive experience in penetration testing, application hardening, code obfuscation, cryptography and blockchain, Andrew leads Promon’s R&D team in enhancing the company’s core product suite with new security capabilities.
