Připoutejte se děti, protože tohle je pohádka. Jak možná víte, mám krásný podcast na https://hanselminutes.com. Měli byste poslouchat.
Nedávno jsem díky řadě super cool náhodných událostí dostal příležitost udělat rozhovor s hercem Chrisem Connerem, který hraje Poea v Altered Carbon. Jsem velkým fanouškem show, ale především Chrise. Měli byste se na show podívat, protože Poe je radost a Chris vlastní každou scénu, a to s VELMI silným obsazením.
Rozhovory pro podcast obvykle dělám na dálku, ale chtěl jsem se setkat s Chrisem a potkat se osobně, takže jsem použil místní podcastingové zařízení, které se skládá z rekordéru Zoom H6.
Mám dva mikrofony Shure XLR, stojan na mikrofon a zoom. Zoom H6 je velmi dobrý dříč a už jsem ho mnohokrát použil při nahrávání pořadů. Není to raketová operace, ale člověk by měl vždy své věci vyzkoušet.
Nechtěl jsem riskovat, že jsem si vzal 5 balení 32GIG vysoce kvalitních SD karet. Dal jsem nový do Zoomu, Zoom okamžitě rozpoznal SD kartu, takže jsem tam udělal místní záznam a přehrál ho. To zní dobře. Přehrál jsem to lokálně na Zoomu a slyšel jsem záznam z místního reproduktoru Zoomu. Nahrává soubor stereofonně, jedna strana pro každý mikrofon. Pamatujte si to na později.
Šel jsem brzy na schůzku a připravil celé nastavení nahrávání. Připojil jsem místní monitor a znovu testoval. Nahrává a přehrává lokálně. Chladný. Chris se objeví, nahráli jsme fantastickou show, je zasnoubený a teď jsme kámoši a jdeme do Chipotle, talk shopu, sci-fi, herectví, AI atd. Prostě vražedné odpoledne všude kolem.
Jdu domů a vytáhnu SD kartu a vložím ji do PC a vidím tohle. Skoro zvracím. Zatočí se mi hlava.
Pořad jsem nahrával přes 730 dílů za 14 let a nikdy jsem o žádný pořad nepřišel. Dělám svůj domácí úkol - jako byste měli vy. motám se. Dobře, dýchej. Pojďme na problém.
Klikněte pravým tlačítkem na jednotku, zkontrolujte vlastnosti. Dýchat. Toto je 32GB disk, ale Windows vidí, že je využito 329 MB . 300ish megs je velikost 30 minut dlouhého dvoukanálového WAV souboru. Vím to, protože jsem se podíval na 300 mega souborů za posledních několik stovek představení. Stejně jako byste mohli zhruba vědět, jakou velikost JPEG vytváří váš fotoaparát. To je věc, kterou víte.
Čas příkazového řádku. Vypište kořenový adresář. Prázdný. Zkontrolujte to znovu, ale "zobrazit všechny soubory," divné, je tam složka pro Mac, ale možná byla SD karta předformátována na Macu.
Zajímavý bod zápletky - Neformátoval jsem SD kartu. Používám ho tak, jak vyšel z obalu od Amazonu. Přišel předformátovaný a já to přijal. Testoval jsem to a fungovalo to, ale "nenainstaloval jsem si vlastní koberec." Přestěhoval jsem se do domu tak, jak je.
A co malá akce "zobrazit všechny složky odtud dolů"? To samé, co jsem viděl v Průzkumníku Windows. Kořenová složka má další podsložku, která je sama o sobě. Je to složka "Počátek" bez kopu!
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, disk si myslí, že jsou tam data, ale já je nevidím. Vložím SD kartu zpět do Zoomu a pokusím se ji přehrát.
Zoom může vidět složky a soubory A samotný rozhovor. A Zoom to umí přehrát. Zoom je vestavěné zařízení s implementací souborového systému FAT32 a umí jej číst, ale Windows ne. Může Linux? Může Mac?
Stručná odpověď. Ne.
Hacky Poznámka: Vzhledem k tomu, že Zoom může vidět a přehrávat soubor a má konektor pro sluchátka/monitor, mohl jsem vždy zapojit analogový 1/8" kabel pro sluchátka do 1/4" vstupu na mém mixu Peavy PV6 a zachránit zvuk nějakým analogovým ztráta kvality. Ptáte se, proč nepoužiji funkci USB Audio out u Zoom H6 a nepřehraju soubor přes digitální kabel? Protože to audio přehrávač Zoom nepodporuje. Podporuje tři režimy – čtečka karet SD (což je průchod do Windows a zobrazuje mi rekurzivní adresáře a žádné soubory), průchod zvuku, který umožňuje, aby Zoom vypadal jako zvukové zařízení pro Windows, ale nezobrazuje SD kartu jako jednotku nebo umožnit přehrávání SD karty přes digitální rozhraní nebo její hlavní režim, kde se nahrává lokálně.
Je čas na forenzní vyšetřování, děti.
Máme 32 SD kartu - diskovou jednotku jakoby - to je standardní formát FAT32, který má 300-400 meg dvoukanálového (Chris a já jsme měli dva mikrofony) WAV souboru, který byl nahrán lokálně zvukem Zoom H6 doobjednat a nechci to příliš ztratit nebo pokazit.
Potřebuji vzít bajt za bajtem obrázek toho, co je na SD kartě, abych do toho mohl šťouchnout a "virtuálně" si s tím pohrát, změnit to, opravit to, zkusit to znovu, aniž bych měnil fyzickou stránku.
"dd" je nástroj příkazového řádku s bohatou a historií sahající 45 let zpět. I když to znamená „definice dat“, v mé hlavě to bude vždy „disk“.
Jak naklonovat jednotku USB nebo kartu SD do souboru IMG v systému Windows
Mám kopii dd pro Windows, která mi umožňuje získat bajt pro byte stream/soubor, který představuje tuto SD kartu. Mohl bych například získat celé zařízení v USD:
dd if=\\?\Device\Harddisk1\Partition0 of=c:\temp\usb2.img bs=1M --size --progress
Potřebuji znát číslo pevného disku a číslo oddílu, jak vidíte výše. Obvykle k tomu používám 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
Vypadá to, že je to Disk 8 Partition 1 v mém systému. Pojďme na to všechno, než zpanikařím.
dd if=\\?\Device\Harddisk8\Partition1 of=c:\temp\ZOMG.img bs=1M --size --progress
IF a OF jsou vstupní a výstupní soubor a udělám to pro celou velikost SD karty. Je to však pravděpodobně přehnané, jak uvidíme za sekundu.
Tento soubor byl nakonec naprosto masivní a těžko se s ním pracovalo. Pamatujete si, že jsem potřeboval jen prvních 400 megů? Nasekám jen tu část.
dd if=ZOMG.img of=SmallerZOMG.img bs=1M count=400
co to ale je? Pamatujte, že je to obraz systému souborů. Je to jen bajtů v souboru. Není to soubor WAV nebo TENTO soubor nebo TEN soubor. Myslím, že ano, pokud se rozhodneme, že ano, ale ve skutečnosti o tom uvažujeme tak, že je to rozbitá obálka, která je tmavá, když do ní nahlédnu. Budeme se muset prokousat a zjistit, jestli dokážeme znovu vytvořit pocit, jaký obsah skutečně je.
Import nezpracovaných bajtů z IMG do Audition nebo Audacity
Adobe Audition i Audacity jsou zvukové aplikace, které mají funkci „Import RAW Data“. Nicméně musím Auditionovi říct, jak to má interpretovat. Je tam spousta WAV souborů. Kolik prostých bylo? 1 kanál? 2 kanál? 16bit nebo 32bit? Spousta otázek.
Mohu jen importovat toto 4gigabajtové pole souborového systému a něco získat?
Vypadá to jako něco. Můžete vidět, že první část je pravděpodobně začátek tabulky oddílů, hlavičky souborového systému atd., než se objeví zvuková data. Zde je import jako 2 kanál.
Slyším hlasy, ale znějí jako chipmunkové a nejsou srozumitelné. Něco je „zdvojené“. Vzorkovací frekvence? Ne, dvakrát jsem to zkontroloval.
Zde je import nezpracovaných dat z 1 kanálu, i když si myslím, že jsou dva.
Nyní je zajímavé TOTO. Slyším zvuk normální rychlostí, jak mluvíme (po preambuli), ALE je to vždy jen slabika a pak se opakuje tišší verze stejné slabiky. Nechci (čti:opravdu nemůžu) znovu sestavovat 30minutový rozhovor ze slabik, že?
Pamatujete si, když jsem řekl, že Zoom H6 nahrává dvoukanálový soubor s jedním kanálem na mikrofon? Spíš ne. Zaznamenává JEDEN SOUBOR NA KANÁL. Jakýkoli L.wav a jakýkoli R.wav. Úplně jsem zapomněl!
Tento „jeden kanál“ soubor výše jsou ve skutečnosti bajty, jak byly umístěny na disku, že? Jsou to vlastně dva soubory zapsané současně , několik kilobajtů najednou, L,R,L,R,L,R. A tady říkám svému zvukovému softwaru, aby s tímto "byte for byte file system dump" nakládal jako s jedním souborem. Jsou to dva, které vznikly ve stejnou dobu.
Je to jako Brundlefly. Jak to mám rozdělit? No, už nemůžu s polem zacházet jako se surovým souborem, to ne. A chci (opravdu ještě nemám energii) napsat svou vlastní malou aplikaci, která by efektivně odstranila prokládání tohoto obrázku. Také nevím, zda je velikost segmentu dokonale spolehlivá nebo zda se liší podle zaznamenaného Zoomu.
POZNÁMKA: Pete Brown psal o souborech RIFF/WAV ze záznamů Sound Devices, které mají nesprávně nastavený FAT32 bit. Není to tak, ale je ve stejné rodině a stojí za zmínku, pokud budete mít někdy problém s poškozením nebo zašifrovaným souborem Broadcast Wave.
Pete Brown, který mi pomáhal vyřešit tento problém, tweetoval hexdump tabulky adresářů, takže na obrázku můžete vidět adresáře Zoom0001, Zoom0002 atd.
Dovolte mi přesunout se do Ubuntu na mém počítači se systémem Windows se systémem WSL. Zde mohu spustit fdisk a získat určitou představu o tom, co je tento obrázek špatné SD karty. Pamatujte také, že jsem hacknul prvních 0-400 Megs, ale tento soubor IMG si myslí, že je to 32gigový disk, protože je. Jen to bylo agresivně zkráceno.
$ 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)
Možná bych mohl "namontovat" tento IMG? Vytvořím složku na Ubuntu/WSL2 s názvem ~/recovery. Jejda, dobře, nic tam není. Mohu vzít velikost sektoru 512 krát počáteční blok 8192 a použít to jako offset.
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 si myslí, že možná „přepsali definici struktury FAT32 a nepoužili standardní knihovnu a udělali chybu,“ a Leandro Pereria postuluje, „co by se mohlo stát, je, že kontrolní součet LFN (dlouhý název souboru) je neplatný a oni to udělali. neobtěžujte se vyplňováním názvu souboru 8.3... aby se vyhovující implementace VFAT pokusily podívat se na záložní název 8.3, jsou to všechny mezery a zjistily, že „je to všechno vycpávka, pokračujte.“
Ali navrhl spustit dosfsck na připojeném obrazu a můžete znovu vidět, že soubory tam jsou, ale jsou tam jako 3 kořenové položky? Poznámka:Udělal jsem kočku /proc/mounts, abych viděl smyčku, ke které je připojen můj img, takže se na ni mohu odkázat v příkazu 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.
Vidíme je, ale nemůžeme se k nim dostat pomocí ovladače souborového systému vfat v Linuxu nebo ve Windows.
Nástroj DUMP.exe jako součást mtools pro Windows je úžasný, ale nemohu přijít na to, co je v tabulce souborů FAT32 špatně. Mohu spustit minfo na linuxovém příkazu land, který mu říká, že má přeskočit 8192 sektorů pomocí modifikátoru @@offset:
$ 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
Dobře, teď jsme našli ještě DALŠÍ způsob, jak připojit tento poškozený souborový systém. S mtools použijeme mdir k výpisu kořenového adresáře. Všimněte si, že je něco tak špatně, že musím nastavit mtools_skip_check=1 na ~/.mtoolsrc a pokračovat.
$ 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
Stejný výsledek. Mohu spustit mdu a zobrazit jen několik složek. Všimněte si, že zde chybí ZOOMxxxx
$ mdu -i ZOMG.img@@8192S ::
::/System Volume Information/ClientRecoveryPasswordRotation 1
::/System Volume Information/AadRecoveryPasswordDelete 1
::/System Volume Information 5
::/ 6
Nyní zde v ideálním případě chci dosáhnout dvou věcí.
- Vědět, PROČ je poškozený, a přesně CO je špatně.
- Je zde bezejmenný kořenový adresář a já postrádám trpělivost a dovednosti, abych jej ručně hexdumpoval a opravoval.
- Budete moci zkopírovat soubory "normálně" připojením IMG a zkopírováním je.
AKTUALIZACE #1 - Po několika minutách přemýšlení jsem zpět.
Pokud použiji mmls ze Sleuthkitu, vidím to.
$ 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)
Pokud znovu provedu offset 512*8192 a vizualizuji tabulku FAT32 v Hexdump/xxd takto:
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 ................
Vidím, že jsem hledal správné místo, protože řetězec FAT32 právě visí ven. Možná bych mohl vystřihnout tuto tabulku a vizualizovat ji v lepším grafickém nástroji.
Mohl bych vzít rozumný (čti:libovolný) kus z tohoto offsetu a vložit ho do velmi malého spravovatelného souboru:
dd if=ZOMG.img ibs=1 skip=4194304 count=64000 > another.img
A pak to nahrajte do dump.exe na Windows, což je opravdu sakra nástroj. Zdá se, že přemýšlí a myslí si, že existuje více FAT Root Entries (což může být důvod, proč vidím tento podivný kořen duchů). Všimněte si také částí „mělo by být“.
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.............
Nejvíce matoucí je, že podpis FAT32 - magické číslo má být vždy 0x41615252. Google to. Uvidíte. Je to pevně zakódovaný podpis, ale možná mám špatný offset a v tu chvíli jsou všechny sázky vypnuté.
Takže to mám? Mohu hledat v binárním souboru Hex hodnoty pomocí kombinace xxd a grep. Všimněte si výměny bajtů:
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............
Těsně před tím je 55 AA, což jsou poslední dva bajty 64bajtové tabulky oddílů. mm
Nyní mám dva informační bloky FAT32 a tři kořenové záznamy? Ztratil jsem se. Chci vypsat položky adresáře.
Co říká fsstat o kořenovém adresáři?
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
Jakmile se dozvím více, tuto část aktualizuji. Jsem vyčerpaný. Někdo si to pravděpodobně přečte a řekne „ty hlupáku, hledej ZDE“ a v systému souborů je chybný bajt. Ten LFN (dlouhý název souboru) nemá krátký atd.“ a pak to budu vědět.
AKTUALIZACE #2:
Skypoval jsem s Ali a myslíme si, že víme, co se děje. Navrhl, abych naformátoval SD kartu, nahrál stejné 3 pořady (dvě testovací WAV a jeden skutečný) a pak vytvořil obraz DOBRÉHO disku, abych odstranil proměnné. Chytrý chlap!
Potom jsme vzali prvních asi 12 megů GOOD.img a BAD.img a převedli je přes xxd do HEX, pak jsme je porovnali pomocí Visual Studio Code.
Nyní si můžeme na levé straně vizualizovat, jak vypadá dobrá adresářová struktura a napravo, jak vypadá špatná. Zdá se, že mám dva rekurzivní kořenové adresáře s mezerou pro jméno.
Nyní, pokud bychom chtěli, mohli bychom ručně přepsat kompletní nový záznam adresáře a přiřadit k němu naše osiřelé soubory.
To bych udělal, kdybych byl najat na obnovu dat.
7zazipujte všechny věci
Tady to začíná být divné a začalo to být tak divné, že jsme si Pete Brown i já říkali, NO. TO JE ÚŽASNÉ.
Z rozmaru jsem kliknul pravým tlačítkem na soubor IMG a otevřel jej v 7zip a viděl jsem toto.
Vidíš tam ten adresář, že tam nic není? Prostor? Něco. Nemá Krátký název. Je to neplatný záznam, ale 7zip je v pohodě. Pojďme dovnitř. Sledujte cestu a \\. To je oddělovač cest, nic a další oddělovač cest. To není povoleno nebo OK, ale znovu, 7zip je cool.
Vytáhl jsem soubory a jsou v pořádku! Den je uložen.
Morálka? Pár jich vidím.
- Přeformátujte náhodné SD karty, které získáte od Amazonu, konkrétně na zařízení, kde je budete používat.
- FAT jako specifikace má spoustu věcí, které mohou různé „ovladače“ (Windows, VFAT atd.) ignorovat nebo je obejít nebo je prostě neimplementovat.
- Mám 85 % znalostí, které potřebuji, abych něco takového napsal, ale posledních 15 % je cihlová zeď. Potřeboval bych více trpělivosti a přečíst si o tom více.
- Vědět, jak to udělat, je užitečné pro každého inženýra. Je to ekvivalent toho, jak v případě nouze řídit řazení pákou, i když obvykle používáte Lyft.
- Zjevně nejsem odborník, ale mám mentální model, který zahrnuje (mimo jiné) bajty na fyzickém médiu, samotný souborový systém, tabulky souborů, tabulky adresářů, tabulky oddílů, způsob, jakým fungují Linux a Windows.
- Jasně jsem narazil do zdi, protože vím, co chci udělat, ale nejsem si jistý dalším krokem.
- Je zde špatný záznam adresářové tabulky. Chci jej přejmenovat a ujistit se, že je úplný a specifikovaný.
- 7zip je úžasný. Vyzkoušejte to nejprve v podstatě u všeho.
V ideálním případě bych byl schopen aktualizovat tento příspěvek přesně tím, který bajt je špatně a jak to opravit. Děkuji Ali, Peteovi a Leandrovi, že si se mnou hráli!
Tvoje myšlenky? (Pokud jste to dotáhli až sem, je zde zkrácený IMG z 32gigového SD (500 megů), ale možná ho budete muset doplnit nulami, aby se některé nástroje mohly líbit.
Jo, a poslouchejte https://hanselminutes.com/, protože rozhovor byl skvělý a už je tady!
Sponzor: Zkoušeli jste už vývoj v Rideru? Toto rychlé a na funkce bohaté multiplatformní IDE vylepšuje váš kód pro aplikace .NET, ASP.NET, .NET Core, Xamarin a Unity na Windows, Mac a Linux.