Corellium supports mobile security research on iOS 16

Announcement: Corellium Supports iOS 16 Mobile Security Research

We provide the mobile security research community with the tools they need to test iOS – without jailbreaks. Now, Corellium Virtual Hardware platform supports iOS 16.

Corellium Support for iOS 16

<p>At Corellium, we’re committed to providing the mobile security research and app developer communities the ability to comprehensively test and analyze Apple’s mobile operating systems without having to jailbreak physical devices<em>.</em> To that end, we’re very proud to announce that our Corellium Virtual Hardware platform now supports iOS 16, including fully jailbroken iOS 16.</p>

<p>&nbsp;</p>
<p>Jailbreaks are essential to iOS security work. Without jailbreaks, white-hat researchers wouldn’t be able to dynamically analyze mobile apps or discover security flaws in walled-off areas of the operating system. Researchers have relied on jailbreaks for significant, groundbreaking discoveries ranging from <a href="https://www.amnesty.org/en/latest/research/2021/07/forensic-methodology-report-how-to-catch-nso-groups-pegasus/"><span>analyzing the Pegasus malware</span></a> to dissecting the <a href="https://twitter.com/patrickwardle/status/1210742545451323392"><span>UAE-spy app ToTok</span></a> to uncovering how malware may be loaded onto an iPhone’s Bluetooth chip <a href="https://arxiv.org/pdf/2205.06114.pdf"><span>even when the device is off</span></a>. Most of the bugs reported to Apple’s Bug Bounty program wouldn’t have been discovered without a jailbreak, and you would be hard-pressed to find a mobile pen-testing team that doesn’t have a pile of jailbroken iPhones for application analysis.</p>
<p>&nbsp;</p>
<p>Counterintuitively, while jailbreaks are essential for security research, achieving a jailbreak on a physical iOS device fundamentally requires the exploitation of security vulnerabilities. The purpose of jailbreaking is to enable users to do things that aren’t ordinarily permitted by the operating system – namely, to run their own code and to access lower levels of the system. Since iOS is not designed to enable this access by default, a user must find and leverage security flaws in the operating system to change the way it behaves. Typically, this is achieved by “patching” the iOS kernel.</p>
<p>&nbsp;</p>
<p>Put another way: to find bugs in iOS, the security community has to exploit bugs in iOS. This creates an uncomfortable incentive for researchers to withhold known bugs from Apple, in order to maintain their ability to do their work.&nbsp;</p>
<p>&nbsp;</p>
<p>Corellium’s approach is inherently different: it doesn’t rely on vulnerabilities at all. Instead, because the operating system is running in a virtualized environment, the OS can simply be configured to run with escalated privileges by default – the “patches” can simply be applied at the outset. Corellium’s virtual devices behave and function the same way a physical jailbroken device would, and they even come pre-loaded with common jailbreak tools like Cydia. In this way, Corellium is not only able to provide the security research community with immediate support for a jailbroken version of the latest OS, but it can do so without having to withhold any security vulnerabilities from Apple.&nbsp;</p>
<h2>Public jailbreaks are increasingly rare</h2>
<p>Apple invests considerable effort in continually improving the security of its operating system. As it hardens iOS with each new release, public jailbreaks are becoming more and more rare. Nearly a year after the release of iOS 15, a public jailbreak for this version has yet to be made available.&nbsp;</p>
<p>The reason for this is simple: it’s getting harder and harder to find bugs that can be used for a jailbreak. It used to be that a fully untethered jailbreak required just one or two vulnerabilities to achieve privilege escalation. Now, jailbreaks require a complex chain of exploits, and even then, they often don’t provide the same degree of access or persistence. From this perspective, Apple’s efforts to improve the security of iOS over time have arguably succeeded.</p>
<p>But this success has created something of a catch-22. As our CTO Chris Wade describes:&nbsp;</p>
<blockquote>
<p>The more Apple locks down their operating system to improve end user security, the harder it becomes for the independent security research community to investigate and identify security vulnerabilities, both in the operating system itself and in the apps that run on it. That doesn’t mean vulnerabilities aren’t still there; it just makes it harder for the community to help find them before bad actors do. And the harder they are to find, the more valuable they are, so the more incentive researchers have to hold them instead of report them, and the more incentive bad actors have to go looking for them.</p>
</blockquote>
<p>Indeed, as jailbreaks become harder to implement, they become increasingly valuable. This drives researchers, governments, and security companies to create their own private jailbreaks and hoard the bugs that enable them to protect their advantage for future security work.</p>
<h2>&nbsp;</h2>
<h2>iOS 16 features focus on narrowing attack surfaces</h2>
<p>iOS 16 includes two notable new features aimed at limiting attack vectors. One is called “Lockdown Mode,” which focuses on protecting a small but highly vulnerable set of users, such as activists and journalists. <span style="color: #041427;">Lockdown Mode strictly limits or disables certain ‌iPhone‌ features, as well as access </span><span style="color: #041427;">to</span><span style="color: #041427;"> certain apps and websites.</span></p>
<p><span style="color: #041427;">Interestingly, the specific features of Lockdown Mode suggest that, in Apple’s assessment, the most common attack vectors on an iPhone today are malicious websites, infected iMessages or FaceTime videos, MDM profiles, and wired connections to the phone. </span>Notably, Lockdown Mode does not seem to impact a user’s access to third-party app store apps. As Apple increasingly limits the attack surface for native features, the attack focus may shift to apps from the App Store – particularly given the <a href="https://www.washingtonpost.com/technology/2021/06/06/apple-app-store-scams-fraud/"><span>limited review</span></a> these apps undergo.</p>
<p>Another new feature, “Developer Mode,” aims to protect people from “inadvertently installing potentially harmful software on their devices” and to “reduce attack vectors exposed by developer-only functionality,” <a href="https://developer.apple.com/documentation/xcode/enabling-developer-mode-on-a-device"><span>according to Apple</span></a>. As a byproduct, this feature also introduces additional friction to installing and running third-party code, including apps from alternative app stores. Apple is of course facing intense regulatory scrutiny over its monopoly of app distribution, and this wouldn’t be the first time it used security as a pretext for preserving control of the iOS ecosystem.</p>
<p>The addition of Lockdown Mode and Developer Mode in iOS 16 highlights an evolving and heightened focus on the security of iOS. High-profile stories – about malware like Pegasus or about a critical FaceTime bug discovered by a highschooler – have put increasing pressure on Apple to address even obscure attack vectors that are unlikely to affect an ordinary user.&nbsp;</p>
<p>This has resulted in a new iOS version that, for the first time, acknowledges and addresses the different threat profiles faced by different audiences, demonstrating an increasingly sophisticated and nuanced approach by Apple to user security. At the same time, this new iOS version continues the trend of tighter security controls, which will likely also mean a continuation of the trend of not seeing a public jailbreak for this new version anytime soon – if ever.&nbsp;</p>
<p>This is why we believe it’s as important as ever for Corellium to provide a place for white-hat developers to perform good-faith security research in a way that’s not possible on physical devices – a way that doesn’t require exploiting, withholding and retaining vulnerabilities. And given our platform’s widespread adoption by the world’s top security research and development teams, it seems the community would agree.</p>
<p>For more information about our latest code release, check out <a href="https://www.corellium.com/updates"><span>https://www.corellium.com/updates</span></a>.&nbsp;</p>

