Recover deleted photos, videos and messages from Android and iOS — with provenance you can defend.
RecoverKit finds what is still there after a delete: files sitting in a trash area with days left on the clock, rows still readable in a SQLite freelist, thumbnails of photos whose originals are long gone, notification text that outlived the message it announced. It records exactly how each item was recovered, so nobody has to take the result on faith.
RecoverKit contains no exploits, no jailbreaks, no lockscreen bypass, no FRP bypass, and no attacks on cloud account credentials. Not in this repository, not as an optional plugin, not as a recommended dependency. This is a permanent boundary, not a roadmap gap. Contributions that cross it are declined on sight (see SECURITY.md).
RecoverKit works on devices you are authorised to work on: your own device, or someone else's with their informed consent, or under lawful authority. Every run requires you to state that authorisation on the command line, and records it permanently in the run manifest. Read ACCEPTABLE_USE.md before you use this on a device that is not yours — especially the part about the difference between owning a phone and owning the data on it.
Honest expectations matter more here than in most software, because the physics are unforgiving and "recovery tool" is a category full of products that overpromise.
| Situation | Realistic outcome |
|---|---|
| Photo deleted from an iPhone in the last 30 days | Recovered in full. It is in "Recently Deleted" and RecoverKit also reads the Syndication library most tools skip |
| Photo deleted from an Android phone in the last 30 days | Recovered in full. Trashed media is renamed in place, not erased |
| Photo deleted 6 months ago, iPhone | Thumbnail only, if you are lucky. The full-resolution original is gone and cannot be brought back |
| iMessage/SMS deleted on iOS 12 or newer | Usually a count, not the content. Apple compacts the message database on deletion. RecoverKit tells you precisely how many messages were deleted and when — see "negative evidence" below |
| WhatsApp message deleted on Android, device rooted | Often recovered, from the database freelist, the write-ahead log, or the system notification history |
| Anything, on a device that has not been unlocked since boot | Nothing. File-based encryption keys are not in memory yet. No tool of any price changes this |
| Anything, after "Erase All Content and Settings" | Nothing, ever. The encryption key is destroyed; the storage is unrecoverable ciphertext |
The full matrix is in docs/ACQUISITION.md. What is permanently impossible, and why, is in docs/LIMITATIONS.md. Read the second one before opening an issue titled "it didn't find my photos".
Existing open-source forensic tools split the problem in half and each take one side. iLEAPP and ALEAPP parse roughly 700 artifacts beautifully — but they read live rows. PhotoRec, The Sleuth Kit and sqlite-dissect carve deleted data superbly — but know nothing about mobile artifacts. RecoverKit drives both sides and adds three things neither has:
Cross-source correlation. A deleted WhatsApp message typically leaves nothing in the messages table, its text in the system notification history, an orphaned image file whose database row is gone, and maybe a partial record in the database freelist. Four traces, four tools, four disconnected outputs. RecoverKit joins them into one item and raises its confidence because independent sources agree.
Quantified negative evidence. When content cannot be recovered, gaps in database row-id sequences still prove precisely how much was deleted and roughly when. "1,412 messages deleted from this thread; the gaps cluster between 14:10 and 14:19 UTC on 2026-03-04." On modern iOS this is often the only messaging result that is not empty — and it is arithmetic, so it does not depend on anyone believing a heuristic.
A unified trash sweep with an expiry countdown. One command covers Android's in-place trashed files, vendor trash bins, MediaStore, Google Photos, and iOS Recently Deleted across both photo libraries — and tells you "37 items still fully recoverable, 12 expire in under 48 hours." Deleted data has a clock on it. The tool should say so.
pipx install recoverkit # or: uv tool install recoverkit
recoverkit doctor # tells you what else you need, and how to get itThe base install is a pure-Python wheel — no compiler, no toolchain. Some
capabilities need external programs (adb, photorec, pymobiledevice3).
RecoverKit detects these and tells you the exact install command for your
system; it never bundles them. recoverkit doctor is the first thing to run and
the first thing to paste into a bug report.
If you would rather not install anything, the Docker image has the full toolchain:
docker run --rm -v "$PWD/cases:/cases" ghcr.io/recoverkit/recoverkit doctorNote that USB device access from a container only works on Linux hosts. Analysing an already-acquired backup or image works everywhere.
# Analyse an iTunes/Finder backup that already exists on this computer.
# Nothing is written to the backup; it is opened read-only and hashed before and after.
recoverkit ios import ~/Library/Application\ Support/MobileSync/Backup/<UDID> \
--authorization owner-self \
--out ./cases/my-phone
# Acquire a fresh encrypted backup from a connected iPhone, then analyse it.
recoverkit ios acquire --authorization owner-self --out ./cases/my-phone
# What is still recoverable right now, and what expires soonest? Read-only, minutes.
recoverkit triage --authorization owner-selfEach run produces a case bundle: the untouched extraction, the recovered content
addressed by hash, a ledger.db of every item found, a report.html you can
open in any browser or hand to someone else, and a manifest.json that records
every input hash, every output hash, every external tool version, and the
authorisation you stated. See docs/MANIFEST.md for how to
verify a run independently — including a run produced by someone else.
--authorization is required. RecoverKit refuses to run without it. It accepts
any string; owner-self, consent:<name> and warrant:<reference> are the
conventional ones. It is a speed bump and an audit-trail entry, not a security
control, and the documentation says so plainly rather than pretending otherwise.
| Document | What it covers |
|---|---|
| docs/ACQUISITION.md | Device state vs. what is actually recoverable — the matrix |
| docs/LIMITATIONS.md | What is impossible, and the physics behind each "no" |
| docs/ARCHITECTURE.md | Layers, boundaries, and why GPL dependencies run as separate processes |
| docs/CONFIDENCE.md | How a recovery method maps to a confidence tier |
| docs/DATA_MODEL.md | RecoveredItem fields and the RecoveryMethod vocabulary |
| docs/MANIFEST.md | Run manifest reference and independent verification |
| docs/playbooks/ | Step-by-step guides per platform and per app |
| docs/UPSTREAM.md | Relationship to iLEAPP/ALEAPP and how to write a module that runs in both |
RecoverKit deliberately writes as little as possible. The heavy lifting belongs to projects that have been doing it well for years: pymobiledevice3, PhotoRec, The Sleuth Kit, sqlite-dissect, wa-crypt-tools, iLEAPP and ALEAPP, and others. Full attribution, licences, and integration modes are in THIRD_PARTY_LICENSES.md.
Apache-2.0. See LICENSE and NOTICE.
The consent and lawful-use expectations live in ACCEPTABLE_USE.md, deliberately not in the licence. Putting use restrictions in a licence costs OSI approval and Linux distribution packaging while doing little to stop anyone determined to misuse the tool. The expectations are no less real for being stated in prose.
RecoverKit has no telemetry, no analytics, no update check, and no network access other than what you explicitly ask it to do. Nothing leaves your machine. This is a design commitment, not a current-version detail — it is what keeps the people who run this tool solely responsible for the data they process, and keeps this project out of that relationship entirely.