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 iOS virtual device 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 iOS virtual device 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

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

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

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 app security development and testing is included in the Application Workload pillar and its Application Security guidance, but that’s about it. It doesn’t use the acronyms, but it’s basically implying a shift from DevOps to DevSecOps.&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.

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

Resources and insights

Hayden Bleasel

Media Room

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

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

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.”
— Janey Hoe, VP Cisco Investments
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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.corellium.com/careers">our open roles</a>. You can also read more about our Series A funding on&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.forbes.com/sites/thomasbrewster/2021/12/16/corellium-announces-25-million-investment-from-cisco-paladin-to-build-iphone-and-android-research-heaven/?sh=21e4787b6b37">Forbes</a>,&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.businesswire.com/news/home/20211216005045/en/Corellium-Secures-25M-Series-A-Round-Led-by-Paladin-Capital-Group-with-Participation-from-Cisco-Investments">BusinessWire</a>&nbsp;or the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.ciscoinvestments.com/corellium-arm-cybersecurity-virtualization/?utm_source=corelliumpr&amp;utm_medium=referral&amp;utm_campaign=newinvestments">Cisco Investments Blog</a>.

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.

Amanda Gorton

Announcing the 2021 COSI Award Winner

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

Back in August, we announced the&nbsp;Corellium Open Security Initiative&nbsp;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&nbsp;any&nbsp;security and privacy claims for&nbsp;any&nbsp;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&nbsp;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!

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

Corellium Open Security Initiative

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.

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.
<h2>Rewarding Independent Research</h2>
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.&nbsp;
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.&nbsp;
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.&nbsp;
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 <a url="mailto:securityinitiative@corellium.com" data-span="hyperlink">securityinitiative@corellium.com</a>.&nbsp;
&nbsp;
<h2>First Call for Proposals</h2>
<h3>Topic: Validating Vendor Security Claims</h3>
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, <a url="https://www.apple.com/child-safety/" data-span="hyperlink">Apple announced</a> 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, <a url="https://www.apple.com/child-safety/pdf/Security_Threat_Model_Review_of_Apple_Child_Safety_Features.pdf" data-span="hyperlink">Apple has made</a> 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.&nbsp;
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 <a url="https://www.wsj.com/video/series/joanna-stern-personal-technology/apples-software-chief-explains-misunderstood-iphone-child-protection-features-exclusive/573D76B3-5ACF-4C87-ACE1-E99CECEFA82C" data-span="hyperlink">stated in an interview</a> 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.”&nbsp;
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.&nbsp;
<h3>Awards</h3>
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.&nbsp;
<h3>Eligibility</h3>
Having a track record of security research is helpful, but not required.
<h3>Requirements</h3>
<ul>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.&nbsp;
</li>
<li>
Any use of the Corellium platform is governed by our <a url="https://www.corellium.com/terms" data-span="hyperlink">Terms of Service</a>.
</li>
</ul>
<h3>Criteria</h3>
Awards will be granted at our sole discretion. We will review submissions based on the following criteria:
<ul>
<li>
The likely impact of the proposed research on improving mobile security or privacy.
</li>
<li>
The novelty and feasibility of the proposed research.
</li>
<li>
The likelihood that the project will be completed successfully.
</li>
<li>
The technical merits of the proposed research.
</li>
</ul>
<h3>How To Apply</h3>
Please email your proposal to <a url="mailto:securityinitiative@corellium.com" data-span="hyperlink">securityinitiative@corellium.com</a> by or before 5:00pm EST October 15, 2021.&nbsp;
In your proposal, please include the following details:
<ul>
<li>
Name: the name(s) of the researcher(s) that will be performing the research.
</li>
<li>
Organization (if applicable): your institutional affiliation, if any.
</li>
<li>
Project Description: a detailed description of the research you intend to perform.
</li>
<li>
Impact: a detailed description of why this research is important and the impact you expect it to have on improving mobile security or privacy.
</li>
<li>
Plan and Timeline: when you expect to start the research and how long you expect it to take.
</li>
<li>
How Corellium can Help: why you would benefit from using Corellium to perform your research.
</li>
<li>
Supplemental Information: any prior research or other details that might help us review your submission.
</li>
</ul>
We will review and respond to all proposals by 5:00pm EST October 31, 2021.&nbsp;
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 <a url="mailto:securityinitiative@corellium.com" data-span="hyperlink">securityinitiative@corellium.com</a>.&nbsp;
&nbsp;
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.

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.

