It’s difficult to find technically useful, well contributed information on mobile security testing and mobile software development life cycle (SDLC) best practices. There is a lot of high-level info scattered around, and it seems like new government cybersecurity publications are popping up all the time which makes it hard to tell how everything fits together. So I set out to research the topics on my own, and this blog covers what I’ve found. As I continue, and as comments come in, I’ll make corrections and updates.

Let’s start with very useful, seminal work on mobile security testing, with OWASP® contributors doing a wonderful job with two foundational works. Any searches on the topic of mobile security testing should have landed on them, but in case yours didn’t.

The first is the Mobile Security Testing Guide (MSTG)1 from OWASP. From its introduction:

“The OWASP Mobile Security Testing Guide (MSTG) is a comprehensive manual for testing the security of mobile apps. It describes processes and techniques for verifying the requirements listed in the Mobile Application Security Verification Standard (MASVS), and provides a baseline for complete and consistent security tests.”

If you haven’t seen it before, at first glance you may get the impression that it’s merely a high-level overview of basic principles that any mobile developer or security expert already knows. But in fact, it’s quite comprehensive and technically detailed, a great living work by all its contributors, and a very useful resource for new and advanced mobile security gurus alike.

The MSTG is comprised of three primary sections, again from the Guide’s overview: 

“The General Testing Guide contains a mobile app security testing methodology and general vulnerability analysis techniques as they apply to mobile app security. It also contains additional technical test cases that are OS-independent, such as authentication and session management, network communications, and cryptography.

The Android Testing Guide covers mobile security testing for the Android platform, including security basics, security test cases, reverse engineering techniques and prevention, and tampering techniques and prevention.

The iOS Testing Guide covers mobile security testing for the iOS platform, including an overview of the iOS OS, security testing, reverse engineering techniques and prevention, and tampering techniques and prevention.”

The second work from the OWASP Mobile Security Project™ and its contributors, is the Mobile AppSec Verification Standard (MASVS)1.

From its introduction, “The MASVS is a community effort to establish a framework of security requirements needed to design, develop and test secure mobile apps on iOS and Android.”

You must admit, this is a bold undertaking to produce and keep current, but it’s a sorely needed one and a job well done. A useful summary from the document:

“The MASVS defines two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing client-side threats is a design goal.

Fulfilling the requirements in MASVS-L1 results in a secure app that follows security best practices and doesn't suffer from common vulnerabilities. MASVS-L2 adds additional defense-in-depth controls such as SSL pinning, resulting in an app that is resilient against more sophisticated attacks - assuming the security controls of the mobile operating system are intact and the end user is not viewed as a potential adversary. Fulfilling all, or subsets of, the software protection requirements in MASVS-R helps impede specific client-side threats where the end user is malicious and/or the mobile OS is compromised.”

And now for what’s happening from the U.S. gov end of things and recent cybersecurity standards and guidance news. Let’s start with the National Institute of Standards and Technology (NIST) which produces many publications on the topic of cybersecurity.

The recent news has been around the NIST 800-218 publication in 2021 and updated in February 2022, entitled “Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities”.

It’s a comprehensive and relevant work as it applies to mobile software development and testing. Excusing the pun, it sets the new standard as far as past security frameworks for SDLC go. It contains numerous references to useful resources, and the OWASP MASVS resource is primarily referenced within the Produce Well-Secured Software (PW) section.

I find the NIST SSDF publication to be well thought-out and as you read through the examples for each “task”, it makes for a good checklist to walk through for your mobile software development practices (or any software development). Some tasks are easier said than done, but it provides for a great “you are here” resource for understanding your current SDLC security posture and what you need to keep an eye on moving forward.

Having no affiliation with it, I found this blog useful when reading NIST 800-218:

I Read NIST 800-218 So You Don’t Have To - Here’s What to Watch Out For, by Dan Lorenc.

When searching for other NIST cybersecurity initiatives that are currently underway, I found the following particularly interesting. They are looking into consumer labeling practices for both software and IoT devices. In a nutshell, when software or IoT devices are made available for end-use, the level of security testing performed or achieved would be clearly indicated. According to the links below, an initial summary report is to be published by May 12, 2022. This will be interesting to say the least and I’ll update this blog with relevant information.

Recommended Criteria for Cybersecurity Labeling of Consumer Software

Consumer Cybersecurity Labeling Pilots: The Approach and Contributions

There also have been recent news headlines made by the Cybersecurity & Infrastructure Agency (CISA), first established in 2018.

Zero Trust Maturity Model, introduced in September 2021, and

Applying Zero Trust Principles to Enterprise Mobility, newly introduced in March 2022.

