Phone data · recovery & forensics guide

Get the data off the phone. Lawfully, and the honest way.

How to recover data from a device you are authorized to access - a consenting owner's phone, or a device you hold under lawful authority in a forensic case. Guided acquisition and the method choice, locked and dead devices and the real ceiling, app decoders and deleted messages, iOS vs Android, and the forensic sealing wrapper - each with real situations and exact steps.

in scope, authorized lawful access onlybyte-exact and hashedrecovery + forensic one acquisition

Authorized, in-scope acquisition only. Every method on this page is for a device that is IN SCOPE and that you are LAWFULLY AUTHORIZED to access - a consenting owner's phone in a recovery job, or a device held under a warrant, court order or written consent in a forensic case. The purpose is to RECOVER data, for a recovery job or a forensic examination, and nothing else. Every locked-device job records the operator's stated authority and the case reference before it runs; the product never asserts ownership, never acts outside the authority you record, and states plainly where no lawful software route exists rather than promising one.

Feature 1 · Guided acquisition

Get the data off the phone - the right method, chosen for you

Shared by RecoverYantra Mobile and the SakshyaYantra Mobile Workbench: a method registry that reads the real device state and picks the route that fits, byte-exact and hashed, honest about what it cannot reach.

1How to get there

Home›Mobile acquisition
The mobile acquisition workspace
  1. 1Connect / probe reads the real device state; never assumes reachability.
  2. 2Method registry each method with the devices it reaches and what it needs.
  3. 3Authority + case id the authority / case gate for a locked-device job.
app-mobile.webp - the acquisition screen (device-probe state; a real phone populates the method list)

2Which method, and what you get back

Try everything (automatic)
Runs the method sequence for the detected device and stops at the first that works.
Choose this when you are not sure which method fits - let the registry pick and report what it reached.
Pick a method (manual)
Runs one named method - checkm8, EDL/firehose, MTK BROM, ADB, AFC, backup.
Choose this when you know the device and the vector, or you must document one specific route.
File-system vs logical vs physical
The state you get back: full physical bytes, a file-system copy, or a logical backup.
Choose this when physical when the vector allows it and you need deleted data; logical/backup when that is all the device permits.

The honest ceiling. The tool never fakes a capability. A locked device it cannot open says which method WOULD reach it and what that needs; where nothing public can (a modern locked iPhone with no available vector) it says so plainly rather than pretending.

3Step by step

  1. Connect the device and probe
    The tool reads the real state. A locked device that a method cannot reach says so, with the reason.
  2. Record authority and the case id
    A locked-device job records the operator's stated authority; the tool never asserts ownership.
  3. Choose Try-everything or a method
    Automatic walks the sequence; manual runs one route you can document.
  4. Acquire - byte-exact and hashed
    The image is verified by reading it back; a short image is reported failed, never handed over whole.
  5. Recover or examine the image
    Hand the extraction to the recovery flow (photos, messages) or seal it in a forensic case.

4Situations, and exactly what to do

1 of 10

Photos after a factory reset

An Android was reset; the owner wants the camera roll.

What to choose

Acquire a physical image if the vector allows, then carve the userdata for photos.

Steps
  1. Connect + probe
  2. Try-everything acquisition
  3. Recover from the image (Photos)
  4. Export
recoveryantra phone --acquire-all --out phone.img
2 of 10

Deleted messages

SMS / WhatsApp messages were deleted on a rooted phone.

What to choose

Acquire, then the app decoders read deleted rows from the WAL and superseded pages.

Steps
  1. Acquire the image
  2. Run the app decoders
  3. Read deleted-row results
  4. Export to CSV
recoveryantra phone --store messages.db --deleted
3 of 10

Locked, lawful, for evidence

A seized iPhone is locked; the acquisition must be sealed.

What to choose

Record authority, use the method the device's chip allows, and seal it in a case.

Steps
  1. Record authority + case id
  2. Pick the method the registry offers
  3. Acquire (hashed)
  4. Seal in the forensic case
recoveryantra phone --acquire-method checkm8 --case CASE-01
Feature 2 · Choosing the acquisition method

checkm8, EDL, BROM, ADB or backup - the right route for this exact device

Every method the Mobile Workbench carries, honestly labelled: what it reaches, what it needs, and the state it hands back. Nothing here claims more than the device in front of you allows.

1How to get there

Home›Mobile acquisition›Method
The mobile acquisition method picker
  1. 1Case ID the case reference, required before any locked-device method runs.
  2. 2Authority / consent the lawful basis or consent reference for this specific device.
  3. 3Method + ceiling the method, the state it yields (physical / file-system / logical / backup) and what it needs.
app-mobile-methods.webp - the method picker with capability status and the authority attestation (device-absent state)

2The methods, what they reach, what they need

