Home > iOS Pentesting

File System Structure of iOS Apps

Understanding the filesystem structure of iOS applications is essential for pentesting because every sensitive asset—databases, logs, caches, cookies, tokens, configuration files, plist settings, and local storage—lives inside the app container. This chapter provides a complete practical guide to exploring, extracting and analyzing the filesystem of an installed application on both jailbroken and non-jailbroken devices. You will learn actual directory layouts, what each folder contains, where sensitive data usually hides and exactly how to inspect everything during pentests.

How iOS App Sandboxing Works

Each app runs inside its own sandbox container. The sandbox prevents apps from accessing each other’s data. For pentesters, this means you must locate the correct container and then inspect every directory inside it.

A typical app container contains:

AppName.app              (the application bundle)
Documents/               (user data / sensitive files)
Library/                 (caches, preferences, state)
tmp/                     (temporary files)

Inside Library/ you will find subfolders:

Library/Preferences/
Library/Caches/
Library/Application Support/
Library/Cookies/

Each has different forensic and security implications.

Step 1: Locating the App Container (Jailbroken Device)

SSH into the device:

iproxy 2222 22
ssh root@localhost -p 2222

App containers are stored here:

/var/mobile/Containers/Data/Application/

List all containers:

ls -l /var/mobile/Containers/Data/Application/

To find the correct app container:

grep -R "BundleID" -n /var/mobile/Containers/Data/Application/*/Library/Preferences/

Example:

/var/mobile/Containers/Data/Application/UUID/Library/Preferences/com.example.app.plist

This UUID folder is the app’s container.

Step 2: Understanding Application Bundle Location

The application bundle (.app) is stored separately:

/var/containers/Bundle/Application/

Each folder contains one app. Identify your target:

ls /var/containers/Bundle/Application/*/ | grep .app

The .app directory contains:

  • Mach-O binary

  • Info.plist

  • Frameworks

  • Assets (images, JSON, configs)

  • Storyboards

  • Swift/ObjC metadata

This is critical for static analysis.

Step 3: Full Filesystem Layout of a Standard iOS App

Once inside the app container:

cd /var/mobile/Containers/Data/Application/UUID/

You will see:

Documents/
Library/
tmp/

Documents Directory

Contains user-created data or developer-stored data.

Common contents:

  • SQLite databases

  • User profiles

  • Session storage

  • Exported files

  • Sensitive cached data

Check:

ls Documents/

Inspect databases:

sqlite3 Documents/database.sqlite

Dump tables:

.tables
SELECT * FROM users;

Library Directory

Contains all internal app data.

ls Library/

Subdirectories:

Library/Preferences

Stores plist files.

ls Library/Preferences/

These contain:

  • Feature flags

  • App configuration

  • Authentication settings

  • Analytics settings

  • Potential API endpoints

Use:

plutil -convert xml1 Library/Preferences/*.plist

Library/Caches

Stores temporary data:

  • HTTP caches

  • Image caches

  • API responses

  • Offline data

Search:

grep -R "http" -n Library/Caches/

You may find internal staging URLs and hidden APIs.

Library/Application Support

One of the most sensitive folders.

Contains:

  • Internal app state

  • Custom databases

  • JSON configs

  • Encrypted data files

  • Session tokens

  • User secrets

  • App logic artifacts

Inspect:

ls -l Library/Application\ Support/

Library/Cookies

Stores cookie files:

ls Library/Cookies/

Look for:

  • Session cookies

  • Authentication cookies

  • WebView cookies

tmp Directory

Temporary files used during runtime.

ls tmp/

Common contents:

  • Uploaded files

  • Temporary logs

  • Crash-related files

  • Incomplete download artifacts

These often contain sensitive data left unintentionally.

Step 4: Extracting the Entire File System for Analysis

Use SCP to download everything:

scp -P 2222 -r root@localhost:/var/mobile/Containers/Data/Application/UUID/ ./AppData/

This copies the entire sandbox container to your machine.

Inspect locally:

tree AppData/

Step 5: File System Structure on Non-Jailbroken Devices

Non-jailbroken devices restrict access heavily, but Xcode allows partial access.

Connect device → Open Xcode → Devices & Simulators
Select app → Download Container

This gives:

AppData/
  ├── AppName.app (sometimes restricted)
  ├── Documents
  ├── Library
  └── tmp

You can still inspect:

  • SQLite databases

  • Plists

  • Preferences

  • App caches

  • Local data

You cannot inspect:

  • Executable binary (still encrypted)

  • System-level files

  • Protected keychain items

Use this for safe analysis while validating jailbreak-findings.

Step 6: Identifying Sensitive Files

Search for common patterns:

grep -R "password" -n .
grep -R "token" -n .
grep -R "api" -n .
grep -R "secret" -n .
grep -R "key" -n .

Common discoveries include:

  • API tokens

  • AWS keys

  • Environment variables

  • Authentication cookies

  • API base URLs

  • Logged user data

  • JSON configs with secrets

Inspect JSON files:

cat Library/Application\ Support/*.json

Inspect SQLite:

sqlite3 Documents/*sqlite .dump

Step 7: Analyzing Keychain Usage

Keychain items are not stored in the app sandbox, but metadata may reference them.

Check for keychain groups:

grep -R "keychain" -n Library/Preferences/

This helps during entitlements analysis.

Step 8: Locating Logs and Crash Artifacts

Apps commonly leak data into:

Library/Logs/
Library/Preferences/
tmp/

Look for crash logs:

ls tmp/ | grep crash

Inspect logs:

grep -R "." tmp/

Developers often accidentally log:

  • Responses

  • API URLs

  • JWT tokens

  • Error messages giving internal info

Step 9: Frameworks Within the App Bundle

Open app bundle:

cd /var/containers/Bundle/Application/UUID/AppName.app/
ls -1 | grep .framework

Frameworks may contain:

  • Embedded authentication logic

  • Crypto implementations

  • Private API wrappers

  • Hardcoded keys

Extract strings from frameworks:

strings FrameworkName.framework/FrameworkName | grep -i "http"

Step 10: Mapping Filesystem to Pentesting Actions

Each folder provides clues for real attacks:

  • Documents → Database extraction → Credential leakage

  • Library/Preferences → App logic flags → Feature abuse

  • Library/Caches → Offline API responses → Sensitive data exposure

  • Library/Application Support → Tokens → Internal configs → Keys

  • tmp → Uploaded files → Pre-processed sensitive files

  • Frameworks → Hardcoded keys → Private logic

This filesystem is the foundation for all deeper exploitation.

Intel Dump

  • App containers live in /var/mobile/Containers/Data/Application

  • The .app bundle lives in /var/containers/Bundle/Application

  • Documents stores user data and databases

  • Library/Application Support contains sensitive internal app files

  • Library/Preferences holds important configuration plists

  • Library/Caches stores HTTP caches and API results

  • tmp contains temporary sensitive files

  • Use grep, plutil, sqlite3 and strings for full analysis

  • Entire container can be extracted for deep local analysis

HOME LEARN COMMUNITY DASHBOARD