What does the disappearance of bitcode mean for the future of application security?

Image: Konstantin Savusia/Adobe Stock

For app developers, the low-level virtual machine binary has been a staple of Apple’s toolchain and native Android SDK for seven years. With the release of Xcode 14 betawhich will soon become the standard for iOS and macOS development starting this year, Apple has deprecated the option of building bitcode apps.

For the application security industry, which has largely designed and integrated its approach to code obfuscation around bitcode, this has wide ramifications. Unless security vendors adapt, in the not-too-distant future, many apps could face a gaping hole in their security.

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 file so that it is no longer transparent to a hacker but remains fully functional.

SEE: Mobile Device Security Policy (TechRepublic 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 its competitors to understand, such as to protect security code.

In the area of ​​application protection, we use a number of tools to establish a safe environment in which applications can operate. This includes things like hook detection, anti-debugging, and anti-tampering, all of which are ironically vulnerable to tampering or removal unless they’re 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-based 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 performed.

The low-level virtual machine is the best-known example. 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 it allows compilers like Clang or Rustc to target different backends like Linux on X86_64, armv7, iOS and Windows. If an obfuscator can work at this level, it’s the easiest to build and maintain because it’s not tied to either the front-end compiler language or the main-machine instruction set.

However, there is a downside: it is often tied to the toolchain. For apps on iOS and MacOS, those that obfuscate at the middle tier are subject to any major changes or revisions to Apple’s embedded software development, such as Xcode 14.

What is bitcode?

Bitcode is a serialized version of the intermediate representation of LLVM.

One of the main reasons for the popular use of LLVM in the development of applications, and therefore bitcode, is that it is open source and available to everyone. This has led many vendors to create obfuscators that work on bitcode. The advantage for them is that they can also target many back-ends and also usually several front-ends. The fact that LLVM libraries also provide all the APIs needed to manipulate bitcode further contributed to its dominance.

Apple used bitcode in its toolchain before because it had multiple processor architectures to support it, such as Intel, arm32, and arm64. Apple has even required in some cases that apps be submitted in bitcode format, not machine code. This allowed Apple to perform the final step by lowering the machine code on which the particular device should be installed.

How is bitcode affected by future versions of Xcode?

Apple has now reached a point where all of its new hardware uses arm64 and no longer requires the flexible back-ends provided by LLVM. In particular, at WWDC 2022 keynote, it was mentioned that it was possible to optimize better just for this architecture, which suggests that the LLVM middle layer may not be used for this purpose in the future.

This led to a major overhaul in the form of the Xcode 14 beta, where Apple deprecated the ability to build bitcode apps. Developers for iOS and macOS can still use bitcode with a warning, but that will be removed later. Essentially, it’s not as easy to produce bitcode applications anymore.

Why is it important, and who is impacted?

Future versions of Xcode can now block security vendors from using bitcode. Obfuscation vendors typically take two approaches to binary code obfuscation that will have a different impact.

The first approach is application obfuscation, where the obfuscator acts on the entire application in bitcode format, post-build, as an IPA or Xcarchive file. This is a great approach because it means the obfuscator doesn’t need to be tightly integrated into the toolchain and obfuscations can work across the entire application rather than individual modules at that time.

The second is an integrated toolchain approach where the obfuscator overrides or fixes components of the Apple toolchain to ensure it is called during the build process. This can lead to maintenance issues, but it’s generally a lightweight integration by creating wrappers around the existing clang compiler.

The first approach is effectively now obsolete. Sellers using it are likely to continue their work (with warnings) for at least another year. However, this method will likely be 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 or prevent access to it in the compiler at some point, potentially even without warning. All vendors currently using an LLVM-based obfuscator for iOS and MacOS app protection will be impacted 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, in the future Apple’s platforms could become much more difficult to protect and therefore fewer vendors will have products available to do so.

It’s entirely possible that this shake-up will compromise the security of many apps on the App Store. Whether or not this happens will depend on the adaptability of security vendors. Those using an integrated toolchain approach will be fine for now, but they run the risk of that approach being shut down without warning in the future.

What is likely is that we will see an increase in the native binary approach to obfuscation. The main difference being this approach to obfuscation is where the constructed machine code is directly manipulated. There are not many obfuscators currently using this method because it is particularly difficult to do and may need to support many binary formats and/or CPU instruction sets.

In any case, while the future of code obfuscation may be uncertain, one thing is certain: application developers will need to take a proactive approach, monitor security vendors, and plan accordingly if they are to s ensure that their applications remain secure.

Andrew Balley

Andrew Whaley is the Senior Technical Director of Promotion, a Norwegian application security company. With extensive experience in penetration testing, application hardening, code obfuscation, cryptography and blockchain, Andrew leads Promon’s R&D team to enhance the company’s core product suite with new security capabilities.