# iBackupExtractor: reading iOS backup sandboxes without the hash maze > iBackupExtractor is a Rust CLI that reads Manifest.db inside an unencrypted iOS backup and rebuilds the original app sandbox layout on disk. It is small, it is read-only for the commands most people need, and its last push was on 2023-09-21. **unixzii/ibackupextractor** — A simple tool for extracting files from iOS backup archive. Build Locally To build the project locally, use Cargo: Usage First, locate the backup archive you want to extract. - Repository: https://github.com/unixzii/ibackupextractor - Stars: 1,332 · Forks: 58 - Language: Rust - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/unixzii-ibackupextractor ## The problem: iOS backups do not keep your directory tree An iOS backup is not a copy of the filesystem. The README states that backup files are not stored with their original directory layouts, which is why retrieving one particular file from an app sandbox is difficult. The archive is a directory containing a Manifest.db file, and that database is what maps the stored blobs back to the paths they came from. Without a tool that reads it, you are left with a flat pile of files whose names tell you nothing about which app wrote them or where they lived. iBackupExtractor targets that gap. Its stated purpose is to extract all files from a backup archive so you can view the sandbox filesystem as it was originally stored on the device. The audience is narrow and practical: someone who already has a backup on disk and needs the files inside it, not someone looking for a general iOS data browser. ## How the extraction actually works The tool is a Rust binary with three read paths and one write path. The info subcommand opens the manifest and reports archive-level metadata: the manifest location, timestamps, device and iTunes metadata, total files and domains, and the overall size on disk. The list-domains subcommand enumerates the iOS domains inside the archive and sorts them by the amount of exportable data in each. The extract subcommand then walks the selected domain or domains and writes the files out. Domains are the organising unit throughout. iOS groups backup files by domain, so selecting -d SomeDomain is how you narrow an extraction to one app or one system area instead of pulling everything. The migrate subcommand reuses the same domain selection but targets a second archive, transferring files while preserving the original directory structure. One detail worth noticing is the read-only claim. The README says that except when performing migrations, Manifest.db is opened in read-only mode, so the tool works even when the archive sits on a read-only filesystem such as HFS+ mounted on Linux. The Cargo.toml dependency list includes a crate named readonly, which is consistent with that design. The author still warns against working on the only copy of your data, and that warning is reasonable: read-only access protects the archive from the tool, not from a bad destination path. ## Installing iBackupExtractor and running a first extraction Mac users can download pre-built binaries from the GitHub releases page, which the README points to directly. There is no Homebrew formula or package manager instruction in the README, so building from source is the documented path everywhere else. The project builds with Cargo: ```bash cargo build --release ``` The repository pins its toolchain in rust-toolchain.toml, so a rustup-managed environment will pick the right compiler version automatically. Cargo.toml declares edition 2024, which means you need a recent stable Rust toolchain rather than an old one. Before extracting anything, locate the archive. The README gives the usual location on macOS: ```bash /Users//Library/Application Support/MobileSync/Backup ``` The archive you want is a directory inside that folder that contains a Manifest.db file. Confirm you have the right one by asking for a summary first: ```bash ibackupextractor info /path/to/your_backup_archive ``` If the manifest opens, you should see the manifest location, timestamps, device and iTunes metadata, and counts of files and domains. If that command fails, the archive is the wrong shape or encrypted, and extraction will not help. Next, see what is inside and how much data each domain holds: ```bash ibackupextractor list-domains /path/to/your_backup_archive ``` The output is sorted by exportable data, so the domains with real content appear first. Then extract. To pull everything with data: ```bash ibackupextractor extract --all /path/to/your_backup_archive /path/to/dest_dir ``` Or to pull a single domain, for example one app sandbox: ```bash ibackupextractor extract -d SomeDomain /path/to/your_backup_archive /path/to/dest_dir ``` Use an empty destination directory. The README states that an error results if the tool tries to write over an existing file, so a partially populated destination will stop the run rather than merge into it. If disk space is tight, add the -L (or --link) option to create symbolic links instead of copies. That keeps the extraction cheap but ties the output to the archive staying in place. ## Unencrypted archives only, and other limits The largest constraint is stated plainly in the FAQ: the tool can only handle backup archives that are unencrypted. If you checked the encrypt local backup option in Finder or iTunes, this tool is the wrong one and there is no documented workaround. That single fact rules it out for a large share of real backups, because encrypted local backups are common. The second constraint is the destination behaviour. Extraction refuses to overwrite an existing file, which is safe but unforgiving. A rerun after a partial failure will hit the same paths and error out unless you clear the destination first. The README does not document a force flag or a resume mode, so plan the destination directory accordingly. The third is scope. This is a file extractor, not a viewer. It has no preview, no search across extracted content, and no GUI. If your question is "what was in this message thread" rather than "give me the files from this domain", you will still be reading plist and SQLite files by hand afterwards. The migrate subcommand also needs read/write access to the destination archive, so it is the one operation that cannot run against read-only storage. ## Where it sits next to a GUI backup browser The obvious alternative for the same job is a graphical iOS backup browser, the category that tools like iBackup Viewer occupy. The difference is not cosmetic. A GUI browser indexes the manifest and presents messages, photos, call history and contacts as browsable tables, which is faster when you want to look at something and slower when you want a faithful copy of an app sandbox on disk. iBackupExtractor goes the other way. It reconstructs the directory layout and hands you files, which means you can run your own tooling over them: grep, diff two extractions from different dates, or feed a domain into a script. The trade-off is that you get no interpretation layer at all. It also runs on Linux, which matters if your archive was copied off a Mac onto a Linux box, and the read-only manifest handling is explicitly designed for that case. A GUI browser tied to macOS does not help you there. If your goal is quick human inspection of a backup, the GUI route is less work. If your goal is a reproducible, scriptable dump of specific domains, the CLI is the better fit. ## Maintenance, licence and upgrade cost The repository is not archived, but the last push was on 2023-09-21 and the only release listed is v0.1.0 from the same date. That is the whole maintenance picture available here, and it is worth weighing before you build a workflow around it. Cargo.toml declares version 0.2.0 while the release list stops at v0.1.0, so the source tree is ahead of the published binaries. If you rely on the pre-built macOS downloads, you are on the older build; if you need the current code, you build it yourself. That gap has a practical cost. Cargo.toml targets edition 2024 and pins a toolchain, so building requires a reasonably current Rust installation, and the dependency set (rusqlite, plist, clap, indicatif, chrono and others) will drift over time. There is no CI or release automation described in the README, so nothing guarantees a rebuild will keep working without intervention. The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the tool. This is a description of the licence identifier in the repository, not legal advice; check the LICENSE file if you need terms for a commercial redistribution. ## Conclusion Adopt iBackupExtractor if you need a specific app sandbox from an unencrypted, already-made iOS backup and you want the original directory structure rather than a pile of hash-named files. Do not adopt it if the backup is encrypted, if you need to browse or preview data interactively, or if you expect ongoing releases: the last push was on 2023-09-21 and the single listed release is v0.1.0. Before relying on it, verify that your archive contains a Manifest.db file, run ibackupextractor info against it to confirm the manifest opens, and extract into an empty destination directory, because writing over an existing file raises an error. ## FAQ ### Does iBackupExtractor work? It works on the archives it was designed for: unencrypted iOS backups whose archive directory contains a Manifest.db file. The README states that encrypted backups are not supported, so a failure on an encrypted archive is expected behaviour rather than a bug. ### Is there a free iOS backup extractor available? iBackupExtractor is MIT licensed and its source is on GitHub, with pre-built macOS binaries on the releases page. You can also build it yourself with cargo build --release. ### How do I use iBackupExtractor? Point the info subcommand at the archive directory first to confirm the manifest opens, then use list-domains to see what is inside, then extract with either -d SomeDomain or --all followed by the archive path and an empty destination directory. ### What is iBackupExtractor? It is a Rust command line tool that extracts files from an iOS backup archive. Because iOS backups do not preserve the original directory layout, the tool reads Manifest.db and rebuilds the sandbox filesystem as it was originally stored on the device. ## Sources - [Official README](https://github.com/unixzii/ibackupextractor#readme) - [Project repository](https://github.com/unixzii/ibackupextractor) - [Release notes](https://github.com/unixzii/ibackupextractor/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unixzii-ibackupextractor