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

Back in August, we announced the Corellium Open Security Initiative to support independent public research into the security and privacy of mobile apps and devices. 

To encourage this important research, we accepted proposals for research projects designed to validate any security and privacy claims for any mobile software vendor, whether in the operating system or third-party applications, with the winning proposal receiving a $5,000 grant and a year of free access to the Corellium platform.

Today, we're very excited to announce that the winner of the 2021 COSI Award is James Sebree, a Principal Research Engineer at Tenable. 

James's project will be aimed at validating Apple’s claims of secure transmission of data between apps and strong data protection mechanisms. In particular, the project will take a deep dive into how entitlements are verified, to evaluate the secure transfer of information between applications on iOS and investigate where access to user information is restricted without explicit permission from the user.

This research will help strengthen the overall security of the platform by identifying both the flaws and strengths of these mitigations, and confidently verifying places they work correctly. This research will also help lower the barrier to entry for others to examine these points of interaction by providing a detailed overview of how information is transferred between third-party apps and native iOS apps and daemons.

Congratulations James! We're excited to see what your research uncovers!

Today, we're very excited to announce that the winner of the 2021 COSI Award is James Sebree, a Principal Research Engineer at Tenable.

Announcing the 2021 COSI Award Winner

Today, in honor of Corellium’s fourth birthday, we’re announcing the Corellium Open Security Initiative. This initiative will support independent public research into the security and privacy of mobile applications and devices through a series of awards and access to the Corellium platform.

More than any other field of computing, security depends on the existence of a large, diverse, unofficial community of researchers. While advancements in areas like hardware design often emerge from well-funded private labs, the majority of progress in cybersecurity over the last several decades has come from “the security research community,” a community that includes not only credentialed academics and corporate professionals, but hackers, dropouts, and hobbyists too. 

Conducting third-party research on mobile devices remains difficult, inefficient, and expensive. Particularly in the iOS ecosystem, testing typically requires a jailbroken physical device. Jailbreaks rely on complex exploits, and they often aren’t reliable or available for the latest device models and OS versions. 

At Corellium, we recognize the critical role independent researchers play in promoting the security and privacy of mobile devices. That’s why we’re constantly looking for ways to make third-party research on mobile devices easier and more accessible, and that’s why we’re launching the Corellium Open Security Initiative. 

As an initial pilot for this program, we will be calling for proposals on a specific topic. Over time, we will evaluate adding more topics and more opportunities for awards. If you’re interested in sponsoring or partnering with us on this initiative, please reach out to us at securityinitiative@corellium.com. 

The security research community plays a pivotal role not only in identifying and defending against security threats, but also in holding software vendors accountable for the security and privacy claims they make about their products.

Just last week, Apple announced that it would begin scanning photos uploaded into Apple’s iCloud service for Child Sexual Abuse Material (CSAM). Setting aside debates on the civil and philosophical implications of this new feature, Apple has made several privacy and security claims about this new system. These claims cover topics as diverse as image hashing technology, modern cryptographic design, code analysis, and the internal mechanics and security design of iOS itself. Errors in any component of this overall design could be used to subvert the system as a whole, and consequently violate iPhone users’ privacy and security expectations. 

Since that initial announcement, Apple has encouraged the independent security research community to validate and verify its security claims. As Apple’s SVP of Software Engineering Craig Federighi stated in an interview with the Wall Street Journal, “Security researchers are constantly able to introspect what's happening in Apple's [phone] software, so if any changes were made that were to expand the scope of this in some way—in a way that we had committed to not doing—there's verifiability, they can spot that that's happening.” 

We applaud Apple’s commitment to holding itself accountable by third-party researchers. We believe our platform is uniquely capable of supporting researchers in that effort. Our “jailbroken” virtual devices do not make use of any exploits, and instead rely on our unique hypervisor technology. This allows us to provide rooted virtual devices for dynamic security analysis almost as soon as a new version of iOS is released. In addition, our platform provides tools and capabilities not readily available with physical devices.

We hope that other mobile software vendors will follow Apple’s example in promoting independent verification of security and privacy claims. To encourage this important research, for this initial pilot of our Security Initiative, we will be accepting proposals for research projects designed to validate any security and privacy claims for any mobile software vendor, whether in the operating system or third-party applications. 

In the initial pilot of the Corellium Open Security Initiative, we will be awarding up to three qualifying submissions a $5,000 grant, to be awarded upon acceptance of the proposal, and free access to the Corellium platform for one year. 

Having a track record of security research is helpful, but not required.

Any vulnerabilities discovered in the course of your research must be reported to the vendor. We encourage you to follow the disclosure guidelines of the relevant vendor.

You must provide us with regular updates about the progress of your research. If your proposal is accepted, we will coordinate with you to set a timeline for updates, depending on the length of your project.

You must submit a final report to us providing a detailed technical explanation of the project and its outcomes. This report will be featured on our blog as part of our commitment to open access to security and privacy research. It must be submitted no later than 30 days from the end of your project, or after any disclosure requirements are met. 

Any use of the Corellium platform is governed by our Terms of Service.

Awards will be granted at our sole discretion. We will review submissions based on the following criteria:

