Arming ARM Protection: ARM-based Arm Wrestling

Auspiciously Aggravating ARM Attackers 

A few years ago, Apple released a single paragraph of text that changed the course of Application Security overnight. 

Starting with Xcode 14, bitcode is no longer required for watchOS and tvOS applications, and the App Store no longer accepts bitcode submissions from Xcode 14. Xcode no longer builds bitcode by default and generates a warning message if a project explicitly enables bitcode: “Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.” The capability to build with bitcode will be removed in a future Xcode release. 

Apple clearly knew this was coming, and preserved Glendenning Barn as part of their campus just to take Enable Bitcode on a tour. They started behind the barn. It was a short tour. Not to worry, the Airpods have great noise canceling, and Tim probably didn’t hear anything.  

Thankfully, we were ready for the starting gun and had already been planning for the change. Modifying the intermediary bitcode is a fragile and frustrating process as it’s tied to the compilation toolchain controlled by Apple and the Swift open-source community. Having a third-party security tool integrated in your compilation chain dramatically slows down an app dev’s development speed.  

Build-time Application Security is a pain, and, while we still maintain our build-time tooling, we’ve been purposefully building a post-build focused solution: Digital.ai Application Security for Mobile: ARM. We can now modify and inject security into a Mach-O binary file directly rather than modify the intermediary bitcode during compilation.  

Now, I’ll do what Old Yeller can’t and give an update on progress and next steps for our ARM Protection product. 

Public PSA Announcement 

As anyone who’s used Ghidra before will happily attest to, Mach-O executable file manipulation is difficult. The compiler, linker, and loader all have specific rules they follow (many of which are undocumented) to create and load a working binary file. Injecting our detection code after the compiler and linker have done their job, without breaking promises made to the loader, adds significant complexity to the Application Security space.  

That’s why we’re the only ones doing this; it’s just that trifficult.  

This is a double-edged sword though, and attackers have incredible difficulty removing or branching around our guards without invalidating the binary. The end result is worth it, and we’re dedicated to improving our already ground-breaking start. We’ve heard the request for more detailed per-guard access to our custom Tamper and Non-tamper actions, and we’ve dedicated our engineering team to delivering that need. Our engineering team fights with __DATA and __TEXT so yours doesn’t have to. 

What’s Here Now? 

Fabulously Forceful Frida Firefighting 

Anyone involved in any form of client-side security knows what Frida is at this point. The tool, sponsored and developed by our friends at NowSecure, is (dynamically) instrumental to developers around the world. Unfortunately, it’s also the most powerful application attack tool built so far.  

We’ve engineered a performant solution to detect Frida’s instrumentation process, and we’re now able to inject comprehensive and secure Frida detection directly into a binary file. As with all of our detection and obfuscation processes, this is internal-only IP. LLMs do not have access to the source and cannot learn from any of our techniques. In one of our detection mechanisms, we scan critical places inside and outside of the application sandbox for fundamental traces left behind by both frida-server and frida-gadget. The more we scan the less performant the algorithm is, and our detection process is specifically designed to solve that concern. We’ve developed an algorithm that quickly identifies potential places of interest, marking them for future investigation. The guard then runs a targeted investigation of those marked identifiers to detect the presence of Frida. We found this algorithm, through our own testing, to have a significantly reduced impact on the performance of the modified application. 

None of these changes impact the application’s runtime behavior and allow us to detect the presence of Frida without noticeable impact on an application’s performance. This detection comes in the form of the more generic Dynamic Instrumentation Detection Guard and will be shipping (with custom Tamper and Non-tamper actions) in our upcoming release. 

Hindering Hackers’ Happy Hooking 

Hook Detection sounds simple at face value: stop attackers from injecting changes in control flow into code an application calls. Detection, in that case, truly is simple. We make sure the assembly inside, and outside, of the binary doesn’t contain any unauthorized control flow modifying instructions (B, BL, CBZ, etc.) In reality, that simple detection step is not enough to protect modern applications. The security complexity skyrockets when applications call external libraries from within the application package, or system libraries outside of the binary. 

Detecting potential modification, hooking, or full replacement, of system libraries (a form of which was the cause of the 2024 Ticketmaster breach) is a substantial jump in scope. Even though jmps are an x86 thing, ARM Protection’s Hook Detection Guard protects against 3rd party modification attack vectors as well. As mentioned, while explaining one of our Frida detection algorithms, the algorithm for detecting these high impact modifications is proprietary.  

Suffice it to say, in this case, I won’t share the details of this particular mechanism publicly. This multi-purpose Guard hits shelves, custom actions included, together with the Dynamic Instrumentation Detection Guard in our upcoming release. 

What’s Coming Soon? 

Joyfully Jam-packed Jailbreak JDetection 

We’ve started working on our next generation of Jailbreak Detection and it’s coming soon to a binary near you. Dopamine and its many forms and iterations, especially Dopamine-Roothide, has been a tricky tool to detect. We have some inventive, powerful, detection options that you can read about in Amir’s blog posted last week. These improvements, and more, are currently in-flight in ARM Protection. 

Naturally Navigating NAPs (Native Android Protections) 

While ARM Protection started as an iOS focused tool, Android native shared object support is a platform and security need we’ve been working hard to address. In a future release we’ll be officially launching an update to Application Security for Mobile: ARM with Android support targeted at protecting Android native shared objects. The native shared object environment in Android is insecure by default, and adding application protection to those compiled ARM libraries is critical for comprehensive application security.  

This one is near and dear to me, personally, as I’m terrified of Java’s refusal to expose pointers. What are you doing with them? Why don’t you trust me? Why do you have a straight jacket with you?  

Comically Corroborating Conclusion 

Apple’s destruction of Embedded Bitcode and the difficulties of a compile-time protection product make the tools of the past clunky and less resilient to future rug-pulls from Apple. Digital.ai’s Application Security for Mobile: ARM revolutionizes Application Protection by getting out of build system complexities. While it’s harder for us to build, it’s easier for you to use. 

Instead of repeating myself further, I’ll leave everyone with a riddle: 

I have a curve, but I’m not a smile, I catch things that swim or hold weight for a while. In coding, I wait for an action to fire, then trigger a script, fulfilling a desire. I often connect things that hang in the air, and though I may have teeth, I don’t eat or share. You might see me on a door, or on a boat’s side, always ready to grab, secure, or hide.