<p>At Corellium, we’re committed to providing the mobile security research and app developer communities the ability to comprehensively test and analyze Apple’s mobile operating systems without having to jailbreak physical devices<em>.</em> To that end, we’re very proud to announce that our Corellium Virtual Hardware platform now supports iOS 16, including fully jailbroken iOS 16.</p>


text

Attack Surface Mapping with Corellium: iOS Persistence

Attack surface mapping of files opened by processes is a useful tactic to thwart attacker persistence. Learn how to use Corellium for this strategy.

Mapping iOS Persistence Attack Surface using Corellium

<p style="font-size: 18px;"><span style="background-color: #ffffff;"><span style="background-color: #ffffff;">Persistence is a </span><a href="https://attack.mitre.org/tactics/TA0003/" style="background-color: #ffffff;" rel="noopener" target="_blank">tactic</a><span style="background-color: #ffffff;"> used by attackers and jailbreakers</span><span style="background-color: #ffffff;"><sup>1</sup></span><span style="background-color: #ffffff;"> to maintain a foothold on a device after reboot, and can be a <a href="https://zerodium.com/program.html" rel="noopener" target="_blank">valuable</a></span><span style="background-color: #ffffff;">&nbsp;component of an exploit chain. Fundamentally, this requires attacker-controlled data to be processed at some point in the course of booting, so creating a mapping of files opened by various processes should provide a useful first approximation of the </span><span style="background-color: #ffffff;">cyber attack surface</span><span style="background-color: #ffffff;">.</span></span></p>


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

