Which feature do I need?
Find the situation you are actually in. Each one says which feature to use, why that one rather than the obvious alternative, a real case with real numbers, the exact commands, and - the part most guides leave out - what NOT to do, because nearly every expensive mistake is somebody choosing a reasonable-sounding feature.
Files are missing
A drive, a card or a phone that still works, but the files have gone.
I deleted files and emptied the Recycle Bin
- The files are not in the Recycle Bin
- The drive is otherwise working normally
- It happened recently and little has been written since
Use: Recover lost or deleted files in RecoverYantraSuite
Deleting a file removes its directory entry, not its contents. The sooner you read the drive, the more of it is still there - and the first thing that matters is to stop writing to it.
A designer emptied the bin with 240 project files in it, noticed 20 minutes later, and unplugged the drive straight away. All 240 came back with their original names and folders, because nothing had been written over them in 20 minutes.
recover --device \\.\PhysicalDrive2 -o D:\RecoveredRead the drive, write the results somewhere else.
- Do NOT keep using the computer while you think about it. Every download, update and temporary file can land on top of what you are trying to get back.
- Do NOT save the recovered files onto the same drive. The pre-flight refuses it, and this is why.
I formatted the wrong drive
- Windows offered to format it and I said yes
- The drive now shows as empty
- It has the right capacity but no files
Use: Recover lost or deleted files, in smart mode in RecoverYantraSuite
A quick format writes a new, empty filing system over the old one. It does not erase the files themselves, so both routes are open: the old structures often survive, and anything they miss can be found by its contents.
A photographer formatted a 128 GB card in the wrong camera slot before a shoot. 3,180 raw files came back byte-exact, because a format had written a few megabytes of new filing system over 40 GB of untouched photographs.
recover --device \\.\PhysicalDrive3 -o E:\Cards --mode smartRead the old structures AND search by content, in one pass.
- Do NOT do a FULL format if you are asked again. A full format writes over every block and there is nothing left to find.
- Do NOT let the camera or phone write anything new to the card.
I need the photos and messages off a phone
- The phone works and unlocks
- You want the camera roll, chats or call history
- Nothing has been deleted, or something was deleted recently
Use: Get data off a phone in RecoverYantra Mobile
A phone cannot be read like a disk, so this copies what the phone itself will hand over, and reads the app databases where deleted rows often still sit.
A parent needed 8 months of a child's messages after a device was replaced. The camera roll copied over intact, and the messages database gave back 1,100 live messages plus 76 that had been deleted and were still in the file's free space.
phone --areasWhat can be recovered from which app, before you start.
phone --store messages.db --deleted-onlyRead one app's store and show the rows that were deleted.
- Do NOT expect a locked phone to be readable. Files stay encrypted until the first unlock after a restart, so a phone that lists fine can still read nothing.
- Do NOT keep using the phone if something was deleted. It writes constantly.
I don't know which of my drives has the data
- An external drive, an old laptop disk in a caddy and a couple of USB sticks are all attached at once
- You can describe the file - a name, roughly when it was made - but not which drive it is on
- Guessing wrong costs a full scan of a drive the file was never on
Use: Search across every drive at once in RecoverYantraSuite
A filesystem index reads in seconds and needs no licence; run over every USABLE attached drive it answers the question that comes BEFORE "recover from which drive" - the one the product otherwise assumes you can already answer. Each drive is only read once for its listing, so checking four candidates costs a couple of minutes total instead of committing hours, and a use of the licence, to the wrong one first.
A customer had one photo, 'IMG_2019_beach.jpg', somewhere across a 4 TB external drive, a 500 GB laptop disk pulled into a USB caddy, and two 64 GB USB sticks. Listing each drive's index by name took under two minutes combined and found the file on the third of the four, sparing three full scans - each of which would have taken hours - of drives it was never on.
list --triageSee every attached drive first, with its state and why any of them is not usable, before searching a single one.
recover --image \\.\PhysicalDrive2 --listRead one drive's index by name - the free, licence-free first look this situation is built on. Repeat for each candidate drive until the name turns up; a single sweep across every listed drive at once is the same engine call, one drive at a time.
- Do NOT run a full scan on every attached drive in turn hoping to get lucky - each full scan can take hours and spends a use per source under the licence, while reading the index alone is free and takes seconds.
- Do NOT judge a drive by its letter or its size alone. Two drives of a similar size look identical from the outside; only the index by name tells them apart.
The recovery finished but which of these is the one I actually wanted
- A finished recovery with tens or hundreds of thousands of files on screen
- You remember roughly when it was, roughly what kind of file, and part of the name - not the exact path
- The results grid is too big to scroll through by eye
Use: Find the one file you actually wanted in RecoverYantraSuite
The scan already recovered everything (the product never narrows a scan up front), so this is a filter on the results you already have, not another pass over the drive. It answers with the three things a customer can actually say - roughly when, roughly what kind, roughly what it was called - and shows RC1's trust grade (good / mismatch / empty / unknown) beside every match, so you are never sent to open a file that will not.
A customer recovered 229,104 files off a formatted 128 GB card and could not find the one photo of a 2021 receipt they needed for a tax return. Filtering to "2021", category Document, name containing "receipt" cut the grid from 229,104 to 7 matches in under a second, one marked mismatch and skipped.
search <recovery_dir> "receipt" --category documentFilter by category and part of the name; the date range narrows further on the results screen.
- Do NOT re-scan the drive narrowed to one file type to "search faster" - the product always recovers everything up front for exactly this reason, and a second scan costs another use under the licence for no benefit.
- Do NOT open the first file that looks close and assume it is right - check the trust grade shown beside it first; a mismatched or empty file wastes the one look you get before you notice it is wrong.
I ran CHKDSK and now files are missing, or the drive looks empty
- Windows offered to 'Scan and fix this drive' after an error, or you ran chkdsk /f yourself
- The drive now looks like a normal, working volume - not RAW, not asking to be formatted
- Folders that used to have files in them are empty, or the whole drive looks empty
Use: Recover lost or deleted files, in smart mode in RecoverYantraSuite
A repair tool can rewrite the index into something that still looks like a valid volume while pointing at the wrong place, so the drive stops asking to be formatted but also stops showing what it has. This reads the volume as it is now, and automatically tries the volume's own untouched spare copy of that index whenever the first read comes back essentially empty - nothing is written to get there.
A small business's 1 TB NTFS drive had chkdsk /f run on it after Explorer stopped showing the shared folder. Afterwards it mounted normally and reported the right free space, but recover came back with 0 named files. The volume's own backup boot sector, byte-identical and sitting in the last sector, was read instead: 4,180 files came back with their original names and folders, plus 6 fragments CHKDSK itself had already saved into FOUND.000.
recover --device \\.\PhysicalDrive2 -o D:\Recovered --mode fs --include-intactRead the volume as it stands now; the spare index copy is consulted automatically when the primary names almost nothing.
recover --device \\.\PhysicalDrive2 -o D:\Recovered --mode smart --include-intactAlso carve by content for anything neither copy of the index reaches.
- Do NOT run CHKDSK, or any other repair tool, a second time hoping it does better - each run writes to the very structures being read from here.
- Do NOT format the drive because it "looks empty" - an index that comes back with nothing is not the same as a drive with nothing on it.
The drive itself is in trouble
Noises, errors, disappearing, or not showing up at all.
The drive is clicking, or very slow, or gives read errors
- A repeated click, beep or grinding
- The computer freezes when it is plugged in
- Copying starts and then stalls
Use: Copy (image) a failing drive in RecoverYantraSuite
A dying drive has a limited number of reads left in it. Imaging takes the easy data FIRST and only then returns to the difficult areas, so you get the most out of it before it stops - and every scan afterwards runs against the copy, not the patient.
A 2 TB drive with a clicking head was imaged over 11 hours: 99.96% copied, 840 MB unreadable in 4 regions. It failed completely 2 days later. Everything recovered afterwards came out of that image, which would not have existed if the first move had been a scan.
list --triageCheck the drive's health before you touch it.
image --device \\.\PhysicalDrive2 -o D:\failing.dd --retries 1Copy it gently: few retries, easy data first.
- Do NOT run a normal scan first. A scan reads the whole surface repeatedly and can be the thing that finishes the drive off.
- Do NOT run CHKDSK or a repair tool. They WRITE to a drive that is already failing.
- Do NOT keep power-cycling it hoping it will behave.
The drive does not show up at all
- Nothing appears in Explorer or Disk Management
- It may not spin up, or the light does not come on
- It worked yesterday
Use: Find out why the drive will not read in RecoverYantraSuite
There are four links between plugged-in and readable, and only two of them are ours. Being LISTED is never proof of being READABLE, so this actually reads a sector at each end before saying anything.
A customer had followed 3 guides telling them to run as administrator. The check read sector 0 and a sector near the end, and found the drive absent from the bus entirely: an enclosure fault, not a software problem. 5 minutes instead of an afternoon, and a 4 TB drive that was fine once re-housed.
list --triageSay which link in the chain is broken, and whether it is ours.
- Do NOT buy recovery software until you know the drive is readable. No software reaches a drive the machine cannot see.
- Do NOT open the drive. The platters need a clean room, and opening it ends any chance a lab has.
The computer will not start, and the files are on its internal disk
- It fails before Windows loads
- You cannot get to the desktop to install anything
- The disk itself is probably fine
Use: Build a rescue USB in RecoverYantraSuite
The disk is usually healthy; it is the machine that will not start. Working from a USB means the broken system never runs, so nothing writes to the disk you are recovering.
A laptop that would not get past the logo was recovered from a USB: the disk was fine and a Windows update had failed half way. 96 GB of documents and photographs came off it untouched, in 3 hours.
bootusb --target \\.\PhysicalDrive4 --payload-iso linux.isoPrepare a stick that really boots.
acquireOn the booted machine: pick a disk and image it.
- Do NOT run Windows recovery or 'reset this PC' first. Both write to the disk, and reset can delete the files you want.
- Do NOT put the disk in another Windows machine without a write blocker - Windows writes to any disk it sees.
The drive works but the data is unreadable
Formatted, RAW, repartitioned, encrypted, or spread across several disks.
Windows says the drive needs formatting, or shows it as RAW
- 'You need to format the disk before you can use it'
- The drive shows 0 bytes, or the wrong size
- It was working and now is not
Use: Recover lost or deleted files, using the spare boot sector in RecoverYantraSuite
Usually one small structure has been damaged, not the data. Every filing system keeps a SECOND copy of what it cannot live without, and reading that spare copy often turns an unreadable drive back into a full list of files with their real names.
A wiped boot sector took a volume from 1 named file to 0. The backup boot sector, byte-identical, was sitting in the last sector of the same drive. Reading it gave back all 14,000 files with their names and folders.
recover --device \\.\PhysicalDrive2 -o D:\Out --mode smartFalls back to the spare copies when the primary structures will not parse.
- Do NOT click Format. That is the one action that makes this harder.
- Do NOT run CHKDSK. It writes its repairs onto the very structures somebody may need to read afterwards.
A NAS or RAID array has failed
- Two or more disks that were one volume
- The box will not rebuild, or rebuilt wrongly
- You have the disks but not the controller
Use: Recover from a RAID or NAS in RecoverYantraSuite
The array's layout - order, block size, parity rotation - can be worked out from the disks themselves, so the original controller is not needed. Each member is only ever read.
A 4-disk NAS lost its controller. The stripe size, disk order and parity pattern were detected from the members, the volume was reassembled read-only, and 2.4 TB of company files came back with their folder structure intact.
raid --members d1.dd d2.dd d3.dd d4.dd --auto --list-volumesWork the layout out from the disks and show what is on it.
raid --members d1.dd d2.dd d3.dd d4.dd --auto -o D:\OutRecover from the reassembled array.
- Do NOT let the NAS rebuild onto a replacement disk before imaging the members. A rebuild with the wrong assumption overwrites parity and can destroy what was recoverable.
- Do NOT change the disk order in the enclosure.
- Do NOT run this against a Drobo. A Drobo uses BeyondRAID, a proprietary block-virtualisation layer with no mdadm-style striping - --auto will scan for hours and detect nothing. See the hardware-help entry for what to procure instead.
A virtual machine will not start, or its disk is damaged
- A .vmdk, .vhdx, .vdi or .qcow2 file
- The hypervisor refuses it, or the guest will not boot
- Snapshots may be involved
Use: Recover from a virtual machine disk in RecoverYantraSuite
A virtual disk is a filing system inside a file. Reading the container gives access to the guest's own volumes, so the guest never has to start for its files to come out.
A finance server's 900 GB VHDX would not boot after a failed snapshot merge. The guest volume was read straight out of the container and all 41 GB of the accounts database came out without the machine ever starting.
recover --image server.vhdx -o D:\OutRead the guest volume inside the container.
- Do NOT keep trying to boot the guest. Each attempt writes to the disk.
- Do NOT delete or merge snapshots to tidy up first - the data you want may only exist in one of them.
The drive is encrypted and I have the password or recovery key
- BitLocker, LUKS or FileVault
- You have the recovery key, password or keyfile
- The volume will not mount normally
Use: Recover from an encrypted volume in RecoverYantraSuite
Everything on the drive is unreadable until it is unlocked, so this has to come first. Unlocking happens in memory against a read-only source: the drive itself is never modified.
A stolen-then-recovered laptop had BitLocker on and the owner had the 48-digit recovery password from their account. The volume was unlocked read-only and 300 GB recovered; not 1 byte was written to the drive.
recover --device \\.\PhysicalDrive2 -o D:\Out --password <recovery-key>Unlock read-only and recover in one pass.
- Do NOT try to recover from an encrypted volume without unlocking it first. Everything found will be meaningless.
- WITHOUT the key or password there is no route. Encryption that could be worked around would not be encryption.
One file will not open
Mail stores, databases, videos and archives - where the file is there and the application refuses it.
Outlook will not open the mailbox file
- 'The file is not an Outlook data file'
- Outlook reports it as damaged
- A .pst or .ost that used to work
Use: Recover a mailbox in RecoverYantraSuite
Outlook calling a file damaged MEANS the structures a normal reader depends on are gone. So the file is swept for the messages themselves, and each candidate is validated by its own contents rather than by an index that no longer exists.
A store whose header and both index pages had been zeroed returned 0 messages to a normal reader. Sweeping it recovered 6 of 6 messages with their subjects, dates and attachments. The same sweep against a renamed JPEG returned nothing, which is what makes the result trustworthy.
mail archive.pst --listSee what is in it before writing anything out.
mail archive.pst -o D:\MailOut --format emlRead it if it is healthy, sweep it if it is not.
- Do NOT run scanpst.exe on the only copy. It WRITES to the file, and on a badly damaged store it can make things worse.
- Do NOT work on the original. Copy it first and work on the copy.
A database file will not attach or open
- SQL Server, MySQL, Postgres, Oracle, SQLite or Access
- The server refuses to attach or start
- You need the rows, not the server
Use: Recover a database in RecoverYantraSuite
The rows are stored on pages inside the file, and those pages survive damage that stops the server. The rows can be read straight out of them - including rows that were deleted, which come back flagged so they can never be mistaken for live data.
A 40 GB MDF that SQL Server would not attach gave back 11.2 million rows across 63 tables, straight to CSV. 2,900 of them were deleted rows, marked as such in the export.
db --identify accounts.mdfIdentify it and say what can be extracted.
db --recover accounts.mdf --out D:\RowsWrite the rows out, deleted ones flagged.
- Do NOT run the vendor's repair with data loss allowed on the only copy. It works by DELETING what it cannot fix.
- Do NOT keep restarting the server. Recovery attempts write to the file.
A recovered video plays sound but no picture, or will not open
- The file is there and is roughly the right size
- Audio plays, the picture is missing or frozen
- VLC opens it but Windows Media Player does not
Use: Repair videos that will not play in RecoverYantraSuite
A video's index says where every frame is. If it is damaged, or was written last and lost, players cannot find the picture even though it is all there. Rebuilding the index is enough - and where frames really are missing, it says so instead of claiming a repair.
A card of phone videos came back 90% unplayable. The container header disagreed with the video's own index in every case. Sizing from the index and rewriting the header made them play: 1 clip stored as 939 MB was correctly 296 MB of video.
fixvideos D:\RecoveredRebuild the index and correct the header, working on copies.
fixwith --file broken.mp4 --reference good.mp4 -o D:\FixedUse a healthy file from the same camera for the hard cases.
- Do NOT re-encode the file with a converter. That bakes the fault in and loses quality permanently.
- Do NOT overwrite the original. Repairs always work on a copy.
I need footage off a security recorder's hard drive
- A disk out of a Hikvision, Dahua or similar NVR or DVR
- Windows says the disk is unformatted
- The footage may have been overwritten by newer recording
Use: Recover surveillance video in RecoverYantraSuite
Recorders use their own layouts, which is why a PC calls the disk unformatted. The video is found by its structure instead, and each clip is written so it will actually play on its own.
A shop's DVR disk showed as unformatted. 412 clips were recovered covering 9 days, each written with the parameter sets it needs to open in an ordinary player.
cctv --device \\.\PhysicalDrive2 --identify-onlyConfirm it is a recorder disk before committing hours.
cctv --device \\.\PhysicalDrive2 -o D:\FootageFind and extract the clips.
- Do NOT leave the disk in the recorder. It keeps recording, and it overwrites oldest first - which is exactly the footage you want.
- Do NOT let the recorder initialise or repair the disk.
I only need one camera between two times off the recorder disk
- The recorder disk or its image is here
- The incident is one camera and a known hour
- Nobody wants nine days of every channel
Use: Recorder view in RecoverYantraSuite
The recorder's own index is read in seconds and nothing is written: cameras down the side, time across, played straight from the disk. A cut of one camera between two times is remuxed losslessly with a sidecar naming the extent and the three times, so the whole disk is never carved for one hour of one channel.
A car park camera between 22:10 and 23:05 on a 4 TB Hikvision disk: the index of 20,000 entries took 1.8 seconds, the 55-minute cut on channel 3 was written in under a minute, and the other 15 channels were never touched.
cctv index \.\PhysicalDrive2List the cameras and their times from the recorder's own table (--json or --csv for a file).
cctv cut \.\PhysicalDrive2 --camera ch3 --from 2026-09-15T22:10:00 --to 2026-09-15T23:05:00 -o D:\FootageOne camera, one range, lossless, with its sidecar.
cctv download D:\Footage\ch3_c000412.mp4 -o E:\HandoverCopy a clip byte-exact with its digest.
- Do NOT carve the whole disk first when the index reads - that is hours, and the choice comes after. Carve when the table is gone, and the view says so ("inferred").
- Do NOT trust a time the disk did not give: a table-less disk shows "time unknown", never an invented channel number or clock.
Something has happened
Ransomware, an intrusion, a departing employee, a machine that must not be switched off.
I found something on one machine and need to know where else it is
- A file, a hash or a phrase turned up in one place
- There are hundreds of machines and you cannot image them all
- You need to know which machines are worth acquiring
Use: Sweep the estate in SakshyaYantra Forensic Suite
Imaging four hundred machines to answer one question is not an investigation, it is a year. A sweep asks every enrolled endpoint to look on its own disk and report yes or no. The data does not move; what comes back is the short list worth acquiring.
A leaked pricing document was found on one laptop. A sweep of 380 enrolled machines for its exact SHA-256 finished in 41 minutes and found it on 3 of them. Those 3 were imaged; the other 377 were never touched.
remote sweep --key <pairing-key> --sha256 <64-hex> --root C:\UsersFollow ONE file by its exact hash - the copy that left, not merely something with the same name. --root narrows where each endpoint looks, so hundreds of machines finish while you are still in the meeting.
remote sweep --key <pairing-key> --name *.kdbxFind password vaults nobody declared, by filename or pattern.
remote sweep --key <pairing-key> --text "project falcon"A phrase inside files. Bounded by size and file type on purpose, or a sweep becomes a full-text index of somebody's laptop.
remote live --host 10.0.4.22 --key <pairing-key> --volume C: -o D:\cases\hit-1.ddAcquire only the machines that had hits.
- Machines that were asleep or unreachable are reported as NOT ASKED. That is not the same as no hits, and a sweep that covered 200 of 400 machines and read as clean is worse than no sweep.
- A sweep returns paths and sizes, NEVER file contents. To read a file you acquire that machine, deliberately, and that is recorded.
- Sweep before you acquire. Acquiring first and searching afterwards is the expensive way round.
A seized phone is locked and I need a full forensic image, not a backup
- The phone is evidence, not a consenting owner's handset
- A backup or "get the photos" pull is not enough for the case
- You need to know BEFORE touching it whether a method exists for this exact chip
Use: Full mobile acquisition (checkm8 / Qualcomm EDL / MediaTek BROM, by device) in SakshyaYantra Mobile Workbench
Which method reaches a locked phone depends on its exact chip, not its brand, and the honest answer for a current flagship is often none in software. A plan is run BEFORE anything touches the device, so the examiner knows which method applies and what it needs, or that none does.
An iPhone 8 (A11) seized under a warrant answered CPID:8015 in DFU mode: checkm8 applied and the plan reported a proto-proven route needing only the physical device and checkra1n/ipwndfu to certify. A Galaxy S23 in the same case, running a modern Exynos, gave no public read path at all, and the plan named a licensed capability package as the only route rather than pretending one existed.
phone --methodsSee every method the Mobile Workbench carries: in-house protocol, detected external tool or licensed package, and its certification.
phone --plan "CPID:8015 ECID:001A70"Rank the methods that reach THIS exact device, honestly, before anything is touched.
- Do NOT run a consumer unlocking tool on seized evidence - the acquisition method and every step it took have to be on the record.
- Do NOT assume a locked flagship has no answer without checking --plan first: it names the licensed package that would actually reach it, rather than a guess.
Files have been encrypted and there is a ransom note
- Files renamed with an unusual extension
- A note demanding payment
- It may still be spreading
Use: Recover from a ransomware attack in RecoverYantraSuite
Some of what looks encrypted is not: files that were only renamed, partially encrypted, or whose originals survive in shadow copies, temporary files or free space. Those come back with no key and no payment. What genuinely is encrypted is said to be encrypted.
A file server hit overnight: 190,000 files renamed. 41,000 came back without any key - deleted originals still in free space, plus documents whose temporary copies had never been encrypted. The rest genuinely needed a key nobody had, and the report said so.
ransomware --dir E:\Shares --triageFind what comes back with no key at all.
ransomware --dir E:\Shares --verdictIdentify the family and give an honest plan.
- Do NOT delete the encrypted files. A decryptor may be published later, and without the files it will be useless to you.
- Do NOT reinstall or wipe the machine yet. It holds the evidence of how they got in.
- Do NOT pay before checking. A good proportion is often recoverable for nothing.
I need to acquire a machine that cannot be switched off
- A production server, or a machine in use
- Powering it down costs more than the investigation
- You need a consistent copy, not a smear
Use: Live acquisition in SakshyaYantra Forensic Suite
The volume is frozen at one instant and THAT is imaged, so the copy is a single point in time even though the machine keeps running. A plain read of a live disk is an image of no single moment: databases half-written, files half-copied.
A finance server could not be stopped during month-end. Its 800 GB volume was frozen in 16 seconds, imaged over 4 hours while the server kept working, and verified unchanged across the whole acquisition. The report also records that the acquisition wrote to the machine, because creating a snapshot allocates space.
remote volumes --host 10.0.4.22 --key <pairing-key>Ask what it has and whether it can be frozen.
remote live --host 10.0.4.22 --key <pairing-key> --volume C: -o D:\case.ddAcquire it while it runs.
- Do NOT just copy the files with Explorer or robocopy. You get a collection of moments, not a copy of one.
- Do NOT reboot to get a clean state. That destroys everything held only in memory and in open files.
I need to acquire a staff machine without going to it
- The machine is at another site, or with the person
- Collecting it would announce the investigation
- The organisation owns and administers it
Use: Endpoint agent and roster in SakshyaYantra Forensic Suite
An agent deployed with the rest of the fleet software means acquisition is a decision rather than a project. Machines report in, so you pick one from a list instead of scanning.
An agent was pushed to 380 machines by Group Policy months before it was needed. When a leak was suspected, the laptop was picked off the roster and imaged the same afternoon, from a different building, without the custodian being involved.
remote package --platform windows -o D:\rollout --msi --server console.example.internalBuild the pushable installer, with the console baked in.
remote rosterSee what enrolled, and what can be reached right now.
- Do NOT install the agent on a machine you already suspect. It announces the investigation and changes the machine.
- Do NOT assume enrolled means reachable. A laptop on a home network appears on the roster and cannot be acquired until it is back on a network you can reach.
I need to know what somebody did on this computer
- Which files were opened, copied or deleted
- What was plugged in, and when
- Which programs ran
Use: Forensic examination and timeline in SakshyaYantra Forensic Suite
Windows records far more than most people expect - the recycle bin, the change journal, prefetch, the registry, shortcuts, event logs, jump lists, shellbags and browser history. On one timeline they answer questions no single artefact can.
A departing employee denied copying anything. The change journal, shortcut files and shellbags together showed a USB device connected at 18:42 and 1,100 files opened from it over 11 minutes, corroborated across 3 independent artefacts.
recover --image case.E01 -o D:\case-out --profile forensicExamine the verified image, hashing everything.
timeline D:\case-out --out D:\case-out\timeline.csvPut the artefacts on one timeline.
- Do NOT examine the original machine. Work from a verified image, or every finding rests on something that has since changed.
- Do NOT rely on one artefact. Corroborate across several - that is what makes a finding hold up.
The data is in Microsoft 365 or Google Workspace, not on a disk
- The estate is mostly cloud
- You need a mailbox or a drive, not a machine
- The organisation owns and administers the accounts
Use: Authorised cloud acquisition in SakshyaYantra Forensic Suite
After an attack on a largely virtual estate the cloud IS the estate. The organisation's own administrator authorises it, the scope is recorded before anything is collected, and mail arrives as .eml so it opens anywhere.
An incident covering 3 months of 1 mailbox: the date range was applied by the provider, keywords were matched against the decoded messages, and 2,400 items were collected as .eml with a manifest, an authorisation record and a separate error report naming the 11 items that did not come back.
mail export.pst -o D:\Cloud --format emlIngest the administrator's Purview or Vault export.
- Do NOT collect a whole mailbox when the authority covers a date range. That is over-collection, and you answer for it.
- A token found on a seized device is NEVER used for this. That route is identify-and-report only.
Getting rid of a drive safely
Selling, returning or scrapping hardware, and being able to prove it was cleared.
I am selling, returning or scrapping a drive
- The drive leaves your control
- It held personal or company data
- You may need to show it was cleared
Use: Securely erase a drive in RecoverYantra Wipe
Deleting and formatting leave the data in place. Overwriting every block does not - and this then runs the recovery engine over the result, so the certificate says what was actually achieved rather than what was intended.
40 laptops going back at the end of a lease were cleared to NIST SP 800-88 Clear, each verified by running the recovery engine over the erased drive and finding 0 files, each with a certificate naming the drive's serial number.
erase \\.\PhysicalDrive3 --confirm <serial> --examiner "A Sharma"Overwrite, verify with our own recovery engine, and issue a certificate.
- Do NOT rely on a quick format or on deleting the partitions. Everything is still there.
- Overwriting cannot reach a flash drive's spare pages, so for an SSD holding something truly sensitive, physical destruction is the only complete answer. The certificate says this.
I need to show that I did not alter the evidence
- The work may be reviewed or challenged
- A client, auditor or court will ask
- You need more than an assurance
Use: Write-block verification and the audit trail in SakshyaYantra Forensic Suite
This engine has no write path to a source at all - but that is an assertion, and an assertion is not evidence. So the source is fingerprinted before and after the job, the audit trail is hash-chained so an edit or deletion is detectable, and the report states which regions were checked rather than claiming the whole drive.
An examination was challenged 18 months later. The sealed audit trail verified unbroken across all 4,180 entries, and the before-and-after fingerprints of the exhibit matched over the 9 regions the report had named at the time.
validate --out D:\reportsRun the tool's own validation against images whose contents are known.
audit D:\case-out --manifest D:\case-out\recovery_manifest.jsonCheck the trail is unbroken, including anything cut off the end.
- Do NOT rely on 'the tool is read-only' as your answer. Measure it and put the measurement in the report.
- Do NOT leave the audit trail unsealed. A chain cannot detect a tail that was cut off; the seal is what catches that.
Video has to become evidence
CCTV exports, phone clips and recorder drives that have to be read, reviewed, redacted or authenticated for a case.
The recorder export will not play, and it is evidence
- A .dav, .h264 or vendor file from a DVR
- Windows Media Player and VLC refuse it or show green
- Nobody has hashed it and the station needs a certificate
Use: Bring the footage in through the decode ladder in SakshyaYantra Forensic Suite
Recorder exports are the vendor's own container, and a normal player gives up at the first thing it does not know. The ladder tries the container, then the index, then the raw stream, then salvage - and records which rung produced each frame, so what you show later can be traced to this file.
A district cyber cell had 3 channels of a Hikvision export nobody could open. The ladder read 2 through the index and salvaged the third from the raw stream: 18,420 frames, 61 of them marked salvaged, hashed and in the case in 25 minutes.
footage acquire E:\E3\ch07.dav -o F:\Case-176\decodedDecode it through the ladder to another drive.
footage intake F:\Case-176\decoded --case F:\Case-176 --examiner "S. Menon"Record the intake with the examiner named.
- Do NOT re-encode it with a converter first. The converter's frames are not the recorder's frames, and the overlay clock is the only clock the recorder gave you.
- Do NOT play it from the pen drive it came on. Copy and hash it first; the intake does both.
The court wants the frames that show the vehicle, with the time
- A specific moment in a long recording
- A request for stills the defence can check
- The video itself must not be handed out
Use: Capture a frame pack in SakshyaYantra Forensic Suite
A screenshot has no provenance. A frame pack has every frame with its presentation ticks, its decoded index, the overlay clock as text, the source hash and the frame's own SHA-256, plus a hashed manifest - and it is the only unit that ever leaves the machine.
Four frames, 1410 to 1416 every second one, went to the court as a 2.1 MB pack. The defence expert verified it against the manifest in 30 seconds; the 9 GB recording never left the station.
review open F:\Case-176\decoded\ch07.mp4The timeline: frames, keyframes, gaps.
review frames F:\Case-176\decoded\ch07.mp4 --from 1410 --to 1416 --interval 2 -o F:\Case-176\packsThe pack.
review verify F:\Case-176\packs\pack_001.zipRe-hash it before it leaves.
- Do NOT send a screenshot or a player's snapshot. It has no time base, no hash and no chain.
- Do NOT write the overlay clock down as the time of the event. It is the recorder's clock, as text; the case time is a separate field with its own uncertainty.
The other side says the clip was cut or faked
- A claim of editing, re-encoding or synthesis
- A file with no known history
- A court that will ask which method said what
Use: Examine authenticity in SakshyaYantra Forensic Suite
One score convinces nobody. The workbench runs every method - structure, codec history, double compression, frame statistics, the optional model packs - reports each result or refusal, and ranks the hypotheses with the methods for and against each. The examiner writes the conclusion.
A 42-second clip said to be original carried 2 encoding generations and a container written by an editor released 3 years after the recorder. 5 methods supported "re-encoded", 1 refused, 0 supported "original"; the ranking and every method output went into the report.
authenticate E:\Exhibits\E5\clip.mp4 --case F:\Case-176Every method, the ranking, the record in the case.
- Do NOT quote a model's verdict as the finding. A model output is an observation; the methods and the examiner make the finding.
- Do NOT examine the only copy. Hash it, copy it, examine the copy.
I need a clip off the recorder with the time on it, playable, and a still for the report
- The clips are already extracted from the recorder disk
- One customer or insurer needs ONE exact clip, not the whole extraction
- The report needs a still frame, and it has to be somebody's exact moment, not a screenshot
Use: Play, cut and hand over CCTV clips in RecoverYantraSuite
The Suite carries the same player, clip download, custom-download and enhance the forensic family has (R-CCTV-PARITY) - because a recovery customer wants a playable, timestamped clip just as much as an examiner does. A custom cut is remuxed losslessly by default (the recorder's own compressed pictures, not re-encoded), and only becomes an exact-frame re-encode when you ask for it and the screen says every pixel is now new.
A retail customer needed 90 seconds of a till camera for their insurer. The recorder's own index gave 6 cameras and 340 clips; `cctv custom` cut frames 1200-3900 of camera 3 losslessly (2.6 MB instead of the 1.1 GB source clip) and `cctv frames` captured 4 stills for the claim form in under a second.
cctv index E:\dvr.ddSee the recorder's own camera x time table before extracting anything.
cctv cut E:\dvr.dd --camera 3 --from 1700000000 --to 1700000090 -o D:\HandoverCut straight off the disk, by camera and time, with no separate recovery step first.
cctv download D:\Footage\clip_00000000.h264 -o D:\HandoverHand over one clip exactly as carved, SHA-256 verified.
cctv custom D:\Footage\clip_00000000.h264 --from 1200 --to 3900 -o D:\HandoverCut the range that matters, losslessly by default.
cctv frames D:\Footage\clip_00000000.h264 --from 1200 --to 1206 -o D:\HandoverA few stills for the report or the claim form.
cctv report D:\Footage -o D:\HandoverA written report of clips, channels, times and hashes.
- Do NOT zip up the whole extraction and send it - a customer or insurer asked for one clip, and sending everything else needlessly widens who sees the footage.
- Do NOT re-encode by default. --reencode changes every pixel; the plain cut keeps the recorder's own bytes and says so on screen.