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

In an effort, we believe, to stifle innovation and the freedom of mobile developers, Apple has filed a complaint against Corellium, claiming our company infringed on its copyrighted works. This comes as a surprise to our team, given our long-standing relationship with Apple. Apple has been aware of our ground-breaking technology since the company was founded, and at any point in the past two years, Apple could have notified us of their concerns. We think Apple’s lawsuit is driven by its own business interests rather than a genuine belief that we violated any of its rights.

As a leader in the advancement of cybersecurity solutions, we’re especially disappointed that Apple is choosing to sue us rather than embrace our efforts, given their challenges in this space.

We founded Corellium to equip the mobile community with the scalable, efficient, and innovative tools they need to push the mobile ecosystem forward. By combining the fidelity of native architecture with the advantages of a virtual resource, our pioneering platform empowers security experts, software developers, and mobile testers to do their work better than they ever could before – whether that’s testing an app, conducting a training, or working for our national defense.

We’re proud of the transformative technology we’ve developed and the product we provide our peers in the mobile engineering community, and we appreciate their strong showing of support. We’re proud of the work our customers are doing to deliver a better, safer experience to end users. That’s why we are prepared to strongly defend our ability to continue to provide this important, revolutionary technology, and to continue to enable our customers to do amazing work.

We are changing the way mobile development is done. We are pushing technology to the next level. This should be celebrated, not shut down.

Link to Corellium’s Response to Apple’s Claims

Liz Bradford
lbradford@bradfordpr.com
214-612-8014

In an effort, we believe, to stifle innovation and the freedom of mobile developers, Apple has filed a complaint against Corellium, claiming our company infringed on its copyrighted works.

A statement from Amanda Gorton, CEO of Corellium, regarding Apple lawsuit

In October, Corellium presented an interactive workshop at the Arm DevSummit called “App Unknown: An Introduction to Rapid Security Analysis on Arm.” Spots for the workshop filled up in a matter of hours, so we wanted to share some highlights and resources here for those who weren’t able to attend!

Click here to download the workshop slides.

The workshop was designed to introduce the audience to essential tools and methods for quickly assessing an unknown application for potential security threats. Someone sends you an app you don’t recognize — how can you get an idea if it’s doing something bad?

Virtual devices like Corellium’s offer an ideal place to test unknown apps. You don’t have to worry about contaminating a physical test device with malware, and you can simply delete the virtual device when you’re done testing. Our devices also offer unique built-in tools that give you greater control over the device environment and a ready-made setup for rapid analysis. Plus, Corellium’s devices run on Arm, giving you a realistic platform for testing without the hassle of recompiling.

One of the first things you might want to inspect in an unknown app is network traffic. This can give you an idea if the app is sending traffic to a nefarious source. There are a number of ways you might approach this:

Corellium’s built-in Network Monitor tool makes it easy to inspect HTTP and HTTPS network traffic on your virtual device. Network Monitor leverages sslsplit to capture and present HTTP and HTTPS network traffic, transparently defeating certificate pinning. For any captured packet, you can drill in to view more information, the request, and the response.

Another key approach to assessing an unknown app is system call tracing, or intercepting and recording the system calls that are called and received by a process. This approach enables you to drill down into precisely what an application is doing and how it’s interacting with the surrounding system. It’s an invaluable dynamic analysis technique when source is not readily available.

Traditionally, to perform this type of tracing, you would use strace, a Linux diagnostic utility that can be used to monitor interactions between processes and the Linux kernel. The strace utility relies on a kernel feature known as ptrace. This makes it susceptible to anti-ptrace techniques. 

Corellium’s CoreTrace tool provides even more sophisticated tracing. EL2 patches the kernel system call entry to trap into the hypervisor, so it can record the system call and its arguments. Because it’s implemented at the hypervisor level, it avoids anti-ptrace techniques and cannot be easily detected by applications. CoreTrace can also trace the entire system at once — it isn’t limited to a single process. 

If you happen to be up against a kernel vulnerability, one powerful tool at your disposal is to run the app with KASAN, Kernel Address Sanitizer. KASAN is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs, and it works by checking whether all memory accesses are valid with compiler instrumentation. 

KASAN is appropriate to use in virtual environments like Corellium or QEMU. It can also be used on commercial products with unlocked bootloaders, or by SOC or OEM vendors. To try this in a Corellium virtual environment, upload a custom kernel to a Corellium device and check for KASAN output in the Corellium console. 

The final method we reviewed in our workshop for assessing an unknown app is kernel debugging. Kernel debugging provides unparalleled introspection, but it can be difficult to set up, and it requires an understanding of Linux or XNU kernel internals. Often, it’s easier to reach for SystemTap first. 

Corellium devices make kernel debugging much more convenient by injecting a gdb stub into the device kernel’s memory. If you’re interested in exploring kernel debugging with a virtual Corellium device, check out our resources on kernel debugging or building custom kernels.

In October, Corellium presented an interactive workshop at the Arm DevSummit called “App Unknown: An Introduction to Rapid Security Analysis on Arm.”

Corellium Workshop at Arm DevSummit 2020

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

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

Apple’s latest filing against Corellium should give all security researchers, app developers, and jailbreakers reason to be concerned. The filing asserts that because Corellium “allows users to jailbreak” and “gave one or more Persons access… to develop software that can be used to jailbreak,” Corellium is “engaging in trafficking” in violation of the DMCA. In other words, Apple is asserting that anyone who provides a tool that allows other people to jailbreak, and anyone who assists in creating such a tool, is violating the DMCA. Apple underscores this position by calling the unc0ver jailbreak tool “unlawful” and stating that it is “designed to circumvent [the] same technological measures” as Corellium.

Apple is using this case as a trial balloon in a new angle to crack down on jailbreaking. Apple has made it clear that it does not intend to limit this attack to Corellium: it is seeking to set a precedent to eliminate public jailbreaks.

We are deeply disappointed by Apple’s persistent demonization of jailbreaking. Across the industry, developers and researchers rely on jailbreaks to test the security of both their own apps and third-party apps – testing which cannot be done without a jailbroken device. For example, a recent analysis of the ToTok app revealed that an Apple-approved chat app was being used as a spying tool by the government of the United Arab Emirates, and according to the researchers behind this analysis, this work would not have been possible without a jailbreak.

Not only do researchers and developers rely on jailbreaking to protect end users, but Apple itself has directly benefited from the jailbreak community in a number of ways. Many of the features of iOS originally appeared as jailbreak tweaks and were copied by Apple, including dark mode, control center, and context menus. In addition, jailbreak creators regularly contribute to the security of iOS. The developer behind the unc0ver jailbreak was acknowledged and credited by Apple for assisting with a security vulnerability in the iOS kernel – a vulnerability he discovered while using Corellium.

We are prepared to strongly defend against this attack, and we look forward to sharing our formal response to this claim when we file it in court. Until then, we appreciate the outpouring of support from the mobile community that is as concerned as we are by the far-reaching implications of this new filing.

Apple’s latest filing against Corellium should give all security researchers, app developers, and jailbreakers reason to be concerned.

A statement from Amanda Gorton, CEO of Corellium, regarding Apple DMCA filing

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

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

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

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

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.

Amanda Gorton