CSI：FAT32 SD卡上缺少WAV音频文件的情况

Buckle up kids, as this is a tale. As you may know, I have a lovely podcast at https://hanselminutes.com. You should listen.

带上孩子们，因为这是一个故事。 您可能知道，我在https://hanselminutes.com上有一个可爱的播客。 你应该听。

Recently through an number of super cool random events I got the opportunity to interview actor Chris Conner who plays Poe on Altered Carbon. I'm a big fan of the show but especially Chris. You should watch the show because Poe is a joy and Chris owns every scene, and that's with a VERY strong cast.

最近，通过一些超酷的随机事件，我有机会采访演员克里斯·康纳(Chris Conner)，后者在《变碳》上饰演Poe 。 我是该节目的忠实粉丝，尤其是克里斯。 您应该看演出，因为坡很快乐，克里斯拥有每个场景，而且演员阵容很强。

I usually do my interviews remotely for the podcast but I wanted to meet Chris and hang out in person so I used my local podcasting rig which consists of a Zoom H6 recorder.

我通常会对播客进行远程采访，但是我想和克里斯见面并亲自闲逛，所以我使用了由Zoom H6录像机组成的当地播客装置。

I have two Shure XLR mics, a Mic stand, and the Zoom. The Zoom H6 is a very well though of workhorse and I've used it many times before when recording shows. It's not rocket surgery but one should always test their things.

我有两个Shure XLR麦克风，一个麦克风支架和一个Zoom 。 Zoom H6是非常出色的工具，在录制节目之前，我已经使用了很多次。 这不是火箭手术，而是应该经常测试他们的东西。

I didn't want to take any chances to I picked up a 5 pack of 32GIG high quality SD Cards. I put a new one in the Zoom, the Zoom immediately recognized the SD Card so 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. It's recording the file in stereo, one side for each mic. Remember this for later.

我不想冒险拿起5包32GIG高质量SD卡。 我在Zoom中放了一个新的，Zoom立即识别了SD卡，因此我在那里进行了本地录制并播放了。 听起来不错。 我在Zoom上本地播放了声音，并且可以从Zoom的本地扬声器听到录音。 它以立体声录制文件，每个麦克风一侧。 记住这一点，以后再说。

I went early to the meet and set up the whole recording setup. I hooked up a local monitor and tested again. Records and plays back locally. Cool. Chris shows up, we recorded a fantastic show, he's engaged and we're now besties and we go to Chipotle, talk shop, Sci-fi, acting, AIs, etc. Just a killer afternoon all around.

我很早去开会，设置了整个录音装置。 我连接了本地监视器，然后再次进行测试。 记录并在本地播放。 凉。 克里斯(Chris)出现了，我们录制了一场精彩的表演，他订婚了，我们现在是好朋友，我们去了Chipotle，谈话店，科幻，表演，人工智能等。这只是整个下午的杀手afternoon。

I head home and pull out the SD Card and put it into the PC and I see this. I almost vomit. I get lightheaded.

我回家，拔出SD卡，将其插入PC中，我看到了。 我差点呕吐我头晕。

I've been recording the show for over 730 episodes over 14 years and I've never lost a show. I do my homework - as should you. I'm reeling. Ok, breathe. Let's work the problem.

在过去的14年中，我一直在录制超过730集的节目，但从未间断。 我做我的作业-你也应该做。 我在re。 好呼吸让我们解决这个问题。

Right click the drive, check properties. Breathe. This is a 32 gig drive, but Windows sees that it's got 329 MB used. 300ish megs is the size of a 30 minute long two channel WAV file. I know this because I've looked at 300 meg files for the last several hundred shows. Just like you might know roughly the size of a JPEG your camera makes. It's a thing you know.

右键单击驱动器，检查属性。 呼吸。 这是一个32 gig的驱动器，但是Windows看到它已经使用了329 MB 。 300ish兆是一个30分钟长的两通道WAV文件的大小。 我知道这一点是因为在最近的几百场演出中，我查看了300个MEG文件。 就像您大概知道相机制作的JPEG大小一样。 你知道的

Command line time. List the root directory. Empty. Check it again but "show all files," weird, there's a Mac folder there but maybe the SD Card was preformatted on a Mac.

命令行时间。 列出根目录。 空的再次检查，但“显示所有文件”很奇怪，那里有一个Mac文件夹，但SD卡可能已在Mac上进行了预格式化。

Interesting Plot Point - I didn't format the SD card. I use it as it came out of the packaging from Amazon. It came preformatted and I accepted it. I tested it and it worked but I didn't "install my own carpet." I moved in to the house as-is.

有趣的绘图点-我没有格式化SD卡。 我使用它是从亚马逊包装中取出的。 它是预先格式化的，我接受了。 我对其进行了测试，但仍然有效，但是我没有“自己安装地毯”。 我原样搬进了这所房子。

