Anthony Ricco

Technical Writeups

How to Use Safari Web Inspector to Debug iOS Devices | A Guide

Learn to set up a Corellium iOS virtual device and perform debugging of web applications using Safari's Web Inspector tool.

Using the Safari Web Inspector with Corellium

<h2>Overview</h2>
In this guide, we'll be setting up a Corellium <a href="https://www.corellium.com/devices/ios" rel="noopener">iOS virtual device</a> to perform debugging of web applications using Safari's Web Inspector tool. For web developers, this is useful for testing rapid tweaks to CSS or troubleshooting responsive web design on an iPhone-sized display. For security researchers, the Javascript console can help identify why their fakeobj and addrof primitives aren't working.

<h2>Configure the Virtual Device</h2>
<img src="https://21590441.fs1.hubspotusercontent-na1.net/hubfs/21590441/EnablingWebInspector.png" alt="Enabling Web Inspector" width="572" loading="lazy" style="width: 572px;">
First, Safari on the virtual device must be configured to enable the Web Inspector. From the home screen, select the Settings icon, and then scroll down to Safari. On the next screen, scroll all the way to the bottom and select Advanced.
Enable the Web Inspector and return to the home screen.
Open Safari and browse to any page.
<h2>Configure Safari on the Mac</h2>
Next, ensure that the <a href="https://www.corellium.com/guides/connecting-to-the-corellium-vpn" rel="noopener" target="_blank">Corellium VPN is connected</a> and connect with <a href="https://www.corellium.com/guides/connecting-to-a-virtual-ios-device-with-usbflux" rel="noopener" target="_blank">USBFlux</a>.
 <img src="https://lh3.googleusercontent.com/DUqWcq8P8xMAjcCIW4T8_zqU6ailS8PaD-shOniDkcAcfMt9ynUSI0vsXT-wr7OWdgTgHmWQgLuvelM0bcuza4e3R0vncVjsiOXv0T59t-ejo0IhxCQPCq-Zzim3ZJHzgUIXZeJluSRhar81oA" width="381" height="296" loading="lazy">
<img src="https://lh3.googleusercontent.com/PLWbSxDE98RkJE22ULt_HoPRuGvfxclwiVODhKkgVraE7HVmtNmM2fW6EKFonfz-trnlGS2BEk_kCFVEVwzx2EJypdXhRtRyf4X7rLuREdJMkrPCvOSGR3jhQ2CsGtv0S0fLr8AyAD-vbq-ZJQ" width="487" height="264" loading="lazy">
If Safari is already running on the Mac, restart it fully by clicking Safari in the menu bar, followed by Quit Safari (or press ⌘Q with Safari selected) and then re-opening the application.
From the Safari menu, select Preferences and then switch to the Advanced tab. At the bottom of the window, ensure that "Show Develop menu in menu bar" is selected. Close the Preferences window.
<img src="https://lh3.googleusercontent.com/bdeX1ngAeq_Z3uaTdcrsXAGTSCG_sRxNIIZ5KbunwUblfM-Q1h2mBvsKrdwte5-O9dxwohWUu3QDjn474tv9mHSaPj6v68lUc-gcRnlNFAZVO1Ulb1cOUTrUcSYYWU5u-oR4FNTkV0P7IqJOzQ" width="624" height="341" loading="lazy" alt="The advanced tab screen in the Safari preferences menu">
The Develop menu will now appear in the menu bar, including a list of devices that have inspectable browsers. In this case, it will include the virtual device (named "iPhone" by default) and the local Mac (named "User's Mac" in the screenshot). When mousing over the iPhone submenu, the available tabs will appear under Safari, and selecting one will open the inspector.
<img src="https://lh3.googleusercontent.com/pt0oQ7rZb3IyB2TdCGmVMBJ_lRxQSn5NOwT8ASxK-X27nBbfINBpcSKj2r6CpP-X9bcC2kYJrGeURzUzJl-5OzCdXbjvwS2MLs9DGxsWpafRmudSSRUADZDacYczy9zd4T8UyjUysif8h4bvvQ" width="624" height="197" loading="lazy" alt="iPhone &quot;Develop&quot; submenu dropdown"> <img src="https://lh3.googleusercontent.com/ze48oYVXulVL14jciRMD3n54FVcFj2wJQpNoWr95D7_9aLrGakeLkCks_uISSrQBe9AwMAdcmQ1Xjfr03bIAXhJiJUp6-sGUhIhbj6w4l2gn9absDV0zwK3plMoHcD3SX9E47MFR72HRb3g2dQ" width="624" height="406" loading="lazy" alt="web inspector">
The inspector has many features that are out of the scope of this guide, see the <a href="https://developer.apple.com/safari/tools/" rel="noopener" target="_blank">official documentation</a> for additional details.
<h2>Troubleshooting</h2>
<ul>
<li>If you are in the cloud, always ensure you are connected to VPN with the correct configuration profile.</li>
<li>If a device is not detected properly, try closing and reopening USBFlux and Safari, in that order. </li>
</ul>

