Photos & Videos
Every album, by capture date.
HEIC converts on the fly for preview. Exports keep the original HEIC bytes and EXIF. Videos preserve QuickTime metadata.






























Your iPhone backup. Recovered, untouched.
Photos, videos, messages. Even when Manifest.db is corrupt, every file is identified and retrieved from the raw bytes.



































Every album, by capture date.
HEIC converts on the fly for preview. Exports keep the original HEIC bytes and EXIF. Videos preserve QuickTime metadata.






























Native bubble view.
Full conversations, image and video attachments, iOS 14+ attributedBody bodies — a 100% match against the raw text column.
Broken Manifest? Still recoverable.
Bypass the database. Identify JPEG, HEIC, MOV, SQLite, plist, and PDF by header magic bytes, then export by type.
| Type | Count | Total size | |
|---|---|---|---|
| heic | — | — GB | Export › |
| jpeg | — | — GB | Export › |
| mov | — | — GB | Export › |
| png | — | — GB | Export › |
| sqlite | — | — MB | Export › |
See the damage at a glance.
SQLite PRAGMA integrity_check, plus the count Manifest claims against what actually exists on disk.
Not a single byte changed.
Original filenames, original EXIF, mtime set to capture time. Already-exported files are skipped. Resume anywhere.
An iOS backup renames every file to its SHA1 hash, dropped into <root>/xx/ subdirectories. The original names and capture dates all live inside Manifest.db. Corrupt that database and ordinary tools stop working — but the bytes themselves are still intact.
Read the first 32 bytes of each blob. JPEG starts with FF D8 FF. PNG with 89 50 4E 47. HEIC has an ftyp box at byte 4 followed by the heic brand. SQLite begins with SQLite format 3.
No guessing. No inference. If it matches, it gets classified. If not, it is marked "other", with the raw bytes preserved.
$ iphone-rescue scan ./Backup Manifest.db ............... corrupt Photos.sqlite ............. ok sms.db .................... ok blobs on disk ............. xxxx blobs recognised .......... xxxx heic ··· ·· GB jpeg ··· ·· GB mov ··· ·· GB png ··· ·· GB sqlite ··· ·· MB plist ··· ·· MB
An interface that gets out of the way, built for tens of thousands of photos.





















| Type | Count | Total size | |
|---|---|---|---|
| heic | — | — GB | Export › |
| jpeg | — | — GB | Export › |
| mov | — | — GB | Export › |
| png | — | — GB | Export › |
| sqlite | — | — MB | Export › |
Schematic UI. Real screenshots ship with the release build.
Three platforms. Native builds.
Every release ships with SHA-256 checksums so you can verify file integrity after downloading.
No. The backend only binds to 127.0.0.1. No telemetry, no analytics, no auto-update checks. Works fully offline.
No. Every SQLite connection uses mode=ro&immutable=1. All file operations are read-only. Caches are written to the app's own data directory.
Not in this release. For now, encryption has to be turned off in iTunes or Finder and the backup remade.
No. Albums load lazily, 120 per page, with thumbnails generated on demand and cached. Fragment rescue uses a streaming scan.
Backups are tens to hundreds of gigabytes. There is no sensible reason to upload that to any cloud service. A local desktop app is the only form that fits — offline-capable, nothing leaves your machine.
Every release ships with SHA-256 checksums. After downloading, verify in a terminal with shasum (macOS / Linux) or certutil (Windows) to confirm the file was not tampered with or corrupted in transit.