Resources and insights

Amanda Gorton

Media Room

Announcing iOS Device Virtualization for Individual Cloud Accounts

We’re very excited to announce that iOS device virtualization is now available for individual accounts on our groundbreaking security research platform.

Announcing Support for iOS on Individual Cloud Accounts

<p><span>We’re very excited to announce that <span style="font-weight: bold;">iOS device virtualization is now available for individual accounts</span></span><span>&nbsp;</span>on our groundbreaking <a href="https://www.corellium.com/platform" rel="noopener">security research platform</a>, CORSEC.</p>

<p>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.</p>
<h2>iOS Device Virtualization Pricing</h2>
<p>One of the questions we faced in introducing iOS-based device models to individual accounts was how to keep pricing straightforward. While our <a href="https://www.corellium.com/devices/android" rel="noopener">virtual Android devices</a> 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 <a href="https://www.corellium.com/pricing" rel="noopener">pricing structure</a> as enterprise accounts, with prices per CPU core. Customers will see prices remain the same for individual subscriptions, but<span>&nbsp;</span><strong>prices will now be listed per core rather than per device</strong>.</p>
<h3>Monthly Subscription Model</h3>
<p>With our<span>&nbsp;</span><strong>monthly subscription model</strong>, 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.</p>
<h3>Usage-Based Model</h3>
<p>With our<span>&nbsp;</span><strong>usage-based model</strong>, 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<span>&nbsp;</span><em>per device</em><span>&nbsp;</span>(not per core), and they are charged<span>&nbsp;</span><em>per day</em><span>&nbsp;</span>rather than per hour.</p>
<h2>iOS Device Virtualization Account Verification</h2>
<p>One of the other considerations we faced in introducing <a href="https://www.corellium.com/devices/ios" rel="noopener">iOS-based devices</a> 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<span>&nbsp;</span><strong>request an account</strong>, 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.</p>

<p><span>We’re very excited to announce that <span style="font-weight: bold;">iOS device virtualization is now available for individual accounts</span></span><span>&nbsp;</span>on our groundbreaking <a href="https://www.corellium.com/platform" rel="noopener">security research platform</a>, CORSEC.</p>


Technical Writeups

Firefox browser's details window inside Linux operating system

How We Ported Linux to the M1

Discover Corellium’s approach to porting Linux on M1. The included tutorial also explains how to boot Linux on your M1 (Mac Mini/Pro/Air) with our Ubuntu POC.

<h2 id="1-apple-special-sauce-the-m1-processor">1. Apple Special Sauce: The M1 Processor</h2>
<p>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.</p>

