
The case of the missing WAV audio files on the FAT32 SD Card - shanselman
https://www.hanselman.com/blog/CSITheCaseOfTheMissingWAVAudioFilesOnTheFAT32SDCard.aspx
======
amluto
> I didn't want to take any chances to I picked up a 5 pack of 32GIG high
> quality SD Cards. [link to Amazon]

The lesson: never ever buy SD cards or USB sticks from Amazon. Buy them from a
reputable company.

~~~
knaik94
There was nothing wrong with the SD cards physically, they weren't formatted
properly for the sound recording device. There was zero data loss, it was a
data access issue. An initial format would have helped avoid the problem. I'm
not sure the lesson you state is the lesson the author was trying to share.

~~~
zenexer
There’s a fairly good chance that the physical cards themselves were fake.
That happens a lot on Amazon. Given that cards purchased from reputable
manufacturers tend to be formatted without issue, it’s reasonable to guess
that the real problem here is that those are counterfeit cards.

~~~
londons_explore
Agreed. This was probably someone trying to tweak the fat32 header for better
fake-ability, for example putting the sector maps elsewhere.

------
solstice
Wow, what a ride. 7-zip is awesome. For anything involving (suspected) data
loss or "data disappearance", I usually try Testdisk/photorec from
[https://www.cgsecurity.org/](https://www.cgsecurity.org/)

~~~
skunkworker
I've used 7-zip to extract data from vmware VMDK files. Nothing else has come
close to opening obscure files for me.

------
Fr0styMatt88
That was an awesome article! The kind of rabbit hole I’d gladly go down :)

SD cards and USB sticks are just.... weird. I haven’t delved too deeply but
maybe someone here knows.... why is this? At this point I almost think of them
as ‘not disks’. The particular weirdness I’m thinking of is I’ve seen more
than one drive just seem to die, just because you try and repartition them in
Windows. Not even filling the drives up.

Is it the case that USB drive and SD card firmware is just crap? Like it makes
assumptions about the device other than ‘this is just a set of blocks on flash
memory’ and actually needs things on the disk at a file system level to be a
certain way for it to work properly? I’m really curious.

~~~
ObsoleteNerd
> The particular weirdness I’m thinking of is I’ve seen more than one drives
> just seem to die, just because you try and repartition them in Windows. Not
> even filling the drives up.

I’ve absolutely had this issue. Lots. I can’t figure out why either. I have
about half dozen Micro SD cards that now say they’re not formatted, and error
when trying to format them in windows. All of them “broke” during a simple
repartition in Disk Manager.

I’ve had minor success with some of them using fdisk to “repair” them but
others just fail there too.

~~~
userbinator
Have you tried Linux? It tends to be better at low-level access, or at least
give a more informative error message.

------
rahimnathwani
This advice should go without saying:

"Re-format the random SD cards you get from Amazon specifically on the device
you're gonna use them."

Do this also for portable hard drives.

~~~
userbinator
Any storage device I buy gets at least a full pass of read/write testing, any
errors means it's being returned as not fit for purpose. SSDs and HDDs get 8
full passes.

~~~
zimpenfish
To be fair, he did test the storage device:

"I did a local recording right there and played it back. Sounds good. I played
it back locally on the Zoom and I could hear the recording from the Zoom's
local speaker"

~~~
wtallis
That test doesn't really give you any more information than noticing that you
didn't get a "card not found" error. A full-capacity write and read
verification is a test that's actually informed by the possible failure modes
that wouldn't be immediately apparent from ordinary usage.

If you're worried enough to take the deliberate step of manually testing your
storage device, you should at least make sure it's a _useful_ test that tells
you something you don't already know.

------
sbradford26
7-Zip is pretty awesome. At one point I had a file that simply wouldn't delete
in Windows. Came across a random thing online that said to try and delete it
from 7-Zip. Simple as that 7-Zip was able to delete the file while everything
else couldn't.

~~~
qayxc
That's a common issue with Windows. The internal file API is much more
powerful than the user-accessible front-end programs, which can be very
frustrating at times. I had similar issues with corrupted file names created
by some application bug. There was no way to delete these invalid file entries
using OS-provided tools.

~~~
sbradford26
That clears up some of the mystery. I was wondering how 7-Zip could do it but
not explorer or command prompt. But it makes lot of sense that 7-Zip is just
fully utilizing the internal file API.

------
hag
I'm wondering if `binwalk`'ing the initial dd-image would have worked. That's
the first thing I would try.

~~~
akx
It absolutely doesn't, in this case.

    
    
        $ binwalk hanselman.img
    
        DECIMAL       HEXADECIMAL     DESCRIPTION
        --------------------------------------------------------------------------------
        13026788      0xC6C5E4        MySQL ISAM index file Version 6
        13064186      0xC757FA        MySQL ISAM index file Version 2
        15513282      0xECB6C2        YAFFS filesystem, little endian
        18368322      0x1184742       YAFFS filesystem, little endian
        42678040      0x28B3718       MySQL ISAM compressed data file Version 6
        59068786      0x3855172       YAFFS filesystem, little endian
        60315328      0x39856C0       YAFFS filesystem, little endian