What about a little "show me all folders from here down" action? Same as I saw in Windows Explorer. The root folder has another subfolder which is itself. It's folder "Inception" with no Kick!

稍微执行一下“从这里向我显示所有文件夹”操作怎么样？ 与我在Windows资源管理器中看到的相同。 根文件夹还有另一个子文件夹。 它是没有踢脚的文件夹“ Inception”！

G:\>dir /a
Volume in drive G has no label.
Volume Serial Number is 0403-0201
Directory of G:\
03/12/2020 12:29 PM <DIR>
03/13/2020 12:44 PM <DIR> System Volume Information
0 File(s) 0 bytes
2 Dir(s) 30,954,225,664 bytes free
G:\>dir /s
Volume in drive G has no label.
Volume Serial Number is 0403-0201
Directory of G:\
03/12/2020 12:29 PM <DIR>
0 File(s) 0 bytes
Directory of G:\
03/12/2020 12:29 PM <DIR>
0 File(s) 0 bytes
IT GOES FOREVER

Ok, the drive thinks there's data but I can't see it. I put the SD card back in the Zoom and try to play it back.

好的，驱动器认为有数据，但我看不到。 我将SD卡放回了Zoom中，然后尝试播放它。

The Zoom can see folders and files AND the interview itself. And the Zoom can play it back. The Zoom is an embedded device with an implementation of the FAT32 file system and it can read it, but Windows can't. Can Linux? Can a Mac?

Zoom可以查看文件夹和文件以及采访本身。 并且Zoom可以播放它。 Zoom是一种嵌入式设备，具有FAT32文件系统的实现，并且可以读取，但Windows无法读取。 可以Linux吗？ Mac可以吗？

Short answer. No.

简短的答案。 没有。

Hacky Note: Since the Zoom can see and play the file and it has a headphone/monitor jack, I could always plug in an analog 1/8" headphone cable to a 1/4" input on my Peavy PV6 Mixer and rescue the audio with some analog quality loss. Why don't I use the USB Audio out feature of the Zoom H6 and play the file back over a digital cable, you ask? Because the Zoom audio player doesn't support that. It supports three modes - SD Card Reader (which is a pass through to Windows and shows me the recursive directories and no files), an Audio pass-through which lets the Zoom look like an audio device to Windows but doesn't show the SD card as a drive or allow the SD Card to be played back over the digital interface, or its main mode where it's recording locally.

hacky注意：由于Zoom可以查看和播放文件，并且具有耳机/监听插Kong，因此我总是可以将模拟1/8“耳机线插入Peavy PV6调音台上的1/4”输入端并恢复音频有一些模拟质量损失。 您为什么不使用Zoom H6的USB音频输出功能，而是通过数字电缆播放文件？ 因为Zoom音频播放器不支持该功能。 它支持三种模式-SD卡读卡器(通过Windows传递给我，显示递归目录，没有文件)，音频传递，使Zoom看起来像Windows上的音频设备，但不显示SD卡作为驱动器，或允许SD卡通过数字接口或其在本地录制的主模式进行播放。