These works, to me at least, are more indirectly related to mobile security testing and SDLC best practices. This makes sense as Zero Trust refers to user access privileges and hence the in-production phases of SDLC.

But I would have hoped that Zero Trust would have extended to cover the design and development phases of the SDLC as more and more vulnerabilities are likely to be introduced well before software deliveries.

In the Zero Trust Maturity Model document, the topic of app security development and testing is included in the Application Workload pillar and its Application Security guidance, but that’s about it. It doesn’t use the acronyms, but it’s basically implying a shift from DevOps to DevSecOps. 

Traditional – Agency performs application security testing prior to deployment, primarily through static and manual testing methods.

Advanced – Agency integrates application security testing into the application development and deployment process, including the use of dynamic testing methods.

Optimal – Agency integrates application security testing throughout the development and deployment process, with regular automated testing of deployed applications.”

Looking through the Applying Zero Trust Principles to Enterprise Mobility document, you eventually reach “Table 1: Enterprise Mobile Security Components”. And wading through each, mobile security testing lands on its relatively small Mobile App Vetting (MAV) component.

Not bad I suppose for a CISA framework where the Zero Trust context aims at a different aspect of mobile security and different phase of mobile software development. Would have been helpful if CISA’s MAV and NIST’s SSDF were linked or cross-referenced.

I’d keep an eye on CISA “Zero Trust” publications, but looks like the NIST “SSDF” publications are currently more directly relevant to the topic of mobile security testing and mobile SDLC.

To learn more about Corellium and what we do, visit us at Corellium.com 

1 OWASP trademarks and published works belong to and are under copyright by The OWASP Foundation. The OWASP works are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. For any reuse or distribution, you must make clear to others the license terms of the works.

It’s hard to find useful, well contributed to information on mobile security testing and best practices. Recent cybersecurity publications from U.S. gov agencies often confuse the search. Here’s one interpretation of how they’re interrelated.

Where does Mobile App Security Testing fit into the latest NIST SSDF and CISA Zero Trust publications?

2021 has been an incredible year for us. Like most of the world, it's been a year of change, hope, and growth. We've proudly welcomed hundreds of new businesses, government agencies, and security community professionals to our virtualization platform. And we’ve been expanding our developer and customer success teams as quickly as possible to support our fast pace of innovation.

Today, we're excited to announce that we've raised $25M in Series A funding led by our friends at Paladin Capital Group, Cisco Investments and a few other strategic supporters.

This equity-only round will be used to accelerate our growth, support partnership initiatives, and expand our platform to deliver a wider variety of virtual IoT devices.

For the last four years, our focus has been on creating an incredible security research tool for iOS and Android by bringing a better alternative to the mobile device emulator and device lab markets. While this is still a key focus for us, we're using this new funding to broaden our horizons, with the goal of becoming the go-to platform for testing, research, and development on all Arm-powered IoT devices - from routers to cars to robots.

“In a world of increasing security threats, malware attacks, and dynamic security regulations, effective full-stack system testing - apps, firmware, and hardware - is more critical and complex than ever. As the world’s 13 million Arm developers shift to DevSecOps, Corellium provides the tools they need in a scalable, repeatable, high-performance, high-accuracy, and cost-effective solution. We are excited to be partnering with Corellium in its next phase of growth as the company continues to expand its technical offerings.”

— Mourad Yesayan, managing director at Paladin Capital Group

Because our virtual models run natively on Arm, developers can run production code without making changes, and they run with native-like speed. Combined with our powerful security tools, our advanced virtual environment vastly improves and accelerates end-to-end development, testing, and security acceptance lifecycles on Arm. And to best meet our diverse customer needs, we offer our virtual platform as a Cloud service or as on-site server appliances.

"We know our customers need to be supported across hybrid processor environments. That’s why we are excited to invest in Corellium because it gives customers a new virtualized development paradigm, enabling effective penetration assessment, application testing, and security and threat intelligence research at scale.”

We have big plans for 2022 and we’re grateful for the love and support of the security community and remain steadfastly focused on creating products that work like magic. ✨

If you're excited about what we're working on and want to join us on our journey, check out our open roles. You can also read more about our Series A funding on Forbes, BusinessWire or the Cisco Investments Blog.

We've raised a Series A round with our friends at Paladin and Cisco Investments.

$25M to Accelerate Arm Testing, Research, and Development

The latest industry news, interviews, technologies, and resources.

Resources and insights

Last week, Arm gave us a glimpse into the future by unveiling the next-generation of Arm processors: the Armv9 architecture. This is a huge deal for the future of mobile devices. The device you’re carrying around in your pocket is almost certainly running on an Arm-based processor, so these processor-level improvements will lead to faster, smarter, and more secure devices that you use day-to-day.

