Each one states the situation, how to recognise it, which product and workspace cover it, the procedure and the reason for each step, the exact commands, the options that apply and when, best practice, and what the product will not do.
Files were deleted and the Recycle Bin emptied before anybody noticed they mattered. The volume is otherwise healthy and still in use, which is the part that decides the outcome.
How to recognise it
The file is not in the Recycle Bin
The volume mounts normally and other files open
The machine has been used since the deletion
Procedure
Stop using the drive holding the deleted filesDeleting a file releases its space. Anything written afterwards can land on it, and once that happens no tool recovers the contents.
If the files are on the system drive, shut the machine down and read the disk from another machine, or work from an imageWindows writes to the system drive continuously, so a recovery run on the live system drive is racing the operating system.
Scan in smart mode and review before exportingSmart mode parses the file system for original names and folders and carves free space for what the metadata no longer covers.
A camera, phone or card reader reports that the card must be formatted before it can be used. This usually means the file system header is damaged, not that the photographs are gone.
How to recognise it
Windows offers to format the card every time it is inserted
The camera reports a card error
The card's capacity shows correctly, or shows as 0 bytes
Procedure
Do not accept the format promptFormatting writes a new file system over the old one. The photographs usually survive it, but the names and folders often do not.
Copy the card to an image first if it is failing or valuableA card that is producing read errors should be read once, not repeatedly.
Scan the card or the image in smart modeThe file system header may be damaged while its backup copy is intact, in which case names and folders come back too.
A handset was reset, or an application was removed, and photographs or messages that were never backed up are wanted. What is possible depends almost entirely on the handset and whether it is rooted.
How to recognise it
The handset works normally but the content is gone
There is no cloud backup, or the backup predates the loss
There may be an old computer backup
Procedure
Establish what this specific handset allows before promising anythingA modern handset encrypts storage, so deleted data is not recoverable by reading the device unless it is rooted.
Check for an existing computer backup firstAn iTunes or Finder backup, or an Android backup, is frequently the complete answer and takes minutes.
Copy what the handset does exposePhotographs still present can be copied off directly, read-only.
Commands
recoveryantra phone --areas
List what is recoverable per application, including what is honestly not recoverable locally.
recoveryantra phone --types
The same question by data type: contacts, messages, photographs.
A machine was reinstalled or reset and the previous user's documents were not moved off first. Some of the old data is usually still in the space the new installation has not yet used.
How to recognise it
The machine works and has a fresh Windows installation
The old user profile is not present
The drive is the same physical disk
Procedure
Stop using the machine immediatelyA fresh Windows installation writes continuously. Every hour of use reduces what is left.
Read the disk from another machineRecovering the system drive while Windows runs on it is racing the operating system for the same free space. Take the disk out, or image it from a second machine.
Scan in smart mode to a separate driveDocuments and photographs carve well even when the old file system has been replaced.
Messages, call history or contacts have been deleted from an Android handset and are needed back. Whether this is possible depends on whether the database can be reached.
How to recognise it
The handset works and is unlocked
The messages are not in any backup
The handset may or may not be rooted
Procedure
Establish what can be reached on this handsetWithout root, only what the handset exposes can be copied. With root, the databases themselves can be read.
Read the message database, including deleted rowsA deleted row frequently survives in the database's free space or in its write-ahead log.
Report recovered deleted records as recovered deleted recordsThey are flagged as such, and the flag must survive into whatever is handed over.
CHKDSK can rewrite a volume's index into something that still looks like a real, working filesystem - it stops asking to be formatted - while the fields inside it now point at the wrong place. Reading it as it stands now names almost nothing; the volume's own untouched spare copy of that index is consulted automatically whenever that happens, the same way it already is when the index is gone entirely.
How to recognise it
The drive mounts normally and reports the right size, not RAW
Folders that used to hold files are now empty, or the whole drive looks empty
CHKDSK (run by Windows automatically, or by the customer) said it fixed something
Procedure
Do not run CHKDSK, or any other repair tool, againEach run writes to the very structures a spare-copy recovery reads from; a second run can overwrite the untouched copy as well.
Recover in fs or smart mode, including intact filesThe primary index is read first; if it names essentially nothing, the volume's own spare copy is tried next, automatically, before anything is reported back.
Read the recovery's own note about which copy was usedWhen the spare copy was needed, the result says so plainly, together with anything CHKDSK itself had already saved into FOUND.000-style folders.
Also carve by content for anything neither copy of the index reaches.
Options, and when to use them
--include-intact
Required: CHKDSK's aftermath is not a deletion, the customer's own live files need reading back too.
--mode
fs reads only the index (fast, includes the automatic spare-copy fallback); smart adds carving over the same region.
Best practice
Never word this as the customer's mistake - they tried the obvious thing before calling, which is what most customers arriving here have done
Say plainly which copy of the index was actually used
Point out any FOUND.000\FILEnnnn.CHK fragments CHKDSK itself already produced, rather than leaving them unexplained in the results
What this will not do
A spare copy of the INDEX only restores names and folders; file data genuinely overwritten since CHKDSK ran is not recovered by it
A volume that legitimately holds very little is left alone - the fallback only runs when a known, valid filesystem names essentially nothing, not merely a small number of files
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
9 scenarios
Servers, arrays and virtual infrastructure
Storage that a business runs on: RAID sets, NAS units, storage pools, virtual machine disks and machines that cannot be dismantled.
The source step: one card per connected drive
A RAID 5 array dropped a disk and the controller will not rebuild
An array has lost a member and the controller either refuses to rebuild or failed part way through. The data is still spread across the surviving members and can be assembled in software.
How to recognise it
The controller reports the array as failed or offline
A rebuild started and stopped, or was never offered
The volume no longer mounts on the host
Procedure
Stop the controller from rebuilding againA second rebuild attempt onto a marginal disk is the most common way an array that could be rebuilt no longer can be.
Image every surviving member before assembling anythingAssembly is read-only, but the members are usually the same age and the same model, so a second failure during the work is a real risk.
Assemble from the member images and read the volumeGeometry is read from the members' own metadata where it survives.
A NAS has stopped serving. The unit itself may have failed while the disks are fine, which is the common case and the recoverable one.
How to recognise it
The web interface does not respond or reports a degraded volume
Shares have disappeared from the network
The disks spin up normally when connected directly
Procedure
Take the disks out and label the bay orderNAS units store the array layout on the disks, but bay order is the cheapest thing to record and the most annoying to reconstruct.
Image each diskConsumer NAS disks are usually the same batch and the same age.
Assemble the array and read the volumeSynology SHR, standard Linux md arrays and LVM volumes are read from their own metadata.
Power was lost during writes and the volume no longer mounts. The file system metadata is damaged; the data usually is not.
How to recognise it
The volume shows as RAW in Disk Management
chkdsk offers to fix it, or refuses to run
The partition table still shows the right size
Procedure
Do not run a repair utility yetA repair writes to the volume. If it goes wrong there is no second attempt, and the recovery becomes much harder.
Image the volume firstThe image is what protects the option of trying something else.
Recover from the image with intact files includedThe file system's backup copies are consulted automatically, which often returns names and folders intact.
A VMware or Hyper-V virtual disk will not boot or will not attach, and the most recent usable backup predates work that matters.
How to recognise it
The hypervisor reports the disk as invalid or locked
The guest fails to boot after a snapshot operation
A -flat.vmdk or .vhdx file exists and is the expected size
Procedure
Copy the virtual disk files off the datastoreWork from a copy. The datastore is live storage and the original should stay untouched.
Open the virtual disk directly and read the guest file systemThe disk does not need to boot, or even attach, to have its contents read.
Recover the files the business needs, not the whole guestA full guest restore is usually slower than extracting the data and putting it into a working machine.
A disk taken out of a security recorder shows no readable file system in Windows, because recorders use their own layout rather than NTFS.
How to recognise it
Windows offers to format the disk
The recorder itself has failed or its export function does not work
The footage is needed for a specific date and time
Procedure
Identify the recorder before extracting anythingIt reports which recorder wrote the disk, which tells you whether the format is supported and how long the job will take.
Image the disk if the footage may be needed as evidenceRecorder disks are large, so plan the storage first.
Extract clips, then reviewRecorders overwrite continuously, so the oldest footage present is the boundary of what exists.
The clips are already extracted from a recorder disk, and one customer or insurer needs a single time range from a single camera - not the whole extraction, and not the raw carved file if a shorter, playable cut will do.
How to recognise it
The footage has already been through `cctv --device/--image -o`
A customer, insurer or the other side needs one clip, one range, or a still, not the full extraction
The clip has to remain trustworthy: the recorder's own bytes wherever possible, and said plainly when it is not
Procedure
Read the recorder's own camera indexCameras against time, read in seconds, nothing written - confirms which camera and time range you actually need before touching a single clip file.
Play the clip firstFrame count, keyframes, picture size and time base - the same check a forensic examination runs before handing anything over.
Hand over the whole clip, or cut a shorter rangeA full clip is downloaded byte-exact; a range is remuxed losslessly by default, so the recorder's own compressed pictures are kept rather than re-encoded.
Capture a still and write the reportA still frame for a claim form, and a written report covering every clip's channel, time, codec and hash.
Commands
recoveryantra cctv index E:\dvr.dd
See every camera and its time range before choosing a clip.
recoveryantra cctv play D:\Footage\clip_00000000.h264
Confirm the clip's own timeline before handing it over.
A written report of every clip's channel, time, codec and hash.
Options, and when to use them
--unit
Give --from/--to in seconds instead of frames when you are working from a timestamp rather than a frame number.
--reencode
Only when the exact frame range matters more than keeping the recorder's own bytes - every pixel becomes new, and the screen and the sidecar both say so.
--channel
Narrow `cctv extract` to one camera once `cctv index` or `cctv clips` has said which channel it is.
Best practice
Identify and index the recorder before choosing a clip, so the range asked for is the range that actually matters
Prefer the lossless cut; only re-encode when the exact frame range is required and say so in the handover notes
Keep the original clip and every cut's provenance sidecar; a re-encoded clip is a fair representation, not the recorder's bytes
What this will not do
Channel and start time are only as good as the recorder's own table - a table-less disk's clips carry inferred camera labels and unknown times, never an invented channel number
A clip whose parameter sets were lost may not play in every viewer, and is marked as such rather than listed as normal
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
Files were removed from a OneDrive, Google Drive or Dropbox folder and the provider's own recycle bin no longer has them. The local cache on the machine may still hold copies.
How to recognise it
The provider's web interface shows nothing to restore
The deletion is older than the retention window
The machine that held the folder is still available
Procedure
Check the provider's version history firstWhere it still holds the file, that is the complete and correct answer, and it takes minutes.
Recover the local sync cache from the machineThe client keeps local copies and metadata that frequently survive the deletion.
Stop using the machine while this is outstandingThe cache is on the same volume as everything else the machine writes.
The recovery listed a video as recovered, but the file will not open, or plays sound with no picture. This is normally a missing or inconsistent index rather than missing picture data.
How to recognise it
The player reports an unsupported or corrupt file
Audio plays but the picture is absent
The file size looks plausible
Procedure
Run the video repair over the recovery folderIt rebuilds the index in the recovered COPY, which is what most players read.
If that is not enough, repair using a healthy clip from the same deviceA reference file from the same camera donates structure only; the picture data comes entirely from the damaged file.
Commands
recoveryantra fixvideos D:\Recovered
Repair the index of every unplayable video in the folder.
The drive still reads but is deteriorating. The decision that matters is made in the first ten minutes: read it once, carefully, and work from the copy.
How to recognise it
Read errors appear in the system log
Throughput collapses part way through a read
The triage reports the drive as unhealthy
Procedure
Triage briefly, then stop reading the driveTriage establishes the condition. It is not a scan and should not become one.
Image once, with a retry policy chosen in advanceEvery retry is another read of a failing surface. Decide the policy before starting, not while watching it.
Do all the recovery work against the imageThe original goes back to the client having been read once.
A set of disks has arrived with no controller, no documentation and no agreed order. The order and geometry have to be established before anything can be read.
How to recognise it
Several disks of the same model and size
No controller, or a controller that no longer works
Nobody at the client knows the configuration
Procedure
Image every disk firstEverything after this is trial and error, and it must be done against copies.
Try automatic detection before assuming anythingLinux md, Intel RST, Synology SHR and Windows dynamic disks all write their layout onto the members.
Where the metadata is gone, test geometries and judge by the filesA correct assembly produces files that open. A wrong one produces a volume that mounts and returns rubbish.
A single job combines several kinds of media, each needing a different acquisition method, and the client expects one answer at the end.
How to recognise it
Multiple exhibits with one reference number
Different media types with different urgency
A deadline that covers all of them
Procedure
Triage everything before starting any of itThe failing item sets the order. Anything deteriorating goes first.
Image what can be imaged; send the phone to RecoverYantra MobileHandsets are not drives and are not imaged the same way; the phone exhibit is acquired in RecoverYantra Mobile and its image or extraction comes back here for recovery.
Keep one output structure per exhibitOne folder per exhibit is what keeps a mixed case reportable.
A desktop or workstation using Intel Rapid Storage Technology has lost its motherboard. The replacement board does not recognise the array, so the volume is unreachable.
How to recognise it
The new board shows the disks individually
The RST option ROM reports the array as missing or failed
Both disks are healthy on their own
Procedure
Image both disksThe array metadata is on the disks, so nothing is lost by working from copies.
Assemble from the members' own metadataIntel RST writes its metadata block onto the members, so the array can be read without the board that made it.
Recover the volumeOnce assembled it is an ordinary Windows volume.
An archive came back from a recovery and the archive tool refuses it. Whether this is repairable depends on whether the archive was stored in one piece.
How to recognise it
The archive tool reports the file as corrupt or truncated
The file size looks plausible
Other recovered files from the same scan open normally
Procedure
Check what the recovery itself said about the fileArchives that will not open are flagged during the scan rather than presented as clean recoveries.
Re-run against the image with carving as well as file system parsingA fragmented archive sometimes recovers whole through a different route.
Search the recovery for the individual files insteadWhere the archive cannot be rebuilt, the documents inside it may have been recovered separately.
A bench has a row of drives waiting, some healthy and some not. Each should be copied to an image once, so a failing drive is read as little as possible, and then recovered from that image, overnight and without anyone typing the jobs in one by one. The order has to be enforced: a recovery must never start before its image exists, and a drive that could not be imaged must not go on to fail a second time.
How to recognise it
Three or more drives to work through and one operator
Some of the drives are old, noisy or already flaky, so every extra read of them costs
The same two steps, image then recover, apply to every drive
Procedure
Read the built-in playbook firstimage-then-recover copies each drive to a raw image once, then recovers from that image in smart mode. Each of its two steps is tried once more if it ends failed. Print it, or list the playbooks, before applying one.
Apply it to every drive in one commandName the drives, each a device path or an image file, and one destination folder. One set of jobs is made per drive, and the recovery job of each drive is wired to wait for that drive's own image. Nothing is written until the whole plan is valid, so a refused plan leaves no half-built queue.
Set how many drives may run at onceThe default is 1, one job at a time, and the ceiling is 8. Jobs that read the same drive or write to the same place still run one after the other. Start with a low number and raise it only after seeing that the bench keeps up.
Start the queue and leave itThe queue prints one JSON line for each event and runs until every job has finished. Its state is kept on disk, so an overnight run survives the program closing or the machine restarting: a job that was running goes back in the queue and resumes from its imaging map or recovery checkpoint.
Read what failed, and what was skipped, in the morningA failed job says why. Its recovery job is skipped, with the reason, instead of running out of order. A failed job is tried again up to its retry count, resuming from what is already saved, except where the reason cannot change on a second try: a refused licence, a password that is needed, or a memory shortfall.
Write the batch reportOne report across the batch: what succeeded, what failed and why, and per-job counts and sizes, as html, pdf or docx.
Commands
recoveryantra batch playbook show image-then-recover
Print the steps of the playbook before it is used.
Run every job that has not finished. Pause and stop are typed in a second terminal while this one runs.
recoveryantra batch status BATCH20260930-025344-ebafaf
How many jobs are queued, running, done, failed or skipped.
recoveryantra batch report BATCH20260930-025344-ebafaf --out D:\Bench\2026-09-30\report --format html pdf
The report across the whole batch.
Options, and when to use them
--sources
The drives or image files, separated by spaces. A source named twice is refused.
--dest
The one folder every image and every recovery is written under; the playbook can write nowhere else. Choose a different drive from the ones being read, with room for an image of each.
--name
A name for the batch. Without it the playbook's name and the date are used.
--out
The folder the batch report is written into.
--format
html, pdf or docx, one or more. The default is html and pdf.
Best practice
Image each drive once and recover from the image; do not scan a failing drive directly when an image can be made
Keep the batch id with the case notes; every later command names it
Read the skipped jobs as carefully as the failed ones. A skip is the consequence of a failure earlier in the same drive's steps
Write the report before the drives leave the bench
What this will not do
Imaging and recovery both need an active licence. Without one every job fails at once with that reason, and the recovery jobs are skipped behind them
A playbook never carries a password. A locked drive fails its own jobs with the reason and the rest of the bench carries on
Jobs that share a source, a device or an output path never run together, whatever the count
The queue does not repair drives. A drive that cannot be read fails its image, and the recovery from that image is skipped
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
The lab's procedure is not the built-in one. It wants a quick filesystem pass first, so named files are in hand fast, then an image, then a deep carving pass from that image. Typing those as separate jobs for every drive is where mistakes creep in, and where a fragile drive gets read in the wrong order.
How to recognise it
The same three or four steps are being typed for every drive
A step is sometimes forgotten, or run before the image it needs
One drive in the batch is fragile and should be read after the others
Procedure
Write the procedure as a list of steps in a JSON fileEach step has a kind (image, recover or both) and may set a name, an image format (raw or e01), a recovery mode (smart, fs or carve), a retry count, the earlier steps it waits for and, for a recovery, the step whose image it reads. In the file the steps are numbered from 0, and from_step and depends_on_steps use those numbers; the messages and the job records call the first step Step 1. Output paths are patterns that must begin with {dest}, so a playbook can write only under the folder named when it is applied. Three steps look like this: [{"kind": "recover", "name": "Quick", "recover_mode": "fs", "recover_out": "{dest}/{label}-quick"}, {"kind": "image", "name": "Image", "image_format": "raw", "image_out": "{dest}/{label}.img"}, {"kind": "recover", "name": "Deep", "recover_mode": "carve", "from_step": 1, "depends_on_steps": [1], "recover_out": "{dest}/{label}-deep"}]. The third step reads the image that step 1 (the second step) made.
Save it under a nameThe steps are checked in full when it is saved. An unknown setting, a step that waits for a later step, or a recovery that reads an image no earlier step makes is refused with its step number, counting from 1 as the messages do. The two built-in playbooks cannot be replaced. A name is 1 to 64 letters, digits, dots, dashes or underscores.
Apply it to the drives that came inOne set of jobs is made per drive, wired in the order the steps say. Two steps that would write to the same place are refused, so give each output its own pattern, for example {dest}/{label}-{step}.
Hold a later job back where the order mattersList the batch, then make one job wait for another by their ids. A circle is refused and named. If the job it waits for fails or is skipped, the waiting job is skipped with the reason instead of running out of order.
Pause and carry on without losing workPause and stop are typed in a second terminal; the run stops at the next safe point. Resume skips every job already finished and carries an interrupted one on from its own checkpoint.
Commands
recoveryantra batch playbook save lab-triage --file D:\Bench\lab-triage.json --description "Quick pass, image, deep pass"
Save a playbook. The file holds three steps: a recover step in fs mode writing to {dest}/{label}-quick, an image step writing to {dest}/{label}.img, and a recover step in carve mode that reads that image (from_step 1) and writes to {dest}/{label}-deep.
Files have been renamed with an unfamiliar extension and a ransom note has appeared. The first hour decides how much comes back, because the originals many strains delete are still in free space.
How to recognise it
Files carry a new extension and will not open
A ransom note file appears in every folder
Scheduled backups have failed or been deleted
Procedure
Take the affected machines off the network and STOP USING THEMContinued use overwrites the free space holding the deleted originals, which is the highest-value recovery available.
Identify the family before planning anythingWhat is recoverable depends entirely on which strain it is.
Triage, then hunt the originals, then state a verdictIn that order. The verdict is only honest once the first two are done.
Backups have been deleted or encrypted as part of the attack. Windows shadow copies and file-system snapshots are frequently missed by the attacker and are the fastest complete recovery.
How to recognise it
Backup jobs report missing or deleted targets
The backup server was reachable from the compromised machine
The affected volumes are Windows or run on a NAS
Procedure
Check for shadow copies before anything elseThey hold the volume as it was before the encryption, and reading one is far faster and more complete than carving.
Check NAS and volume-manager snapshotsQNAP, Synology and LVM snapshots survive many attacks.
Recover from the snapshot rather than from the encrypted volumeA snapshot recovery returns whole files with their names and folders.
Several strains encrypt only part of each file to work faster across a large estate. The untouched regions of large documents, databases and virtual disks are still readable.
How to recognise it
Very large files were processed suspiciously quickly
Parts of a file open or display correctly
The strain is identified as one that encrypts intermittently
Procedure
Identify the strain and its encryption patternThe pattern determines which regions survived.
Map the damage before deciding what is worth extractingTriage reports what proportion of each file is intact.
Extract the untouched regionsFor a database or a virtual disk, the intact regions are frequently enough to recover the contents.
A hypervisor estate has been hit. Several strains that target ESXi encrypt the small descriptor files and leave the large flat disks holding the actual data intact.
How to recognise it
Virtual machines will not power on
Datastore files carry a new extension
The -flat.vmdk files are still their original size
Procedure
Establish the strain and its ESXi behaviourThe playbook differs by family, and some encrypt only descriptors.
Check whether the flat disks survivedA flat disk of the expected size is the whole virtual machine's data.
Rebuild the descriptor for each intact flat diskA rebuilt descriptor makes the surviving data readable again.
A published decryptor appears to exist for the strain. Running an unverified executable against the client's only remaining data is how a single incident becomes two.
How to recognise it
The family has been positively identified
A tool is available from somewhere on the internet
The client is under pressure to act quickly
Procedure
Check the index for a legitimate published decryptorIt names the tool, the publisher and the scope, or states that none exists.
Verify the downloaded file before running itCompare its hash against the catalogue entry for the tool.
Test on copies, never on the only remaining dataA decryptor that behaves unexpectedly must not be able to make things worse.
Commands
recoveryantra ransomware --decryptor stop_djvu
The offline decryptor index for that family: publisher, key status and scope, or a statement that none exists.
Multiple machines are affected and the entry point is unknown. Recovering the data and establishing the entry point are two different jobs, and confusing them costs both.
How to recognise it
Several machines encrypted within a short window
No obvious first victim
Insurers or regulators will ask how it started
Procedure
Separate the two objectives explicitlyRecovery restores the business; investigation answers how it happened. They compete for the same machines.
Preserve at least one affected machine untouchedIf everything is remediated, the question of entry point becomes unanswerable.
Recover the restThe business can be restored from the machines that are not being preserved.
The database will not attach and the most recent backup has failed or is too old. The data file itself is present and the rows can be read out of its pages.
How to recognise it
SQL Server reports the file as corrupt or a different version
The instance will not start, or the database is marked suspect
The .mdf and possibly the .ldf are present
Procedure
Take the instance offline and copy the filesExtracting from files a running engine is writing to produces rows from a state that never existed.
Identify the file before planning the workIdentification names the engine and the recovery method, which decides whether this is a short job.
Extract the tables and rows to CSVThe rows are then loadable into a working instance.
Commands
recoveryantra db --identify E:\copy\accounts.mdf
Name the engine and the recovery method that applies.
recoveryantra db --recover E:\copy\accounts.mdf --out E:\Out\accounts.csv
Extract records from the data file to CSV.
recoveryantra db --coverage
Review which database families are covered and at what tier.
Options, and when to use them
--identify
Always first. It decides the plan.
--recover
Work from a COPY, with the instance offline.
--out
Write to CSV whenever the rows are going to be reviewed or loaded elsewhere. Deleted rows are exported flagged; keep the flag.
--coverage
Use when scoping or quoting; the tier matters more than presence in the list.
Best practice
Always work from a copy, with the engine stopped
Check the row counts against what the business expects before reporting success
Preserve the deleted-row flag through to whatever is handed over
What this will not do
A live, running database is not repaired by this route
Pages that were never written to disk, or have been overwritten since, are not recoverable
This recovers data, not a complete server with its users, permissions and jobs
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
An application stores its data in SQLite and rows have been deleted. SQLite frequently leaves deleted rows in the page or in the write-ahead log.
How to recognise it
The application no longer shows the records
The .db file and possibly a -wal file are present
The database has not been vacuumed
Procedure
Copy the database AND its -wal and -shm files togetherThe write-ahead log frequently holds the page that still has the deleted row. Copying the .db alone loses it.
Identify and extractDeleted rows are recovered from free blocks, unallocated space and superseded pages in the log.
Report deleted rows as deletedThey are flagged, and the flag has to survive the export.
Commands
recoveryantra db --identify E:\copy\app.db
Confirm the format and the recovery route.
recoveryantra db --recover E:\copy\app.db --out E:\Out\rows.csv
Extract rows including recovered deleted ones.
Options, and when to use them
--identify
Confirms SQLite and reports what is present.
--out
CSV, with the deleted flag preserved as a column.
Best practice
Copy the -wal and -shm files with the database; they are part of it
Do not open the database in the application first: that can checkpoint the log and lose the very pages wanted
Keep the deleted flag through to the deliverable
What this will not do
A vacuumed database has genuinely removed the deleted rows
Where only fragments of a row survive, the text is reported as recovered text rather than reassembled into a row that was never seen
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
5 scenarios
Mail stores
Reading and exporting mail from a store the client refuses to open.
Mail recovery: the stores covered
Outlook reports that the file is not an Outlook data file
Outlook refuses to open a .pst. That message means the header or the index structures are damaged, which is exactly the case the structured reader alone cannot handle.
How to recognise it
Outlook reports the file is not an Outlook data file
The file is a plausible size
Repair tools have not been run, or did not help
Procedure
Copy the store and work from the copyRepair tools rewrite the original. Preserve it before anything runs.
List what the store contains before exportingThe listing says whether the store read cleanly or had to be salvaged, which changes what you can promise.
Export the messages to a format that will openThe deliverable is readable mail, not a repaired container.
Commands
recoveryantra mail E:\copy\archive.pst --list
Show what is in the store and how it had to be read.
recoveryantra mail E:\copy\archive.pst -o E:\Out --format eml
Export one file per message, ready to drag into Outlook.
recoveryantra mail E:\copy\archive.pst -o E:\Out --format mbox
Export as a single mbox container for another client or a review platform.
Options, and when to use them
--list
Always run first. A salvaged read recovers messages but may not recover the folder structure.
--format
eml for individual review or reimport into Outlook; mbox for Thunderbird, Apple Mail and review platforms.
-o
Never the folder holding the store being read.
Best practice
Work from a copy and keep the original untouched
Tell the client whether the read was clean or salvaged: they differ in what they can deliver
Deliver an index alongside the messages; loose .eml files are not a mailbox anybody can use
What this will not do
The product extracts messages; it does not write back a .pst that Outlook will reopen
Where the folder hierarchy is lost, messages are still recovered but their folder placement may not be
A PST password is a check Outlook makes before opening; it does not encrypt the store
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A member of staff has left and only their OST remains
The mailbox has been removed from the server and the only copy is the offline store file on the machine they used. Outlook will not open an OST without its original account.
How to recognise it
The mailbox no longer exists on Exchange or Microsoft 365
A .ost file is present in the user's profile
Outlook will not open it
Procedure
Copy the OST off the machineThe machine may be reissued, which destroys it.
Read the store on its ownThe OST is read directly, without the account that created it.
Export to a format the business can useUsually .eml for reimport, or mbox for review.
Commands
recoveryantra mail E:\copy\user.ost --list
Show what the offline store contains.
recoveryantra mail E:\copy\user.ost -o E:\Out --format eml
Export the messages.
Options, and when to use them
--list
Establish what is there before promising it.
--format
eml for reimport into a mailbox; mbox for a review platform.
Best practice
Secure the OST before the machine is reissued or wiped
Confirm with the business who is authorised to read a former employee's mail before opening it
Deliver with an index
What this will not do
An OST that was never fully synchronised only holds what it had downloaded
The container is not rebuilt; messages are extracted
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
You are responsible for several hundred machines and you do not want the first hour of an incident spent working out how to reach one. The agent is deployed with the rest of the fleet software, before anything has happened, so acquisition is a decision rather than a project.
How to recognise it
Machines are spread across sites and subnets, so a network scan finds only what is near you
Laptops are often asleep or away when you look
Nobody can be sent to sit at the machine
The organisation owns and administers the machines
Procedure
Build the package with your console already in itOne MSI, carrying the pairing key, the console's address and the check-in interval. Nothing has to be typed at any desk, and there is no transform or post-install script to get wrong.
Push it the way you push everything elseGroup Policy Software Installation takes MSI and nothing else; Intune and SCCM both accept one. It installs silently and runs as a service, so it is there before anyone logs in.
Let the machines report inEach one says what it is - name, system, volumes, and whether it can be frozen for a live acquisition - when it starts and every few minutes after. You get a roster instead of a scan.
When something happens, pick a machine and acquire itA deliberate act by an operator holding the pairing key. The agent cannot be instructed by the console, so this is never automatic.
If the machine is switched off mid-copy, carry onThe shadow copy survives a restart and the agent remembers it, so the copy resumes into the same image. If that frozen moment is gone, it starts again rather than splicing two moments into one file.
Acquire one, through a snapshot taken on that machine.
Options, and when to use them
--msi
Use it for a real rollout. The folder installers need somebody at each desk, which is not a rollout.
--server
Build the console's address in, or the agents are silent and you are back to scanning.
--site
Label the batch - office, department or case - so you can tell which rollout a machine came from.
--key
One key per site or per case. Rotating a key means generating a new package; the roster shows which key each machine holds so you can see who has not been updated.
--stale
On the roster, include machines not heard from recently, when you are looking for one specific laptop.
Best practice
Deploy BEFORE an incident. Installing an agent on a machine you already suspect announces the investigation and changes the machine.
Use a different pairing key per site. One key everywhere means one leak everywhere.
The MSI carries the key and the server. Store it where you would store a credential, not on a share everyone can read.
Check the roster occasionally for machines that stopped reporting - that is how you find an agent that was removed or a machine that was rebuilt.
What this will not do
ENROLMENT IS REPORT-ONLY. The console cannot instruct an agent. That is deliberate: an agent that took orders from whatever answered at a hostname would make one server worth every workstation's disk.
A machine that is switched off does not report in. The roster shows when each was last heard from.
Acquisition connects from the console TO the machine, so the two must be able to reach each other. A laptop behind a home router is enrolled but not reachable until it is on the corporate network.
Creating a snapshot allocates space on the endpoint, so a live acquisition writes to the machine even though it never writes to the data being acquired.
This is for machines the organisation owns and administers.
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
Something has happened - a leak, a suspected intrusion, a departing employee - and the machine belongs to the organisation but sits with the person. Seizing it announces the investigation, and powering it down destroys what is only in memory and in open files.
How to recognise it
The machine is in daily use and cannot be collected
The custodian must not know an examination has started
The organisation owns and administers the machine
It is on the network, or comes back to it
Procedure
Record the authority firstConfirm the organisation owns and administers the machine, and record who authorised the acquisition. An authority written afterwards is not an audit trail.
Have the agent already in placeThe agent is deployed with the rest of the fleet software, with a pairing key. Installing it at the moment of the incident is what tips somebody off.
Ask the endpoint what it can do`remote volumes` reports the machine's volumes and whether it can be frozen, before you commit to a transfer that may take hours.
Acquire through a snapshotThe snapshot is taken ON the endpoint, because a volume can only be frozen where it lives, and the frozen view is imaged across the network.
Put the machine backThe snapshot is released and the endpoint is left as it was found. That happens even if the transfer failed part way.
Verify, then work on the copyCheck the image before examining it. Everything after this point rests on it.
Examine the image, hashing every file into the manifest.
recoveryantra audit D:\cases\IR-2026-014\out
Check the audit trail is unbroken before the report goes out.
recoveryantra search D:\cases\IR-2026-014\out
Search the verified copy for the names, keywords or accounts the incident concerns.
Options, and when to use them
--host
The endpoint's address, from `remote discover` or your own asset list.
--key
The pairing key the agent was installed with. Without it the agent answers nothing at all.
--volume
The volume ON THE ENDPOINT, in that machine's own terms: a drive letter on Windows, a mount point on Linux and macOS.
-o
Where the image lands on YOUR machine. A case folder on evidence storage, never a workstation desktop.
--keep-snapshot
Leave the snapshot in place afterwards. Use when a second volume from the same machine follows, so it is frozen once rather than twice.
--port
Only when the agent was installed on a non-default port.
--profile
forensic hashes every recovered file into the manifest and keeps a flat layout; recovery sorts by type and skips hashing. In an examination this is not a preference.
Best practice
`--keep-snapshot` leaves the snapshot in place when you expect to take a second volume from the same machine, so it is frozen only once.
`volumes` first, always. It tells you whether the machine can be frozen BEFORE you commit to a transfer that may take hours.
Run the agent with administrator rights on Windows, or Volume Shadow Copy cannot create the snapshot.
What this will not do
Creating the snapshot allocates space on the endpoint. A live acquisition therefore WRITES to the machine, even though it never writes to the data being acquired. Say so in the report.
A machine that cannot be frozen is refused, not read live. An image of a moving volume is not a point in time.
The Windows route is certified against a real machine. The Linux and macOS routes are implemented and not yet certified.
This is for machines the organisation owns and administers. It is not a way into somebody else's computer.
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A production server is the subject of an investigation or has been attacked. Shutting it down costs the business more than the investigation is worth, and rebooting it would destroy the state you came for.
How to recognise it
The machine cannot be stopped
Its disks cannot be removed
The data is changing while you look at it
Procedure
Record the authority and the scopeWho asked for this, over which machine, and on what basis.
Check what the server can actually doWindows offers a shadow copy. Linux can be frozen only where the filesystem is on LVM, and a plain partition cannot be. Learn that now rather than after a two-hour transfer.
Acquire through a snapshotSo the image is one moment rather than a smear across however long the copy took.
Release, and confirmThe snapshot is removed and the server is left as it was found.
Verify, then examine the copyThe server keeps running throughout; the examination happens on the image.
Examine the image, hashing every file into the manifest.
Options, and when to use them
--host
The server's address. Use the name your own records use, so the report matches the asset register.
--volume
A mount point on Linux, so /var rather than a device name.
-o
Evidence storage with room for the whole volume. The pre-flight measures this before the copy starts.
--key
The pairing key the agent was installed with.
--port
Only when the agent is not on the default port.
--profile
forensic, so every recovered file is hashed into the manifest.
Best practice
Take the busiest volume first if the machine is under load - the snapshot fixes the moment, so the earlier it is taken the closer it is to the event.
A database on the volume is captured mid-transaction unless it is quiesced first. A snapshot freezes the disk, not the application.
Watch the endpoint's free space: the snapshot needs somewhere to keep what changes while it exists.
What this will not do
A Linux server whose filesystem is NOT on LVM cannot be frozen, and the acquisition is refused rather than taken live. Acquire it from a boot medium instead.
The snapshot is of the disk. Anything held only in memory is not in it.
The Linux route is implemented and not yet certified against a real machine.
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
An exhibit has to be acquired in a way that will withstand scrutiny: the source unchanged, the copy provably identical, and the method recorded alongside the result.
How to recognise it
The matter may reach court, a tribunal or an insurer
The exhibit must be returned in the state it arrived
The examiner must be able to state their method
Procedure
Record the authority before touching the exhibitOperator, lawful basis, organisation and case reference belong on the acquisition, not added afterwards.
Engage a write block, hardware if availableWhere no hardware blocker is available, the software block is engaged and reported as a software block.
Acquire to an evidence container and verifyThe image is hashed on read and verified on completion.
Memory was captured while the machine was running. It answers questions the disk cannot: what was executing, what was connected, and what was injected.
How to recognise it
A physical memory image exists
The question concerns running state rather than stored files
The kernel build of the source machine is known or discoverable
Procedure
Identify the operating system and kernel firstThe kernel build decides which symbols every other plugin needs, and the answer names them.
Supply the symbols for the exact kernel buildVolatility 3 refuses a run it has no matching symbols for, and names the kernel PDB or banner it needs; nothing is substituted.
List processes, then narrow to the ones that matterInjected-code detection across every process on a large image produces a great deal to review.
Commands
recoveryantra memory info E:\Case\Ex1\memory.raw
Name the operating system and kernel, and the symbols it needs.
recoveryantra memory run E:\Case\Ex1\memory.raw --plugin pslist --os windows --symbols E:\symbols --out E:\Case\Ex1\pslist.json
Processes through Volatility 3, saved so a row can become a finding.
The handling of the exhibit will be examined as closely as the findings. The record has to show that nothing was inserted, removed or reordered.
How to recognise it
The matter is contested, or likely to be
Several people will handle the exhibit
Disclosure is expected
Procedure
Work in forensic mode from the first actionIt hashes every item and writes the custody manifest. A recovery-mode scan does not become evidential afterwards.
Verify the audit trail at the close of the caseThe trail is hash chained, so an edit, an insertion or a reorder is detectable.
Verify again with the manifest before disclosureThe chain alone cannot see a trail that was cut short at the end; the manifest holds the sealed receipt that catches it.
Whether a particular program executed, and when, is answered from several independent Windows artefacts rather than from one.
How to recognise it
A question about whether something was run
An acquired image of a Windows machine
A defined period of interest
Procedure
Collect the execution artefacts togetherPrefetch, ShimCache, BAM, SRUM, Jump Lists and AmCache each record different aspects, and they corroborate each other.
Put them on one timelineSequence is what makes execution evidence interpretable.
Corroborate before concludingA single artefact is weaker than two that agree.
A handset is an exhibit. What can be acquired depends on the device, and what may be acquired depends on the authority, and both have to be settled before it is connected.
How to recognise it
A handset submitted as an exhibit
A warrant, consent or statutory power
An unknown model and state
Procedure
Record the authority before connecting anythingOperator, lawful basis, organisation and case reference.
Establish what this device actually allowsThe plan is gated on the device: a modern handset frequently does not permit a full-filesystem acquisition, and the plan says so.
Decide on advanced methods deliberately, on the recordAdvanced methods can alter the device, so they are off until an examiner opts in and that choice is recorded.
Commands
recoveryantra capabilities --tools --operator "A Sharma" --case FIR-4471
See which acquisition methods are actually available on this bench today.
recoveryantra phone --areas --operator "A Sharma" --authority warrant --case FIR-4471
What is recoverable on this device, recorded against the case.
A station has a DVR export on a pen drive - the recorder's own container, an overlay clock burnt into the picture, and no hash. It has to be read, decoded and recorded so that every frame later shown can be traced to this file and this examiner.
How to recognise it
A vendor container or a .dav/.h264 export a normal player refuses
An overlay clock in the picture that may not match the case time
No hash, no record of who received it or when
Procedure
Probe before decodingTwo readers are run on purpose; where the parser and the decoder disagree the intake says so, and the recorder registry says whether this make and model was tested.
Decode through the ladder to another driveContainer, index, stream, then salvage. The rung that produced each frame is recorded; a salvaged frame is marked, never passed off as normal.
Record the intake in the case with the examiner namedThe source hash, the decode result and the typed name become the exhibit record. One use of the licence is spent here - one source, however many frames. The command prints the case it opened or created, with its folder in brackets; give that folder, exactly as printed, to --case in every later command.
Commands
recoveryantra footage formats
What this build can read, before anything is promised.
An investigating officer needs the three frames that show the vehicle, with their times, in a form a court and a defence expert can check. The video itself must not leave.
How to recognise it
A specific moment in a long recording
A request for stills with the time on them
A defence expert who will ask which frame, from which file
Procedure
Open the asset on the frame server and step to the framePresentation ticks, the decoded index and the overlay text are three fields; the review never merges them into one time.
Bookmark what you see in your own wordsThe bookmark is a finding record in the case, tied to the frame by ordinal and digest.
Capture a frame pack and verify itPNG frames, each with its times, its source hash and extent and its own SHA-256, plus a hashed manifest. Verify it before it leaves.
Commands
recoveryantra review open F:\Case-176\decoded\ch07.mp4
The timeline summary: frames, keyframes, gaps and whether the frames carry times.
Footage has to go to a party who may not see everyone in it. The mask must hold on every frame, a named person must have checked it, and the original must stay untouched.
How to recognise it
A disclosure order with named exclusions
A face or a plate that moves across the frame
A reviewer who will sign for the redaction
Procedure
Mask the region across the framesPixels in the frame, from one ordinal to another, followed across frames when it moves. The mask is a record with its own chain.
A named reviewer types the decisionApprove or reject, with a name and a note, into the hash-chained audit trail. Recorded by the software, not authenticated.
Export the redacted copyRefused until the decision says approve. The copy carries the mask chain and its hashes; the original stays as received.
Read the leak check before you discloseEvery export re-reads the copy and checks two things: that everything outside the masks is identical to the original, and that each masked region really changed. The result is printed as the leak check, and a failed check ends the command with a failure code. If it fails, do not disclose that copy: a mask over a flat area changes nothing, and a mask that missed the subject hides nothing. Move the mask, track again and export again.
The other side says the clip was cut, re-encoded or generated. The laboratory has to say what the file's structure and statistics support and what they do not - as evidence, not as a score. A video has its own examination: the still-image tools read one frame, so a video path given to them is refused and pointed at the video exam.
How to recognise it
A claim of editing, re-encoding or synthesis
A file whose history is unknown
A court that will ask which method said what
Procedure
Run the one-button exam that matches the file--exam for a video, --audio for a recording of sound, --synth for a picture or clip suspected of being generated, --document for a PDF or a scan. Each runs every method that applies to that kind of file, and a method that cannot judge this file says so instead of staying quiet. Each writes three reports (Executive, Judicial, DETAILED) and the raw results.
Look at the clip segment by segment--video-timeline lays the signals out along the clip: where the encoding changes, where an edit list or a splice point sits. It reports signals and never a verdict.
For a single frame or a still, use the still-image examinationreview frames writes the frames you name into a frame pack, a zip with each frame as a PNG in its frames folder. Unzip it and run authenticate on one PNG. Without a flag the still-image examination runs every method and ranks the hypotheses, each with the methods for and against it. The software ranks the evidence; the examiner writes the conclusion.
Keep the reports with the caseThe reports are written to the folder named with -o. Name a folder inside the case folder so the reports, the file's digest and every method's output travel with the case.
The video route runs first: the signals laid out segment by segment along the clip. The still-image methods read a single frame, so a video given to them is refused and pointed here.
A device image was exported into a case and it holds tens of thousands of pictures, many of them the same shot saved, resized or re-shared several times. Reviewing each file on its own is days of work. Grouping the pictures that look alike lets the examiner open one, look at the others in its group, and move on.
How to recognise it
A case with 20,000 or more pictures and a deadline that allows a look at a fraction of them
The same photograph appears at several sizes, from messaging apps, thumbnail caches and re-saves
Reviewers are opening pictures they have already seen
Procedure
Point the grouping at a folder, or at the open caseOn the command line the folder is named. In the gallery, the Find near-duplicates card takes a folder, or every picture in the open case when the box is left empty. The pictures are read and never written to.
Start at the measured default distanceTwo pictures are grouped when their 64-bit pHash values differ by at most 10 bits, and every pair inside a group is within that distance of every other pair. On 3,820 real pictures about 4 clearly different pairs in a million came within it, and up to 57 in a million when look-alikes were counted.
Read what was set asideSolid colours, near-flat scans and smooth gradients produce hashes that many unrelated pictures share. They are listed with the reason and never grouped or dropped in silence. In the measurement set that was 224 of 4,044 pictures, mostly cut-outs on plain white, and none of the 45 real photographs.
Review one picture per group, then the rest of itOpen the representative, then the other members at full size. A group is a list of candidates for the examiner to look at. It does not say what any of the pictures show.
Mark what matters through the galleryTag the representative so the mark travels with the exhibit, and say in the label that it rests on a perceptual-hash grouping.
Keep the parameters with the resultThe output names the algorithm (phash/v1), the distance, the linkage and the tool version. Quote them wherever a group is relied on, so that someone else can repeat the run on the same pictures and get the same groups.
Commands
recoveryantra phash dedup E:\Case-211\Ex4\DCIM
Group the near-duplicate pictures under a folder. The output lists each group with its representative and the exact duplicates inside it, the pictures that had no near-duplicate, the pictures set aside and the statement of what the grouping does not show.
Use image to keep videos off the wall. A video is not hashed; its frames have to be passed in as pictures.
--tag-asset
Once a group has been looked at, tag its representative so the mark is written into the case with the exhibit.
--label
The words the tag carries. Say what it rests on, such as the group number and that it came from a perceptual-hash grouping.
Best practice
Quote the algorithm, the distance and the tool version wherever a group is relied on
Read the pictures set aside for too little detail by eye; they are listed, not judged
Open the members of a group before tagging any of them
Keep the JSON the run prints with the case, next to the folder it was run on
What this will not do
Crops of 5 percent or more on each side, a 10 percent border and a 10 degree rotation were matched at most 47 percent of the time at the default distance, and a flip or a quarter turn is not matched at all on the command line. A picture outside every group is not thereby a different picture
Screenshots and scanned pages share large plain areas. In 4,950 pairs of synthetic scanned pages, about 6 pairs in 10,000 fell within the default distance, so confirm those groups by eye
A video is not hashed. HEIC and RAW files are read through their embedded preview and flagged as such; a truncated picture is reported, never hashed in part
Hashing is the slow part: about 56 pictures a second on 8 threads and 12 on one, measured on one bench machine. 20,000 pictures is about 6 minutes on 8 threads
The result is triage. Nothing in it classifies what a picture shows
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A hash set from the instructing agency has to be checked against an exhibit
An agency has supplied a hash set for the matter. An exact SHA-256 lookup finds only byte-identical files, and the pictures have been re-saved, resized and re-shared. The examiner needs the pictures that sit close to an entry in the set, listed as candidates with the distance and the set owner's own label, and nothing said about what any picture shows.
How to recognise it
A hash set has arrived as JSON, CSV, a text list or a SQLite file
An exact-digest check found little or nothing, but the pictures have been through messaging apps or an editor
The set belongs to the instructing body and the tool bundles no set of its own
Procedure
Do the exact-digest lookup firstA byte-identical copy of a listed file is answered by an exact SHA-256 lookup with no perceptual step. Import the exact digests where the set has them, look a file up, and keep the perceptual match for what that leaves.
Confirm the set declares its algorithmA set that does not say which algorithm made its hashes, or that has no usable row, is refused. Rows that cannot be used are counted and listed with the reason, never dropped in silence.
Match one questioned picture at a timeThe picture is hashed with the same algorithm and compared with every entry. A set made with an algorithm the tool cannot compute for a picture is refused with the reason; the tool does not guess.
Read each candidate with its distanceA candidate is a set entry within the stated distance of the picture. Its label is passed through exactly as the set's owner wrote it, and nothing is added to it.
Set the chance rate beside itThe output states how many chance candidates a set of that size produces. A large set produces some by chance alone, so a candidate at 2 bits carries a different weight from one at 10.
Look at both pictures, then decideThe match says two pictures look alike at a stated distance. The examiner looks at both and, where the set gives an exact digest, checks it. The finding is the examiner's.
Record the set with the resultThe result carries the set's source, its file SHA-256 and size, and the note that the operator supplied it. Keep them beside the finding.
Exact digest first: is this exact file in a set already imported?
recoveryantra phash match E:\Case-211\Ex4\DCIM\IMG_0412.jpg E:\Sets\agency-set.json
Compare one picture with the supplied set. The output lists every candidate with its distance and label, the chance rate and the set's provenance.
recoveryantra hashset import E:\Sets\agency-exact.csv --kind bad --label "Agency set 2026-09" --source "Instructing agency"
Where the set also lists exact digests, import them so the gallery's known-file filter can use them.
Options, and when to use them
--kind
bad flags the listed files and good marks them as ignorable. A set of pictures of interest is imported as bad; the default for import is good, which would tell the gallery to ignore them.
--label
A name for the set in the case, so a later reader can tell which agency list a flag came from.
--source
Where the set came from and on what terms; it is kept with every result that uses it.
Best practice
Check exact digests first, then run the perceptual match on what is left
Keep the set out of anything that leaves the case; the operator supplies it and the result records where it came from
Say in the report that a match is a candidate at a stated distance, and give the distance
Confirm every candidate by eye before it is written up
What this will not do
A candidate says two pictures look alike at a stated distance. It does not say what either shows, and no candidate does not mean the picture is absent: crops, borders, watermarks and rotations defeat the hash to the degrees measured
At the default distance a set of 2,000,000 entries gives a single questioned picture about 7 to 114 chance candidates. The command line has no distance switch, so read the chance figure the output prints and confirm each candidate by eye
The tool ships no hash set and computes no restricted algorithm. A set made with another algorithm is searched only when it declares that algorithm and the questioned picture can be hashed the same way
A picture with too little detail can only give a candidate that is flagged as weak
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A perceptual-hash result has to be explained to someone who will challenge it
A group of near-duplicates or a candidate from a hash set is going into a report. The other side's expert will ask what the number means, how often unrelated pictures reach it, what the method cannot see, and whether the run can be repeated by somebody else.
How to recognise it
A report sentence is about to rest on a hash distance
Opposing counsel or an expert has asked how reliable perceptual hashing is
A picture that should have matched did not, or one that should not have did
Procedure
Read the distance as a count of bitsA 64-bit hash differs from another in 0 to 64 places. pHash distances almost always come out even, so a distance limit of 9 behaves as 8. Zero means the two hashes are the same, which is not the same statement as the two files being the same.
Set the chance rate beside the distanceAt the default distance about 4 to 57 unrelated pictures in every million entries fall within it. For a set of 500,000 entries that is about 2 to 29 chance candidates for every questioned picture.
Say what the method cannot seeCrops of 5 percent or more per side, borders, rotations of a few degrees and flips defeat the hash. A questioned picture that was cropped hard will not match its original, and that is a limit of the method and not evidence about the picture.
Treat a weak picture as weakA picture with too little detail is flagged in the output. Its candidates carry that flag into the report, and it is not grouped with others.
Let the other side repeat itEvery result names the algorithm, the distance, the tool version and the libraries used, and the same pictures give the same result whatever the order or the number of threads. Give them the picture list and the parameters, and print the hashes of the two pictures in question so they can compare the values by hand.
A body-worn camera recording and the files that came with it have been handed over. Before anything else is done with it, it has to be hashed, read and described in a way the other side can repeat: what the file is, what it declares about itself, what is missing from it, and which clock says what.
How to recognise it
A clip from a body-worn or in-car camera, with or without XML, JSON, CSV, GPX or checksum files beside it
The time and place on the clip will be relied on
Nobody has yet recorded its hash or checked that it is whole
Procedure
Keep the recording and its companion files together, read onlyCompanion files are paired with the clip by file-name stem, by an explicit --sidecar, or by a manifest that names the clip or its SHA-256. A checksum file beside the clip is compared with the hash the tool computes.
Run the ingestThe whole file is hashed (SHA-256, with MD5 and SHA-1 beside it), read through its own index, and hashed again at the end. If the size, the modified time or the hash changed while it was being read, the result says so.
Read how it was recognisedThe verdict names the markers it rests on: a body-camera maker's name in the metadata, body-camera wording, or officer, badge and device identifiers together in one source. A file name is never enough.
Read the three times as three thingsThe media clock is the length of the recording. The recorder clock is every time the file and its companions state, each kept as written, with its zone where one was written and never established as UTC. The case time is what the examiner supplies. They are never merged.
Read the completeness statementComplete means every picture and sound the index declares is present. Anything else is reported with numbers, such as the first missing sample and the bytes absent, and nothing is padded or repaired. Complete is a structural statement: it does not decode the pictures.
Write the report set into the case folderThe output folder receives the full result as JSON, three reports (executive, judicial and detailed) and a manifest that hashes each of them. The detailed report carries what is needed to re-derive the finding.
Bring the recording into the caseFootage intake records the exhibit with the source hash and the examiner's typed name. It spends one use of the licence for the source, however many frames it holds. The command prints the case it opened or created, with its folder in brackets; give that folder, exactly as printed, to --case in every later command.
A folder for the report set. Give it whenever the ingest will be relied on; without it the result is printed and nothing is saved.
--examiner
Recorded in the report. Type your own name.
--recursive
With a folder, also read the folders below it.
--json
Print the whole structured result, for a script or a second reader.
Best practice
Work from a copy, or read the exhibit through a write blocker; the ingest writes only into the report folder
Keep the companion files with the clip; each one read is an exhibit of its own
Keep the manifest with the three reports; it hashes each of them
Quote the result digest wherever the finding is relied on; the same bytes give the same digest
What this will not do
Recognition is by markers. The reader was proved on synthetic body-cam files and on 100 real recordings that were not body-cam footage, two of them GoPro. No maker's proprietary wrapper has been certified against a real body-cam recording
MP4, MOV, 3GP and Matroska or WebM are read by the tool's own readers. AVI, MPEG-TS and other containers get the hash, the probe and the companion files only, and the report says so
A clock burnt into the picture is not read by the ingest
The result is a set of observations. It says nothing about the recording's authenticity, the device's identity or anyone's conduct
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
The place and the time on a body-worn camera recording will be relied on
A recording is put forward as showing where a camera was and when. The examiner has to say what the file itself records about position and time, keep the three clocks apart, and show where the recorder's clock and the GPS clock agree or do not.
How to recognise it
A GoPro-class file with a telemetry track, or a clip with a GPX, NMEA or CSV track beside it
Someone will say the recording places the wearer at a location at a time
The recorder clock, the GPS clock and the file times are not obviously the same
Procedure
Ingest with the case time the examiner can supportGive the case time as key=value pairs. It is stored exactly as supplied and is never merged with the recorder's clock.
Read the GPS summary before the pointsThe summary gives the bounds and the time range. Rows with no satellite fix, and NMEA sentences that fail their checksum, are counted and reported, not used. A file that states no fix at all is reported as having no position.
See which points are tied to media timeIn a GoPro-class telemetry track each point carries the media-time span of the sample that held it. Points from a companion file are unlinked to media time by design, and the result marks them so.
Compare like with likeRecorder clock observations are compared only with observations of the same kind. A difference is reported as one grouped warning in which neither clock is taken as correct. The recorded start and stop are checked against the media duration, and the GPS clock against that window.
Leave the time zone aloneA time written without a zone is never converted. Establishing UTC needs the examiner's corroboration, recorded separately.
Read a track file that name pairing would not find, and list the first 500 points; every summary figure still uses all of them.
Options, and when to use them
--case-time
KEY=VALUE, repeatable. For facts the examiner establishes, such as the time of a call. It is kept verbatim and separate.
--sidecar
A companion file to read even when pairing by name would not find it. Repeatable.
--max-points
How many GPS points are listed in the result. Every summary figure still uses all of them.
Best practice
Give the case time in the words of its source, with its own uncertainty stated separately
Report the no-fix and failed-checksum counts beside the position count
Say which points are tied to media time and which are not
Compare positions with other evidence before relying on them
What this will not do
Position comes only from the forms the tool reads: ISO 6709 strings, 3GPP location boxes, NMEA, GPX, GoPro GPMF telemetry and latitude or longitude keys in JSON or CSV. GPS held in subtitle or text tracks and in other vendor boxes is not decoded, and KML is inventoried only
Nothing is interpolated, sorted or smoothed
A real GoPro HERO7 recording carried 204 GPS rows and no satellite lock; the result said no position was found rather than presenting the rows as places
The ingest reports what the file records. It does not say whether the record is correct
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A recording is not recognised as body-cam footage, or stops short of what its index declares
A recording was handed over as body-worn camera footage but the ingest does not recognise it, or it is shorter than the index says it should be. The examiner has to record what was found, what was refused and why, and what is missing, without guessing at a make or padding a gap.
How to recognise it
The verdict starts with not recognised as body-cam footage
The completeness line reads truncated or no_index
A wrapper or box the tool has no specification for is listed as needing a sample
Procedure
Read the refusal as a findingA recording with no markers inside it is not called body-cam footage. The verdict says how many fields were examined and what was looked for. A file name that carries a maker's name is a weak hint and is not enough.
Record the source as an assertion when the examiner knows itIngest again with the assertion. It is written into the result as asserted by the examiner and not measured, and it cannot turn a file that is not a video into a clip.
Read what is missing, in numbersA cut recording is reported as a state, such as no index or truncated, with the samples and bytes that are absent: a movie box that never arrived, or a media box that declares more bytes than the file holds. Nothing is padded or repaired. The report says whether picture and sound survived the cut.
Read the wrapper inventoryA box or wrapper with no public specification is listed with its offset, size and SHA-256 and marked as needing a sample to certify. Keep the file; it is the sample a decoder would be written from.
Use the salvage ladder if frames must be recoveredThe decode ladder tries the container, the index, the stream and then salvage, and records which rung produced each frame. Its output is a different exhibit from the original and is labelled as one.
Run the decode ladder on a copy when the frames themselves are needed.
Options, and when to use them
--assert-bodycam
Only when the examiner knows the source. It is recorded as an assertion and never as a measurement.
-o
The folder the decoded frames go to, on a different drive from the evidence.
Best practice
Report the refusal and its reason exactly as printed
Keep the original untouched and try salvage on a copy
Say which numbers came from the index and which from the bytes present
Keep an unrecognised wrapper; it is the sample a decoder would be written from
What this will not do
Not recognised is not the same as not a body-cam recording. It says only that no marker was found in the file or its companion files
Complete is a structural word: the index matches the bytes present. A recording with a zeroed region and an intact index is called complete, and the report says why the word is limited there
A fragmented recording that lost a fragment shows the gap in time and sequence. The missing footage cannot be rebuilt from what the file holds
A real QuickTime test file that had been cut short was reported as 33 of 708 samples present with 938,476 bytes missing, and it was not padded
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A reviewer needs to know where a name, number or phrase is written in the case, with proof
A case holds dozens of exhibits, notes, findings and reports. A reviewer, a lawyer or the next examiner asks where something is written down, and an answer that cannot be checked against the case will not be accepted. The case index returns the verbatim passages that answer the question, each with the exhibit and the exact place it came from.
How to recognise it
A question of the form who, where, when or which number, over a case with many exhibits
Reading every exhibit again would cost an afternoon and leave nothing to point at
The answer has to be checkable by someone who was not there
Procedure
Build the index onceThe index reads every text exhibit, every finding and note, the report files and the recorder overlay text, in place. It is kept inside the case and reused while nothing in the case has changed; a locked, read-only case is indexed in memory and nothing is written into it. The output lists what was not searched, such as video, audio and archives, and why.
Ask in the words the case would useUse the names, numbers and phrases the case would contain. A phone number written with spaces or a plus sign is found however it was typed, and a quoted phrase must appear as written. Matching is by word, not by meaning, so a question that says meet will not find a passage that says met.
Read the passages, not a summaryEach passage is a verbatim slice of the source, with its exhibit, its kind and its place: a byte range and line numbers for a text file, or a character range inside a finding. A partial answer names the words it lacks.
Read a not-found as a statement about what was searchedWhen nothing answers, the output says not found in this case and repeats what was and was not searched. Weaker candidates appear only as labelled weak leads and never as the answer.
Narrow the search when the answer is noisyLimit it to evidence, findings, notes, reports, overlays or exhibit descriptors, or to one report tier, and say how many passages should come back.
Keep the citation with the passageEvery passage carries a citation naming the exhibit, the place in it and the digest of the text. Put the passage and its citation into the report together.
Commands
recoveryantra caseqa index --case F:\Case-211
Build or refresh the index and list what was not searched.
recoveryantra caseqa ask "Who did Meera meet at Cafe Lotus" --case F:\Case-211
The verbatim passages that answer it, each with its exhibit and place, or not found in this case.
Look only in evidence and findings and return up to eight passages. An exact identifier such as a plate is treated as decisive.
Options, and when to use them
--case
The case folder. Name it every time: left out, the most recently opened case is used, which is a surprise on a shared workstation.
--kind
evidence, finding, note, report, overlay or exhibit, and repeatable. Use it when one kind of source drowns the others.
-k
How many passages come back. The default is 5.
Best practice
Name the case folder on every command
Quote a passage together with its citation and never on its own
State what was not searched beside every not-found
Ask again after the case changes; the index is rebuilt whenever a source has changed
What this will not do
Only text is searched. Video and audio content, image pixels and speech are not, and a PDF is searched only through its printable strings. Not found means not found in the indexed text of this case
Matching is by words, with English stemming only. Other scripts are matched correctly but not stemmed, and Chinese, Japanese and Thai are not segmented
AI-generated observations already in the case are left out of the answers unless --include-ai-observations is given, and are labelled when they are used
Measured on synthetic English text, 16.7 MB (40,185 passages) took 6.6 seconds to index. A 500 MB text corpus would take a few minutes and about 2 GB of memory
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A local language model's summary is wanted, and it has to stay an observation
A reviewer wants a short summary of the passages that answer a question, from a language model running on the workstation. The summary may help the examiner read faster, and it has to stay what it is: an observation made after the examiner recorded their own reading, never a finding.
How to recognise it
AI is set to local mode and a model is on the workstation's own disk
A summary is wanted over the passages a question already returned
The agency or the court will ask what the model saw, what it said and what the examiner had already written
Procedure
Ask without a model firstThe verbatim passages are the answer of record. Read them before anything else. AI is off by default: with no model named nothing is loaded, and the output says so.
Write your own reading and seal itGive the reading and your name with the question, or mark it inconclusive. It is recorded in the case's hash-chained audit trail before the model is loaded. With no reading and no inconclusive mark, or no examiner name, the model is not run.
Name the local modelThe model is a folder or file on the workstation's own disk. A network address or a missing path is refused, nothing is downloaded, a model folder's own Python code is never run and pickled weights are refused.
Read the claims, supported and flaggedThe summary is split into claims. A claim that cites a passage that was not supplied refuses the whole answer. A cited claim whose numbers or identifiers are not in the cited text is flagged. The check is a heuristic: it catches wrong numbers and invented detail, and it does not prove a claim true.
Keep it labelledThe output is headed AI OBSERVATION - NOT A FINDING and records the model, the prompt and the digest of every passage it was given. Nothing from it becomes a finding except by the examiner's own typed decision.
Commands
recoveryantra caseqa ask "What did the witness say about the sedan" --case F:\Case-211
The passages alone. No model is touched.
recoveryantra caseqa ask "What did the witness say about the sedan" --case F:\Case-211 --model D:\models\local-llm --reading "Statement places her at the cafe from 21:04; sedan detail unverified" --examiner R.Iyer
The same question with the reading sealed first and a local model named.
recoveryantra caseqa ask "What did the witness say about the sedan" --case F:\Case-211 --model D:\models\local-llm --inconclusive --examiner R.Iyer
When no reading can be formed yet, that is recorded instead.
Options, and when to use them
--model
A local model path, used only when AI is set to local. Leave it off and no model is touched.
--reading
Your own reading of the case, sealed before the model is loaded.
--inconclusive
In place of a reading, when you cannot yet form one. It is recorded as such.
--examiner
Your name. The reading is sealed under it, and without it the model is not run.
Best practice
Record your own reading before you look at anything a model wrote
Report the model, its version and the digests of its files beside anything it contributed
Cite the passages and never the summary
Leave AI off where it has not been authorised
What this will not do
No model ships with the tool. A run that cannot happen is refused with a named reason (model unavailable, context too long, model failed) and the sealed reading stays sealed
A summary can be fluent and wrong. The grounding check is a heuristic and the verbatim passages remain the answer of record
If AI is set to cloud this command declines and says so. The cloud route belongs to the casequery command, with its own switch and transfer record
The command opens no network connection; a test that watches for any saw none across the index, the embedder and the model load
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
A citation in a report has to be shown to still match the case
A report quotes passages from the case. Weeks later, before it is disclosed or when it is challenged, somebody has to show that each quoted passage is still exactly what the case holds: that the exhibit has not changed and that the text is the same.
How to recognise it
A report or a statement quotes passages with citations
The case has been worked on since the answer was given
The other side asks to see the source of each quotation
Procedure
Keep the answer as it was givenSave the JSON that the ask command prints with --json, to a file. It carries the whole result, every citation included, and nothing else.
Re-check against the live caseEach citation is re-derived from the case as it is now and compared with the digest recorded when the answer was given. The index is never trusted for this.
Read the reason for any problemThe reasons are named: the record is missing, the source is missing, the exhibit no longer hashes to its recorded digest, the record has changed, the content has changed, or the citation is of a kind that cannot be re-checked.
Treat a change as a finding about the caseAn exhibit that no longer matches its digest is a matter for the chain of custody, not a formatting problem. Find out why before the report is disclosed.
File the result with the reportThe command prints how many citations resolve, and exits with a failure code when any does not, so it can gate a release step. Attach the line, with the date, to the report.
Commands
recoveryantra caseqa ask "Who did Meera meet at Cafe Lotus" --case F:\Case-211 --json
Print the whole result, citations included, as JSON to be saved to a file.
Re-check every citation in the saved answer against the case as it is now.
Options, and when to use them
--json
Print the whole structured answer. This is the file to keep if the citations are to be re-checked later.
--citation
A JSON file holding one citation, a list of them, or a whole saved answer.
Best practice
Re-check every citation on the day a report is finalised and again on the day it is disclosed
Keep each saved answer with the report it supports
Look into a citation that does not resolve before anything else
What this will not do
A citation into derived text, such as an Office document, UTF-16 or HTML, is a character position and not a byte offset. It is re-derived and compared by digest, and it carries no byte range
The check shows that the text is the same as when it was cited. It does not show what the text means
It opens only paths it derives from the case's own records, and refuses a path that leaves the case folder
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
4 scenarios
Sanitisation and disposal
Removing data on purpose, and being able to prove it was removed.
Verify that the disposal record has not been altered.
Options, and when to use them
--purge-method
Force a specific firmware method when the policy names one. Forcing a weaker method than the drive supports lowers the level reached, and the certificate will say so.
--examiner
The person accountable for the disposal under your policy.
--no-verify
Only for bulk passes over drives that will be physically destroyed anyway. An unverified certificate must never be presented to an auditor as a verified one.
<path>
Verify the disposal audit trail at the close of each batch.
Best practice
Record the level ACHIEVED, which is what the certificate states, not the level requested
Verify the audit trail for each batch
Keep certificates for the retention period the policy sets
What this will not do
The certificate states the level reached and its limits; it does not assert that recovery is impossible by any means
Destroy level requires physical destruction and no software provides it
Hit one of these limits? The situation chooser names the product or the method that gets past each one, case by case.
Flash storage remaps blocks internally, so an overwrite issued by the host does not reach the spare and remapped areas. The controller has to do the work.
How to recognise it
The device is an SSD, NVMe or flash module
Policy requires Purge rather than Clear
The drive supports a firmware sanitise command
Procedure
Establish what the drive itself supportsThe strongest method the drive advertises is used unless one is forced.
Issue the firmware sanitiseThe controller clears areas an overwrite cannot address.
Verify and read the certificate carefullyThe certificate records the level actually reached, which may be lower than requested.
Work arrives before it can be classified. Committing to a route before the media has been examined is how a job ends up needing a tool that is not on the bench.
How to recognise it
A customer description that does not match a category cleanly
Media of unknown type or condition
A deadline that does not allow a second procurement
Procedure
Triage the media before deciding anythingCondition and device class decide the route, and both are measured rather than assumed.
Image anything that is failing, before classifying it furtherThe condition question outranks the category question.
Then take the route the triage indicatesRecorder, phone, array and plain volume each go a different way.
Commands
recoveryantra list --triage
Condition, connection and device class for everything attached.
Part way through a routine recovery something is found that changes the nature of the job. What has already been done determines whether the work remains usable.
How to recognise it
A finding that suggests deliberate deletion, fraud or misuse
A client who now wants the result to be defensible
Work already done in recovery mode
Procedure
Stop and preserve the current stateDo not continue in recovery mode once the character of the job has changed.
Switch to forensic mode before the next actionIt hashes every item and writes the custody manifest. A recovery-mode scan does not become evidential retrospectively.
Record the point at which the change happenedBeing explicit about what was done under which mode is what keeps the earlier work usable.
The volume is encrypted with BitLocker, LUKS, FileVault or VeraCrypt. Without the credential there is nothing to recover, and with it the job is ordinary.
How to recognise it
The volume shows as encrypted or unrecognised
A recovery key or passphrase may exist somewhere in the organisation
The data is needed
Procedure
Find the credential before doing anything elseFor BitLocker this is frequently in Active Directory, a Microsoft account, or a printed recovery sheet.
Unlock and recover in one step where the volume type supports itThe recovery runs against the decrypted view.
For a container file, unlock it separatelyVeraCrypt and TrueCrypt containers are handled by their own command.