孩子们，这是取证时间。 (It's Forensics Time, Kids.)

We have an 32 SD Card - a disk drive as it were - that is standard FAT32 formatted, that has 300-400 megs of a two-channel (Chris and I had two mics) WAV file that was recorded locally by the Zoom H6  audio reorder and I don't want too lose it or mess it up.

我们有一个32 SD卡(实际上是一个磁盘驱动器)，它是标准FAT32格式的，具有300-400兆的两通道WAV文件(克里斯和我有两个麦克风)，通过Zoom H6音频在本地录制重新排序，我不想失去它或弄乱它。

I need to take a byte for byte image of what's on the SD Card so I can poke and it and "virtually" mess with with it, change it, fix it, try again, without changing the physical.

我需要为SD卡中的字节图像获取一个字节，以便戳戳它，然后“虚拟”地将其弄乱，更改，修复，重试，而无需更改物理外观。

"dd" is a command-line utility with a rich and storied history going back 45 years. Even though it means "Data Definition" it'll always be "disk drive" I my head.

“ dd”是一种命令行实用程序，具有45年的悠久历史。 即使它意味着“数据定义”，也永远是“磁盘驱动器”。

如何在Windows上将USB驱动器或SD卡克隆到IMG文件 (How to clone a USB Drive or SD Card to an IMG file on Windows)

I have a copy of dd for Windows which lets me get a byte for byte stream/file that represents this SD Card. For example I could get an entire USD device:

我有Windows的dd副本，可让我获取代表此SD卡的字节流/文件的字节。 例如，我可以获得一个完整的美元设备：

dd if=\\?\Device\Harddisk1\Partition0 of=c:\temp\usb2.img bs=1M --size --progress

I need to know the Harddisk number and Partition number as you can see above. I usually use diskpart for this.

如上所示，我需要知道硬盘号和分区号。 我通常为此使用diskpart。

>diskpart

Microsoft DiskPart version 10.0.19041.1

Copyright (C) Microsoft Corporation.
On computer: IRONHEART

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online         1863 GB      0 B        *
  Disk 2    Online         3725 GB      0 B
  Disk 3    Online         2794 GB      0 B        *
  Disk 8    Online           29 GB  3072 KB

DISKPART> select disk 8

Disk 8 is now the selected disk.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary             29 GB  4096 KB

Looks like it's Disk 8 Partition 1 on my system. Let's get it all before I panic.

看起来是我系统上的Disk 8 Partition 1。 让我们在惊慌之前得到所有。

dd if=\\?\Device\Harddisk8\Partition1 of=c:\temp\ZOMG.img bs=1M --size --progress

IF and OF are input file and output file, and I will do it for the whole size of the SD Card. It's likely overkill though as we'll see in a second.

IF和OF是输入文件和输出文件，我将对SD卡的整个大小进行处理。 不过，正如我们稍后将看到的那样，这可能会导致过度杀伤。

This file ended up being totally massive and hard to work with. Remember I needed just the first 400ish megs? I'll chop of just that part.

该文件最终变得非常庞大且难以使用。 还记得我只需要前400个兆头吗？ 我只剩下那一部分。

dd if=ZOMG.img of=SmallerZOMG.img bs=1M count=400

What is this though? Remember it's an image of a File System. It just bytes in a file. It's not a WAV file or a THIS file or a THAT file. I mean, it is if we decide it is, but in fact, a way to think about it is that it's a mangled envelope that is dark when I peer inside it. We're gonna have to feel around and see if we can rebuild a sense of what the contents really are.

那是什么记住，这是文件系统的映像。 它只是文件中的字节。 它不是WAV文件，也不是THIS文件或THAT文件。 我的意思是，如果我们确定是的话，但实际上，可以考虑一下的方式是，当我窥视它时，它是一个破烂不堪的信封。 我们将不得不去看看，看看我们是否可以重建对内容真正的理解。

从IMG导入原始字节到试听或Audacity (Importing Raw Bytes from an IMG into Audition or Audacity)

Both Adobe Audition and Audacity are audio apps that have an "Import RAW Data" feature. However, I DO need to tell Audition how to interpret it. There's lots of WAV files out there. How many simples were there? 1 channel? 2 channel? 16 bit or 32 bit? Lots of questions.

Adobe Audition和Audacity都是具有“导入RAW数据”功能的音频应用程序。 但是，我确实需要告诉Audition如何解释它。 那里有很多WAV文件。 那里有几个简单的东西？ 1个频道？ 2频道？ 16位还是32位？ 很多问题。

Can I just import this 4 gig byte array of a file system and get something?

我可以只导入文件系统的这个4 gig字节的数组并得到一些东西吗？

Looks like something. You can see that the first part there is likely the start of the partition table, file system headers, etc. before audio data shows up. Here's importing as 2 channel.

看起来像东西。 您可以看到，在显示音频数据之前，第一部分可能是分区表的开始，文件系统标头等。 这是导入为2通道。

I can hear voices but they sound like chipmunks and aren't understandable. Something is "doubled." Sample rate? No, I double checked it.

我可以听到声音，但听起来像花栗鼠，听不懂。 某些东西“加倍了”。 采样率？ 不，我仔细检查了一下。

Here's 1 channel raw data import even though I think it's two.

这是1通道原始数据导入，尽管我认为是2。

Now THIS is interesting. I can hear audio at normal speed of us talking (after the preamble) BUT it's only a syllable at a time, and then a quieter version of the same syllable repeats. I don't want to (read: can't really) reassemble a 30 min interview from syllables, right?

现在，这很有趣。 我可以听见我们以正常速度说话的声音(在序言之后)，但一次只是一个音节，然后是相同音节的安静版本。 我不想(读：真的不能)重新组织一个30分钟的音节访谈，对吗？

Remember when I said that the Zoom H6 records a two channel file with one channel per mic? Not really. It records ONE FILE PER CHANNEL. A whateverL.wav and a whateverR.wav. I totally forgot!

还记得我说过Zoom H6录制两个声道文件，每个麦克风一个声道吗？ 并不是的。 它记录每个通道一个文件。 whatL.wav和whatR.wav。 我完全忘记了！

This "one channel" file above is actually the bytes as they were laid down on disk, right? It's actually two files written simultaneously, a few kilobytes at a time, L,R,L,R,L,R. And here I am telling my sound software to treat this "byte for byte file system dump" as one file. It's two that were made at the same time.

上面的这个“一个通道”文件实际上是放置在磁盘上的字节，对吗？ 实际上是两个文件同时写入，一次写入几千字节，L，R，L，R，L，R。 在这里，我告诉我的声音软件将这个“字节对字节文件系统转储”视为一个文件。 是同时制作的两个。

It's like the Brundlefly. How do I tease it apart? Well I can't treat the array as a raw file anymore, it's not. And I want (really don't have the energy yet) to write my own little app to effectively de-interlace this image. I also don't know if the segment size is perfectly reliable or if it varies as the Zoom recorded.

就像Brundlefly 。 我如何把它分开？ 好吧，我不能再将数组视为原始文件了，不是。 我想(真的还没有能量)编写自己的小应用程序以有效地对图像进行隔行扫描。 我也不知道段大小是否完全可靠，或者它是否随记录的缩放而变化。

NOTE: Pete Brown has written about RIFF/WAV files from Sound Devices records having an incorrect FAT32 bit set. This isn't that, but it's in the same family and is worth noting if you ever have an issue with a Broadcast Wave File getting corrupted or looking encrypted.

注意： Pete Brown从Sound Devices记录中写了有关FAT32位设置不正确的RIFF / WAV文件。 不是那样的，但是它属于同一个家族，并且值得注意的是，如果您遇到广播波形文件损坏或看起来加密的问题。

Whole helping me work this issue, Pete Brown tweeted a hexdump of the Directory Table so you can see the Zoom0001, Zoom0002, etc directories there in the image.

Pete Brown在整体上帮助我解决了这个问题，在Twitter上发布了目录表的十六进制转储，以便您可以在图像中看到Zoom0001，Zoom0002等目录。

Let me move into Ubuntu on my Windows machine running WSL. Here I can run fdisk and get some sense of what this Image of the bad SD Card is. Remember also that I hacked off the first 0-400 Megs but this IMG file thinks it's a 32gig drive, because it is. It's just that's been aggressively truncated.

让我进入运行WSL的Windows计算机上的Ubuntu。 在这里，我可以运行fdisk并了解此错误SD卡的映像是什么。 还要记住，我砍掉了第一个0-400 Meg，但是这个IMG文件认为它是32gig驱动器，因为它是。 只是被积极地截断了。

$ fdisk -u -l SmallerZOMG.img
Disk SmallerZOMG.img: 400 MiB, 419430400 bytes, 819200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device           Boot Start      End  Sectors  Size Id Type
SmallerZOMG.img1       8192 61157375 61149184 29.2G  c W95 FAT32 (LBA)

Maybe I can "mount" this IMG? I make a folder on Ubuntu/WSL2 called ~/recovery. Yikes, ok there's nothing there. I can take the sector size 512 times the Start block of 8192 and use that as the offset.

也许我可以“安装”此IMG？ 我在Ubuntu / WSL2上创建一个名为〜/ recovery的文件夹。 kes，好的，那里什么都没有。 我可以将扇区大小设为8192起始块的512倍，并将其用作偏移量。

sudo mount -o loop,offset=4194304 SmallerShit.img recover/
$ cd recover/
$ ll
total 68
drwxr-xr-x  4 root  root  32768 Dec 31  1969  ./

Ali Mosajjal thinks perhaps "they re-wrote the FAT32 structure definition and didn't use a standard library and made a mistake," and Leandro Pereria postulates "what could happen is that the LFN (long file name) checksum is invalid and they didn't bother filling in the 8.3 filename... so that complying implementations of VFAT tries to look at the fallback 8.3 name, it's all spaces and figures out "it's all padding, move along."

Ali Mosajjal认为“也许他们重写了FAT32结构定义，并且没有使用标准库并犯了错误”，而Leandro Pereria则假设“可能发生的情况是LFN(长文件名)校验和无效，而他们没有这样做。不必费心填写8.3文件名...，以便符合VFAT的实现会尝试查看后备8.3名称，它是所有空格，并弄清楚“都是填充，请继续前进”。

Ali suggested running dosfsck on the mounted image and you can see again that the files are there, but there's like 3 root entries? Note I've done a cat of /proc/mounts to see the loop that my img is mounted on so I can refer to it in the dosfsck command.

Ali建议在已装载的映像上运行dosfsck ，您可以再次看到文件在那里，但是有3个根条目？ 注意，我已经完成了/ proc / mounts的工作，以查看安装了img的循环，因此可以在dosfsck命令中对其进行引用。

$ sudo dosfsck -w -r -l -a -v -t /dev/loop3
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "        "
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     32768 bytes per cluster
      1458 reserved sectors
First FAT starts at byte 746496 (sector 1458)
         2 FATs, 32 bit entries
   3821056 bytes per FAT (= 7463 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 8388608 (sector 16384)
    955200 data clusters (31299993600 bytes)
63 sectors/track, 255 heads
      8192 hidden sectors
  61149184 sectors total
Checking file /
Checking file /
Checking file /
Checking file /System Volume Information (SYSTEM~1)
Checking file /.
Checking file /..
Checking file /ZOOM0001
Checking file /ZOOM0002
Checking file /ZOOM0003
Checking file /ZOOM0001/.
Checking file /ZOOM0001/..
Checking file /ZOOM0001/ZOOM0001.hprj (ZOOM00~1.HPR)
Checking file /ZOOM0001/ZOOM0001_LR.WAV (ZOOM00~1.WAV)
Checking file /ZOOM0002/.
Checking file /ZOOM0002/..
Checking file /ZOOM0002/ZOOM0002.hprj (ZOOM00~1.HPR)
Checking file /ZOOM0002/ZOOM0002_Tr1.WAV (ZOOM00~1.WAV)
Checking file /ZOOM0002/ZOOM0002_Tr2.WAV (ZOOM00~2.WAV)
Checking file /ZOOM0003/.
Checking file /ZOOM0003/..
Checking file /ZOOM0003/ZOOM0003.hprj (ZOOM00~1.HPR)
Checking file /ZOOM0003/ZOOM0003_Tr1.WAV (ZOOM00~1.WAV)
Checking file /ZOOM0003/ZOOM0003_Tr2.WAV (ZOOM00~2.WAV)
Checking file /System Volume Information/.
Checking file /System Volume Information/..
Checking file /System Volume Information/WPSettings.dat (WPSETT~1.DAT)
Checking file /System Volume Information/ClientRecoveryPasswordRotation (CLIENT~1)
Checking file /System Volume Information/IndexerVolumeGuid (INDEXE~1)
Checking file /System Volume Information/AadRecoveryPasswordDelete (AADREC~1)
Checking file /System Volume Information/ClientRecoveryPasswordRotation/.
Checking file /System Volume Information/ClientRecoveryPasswordRotation/..
Checking file /System Volume Information/AadRecoveryPasswordDelete/.
Checking file /System Volume Information/AadRecoveryPasswordDelete/..
Checking for bad clusters.

We can see  them, but can't get at them with the vfat file system driver on Linux or with Windows.

我们可以看到它们，但是不能通过Linux或Windows上的vfat文件系统驱动程序找到它们。

The DUMP.exe util as part of mtools for Windows is amazing but I'm unable to figure out what is wrong in the FAT32 file table. I can run minfo on the Linux command land telling it to skip 8192 sectors in with the @@offset modifier:

DUMP.exe util作为Windows mtools的一部分，非常棒，但是我无法确定FAT32文件表中的错误。 我可以在Linux命令域上运行minfo，告诉它使用@@ offset修饰符跳过8192个扇区：

$ minfo -i ZOMG.img@@8192S
device information:
===================
filename="ZOMG.img"
sectors per track: 63
heads: 255
cylinders: 3807

mformat command line: mformat -T 61149184 -i ZOMG.img@@8192S  -h 255 -s 63 -H 8192 ::

bootsector information
======================
banner:"        "
sector size: 512 bytes
cluster size: 64 sectors
reserved (boot) sectors: 1458
fats: 2
max available root directory slots: 0
small size: 0 sectors
media descriptor byte: 0xf8
sectors per fat: 0
sectors per track: 63
heads: 255
hidden sectors: 8192
big size: 61149184 sectors
physical drive id: 0x80
reserved=0x0
dos4=0x29
serial number: 04030201
disk label="           "
disk type="FAT32   "
Big fatlen=7463
Extended flags=0x0000
FS version=0x0000
rootCluster=2
infoSector location=1
backup boot sector=6

Infosector:
signature=0x41615252
free clusters=944648
last allocated cluster=10551

Ok, now we've found yet ANOTHER way to mount this corrupted file system. With mtools we'll use mdir to list the root directory. Note there is something wrong enough that I have to set mtools_skip_check=1 to ~/.mtoolsrc and continue.

好的，现在我们找到了挂载这个损坏的文件系统的另一种方法。 通过mtools，我们将使用mdir列出根目录。 请注意，我必须将mtools_skip_check = 1设置为〜/ .mtoolsrc并继续进行操作，这足以说明问题。

$ mdir -i ZOMG.img@@8192S ::
Total number of sectors (61149184) not a multiple of sectors per track (63)!
Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
$ pico ~/.mtoolsrc
$ mdir -i ZOMG.img@@8192S ::
 Volume in drive : is
 Volume Serial Number is 0403-0201
Directory for ::/

             <DIR>     2020-03-12  12:29
        1 file                    0 bytes
                     30 954 225 664 bytes free

Same result. I can run mdu and see just a few folders. Note the ZOOMxxxx ones are missing here

结果相同。 我可以运行mdu并只看到几个文件夹。 请注意，此处缺少ZOOMxxxx

$ mdu -i ZOMG.img@@8192S ::
::/System Volume Information/ClientRecoveryPasswordRotation 1
::/System Volume Information/AadRecoveryPasswordDelete 1
::/System Volume Information 5
::/ 6

Now, ideally I want to achieve two things here.

现在，理想情况下，我想在这里实现两件事。

• Know WHY it's broken and exactly WHAT is wrong.

  知道为什么它坏了，到底是哪里错了。

  • There's a nameless root directory here and I lack the patience and skill to manually hexdump and patch it.
    这里有一个无名的根目录，我缺乏耐心和技巧来手动对其进行十六进制转储和修补。
• Be able to copy the files out "normally" by mounting the IMG and, well, copying them out.
  可以通过安装IMG并“将它们复制出去”来“正常”复制文件。

UPDATE #1 - I'm back after a few minutes of thinking again.

更新＃1-经过几分钟的思考，我回来了。

If I use mmls from Sleuthkit, I can see this.

如果我使用Sleuthkit的mmls，我会看到的。

$ mmls HolyShit.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000008191   0000008192   Unallocated
002:  000:000   0000008192   0061157375   0061149184   Win95 FAT32 (0x0c)

If I do the 512*8192 offset again and visualize the FAT32 table in Hexdump/xxd like this:

如果我再次执行512 * 8192偏移并像这样在Hexdump / xxd中可视化FAT32表：

xxd -seek 4194304 ZOMG.img  | more
00400000: eb00 9020 2020 2020 2020 2000 0240 b205  ...        ..@..
00400010: 0200 0000 00f8 0000 3f00 ff00 0020 0000  ........?.... ..
00400020: 0010 a503 271d 0000 0000 0000 0200 0000  ....'...........
00400030: 0100 0600 0000 0000 0000 0000 0000 0000  ................
00400040: 8000 2901 0203 0420 2020 2020 2020 2020  ..)....
00400050: 2020 4641 5433 3220 2020 0000 0000 0000    FAT32   ......
00400060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00400070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00400080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00400090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
004000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
004000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
004000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

I can see I seek'ed to the right spot, as the string FAT32 is just hanging out. Maybe I can clip out this table and visualize it in a better graphical tool.

我可以看到我一直在寻找正确的位置，因为字符串FAT32刚刚伸出来。 也许我可以剪裁此表并使用更好的图形工具对其进行可视化。

I could grab a reasonable (read: arbitrary) chunk from this offset and put it in a very small manageable file:

我可以从此偏移量中获取一个合理的(读取：任意)块并将其放入一个非常小的可管理文件中：

dd if=ZOMG.img ibs=1 skip=4194304 count=64000 > another.img

And then load it in dump.exe on Windows which is really a heck of a tool. It seems to be thinking thinking there's multiple FAT Root Entries (which might be why I'm seeing this weird ghost root). Note the "should be" parts as well.