There are two groups of features in Armv9 that we’re particularly excited about. The first is that next-generation Arm processors will have security built in right at their very core. That includes features like the new Confidential Compute Architecture built around TrustZone, as well as brand new security features like Memory Tagging Extensions (MTE) specifically designed to help secure devices against sophisticated memory-corruption attacks.

The second exciting group of features are all about performance. Armv9 improves Scalable Vector Extension to SVE2, adds new features and optimizations for machine learning, and adds new features like the Transactional Memory Extension (TME) to make parallelizable programs even faster. These improvements won’t just make devices faster, they’ll also be helping power even better quality video, graphics, and games on your next-gen device.

Of course, these upcoming new Armv9-based devices mean a whole new class of devices to virtualize. And perhaps it’s worth explaining how we do it, and why we built our hypervisor to run natively on Arm.

Most device emulators rely on either dynamic translation technology or cross-compilation to emulate the software you’d normally find on a device. Dynamic translation uses software to translate each Arm instruction in the program into equivalent instructions that your non-Arm processor knows how to interpret. That gives a very accurate translation of how the program will behave, but unfortunately that translation takes both time and power to achieve. Over the course of emulating a substantial program, that extra time and power quickly adds up, giving you a slow and unresponsive emulated device that burns its way through your laptop’s battery life in minutes.

Cross-compilation is a different approach, and comes with different problems. For example, the emulated software is no longer exactly the same as the same software on a real device, and these differences can lead to missing bugs during development that suddenly show up when you deploy to real devices. Cross-compilation also doesn’t work if your application relies on libraries you don’t have source-code for.

At Corellium, we avoid all of these problems using our secret weapon: the Corellium Hypervisor on Arm (CHARM™). This hypervisor is built from the ground-up to virtualize Arm-based devices, and we run them directly on Arm servers. Mobile applications on Corellium run natively fast because we run them directly on a modern Arm processor. The application, its shared libraries, the operating system, and all of the supporting services on the mobile device are running almost exactly as they would on a physical device. And that means they’re running the same logic in your virtual device as they would on a real device, with byte-for-byte and instruction-for-instruction clarity.

We’re excited for the release of Armv9. We don’t yet know what the future holds, but we already know the next generation of devices will be better, faster, and more secure than ever. And whatever those devices look like, we’ll be here at Corellium, giving you virtual, full-fidelity, and ultra-high performance virtual devices, powered by our next-gen Arm servers.

If you’re interested in learning more about Corellium’s leading Arm virtualization platform and tools, visit us at corellium.com and sign up for a free trial!

Last week, Arm gave us a glimpse into the future by unveiling the next-generation of Arm processors: the Armv9 architecture. This is a huge deal for the future of mobile devices, and there are two groups of features in Armv9 that we’re particularly excited about.

Armv9 and Corellium: Why we chose Arm vs X86

When Apple released their desktop products with the M1 processor in November 2020, quite a few people in the tech community were surprised by the excellent performance of these systems.  But those who have been following the development of Apple phone chipsets closely knew that the evolutionary path Apple followed would result in a powerful 64-bit Arm processor.

At Corellium, we've been tracking the Apple mobile ecosystem since iPhone 6, released in 2014 with two 64-bit cores.  Since then, Apple has been focusing their energy on building faster chips, preferring to improve single-threaded performance over throwing more cores on the chip.  This approach was enabled by their in-house hardware design team, and resulted in unique parts with a broad feature set, leading the industry in terms of architectural features.

It also made Apple silicon rather distinct from all other 64-bit Arm hardware in terms of both CPU core and peripherals.  Our Corellium virtualization platform has been providing security researchers with unparalleled insight into how operating systems and programs work on Apple Arm processors. But in the process of developing our virtualization system, we also gain knowledge about the hardware we are modeling, and this knowledge can be best refined by testing it against real hardware - which we have only been able to do with the emergence of checkm8, an exploit that let us load programs onto Apple smartphones.  This led directly to the Sandcastle project, where we built a kernel port to the A10 processor in early 2020.

So when Apple decided to allow installing custom kernels on the Macs with M1 processor, we were very happy to try building another Linux port to further our understanding of the hardware platform.  As we were creating a model of the processor for our security research product, we were working on the Linux port in parallel.

Many components of the M1 are shared with Apple mobile SoCs, which gave us a good running start.  But when writing Linux drivers, it became very apparent how non-standard Apple SoCs really are.  Our virtual environment is extremely flexible in terms of models it can accommodate; but on the Linux side, the 64-bit Arm world has largely settled on a well-defined set of building blocks and firmware interfaces - nearly none of which were used on the M1.

