RecoverYantra Mobile on the command line

Also write the report (HTML, PDF, JSON) into DIR

When to use it. Write the detection report - HTML, PDF and JSON - into this folder: every device with its state, bus, serial and sector size, the hardware Windows can see but cannot use with the code and the fix, and the Plug-and-Play inventory. Use it when a customer or a partner says a drive is not detected: the report replaces "it does not work" with what the machine actually sees.

What it costs. The folder goes through the same pre-flight as every other writing job; the report is small, so only rights and a full disk stop it.

Skip the health read of each usable drive (faster)

When to use it. Skip the health read of each usable drive. Detection is then a listing only and returns in a second or two. Use it on a machine with many drives, or when a drive is known to be failing and you do not want even a test read against it before imaging.

Write the report even if the pre-flight objects

When to use it. Write the report even when the pre-flight objects to the folder. Use it only when you have read the objection and it does not apply - a report is a few hundred kilobytes, so the usual reason is a destination the check cannot judge.

What it costs. A refusal you have not read is not one you can override safely.

Use the classic Tkinter wizard

When to use it. Fall back to the classic interface on a machine where the modern window will not start, typically an old or minimal Windows install.

Show what has been acknowledged on this install

When to use it. Show what lawful-use acknowledgements have been made on this install. Useful when auditing a shared bench machine.

Forget remembered acknowledgements (history is kept)

When to use it. Clear the remembered acknowledgements when a machine changes hands or a new operator takes it over.

What it costs. The history is retained. Resetting does not erase the record of what was previously acknowledged.

A phone SQLite database (mmssms.db, msgstore.db, sms.db, contacts2.db, ...)

When to use it. Point at a single database pulled from a handset when you already know which application's data you need.

Deep-mine a PULLED phone folder for DELETED data (trash, deleted DB rows, thumbnails of purged photos)

When to use it. Run against a whole pulled phone folder when deleted material matters: trash folders, deleted database rows and thumbnails of photographs that are no longer present.

What it costs. Deep mining takes considerably longer than reading one store, and recovered deleted rows are reported flagged as such.

Force a profile (android_sms, android_calls, whatsapp, ios_imessage); auto-detected if omitted

When to use it. Force a profile when auto-detection picks the wrong one, usually on a renamed or unusually located database.

Decryption key for an encrypted store: path to a WhatsApp `key` file, or a hex key (WhatsApp crypt / SQLCipher: Signal, WeChat, Wickr, ...)

When to use it. Supply the key for an encrypted store: a WhatsApp key file, or a hex key for an SQLCipher database.

What it costs. Without the key the store cannot be read. The product does not attempt to break the encryption and will say so rather than returning partial output.

Show only recovered deleted records

When to use it. Narrow the output to recovered deleted records when the live data is already available from the handset or a backup.

Instead of parsing, list the mobile recovery areas (by app + media)

When to use it. Use when scoping. It lists what is recoverable per application and media type, including the areas that are honestly not recoverable locally.

What it costs. Applications listed as not locally recoverable are ephemeral or server-side. Scope them out of the quote rather than promising them.

List recovery by DATA TYPE (Contacts, Messages, Photos, ...) and sources

When to use it. The same scoping question asked by data type: contacts, messages, calls, photographs, and where each comes from.

Identify a checkm8 full-filesystem acquisition from a device's DFU USB serial (e.g. 'CPID:8015 ECID:.. SRTG:[..]') and print the honest, ordered FFS plan

When to use it. Establish whether a full-filesystem acquisition is possible for a specific iPhone before promising one, from the device's own DFU identifiers.

What it costs. The answer for a modern handset is often no, and the plan says so. An unknown chip is never assumed to be vulnerable.

Plan an Android full-filesystem acquisition from a device descriptor (VID:PID and/or 'chipset:SM8250 android:13 bootloader:locked credential:unknown'): SoC, download mode, and the honest FBE boundary

When to use it. The same question for Android, from the device descriptor. Produces a plan gated on what that specific device actually allows.

Scan a lawfully-acquired artifact/file for cloud-account tokens (OAuth refresh/access, JWT) and print the lawful cloud-acquisition route per provider (identify-only)

When to use it. Scan a lawfully acquired artefact for cloud account tokens, and get the lawful route to the provider rather than to the account.

What it costs. Finding a token is not authority to use it. The output is a lawful acquisition route, and it should be followed.

List the full mobile-acquisition method registry (in-house protocol / external tool / licensed seam, state, BFU/AFU, certification, provenance)

When to use it. List every mobile-acquisition method the engine carries: in-house protocol, detected external tool, or licensed capability package; the state it yields, whether it works before first unlock, and its certification (proto-proven vs needing a device to certify).

Rank the acquisition methods that apply to a device: an iOS DFU serial (CPID:.. ECID:..) or an Android descriptor (VID:PID / chipset:.. / adb:device / adb:device+root); honest about what this build offers and, if nothing reaches the device, what WOULD and what it needs

When to use it. Rank the methods that actually apply to a described device (an iOS DFU serial or an Android descriptor) - honest about what THIS build offers, and, when nothing reaches the device, which method WOULD and exactly what it needs.

What it costs. A recovery build lists a physical method as NOT offered rather than hiding it; only the Forensic Suite may run one.