<p>At <a href="https://www.corellium.com/" rel="noopener">Corellium</a>, 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.</p>
<p>It also made Apple silicon rather distinct from all other 64-bit Arm hardware in terms of both CPU core and peripherals. Our Corellium <a href="https://www.corellium.com/" rel="noopener">virtualization platform</a> 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<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://projectsandcastle.org/">Sandcastle project</a>, where we built a kernel port to the A10 processor in early 2020.</p>
<p>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 <a href="https://www.corellium.com/solutions/security-research" rel="noopener">security research product</a>, we were working on the Linux port in parallel.</p>
<h2 id="2-starting-the-port-for-linux-on-m1">2. Starting the port for Linux on M1</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <a href="https://www.corellium.com/solutions/mobile-security-research" rel="noopener">security research product</a> has prepared us for this.</p>
<p>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.</p>
<h2 id="3-need-input-connecting-the-usb-port">3. Need Input! Connecting the USB Port</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://corellium.com/blog/mobile-physical-memory-security">blog post on IOMMUs</a><span>&nbsp;</span>and other similar devices last month.)</p>
<p>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.</p>
<p>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.</p>
<p>&nbsp;</p>
<h2 id="tutorial-for-usb-boot-works-on-mac-miniproair">Tutorial for USB Boot (Works on Mac Mini/Pro/Air)</h2>
<h3 id="1-download-the-ubuntu-rootfs">1. Download the Ubuntu rootfs</h3>
<p>The first step to booting Linux on your Mac M1 is to download the Ubuntu POC rootfs<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://assets.checkra.in/downloads/corellium/e4beb88251d7adf927e1a0db33677bf3b4b8ec6bfff4f971e38fb9d2767cbd69/ubuntu-20.10-preinstalled-desktop-arm64+raspi.img.bz2">available here</a>. 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.</p>
<h3 id="2-extract-the-image">2. Extract the image</h3>
<p>You will need a minimum 16G external USB drive. Extract the image by typing:</p>
<p><em>tar -xjvf ubuntu-20.10-preinstalled-desktop-arm64+raspi.img.bz2</em></p>
<p>Then, use disk utility to locate the name of the external disk. Finally, copy the image to the USB drive using:</p>
<p><em>sudo dd if=ubuntu-20.10-preinstalled-desktop-arm64+raspi.img of=/dev/rYOURUSBDISK bs=1m</em></p>
<p>Once you complete the dd, you will need to copy the WiFi firmware across to the exfat partition. You can do that by typing:</p>
<p><em>cp -RLav /usr/share/firmware/wifi /Volumes/system-boot</em></p>
<h3 id="3-connect-to-the-mac">3. Connect to the Mac</h3>
<p>Connect your USB drive to the Mac M1 using a dongle via the USB C port. The USB A ports are not currently supported.</p>
<h3 id="4-boot-into-1tr">4. Boot into 1TR</h3>
<p>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.</p>
<h3 id="5-install-the-custom-kernel">5. Install the Custom Kernel</h3>
<p>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:</p>
<p><em>bash -c "$(curl -fsSL<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://downloads.corellium.info/linuxsetup.sh">https://downloads.corellium.info/linuxusbboot.sh</a>)"</em></p>
<p>The script will prompt you for your username and password. One you see it print "Kernel installed" it's safe to type&nbsp;<em>reboot</em>.</p>
<h3 id="6-login">6. Login</h3>
<p>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."</p>
<h3 id="7-reverting-to-macos">7. Reverting to MacOS</h3>
<p>To revert to booting MacOS, in 1TR open terminal and type<span>&nbsp;</span><em>bputil -n</em></p>
<p>------</p>
<h2 id="tutorial-for-nvme-boot-works-on-mac-miniproair">Tutorial for NVME Boot ( Works on Mac Mini/Pro/Air )</h2>
<h3 id="1-download-the-ubuntu-rootfs">1. Download the Ubuntu rootfs</h3>
<p>The first step to booting Linux on your Mac M1 is to download the Ubuntu POC rootfs<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://assets.checkra.in/downloads/corellium/2131d1ef577986a2fe3b3f187ba0a58d7835d690a6555bb4beba33e248322fae/ubuntu-20.10-preinstalled-desktop-arm64+raspi-nvme.img.tar.bz2">available here</a>. 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.</p>
<h3 id="2-create-partition-and-flash-image">2. Create Partition and Flash Image</h3>
<p><strong>Warning! Don't attempt this step if you aren't sure what you're doing. If done incorrectly, this can harm your device.</strong></p>
<p>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:</p>
<p><em>tar -xjvf ubuntu-20.10-preinstalled-desktop-arm64+raspi-nvme.img.tar.bz2</em></p>
<p>Then dd to the specific partition you created.</p>
<p><em>sudo dd if=ubuntu-20.10-preinstalled-desktop-arm64+raspi-nvme.img of=/dev/rYOURDISK&nbsp;bs=1m</em></p>
<p>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&nbsp;typing:</p>
<p><em>cp -RLav /usr/share/firmware/wifi /Volumes/EFIESP</em></p>
<h3 id="3-boot-into-1tr">3. Boot into 1TR</h3>
<p>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.</p>
<h3 id="4-install-the-custom-kernel">4. Install the Custom Kernel</h3>
<p>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:</p>
<p><em>bash -c "$(curl -fsSL<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://downloads.corellium.info/linuxnvmeboot.sh">https://downloads.corellium.info/linuxnvmeboot.sh</a>)"</em></p>
<p>The script will prompt you for your username and password. One you see it print "Kernel installed" it's safe to type&nbsp;<em>reboot</em>.</p>
<h3 id="5-login">5. Login</h3>
<p>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."</p>
<h3 id="6-reverting-to-macos">6. Reverting to MacOS</h3>
<p>To revert to booting MacOS, in 1TR open terminal and type<span>&nbsp;</span><em>bputil -n</em></p>
<p>------</p>
<p><em>If you're interested in supporting our work on open source projects like these, please consider<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://supporters.eff.org/donate/join-eff-4">donating on our behalf to the EFF</a>, 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<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://asahilinux.org/">Asahi Linux</a>.</em></p>
<p><em>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!</em></p>
&nbsp;