To start with, Apple CPUs boot the operating system kernel in a different way. The bootloader, traditionally called iBoot, loads an executable object file in a format called Mach-O, optionally compressed and wrapped in a signed ASN.1 based wrapper format called IMG4.  For comparison, normal Linux on 64-bit Arm starts as a flat binary image (optionally compressed and put in one of the few container formats), or a Windows-style "PE" executable on UEFI platforms.

But the real surprises start when further CPU cores are brought up.  On other 64-bit Arm systems, this is done by calling the firmware through an interface called PSCI (a few systems use poll-tables, but the firmware is still responsible for them).  But on M1, CPU cores start at an address specified by a MMIO register (set to a specific offset within the kernel image, then locked, by the bootloader), and simply begin running the kernel.

If that wasn't enough, Apple designed their own interrupt controller, the Apple Interrupt Controller (AIC), not compatible with either of the major Arm GIC standards.  And not only that: the timer interrupts - normally connected to a regular per-CPU interrupt on Arm - are instead routed to the FIQ, an abstruse architectural feature, seen more frequently in the old 32-bit Arm days.  Naturally, Linux kernel did not support delivering any interrupts via the FIQ path, so we had to add that.

When you try to get multiple processors in a system to talk to each other, you have to provide a set of inter-processor interrupts (IPIs).  On older Apple SoCs, those were handled similarly to IRQs, by executing MMIO accesses to the AIC.  But on newer ones, Apple uses a set of processor core registers to dispatch and acknowledge IPIs, and they are - again - delivered as FIQs. So the FIQ support was really quite important.  Fortunately, our work on virtual models in our security research product has prepared us for this.

After working out a few more hardware quirks, and adding a pre-loader that acts as a wrapper for Linux and provides a trampoline for starting processor cores, we could set a framebuffer and were greeted with the sight of eight penguins representing the eight cores of the M1.

Unfortunately, since we do not have a UART cable for the M1 Macs, we had to find another way to add a keyboard (and maybe even a mouse).  There are fundamentally three paths to do that on the M1 Mac Mini: the built-in USB host in the M1 chip (serves the Thunderbolt/USB ports), the xHCI USB host on PCIe (serves the type A ports) and Bluetooth.

While we won't get into the details of Apple Bluetooth, we'll note it uses a non-standard PCIe-based protocol that is supported in our virtualization product, and would require not only bringing up PCIe ports on the M1 chip, but also writing a custom kernel driver for this protocol.  That made it seem like the worst choice for getting this done quickly.

This means we had a choice between bringing up PCIe and using the standard kernel xHCI driver, or bringing up the built-in USB controller.  Apple has been using the Synopsys DWC3 dual-role USB controller for a while in their chips, and it has a Linux kernel driver.  Unfortunately, Apple is also in the habit of adding custom logic around the controller, so this ended up being a fair bit of work.

Both the PCIe and the built-in DWC3 USB controller on M1 use IOMMUs, called DARTs. Apple has been refining their DART design in a consistent, evolutionary way, resulting in an excellent, full-featured IOMMU.  The last version even has support for sub-page memory protection, rarely seen elsewhere. (We had a blog post on IOMMUs and other similar devices last month.)

To actually connect the USB port inside the M1 to the USB type-C connectors on the back of the Mac Mini, we had to interact with a chip on I2C (which means GPIO and I2C drivers) which has customized firmware.  We've seen the protocol for these while building our virtualized models; nothing is a big surprise if you have a bird's eye view of the system.

After a few days of figuring out the details of USB, we were finally able to connect an external USB hub and connect a keyboard, mouse and a Flash drive, opening the possibility for running a normal desktop Linux distribution.

Tutorial for USB Boot ( Works on Mac Mini/Pro/Air )

The first step to booting Linux on your Mac M1 is to download the Ubuntu POC rootfs available here. We used a Raspberry Pi image because it was a live USB boot image, so we only had to make minor modifications to boot it.

You will need a minimum 16G external USB drive. Extract the image by typing: 

tar -xjvf ubuntu-20.10-preinstalled-desktop-arm64+raspi.img.bz2

Then, use disk utility to locate the name of the external disk. Finally, copy the image to the USB drive using:

sudo dd if=ubuntu-20.10-preinstalled-desktop-arm64+raspi.img of=/dev/rYOURUSBDISK bs=1m

Once you complete the dd, you will need to copy the WiFi firmware across to the exfat partition. You can do that by typing:

cp -RLav /usr/share/firmware/wifi /Volumes/system-boot

Connect your USB drive to the Mac M1 using a dongle via the USB C port. The USB A ports are not currently supported.