MANUAL acquisition: run ONE method from --methods against a device descriptor (paired with --plan's DESCRIPTOR) into --dest; refused for a build without full mobile acquisition (the recovery family keeps consent-only)

When to use it. Run one named method from --plan's device against --dest. Behind the same lawful-use gate as every forensic acquisition.

What it costs. Refused by naming the PRODUCT when the build lacks full mobile acquisition, and refused structurally (never a fake success) when the physical device, tool or loader it needs was not provided.

AUTOMATIC acquisition: work DOWN the methods that reach this device in order (checkm8 / EDL / MediaTek BROM / rooted ADB / backup), trying each until one succeeds - acquire on the first success, an honest refusal naming what is needed if none reaches it. Needs --plan DESCRIPTOR and --dest

When to use it. Acquire a phone automatically: try every method that reaches the device in order (checkm8, Qualcomm EDL, MediaTek BootROM, rooted ADB, backup) until one succeeds, when you want the tool to work down the options rather than picking one by hand.

What it costs. It runs real acquisition methods against the device and writes the image to the destination; the operator's stated authority is recorded, and a device no public method reaches is refused, never faked.

Destination folder for --acquire-method / --acquire-all

When to use it. Where --acquire-method writes the image or the copied files, and the hashed manifest naming the method, its provenance and (for a licensed package) the authority.

Install a signed capability package (.sypkg) after verifying its signature and every payload file's hash; refused if tampered, expired, or signed by the wrong key

When to use it. Install a signed capability package (.sypkg) - a vendor's licensed loader/exploit chain under counsel's agreement - after verifying its Ed25519 signature and re-hashing every payload file against the signed manifest.

What it costs. A tampered, expired, or wrong-key package is refused outright and contributes nothing to the method registry; it is never partially installed.

Verify a .sypkg file WITHOUT installing it

When to use it. Check a .sypkg file's signature and payload hashes WITHOUT installing it - for auditing a package before it goes anywhere near a case machine.

List installed, currently-verified capability packages

When to use it. List the capability packages currently installed and still verifying (a package that no longer verifies is silently absent from this list, per the module's no-partial-trust rule).

Remove an installed capability package

When to use it. Remove an installed capability package by its package_id, and delete its extracted payload from disk.

Recover key/value records from a LevelDB write-ahead log - the store Chrome, Electron apps (Discord, Slack, WhatsApp Desktop) and browser Local Storage keep. Point it at a `leveldb` folder or a single .log file

When to use it. Point at a LevelDB folder or a single .log file when the data lives in a key/value store rather than SQLite, which is what Chrome, Electron chat apps and browser Local Storage use.

What it costs. Only the write-ahead log (.log) is read; data already compacted into .ldb table files is a stated limit, not everything the store held.

Run a breadth pass over an ALREADY-ACQUIRED extraction folder with the signed mobile toolpack (iLEAPP for iOS, ALEAPP for Android) to widen coverage beyond our own parsers; needs --platform. Does nothing if the toolpack is not installed

When to use it. Point at an already-acquired extraction folder to run the signed toolpack (iLEAPP or ALEAPP) over it and widen coverage past our own parsers, when a case needs the long tail of apps.

What it costs. It does nothing when the toolpack is not installed, and its rows are labelled as the tool's, shown under our own parsers as corroboration.

Which breadth tool to run for --breadth: ios (iLEAPP) or android (ALEAPP)

When to use it. Choose which breadth tool runs on the extraction, ios for iLEAPP or android for ALEAPP, since the two read different artefact layouts.

Examiner asserting lawful authority (recorded)

When to use it. As on acquire: the examiner asserting lawful authority.

Lawful basis: warrant / consent / statutory power

When to use it. As on acquire: the lawful basis for touching this device.

Examiner's organisation (recorded)

When to use it. The examining organisation, recorded against the acquisition so the custody record names the body accountable for it.

Case / FIR reference (recorded)

When to use it. The case reference, set consistently across every step.

The case folder

When to use it. Point at the case folder you want to hand to another tool or lab. `report` exports it in a standardized interchange format rather than a PDF, so an examiner on different software can load the same evidence, timeline and provenance. The case folder is read only.

Export format (default case-uco)

When to use it. Choose the interchange format for the export; today that is CASE-UCO, the community standard the major forensic tools read, so findings travel to another examiner without being retyped. Leave it at the default unless a receiving lab asks for a specific one.

Path to write the export to

When to use it. Where to write the exported file. Choose a path outside the case folder and the evidence drive so the export never lands among the files it describes; writing it does not change the case.

Write even if the pre-flight objects

When to use it. Write the export even when the pre-flight raises an objection, such as too little free space at the destination. Use it only after you have read the warning and accept it.

What it costs. The pre-flight is what stops a half-written export or a destination that cannot hold the file; forcing past it can leave an incomplete export that another tool will reject as malformed.

What is happening, in plain words (e.g. "drive is clicking"); omit to list every situation

When to use it. Describe what is happening in your own words - "drive is clicking", "formatted the wrong disk", "Outlook will not open it" - and get the feature to use, why that one rather than the obvious alternative, a worked example, the commands, and what NOT to do. Use it when somebody hands you a job and you are not sure which part of the product it belongs to, and give it to new staff before you give them anything else.

Show every situation, grouped, rather than searching

When to use it. List every situation, grouped, instead of searching. Use it to see the whole range at once - useful when scoping what a product will cover for a customer, and for training.

What it costs. Situations the product you are running does not include are marked, so the list stays honest about what this build can actually do.