OptionWhat it doesWhat to choose
checkm8 (iOS)A public BootROM acquisition method; a near-full file-system image even locked (before first unlock), on the chips it reaches.A5 to A11 (iPhone 4S through iPhone X). A12 and later are not vulnerable and the plan says so.
Qualcomm EDL / firehose (Android)9008 mode dumps raw flash once a signed firehose loader is supplied.A Qualcomm chipset with a loader the case can lawfully use. No loader means no proceeding, and the tool says so rather than guessing.
MediaTek BootROM (mtkclient)Dumps partitions through the MediaTek BootROM acquisition route on the chipsets it reaches, locked or powered off.A locked or dead MediaTek phone. No root needed on a chipset the method reaches.
Samsung download modeThe vendor's own flashing mode, used to reach partitions on a Samsung device that will accept it.A Samsung phone you can put into download mode; the state it yields depends on the model and what the mode permits.
ADB physical (rooted)dd's the userdata partition to a raw image over ADB once the phone is rooted and USB debugging is on.A rooted Android with debugging enabled - the full physical route, including deleted data.
ADB backup / AFC + iOS lockdown backupA logical backup: app data the platform is willing to export, not raw storage.A non-root Android or an iPhone with no vulnerable chip - the honest floor when nothing deeper applies.

Never a guess. An unknown chipset is never assumed to be vulnerable. The plan is built from the device's own identifiers - a DFU serial, a BootROM/preloader mode, an Android descriptor - and states plainly when nothing in this build reaches it.

3Step by step

  1. List what this build carries
    In-house protocol, a detected external tool, or a licensed capability package - each with its real certification state.
  2. Rank the methods for THIS device
    From the device's own identifiers (an iOS DFU serial or an Android descriptor), before anything is touched.
  3. Run one named method
    Behind the same lawful-use gate as every forensic acquisition; a build without full mobile acquisition refuses by naming the product.
  4. Verify a licensed package before it runs
    Ed25519 signature and payload hashes checked against the signed manifest; a tampered or wrong-key package is refused outright, never partially installed.
  5. Write the hashed manifest
    The method, its provenance, and (for a licensed package) the authority that unlocked it all travel with the image.

4Ten situations, and exactly what to do

1 of 10

iPhone 8 in DFU mode

A seized iPhone 8 answers CPID:8015 in DFU mode.

What to choose

checkm8 applies to A11 and earlier; the plan reports a proto-proven route needing the physical device and the loader tool.

Steps
  1. Read the DFU identifiers
  2. Rank methods for this device
  3. Run checkm8
  4. Hash and seal the image
recoveryantra phone --plan "CPID:8015 ECID:001A70"
2 of 10

A modern flagship, no public vector

The same case includes a current-generation Android on a modern chipset.

What to choose

No public method reaches it. The plan names a licensed capability package as the only route rather than pretending one exists.

Steps
  1. List methods for the device
  2. See the honest refusal
  3. Check the licensed-package route
  4. Record the outcome in the case
recoveryantra phone --methods
3 of 10

MediaTek phone, locked and off

A budget Android on a MediaTek chipset will not power on.

What to choose

MediaTek BootROM dump reaches it locked or off, no root required, on a vulnerable chipset.

Steps
  1. Identify the chipset from the BootROM/preloader mode
  2. Run the MediaTek method
  3. Recover from the dump
  4. Report the method used
recoveryantra phone --acquire-method mtk-brom --case CASE-04 --dest D:\Acq
4 of 10

Qualcomm phone, no loader available

A Qualcomm device sits in EDL (9008) mode but no signed firehose loader is in hand.

What to choose

EDL needs a loader the case can lawfully use. Without one the method is refused with the reason, not attempted.

Steps
  1. Confirm the device is in EDL mode
  2. Check for a lawful loader
  3. If none, name the refusal in the plan
  4. Reconsider once a loader is available
recoveryantra phone --plan qualcomm-edl
5 of 10

Samsung device in download mode

A Samsung phone is put into Odin/download mode for acquisition.

What to choose

The vendor mode reaches what it reaches for that model; the plan states the resulting state honestly rather than assuming full-physical.

Steps
  1. Put the device into download mode
  2. Run the Samsung method
  3. Read the state it actually yielded
  4. Recover from the result
recoveryantra phone --acquire-method samsung-download --case CASE-05
6 of 10

Rooted Android, straightforward

A consenting owner's phone is already rooted with debugging on.

What to choose

ADB physical - the full route, including deleted data, with no low-level method needed.

Steps
  1. Confirm root and USB debugging
  2. Run ADB physical acquisition
  3. Recover the image
  4. Export
recoveryantra phone --acquire-method adb-dd --dest D:\Acq
7 of 10

Non-root Android, owner consents

A family member's Android has never been rooted.

What to choose

ADB logical backup - allowed app data only, no deleted recovery; the honest floor for this device.

Steps
  1. Confirm consent
  2. Run the ADB backup method
  3. Extract app data
  4. Report what could not be reached
recoveryantra phone --acquire-method adb-backup --dest D:\Acq
8 of 10

iPhone with device trust already granted

An iPhone has previously trusted this computer.

What to choose

AFC + iOS lockdown backup - a logical backup; more comes out if the backup is encrypted with a known passcode.

Steps
  1. Confirm trust and unlock state
  2. Run the iOS backup method
  3. Parse Manifest.db and the stores
  4. Export
recoveryantra phone --acquire-method ios-backup --dest D:\Acq
9 of 10

A dead, physically damaged handset

A phone will not power on and the board is damaged.

What to choose