------
userbinator
Among one of the reasons the FAT family of filesystems is in widespread use is
its simplicity, which makes data recovery easier. Writing a FAT driver/reader
is a common assignment for systems programming courses, and I've done it
myself too.

I took a quick look at the truncated image he provided, and it looks like the
fields in the MBR and boot sector are OK; but things start getting weird after
that.

The root is at cluster 2 where it normally should be (byte offset C00000 in
the image), but its second entry is that all-spaces directory which claims to
start in cluster 4, and furthermore its creation date is recent (2020-03-12).

Cluster 3 (C08000) is a directory which points to ZOOM0002.hprj,
ZOOM0002_Tr1.WAV, and ZOOM0002_Tr2.WAV, its "." is correctly pointing to
itself, but its parent according to ".." is at cluster 4. It is directory
"ZOOM0002".

Cluster 4 (C10000) is a directory which contains 3 directories ZOOM0001
through 3, its "." is correctly pointing to itself, and its parent is pointing
to the root (indicated with a cluster of 0). This is, according to the root,
the "all spaces" directory.

Cluster 5 (C18000) is ZOOM0001 directory, and its "." and ".." are correct.

Cluster 6 (C20000) is a file, ZOOM0001.hprj

Cluster 7 (C28000) is a file, ZOOM0001_LR.WAV

In other words, everything looks OK except for that all-spaces directory in
the root. According to page 25 of [https://www.zoom-
na.com/sites/default/files/products/downloa...](https://www.zoom-
na.com/sites/default/files/products/downloads/pdfs/H6-Manual_0_1.pdf) that
should have been named something like FOLDER01 through FOLDER10, so fixing
that should make it valid again.

It's hard to say what happened here without knowing the state of the
filesystem before the Zoom started writing to it, but the fact that the
creation date/time of that nameless directory (2020-03-12 12:29) matches
_exactly_ with that of the first file it wrote (ZOOM0001.hprj/ZOOM0001_LR.WAV)
strongly suggests that the card did not already have a corrupted filesystem
beforehand, and the Zoom somehow wrote a blank name directory where it
should've written FOLDER01. A search for "FOLDER" in the image yields no
results either, so it's not like it wrote them somewhere else (unless it did
so beyond the first 500MB of the card.)

I've seen embedded devices become confused and write corrupted filesystems a
few times before, but they were far more egregious than this; e.g.
ignoring/assuming certain fields' values would result in filesystem structures
being wholesale shifted by some offset, etc. This is an unusual case because
nothing about the filesystem stood out as being "obviously suspicious/non-
standard", and everything except for the name was fine --- hence why 7-zip
could still operate on it; it didn't care about the name.

The value of 1458 reserved sectors (729KB!) initially stood out, but upon
further thought, that may simply be to align the first cluster with the
eraseblocks of the flash, as if the Zoom really was to ignore it, the
filesystem structures would've been far more mangled.

~~~
mercora
thanks a lot for dissecting this i was hoping for this ;) If i recall
correctly the recording device could read those files without a hitch too.
that's probably because it ignored the malformed name too or is it? i am a bit
confused on how the device knew where to look at to find those files if not by
the name of the parent directory.

------
mercora
its a really nice read but i am somewhat sad they neither know what actually
happened nor why it happened at all. I hope this gets some attention from
someone here that is skilled enough with this kind of things and willing to
figure this out as it kinda bugs me now...

------
Neil44
Why not try a ready rolled file recovery utility first? Why grind out this
reinventing of the wheel?

~~~
qayxc
Because he's a curious mind and wanted to figure out what was happening here.
Admittedly not the most pragmatic approach, but definitely the more
entertaining and informative one :)

~~~
shanselman
Exactly! Thanks ;)

------
heywire
Great read! I agree, 7-zip is amazing. You can open all kinds of files for
exploration using it.

------
lostmsu
He did not try chkdsk, the default tool to fix file systems on Windows?

------
rdp36
lesson: use linux end to end (unless you work for Microsoft). :)

~~~
Arnavion
The author eventually recovered their files using 7-zip, which is a Windows
program.

~~~
ptspts
p7zip, the portable version of 7-Zip works on Linux, macOS and other Unix
systems as well. It also has a Debian package.

Data recovery from that FAT32 filesystem would have worked identically in
p7zip (and 7-Zip).

~~~
Arnavion
I know that p7zip exists. Nevertheless, the author used the Windows version
and it worked for them, so I'm not sure why the Linux implementation is
relevant to this conversation.