To boot into 1TR (the one true recovery OS), turn off your Mac M1 and then hold Power until you see "loading options". Once it loads, you can select the terminal option from the menu bar at the top.

The next step is to install the custom kernel. We have made a script that makes this step easier for you. You can run it by typing: 

bash -c "$(curl -fsSL https://downloads.corellium.info/linuxusbboot.sh)"

The script will prompt you for your username and password. One you see it print "Kernel installed" it's safe to type reboot.

Once you're booted, you'll be prompted for a login. The username is "pi" and the password is "raspberry." The root password is also "raspberry."

To revert to booting MacOS, in 1TR open terminal and type bputil -n

Tutorial for NVME Boot ( Works on Mac Mini/Pro/Air )

Warning! Don't attempt this step if you aren't sure what you're doing. If done incorrectly, this can harm your device.  

Open Disk util, then click the drive at the top on the left and select partitions. In the partition information, select the + and add a exfat partition of at least 16G. Take note of the disk id and the partition offset. Once you have added the partition, make sure to unmount that partition. You can now dd the image to that new partition. To do that you need to first extract the image:

tar -xjvf ubuntu-20.10-preinstalled-desktop-arm64+raspi-nvme.img.tar.bz2

Then dd to the specific partition you created.

sudo dd if=ubuntu-20.10-preinstalled-desktop-arm64+raspi-nvme.img of=/dev/rYOURDISK bs=1m

Next, create another exfat partition with the size of 200M and call it EFIESP. Then once its finished formatting, you can copy the Wifi firmware to that EFIESP partition by typing:

cp -RLav /usr/share/firmware/wifi /Volumes/EFIESP

bash -c "$(curl -fsSL https://downloads.corellium.info/linuxnvmeboot.sh)"

If you're interested in supporting our work on open source projects like these, please consider donating on our behalf to the EFF, who work tirelessly to defend security researchers and protect the digital rights of users and developers. You should also consider supporting the work being done by the folks over at Asahi Linux.

We'd like to extend a very special thanks to the engineers behind PongoOS for contributing their expertise and collaboration. We're looking forward to updating with a version that uses PongoOS as the bootloader!

A brief overview of our approach to porting Linux to the Apple Mac Mini M1 and a tutorial for installing our Ubuntu POC

How We Ported Linux to the M1

While developing our mobile hardware models, we've run into a large array of schemes aimed at improving physical memory security. The sheer ingenuity displayed by the engineers in coming up with them often goes unnoticed, even by technically inclined users, because most of the time these mechanisms are quietly working in the background acting as mitigations for potential complex exploit chains.

Instruction-level schemes that focus on hardening virtual memory access of one kind or another (code flow, heap allocation) have been receiving a lot of attention, for instance ARMv8.3-PAC or ARMv8.5-MTE. They are aimed at solving different problems so we won't talk about them here.

Modern mobile devices have grown in complexity at a breathtaking pace. A classic GSM mobile terminal with GPRS would probably include a single core, perhaps an ARM7 or ARM9, a modem handling most of the core functionality, and a simple text-based AT command protocol running between those two. The physical RAM of the Application Processor (AP) would be really quite private to it, with little in the way of DMA, and no way to access it from other programmable processors.

This is as far from a modern smartphone as you can imagine.

A typical smartphone SoC in 2020 includes multiple requesters sharing the address space - not just many cores in the AP, but also multiple, possibly heterogeneous, cores running key functions such as digital signal processing for modem, audio and camera, 3D graphics hardware, (overly) flexible DMA blocks, low-power-mode system control processors, and others. The cores that can perform main memory operations number in tens now. For instance, the Apple A14 includes no fewer than 12 "accessory" ARM cores in addition to the 6 visible to the user software, two audio DMA controllers, three graphics support blocks (all with DMA capability) and an encryption block. Even older parts such as the Qualcomm Snapdragon 845 will have upwards of ten memory requesters.

Arbitrary, unrestricted memory access by any single one of these cores can lead to a complete compromise of the SoC. Their heterogeneous nature means each of them can have its own set of security vulnerabilities. It's hard enough to write reasonably bug-free software once; doing it multiple times makes it exponentially harder.

In addition, there are now paths in the system that allow injection of memory access commands from the outside. The most notorious one of these is PCI Express, which is designed for efficiently performing memory accesses to host's memory. But a poorly secured debug path into any of the other cores can also result in memory access injection.

Fig.3: Attack paths in a modern smartphone (PCIe, compromised coprocessor) 

The lowest-cost solution to some of the issues with physical memory security is to use a higher privilege level in the main CPU core to control DMA configurations of other blocks or provide security to accesses from the CPU itself.