<h2 id="1-apple-special-sauce-the-m1-processor">1. Apple Special Sauce: The M1 Processor</h2>
<p>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.</p>


Demo

Corellium platform Account Billing details section

Usage-Based Billing

A quick demo of our usage-based subscription option.

<p>&nbsp;</p>
<div class="hs-embed-wrapper" data-service="vimeo" data-responsive="true" style="position: relative; overflow: hidden; width: 100%; height: auto; padding: 0; max-width: 426px; max-height: 240px; min-width: 256px; display: block; margin: auto;"><div class="hs-embed-content-wrapper"><div style="position: relative; overflow: hidden; max-width: 100%; padding-bottom: 56.34%; margin: 0px;"><iframe src="https://player.vimeo.com/video/502263077?h=48455b12c7&amp;app_id=122963" width="1280" height="720" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen="" title="Usage Based Billing" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; border: none;"></iframe></div></div></div>
<p>In this video, we're taking a look at the new usage-based subscription model for CORSEC, our advanced Security Research platform.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Active devices, or devices that are in the "On" state, cost just<span>&nbsp;</span><strong>$0.25/hour/core</strong>. 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.</p>
<p>You can also turn devices off and keep them in a Stored state for just<span>&nbsp;</span><strong>$0.25/day</strong>. When you’re ready to run more tests on that configuration, it's as simple as turning the device back on.</p>
<p>Ready to try a usage-based subscription?<span>&nbsp;</span><a target="_blank" rel="noopener noreferrer" href="https://signup.corellium.com/">Click here to get started!</a></p>

diagram of memory layers from Requester to Target

Hardware Design Patterns for Better Physical Memory Security | Diagrams

Physical memory security is a key, but often overlooked, element of mobile hardware security.  Recognizing design patterns greatly benefits mobile security researchers.

Mobile Physical Memory Security

<h2 data-pm-context="[]">Physical Memory Security vs. Virtual Memory Security</h2>
<p>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.</p>


Workshops

Arm dev summit, October 6-8, 2020 Virtual Conference

Corellium Workshop at Arm DevSummit 2020

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

