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 a recoverable array becomes unrecoverable.
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.
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 timeline D:\cases\IR-2026-014\out
Build the timeline from the verified copy.
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.
Commands
recoveryantra mode forensic
Set before any acquisition or scan.
recoveryantra audit E:\Case\Ex1\audit_trail.jsonl
Verify the chain and name the first break, if any.
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.
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, the time base.
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.
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.
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 every method and read the refusalsStructure, codec history, double compression, frame statistics and the optional model packs each report a result or a refusal; a method that cannot judge this file says so.
Read the ranked hypothesesEach names the methods that support it and the ones that oppose it. The software ranks the evidence; the examiner writes the conclusion.
Put the record in the caseThe examination record, with every method's output and the file's digest, is written to the case folder for the report.
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.