The ARM architecture provides a mode perfectly suited to this task. The EL2 mode, intended for accelerated hypervisors, has seen significant use on both Samsung and Huawei devices as a security-privileged execution mode instead. It can restrict access to physical memory and memory-mapped I/O using second stage memory translation, and from that primitive a pretty compelling security architecture may be constructed.

Let's start with an example of a simple DMA block that moves data from system memory to an I/O device, or perhaps another place in memory.

Typically, DMA configuration is set by a driver running in the operating system kernel, so in EL1 in modern ARM privilege level hierarchy. A lot of the configuration will be fairly non-sensitive: endianness translation, timestamps, element and FIFO sizes being set incorrectly would be perhaps disappointing or unpleasant to the user - especially in the case of audio, as anyone who ever worked with audio DSP will certainly appreciate - but not really leading to the system compromise.

There are in fact only two key elements to a DMA transfer configuration that really matter from a security standpoint: base address and transfer size. So, some hardware vendors have these two registers filled out by software running at a higher privilege level. That software can vet the physical memory address passed to it and make sure the configuration written to the hardware will not violate security assumptions of the system. All that's required to make this a pretty good approach is to make those registers non-writable by ordinary kernel code, for instance by putting them in their own page-sized memory range, and using second translation stage (controlled by EL2 privilege level) to prevent EL1 (kernel) access.

This approach works really well for simple DMA controllers, where vetting the address/size block pairs is sufficient. It does not work as well for mitigating compromises caused by fully programmable accessory processors, but it's still a valuable component of other mitigations - for instance by ensuring the kernel cannot surreptitiously disable them without going through validation at a higher privilege level.

Additionally, once built, the same mechanism can be used to protect other system security guarantees. For instance, Samsung and Huawei devices use EL2 to protect pagetables and some security-critical kernel structures (SELinux, credentials and similar); writes to pagetables must go through EL2, which makes sure the kernel does not attempt to map memory or MMIO that it has no right to use. Similarly, Apple processors modify their understanding of memory page permission bits when they run a special, separate piece of code responsible for pagetable modification (PPL) using a novel mechanism called APRRs. In this case, EL2 is not used, but on newer SoCs, a "lateral" exception level has been introduced with much the same effect on access permissions.

Lastly, any discussion of elevated protection levels must necessarily include ARM architecture's Secure mode. This long-standing feature of ARM processors, included in the TrustZone feature set, allows the processor to run in two "worlds": secure (S) or non-secure (NS). Most regular operating system software would run in NS world (EL0NS to EL2NS), but critical security functions could run in EL0S or EL1S.

What makes this mode different from the EL2, APRR or "lateral" exception level based security is the concept of marking every memory access request with the world it came from. Then, memory controllers and peripherals can     decide to accept (or not) NS requests. There's a cost to making that work well: caches need to retain information on the world each cacheline is meant for. However, it's also a more powerful mechanism for DMA protection: DMA controllers and accessory processor requests could also be classified as S or NS, and their memory accesses could be subject to the same restrictions.

In many ways, this is the prototypical hardware physical memory security solution, pioneered by the Broadcom secure application processor line, and extended into many refined versions giving more fine-grained control. Time     to talk about these.

The tags on memory requests can be extended beyond Secure / Non-Secure. For instance, they can include the requester's identity: did the request come from the AP, or from the audio DMA controller? Some requesters can be even more flexible, including a "stream ID" with their request: is this request retrieving a next DMA descriptor (which contains physical addresses, and can lead to compromise) or just audio data (which does not)? This is the foundation of a whole family of physical memory security methods, the first of which - and the simplest - is the address filter.

Sometimes, all that's needed is to give a specific DMA block (or processor) permission to access the memory range. There are two common approaches to this. One can insert a hardware block between the DMA block and the system fabric (which routes memory requests around the SoC) and have it compare addresses on the outgoing requests against a list of ranges, perhaps configured by MMIO from the main system processor (running in a higher privilege mode, to protect it better). Only requests that hit one of these specified ranges will be allowed to proceed to the system fabric for fulfillment. This is how the DAPF block works on Apple CPUs.

Other approach is to put the enforcement on the target side of the request. Target side enforcement requires the system fabric to route the security tag from the source, and to make sure that the "requester identity" part of the security tag is in line with the actual requester; after all, if a programmable requester could freely spoof the tag on the bus, that is to claim the request originated from someone with higher privileges, the system security guarantees may not be met.

This approach is used by the original Secure / Non-Secure peripheral classification in TrustZone ("only Secure requesters may touch this peripheral") and dedicated memory ranges for accessory processors ("only modem DSP can use this range of memory, because it's its own program / data memory"); those would be enforced at the memory controller with a permission bit or range map.

