{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigsvc7somiyzrzsrkwltknvtbs3zcxewykcxjfsstkhtuezudur3y",
    "uri": "at://did:plc:z2irh2ogqmggn53qmpyi3e7s/app.bsky.feed.post/3mitcjjmv2sp2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibvp57rqha4w5de456y45lnheshmrbezq5wqddm5zh7f7mnxapice"
    },
    "mimeType": "image/png",
    "size": 1192916
  },
  "description": "Learn how to image a disk with dd, recover deleted files with Foremost and Scalpel, and document your entire investigation with forensic-log-tracker. A step-by-step beginner guide.",
  "path": "/digital-forensics/digital-forensics-for-beginners/",
  "publishedAt": "2026-04-06T12:50:53.000Z",
  "site": "https://niklas-heringer.com",
  "tags": [
    "GitHub - mev0lent/forensic-log-tracker: A modular, secure CLI tool for forensic professionals and students.A modular, secure CLI tool for forensic professionals and students. - mev0lent/forensic-log-trackerGitHubmev0lent",
    "README",
    "dd - ArchWikiArchWiki",
    "forensics challenge series",
    "readthrough on the basics",
    "in their own post",
    "here"
  ],
  "textContent": "Last summer i had a course on digital forensics basics in university. I loved digging for clues and information, yet the documentation part of it all, somehow bringing in a legal context aswell, kind of bothered me and my colleagues. We decided to change that, to make documentation as seamless as possible for our purposes. forensic-log-tracker is the outcome of this.\n\nGitHub - mev0lent/forensic-log-tracker: A modular, secure CLI tool for forensic professionals and students.A modular, secure CLI tool for forensic professionals and students. - mev0lent/forensic-log-trackerGitHubmev0lent\n\n💡\n\nIn this post, let's both ****learn the basics of digital forensics**** and how to ****document properly****!\n\n# You Found the File. Now Prove You Didn´t Touch It.\n\n**Picture this:** a Linux machine gets flagged. Someone deleted something they shouldn't\nhave. You're handed the system, told to investigate, and, after twenty minutes with\nthe right tools, you recover the file.\n\nNice work. But then comes the question nobody prepares beginners for:\n\n> _Can you prove the disk image wasn't modified after you received it? Can you prove your timestamps are clean? Can you show, step by step, exactly what you did, and in what order?_\n\nIn a real DFIR engagement, that documentation is the investigation. In a CTF with\nforensics scoring, it's what separates a flag submission from an actual write-up worth\nreading. And if you ever want to work in incident response professionally, chain of\ncustody isn't optional **but rather the actual job**.\n\nMost beginner forensics guides teach you the recovery part. Almost none of them teach\nyou the documentation part. This one does both.\n\nBy the end of this guide, you'll know how to:\n\n  * Create a forensic disk image without altering the original evidence\n  * Recover deleted files using two battle-tested carving tools\n  * Log every step of your investigation automatically, timestamped and signed\n  * Generate a clean, shareable investigation report when you're done\n\n\n\nNo prior forensics experience needed. A Linux terminal and 20 minutes is enough.\n\n* * *\n\n# The Setup: What You Need and Why\n\n## The Lab Image\n\nYou don't need special hardware, a seized hard drive, or a professional forensics\nworkstation.\n\nEverything in this guide runs on a standard Linux terminal: Kali, Ubuntu,\nDebian, all work fine.\n\nInstead of building a disk image from scratch, I've prepared one for you. It's a 20MB\next4 image with several deleted files hidden inside, along with some stuff\nthat carving tools alone won't find. **Your job is to recover them.**\n\nDownload it and verify its integrity before touching anything:\n\n\n    wget https://github.com/mev0lent/forensic-log-tracker/releases/download/lab01-v1.0.2/lab01.img\n    wget https://github.com/mev0lent/forensic-log-tracker/releases/download/lab01-v1.0.2/lab01.img.sha256\n\n    # Verify the image hasn't been tampered with\n    sha256sum -c lab01.img.sha256\n\n\nYou should see `lab01.img: OK`. If you don't, re-download before continuing. A hash mismatch means the file is corrupted or modified.\n\n> This verification step is your first act of forensic discipline: you're establishing that the evidence you received is exactly what was published, unchanged. Write down that hash. You'll understand why that matters in a moment.\n\n## Install the Tools\n\nYou'll need two carving tools and forensic-log-tracker for the documentation layer.\n\n\n    # Carving tools\n    sudo apt install foremost scalpel\n\n    # forensic-log-tracker (I suggest you do this inside a python venv)\n    pip install forensic-log-tracker\n\n\nHere's what each one does before we go deeper:\n\n  * **dd:** creates bit-for-bit copies of disks or images. Already installed on (most)\nLinux systems, no action needed.\n  * **foremost:** scans raw disk data and recovers files based on known file signatures.\nFast, straightforward, good default choice.\n  * **scalpel:** similar to Foremost but config-driven. More work to set up,\nsignificantly more control over what you're looking for.\n  * **forensic-log-tracker:** our CLI tool that executes forensic commands, logs their\noutput, hashes everything with SHA256, and optionally signs the log with your GPG key. Built by me and my colleagues exactly because documentation kept getting in the way.\n\n\n\nOn first run, `flt` initializes most of your config automatically, yet you still have to do\n\n\n    flt setup\n\nJust go with the GPG setup, it is there to cryptographically testify that nothing was altered by you in your research :D\n\nYou actually don´t need to use your real name for this yet in an official matter it would be wise. I did it like this for now:\n\nSetup a passwordfor your key and you're ready to go!\n\nNow open `~/.config/forensic-log-tracker/config.yaml` and set your analyst name before continuing; it gets embedded in every log entry.\n\n## The Golden Rule: Never Touch the Original\n\nBefore a single command runs against evidence, this principle needs to be locked in:\n\n> **Never investigate the original. Always image first, work on the copy.**\n\nThis is the difference between admissible evidence and compromised evidence.\n\nThe moment you mount a disk, your OS starts writing to it: access\ntimestamps update, journal entries get created, metadata shifts.\nEven _reading_ a file changes things.\n\n`lab01.img` is your original. You'll make a working copy of it in the next step,\nand that copy is what every subsequent command will touch. **The original stays exactly\nas it was when you verified that hash.**\n\nThat mindset is what the rest of this guide is built on.\n\nLet's create our project, our **case** , according to the README.\n\n\n    flt new-case practicing01 --description \"Investigating a suspicious image most likely containing deleted evidence\"\n    2026-04-05 15:46:49,864 [INFO] New case created: ...\n    [+] Logs for case 'practicing01' will be stored in: ...\n\n\n* * *\n\n# Step 1 | Working With the Image (dd)\n\nBefore Foremost and Scalpel can do anything, you need a working copy of `lab01.img`\nto investigate. This is where `dd` comes in.. and where most beginners skip a step\nthey'll later regret.\n\n## What dd Actually Is\n\ndd - ArchWikiArchWiki\n\n`dd` stands for **Disk Dump**. It's a Unix tool that's been around since the 1970s and\ndoes exactly one thing: copy data block by block, byte by byte, without caring about\nfilesystems, file names, or structure. It sees your disk the way a photocopier sees\na document; it doesn't read words, it copies pixels.\n\nThat property is what makes it forensically valuable. When you copy a file with `cp`,\nthe operating system interprets the filesystem and gives you the file's contents. When\nyou copy with `dd`, you get everything, _including_ the empty space, the deleted sectors,\nthe fragments between files. That's exactly where your evidence hides.\n\n## Create Your Working Copy\n\n> **Remember:** Never run your investigation tools directly against `lab01.img`. That's your original. Treat it like a sealed evidence bag. Make a copy first:\n\n\n    flt run \"dd if=lab01.img of=working_copy.img bs=4M conv=noerror,sync status=progress\" --case practicing01\n\nEvery flag here has a reason:\n\nFlag | What it does\n---|---\n`if=lab01.img` | Input (the image you downloaded)\n`of=working_copy.img` | Output (0your investigation copy)\n`bs=4M` | Read and write in 4MB chunks, faster than the default 512 bytes\n`conv=noerror` | Don't stop if there's a read error — keep going\n`conv=sync` | If a block can't be read, pad it with zeros instead of skipping it\n`status=progress` | Show live progress so you're not staring at a blank terminal\n\n`conv=noerror,sync` together is the forensic standard. A real damaged drive will have\nbad sectors. Without these flags, `dd` would stop at the first read error and you'd\nlose everything after it. With them, you get a complete image with problem areas\nmarked as zeros: recoverable, documented, intact.\n\n## Verify the Copy\n\nNow hash both files and confirm they match:\n\n\n    flt run \"sha256sum lab01.img\" --case practicing01\n\n    # you can also use `-c` instead:\n    flt run \"sha256sum working_copy.img\" -c practicing01\n\nBoth hashes should be identical. If they are, you have a verified, pristine copy of\nthe original and you can prove it. If they differ, something went wrong during the\ncopy. Run it again before continuing.\n\n> This is the hash you'd record in a real chain of custody document. In a court\n> context, matching hashes are how you demonstrate that the evidence you analyzed\n> is identical to the evidence you received.\n\nEach command gets logged with its output, a SHA256 hash of that output, a timestamp,\nand a formal explanation of what the command does, _automatically with forensic-log-tracker_. Your investigation timeline has already started. **Congratulations!**\n\n## Take a Look Inside.. Without Mounting\n\nBefore running carving tools, it helps to understand what the filesystem looks like.\nYou can query the image directly without mounting it:\n\n\n    flt run \"fdisk -l working_copy.img\" -c practicing01\n    2026-04-05 16:17:41,881 [INFO] Executing command: fdisk -l working_copy.img\n    2026-04-05 16:17:41,918 [INFO] Log written to: .../logs/practicing01/2026-04-05T14-17-41-881642+00-00_command.log\n    2026-04-05 16:17:41,918 [INFO] Command executed, logged: fdisk -l working_copy.img\n    2026-04-05 16:17:42,508 [INFO] Signed logfile: 2026-04-05T14-17-41-881642+00-00_command.log.sig\n\n    [+] Command Output:\n    [STDOUT]\n    Disk working_copy.img: 20 MiB, 20971520 bytes, 40960 sectors\n    Units: sectors of 1 * 512 = 512 bytes\n    Sector size (logical/physical): 512 bytes / 512 bytes\n    I/O size (minimum/optimal): 512 bytes / 512 bytes\n\n    [STDERR]\n\n\nThis shows you the partition table, whether it's MBR or GPT, where partitions start,\nwhat filesystem types are present. For `lab01.img` you'll see a single ext4 partition.\n\nIf you want to dig one level deeper and see what files the filesystem still knows\nabout (including entries for deleted files), use `fls` from the Sleuth Kit:\n\n\n    sudo apt install sleuthkit\n    flt run \"fls -r working_copy.img\" -c practicing01\n    \\2026-04-05 17:36:24,805 [INFO] Executing command: fls -r working_copy.img\n    2026-04-05 17:36:24,856 [INFO] Log written to: .../logs/practicing01/2026-04-05T15-36-24-804919+00-00_command.log\n    2026-04-05 17:36:24,856 [INFO] Command executed, logged: fls -r working_copy.img\n    2026-04-05 17:36:36,784 [INFO] Signed logfile: 2026-04-05T15-36-24-804919+00-00_command.log.sig\n\n    [+] Command Output:\n    [STDOUT]\n    d/d 11:\tlost+found\n    r/r 15:\treadme.txt\n    V/V 5121:\t$OrphanFiles\n    + -/r * 12:\tOrphanFile-12\n    + -/r * 13:\tOrphanFile-13\n    + -/r * 14:\tOrphanFile-14\n\n    [STDERR]\n\n\nYou'll notice something interesting: even though files were deleted, some of their\nnames still appear in the output, _marked with an asterisk_. The filesystem remembers\nthat something was there, even if it can't give you the contents back through normal\nmeans. **That's what the next two tools are for.**\n\nIf terms like ext4, inodes, or partition tables are new and difficult to you, I covered all of\nthat in depth in my forensics challenge series, worth reading before continuing.\n\n> The second part there specifically is about sleuthkit if you want to read more on that toolsuite.\n\n## Checkpoint: dd\n\nAt this point you should have `working_copy.img` on disk, two\nmatching SHA256 hashes, an active `flt` case with three logged entries, and a rough\npicture of what the filesystem contains. If anything is missing, go back before\ncontinuing. **Everything from here builds on this foundation.**\n\nKnowledge Check\n\n0 / 5 correct\n\nQuestion 1 of 5\n\nnext →\n\nfinal score\n\n↺ restart quiz\n\n# Step 2 | Recovering Deleted Files with Foremost\n\nYou've got a verified working copy and a case log already running. The filesystem\ntold you something was deleted. Now we go get it back.\n\n## How File Carving Actually Works\n\nBefore running anything, it's worth understanding what's happening under the hood because it changes how you interpret the results.\n\nWhen a file gets deleted on Linux, the OS doesn't wipe the actual bytes. It just\nupdates the directory entry to say \"this space is available.\" The raw data sits\non disk, untouched, _until something else gets written over it_.\n\nFile carving exploits exactly that. Instead of asking the filesystem _\"what files\nexist?\"_, carving tools scan the raw disk byte by byte, looking for **known file\nsignatures**, specific byte sequences that mark the beginning and end of known\nfile types.\n\nA JPEG, for example, always starts with these bytes:\n`FF D8 FF`\n\nAnd ends with:\n`FF D9`\n\nForemost knows hundreds of these signatures. It scans your image from start to\nfinish, finds, e.g., a `FF D8 FF`, calls that the start of a JPEG, then keeps reading\nuntil it hits `FF D9`, and extracts everything in between as a recovered file.\n\nThis is also why plain text files are harder to recover with carving tools. A\n`.txt` file has no magic bytes. There's no universal \"text file starts here\"\nsignature, it's just... characters. We'll come back to that limitation in a\nmoment.\n\n## Running Foremost\n\nPoint it at your working copy, never the original:\n\n\n    flt run \"foremost -i working_copy.img -o foremost_output/ -v\" -c practicing01\n    ... # same as always, flt context, then:\n    [+] Command Output:\n    [STDOUT]\n    Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus\n    Audit File\n\n    Foremost started at Sun Apr  5 17:40:37 2026\n    Invocation: foremost -i working_copy.img -o foremost_output/ -v\n    Output directory: .../foremost_output\n    Configuration file: /etc/foremost.conf\n    ------------------------------------------------------------------\n    File: working_copy.img\n    Start: Sun Apr  5 17:40:37 2026\n    Length: 20 MB (20971520 bytes)\n\n    Num\t Name (bs=512)\t       Size\t File Offset\t Comment\n\n    0:\t00010848.jpg \t      31 KB \t    5554176\n    1:\t00010912.pdf \t       7 KB \t    5586944\n    Finish: Sun Apr  5 17:40:38 2026\n\n    2 FILES EXTRACTED\n\n    jpg:= 1\n    pdf:= 1\n    ------------------------------------------------------------------\n\n    Foremost finished at Sun Apr  5 17:40:38 2026\n\n    [STDERR]\n    Processing: working_copy.img\n    |*|\n\n\nFlag breakdown:\n\nFlag | What it does\n---|---\n`-i working_copy.img` | Input (the image to scan)\n`-o foremost_output/` | Output directory (Foremost creates this automatically)\n`-v` | Verbose — shows progress as it scans\n\n### Reading the Output\n\nForemost creates a structured directory for you:\n\n\n    ls foremost_output/\n    # audit.txt   jpg/   pdf/\n\n\n  * `audit.txt` — the full log of everything Foremost found, including file offsets\nand sizes. Always read this.\n  * `jpg/` — recovered JPEG files\n  * `pdf/` — recovered PDF files\n\n\n\nCheck what was recovered:\n\n\n    flt run \"ls -lh foremost_output/jpg/ foremost_output/pdf/\" -c practicing01\n    ...\n    [+] Command Output:\n    [STDOUT]\n    foremost_output/jpg/:\n    total 32K\n    -rw-rw-r-- 1 user user 32K Apr  5 17:40 00010848.jpg\n\n    foremost_output/pdf/:\n    total 8.0K\n    -rw-rw-r-- 1 user user 7.7K Apr  5 17:40 00010912.pdf\n\n    [STDERR]\n\n> You should see at least one file in each directory. Open them.. if the JPEG renders and the PDF opens, the carve was successful.\n\n### The audit.txt File\n\nThis is the most important output Foremost produces, and most beginners ignore it.\nOpen it:\n\n\n    flt run \"cat foremost_output/audit.txt\" -c practicing01\n\n\nIt tells you exactly where on the disk each file was found, its **byte offset**.\nIn a real investigation, this offset is evidence: it tells you where on the\nphysical disk the file lived, which can help establish whether files were\nplanted, copied, or native to the system.\n\n> In a legal context, being able to say \"this file was recovered from bytes 0–814 of the disk image, which corresponds to the first partition\" is significantly more useful than just saying \"we found a JPEG.\"\n\n## The Limitation Foremost Can't Get Around\n\nRun this now:\n\n\n    flt run \"strings working_copy.img | grep flag\" -c practicing01\n\nYou should see:\nflag{forensics_is_not_just_carving}\n\nForemost didn't recover that. It never will, because **plain text has no magic bytes** for Foremost to find. This is one of the most important things to understand about file carving: **it only finds what it has signatures for.**\n\nA skilled investigator doesn't stop at carving. They also run `strings` on the raw image, search for keywords, check filesystem metadata with `fls`, and use multiple tools in combination. The flag you just found with `strings` is your\nreminder that no single tool tells the whole story.\n\n### Where Foremost Falls Short\n\nTwo honest limitations worth knowing before moving to Scalpel:\n\n**Fragmented files.** Foremost assumes a file's bytes are contiguous on disk.\nIf a file was fragmented across non-adjacent blocks (common on heavily used drives), Foremost will either miss it or recover a corrupted version. **Scalpel** handles this better in _some_ configurations.\n\n**Fixed signature list.** Foremost ships with a default `/etc/foremost.conf`\nthat covers common file types. If you need to find something unusual, like a custom binary format, a proprietary database file, Foremost can't help without significant modification. Scalpel is built for exactly that use case, which is what the next section covers.\n\n## **Checkpoint: Foremost**\n\nAt this point Foremost should have recovered at least one JPEG\nand one PDF from `working_copy.img`, both logged in your flt case. You've also found something Foremost couldn't, the text flag, using strings directly on the raw image.\n\n> That contrast is intentional. Keep both results in mind as you read the next section.\n\nKnowledge Check\n\n0 / 5 correct\n\nQuestion 1 of 5\n\nnext →\n\nfinal score\n\nrestart quiz\n\n* * *\n\n# Step 3 | Going Deeper with Scalpel\n\n> Foremost got you started, yet Scalpel is where we get precise.\n\nThe core difference isn't really about power but rather philosophy kind of. Foremost ships ready-to-run with a built-in signature list and sensible defaults.\n\n> Scalpel ships with everything commented out, forcing you to explicitly define what you're looking for before itdoes anything.\n\nThat sounds like more work. It is. It's also exactly what you want in a real investigation.\n\n## How Scalpel Differs From Foremost\n\nBoth tools scan raw disk data for file signatures. But where Foremost makes\ndecisions for you, Scalpel puts you in control of three things:\n\n**What to look for.** Every file type Scalpel searches for must be explicitly\nenabled in its config file. Nothing runs by default.\n\n**How far to look.** You define the maximum file size for each type. Scalpel\nwon't carve beyond that limit, which prevents it from extracting hundreds of\nmegabytes of garbage when it finds a header with no matching footer.\n\n**What the boundaries are.** You define both the header and footer for each file\ntype. If a format has no footer, you define the maximum size and Scalpel carves\nthat many bytes from the header forward.\n\nThis config-driven approach makes Scalpel significantly more precise on known\ntargets and significantly more useful when you're hunting for something Foremost\ndoesn't know about.\n\n## Configure Scalpel Before Running It\n\nUnlike Foremost, Scalpel does nothing until you tell it what to find. Open the\nconfig file:\n\n\n    sudo nano /etc/scalpel/scalpel.conf\n\n\nYou'll see a long list of file types, all commented out with `#`. Find the JPEG\nand PDF entries and uncomment them. They look like this:\n\n\n    # GIF and JPG files (very common)\n            gif     y       5000000         \\x47\\x49\\x46\\x38\\x37\\x61        \\x00\\x3b\n            gif     y       5000000         \\x47\\x49\\x46\\x38\\x39\\x61        \\x00\\x3b\n            jpg     y       5242880         \\xff\\xd8\\xff???Exif             \\xff\\xd9        REVERSE\n            jpg     y       5242880         \\xff\\xd8\\xff???JFIF             \\xff\\xd9        REVERSE\n\n    # ADOBE PDF\n    #---------------------------------------------------------------------\n    #\n            pdf     y       5000000 %PDF  %EOF\\x0d  REVERSE\n            pdf     y       5000000 %PDF  %EOF\\x0a  REVERSE\n\nRemove the `#` from the lines you want active. The columns mean:\n\nColumn | What it means\n---|---\n`jpg` | Output file extension\n`y` | Case-sensitive header matching\n`5242880` | Maximum file size in bytes (5.2MB here)\n`\\xff\\xd8\\xff???Exif` | Header — magic bytes to search for\n`\\xff\\xd9` | Footer — where the file ends\n\nSave and close. Now Scalpel knows exactly what it's hunting.\n\n### Running Scalpel\n\n\n    flt run \"scalpel working_copy.img -o scalpel_output/\" -c practicing01\n\n\nScalpel will refuse to run if the output directory already exists,**it won't\noverwrite previous results**, very important feature. If you need to rerun it:\n\n\n    rm -rf scalpel_output/\n    flt run \"scalpel working_copy.img -o scalpel_output/\" -c practicing01\n\n\n### Reading Scalpel's Output\n\n\n    ls scalpel_output/\n    # audit.txt   jpg-0-y-200000000/   pdf-0-y-5000000/\n\n\nScalpel names its subdirectories after the exact rule that matched — you can\nsee the file type, the case-sensitivity flag, and the size limit right in the\nfolder name. That's intentional: it makes your investigation log unambiguous.\n\nCheck what was recovered:\n\n\n    # folder names might be different for you, just adapt the command for yourself if necessary\n    flt run \"ls -lh scalpel_output/jpg-3-0/ scalpel_output/pdf-5-0/\" -c practicing01\n\nOpen the recovered files and verify they're intact. If both open correctly,\nScalpel confirmed what Foremost found — with a different engine and explicit\nrules you can audit.\n\n## The Same Limitation Applies (Kind of)\n\nScalpel didn't find the txt either. And it never will, because the _Foremost-limitation_ from earlier applies here too.\n\n> It's fundamental to file carving as a technique. No matter how precisely you configure your rules, no matter how many signatures you add\n> to scalpel.conf, carving tools only find what has structure. **Plain text has none.**\n\n💡\n\nThis is the flag's real purpose in the lab image. It's not there to be easy. It's there to make sure you don't leave this post thinking two carving tools are better than one. ****They aren't, they're just different lenses on the same data.****\n\nThe full picture only appears when you combine all three approaches:\n\n  * `foremost`: fast, broad, automatic signature carving\n  * `scalpel`: precise, auditable, configurable signature carving\n  * `strings` + `grep/awk`: raw text extraction, no structure required\n\n\n\nA real investigation uses all of them. The flag was your reminder.\n\n> I made a post last year where you can learn tools like awk, definitely recommend a readthrough on the basics!\n\n## Foremost vs Scalpel, Side by Side\n\nAt this point you've run both tools on the same image. Here's what that\ncomparison actually means:\n\n| Foremost | Scalpel\n---|---|---\nConfiguration | Runs out of the box | Must configure before use\nSignature control | Fixed built-in list | You define every rule\nOutput naming | By file type | By exact rule used\nBest for | Quick triage, known file types | Targeted carving, custom formats\nAudit trail | audit.txt | audit.txt with rule details\n\nNeither tool is better. They answer different questions. Foremost is your first\npass, fast, broad, automatic.\nScalpel is your second pass, deliberate, precise, auditable. In a real investigation you run both.\n\n### Why the Config File Matters Legally\n\nThis is worth pausing on. In a real forensic investigation, being able to show\nexactly which signatures you searched for — and which you didn't — matters.\n\nScalpel's config file is a document. It records your investigative decisions:\nwhat you looked for, what size limits you set, what you chose to exclude.\nCombined with your `flt` case log, you can reconstruct every decision you made\nduring the investigation, in order, with timestamps and signatures.\n\nThat's chain of custody extending beyond just the evidence — it covers your\nmethodology too.\n\nLog the config you used:\n\n\n    flt run \"cat /etc/scalpel/scalpel.conf\" -c practicing01\n\n\nThis embeds a snapshot of your exact Scalpel configuration into your case log\nat the moment you ran the investigation. If the config ever changes on the\nsystem later, your log still shows what rules were active when you ran it.\n\n## **Checkpoint:** Scalpel\n\nYou should now have recovered files in both `foremost_output/`\nand `scalpel_output/`, with every command logged and signed in your `flt` case. Run `flt report -c practicing01` and look at what you've built: a complete,\ntimestamped, GPG-signed record of an investigation.\n\n> That's the report you'd attach to a CTF write-up, a forensics challenge submission, or hand to a supervisor in a real engagement.\n\nKnowledge Check\n\n0 / 5 correct\n\nQuestion 1 of 5\n\nnext ->\n\nfinal score\n\nrestart quiz\n\n* * *\n\n# The Report | Your Investigation, Documented\n\nYou have recovered files, found a hidden flag, and logged every step. Now close\nthe case.\n\n\n    flt report -c practicing01\n\n\nThat's it. forensic-log-tracker reads every log entry in your case folder — every\ncommand, every output hash, every GPG signature, every timestamp — and assembles\nthem into a single Markdown report at logs/practicing01/practicing01_report.md.\n\nOpen it. What you're looking at is a complete, chronological record of everything\nyou did — from the first `sha256sum` on the original image to the final Scalpel\nrun. Every command is there. Every output excerpt is there. Every hash is there.\nEvery entry is signed.\n\nThis is what you hand to a supervisor. This is what you attach to a CTF write-up.\nThis is what you put in front of a professor who asks you to prove you didn't\ntamper with the evidence.\n\nYou didn't just recover the files. You recovered files **and** can prove how you did it.\n\n## What You Learned\n\nYou started this post with a downloaded disk image and no forensics experience.\nYou now know how to:\n\n  * Verify evidence integrity with SHA256 before touching anything\n  * Create a forensic working copy with `dd` using the correct flags\n  * Recover deleted files by their magic bytes using Foremost\n  * Run targeted, auditable carving sessions with Scalpel\n  * Find evidence that carving tools miss entirely using `strings`\n  * Document an entire investigation automatically with forensic-log-tracker —\ntimestamped, hashed, and GPG-signed\n\n\n\nThat last point is the one most guides skip. The tools are learnable in an\nafternoon. The discipline of documentation is what separates someone who\ndid forensics from someone who can prove what they found.\n\n## Where to Go From Here\n\nThis was one image with a few planted files. Real investigations are messier —\nfragmented drives, encrypted volumes, wiped partitions, anti-forensic tools\ndesigned to defeat exactly what you just learned.\n\nA few directions worth exploring next:\n\n  * **Memory forensics** — disk images capture what was stored. RAM captures\nwhat was running. Volatility is the tool. I'll cover it in a future post.\n  * **Sleuth Kit deeper dive** — dive into `fls`, `icat`, `fsstat` and the rest of the\nTSK toolset in their own post. You got a taste with `fls` today.\n  * **Real CTF forensics challenges** — take what you learned here and apply\nit. CyberDefenders and HackTheBox both have beginner-friendly forensics\nchallenges. My writeups are here.\n  * **forensic-log-tracker** — it's open source, actively developed, and has\na growing `explanations.yaml` that needs contributions. If you used it today\nand have a tool explanation to add, open a PR.\n\n\n\n\n    # Star the repo if this was useful\n    # github.com/mev0lent/forensic-log-tracker\n\n\n* * *\n\n_forensic-log-tracker is a student project born out of frustration with\ndocumentation. If you hit a bug, found a limitation, or have a feature idea,\nopen an issue. That's how it gets better._",
  "title": "Digital Forensics for Beginners: How to Image a Disk, Carve Deleted Files, and Document Everything Like a Pro",
  "updatedAt": "2026-04-06T12:50:54.330Z"
}