The likely impact of the proposed research on improving mobile security or privacy.

The novelty and feasibility of the proposed research.

The likelihood that the project will be completed successfully.

The technical merits of the proposed research.

Please email your proposal to securityinitiative@corellium.com by or before 5:00pm EST October 15, 2021. 

In your proposal, please include the following details:

Name: the name(s) of the researcher(s) that will be performing the research.

Organization (if applicable): your institutional affiliation, if any.

Project Description: a detailed description of the research you intend to perform.

Impact: a detailed description of why this research is important and the impact you expect it to have on improving mobile security or privacy.

Plan and Timeline: when you expect to start the research and how long you expect it to take.

How Corellium can Help: why you would benefit from using Corellium to perform your research.

Supplemental Information: any prior research or other details that might help us review your submission.

We will review and respond to all proposals by 5:00pm EST October 31, 2021. 

If you have further questions or suggestions, or are interested in supporting our mission to improve privacy and security through independent third-party research, please feel free to reach out to us at securityinitiative@corellium.com. 

Stuff the lawyers make us say: We can’t accept proposals from individuals who are on sanctions lists or from individuals in embargoed countries. You are responsible for any taxes on applicable awards, depending on your country of residency and citizenship. Additional restrictions may apply, depending on your local law. All awards are issued entirely at our sole discretion, and we can cancel the program at any time. Your research must not violate any law.

In honor of Corellium’s fourth birthday, we’re announcing the Corellium Open Security Initiative to support independent public research into the security and privacy of mobile applications and devices.

Corellium Open Security Initiative

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

We’re very excited to announce that virtual iOS-based devices are now available for individual accounts on our groundbreaking security research platform, CORSEC.

While we have previously supported virtual iPhone and iPad devices for Enterprise accounts, our Individual accounts only offered virtual Android devices. Now, both individuals and enterprises can virtualize both iOS and Android device models.

One of the questions we faced in introducing iOS-based device models to individual accounts was how to keep pricing straightforward. While our virtual Android devices use 2 CPU cores by default, iOS devices can require up to 6 CPU cores, depending on the model. As a result, we could no longer offer a single price per virtual device. Instead, individual subscriptions will now follow the same pricing structure as enterprise accounts, with prices per CPU core. Customers will see prices remain the same for individual subscriptions, but prices will now be listed per core rather than per device. 

With our monthly subscription model, you are allotted a certain number of CPU cores, and you can run as many virtual devices as that number of CPUs will permit at a time. For instance, if you have a 12-core account, you can spin up two virtual Phone 11’s for your first test run, then you could turn those off for storage and create six iPhone 7’s for the next test. For every two active CPU cores allotted to your account, you can store up to five devices in an Off state.

With our usage-based model, you can run as many virtual devices as you want at a time, and you will be charged a flat rate per core per hour. This means 6-core models will be more expensive to run per hour than 2-core models. Stored devices are charged per device (not per core), and they are charged per day rather than per hour.

One of the other considerations we faced in introducing iOS-based devices for individual accounts is continuing our efforts to limit the use of our software for malicious purposes. We have always vetted our customers, and we have not only declined sales, but also revoked customer accounts for violating our terms. In this regard, we wanted to ensure we would be able to use the same vetting process for individuals that we already use for enterprises. To that end, both individuals and enterprises will now be required to request an account, which will be subject to our internal vetting and approval process. Both individuals and enterprises will be required to provide a use case, and users will be asked to enter credit card information prior to accessing the free trial to assist in location and identity verification. 

We’re very excited to announce that virtual iOS-based devices are now available for individual accounts on our groundbreaking security research platform.

Announcing Support for iOS on Individual Cloud Accounts

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

Usage Based Billing

In this video, we're taking a look at the new usage-based subscription model for CORSEC, our advanced Security Research platform. 

In today's agile work environment, it's critical to not only service your internal teams and customers at a moment's notice, but also to remain conscious of company financials. Security teams must perform a wide range of testing across various models and OS versions to ensure their product is ready to meet the real-world security needs of end users. Historically, this has required a substantial investment in purchasing physical test devices, and even with that upfront cost, a particular device may not always be available when a team member needs it.

However, with Corellium's usage-based billing model, you can spin up the device you need right when you need it, and only be charged for the time you use. This enables your team to flexibly adapt your resource demands on demand, while still maintaining the accuracy and convenience of testing on real Arm hardware.

In this video, you'll see that we have 4 virtual devices -- 3 of which are On, and 1 of which is Stored. When we go to manage our subscription, we can quickly check the usage rates and charges for the various devices we've created. 

Active devices, or devices that are in the "On" state, cost just $0.25/hour/core. Most devices use two cores, for a total of $0.50/hour per device -- compared to other companies that may charge up to $.05/min ($3/hour) and don't even run on Arm. Some newer iOS models require six cores, for a total of $1.50/hour per device. Each core is a dedicated core, not a virtual core, so you get full, fast performance.

You can also turn devices off and keep them in a Stored state for just $0.25/day. When you’re ready to run more tests on that configuration, it's as simple as turning the device back on.

Ready to try a usage-based subscription? Click here to get started!

A quick demo of our usage-based subscription option.

Usage-Based Billing

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),

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