Chip-off / JTAG / ISP - hardware extraction done off-tool; the resulting dump is recovered here.

Steps
  1. Send the board for hardware extraction
  2. Receive the raw dump
  3. Recover from the dump
  4. Report the acquisition method as hardware
recoveryantra recover --image chipoff.dump -o D:\Case --profile forensic
10 of 10

Auditing a licensed package before use

A vendor capability package arrives for a case that may need it.

What to choose

Verify the package's signature and payload hashes before it ever touches a case machine.

Steps
  1. Receive the .sypkg file
  2. Verify signature and hashes
  3. Install only if it passes
  4. Record the package version in the manifest
recoveryantra phone --package-verify vendor-pack.sypkg

5The same job at the command line

recoveryantra phone --plan "CPID:8015 ECID:001A70"
Feature 3 · Locked and dead devices

The honest ceiling - what software can and cannot reach

Before first unlock or after, a vulnerable chip or none: the state decides what is possible, and the plan is built from the device's own identifiers, never a guess about the model.

1How to get there

Home›Mobile acquisition›Locked or dead device
The full locked-device acquisition framework
  1. 1Why? an explanation of why a route is or is not available - never a bare code.
  2. 2Route for deleted content where deleted material would come from, if this device allows it.
  3. 3Full acquisition (Forensic Suite) the full method framework, gated to the Forensic Suite and the Suite's own mobile workspace.
app-mf-mobile-modal-framework.webp - checkm8 / EDL / MediaTek BROM / rooted ADB / backup, each with its ceiling (no device connected on this bench)

2The state the device is in decides what is possible

Before first unlock (BFU)
Storage stays encrypted until the device has been unlocked once since it last restarted.
Choose this when a device arrives locked and has not been unlocked since power-on - most software routes reach nothing yet.
After first unlock (AFU)
The device has been unlocked at least once since restart, so more methods and more data become reachable.
Choose this when the device is locked now but was used earlier - state this explicitly, it changes what the plan can offer.
No public vector
The chip or platform version this device carries has no known public acquisition vector.
Choose this when a modern flagship with no vulnerable chip - the plan names the licensed capability package as the only route, or says none exists.

The honest ceiling. A locked modern handset's passcode is not recoverable by software. That is a silicon and hardware-laboratory question, and the product says so rather than promising a route that does not exist. checkm8 reaches A5 through A11 only; A12 and later carry no known public vector.

3The commands that establish the ceiling

OptionWhat it doesWhat to choose
--ffs-dfuFrom an iPhone's own DFU identifiers, establishes whether a full-filesystem acquisition is possible before anything is promised.Before quoting a case involving an iPhone. The answer for a modern handset is often no, and the plan says so plainly.
--android-ffsThe same question for Android, from the device descriptor.Before promising a physical acquisition on an Android device of unknown chipset.
--package-installInstalls a signed capability package under counsel's agreement, after verifying it.Only once a package has been verified; a tampered or wrong-key package contributes nothing to the method registry.
--package-listLists installed capability packages that still verify.Before a case, to confirm which licensed routes are actually available on this bench today.
--cloud-tokensScans a lawfully acquired artefact for cloud account tokens and returns the lawful route to the provider.When cloud data may hold what the device does not. Finding a token is never authority to use it; follow the lawful route instead.

4Ten situations, and exactly what to do

1 of 10

iPhone locked, never unlocked since seizure

The device was seized powered on and has not been unlocked since.

What to choose

BFU state. Check the chip against checkm8's reach before promising a filesystem image.

Steps
  1. Read the DFU identifiers
  2. Run --ffs-dfu
  3. If vulnerable, checkm8 reaches it locked
  4. If not, state the ceiling and name the licensed route
recoveryantra phone --ffs-dfu "CPID:8015 ECID:001A70 SRTG:[..]"
2 of 10

iPhone 14, no public vector

A current-generation iPhone with no known public BootROM vector.

What to choose

Name the licensed capability package as the only route, or state plainly that none is installed.

Steps
  1. Run --ffs-dfu
  2. Read the honest refusal
  3. Check --package-list for an applicable route
  4. Record the outcome
recoveryantra phone --package-list
3 of 10

Dead Android, will not power on

A phone with a damaged board or dead battery will not boot at all.

What to choose

Not a software question. Chip-off, JTAG or ISP extraction is the route, done off-tool.

Steps
  1. Confirm the device will not power on by any means
  2. Send the board for hardware extraction
  3. Recover from the resulting dump
  4. Report the method as hardware
recoveryantra phone --android-ffs unknown
4 of 10

Android with file-based encryption, unrooted

A modern Android with FBE and no root, no vulnerable chip.

What to choose

Storage stays encrypted until the first unlock after restart. State this plainly rather than attempting a read that will fail.

Steps
  1. Establish rooted status
  2. Establish AFU/BFU state
  3. If BFU and unrooted, state the ceiling
  4. If AFU, attempt the reachable logical route
recoveryantra phone --android-ffs "<descriptor>"
5 of 10

Unknown chipset, case just opened

The device model is known but the exact chipset revision is not yet confirmed.

What to choose

Never assume vulnerability from the model name. Read the real identifiers first.

