Stop Treating LLMs Like Google (And How I Used One to Crack a “Forensic Mystery”)

We’ve all seen the complaints. “LLMs hallucinate.” “They get simple things wrong.” “They just regurgitate internet folklore.”

A lot of this criticism stems from a fundamental misunderstanding: people treat LLMs like a standard search engine, expecting a flawless, static answer on the first try. But the real magic of an LLM doesn’t happen when you ask it a question. It happens when you challenge it, push back, and use it as a collaborative sounding board. I recently stumbled across a classic digital forensics puzzle on Reddit that perfectly illustrates how to pair human intuition with AI processing power to solve a low-level mystery.

The Setup: The Impossible Drive

A user posted a screenshot from a Linux terminal running fdisk on a 2 GiB drive (/dev/sdb). The output was completely nonsensical:

The physical disk size was reported as 2 GiB.
Yet, fdisk listed individual partitions that were 544.3 GiB and 923.2 GiB in size.
The file system types were listed as ancient formats like “Novell Netware.”

This was the entire text that accompanied the screenshot: “Need forensic analysis of anomalous USB/MP3 behavior — looking for low-level explanation”.

I found that if you search the web for the specific Disk ID from that output (6F20736B), you find the exact same ghost partition table popping up on tech forums dating back over a decade.

The “Hammer” Theory

When the digital forensics community looked at this, the dominant theory was a common hardware scam: a capacity-faked flash drive. These are cheap USB drives engineered to lie to Windows about their size. The theory was that when Linux tried to read the faked firmware, it glitched out and threw garbage data into the partition table.

When I first dumped this problem into an LLM, it fell into the exact same trap. It scanned the internet, found the folklore about fake flash drives, and confidently parroted it back to me.

But something felt off. If it was random corruption or a faked firmware loop, why were the disk signatures and partition layouts exactly identical across different drives over a ten-year span?

“If you’re a hammer, everything becomes a nail.”

Linux’s fdisk is a hammer. It expects a partition table at Sector 0, so it blindly maps whatever bytes are sitting there into its rigid fields. What if we weren’t looking at hardware corruption, but simply raw text being misread out of alignment?

The Deep Dive: Reversing the Math

Instead of accepting the AI’s first answer, I challenged it. I realized that if fdisk was hallucinating a partition table out of raw data, we should be able to reverse-engineer the math. The partition table is a 4 * 16 bytes structure. We have decimal values for START and SECTORS, these are 4 byte values and the position (byte offset) is known. We have the partition IDs, those are already HEX values. HEX we can convert to ASCII.

I told the LLM to ignore the “fake drive” theory, take the massive decimal numbers from the terminal output (the start sectors and sizes), convert them back into Hex, and decode them into ASCII text using Little-Endian alignment. By forcing the AI to step away from “search engine” mode and into “data crunching” mode, the raw text unmasked itself:

Partition	Field	Hex Value (Little-Endian)	ASCII String Conversion
Partition 1	Start Sector	`64 69 61 2E`	`dia.`
	Total Sectors	`FF 0D 0A 44`	`\xff\r\nD` (Newline + D)
Partition 2	Type ID	`65`	`e` (completes “Media”)
	Start Sector	`20 72 0D 0A`	`r\r\n` (Space + r + Newline)
	Total Sectors	`54 72 65 53`	`Pres`
Partition 3	Type ID	`79`	`y` (completes “Press”)
	Start Sector	`6F 74 20 6F`	`o to`
	Total Sectors	`20 72 65 73`	`res`

The Solution

When you stitch those fragments together, the ghost partition table completely vanishes, and a classic legacy fallback string appears:

…media…
…Pres…
…y to res…

“Media… Error\r\nPress any key to restart”

It wasn’t a fake flash drive at all. Someone had used an imaging tool like dd and accidentally burned a standard Volume Boot Record (VBR) directly onto LBA 0 (the Master Boot Record boundary). Because the legacy error text happened to align perfectly with the partition table structural offsets, fdisk read plain English characters as massive sector boundaries. If you look at the sector in HEX, you’d immediately see it.

The Real Takeaway

The AI didn’t magically know the solution out of the box, and I didn’t want to manually convert dozens of decimal strings into little-endian hex characters by hand.

The breakthrough came from the feedback loop. When you treat an LLM as a collaborative peer (challenging its assumptions, feeding it new hypotheses, and directing its computational strengths) you can unmask anomalies that both humans and algorithms miss when working alone.

Stop searching with LLMs. Start investigating with them.