Drill Your Hard Drives

Posted on Jul 23, 2021

… after filling it with random data. And don’t sell them on eBay.

IN PARTICULAR, don’t be irresponsible enough to do this when you work for IT in something like a pension fund or a law firm.

What am I talking about then? Well, I wanted one of those cute, tiny, barebones, terminal business PC’s to replace a Raspberry Pi at home. I found a Lenovo ThinkCentre Tiny M93 on eBay, with a pretty nice 4th Gen Core i3 and 8GB of DDR3. This is enough, and was pretty damn cheap for what it is.

The seller said on the listing that I would need to install my own OS because the drive was wiped, which is fair enough. As I was about to fdisk the disk to install Void Linux on it, it occurred to me… Why not take a peek into the drive? You know, just healthy human curiosity.

I plugged in an external drive big enough to be able to hold an entire image of the disk, and dd(1)’d away. After a few hours (both drives are mechanical!) it was done. I installed Void and then plugged the drive holding the old image of the drive into my workstation.

At first, I just wanted to see if I could get away with recovering the partitions entirely, since a quick hexdump revealed to me that drive had not been properly wiped. I tried a couple of tools but none seemed to manage to recover the partitions at all, a shame.

A shame, because my next idea would be really slow. Binwalk –as the name implies– walks some blob of binary data. While doing so, it tries to find common file signatures and reports them. So not only this approach is going to take long, it’s also not particularly ideal for something like a filesystem since things can be fragmented and therefore files might not be contiguous. File headers (which is what Binwalk looks for) should be mostly contiguous however, but if the file is fragmented it’d be very hard to recover it entirely. Anyway, still worth a shot. The drive is 320GB so it took about a couple of days to finish.

It produced about 7MB worth of output, telling me offsets where it thinks there might be a file. Unsurprisingly, much of this was false positives and files from the Windows installation, but after loads of grepping and writing some small Go helper programs to extract stuff in bulk, I found some interesting entries:

scroll to the right to see the filenames

25694040064   0x5FB7BF000     Zip archive data, at least v2.0 to extract, compressed size: 2115372, uncompressed size: 2967560, name: Pensions documents for [REDACTED].PDF
25696155549   0x5FB9C379D     Zip archive data, at least v2.0 to extract, compressed size: 325252, uncompressed size: 505022, name: Pensions documents for [REDACTED].PDF
25696480940   0x5FBA12EAC     Zip archive data, at least v2.0 to extract, compressed size: 387402, uncompressed size: 557646, name: Pensions documents for [REDACTED].PDF
25696868469   0x5FBA71875     Zip archive data, at least v2.0 to extract, compressed size: 1038417, uncompressed size: 1803553, name: Pensions documents for [REDACTED].PDF
25697907010   0x5FBB6F142     Zip archive data, at least v2.0 to extract, compressed size: 2591869, uncompressed size: 2761664, name: Pensions documents for [REDACTED].PDF
25700498989   0x5FBDE7E2D     Zip archive data, at least v2.0 to extract, compressed size: 79896, uncompressed size: 87605, name: Pensions documents for [REDACTED].PDF
25700579001   0x5FBDFB6B9     Zip archive data, at least v2.0 to extract, compressed size: 268266, uncompressed size: 296015, name: Pensions documents for [REDACTED].PDF
25700847380   0x5FBE3CF14     Zip archive data, at least v2.0 to extract, compressed size: 509323, uncompressed size: 545522, name: Pensions documents for [REDACTED].PDF
25701356816   0x5FBEB9510     Zip archive data, at least v2.0 to extract, compressed size: 67530, uncompressed size: 76757, name: Pensions documents for [REDACTED].PDF
25701424462   0x5FBEC9D4E     Zip archive data, at least v2.0 to extract, compressed size: 129923, uncompressed size: 140972, name: Pensions documents for [REDACTED].PDF
25701554502   0x5FBEE9946     Zip archive data, at least v2.0 to extract, compressed size: 101429, uncompressed size: 109411, name: Pensions documents for [REDACTED].PDF
25701656044   0x5FBF025EC     Zip archive data, at least v2.0 to extract, compressed size: 207871, uncompressed size: 224584, name: Pensions documents for [REDACTED].PDF
25701864031   0x5FBF3525F     Zip archive data, at least v2.0 to extract, compressed size: 96833, uncompressed size: 104622, name: Pensions documents for [REDACTED].PDF
25701962715   0x5FBF4D3DB     End of Zip archive, footer length: 22

And sure enough. If one is to extract those zip files, highly confidential information about some peoples’ pensions is revealed.

I did a little bit more digging and I’m almost certain that the company that this drive used to belong to was some sort of law firm (there are some court documents in there too) or pension manager or something of that sort.

So where does this leave us? I think it leaves us in a position where you need to be afraid of handling sensitive data, and even more so, you need to be terrified of handing sensitive data to third parties. Because you know, someone might buy the hard drive in which this data is in, and get it back out.

🔎 Browse comments 💬 Post a new comment