Steps
  1. Read the BootROM/preloader/DFU identifiers off the device itself
  2. Run --ffs-dfu or --android-ffs
  3. Act only on the measured answer
  4. Record what was read, not assumed
recoveryantra phone --methods
6 of 10

An examiner wants to try an advanced method

A case may benefit from a method that can alter the device.

What to choose

Advanced methods are off until an examiner opts in, on the record, for this case.

Steps
  1. Record authority, operator, case reference
  2. Opt the method in explicitly
  3. Run it, with the opt-in on the audit trail
  4. Disable it again once the step is complete
recoveryantra capabilities --enable checkm8 --operator "A Sharma" --case FIR-4471
7 of 10

Android unlocked earlier today, now locked

The screen is locked now but the phone was used and unlocked hours ago.

What to choose

AFU state. More is reachable than a device that has never been unlocked since restart.

Steps
  1. Establish AFU state from the case notes or the device itself
  2. Attempt ADB physical if rooted, backup if not
  3. Recover from what is reached
  4. State the ceiling for anything not reached
recoveryantra phone --acquire-method adb-dd --case CASE-07
8 of 10

Qualcomm device, licensed loader available

A case has an applicable licensed capability package for this chipset.

What to choose

Verify and install the package, then run EDL through it, with the authority recorded.

Steps
  1. Verify the package
  2. Install it
  3. Run the EDL method through the package
  4. Record the package version and authority in the manifest
recoveryantra phone --package-install vendor-pack.sypkg
9 of 10

A phone that 'worked yesterday' now bootloops

The device powers on partially but never reaches a usable screen.

What to choose

Triage before choosing a method - a bootloop is a different problem from a locked screen.

Steps
  1. Observe the boot behaviour
  2. Check for a known BootROM/DFU mode regardless of the bootloop
  3. Choose the method that state actually allows
  4. Avoid a route that risks making it worse
recoveryantra phone --methods
10 of 10

Confirming a device's special USB mode before touching it

A phone connected via USB shows an unfamiliar vendor/product id.

What to choose

Identify EDL, MediaTek BootROM, Apple DFU, fastboot or Samsung download mode before running anything.

Steps
  1. Read the USB vendor/product id
  2. Match it against the known special modes
  3. Choose the method that mode supports
  4. Proceed only once the mode is confirmed
recoveryantra phone --methods
Feature 4 · Create a phone image

Read the phone once, work from the image afterwards

For a rooted Android that trusts this computer: streams the partition to an image file, verified by length, so every recovery pass runs against the copy instead of the handset.

1How to get there

Home›Create a phone image
Create a phone image
  1. 1Why? the honest explanation when no rooted or consenting phone is connected.
  2. 2Open Phone opens the mobile acquisition workspace for a locked or non-root device instead.
  3. 3Check again re-checks the connection - useful once the phone is unlocked and USB debugging is on.
app-mobile-phoneimage.webp - the honest 'no rooted or consenting phone connected' state

2What it needs, and what it checks

OptionWhat it doesWhat to choose
Where to saveThe destination for the image file - a drive with room for the whole partition.Always a separate drive with free space measured against the partition size before the copy starts.
USB debugging + unlocked since restartThe two conditions the copy needs; without them storage stays encrypted and unreadable.Confirm on the phone before starting. A locked phone lists fine over USB and still reads nothing.
Length verificationThe finished image is compared against the partition size the phone reported.Always on. A short image (a dropped cable, a sleeping phone) is reported failed, never handed over as whole.

3Step by step

  1. Connect the phone
    USB debugging on, and unlocked at least once since it was last restarted.
  2. Choose where to save
    A drive with room for the whole partition; the pre-flight checks free space first.
  3. Copying
    Streamed in blocks with a live figure and a stop that stops.
  4. Done - hand off to recovery
    The image goes into the ordinary recovery flow: Smart mode reads the filesystem and carves the rest.

What this is for. This copies a rooted or consenting Android's storage to an image file so the phone is read once instead of repeatedly. A locked, unrooted phone, or an iPhone, is not a raw-image device this way - the workspace says so and points at mobile acquisition instead.

4Ten situations, and exactly what to do

1 of 10

Rooted Android before a deep recovery

A rooted phone needs its userdata partition read once, thoroughly.

What to choose

Image the partition first, then run every recovery pass against the image, not the phone.

Steps
  1. Connect, confirm root and debugging
  2. Choose the destination
  3. Copy the partition
  4. Recover from the image with Smart mode
recoveryantra recover --image phone.img -o D:\Rec --mode smart
2 of 10

Phone locked since the last restart

The device lists over USB but has not been unlocked since it last powered on.

What to choose

Storage stays encrypted until the first unlock after restart. Unlock it once, then image.

Steps
  1. Connect the phone
  2. See the honest 'locked since restart' state
  3. Unlock the phone once
  4. Check again, then image
3 of 10

Large partition, limited destination space

The phone's userdata partition is larger than the free space on the chosen drive.

What to choose

The pre-flight measures the partition size against free space before starting, and refuses rather than filling the drive mid-copy.

Steps
  1. Connect the phone
  2. Choose a destination
  3. See the space check
  4. Pick a drive with enough room