Armv9 Architecture & Corellium: Why We Chose Arm vs. x86 | Update

Find out why Corellium chose Arm vs. x86 for our virtualized device platform, and how the Armv9 architecture delivers better security and advanced performance. 

Armv9 and Corellium: Why we chose Arm vs X86

In 2021, <a href="https://www.arm.com/company/news/2021/03/arms-answer-to-the-future-of-ai-armv9-architecture" rel="noopener">Arm gave us a glimpse</a> 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.

<h2>Arm vs x86: Security and Performance</h2>
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&nbsp;Confidential Compute Architecture&nbsp;built around&nbsp;TrustZone, as well as brand new security features like&nbsp;Memory Tagging Extensions&nbsp;(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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/new-technologies-for-the-arm-a-profile-architecture">SVE2</a>, adds new features and&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://www.arm.com/solutions/artificial-intelligence/machine-learning">optimizations for machine learning</a>, and adds new features like the&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture">Transactional Memory Extension</a>&nbsp;(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.
<h2>The Challenges of Dynamic Translation and Cross-Compilation in Device Emulators</h2>
Most device emulators rely on either&nbsp;dynamic translation&nbsp;technology or&nbsp;cross-compilation&nbsp;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&nbsp;exactly&nbsp;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.
<h2>CHARM: Corellium’s Secret Weapon for Virtualization</h2>
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 architecture. 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!

In 2021, <a href="https://www.arm.com/company/news/2021/03/arms-answer-to-the-future-of-ai-armv9-architecture" rel="noopener">Arm gave us a glimpse</a> 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.

Workshops

Upcoming Training Opportunities with Corellium

We're very excited to share a schedule of upcoming training events where you can not only learn from the best engineers in the security industry, but also get hands on with Corellium's Security Platform.

While the pandemic has limited opportunities for in-person trainings, Corellium's virtual devices are making it easier for conferences to host mobile security training events online. We're very excited to share a schedule of upcoming training events where you can not only learn from some of the best engineers in the security industry, but also get hands on with the Corellium CORSEC Security Platform.
Whether you're interested in reverse engineering or application security testing, these courses will give you a chance to learn the latest tips and tricks without having to worry about bringing your own device.
Corellium is proud to partner with the following trainers and upcoming events:
<h4>Blackhat Virtual 2021: March 15th-18th</h4>
Offensive Mobile Reversing and Exploitation Instructor: Dinesh Shetty, @Din3zh
<a previewtitle="https://www.blackhat.com/tr-21/training/schedule/#offensive-mobile-reversing-and-exploitation-22425" url="https://www.blackhat.com/tr-21/training/schedule/#offensive-mobile-reversing-and-exploitation-22425" data-span="hyperlink">Click here to learn more</a>
<h4>Blackhat Asia 2021: May 4th-7th</h4>
Offensive Mobile Reversing and Exploitation Instructor: Dinesh Shetty, @Din3zh
<a previewtitle="https://www.blackhat.com/asia-21/training/schedule/#offensive-mobile-reversing-and-exploitation-22250" url="https://www.blackhat.com/asia-21/training/schedule/#offensive-mobile-reversing-and-exploitation-22250" data-span="hyperlink">Click here to learn more</a>
<h4>Bsides Dublin 2021: March 27th (FREE - 2 Hour Workshop)</h4>
Android &amp; iOS Mobile Hacking Workshop Instructor: Davy Douhine, @ddouhine
<a previewtitle="https://www.bsidesdub.ie/schedule.php" url="https://www.bsidesdub.ie/schedule.php" data-span="hyperlink">Click here to learn more</a>
<h4>Bsides Canberra 2021: April 7th-8th</h4>
Mobile Security Testing Guide Hands-On - iOS Edition Instructor: Sven Schleier, @bsd_daemon
<a previewtitle="https://www.eventbrite.com.au/e/mobile-security-testing-guide-hands-on-ios-edition-tickets-87607876517?aff=ebdsoporgprofile" url="https://www.eventbrite.com.au/e/mobile-security-testing-guide-hands-on-ios-edition-tickets-87607876517?aff=ebdsoporgprofile" data-span="hyperlink">Click here to learn more</a>
<h4>CSA 2021: May 3rd-6th</h4>
Mobile Application Hacking Instructor: Enciphers, @enciphers_
Details Coming Soon
<h4>Blackhat USA 2021: July 31st - August 3rd</h4>
Offensive Mobile Reversing and Exploitation Instructor: Dinesh Shetty, @Din3zh
<a previewtitle="https://www.blackhat.com/us-21/training/schedule/index.html#offensive-mobile-reversing-and-exploitation-21936" url="https://www.blackhat.com/us-21/training/schedule/index.html#offensive-mobile-reversing-and-exploitation-21936" data-span="hyperlink">Click here to learn more</a>
---
<h5>&nbsp;</h5>
New to Corellium? Take advantage of a free 1-hour trial to see what all the hype is about! <a previewtitle="https://signup.corellium.com/" url="https://signup.corellium.com/" data-span="hyperlink">Click here to get started.</a>
Are you a mobile security trainer looking to facilitate online courses? Are you tired of lugging dozens of devices through airport security? <a previewtitle="mailto:steve@corellium.com" url="mailto:steve@corellium.com" data-span="hyperlink">Contact us</a> to learn more about how our affordable virtual devices can simplify your trainings!

While the pandemic has limited opportunities for in-person trainings, Corellium's virtual devices are making it easier for conferences to host mobile security training events online. We're very excited to share a schedule of upcoming training events where you can not only learn from some of the best engineers in the security industry, but also get hands on with the Corellium CORSEC Security Platform.

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

We’re very excited to announce that iOS device virtualization is now available for individual accounts&nbsp;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.
<h2>iOS Device Virtualization Pricing</h2>
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 <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&nbsp;prices will now be listed per core rather than per device.
<h3>Monthly Subscription Model</h3>
With our&nbsp;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.
<h3>Usage-Based Model</h3>
With our&nbsp;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&nbsp;per device&nbsp;(not per core), and they are charged&nbsp;per day&nbsp;rather than per hour.
<h2>iOS Device Virtualization Account Verification</h2>
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&nbsp;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 iOS device virtualization is now available for individual accounts&nbsp;on our groundbreaking security research platform, CORSEC.

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>
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&nbsp;<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.
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.
<h2 id="2-starting-the-port-for-linux-on-m1">2. Starting the port for Linux on M1</h2>
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.
<h2 id="3-need-input-connecting-the-usb-port">3. Need Input! Connecting the USB Port</h2>
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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://corellium.com/blog/mobile-physical-memory-security">blog post on IOMMUs</a>&nbsp;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.
&nbsp;
<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>
The first step to booting Linux on your Mac M1 is to download the Ubuntu POC rootfs&nbsp;<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.
<h3 id="2-extract-the-image">2. Extract the image</h3>
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
<h3 id="3-connect-to-the-mac">3. Connect to the Mac</h3>
Connect your USB drive to the Mac M1 using a dongle via the USB C port. The USB A ports are not currently supported.
<h3 id="4-boot-into-1tr">4. Boot into 1TR</h3>
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.
<h3 id="5-install-the-custom-kernel">5. Install the Custom Kernel</h3>
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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://downloads.corellium.info/linuxsetup.sh">https://downloads.corellium.info/linuxusbboot.sh</a>)"
The script will prompt you for your username and password. One you see it print "Kernel installed" it's safe to type&nbsp;reboot.
<h3 id="6-login">6. Login</h3>
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."
<h3 id="7-reverting-to-macos">7. Reverting to MacOS</h3>
To revert to booting MacOS, in 1TR open terminal and type&nbsp;bputil -n
------
<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>
The first step to booting Linux on your Mac M1 is to download the Ubuntu POC rootfs&nbsp;<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.
<h3 id="2-create-partition-and-flash-image">2. Create Partition and Flash Image</h3>
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&nbsp;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&nbsp;typing:
cp -RLav /usr/share/firmware/wifi /Volumes/EFIESP
<h3 id="3-boot-into-1tr">3. Boot into 1TR</h3>
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.
<h3 id="4-install-the-custom-kernel">4. Install the Custom Kernel</h3>
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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://downloads.corellium.info/linuxnvmeboot.sh">https://downloads.corellium.info/linuxnvmeboot.sh</a>)"
The script will prompt you for your username and password. One you see it print "Kernel installed" it's safe to type&nbsp;reboot.
<h3 id="5-login">5. Login</h3>
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."
<h3 id="6-reverting-to-macos">6. Reverting to MacOS</h3>
To revert to booting MacOS, in 1TR open terminal and type&nbsp;bputil -n
------
If you're interested in supporting our work on open source projects like these, please consider&nbsp;<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&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://asahilinux.org/">Asahi Linux</a>.
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!

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

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