然后将其加载到Windows上的dump.exe中，这确实是一种工具。 似乎是在考虑存在多个FAT根条目(这可能就是为什么我看到这个奇怪的幽灵根)的想法。 注意“应该是”部分。

FAT Root Entry (non LFN) (0x00000000)
                  Name: ···     
             Extension:    
             Attribute: 0x00 
        FAT12:reserved: 02 40 B2 05 02 00 00 00 00 F8
        FAT32:reserved: 02
   FAT32:creation 10th: 0x40
   FAT32:creation time: 0x05B2
   FAT32:creation date: 0x0002
   FAT32:last accessed: 0x0000
FAT32:hi word start cluster: 0xF800
                  Time: 0x0000  (00:00:00) (hms) 
                  Date: 0x003F  (1980/01/31) (ymd) 
      Starting Cluster: 0x00FF (0xF80000FF)
             File Size: 8192

FAT Root Entry (non LFN) (0x00000020)
                  Name: ····'···
             Extension: ···
             Attribute: 0x00 
        FAT12:reserved: 02 00 00 00 01 00 06 00 00 00
        FAT32:reserved: 02
   FAT32:creation 10th: 0x00
   FAT32:creation time: 0x0000
   FAT32:creation date: 0x0001
   FAT32:last accessed: 0x0006