4 of 10

The cable drops mid-copy

A USB connection is interrupted while the image is being written.

What to choose

The copy compares its length against the reported partition size; a short result is reported failed, never handed over as whole.

Steps
  1. Copying begins
  2. Connection drops
  3. The result is reported failed, not partial-complete
  4. Reconnect and image again
5 of 10

Non-rooted phone offered for imaging

An unrooted Android is connected and imaging is attempted anyway.

What to choose

A raw partition image needs root. The workspace states this and offers the mobile acquisition workspace instead.

Steps
  1. Connect the phone
  2. See the honest refusal naming root as the requirement
  3. Open the mobile acquisition workspace
  4. Use ADB backup or the method registry instead
6 of 10

iPhone offered where a raw image is not the route

An iPhone is connected to the same workflow.

What to choose

iOS does not yield a raw partition image this way. AFC and the iOS backup route apply instead.

Steps
  1. Connect the iPhone
  2. See the honest 'not a raw-image device' state
  3. Open the mobile acquisition workspace
  4. Run AFC + iOS lockdown backup
7 of 10

Imaging once, reading many times

Several recovery passes are planned against the same phone.

What to choose

Read the phone once into an image; every subsequent pass runs against the image, not the handset.

Steps
  1. Image the partition once
  2. Run Smart mode recovery
  3. Run a targeted carve if needed
  4. Never reconnect the phone for each pass
recoveryantra recover --image phone.img -o D:\Rec --include-intact
8 of 10

Checking free space before a long copy

A large partition is about to be imaged to an external drive.

What to choose

The destination step states free space against the measured partition size before Copying starts.

Steps
  1. Connect the phone
  2. Choose the destination
  3. Read the free-space figure
  4. Proceed only once it clears
9 of 10

The phone sleeps mid-session

The screen locks itself partway through connecting.

What to choose

The same encrypted-until-unlock rule applies; wake and unlock it, then Check again.

Steps
  1. Connect the phone
  2. Screen locks itself
  3. Wake and unlock the phone
  4. Check again to re-probe
10 of 10

Handing the image to a forensic examination instead

The image is needed for a case, not a customer handover.

What to choose

The same image file feeds either flow; choose the forensic profile when it goes into a case.

Steps
  1. Image the partition
  2. Open the Forensic Suite's case workbench
  3. Add the image as an exhibit
  4. Continue under the sealing wrapper
recoveryantra recover --image phone.img -o D:\Case --profile forensic
Feature 5 · App decoders and deleted messages

Read the app's own store - including what was deleted

Per-application decoders for SMS, WhatsApp, contacts and more, reading live rows and recovering deleted ones from the write-ahead log and superseded database pages, always flagged as deleted.

1How to get there

Home›Mobile acquisition›App decoders
Reading pulled app stores, including deleted rows
  1. 1Files deleted from the phone the route to run when files or messages were deleted, not just lost with the phone.
  2. 2You already have a backup decode an existing backup or pulled store without reconnecting the device.
  3. 3Why? the honest explanation of what this app's data allows.
app-mf-mobile.webp - the Mobile Workbench connect screen; the app decoders run against a store already pulled or acquired

2The options, and what to choose

OptionWhat it doesWhat to choose
--storePoints at a single database or file already pulled off a handset.When you already know which application's data you need.
--leveldbReads a LevelDB folder or a single .log file, for Chrome, Electron chat apps and browser local storage.Only the write-ahead log is read; data already compacted into .ldb table files is a stated limit, not everything the store held.
--deepMines a whole pulled phone folder for deleted material: trash, deleted database rows, thumbnails of photographs no longer present.When deleted material matters. It takes considerably longer than reading one store, and recovered rows are flagged as such.
--appForces a profile when auto-detection picks the wrong one.A renamed or unusually located database that the automatic match misses.
--keySupplies the key for an encrypted store - a WhatsApp key file, or a hex key for SQLCipher.Required for an encrypted store. Without the key the store cannot be read, and the product says so rather than returning partial output.
--breadth / --platformRuns the signed iLEAPP (ios) or ALEAPP (android) toolpack over an extraction for the long tail of apps.When a case needs wider coverage than the in-house decoders. Rows are labelled as the tool's own, shown as corroboration.

3Step by step

  1. Pull or acquire the store
    A single database, a LevelDB folder, or a whole pulled phone folder.
  2. Point the decoder at it
    --store for one database, --deep for a whole folder, --key for anything encrypted.
  3. Read deleted rows honestly
    A deleted row that survives in the write-ahead log or a superseded page comes back whole and flagged deleted; a fragment without its headers is returned as recovered text, not a reconstructed message.
  4. Widen coverage if needed
    Run the breadth tool for the app list beyond the in-house decoders, labelled as its own findings.
  5. Export
    Messages, contacts and call history export in a form that can actually be used, not a private format.

How deleted rows are handled. A deleted row that survives in a write-ahead log or a superseded page comes back whole and is flagged deleted. A fragment with its headers gone is returned as recovered text, never welded back into an invented message.

4Ten situations, and exactly what to do

1 of 10

Deleted WhatsApp messages