A simplified case would be one where a memory range is fully locked out for write transactions, where the security tag is implicit in access type (is it a read or write?) and the memory controller will deny writes in a list of protected ranges. This is what the AMCC does to protect kernel memory from writes on modern Apple SoCs.

A more advanced and flexible approach to the same problem is called IOMMUs. This stands for I/O Memory Management Units; they create a virtual address spaces for devices analogous to the virtual addressing in processors. Now, the protection hardware can apply and modify not only permissions, but also the address being accessed. This requires significantly more memory to store the translation and permission map, and usually ends up with a set of I/O pagetables located in memory that the IOMMU reads from as it translates I/O accesses to the target. It's a significant complication compared to using an address filter, where the filter usually fits in the hardware MMIO registers or on-chip RAM visible via MMIO.

What makes IOMMUs so great and worth this effort, however, is their ability to hide physical memory addresses from peripheral devices. This has twofold consequences. From the security standpoint, it means system memory map is not disclosed to the potentially compromised accessory processor or DMA requester. Additionally, it means non-linearly allocated memory can be presented to the peripheral as a linear virtual address space. This is not only a performance improvement, but also massively simplifies DMA requester design and removes the need to program scatter-gather lists into the requester.

While ARM has been promoting the use of centralized IOMMUs with their SMMU (System MMU) specification, Apple SoCs use a different approach. Many of their peripheral blocks have a device called a DART in front of them. But both of those IOMMUs share a general design, which is that each request stream uses a specific pagetable, which the IOMMU walks. The walk results (translations and permissions for a given address page) are cached in a TLB (Translation Lookaside Buffer) local to the IOMMU, which needs to be flushed (discarded) when the pagetables are modified.

Another, more specialized, kind of IOMMU has shown up in Apple's A10. The NVMe access is performed as fairly long linear transfers, and there's rarely a need to reuse a translation after the transfer is done. So the TLB concept, where all translations share a cache, and are flushed together when any of them is no longer needed, fits poorly. The hardware designers decided to provide scatter-gather tables for each transfer instead; a simple list of target page addresses that a specific range of source addresses would translate to, and make it possible to flush only a single transfer after it's done. This is the SART, and it represents a good example of a custom design guided by performance considerations.

Either way, the task of filling out and managing IOMMU configuration is absolutely critical to security. Otherwise, a perfectly innocuous transfer could instead write arbitrary physical memory, for instance credentials or other permission bits. All of this configuration should therefore be performed by software running at a higher privilege level; this is indeed the case on both Samsung devices with Qualcomm CPUs, and on Apple hardware. They both make it impossible to access IOMMU from lower privilege levels; in the Apple case, by controlling kernel pagetables (which themselves are protected by the APRRs) and in the Samsung case, by second-stage memory translation which is only accessible by EL2.

As a side note, not everyone uses IOMMUs to their full potential. Certain devices use them as a simple address filter, by providing a map of identity address translations and only changing the permission bits. This slightly decreases their utility, but they are still good security.

If the attack model is extended to include sophisticated external attacks that include monitoring memory bus transactions, none of these methods are sufficient. After all, if the attacker can directly alter physical memory contents, checking permissions and translating addresses will amount to nothing. If this is a serious consideration, however, a solution presents itself in form of in-line memory encryption.

The simplest form of memory encryption, used for instance on older Freescale (now NXP) devices, would pass the memory transactions through a cryptographic block with a secret key. Let's consider the consequences:

path to tamper resistance is easier: just erase the on-chip key when a tamper event happens,

as long as the encryption key is derived partially from the memory address, copying attacks are not possible (where encrypted data is moved from one memory location to another in knowledge that it will decrypt to the same plain-text data),

corruption attacks are possible, though poorly controllable (a given corruption of encrypted data can produce arbitrary corruption of plain-text data - but sometimes this is a good attack, for instance if software rejects nonsense data or has a faulty error handler!),

replay attacks are possible, because there's no way to detect that a memory block was reverted to a previous state,

no extra memory or bandwidth is consumed as data does not change size during encryption,

latency is low if decryption is started with the requested address.