FAT32:hi word start cluster: 0x0000
                  Time: 0x0000  (00:00:00) (hms) 
                  Date: 0x0000  (1980/00/00) (ymd) 
      Starting Cluster: 0x0000 (0x00000000) <--- should be 0x0002 or higher.
             File Size: 0

FAT Root Entry (non LFN) (0x00000040)
                  Name: ··)···· 
             Extension:    
             Attribute: 0x20  Archive
        FAT12:reserved: 20 20 20 20 20 20 46 41 54 33
        FAT32:reserved: 20
   FAT32:creation 10th: 0x20
   FAT32:creation time: 0x2020
   FAT32:creation date: 0x2020
   FAT32:last accessed: 0x4146
FAT32:hi word start cluster: 0x3354
                  Time: 0x2032  (04:01:18) (hms) 
                  Date: 0x2020  (1996/01/00) (ymd) 
      Starting Cluster: 0x0000 (0x33540000)
             File Size: 0

FAT Root Entry (non LFN) (0x00000060)
                  Name: ········
             Extension: ···
             Attribute: 0x00 
        FAT12:reserved: 00 00 00 00 00 00 00 00 00 00
        FAT32:reserved: 00
   FAT32:creation 10th: 0x00
   FAT32:creation time: 0x0000
   FAT32:creation date: 0x0000
   FAT32:last accessed: 0x0000
