The scenarios, in the app

Recover lost or deleted files

We'll ask a few simple questions, then find your files. Your original drive is only ever read, never written to.

1. Stop using the drivesafety - cannot skip

   Before anything else: unplug it, or stop saving to it. Every file written to a drive can land on top of the one you are trying to get back, and once that happens no tool can undo it. If the drive is the machine's own system disk, shut the machine down and read the drive from another computer.

   Universal first instruction in data recovery. R-Studio, UFS Explorer, Klennet and DMDE all lead with it.

2. Is the drive healthy or is it failing?

   We read its SMART data and try a few sectors at both ends, because flash dies from one region outwards. This is the question that decides everything after it: a failing drive must be copied before it is scanned, because every extra hour of scanning is an hour it might not survive. For the full measured answer - the recoverable-or-not verdict, with the unreadable fraction as a range and a PDF report - run the quick check on the source step ('Can it be recovered?'), or `check` on the command line.

   Assess before you act. The step every professional recovery workflow puts first and the one this product previously asked the user to guess at.

3. What are you recovering from?

   Pick the kind of storage. This helps us read it the right way.

4. Make a copy first, or recover directly?

   If the health check found ANY unreadable sectors, copy first - we then work on the copy and the drive is read once instead of repeatedly. Recover directly only when the drive read cleanly and you are in a hurry.

   Image first, work from the image. ACPO principle 1 in forensics; standard practice in recovery.

5. Where should the recovered files be saved?safety - cannot skip

   Choose a folder on a DIFFERENT drive. We never save onto the drive you're recovering - that could overwrite the very files we're trying to get back.

6. What happened / what do you want back?

   This focuses the VIEW, not the scan - we always recover everything, so you can widen it afterwards without scanning again.

7. Which device is it?

   Pick the exact drive from the list. Removable drives are shown; the drive this program runs from is disabled so you can't scan it by mistake.

8. Ready to start?safety - cannot skip

   We'll show you the drive we'll read, the folder we'll write to, and the free space - then begin. Nothing is written to the source.

9. Look at the files before you keep them

   Open a few before exporting. A file can come back with the right name and the right size and the wrong contents, if the space it used was reused after deletion - previewing is how you find that out while it still costs nothing.

   Preview before recovery. Offered by every major recovery tool and the step this wizard omitted.

10. Check what came back

    We confirm each exported file matches what we recovered, and tell you plainly about any we could not read whole. Files we know are wrong are marked, never quietly handed over.

    Verify the output. In forensic mode this is a SHA-256 manifest; in recovery mode it is a readability and completeness check.

Find the one file you actually wanted

You already have your files back. This narrows the results down to the one you actually came for, using the three things you can usually answer even when you cannot remember the filename: roughly when, roughly what kind, and roughly what it was called.

1. Roughly when did you last see it?

   A date range is enough - a month, or just a year. We match it against whichever date survived on each file (created, modified or last accessed); a file that kept none of its dates cannot be matched this way and is left for the other two questions to find.

2. Roughly what kind of file was it?

   Photo, video, audio, document or archive - the same groups the results screen already sorts everything into, so narrowing here never excludes a format quietly.

3. Roughly what was it called?

   A part of the filename is enough - "tax", "IMG_2021", "invoice". This matches the name only, not what is inside the file.

4. See the matches

   Every match is shown with the trust grade already worked out for it - a file whose contents do not match its name, or that came back empty, is marked so before you open it rather than after.

   No surveyed data-recovery competitor documents this last step at all - they report a count and offer a preview.

Recover from a virtual machine / virtual disk

We read the virtual disk directly and recover the files inside it, just like a real drive. The disk file is only ever read.

1. Which virtual disk format?

   This is the file the VM uses as its hard disk. We read all the common ones.

2. What do you need back?

   Files from inside the disk, or the whole disk carved (for a deleted/corrupt VM).

3. Where is the virtual disk file?

   Point us at the .vmdk/.vhdx/.vdi/.qcow2 file (or a copy of it).

4. Where should recovered files be saved?safety - cannot skip

   A separate drive - never inside the virtual disk or its folder.

5. Recover

   We open the virtual disk (`recover --image <file>`), read its filesystem, and recover files - including deleted ones. A snapshot chain is followed to its current state.

Databases need care: a running server must not be read raw. We'll find out the situation first.

1. Is the database server running or stopped?safety - cannot skip

   If it's running, we must NOT read the live file - it would be inconsistent. We'll guide you to stop it or take a snapshot.

2. Which database is it?

   We can also detect this from the file. It sets how we read the pages.

3. What happened?

   This chooses the technique.

4. Do backups exist?

   Always check first - restoring a good backup beats forensic extraction.

5. Where should recovered data be saved?safety - cannot skip

   A separate drive. We save extracted rows to a NEW database or CSV and keep the damaged original.