The corruption and replay attacks are pretty serious. Two subsequent solutions have been deployed to prevent these. The corruption attack can be defended against by adding authentication; a cryptographic keyed digest of a memory block is stored along with it. This solution increases complexity (a digest generator is now needed in hardware, even if it's just AES-GCM authentication tags), memory usage and bandwidth (because authentication data must now be stored) and latency (because the whole block must now be read to verify its digest). This solution is commonly employed, including on Broadcom's pioneering line of secure processors, and likely Apple SEP hardware.

Finally, the replay attack, the hardest one to control, can be prevented by creating a Merkle-tree like structure, in which hashes of lower level blocks (or at least counters used as part of authentication digest key) are themselves authenticated - by storing them in authenticated memory. This creates a multi-level structure, the top level of which will be a single digest authenticating the complete state of all encrypted memory in the system. If that digest is then stored inside the SoC, externally-initiated reply can no longer threaten the security model. Obviously, the latency cost and complexity gets worse, though.

As a side note, memory encryption, even in its simplest incarnation, has a surprising benefit. It practically eliminates electro-magnetic emissions from the memory system. In fact, scrambling schemes without cryptographic value have been included in multiple systems expressly for that purpose; but in context of security, getting rid of compromising emanations may well be worth the effort.

We hope that the security researchers that read our article will recognize these design patterns in systems they encounter; awareness of them means less time spent rediscovering the wheel. At the same time, we hope every hardware designer understands why physical memory security is a key element of a good security strategy, and takes the time to weigh its obvious costs against its numerous benefits; software is never as secure as we hope it would be, and sometimes your hardware is the last line of defense.

While developing our mobile hardware models, we've run into a large array of schemes aimed at improving physical memory security.

Mobile Physical Memory Security

Our latest release adds website improvements, an API update, bug fixes, and a new user profile page.

Responsive design enhancements to the front end

Updated response for the createUser() API call

Added modal reporting for user during error states

Enhanced stability for VMs during deployment

Fixed issue preventing Xcode DDI mount on iOS 15.4

Corellium version 3.9.0 contains updated Frida support as well as bug fixes and improvements to the user experience.

Updated Frida for Android to version 15.1.16

Improvements and bug fixes to the user interface

Fixed an issue causing the network monitor to crash

Improvements to query images uploaded to the project 

Fixed an issue with blocked navigation links in Firefox

Added support links to headers for device features, e.g. Connect, Files, Apps, Console

Support downloading files simultaneously from the device filesystem 

For this release we have added support for iOS 15.4 & 15.4.1.

The Corellium team is excited to announce the release of many user experience improvements, simulate receiving SMS to iOS, frames of various Android devices, Android 12 upgrade, as well as bug fixes. 

Device tools have been stacked vertically for easier navigation. 

"Peripherals" renamed to "Sensors” in device tools. 

Device selection has been updated to not require unselecting of current device. 

Simulate receiving an SMS message on the iOS virtual device.

11 Android device frames have been added. 

Upgraded AOSP 12 from beta 1 to revision 26.

Allow shell scripts to be used as the main executable of a process.

Fixed Cydia Installations in iOS 15.2 and later. 

On-Site: Bug fix when instance gateway is set to “default."

Broken links for Knowledge Base articles updated. 

In this latest release, we've added iOS 15.3 and iOS 15.3.1, STUN for WebRTC to allow for functional displays in strict firewall environments, improved snapshot functionality, added a start timestamp to the instance object on the Corellium-API, and other various bug fixes. 

STUN for WebRTC enabling displays on strict firewall environments.

Improvements for multiple snapshot creation.

Added start timestamp field to Corellium-API. Attribute is useful for knowing how long an instance has been in the current state.

Fixed bug on Android devices related to networking issues on a soft-restart.

Bug fix for Android Settings crash when launched.

We are excited to announce in this release that we've added Pop-Out Displays for Virtual Device Screens, and a bug fix for cloning Snapshots.

Pop-Out Display of Virtual Device Screens

This release provides iBoot for iPhone 12, improved API instructions for on-site customers, and bug fixes for custom kernel uploads & API internet access toggling.

Improved API instructions for on-site customers

Fixed a bug that prevented turning on internet via API in projects

Fixed a bug that stuck devices in deleting state when uploading custom kernels

In this release, we've added support for iPhone 13 and iOS peripherals, including Biometrics and Accelerometer. We also improved our error handling.

Support for toggling iOS biometrics to pass / not pass

Support for iOS sensors, including accelerometer / motion

Our latest release brings support for iOS 14.8 and iOS 15, as well as support for GPS on iOS device.

Reduced frequency of payment attempts for past due invoices

Current credit balance now displayed in the UI

Fixed an error in changing the IP Address for the on-site installer

Enables GPU acceleration for all Android devices on Enterprise accounts

This update adds support for iOS 14.7 and iOS 15. Since iOS 15 is still in beta, it's only supported for on-site customers.

Support for iOS 15 betas 1-4 (on-site only)

In this update, we're very excited to add support for Sensors and Camera for our virtual Android devices, as well as beta support for Android 12!

Note: Sensors and Camera may not be available or may behave differently on any pre-existing Android devices created prior to this update.

Added support for sensors for Android devices