<h2>Overview</h2>
In this guide, we'll be setting up a Corellium <a href="https://www.corellium.com/devices/ios" rel="noopener">iOS virtual device</a> to perform debugging of web applications using Safari's Web Inspector tool. For web developers, this is useful for testing rapid tweaks to CSS or troubleshooting responsive web design on an iPhone-sized display. For security researchers, the Javascript console can help identify why their fakeobj and addrof primitives aren't working.

text

Person looks at a screen of code reflected in his glasses

NIST SSDF Mobile Application Security Testing Checklist

It’s hard to find useful, well-researched information on mobile security testing and best practices. Here’s our guide to NIST SSDF Mobile App Security Testing.

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

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

Let’s start with very useful, seminal work on mobile security testing, with OWASP® contributors doing a wonderful job with two foundational works. Any searches on the topic of mobile security testing should have landed on them, but in case yours didn’t.
<h2 id="mobile-security-testing-guide">Mobile Security Testing Guide</h2>
The first is the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://mobile-security.gitbook.io/mobile-security-testing-guide/">Mobile Security Testing Guide (MSTG)</a>1 from OWASP. From its introduction:
“The OWASP Mobile Security Testing Guide (MSTG) is a comprehensive manual for testing the security of mobile apps. It describes processes and techniques for verifying the requirements listed in the Mobile Application Security Verification Standard (MASVS), and provides a baseline for complete and consistent security tests.”
If you haven’t seen it before, at first glance you may get the impression that it’s merely a high-level overview of basic principles that any mobile developer or security expert already knows. But in fact, it’s quite comprehensive and technically detailed, a great living work by all its contributors, and a very useful resource for new and advanced mobile security gurus alike.
The MSTG is comprised of three primary sections, again from the Guide’s overview:&nbsp;
<div>
<ul>
<li>“The General Testing Guide contains a mobile app security testing methodology and general vulnerability analysis techniques as they apply to mobile app security. It also contains additional technical test cases that are OS-independent, such as authentication and session management, network communications, and cryptography.</li>
<li>The Android Testing Guide covers mobile security testing for the Android platform, including security basics, security test cases, reverse engineering techniques and prevention, and tampering techniques and prevention.</li>
<li>The iOS Testing Guide covers mobile security testing for the iOS platform, including an overview of the iOS OS, security testing, reverse engineering techniques and prevention, and tampering techniques and prevention.”</li>
</ul>
</div>
<h2 id="mobile-appsec-verification-standard">Mobile AppSec Verification Standard</h2>
The second work from the OWASP Mobile Security Project™ and its contributors, is the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://mobile-security.gitbook.io/masvs/">Mobile AppSec Verification Standard (MASVS)</a>1.
From its introduction,&nbsp;“The MASVS is a community effort to establish a framework of security requirements needed to design, develop and test secure mobile apps on iOS and Android.”
You must admit, this is a bold undertaking to produce and keep current, but it’s a sorely needed one and a job well done. A useful summary from the document:
“The MASVS defines two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing client-side threats is a design goal.
Fulfilling the requirements in MASVS-L1 results in a secure app that follows security best practices and doesn't suffer from common vulnerabilities. MASVS-L2 adds additional defense-in-depth controls such as SSL pinning, resulting in an app that is resilient against more sophisticated attacks - assuming the security controls of the mobile operating system are intact and the end user is not viewed as a potential adversary. Fulfilling all, or subsets of, the software protection requirements in MASVS-R helps impede specific client-side threats where the end user is malicious and/or the mobile OS is compromised.”
<h2 id="nist-ssdf">NIST SSDF</h2>
And now for what’s happening from the U.S. gov end of things and recent cybersecurity standards and guidance news. Let’s start with the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.nist.gov/">National Institute of Standards and Technology</a>&nbsp;(NIST) which produces many publications on the topic of cybersecurity.
The recent news has been around the NIST 800-218 publication in 2021 and updated in February 2022, entitled “<a target="_blank" rel="noopener noreferrer" href="https://csrc.nist.gov/Projects/ssdf">Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities</a>”.
It’s a comprehensive and relevant work as it applies to mobile software development and testing. Excusing the pun, it sets the new standard as far as past security frameworks for SDLC go. It contains numerous references to useful resources, and the OWASP MASVS resource is primarily referenced within the Produce Well-Secured Software (PW) section.
I find the NIST SSDF publication to be well thought-out and as you read through the examples for each “task”, it makes for a good checklist to walk through for your mobile software development practices (or any software development). Some tasks are easier said than done, but it provides for a great “you are here” resource for understanding your current SDLC security posture and what you need to keep an eye on moving forward.
Having no affiliation with it, I found this blog useful when reading NIST 800-218:
<a target="_blank" rel="noopener noreferrer" href="https://blog.chainguard.dev/i-read-nist-800-218-so-you-dont-have-to-heres-what-to-watch-out-for/">I Read NIST 800-218 So You Don’t Have To - Here’s What to Watch Out For</a>, by Dan Lorenc. When searching for other NIST cybersecurity initiatives that are currently underway, I found the following particularly interesting. They are looking into consumer labeling practices for both software and IoT devices. In a nutshell, when software or IoT devices are made available for end-use, the level of security testing performed or achieved would be clearly indicated. According to the links below, an initial summary report is to be published by May 12, 2022. This will be interesting to say the least and I’ll update this blog with relevant information.
<div>
<ul>
<li><a target="_blank" rel="noopener noreferrer" href="about:blank">Recommended Criteria for Cybersecurity Labeling of Consumer Software</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/consumer-cybersecurity-labeling-pilots-approach">Consumer Cybersecurity Labeling Pilots: The Approach and Contributions</a></li>
</ul>
</div>
<h2 id="cisa-zero-trust">CISA Zero Trust</h2>
There also have been recent news headlines made by the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.cisa.gov/">Cybersecurity &amp; Infrastructure Agency</a>&nbsp;(CISA), first established in 2018.
There are recent two works of interest:
<div>
<ul>
<li><a target="_blank" rel="noopener noreferrer" href="https://www.cisa.gov/zero-trust-maturity-model">Zero Trust Maturity Model</a>, introduced in September 2021, and</li>
<li><a target="_blank" rel="noopener noreferrer" href="https://www.cisa.gov/uscert/ncas/current-activity/2022/03/07/cisas-zero-trust-guidance-enterprise-mobility-available-public">Applying Zero Trust Principles to Enterprise Mobility</a>, newly introduced in March 2022.</li>
</ul>
</div>
These works, to me at least, are more indirectly related to mobile security testing and SDLC best practices. This makes sense as Zero Trust refers to user access privileges and hence the in-production phases of SDLC.
But I would have hoped that Zero Trust would have extended to cover the design and development phases of the SDLC as more and more vulnerabilities are likely to be introduced well before software deliveries.
In the&nbsp;Zero Trust Maturity Model&nbsp;document, the topic of <a href="https://www.corellium.com/solutions/mobile-security-research" rel="noopener">app security</a> development and testing is included in the Application Workload pillar and its Application Security guidance, but that’s about it. It doesn’t use the acronyms, but it’s basically implying a shift from DevOps to DevSecOps.&nbsp;
Reproduced from&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.cisa.gov/sites/default/files/publications/CISA%20Zero%20Trust%20Maturity%20Model_Draft.pdf">Table 4</a>&nbsp;on page 12:
“Application Security Function:
<div>
<ul>
<li>Traditional – Agency performs application security testing prior to deployment, primarily through static and manual testing methods.</li>
<li>Advanced – Agency integrates application security testing into the application development and deployment process, including the use of dynamic testing methods.</li>
<li>Optimal – Agency integrates application security testing throughout the development and deployment process, with regular automated testing of deployed applications.”</li>
</ul>
</div>
Looking through the&nbsp;Applying Zero Trust Principles to Enterprise Mobility&nbsp;document, you eventually reach “Table 1: Enterprise Mobile Security Components”. And wading through each, mobile security testing lands on its relatively small Mobile App Vetting (MAV) component.
Not bad I suppose for a CISA framework where the Zero Trust context aims at a different aspect of mobile security and different phase of mobile software development. Would have been helpful if CISA’s MAV and NIST’s SSDF were linked or cross-referenced.
I’d keep an eye on CISA “Zero Trust” publications, but looks like the NIST “SSDF” publications are currently more directly relevant to the topic of mobile security testing and mobile SDLC.
To learn more about Corellium and what we do, visit us at&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.corellium.com/">Corellium.com</a>&nbsp;
&nbsp;
1 OWASP trademarks and published works belong to and are under copyright by The OWASP Foundation. The OWASP works are licensed under a&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>. For any reuse or distribution, you must make clear to others the license terms of the works.

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

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

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. To that end, we’re very proud to announce that our Corellium Virtual Hardware platform now supports iOS 16, including fully jailbroken iOS 16.

