これは物語なので、子供たちを締めてください.ご存知かもしれませんが、https://hanselminutes.com で素敵なポッドキャストを配信しています。聞いてください。
最近、いくつかの非常にクールなランダム イベントを通じて、Altered Carbon で Poe を演じる俳優の Chris Conner にインタビューする機会を得ました。私はショーの大ファンですが、特にクリスです。ポーは喜びであり、クリスはすべてのシーンを所有しているので、ショーを見る必要があります。それは非常に強力なキャストです.
私は通常、ポッドキャストのインタビューをリモートで行いますが、Chris に直接会ってたむろしたかったので、Zoom H6 レコーダーで構成されるローカルのポッドキャスティング リグを使用しました。
Shure XLR マイク 2 本、マイク スタンド、Zoom を持っています。ズーム H6 は非常に優れた機能を持っており、番組を録画する際に何度も使用しています。ロケット手術ではありませんが、常にテストする必要があります。
チャンスを逃したくなかったので、32GIGの高品質SDカードの5パックを手に入れました。 Zoomに新しいものを入れると、ZoomはすぐにSDカードを認識したので、その場でローカル録音を行い、再生しました。いいですね。 Zoom でローカルに再生したところ、Zoom のローカル スピーカーから録音を聞くことができました。マイクごとに片面ずつ、ステレオでファイルを録音しています。後のためにこれを覚えておいてください。
私は会議に早く行き、レコーディングのセットアップ全体をセットアップしました。ローカル モニターを接続して、再度テストしました。ローカルで記録および再生します。涼しい。 Chris が現れ、素晴らしいショーを録画しました。彼は婚約しており、私たちは今では仲良しです。Chipotle、トークショップ、SF、演技、AI などに行きます。ただのキラーな午後です。
家に帰ってSDカードを取り出してPCに挿入すると、これが表示されます。私はほとんど嘔吐します。めまいがする。
私はこの番組を 14 年間にわたって 730 を超えるエピソードで録画してきましたが、一度も番組を失ったことはありません。私は宿題をします - あなたと同じように。私は動揺しています。よし、息をする。問題に取り組みましょう。
ドライブを右クリックし、プロパティを確認します。息。これは 32 GB のドライブですが、Windows では 329 MB 使用 されていることがわかります . 300 メガバイトは、30 分の 2 チャンネルの WAV ファイルのサイズです。過去数百回のショーで 300 メガのファイルを見たので、私はこれを知っています。カメラが作成する JPEG のサイズを大まかに知っているように。それはあなたが知っていることです.
コマンドライン時間。ルート ディレクトリを一覧表示します。空の。もう一度確認してみてください。「すべてのファイルを表示してください」と表示されますが、変です。そこには Mac フォルダがありますが、SD カードは Mac で事前にフォーマットされている可能性があります。
<ブロック引用>興味深い筋書き - SD カードをフォーマットしていません。アマゾンの袋から出してそのまま使っています。事前にフォーマットされており、私はそれを受け入れました。テストしたところうまくいきましたが、「自分のカーペットを敷く」ことはしませんでした。そのまま家に引っ越しました。
「ここから下にあるすべてのフォルダーを表示する」アクションについてはどうでしょうか。 Windows エクスプローラーで見たものと同じです。ルート フォルダーには、それ自体である別のサブフォルダーがあります。キックなしのフォルダ「インセプション」です！
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
わかりました、ドライブはデータがあると考えていますが、私はそれを見ることができません。 SD カードを Zoom に戻し、再生してみます。
Zoom は、フォルダーとファイル、およびインタビュー自体を表示できます。そしてズームはそれを再生することができます。 Zoom は FAT32 ファイル システムを実装した組み込みデバイスであり、それを読み取ることができますが、Windows はできません。 Linuxはできますか？ Mac はできますか?
簡潔な答え。いいえ
<ブロック引用>ハッキー ノート: Zoom はファイルを表示および再生でき、ヘッドフォン/モニター ジャックが付いているため、アナログ 1/8 インチ ヘッドフォン ケーブルを Peavy PV6 ミキサーの 1/4 インチ入力にいつでも接続でき、オーディオをアナログでレスキューできます。品質の損失。 Zoom H6 の USB オーディオ出力機能を使用して、デジタル ケーブルを介してファイルを再生しないのはなぜですか? Zoomオーディオプレーヤーはそれをサポートしていないためです。それは 3 つのモードをサポートします - SD カード リーダー (Windows へのパススルーであり、再帰的なディレクトリを表示し、ファイルは表示しません)、オーディオ パススルーで、Zoom を Windows に対してオーディオ デバイスのように見せますが、SD は表示しません。カードをドライブとして使用したり、SD カードをデジタル インターフェイス経由で再生したり、ローカルに記録するメイン モードを使用したりできます。
法医学の時間です、子供たち。
私たちは32枚のSDカード（いわばディスクドライブ）を持っています。これは標準のFAT32でフォーマットされており、Zoom H6オーディオによってローカルに録音された300〜400メガの2チャンネル（クリスと私は2本のマイクを持っていました）のWAVファイルを持っています。再注文しますが、紛失したり台無しにしたりしたくありません.
SD カードにあるもののイメージを 1 バイトごとに取得する必要があるため、SD カードを突き刺して「仮想的に」いじり、変更し、修正し、物理的なものを変更せずに再試行できます。
「dd」は、45 年前にさかのぼる豊かで名高い歴史を持つコマンドライン ユーティリティです。 「データ定義」という意味ですが、私の頭では常に「ディスクドライブ」になります。
Windows で USB ドライブまたは SD カードを IMG ファイルに複製する方法
このSDカードを表すバイトストリーム/ファイルのバイトを取得できるWindows用のddのコピーがあります。たとえば、USD デバイス全体を取得できます:
dd if=\\?\Device\Harddisk1\Partition0 of=c:\temp\usb2.img bs=1M --size --progress
上記のように、ハードディスク番号とパーティション番号を知る必要があります。通常、これには 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
私のシステムではディスク 8 パーティション 1 のようです。パニックになる前に全部手に入れましょう。
dd if=\\?\Device\Harddisk8\Partition1 of=c:\temp\ZOMG.img bs=1M --size --progress
IFとOFは入力ファイルと出力ファイルで、SDカードの全サイズ分やります。後ほど説明しますが、これはやり過ぎの可能性があります。
このファイルは最終的に非常に大きくなり、操作が困難になりました。最初の 400 メガが必要だったことを覚えていますか?その部分だけ切り刻みます。
dd if=ZOMG.img of=SmallerZOMG.img bs=1M count=400
これは何ですか？これはファイル システムのイメージであることを忘れないでください。ファイル内のバイトだけです。 WAV ファイルでも、THIS ファイルでも、THAT ファイルでもありません。つまり、そうであると判断した場合ですが、実際には、中をのぞくと暗い、ぼろぼろの封筒であると考えることができます。周りを触って、内容が実際に何であるかの感覚を再構築できるかどうかを確認する必要があります.
IMG から Audition または Audacity への raw バイトのインポート
Adobe Audition と Audacity はどちらも、「RAW データのインポート」機能を備えたオーディオ アプリです。ただし、Audition にそれを解釈する方法を伝える必要があります。たくさんのWAVファイルがあります。シンプルはいくつありましたか？ 1チャンネル？ 2チャンネル？ 16ビットか32ビットか?たくさんの質問。
ファイル システムのこの 4 GB バイト配列をインポートして、何かを取得することはできますか?
何かのように見えます。オーディオ データが表示される前に、最初の部分がパーティション テーブル、ファイル システム ヘッダーなどの開始である可能性が高いことがわかります。ここでは 2 チャンネルとしてインポートしています。
声は聞こえますが、シマリスのように聞こえ、理解できません。何かが「倍増」しています。サンプルレート？いいえ、再確認しました。
2 つだと思いますが、ここでは 1 つのチャネルの生データのインポートです。
今、これは面白いです。私たちの通常の速度での会話の音声が聞こえます (プリアンブルの後) が、一度に 1 つの音節にすぎず、その後、同じ音節のより静かなバージョンが繰り返されます。音節から 30 分間のインタビューを再構築したくありません (読む:本当はできません) ですよね?
Zoom H6 は 2 チャンネルのファイルを録音し、各マイクに 1 つのチャンネルがあると言ったのを覚えていますか?あまり。チャンネルごとに 1 つのファイルを記録します。 whatthingL.wavとwhateverR.wavです。すっかり忘れてました！
上記の「1 チャネル」ファイルは、実際にはディスク上に配置されたバイトですよね?実際には、同時に書き込まれる 2 つのファイルです 、一度に数キロバイト、L、R、L、R、L、R。ここでは、サウンド ソフトウェアに、この「バイトごとのファイル システム ダンプ」を 1 つのファイルとして扱うように指示しています。同時期に作った2枚です。
ブランドルフライに似ています。どうやってそれをからかうのですか？もう配列を生のファイルとして扱うことはできません。そうではありません。そして、この画像のインターレースを効果的に解除するための独自の小さなアプリを書きたいと思っています (実際にはまだエネルギーがありません)。また、セグメント サイズが完全に信頼できるものなのか、それとも Zoom の記録によって変化するのかについてもわかりません。
<ブロック引用>注: Pete Brown は、間違った FAT32 ビット セットを持つ Sound Devices レコードの RIFF/WAV ファイルについて書いています。これはそうではありませんが、同じファミリに属しているため、Broadcast Wave ファイルが破損したり、暗号化されているように見える問題が発生した場合は注意が必要です。
この問題を解決するのを手伝ってくれた Pete Brown は、ディレクトリ テーブルの 16 進ダンプをツイートしたので、Zoom0001、Zoom0002 などのディレクトリを画像で見ることができます。
WSL を実行している Windows マシンで Ubuntu に移動させてください。ここで fdisk を実行して、この不良 SD カードのイメージが何であるかをある程度把握できます。また、最初の 0 ～ 400 メガバイトをハッキングしましたが、この IMG ファイルは 32 ギガ ドライブであると認識していることも覚えておいてください。積極的に切り詰められているだけです。
$ 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)
このIMGを「マウント」できますか？ ~/recovery という名前の Ubuntu/WSL2 フォルダーを作成します。ええ、大丈夫、そこには何もありません。 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 は、おそらく「彼らは FAT32 構造定義を書き直し、標準ライブラリを使用せず、間違いを犯した」と考えており、Leandro Pereria は、「起こり得ることは、LFN (長いファイル名) チェックサムが無効であり、わざわざ 8.3 のファイル名を入力する必要はありません... そのため、準拠している VFAT の実装はフォールバック 8.3 の名前を調べようとします。これはすべてスペースであり、「すべてパディングです。移動してください。」
アリは dosfsck の実行を提案しました マウントされたイメージで、ファイルがそこにあることをもう一度確認できますが、ルートエントリが 3 つほどありますか? dosfsck コマンドで参照できるように、私の img がマウントされているループを確認するために /proc/mounts の cat を実行したことに注意してください。
$ 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.
それらを確認することはできますが、Linux や Windows の vfat ファイル システム ドライバーでは取得できません。
Windows 用の mtools の一部としての DUMP.exe ユーティリティは素晴らしいですが、FAT32 ファイル テーブルの何が問題なのかわかりません。 Linux コマンド land で 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
さて、この破損したファイル システムをマウントする別の方法を見つけました。 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
同じ結果です。 mdu を実行すると、いくつかのフォルダーしか表示されません。 ZOOMxxxx がここにないことに注意してください
$ mdu -i ZOMG.img@@8192S ::
::/System Volume Information/ClientRecoveryPasswordRotation 1
::/System Volume Information/AadRecoveryPasswordDelete 1
::/System Volume Information 5
::/ 6
さて、理想的には、ここで 2 つのことを達成したいと考えています。
- 壊れている理由と正確に何が間違っているかを理解する。
- ここには名前のないルート ディレクトリがあり、手動で 16 進ダンプしてパッチを適用する忍耐力とスキルが不足しています。
- IMG をマウントして、ファイルをコピーすることで、ファイルを「通常どおり」コピーできるようにします。
更新 #1 - 数分考えた後、戻ってきました。
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)
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 ................
文字列 FAT32 がぶら下がっているので、正しい場所にシークしたことがわかります。この表を切り取って、より優れたグラフィカル ツールで視覚化できるかもしれません。
このオフセットから適切な (読み取り:任意の) チャンクを取得し、非常に小さな管理しやすいファイルに入れることができます:
dd if=ZOMG.img ibs=1 skip=4194304 count=64000 > another.img
そして、それを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.............
最も紛らわしい部分は、FAT32 署名です。マジック ナンバーは常に 0x41615252 であると想定されています。それをグーグル。わかるでしょ。これはハードコードされた署名ですが、オフセットが間違っている可能性があり、その時点ですべての賭けが無効になります.
それで、私はそれを持っていますか？ xxd と grep の組み合わせを使用して、16 進値のバイナリ ファイルを検索できます。バイト スワップに注意してください:
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............
この直前は、64 バイトのパーティション テーブルの最後の 2 バイトである 55 AA です。 mm
2 つの FAT32 情報ブロックと 3 つのルート エントリがありますか?道に迷いました。ディレクトリエントリをダンプしたい。
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
詳細がわかり次第、この部分を更新します。疲れた。誰かがこれを読んで、「あなたは馬鹿げている、ここを探しなさい」と言うでしょう。ファイル システムに間違ったバイトがあります。その LFN (長いファイル名) には短いファイル名などはありません。
更新 #2:
私はアリとスカイプしました。彼は、SD カードをフォーマットし、同じ 3 つのショー (2 つのテスト WAV と 1 つの実際の WAV) を録音してから、GOOD ディスクのイメージを作成して変数を削除することを提案しました。頭のいい人！
次に、GOOD.img と BAD.img の最初の 12 MB 程度を取得し、xxd を介して HEX にパイプし、Visual Studio Code を使用してそれらを比較しました。
左側に良いディレクトリ構造がどのように見えるか、右側に悪いディレクトリ構造がどのように見えるかを視覚化できます。名前用のスペースを含む 2 つの再帰ルート ディレクトリがあるようです。
必要に応じて、完全な新しいディレクトリ エントリを手動で書き直し、孤立したファイルをそれに割り当てることができます。
もし私がデータの回復に雇われたら、そうするでしょう。
すべてを7zipで圧縮
ここが奇妙になり、ピート・ブラウンと私はどちらもそうだったほど奇妙になりました。すごいですね。
気まぐれに IMG ファイルを右クリックして 7zip で開くと、これが表示されました。
何もないそのディレクトリを参照してください。空間？何か。短縮名はありません。無効なエントリですが、7zip はクールです。入りましょう。パスと \\ に注意してください。それはパスセパレーターであり、何もなく、別のパスセパレーターです。それは許可されていないか、問題ありませんが、繰り返しますが、7zip は冷静です。
ファイルをドラッグしましたが、問題ありません。その日は救われました。
道徳？私が見ることができるいくつかがあります.
- Amazon からランダムに入手した SD カードを、使用するデバイス専用に再フォーマットします。
- 仕様としての FAT には、さまざまな「ドライバ」(Windows、VFAT など) が無視したり、省略したり、単に実装しない可能性のあるものがたくさんあります。
- このようなものを探検するために必要な知識の 85% はありますが、最後の 15% はレンガの壁です。私はもっと忍耐が必要で、これについてもっと読む必要があります.
- これを行う方法を知っていると、どのエンジニアにとっても役立ちます。これは、通常は Lyft を使用している場合でも、緊急時にスティック シフトを運転する方法を知っているのと同じです。
- 私は明らかに専門家ではありませんが、物理メディア上のバイト、ファイル システム自体、ファイル テーブル、ディレクトリ テーブル、パーティション テーブル、それらがどのように機能するかを含む (ただしこれらに限定されない) メンタル モデルを持っています。 Linux と Windows。
- やりたいことはわかっているが、次のステップがわからないので、明らかに壁にぶつかっています。
- 不適切なディレクトリ テーブル エントリがあります。名前を変更して、完全で仕様どおりであることを確認したい.
- 7zip は素晴らしいです。基本的にすべて最初に試してみてください。
理想的には、この投稿を正確に更新して、どのバイトが間違っているのか、それを修正する方法を教えてください。一緒に遊んでくれた Ali、Pete、Leandro に感謝!
あなたの考え？ (ここまで作成した場合、32 ギガ SD の切り詰められた IMG がここにあります (500 メガ)。ただし、同様のツールを作成するには、ゼロを埋め込む必要がある場合があります。
ああ、インタビューが素晴らしかったので、https://hanselminutes.com/ を聞いてください!
スポンサー: Riderでの開発はもう試しましたか?この高速で機能豊富なクロスプラットフォーム IDE は、Windows、Mac、および Linux 上の .NET、ASP.NET、.NET Core、Xamarin、および Unity アプリケーションのコードを改善します。