WhatsApp messages were deleted on a rooted phone.

What to choose

Supply the key file and read the store's deleted rows alongside the live ones.

Steps
  1. Acquire the phone
  2. Locate the WhatsApp key file
  3. Run the decoder with --key
  4. Export flagged as deleted where recovered
recoveryantra phone --app whatsapp --key wa.key --store msgstore.db.crypt14 --deleted-only
2 of 10

SMS deleted from the message store

Text messages were deleted from an Android's SMS database.

What to choose

Read mmssms.db directly and show only the deleted rows.

Steps
  1. Pull the database
  2. Run the decoder
  3. Filter to deleted-only
  4. Export
recoveryantra phone --store mmssms.db --deleted-only
3 of 10

A deleted contact, recovered whole

A contact was deleted from an Android address book.

What to choose

The phone runs in WAL mode: the superseded page still holding the deleted row is read, giving back the whole contact.

Steps
  1. Pull the contacts database and its WAL file
  2. Run the decoder
  3. Confirm the row source is a superseded page
  4. Export to vCard
recoveryantra phone --store contacts2.db --deleted-only
4 of 10

A Chrome-based app's local storage

A chat app built on Electron stores its data in LevelDB, not SQLite.

What to choose

Read the write-ahead .log file; note the stated limit that already-compacted .ldb data is not covered.

Steps
  1. Locate the LevelDB folder
  2. Run the decoder with --leveldb
  3. Read the recovered log entries
  4. Note the compacted-data limit in the report
recoveryantra phone --leveldb chrome_local\000003.log
5 of 10

Mining a whole pulled folder

A full pulled phone folder is available and deleted material across several apps matters.

What to choose

Deep mining walks trash folders, deleted rows and orphaned thumbnails across the whole folder.

Steps
  1. Pull the phone folder
  2. Run --deep against it
  3. Review the flagged deleted results
  4. Export by app
recoveryantra phone --deep D:\PulledPhone
6 of 10

Auto-detection picks the wrong app profile

A renamed database is misidentified by automatic matching.

What to choose

Force the correct profile by name.

Steps
  1. Run the decoder and see the wrong match
  2. Identify the real app
  3. Re-run with --app set explicitly
  4. Confirm the fields now parse correctly
recoveryantra phone --store data.db --app signal
7 of 10

Widening coverage past the in-house decoders

A case needs artefacts from an app the in-house decoders do not cover.

What to choose

Run the signed breadth toolpack over the extraction and treat its rows as corroboration.

Steps
  1. Complete the core extraction
  2. Run the breadth tool for the platform
  3. Review its rows alongside the in-house findings
  4. Label the source of each row
recoveryantra phone --breadth D:\Extraction --platform ios
8 of 10

Apps that are honestly not locally recoverable

Snapchat, Instagram and Signal content is expected among the recoverable apps.

What to choose

These are named as not locally recoverable - ephemeral, server-side, or encrypted - and scoped out of the quote rather than attempted.

Steps
  1. Run --areas to scope the case
  2. See these apps named as not locally recoverable
  3. Explain the reason to the customer
  4. Scope the quote to what is actually reachable
recoveryantra phone --areas
9 of 10

A serialised blob with no surviving headers

A Telegram-style store yields printable text with its structure gone.

What to choose

Reported as recovered text, not a reconstructed message - inventing a decoded structure from a fragment is not attempted.

Steps
  1. Run the decoder against the store
  2. See the result labelled as recovered text, not a message
  3. Review the text manually
  4. Note the honest limit in the report
10 of 10

Exporting recovered contacts for reuse

Recovered contacts, live and deleted, need to go into another system.

What to choose

Export to vCard so the result is directly importable, not a private database format.

Steps
  1. Run the contacts decoder
  2. Confirm live and deleted rows are both present
  3. Export to vCard
  4. Hand the file to the customer or the case
Feature 6 · iOS vs Android extraction

The platform decides the route - never guessed, always read from the device

iOS speaks the phone's own pairing, lockdown and AFC protocols; Android goes through ADB or a chipset-specific vendor mode. Root and trust state decide how much of each comes back.

1How to get there

Home›Mobile acquisition›iOS or Android
iOS and Android take different routes to the same job
  1. 1Case ID one case reference, whichever platform the device turns out to be.
  2. 2Operator / organisation the operator and organisation recorded against the acquisition.
  3. 3Method list, filtered by platform the method list narrows to what actually applies to the connected platform.
app-mobile-methods.webp - the method picker; the platform decides which protocols and which methods apply

2Which route, and why they differ

iOS route
usbmux pairing, lockdown and AFC for a logical pull; checkm8 for a physical image on A5-A11 chips.
Choose this when the device is an iPhone or iPad. A12 and later have no public physical route; the backup route is the floor.
Android route
ADB for a rooted physical image or a logical backup; EDL, MediaTek BootROM or Samsung download mode for a locked or dead device on a reachable chipset.
Choose this when the device is Android. Root and debugging state decide between a physical and a logical result.
A mixed case
Both platforms are acquired under the same case reference, each through its own route.
Choose this when a case includes more than one handset - a household, a small business, a shared investigation.

3The options on each platform