<div>
<div><span style="color: #363c49; font-family: Inter, system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'Noto Sans', 'Liberation Sans', sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; font-size: 1.125rem; background-color: transparent;">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!</span></div>
</div>
<div>
<p><a target="_blank" rel="noopener noreferrer" href="https://armwork.shop/slides.pdf">Click here to download the workshop slides.</a></p>
<p data-pm-context="[]">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?</p>
<p>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.</p>
<h2>Network Capture&nbsp;</h2>
<p>One of the first things you might want to inspect in an unknown app is <strong>network traffic</strong>. 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:</p>
<ol>
<li>
<p><strong>tcpdump</strong></p>
</li>
<li>
<p><strong>mitmproxy</strong></p>
</li>
<li>
<p><strong>Certificate Pinning</strong></p>
</li>
<li>
<p><strong>Frida</strong></p>
</li>
</ol>
<p>Corellium’s built-in Network Monitor tool makes it easy to inspect HTTP and HTTPS network traffic on your virtual device. Network Monitor leverages <em>sslsplit</em> 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.</p>
<h2>System Call Tracing</h2>
<p>Another key approach to assessing an unknown app is <strong>system call tracing</strong>, 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.</p>
<p>Traditionally, to perform this type of tracing, you would use <em>strace</em>, a Linux diagnostic utility that can be used to monitor interactions between processes and the Linux kernel. The <em>strace</em> utility relies on a kernel feature known as <em>ptrace</em>. This makes it susceptible to anti-ptrace techniques.&nbsp;</p>
<p>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 <em>entire </em>system at once — it isn’t limited to a single process.&nbsp;</p>
<h2>KASAN</h2>
<p>If you happen to be up against a kernel vulnerability, one powerful tool at your disposal is to run the app with <strong>KASAN</strong>, 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.&nbsp;</p>
<p>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.&nbsp;</p>
<h2>Kernel Debugging</h2>
<p>The final method we reviewed in our workshop for assessing an unknown app is <strong>kernel debugging</strong>. 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 <a url="https://sourceware.org/systemtap/" target="_blank" data-span="hyperlink">SystemTap</a> first.&nbsp;</p>
<p>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 <a docid="YeS8ZREAACAAl07L" previewimage="https://images.prismic.io/corellium-ambassador/a5fb5120-c079-4b22-a93c-1c2e19a217f0_Screen_Shot_2018-07-03_at_11.48.40.png?auto=compress,format&amp;w=900" previewtitle="How to Debug the Kernel" wiourl="wio://documents/YeS8ZREAACAAl07L" data-span="hyperlink">kernel debugging</a> or <a docid="Yeu2fhEAACAAtnln" previewtitle="Building a Custom Kernel for Android 9 / 10" wiourl="wio://documents/Yeu2fhEAACAAtnln" data-span="hyperlink">building custom kernels</a>.</p>
<p>&nbsp;</p>
</div>

<div>
<div><span style="color: #363c49; font-family: Inter, system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'Noto Sans', 'Liberation Sans', sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; font-size: 1.125rem; background-color: transparent;">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!</span></div>
</div>


Offered exclusively to customers with on-premises deployments, 3.13.2 provides iOS 16 support, improvements to the device boot process, and performance improvements.

Increased disk space of the misc partition for supplemental application data

User interface enhancements, including improved user alerts

Added nodevmode boot option to the REST API

Known Issues: Please note using Frida with iOS 16 may lead to a kernel panic.

With the 3.13.1 release, we announce iOS 16 support for cloud customers as well as improvements to the device boot process.

The 3.13 release includes preparation for iOS 16 support, design enhancements to the user interface, and performance improvements.

Corellium introduces support for iOS 16 Beta 5. This release is available as a beta exclusively to customers with on-premises deployments.

Limited support for iOS 16 Beta 4 and Beta 5. Please note we are addressing known bugs related to certain features. If you experience critical issues, please consider rolling back to a previous version or contacting support.

General performance improvements, front-end enhancements, and minor bug fixes.

Corellium unveils various new changes to the user interface and user experience with version 3.12.1.

Simplified trial signup process adds address autofill and removes the billing requirement

Accessibility and usability changes, including keyboard support on modal windows

Improvements to navigation, alerts, and typography of our web interface

Moved the OpenGApps installer to the Apps page on Android devices