6. Recover

   We extract what's readable and tell you honestly what is validated versus lost - never a best-guess row.

First we CHECK the drive and tell you plainly whether recovery is realistic. Then we make a faithful copy - gently, so a failing drive isn't stressed - and you recover from the copy.

1. What do you want to copy?

   A drive, a phone, or an existing image file. Phones have their own guided steps.

2. Can it be recovered?

   Before any copying, we test areas right across the drive and tell you the chances: how much is unreadable, what you can expect back, and what cannot come back. You get the answer as a PDF report you can keep or send to us.

   Assess before you act - the step every professional recovery workflow puts first.

3. Where to save the image?safety - cannot skip

   A separate drive with room for the whole source - the app lists your drives with their free space and refuses the drive being copied. Choose raw (.img) or E01, the compressed format recovery labs open directly.

4. Start the copy?safety - cannot skip

   We copy in passes, skipping bad areas first and retrying them gently, and keep a map of what couldn't be read. You can stop at any time and continue later.

5. Sending it to a lab?

   An E01 is already compressed - hand it over as it is. A raw image can be zipped here; any lab can open a zip.

Copies a rooted Android's storage to an image file you can then work on, so the phone is read once instead of repeatedly.

1. Connect the phone

   USB debugging on, and the phone unlocked at least once since it was restarted - files stay encrypted until then, so a locked phone lists fine and reads nothing.

2. Where should the image be saved?safety - cannot skip

   A drive with room for the whole partition.

3. Copying

   Streamed in blocks with a live figure and a stop that stops. We compare the length against what the phone reported: a short image is reported failed, never handed over as whole.

4. Done

   The image goes into the ordinary recovery flow from here.

Runs a read-only agent on the far machine and copies a disk across the local network.

1. Pair with the other machinesafety - cannot skip

   Install and start the agent there; it offers its disks read-only. Both machines show the same pairing code.

2. Which drive should be copied?

   The agent lists what it can offer, with size and health.

3. Where should it be saved?safety - cannot skip

   A local folder with room for the whole drive.

4. Copying

   Live throughput and an estimate. The copy is verified by hash - a transfer that looks finished and is short is the failure this must never hide.

Cloud data is recovered two ways: the copy synced to this computer, and the provider's own version history / restore. We do both, honestly - we can't raw-read a cloud service.

1. Which cloud?

   This sets where the local copy lives and which restore to use.

2. Is there a synced copy on this computer?

   If the account was synced here, the files (or online-only stubs) are on the local disk and we recover them directly.

3. Where should recovered files be saved?safety - cannot skip

   A separate drive from the sync folder.

4. Use the provider's restore for the rest

   For anything not cached locally, use the provider's version history, point-in-time restore, or trash window (OneDrive Files Restore 30 days, Google/Dropbox version history, S3 versioning). We tell you exactly which and how long the window is.

5. Recover

   We recover the local sync cache and report the provider-side restore avenue for each file that lives only in the cloud.

This permanently erases a drive. Here the destination IS the target - the opposite of recovery - so we confirm very carefully.

1. Which drive should be erased?safety - cannot skip

   Pick carefully. The system disk, the drive this program runs from, and the report drive can never be erased.

2. Type the drive's serial number to confirmsafety - cannot skip

   Typing the serial back proves you picked the right drive. A simple 'yes' is too easy to click through.

3. How thorough?

   One zero-writing pass meets the NIST 'Clear' standard and is provable (we read it back). We don't claim more than we can prove.

4. Verify and issue a certificatesafety - cannot skip

   We read the drive back with our own recovery engine to confirm nothing is left, and produce a certificate stating what was achieved and its limits.

See everything this computer can see - drives it can use, drives it can see but not use, and why - and save it as a report.

1. Connect the device

   Plug it straight into the machine, not a hub; a desktop external drive also needs its mains adapter.

   ISO/IEC 27037 7.4 - identification of digital devices

2. Read what the computer sees

   Every device is listed, usable or not. One that is connected but cannot be used says why: cannot be read, needs administrator, in use, Windows cannot start it, or a phone in MTP mode.

3. Do what the row says

   A card the reader cannot address needs an SDXC reader; a bridge Windows cannot start needs power, cable, a USB 2.0 port or a different enclosure; a drive that reads but is failing goes to Image, not Scan.

4. Save the report

   HTML, PDF and JSON, with every device, its state, the Plug-and-Play inventory and the environment. Send it with any support request about a drive that is not detected.

One place to search the case's keyword hits, gallery and timeline; review every tag and bookmark; save a named filter for later; and read the case's own hash-chained action log.

1. Search the case

   Fans out to the keyword hit search, the gallery and the timeline's own text filter - no new search engine, the same ones those workspaces use.

