For app developers, Low Level Virtual Machine bitcode has been a staple of Apple’s toolchain and Android Native Development Kit for the past seven years. With the release Xcode 14 betais about to become the standard for iOS and MacOS development since this year, Apple no longer has the option to build bitcode apps.
For the application security industry, who have largely designed and integrated their approach to obfuscate the code around bitcode, this has a lot of ramifications. Unless security vendors adapt, in the not-too-distant future, many applications may experience security vulnerabilities.
What is code obfuscation?
Code obfuscation is a powerful technique for protecting code and is an essential part of application security products. The idea behind obfuscation is to modify an executable so that it is no longer transparent to hackers but still fully functional.
UNDERSTAND: Mobile device privacy policy (TechRepublic Premium)
When done effectively, obfuscation makes it extremely difficult to reverse engineer a program 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 a competitor to understand – most notably to protect secure code.
In the area of application protection, we use a number of tools to enforce a secure environment for applications to operate within. This includes things like hook detection, anti-debug, and anti-tampering, all of which are easily tampered with or ironically discarded. Therefore, Obfuscation is 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 the many compilers and the native code is an intermediate layer where optimizations are performed.
The 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 user interfaces for any programming language and end user interfaces for any scripting architecture. any. 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 is the easiest to build and maintain since it is not tied to the front-end compiler language or back-end machine script.
However, there is a catch: It is often tied to the toolchain. For apps on iOS and MacOS, those that cause mid-level obfuscation may be subject to any major changes or overhauls to Apple’s built-in software development – such as Xcode 14 .
What is Bitcode?
Bitcode is a serialized version of LLVM’s Intermediate Representation.
A big reason LLVM is so commonly used in application development, and therefore bitcode, is that it is open source and available to everyone. This has led to many vendors creating obfuscators that work on bitcode. The advantage for them is that they can also target multiple back-ends and often several front-ends as well. The fact that the LLVM libraries also provide all the APIs needed to manipulate bitcode has further contributed to its dominance.
Apple has previously used bitcode in its toolchain as it has several CPU architectures to support this like Intel, arm32 and arm64. Apple has even required in some cases that applications be submitted in bitcode format – not machine code. This has allowed Apple to take the final stage of downgrading the machine code for the specific device to be installed.
How is bitcode affected by future Xcode releases?
Apple has now reached a point where all of their new hardware uses arm64 and no longer requires the flexible backs provided by LLVM. Notably, at WWDC 2022 keynote, there is mention of possibly better optimizations altogether for that architecture, which suggests that the LLVM middle layer may no longer be used for that purpose in the future.
This led to a major overhaul in the form of Xcode 14 beta, where Apple no longer had the option to build bitcode apps. Developers for iOS and MacOS will still be able to use bitcode with warnings, but this will be phased out later. Basically, it’s not easy to produce bitcode applications anymore.
Why is this important, and who is affected?
Future Xcode releases may now prevent security vendors from using bitcode. Decoding vendors typically have two approaches to decoding bitcode that will be affected differently.
The first approach is to obfuscate the application, where the obfuscation works on the whole application in bitcode format, after build, as IPA or Xcarchive files. This is a great approach because it means that obfuscator does not need to be tightly integrated into the toolchain and obfuscations can work across the entire application instead of individual modules at a time.
The second is a toolchain integration approach where the obfuscator replaces or patches components in Apple’s 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 effective approach is now deprecated. Vendors using this are likely to continue their work (with warning) for at least another year. However, this method will probably be prevented in Xcode 15 or 16.
The latter approach may also be wobbly in the future, as we don’t know if Apple will remove LLVM or prevent access to it in the compiler at some point – possibly even if no warning. All vendors currently using LLVM-based application protection enablement to protect iOS and MacOS apps will be affected by this change.
What does this mean for the future of application security?
Eventually, LLVM will become less useful and could disappear altogether as Apple looks 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 harder to protect, and thus fewer vendors will have the product to do so.
It’s entirely possible that this change could affect the security of many apps on the App Store. Whether or not this happens will depend on the adaptability of security vendors. Those using the toolchain integration approach should be fine for the time being, but they risk being shut down without warning in the future.
It is likely that we will see an increase in the native binary-based approach to obfuscation. The main difference is that this approach to obfuscation is where the built machine code is manipulated directly. Currently, not many error decoders use this method as it is particularly difficult to implement and may need to support multiple binary formats and/or CPU instruction sets.
In any case, while the future of code obfuscation may be uncertain, one thing is for sure – application developers will need to take a proactive, vendor-monitoring approach security and plan accordingly if they want to make sure their apps stay secure.
Andrew Whaley is Senior Technical Director at Promon, a Norwegian application 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 capabilities. new security.