OptionWhat it doesWhat to choose
iOS: AFC + iOS lockdown backupReads what the device's own backup protocol will hand over; an encrypted backup with a known passcode exposes more.An iPhone or iPad with device trust already granted, or granted during connection.
iOS: checkm8A near-full filesystem image even locked, on A5-A11 chips only.A vulnerable iPhone where a physical result matters more than a logical backup.
Android: ADB physical / backupFull dd image if rooted and debugging is on; otherwise a logical backup of allowed app data.Root state decides which of the two you get - check it before promising a physical result.
Android: EDL / BROM / download modeChipset-specific routes for a locked or dead device that ADB cannot reach.The device is locked or will not boot, and its chipset matches one of these vendor modes.
--breadth --platform ios|androidRuns the matching breadth toolpack (iLEAPP or Android's ALEAPP) since the two read different artefact layouts.Set the platform correctly - the wrong one reads the wrong layout and returns nothing useful.

4Ten situations, and exactly what to do

1 of 10

iPhone with an existing local backup

The owner already made an unencrypted local backup on a computer.

What to choose

Parse the existing backup directly; no need to reconnect the device.

Steps
  1. Locate the backup folder
  2. Run the iOS backup decoder against it
  3. Review Manifest.db and the stores
  4. Export
recoveryantra recover --ios-backup "C:\Users\me\Apple\MobileSync\Backup\xxxx" -o D:\PhoneRecovery
2 of 10

iPhone never paired with this computer

The device has no established trust relationship yet.

What to choose

Connect and approve the trust prompt on the phone's own screen before AFC can read anything.

Steps
  1. Connect the iPhone
  2. Approve trust on the device
  3. Confirm the pairing completed
  4. Run the iOS backup method
3 of 10

Rooted Android, straightforward physical

A consenting owner's Android is rooted with debugging on.

What to choose

ADB physical is the full route here; check root before promising it.

Steps
  1. Confirm root and debugging
  2. Run ADB physical
  3. Recover from the image
  4. Export
recoveryantra phone --acquire-method adb-dd --dest D:\Acq
4 of 10

Android in fastboot/bootloader mode

The device shows a bootloader screen rather than booting normally.

What to choose

Identify the USB mode before choosing a route - fastboot is a different state from EDL or BROM.

Steps
  1. Read the USB vendor/product id
  2. Confirm it as fastboot
  3. Choose the method that mode supports
  4. Proceed accordingly
5 of 10

iPhone in DFU restore mode

The device is held in DFU mode to check checkm8 eligibility.

What to choose

Read the CPID/ECID and rank methods before doing anything else.

Steps
  1. Put the device into DFU mode
  2. Read CPID/ECID
  3. Run --ffs-dfu
  4. Act on the honest answer
recoveryantra phone --ffs-dfu "CPID:8015 ECID:001A70"
6 of 10

One case, two phones, two platforms

A household case includes an iPhone and an Android under one investigation.

What to choose

Acquire each through its own route, under the same case reference.

Steps
  1. Record the case reference once
  2. Acquire the iPhone via its route
  3. Acquire the Android via its route
  4. Review both under the one case
7 of 10

An iPad, treated the same as an iPhone

The device is an iPad rather than a phone.

What to choose

The same AFC/backup and checkm8 routes apply; the platform is iOS, not the form factor.

Steps
  1. Connect the iPad
  2. Approve trust
  3. Run the iOS route that fits its chip
  4. Export
8 of 10

Non-root Android tablet, media only

A tablet is not rooted and USB debugging was never enabled.

What to choose

MTP media copy is the floor: user-visible files only, no deleted recovery, no raw image.

Steps
  1. Connect over MTP
  2. Copy visible media files
  3. State the limit plainly
  4. Suggest enabling debugging for anything deeper
9 of 10

iOS backup with no passcode set

The device's local backup was never encrypted.

What to choose

Fewer artefacts survive in an unencrypted backup than in one protected with a known passcode.

Steps
  1. Run the iOS backup route
  2. Note the backup is unencrypted
  3. Extract what is present
  4. State what an encrypted backup would have added
10 of 10

Deciding which breadth tool to run

Core extraction is complete for both an iPhone and an Android in the same case.

What to choose

Run iLEAPP against the iOS extraction and ALEAPP against the Android one - never the other way round.

Steps
  1. Complete core extraction on each device
  2. Run --breadth --platform ios on the iPhone extraction
  3. Run --breadth --platform android on the Android extraction
  4. Label rows by their source
recoveryantra phone --breadth D:\Extraction --platform android
Feature 7 · The forensic sealing wrapper

From acquisition to exhibit - case, chain of custody, the certificate

The Mobile Workbench's evidentiary layer: every acquisition can become a locked, hashed exhibit with its own Section 63(4) certificate, while the same acquisition remains available unsealed for an ordinary customer recovery.

1How to get there

Home›Mobile acquisition›Seal in a case
The case workbench: where an acquisition is sealed as evidence
  1. 1Add an exhibit adds the acquisition to the case as a formal exhibit.
  2. 2What's next the next step required to move the case forward.
  3. 3The checklist the tracked checklist of steps this case has and has not completed.
app-mf-mobile-seal.webp - the Mobile Workbench's case workbench (no acquisition to seal on this bench - honest empty case)

2What sealing adds, and when to use it

OptionWhat it doesWhat to choose
Case lock and versionsLocks the case's exhibits against silent edits; a new version is created for anything added afterward.As soon as the first exhibit is sealed - never edit a locked exhibit in place.
Chain of custody manifestA hashed, sealed record of every acquisition step: method, operator, authority, time.Always, for every exhibit that will be relied on in a proceeding.
Section 63(4) certificateThe statutory certificate for electronic evidence under the Bharatiya Sakshya Adhiniyam 2023.Before the case goes to a proceeding - generated from the sealed manifest, never hand-typed.
AI observationsA model's reading of an artefact, labelled and dated, sealed separately from the examiner's own reading.Optional. The examiner's own reading is sealed BEFORE any AI answer is shown, and an AI observation is never promoted to a finding automatically.

Forensic-only, not the acquisition itself. The evidentiary wrapper - case lock, versions, the Section 63(4) certificate, registry intake, AI observations - is a Forensic Suite capability. RecoverYantra Mobile carries the same acquisition and the same honest ceiling, without the sealing wrapper: a customer recovery does not need a court certificate.

3Step by step

  1. Acquire under the method registry
    The same acquisition as every other feature here - byte-exact, hashed, with authority recorded.
  2. Add the result as an exhibit
    The image or extraction enters the case, not a loose file on a desk.
  3. Lock the case
    Exhibits are sealed against silent edits; anything added afterward creates a new version.
  4. Generate the certificate
    The Section 63(4) certificate is built from the sealed chain-of-custody manifest.
  5. Hand the case pack to whoever needs it next
    Another examiner, counsel, or the court - the pack carries its own record of how it was made.

4Ten situations, and exactly what to do

1 of 10

Sealing a fresh acquisition into a new case

A phone has just been acquired and needs to become part of a formal case.

What to choose

Create the case, add the acquisition as an exhibit, then lock it.

Steps
  1. Open or create the case
  2. Add the acquisition as an exhibit
  3. Confirm the checklist step completes
  4. Lock the case
2 of 10

A second exhibit joins the same case

The same investigation also seized a laptop.

What to choose

Add the laptop's image to the same case reference; each exhibit keeps its own chain of custody.

Steps
  1. Open the existing case
  2. Add the laptop image as a second exhibit
  3. Confirm both exhibits are listed
  4. Continue the examination
3 of 10

Producing the certificate for court

A case is ready to be submitted as evidence.

What to choose

Generate the Section 63(4) certificate from the sealed manifest, not typed by hand.

Steps
  1. Confirm the case is locked
  2. Generate the certificate
  3. Review it against the manifest
  4. Include it in the case pack
4 of 10

Recording operator authority against the case

The examiner's lawful basis for the acquisition needs to be on the record.

What to choose

Operator, authority and organisation are recorded once and carried through every exhibit in the case.

Steps
  1. Enter operator and organisation
  2. Enter the lawful authority reference
  3. Confirm it is attached to the case
  4. Proceed to acquisition
5 of 10

An AI observation on a recovered message

A model is asked to summarise a decoded conversation.

What to choose

The examiner's own reading is sealed first; the AI's answer is labelled an observation, never promoted automatically.

Steps
  1. Seal the examiner's own reading
  2. Ask the model
  3. Review the AI observation, labelled as such
  4. Promote it only through a typed reviewer decision, if at all
6 of 10

A recorder joins a phone case

The same investigation includes CCTV footage alongside the phone.

What to choose

Registry intake brings the recorder's format and export into the same case as a separate exhibit.

Steps
  1. Run recorder intake for the CCTV export
  2. Add it as an exhibit in the case
  3. Confirm both exhibits share the case reference
  4. Continue the examination
7 of 10

Reviewing before showing an AI answer

A finding is being drafted from decoded message content.

What to choose

The examiner's own reading is sealed before any AI answer is shown, so the human reading is never anchored by the model.

Steps
  1. Read the recovered material
  2. Seal the examiner's own notes
  3. Only then ask the model
  4. Compare, do not overwrite
8 of 10

A recovery-only acquisition, deliberately not sealed

A customer's own phone is being recovered, not investigated.

What to choose

The RecoverYantra Suite acquires the same way but does not carry the evidentiary wrapper - no case lock, no certificate.

Steps
  1. Acquire through the recovery family's mobile workspace
  2. Recover the files
  3. Export directly to the customer
  4. No sealing step exists in this product
9 of 10

Case versioning after new evidence arrives

A locked case needs a third exhibit added weeks later.

What to choose

Adding to a locked case creates a new version rather than editing the sealed one.

Steps
  1. Open the locked case
  2. Add the new exhibit
  3. Confirm a new version was created, not an edit
  4. Review what changed between versions
10 of 10

Exporting the case pack for handover

The case needs to move to another examiner or to counsel.

What to choose

Export the pack: exhibits, manifest, certificate and the audit trail, together.

Steps
  1. Confirm the case is locked and the certificate is generated
  2. Export the case pack
  3. Verify the export against the manifest
  4. Hand it over