2. Review tags and bookmarks

   Every finding and bookmark recorded anywhere in the case, filterable by kind, with its review state.

3. Save a filter for later

   Named presets held with the case itself, so the next examiner sees them too.

4. Read the examiner log

   The case's hash-chained trail, verified on the same screen: an altered, inserted or reordered entry is detected, not assumed absent.

   ISO/IEC 27037 7.6 - documentation

A hash, a phone number or an email that turns up in more than one case is a lead. This keeps a lab-wide store of those values and tells you which authorised cases share them, so a connection between two cases is not left to memory.

1. Look up a value

   Search the lab-wide store for a hash, phone, email or account and see every authorised case that carries it.

2. Add a case to the store

   Adding a case is an explicit, authorised act, never automatic on save. A case stored without authority is never shown as a correlation of another.

3. Correlate a case

   See what the current case shares with every other authorised case - stated plainly when there is nothing, never a blank screen.

See what is on the drive in seconds, tick the files or folders you want, and recover only those - instead of waiting for the whole drive and picking afterwards.

1. See what is on the drive

   We read the index - the filesystem's own record of names and folders, deleted entries marked - without touching any file's contents. Seconds, and free.

   Browse before recovering. R-Studio and DMDE both read the index first and let you choose.

2. Tick what you want back

   A ticked folder covers everything under it. Find by name, modified date or minimum size; deleted entries carry their recovery chances so you know before you commit.

3. Where should the recovered files be saved?safety - cannot skip

   A folder on a different drive. Only the ticked files are read and written - the destination never holds more than that.

4. Recover the selectionsafety - cannot skip

   Only what is ticked is read from the source and written out, under its own folder path rather than sorted by type.

5. Check what came back

   The same completeness check a full recovery gets, scoped to the files you actually asked for.

Windows says the disk must be formatted, or shows it as RAW. RECOVER FIRST, FORMAT SECOND - never the other way round: the files come out through the ordinary recovery, and only then is the disk given a fresh partition table and filesystem so it can be used again. Where the hardware is failing, this refuses and says so.

1. Get the files out firstsafety - cannot skip

   A format destroys exactly what a recovery exists to save. This door opens only after a recovery has finished, and where the scan found files that have not been exported it refuses and says how many.

   Recover before you repair - the ordering diskrepair and every professional workflow put first.

2. Check the drive is fit to be formatted

   Read-only, about 12 seconds: whether the disk reads at all, how many read errors, and whether it stays present and steady on the bus. A disk that drops or cannot be read is refused - formatting failing hardware only wastes what is left of it.

3. Choose the filesystem

   exFAT for cards and sticks used across devices, NTFS for a Windows-only disk, FAT32 where an older device needs it (4 GB file limit). The choices that do not fit the disk say why.

4. Type the drive's serial number to confirmsafety - cannot skip

   Typing the serial back proves you picked the right drive. The system disk and the disk this program runs from can never be formatted here.

5. Format and verifysafety - cannot skip

   A fresh partition table and filesystem are written, the disk is read back, and the record shows each step taken and the drive letter Windows gave it.

Plot every located photo and video in a case on an offline map - only files carrying real EXIF GPS appear, each on its own point with its source exhibit and its real capture time. The map works with no internet.

1. Open the case

   The map reads the exhibits already in a case. Open or create the case in Examination or Footage first; the map is then every located photo and video that case holds.

   ISO/IEC 27037 7.5 - collection and preservation

2. See the points on the map

   Every photo/video that carries EXIF GPS becomes a point; nearby points cluster, and a point names its source exhibit and real timestamp. The basemap is offline.

3. Narrow it down

   Filter by images or video, by date range, or to a single exhibit; turn on the track to join the timed points in order.

4. Open the source item

   Click a point to see the exhibit it came from, and open it in the gallery for the byte-exact original.

   ISO/IEC 27037 7.6 - documentation

5. Export the points

   Export the points to GeoJSON or KML - KML opens them, with the track and timestamps, in Google Earth, QGIS and other mapping tools.

Add a folder, file, recovery manifest or image and it runs the ordinary pipeline - hash, known-file classify, index, gallery, artefacts, and an opt-in carve - with a live dashboard per item.

1. Add the evidence

   A stage set is queued for it at once; carve is opt-in and only meaningful for an image.

2. Run the pipeline

   Each stage is isolated - one failing does not stop the others - and retryable; a resumed case skips finished stages.

3. Watch the dashboard

   Per-stage status, progress and counts, and the case's overall progress.

Build an entity/connections graph over the case's contacts, messages, calls, mail and browser history, and read it as a graph - never a guessed relationship, only what those parsers already found.

1. Build the graph

   Entities (devices, people, phones, emails, accounts, domains) and edges (sms/call/chat/email/contact/visit), each with its own provenance.