FAT32:hi word start cluster: 0x0000
                  Time: 0x0000  (00:00:00) (hms) 
                  Date: 0x0000  (1980/00/00) (ymd) 
      Starting Cluster: 0x0000 (0x00000000) <--- should be 0x0002 or higher.
             File Size: 0

FAT Root Entry (non LFN) (0x00000080)
                  Name: ········
             Extension: ···
             Attribute: 0x00 
        FAT12:reserved: 00 00 00 00 00 00 00 00 00 00
        FAT32:reserved: 00
   FAT32:creation 10th: 0x00
   FAT32:creation time: 0x0000
   FAT32:creation date: 0x0000
   FAT32:last accessed: 0x0000
FAT32:hi word start cluster: 0x0000
                  Time: 0x0000  (00:00:00) (hms) 
                  Date: 0x0000  (1980/00/00) (ymd) 
      Starting Cluster: 0x0000 (0x00000000) <--- should be 0x0002 or higher.
             File Size: 0

FAT32 Info Block (0x00000000)
                   sig: 0x209000EB  (' ···') [1] <--- should be 0x41615252.
              reserved:
00000004  20 20 20 20 20 20 20 00-02 40 B2 05 02 00 00 00     .........@......
00000014  00 F8 00 00 3F 00 FF 00-00 20 00 00 00 10 A5 03     ....?...........
00000024  27 1D 00 00 00 00 00 00-02 00 00 00 01 00 06 00     '...............
00000034  00 00 00 00 00 00 00 00-00 00 00 00 80 00 29 01     ..............).
00000044  02 03 04 20 20 20 20 20-20 20 20 20 20 20 46 41     ..............FA
00000054  54 33 32 20 20 20 00 00-00 00 00 00 00 00 00 00     T32.............