&nbsp;
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/">analyzing the Pegasus malware</a> to dissecting the <a href="https://twitter.com/patrickwardle/status/1210742545451323392">UAE-spy app ToTok</a> to uncovering how malware may be loaded onto an iPhone’s Bluetooth chip <a href="https://arxiv.org/pdf/2205.06114.pdf">even when the device is off</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.
&nbsp;
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.
&nbsp;
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;
&nbsp;
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;
<h2>Public jailbreaks are increasingly rare</h2>
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;
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.
But this success has created something of a catch-22. As our CTO Chris Wade describes:&nbsp;
<blockquote>
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.
</blockquote>
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.
<h2>&nbsp;</h2>
<h2>iOS 16 features focus on narrowing attack surfaces</h2>
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. Lockdown Mode strictly limits or disables certain ‌iPhone‌ features, as well as access to certain apps and websites.
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. 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/">limited review</a> these apps undergo.
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">according to Apple</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.
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;
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;
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.
For more information about our latest code release, check out <a href="https://www.corellium.com/updates">https://www.corellium.com/updates</a>.&nbsp;

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. To that end, we’re very proud to announce that our Corellium Virtual Hardware platform now supports iOS 16, including fully jailbroken iOS 16.

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

Persistence is a <a href="https://attack.mitre.org/tactics/TA0003/" style="background-color: #ffffff;" rel="noopener" target="_blank">tactic</a> used by attackers and jailbreakers1 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>&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 cyber attack surface.

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