2. Explore it

   Degree, betweenness and community metrics; the shortest path between two entities; one entity's neighbourhood.

3. Bookmark an entity or a connection

   Recorded as a finding through the case's own door.

   ISO/IEC 27037 7.6 - documentation

Run a Volatility 3 plugin - processes, network, DLLs, handles, malware detection - against a memory image and read the result as a table.

1. Pick a plugin

   Processes, process tree, command lines, network connections, loaded DLLs, open handles, or a malware-detection plugin, for Windows, Linux or macOS.

2. Run it

   Offline by default; an honest refusal names what is missing (no image, Volatility 3 absent, symbols unavailable) rather than guessing.

3. Add a row to a finding

   The exact row, the plugin and the Volatility 3 version travel with it.

   ISO/IEC 27037 7.6 - documentation

A lab that reads a bare memory chip hands you a raw dump, not a disk. This works out the page and block geometry, unscrambles the controller, applies the chip's error correction and puts the blocks back in order, then writes an image the recovery flow can open.

1. Point at the raw dump

   The file the lab produced, spare (OOB) areas included. It is read-only; nothing is written to it.

2. Analyse first

   Read the dump and report the geometry, scrambling, error correction and block map. It writes nothing and tells you which figures, if any, the lab still needs to supply.

3. Where should the image be saved?safety - cannot skip

   A separate drive from the dump.

4. Rebuild the image

   Write the image, and read the count of pages the error correction could not fully fix before trusting it - a complete image is not the same as a fully verified one.

A RAID set is spread across several disks. Add each member (or a missing one, blank), let it work out the layout off the disks - Windows dynamic disks, Intel RST, SNIA DDF, Synology SHR / mdadm - or set the level yourself, check the assembled volume's partition table looks right, then recover from it exactly like a single disk.

1. Add the members

   Each disk or image in the set. They are only ever read, never written. A RAID 5 array still rebuilds with one member missing (RAID 6 with two) - mark a missing member's row blank so the array is rebuilt degraded.

2. Work out the layout

   Read the RAID metadata off the disks (LDM, IMSM, DDF, SHR / mdadm), or set the level, chunk size and layout yourself when there is no metadata to read.

3. Check the assembled volume

   See the rebuilt volume's partition table before committing. If it looks wrong, go back and set the level yourself rather than recovering from a bad assembly.

4. Recover from the array

   Hand the assembled volume to the ordinary recovery scan - the same results grid and export, licensed and charged like any single source.

A mask over a region of frames, a named person's typed decision, and an export that is refused until that decision says approve.

1. Mask the region

   Pixels in the frame, from one frame to another; optionally followed across frames. The original is never written to; the mask is a record with its own chain.

   SWGDE Best Practices for Forensic Video Analysis s9 - processing recorded and repeatable.

2. A named reviewer decidessafety - cannot skip

   Approve or reject, typed with a name and a note. The decision goes into the hash-chained audit trail and the report. Recorded by the software, not authenticated by an account system - and said so.

   ACPO principle 3 - a record of all processes, and who applied them.

3. Export the redacted copysafety - cannot skip

   Refused until an approve decision exists. The copy carries the mask chain and its hashes; the original stays as it was.

   ISO/IEC 27042 s8 - a derived item names what it was derived from.

Examine an image or file for concealed data - bytes appended after its end, a whole file embedded inside it, a known stego tool's signature, or a payload hidden in the pixels' least significant bits - then carve out what is found. The exhibit is read only and never changed.

1. Choose the file to examine

   Point at the exhibit - a photo, a scan, an audio file or any file a payload might be hidden in. It is opened read only.

   ISO/IEC 27037 7.5 - collection and preservation

2. Run the examination

   The battery checks for appended data, embedded files, known stego-tool signatures and LSB payloads (chi-square for sequential embedding, RS analysis for a payload estimate). Each step is shown as it runs.

3. Recover what was found

   Where something is found, carve it out to a folder you pick. A carve is confirmed only when identifiable bytes come back; anything uncertain is labelled so, never overstated.

4. Read the verdict and the limit

   The verdict is graded clean, likely or confirmed, with the methods used and the honest limit: content-adaptive schemes need a trained model pack, which the tool says is not installed rather than missing silently.

Walk a registry hive's keys and values, a property list's tree, or a SQLite database's tables and rows - or read any file as bookmarked hex.

1. Pick a viewer and a file

   Registry hive, plist, SQLite database, or hex - deleted keys/values and deleted/superseded rows are a switch away.

2. Walk the structure

   Subkeys and values with types; tables with schema and row counts, then a page of rows; a paged hex window with typed data interpretation.

3. Bookmark a byte range

   The bytes (up to 256) and their SHA-256 are captured, so a later reader can prove the mark still points at what the examiner saw.

   ISO/IEC 27037 7.6 - documentation