The most confusing part is that the FAT32 signature - the magic number is always supposed to be 0x41615252. Google that. You'll see. It's a hardcoded signature but maybe I've got the wrong offset and at that point all bets are off.

最令人困惑的部分是FAT32签名-幻数始终应为0x41615252。 谷歌那个。 你会看到的。 这是一个硬编码的签名，但也许我得到了错误的补偿，到那时所有的赌注都没有了。

So do I have that? I can search a binary file for Hex values with a combo of xxd and grep. Note the byte swap:

那我有吗？ 我可以使用xxd和grep的组合在二进制文件中搜索十六进制值。 注意字节交换：

xxd another.img  | grep "6141"
00000200: 5252 6141 0000 0000 0000 0000 0000 0000  RRaA............
00000e00: 5252 6141 0000 0000 0000 0000 0000 0000  RRaA............

Just before this is 55 AA which is the last two bytes of the 64 byte partition table. mm

就在这之前是55 AA，它是64字节分区表的最后两个字节。 毫米

Now do I have two FAT32 info blocks and three Root Entries? I'm lost. I want to dump the directory entries.

现在我有两个FAT32信息块和三个根条目吗？ 我迷路了。 我要转储目录项。

What does fsstat say about the Root Directory?

fsstat对根目录有何看法？

File System Layout (in sectors)
Total Range: 0 - 61149183
* Reserved: 0 - 1457
** Boot Sector: 0
** FS Info Sector: 1
** Backup Boot Sector: 6
* FAT 0: 1458 - 8920
* FAT 1: 8921 - 16383
* Data Area: 16384 - 61149183
** Cluster Area: 16384 - 61149183
*** Root Directory: 16384 - 16447

I'll update this part as I learn more. I'm exhausted. Someone will likely read this and be like "you dork, seek HERE" and there's the byte that's wrong in the file system. That LFN (long file name) has no short one, etc" and then I'll know.

我将在学习更多内容时对此部分进行更新。 我精疲力尽了。 有人可能会读到这句话，就像“你很傻，在这里找”，文件系统中有错误的字节。 该LFN(长文件名)不短，以此类推”，然后我就知道了。

UPDATE #2:

更新＃2：

I skyped with Ali and we think we know what's up. He suggested I format the SD Card, record the same 3 shows (two test WAVs and one actual one) and then make an image of the GOOD disk to remove variables. Smart guy!

我和阿里一起飞翔，我们认为我们知道发生了什么。 他建议我格式化SD卡，记录相同的3个节目(两个测试WAV，一个实际的WAV)，然后制作一张GOOD磁盘映像以删除变量。 聪明的人！