Deeper Intercom chat integration into the customer experience

Reliability and error handling improvements

Corellium is excited to add support for the new iOS 16. This new release is available as a beta exclusively to customers with on-premises deployments.

Limited support for iOS 16 Beta 3. Please note we are addressing known bugs related to certain features. If you experience any critical issues, please consider rolling back to a previous version or contacting support.

Various reliability improvements and bug fixes.

This release adds Quick Connect SSH tunneling, a Rotate button for iOS, XPC support for CoreTrace on iOS, and OpenGApps for Android 12.

New Quick Connect feature enables SSH without a VPN connection

Add a Rotate button to enable landscape mode on iOS devices

Add an XPC trace to CoreTrace for iOS devices 

Add OpenGApps support for Android 12 devices

Various fixes and improvements to the user interface

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

Responsive design enhancements to the front end

Updated response for the createUser() API call

Added modal reporting for user during error states

Enhanced stability for VMs during deployment

Fixed issue preventing Xcode DDI mount on iOS 15.4

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

Updated Frida for Android to version 15.1.16

Improvements and bug fixes to the user interface

Fixed an issue causing the network monitor to crash

Improvements to query images uploaded to the project 

Fixed an issue with blocked navigation links in Firefox

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

Support downloading files simultaneously from the device filesystem 

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

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

Device tools have been stacked vertically for easier navigation. 

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

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

Simulate receiving an SMS message on the iOS virtual device.

11 Android device frames have been added. 

Upgraded AOSP 12 from beta 1 to revision 26.

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

Fixed Cydia Installations in iOS 15.2 and later. 

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

Broken links for Knowledge Base articles updated. 

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

STUN for WebRTC enabling displays on strict firewall environments.

Improvements for multiple snapshot creation.

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

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

Bug fix for Android Settings crash when launched.

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

Pop-Out Display of Virtual Device Screens

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

Improved API instructions for on-site customers

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

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

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

Support for toggling iOS biometrics to pass / not pass

Support for iOS sensors, including accelerometer / motion

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

Reduced frequency of payment attempts for past due invoices

Current credit balance now displayed in the UI

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

Enables GPU acceleration for all Android devices on Enterprise accounts

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

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

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

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

Added support for sensors for Android devices

Added support for camera pass-through for Android devices

Implemented an API for shell access (ShellExec)

Fixed a bug that allowed improperly formatted UDIDs to be applied

Fixed a bug that caused the CoreTrace thread & process list not to populate for iPhone 12 iOS 14.6

Added the ability to export a pcap of the log from the Network Monitor tool

Fixed a bug that caused some apps to timeout on launch on iOS 14.5.1 with PAC enabled

(For on-site customers, Release 2.9.1 incorporates Release 2.9)

Improve the load time of images in the Create Device modal

Increase trial time from one hour to six hours

Fix a Frida-related panic on iOS 14.5+ and enable integrated Frida tab on 14.5+

Disable certificate pinning by default for applications on jailbroken iOS devices

Automatically connect to the device display 

Improves CoreTrace reporting on XNU and Linux

Increases minimum password length for accounts

Adds support for multiple connections to a project or instance via the same openvpn client configuration

This cloud-only release provides support for variable screen sizes in the API, as well as minor bug fixes.

Support for variable screen sizes in the API

Support for toggling GPU acceleration per domain

Fixed a bug that caused Network Monitor to be displayed for non-jailbroken no-agent devices

Fixed an issue with the API that allowed users to create projects without a name

Fixed an issue that prevented re-subscribing after canceling a usage-based account

Fixed a bug that caused Enterprise Team Leads to see an option to invite users and manage teams when this functionality was not available at this permission level

This release provides support for 14.5 betas and Network Monitor for iOS.

Added support for Network Monitor for iOS-based device models

Fixed a bug that could cause errors in upgrading on-site installations

Fixed backwards compatibility with iOS 14.0 betas

This release provides on-site customers with the new ability to load their own models to the hypervisor. It also adds support for copying and pasting data to iOS-based device models. 

