In a previous blog, Exploiting iOS Local Storage with Corellium, we walked through how iOS applications store data locally and where testers can look for potential leaks. If you haven’t read that post yet, we recommend reviewing it to get familiar with the broader storage structure.
In this follow-up, we take a closer look at iOS application databases, specifically how apps use SQLite3 to manage local data and where testers often miss important details during static analysis. Using the DVIA-2 test app inside Corellium’s virtual iOS device environment, we walk through how to locate these database files, identify common oversights, and validate whether sensitive data is actually being saved and where.
We’ve also updated this guide to reflect current concerns around app privacy and local data persistence. This includes how features like Apple Intelligence and common third-party SDKs may store information that isn’t immediately visible or encrypted during mobile app penetration testing.
New Storage Risks in iOS App Security Testing
Changes in how mobile apps use local storage have introduced new testing requirements. Below are current risks researchers should be aware of when examining iOS application databases.
AI Features Writing to Local Storage
Some apps store prompts, responses, or summaries generated by on-device AI features. Depending on the framework used, this data may be written to unencrypted SQLite3 files or other local containers.
Data Persistence from Third-Party SDKs
Many SDKs used for analytics, engagement, and A/B testing write logs or identifiers directly to local database files. These records often sit in plain text and aren’t always cleared on logout or app reset.
Unsecured Files in App Backups
Unless encryption is configured properly, SQLite and WAL files can be recovered from device backups. This remains a reliable entry point for attackers or forensic tools, especially in apps that rely on defaults or skip security reviews for local storage.
iOS Database Background and Location
iOS applications employ local databases, often known as SQLite databases, to store and manage structured data. These databases are kept in the sandboxed environment of the application, which can be accessed with a jailbroken device. Mobile pentesters frequently target these local databases to harvest sensitive data, such as user passwords, private information, or application-specific data, as they can hold insightful information for examining the security posture of iOS applications.
As a refresher from the previous blog post, the iOS data directory is stored in the following location:
/var/mobile/Containers/Data/Application/
Once you are here, there are unique IDs for every application. One way you can identify which ID is related to the application you want is based on the Last Modified column; using that date to match when you installed the application on the device can quickly help identify which ID folder you require.
Alternatively, a second option is to use a third-party tool (Objection). This runtime mobile exploration toolkit utilizes Frida to identify the complete data storage path for an iOS application.
If you are using Objection, the following command can be used to hook an application and then a follow-up command to pull the apps environment details:
Using the DVIA-2 application, we will focus on the core data local storage challenge, similar to what we did in the first blog.
Data entered within this challenge will be available in the following directory
<Application ID>/Library/Application Support/
The iOS Database Is Missing Sensitive Information. Why Is That?
In the Corellium files tab, you can navigate to the directory above after completing the app challenge to see the database that has been generated. Download the database locally to your machine and open it with a database browser (DB Browser is a good option if you don’t have one).
What do you notice?
There is no data within the database, as you see from the screenshot below:
So why is this happening after the data was entered within the application? That is the basis of this blog post, ensuring this concept is not carried over to a mobile pentest or assessment.
An SQLite database also has a .wal (write-ahead log) file associated with it. These write-ahead logs are the reason that when downloading just the SQLite file, you might not see all the data that has been entered. Let's look deeper into .wal files and how to avoid this issue.
iOS Database Write-Ahead Logs
Changes to the iOS database that haven't yet been written to the main SQLite file are kept in the .wal file. As updates may be grouped and published to the main SQLite file in a single transaction, this enables more effective writes to the database. It also implies that information that hasn't yet been written to the SQLite file might be included in the .wal file.
Downloading both the SQLite file and the .wal file is recommended if one plans to perform static analysis on an iOS mobile app. The .wal file must be downloaded to avoid missing important information that hasn't yet been entered into the iOS database. This is very important when examining applications that largely rely on the database and constantly write data to it.
Downloading All Required Files within Corellium
With all that information, let's take a quick look at how to download the required files for the DVIA-2 exercise and ensure the data is there.
Navigate to the local data directory as we did at the start of the blog post:
/var/mobile/Containers/Data/Application/<Application ID>/Library/Application Support/
You should see files similar to what is shown below:
Select the SQLite database and the temporary files and click the Download button; this will download a ZIP archive containing all the files within one folder.
All the files should be within that ZIP archive; if you open the SQLite file when the write-ahead log is in the same folder, you will notice that all the data is then populated.
Identifying Sensitive Data in iOS Application Security Assessments
Identifying sensitive data within an iOS application is crucial to any assessment. While this is a simple concept, the importance is great, especially within the mobile appsec / pentest space. Remembering these fundamental concepts can help ensure that no data is missed and that a full assessment can be performed confidently. Take time regarding the security of your iOS applications.
Unlock Superior Mobile Security Testing with Corellium
With Corellium, security researchers and AppSec teams can test real-world app behavior under the latest iOS versions,including how emerging features like Apple Intelligence may store or transmit sensitive data. Sandbox app behavior. Snapshot it. Analyze it. All in a virtualized iPhone — no hardware lab needed.
Equip your security teams with unprecedented tools for both manual and automated testing, freeing up valuable engineering time and saving money. Discover the power of Corellium’s high-fidelity virtual devices and spin-up near limitless combinations of device and OS with one-click jailbreak/root access. Book a meeting today to see how we can streamline your processes and reduce costs.
Keep reading
Corellium Introduces Unparalleled Support for iOS 26 and Newest Mobile Device Models, Dynamic Risk Scoring for Mobile Applications, and Expanded Global Coverage
Apple's MIE Framework Makes Jailbreak-Dependent Testing Obsolete