We then took the first 12 megs or so of the GOOD.img and the BAD.img and piped them through xxd into HEX, then used Visual Studio Code to diff them.

然后，我们提取了GOOD.img和BAD.img的前12个兆位，并将它们通过xxd传递到HEX中，然后使用Visual Studio Code进行区分。

We can now visualize on the left what a good directory structure looks like and the right what a bad one looks like. Seems like I do have two recursive root directories with a space for the name.

现在，我们可以在左侧可视化一个好的目录结构，而在右侧则可视化一个不良的目录结构。 似乎我确实有两个递归根目录，其中名称空间。

Now if we wanted we could manually rewrite a complete new directory entry and assign our orphaned files to it.

现在，如果我们愿意，我们可以手动重写一个完整的新目录条目，然后将孤立文件分配给它。

That's what I would do if I was hired to recover data.

如果雇用我来恢复数据，那将是我要做的。

7zip所有东西 (7zip all the things)

Here's where it gets weird and it got so weird that both Pete Brown and I were like, WELL. THAT'S AMAZING.

在这里，它变得很奇怪，而且变得如此怪异，以至于我和Pete Brown都喜欢，WELL。 棒极了。

On a whim I right-clicked the IMG file and opened it in 7zip and saw this.

一时兴起，我右键单击了IMG文件，并在7zip中打开它，然后看到了。

See that directory there that's a nothing? A space? A something. It has no Short Name. It's an invalid entry but 7zip is cool with it. Let's go in. Watch the path and the \\. That's a path separator, nothing, and another path separator. That's not allowed or OK but again, 7zip is chill.

看到那个目录，那里什么都没有？ 空间？ 一个东西。 它没有短名称。 这是一个无效的条目，但7zip很酷。 让我们进去。观察路径和\\。 那是一个路径分隔符，什么也没有，还有另一个路径分隔符。 不允许或不能，但是同样，7zip很冷。

I dragged the files out and they're fine! The day is saved.

我将文件拖出，它们很好！ 这一天被保存。

The moral? There are a few I can see.

道德？ 我可以看到一些。

• Re-format the random SD cards you get from Amazon specifically on the device you're gonna use them.
  重新格式化从Amazon获得的随机SD卡，尤其是在要使用它们的设备上。
• FAT as a spec has a bunch of stuff that different "drivers" (Windows, VFAT, etc) may ignore or elide over or just not implement.
  FAT规范中有很多东西，不同的“驱动程序”(Windows，VFAT等)可能会忽略或忽略甚至无法实现。

• I've got 85% of the knowledge I need to spelunk something like this but that last 15% is a brick wall. I would need more patience and to read more about this.

  我已经掌握了需要像这样的东西的85％的知识，但是最后15％是一堵砖墙。 我需要更多的耐心，并阅读有关此内容的更多信息。

• Knowing how to do this is useful for any engineer. It's the equivalent of knowing how to drive a stick shift in an emergency even if you usually use Lyft.

  知道如何做到这一点对任何工程师都是有用的。 这等同于即使在平时使用Lyft的情况下也知道如何在紧急情况下进行手动变速。

  • I'm clearly not an expert but I do have a mental model that includes (but not limited to) bytes on the physical media, the file system itself, file tables, directory tables, partition tables, how they kinda work on Linux and Windows.
    我显然不是专家，但是我确实有一个心理模型，该模型包括(但不限于)物理介质上的字节，文件系统本身，文件表，目录表，分区表以及它们在Linux和Windows上的工作方式。

  • I clearly hit a wall as I know what I want to do but I'm not sure the next step.

    当我知道我想做什么时，我显然碰壁了，但是我不确定下一步。

    • There's a bad Directory Table Entry. I want to rename it and make sure it's complete and to spec.
      目录表条目错误。 我想重命名它，并确保它完整且符合规范。
• 7zip is amazing. Try it first for basically everything.
  7zip很棒。 首先尝试一下所有内容。

Ideally I'd be able to update this post with exactly what byte is wrong and how to fix it. Thanks to Ali, Pete, and Leandro for playing with me!

理想情况下，我将能够确切地更新哪个字节是错误的以及如何修复它。 感谢Ali，Pete和Leandro与我一起玩！

Your thoughts? (If you made it this far the truncated IMG of the 32 gig SD is here (500 megs) but you might have to pad it out with zeros to make some tools like it.

你的想法？ (如果到此为止，那么32 gig SD的截断的IMG就在这里( 500兆)，但是您可能必须用零填充它才能制作一些类似的工具。

Oh, and listen to https://hanselminutes.com/ as the interview was great and it's up now!

哦，收听https://hanselminutes.com/，因为采访很好，现在就来了！

翻译自: https://www.hanselman.com/blog/csi-the-case-of-the-missing-wav-audio-files-on-the-fat32-sd-card