Added support for loadable firmware models for on-site users

Added Copy/Paste for iOS devices. Note that for both Android and iOS-based device models, copy/paste behavior is inconsistent across different web browsers. In particular, data is unable to be pasted into a VM in the Firefox browser, and data is unable to be copied out of a VM in the Safari browser. 

Fixed a bug in switching from monthly to usage-based subscriptions

Fixed a bug that prevents resubscribing after cancelling a usage-based account

Fixed a bug that could cause snapshots to becoming stuck in a Restoring state

Fixed a bug causing incompatibility between A14 iPhone device models and Xcode

Fixed a bug that caused graphical glitches in apps that use WKWebview

Implemented missing ACM protocol extensions and messages for iOS-based device models

This update provides support for iOS 14.4 and adds Frida support for iOS-based devices.

Added support for Frida console for iOS devices

Fixed an intermittent bug causing A14-based models to freeze during restore in Graviton environments

Fixed an error causing IPSWs to fail to upload in Graviton environments

Fixed an error causing iPhone XR and XS device models to panic when APRR was set

This update provided minor bug fixes for the cloud.

Fixed an NVMe panic after pause or reboot from a READ timeout

Fixed a bug that caused ffmpeg to cause unknown device error

Fixed a bug that cause the Kill button in the app tab to occasionally not respond to a click

Added a connection token to vstrm servers, telegfx, and crlm-stream

Resolved an issue with a device that was stuck in the Deleting state

We're very excited to announce that this release brings Apple device models to Individual accounts. With this release, Individual accounts will also see new advanced settings, including the ability to upload custom kernels and ramdisks. In addition, all accounts will now be able to adjust the number of CPU cores and the amount of RAM assigned to generic Android devices. 

Support for Apple device models in Individual accounts

Support for custom kernel and ramdisk in Individual accounts

Improve error messaging for custom kernel and ramdisk

Enable users to change the amount of CPUs and RAM for generic Android devices

Update to the latest AOSP 10 and 11 revisions

Improve stability of links for latest OpenGApps versions

Upgraded the Android 8 Linux kernel version from 3.18 to 4.4

This update brings Enterprise customers support for the Apple A14 devices, including iPhone 12, iPhone 12 mini, iPhone 12 Pro, and iPhone 12 Pro Max. It also implements encryption for AWS S3 backed volumes, and fixes some minor bugs in iOS 14 support. 

Added support for iPhone 12, iPhone 12 mini, iPhone 12 Pro, and iPhone 12 Pro Max

Implemented encryption for AWS S3 backed volumes in the cloud

Fixed a bug preventing keyboard input on iOS 14

Fixed a bug that caused Cydia UI not to display on iOS 14

With this update, we're very excited to now offer Usage-Based Billing for our cloud subscribers. Users can now subscribe to Individual or Enterprise Usage-Based accounts, where devices they create are charged for on an hourly basis. Please visit the Subscription page in your account to view additional details about subscribing to Usage-Based accounts.

Allow writing to filesystems on Android 11

Prevent user from taking an Android snapshot before a device is fully shut down

In this release, a key highlight is that users are now allotted Stored Device slots, enabling users to store Off devices without occupying CPU cores. For each On device permitted on the user's account, up to 5 total devices can be stored. For example, a user with a 3-device Individual account will now have 15 "stored device" slots. Note that On devices count toward the total stored device count, so a user with a 3-device account could have 3 On devices and 12 Off devices.

Here is the full list of changes in this release:

Enabled users to store Off devices without occupying CPU cores

Updated support for iOS versions 14.1 and 14.2 with fixes for the panic patch and display firmware versions

Enabled support for copy and paste to a VM

Fixed a bug that caused iOS 14.0+ devices to fail to connect to network

Fixed a bug that caused large files and apps to sometimes fail to upload to cloud accounts

Fixed a bug that caused the Data folder to be inaccessible on iOS 13.4.1+

Fixed a bug that caused Flutter apps to fail to start on Android devices

Support for Network Monitor for Android devices

Support for Frida Console for Android devices