古いフロッピーイメージファイル（.ima形式）のマウント-どれくらい難しいですか？
ArchLinuxでmountを試して.ima形式（ 。img のようなフロッピーへの生のダンプ）のフロッピーイメージファイルにアクセスしようとしています。
このファイルは30のセットの一部です。ブート可能ではなく、セットの続きです。インストールやクローン作成のための操作ではありません。ディスクの他のデータに含まれているドキュメントに興味があります。
画像ファイル情報
この画像ファイルに関する情報は次のとおりです。
# file U19.IMA
U19.IMA: PC formatted floppy with no filesystem
# fdisk -lu U19.IMA
Disk U19.IMA: 1.4 MiB, 1474560 bytes, 2880 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
(parted) print
Error: /home/meh/Downloads/U19.IMA: unrecognised disk label
Model: (file)
Disk /home/meh/Downloads/U19.IMA: 1475kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
マウント失敗
一般的なエラーメッセージは次のとおりです。
mount -o ro,loop U19.IMA /mnt/cd/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
-tを使用してタイプを指定しようとする多くの組み合わせ、つまりntfs、msdos、iso9660、vfatを試しましたが、常に同じエラーが発生しました。 ntfsファイル形式のようなものだと思ったのですが、ntfs-3Gはそれほどうまく機能しないため、そうではありません。
# ntfs-3g -o loop U19.IMA /mnt
NTFS signature is missing.
Failed to mount '/home/meh/Downloads/U19.IMA': Invalid argument
The device '/home/meh/Downloads/U19.IMA' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
# ntfsclone -r -o file.img U19.IMA
ntfsclone v2013.1.13 (libntfs-3g)
ERROR: Input file is not an image! (invalid magic)
誰かがおそらくMinix fsを提案しました。私が実際に現在の構成でそのようなファイルシステムをマウントできるかどうかは明確ではありませんが、試してみました：
mount -t minix -o loop U19.IMA /mnt/cd
which gave the generic error but there was this at the bottom of the log:
VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.
特定のタイプのファイルシステムを指定すると、ログに特定のタイプのエラーが発生するため、これは決定的なものではないようです。 [fuseiso][2]も試しました：
# fuseiso U19.IMA /mnt/cd
init: wrong standard identifier in volume descriptor 0, skipping..
init: wrong standard identifier in volume descriptor 1, skipping..
init: wrong standard identifier in volume descriptor 2, skipping..
init: wrong standard identifier in volume descriptor 3, skipping..
init: wrong standard identifier in volume descriptor 4, skipping..
init: wrong standard identifier in volume descriptor 5, skipping..
init: wrong standard identifier in volume descriptor 6, skipping..
init: wrong standard identifier in volume descriptor 7, skipping..
init: wrong standard identifier in volume descriptor 8, skipping..
init: wrong standard identifier in volume descriptor 9, skipping..
init: wrong standard identifier in volume descriptor 10, skipping..
init: wrong standard identifier in volume descriptor 11, skipping..
init: wrong standard identifier in volume descriptor 12, skipping..
init: wrong standard identifier in volume descriptor 13, skipping..
init: wrong standard identifier in volume descriptor 14, skipping..
init: wrong standard identifier in volume descriptor 15, skipping..
init: wrong standard identifier in volume descriptor 16, skipping..
init: wrong standard identifier in volume descriptor 17, exiting..
dmesgでそのようなものを見ることができる場所：
[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem
また、lsmod | grep loopは
loop 18511 0
代替スーパーブロック はありません：
# mkfs -n U19.IMA
mke2fs 1.42.8 (20-Jun-2013)
U19.IMA is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=1572864
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group
多くの cases とは対照的に、私が読んだところ、イメージにはパーティションが組み込まれていないため、ここでオフセットを指定する必要はないようです。このような場合、ddコマンドを使用して、マウントを許可するオフセット値を使用してコンテンツを同様のイメージに転送することがあります。これは、mountコマンドにオフセットを直接指定するのと同じようです。しかし、これは this のように簡単なはずです。単純なlosetupが使用され、その後、ループデバイスがマウントされます。 .imaファイルをlosetupでリンクできますが、ループデバイスをマウントしようとすると、最初のエラーメッセージが表示されます。
データの整合性
最後に、safecopy --stage1はデータの問題を報告せず、ステージ3までの出力は同じままで、同じエラーが発生します。
# safecopy U19.IMA test.img --stage1
Low level device calls enabled mode: 2
Reported hw blocksize: 4096
Reported low level blocksize: 4096
File size: 1474560
Blocksize: 4096
Fault skip blocksize: 147456
Resolution: 147456
Min read attempts: 1
Head moves on read error: 0
Badblocks output: stage1.badblocks
Marker string: BaDbLoCk
Starting block: 0
Source: U19.IMA
Destination: test.img
. ;-} 100%
Done!
Recovered bad blocks: 0
Unrecoverable bad blocks (bytes): 0 (0)
Blocks (bytes) copied: 360 (1474560)
これがファイルの先頭です。コンテンツはそのままのようです。
dd if=U19.IMA | hexdump -C | head -n 10
00000000 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 |................|
*
00004600 34 2e 30 2e 32 20 33 38 36 75 6e 69 78 20 46 6e |4.0.2 386unix Fn|
00004610 64 20 53 65 74 20 35 20 6f 66 20 31 30 0a 00 00 |d Set 5 of 10...|
00004620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
「フォレンジック」
raw image はソースメディアのセクターごとのバイナリコピーで構成されるため、ファイルの内容の実際のフォーマットは、イメージの作成元のディスクのファイルシステム（ FATのバージョンとして）。[...] IMGファイルはディスクの内容以外の追加データを保持しないため、これらのファイルは、ファイルシステムを検出できるプログラムによってのみ処理できます。
提案に従って、私はset（30）の他の画像ファイルのいくつかを分析し始めました：
fdisk -lu U14.IMA
Disk U14.IMA: 1.4 MiB, 1474560 bytes, 2880 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
This doesn't look like a partition table. Probably you selected the wrong device.
Device Boot Start End Blocks Id System
U14.IMA1 3840 11519 3840 0 Empty
U14.IMA2 2425393152 4850786447 1212696648 0 Empty
U14.IMA3 ? 2425393296 4850786591 1212696648 90 Unknown
U14.IMA4 ? 2425393296 4850786591 1212696648 90 Unknown
申し訳ありませんが、パーティションテーブルのように見えますが、異常です。 id 90property が含まれます：
90h MBR, EBR CHS, LBA x86, 68000, 8080/Z80 Hidden, Filesystem FreeDOS Free FDISK Hidden FAT16 (corresponds with 04h i.e. MS Fat16 DOS 3.0+ < 65536 sectors)
だから私が得るイメージをマウントしようとしています：
# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv' <-----
誰かが示唆したように、あなたは 'System V and Coherent filesystem support' kernelでコンパイルされた のような特定のものが必要ですmount -t sysvなどを使用します。これはAT＆T UNIXシステムV/386リリース4バージョン2.1インストールメディアの一部であるため、sysv文字列はそれほど驚くべきものではありません。Sunがサポートしていたポート 2006年まで -これらのイメージは、実際には、画像にバンドルされているテキストファイルは、ブートセクターの性質と使用中のフォーマットのため、インストールに必要であることを示しています。素材が元々 Teledisk （TD0） format であったという兆候があります。これはオリジナルの素材ではないことをここで強調したいと思います。いずれにしても、質問で説明されているように実際にオフセットを計算することはできません-512で除算したときに整数で終わらないか、試しても適切なオフセットが見つからないようです-dd: cannot skip to specified offset, 0 writesなど。したがって、現時点での答えはフォレンジックに関するものであり、イメージファイルに関するものではありません。
Qemuによる過去のイメージソースOSのエミュレーション
AT＆T UNIX System Vリリース4バージョン2.1
LABEL Version X of X
AT&T UNIX SVR4.0 2.1 --------------------------------------------------
U01.IMA Maintanace Disk1 2.1 2 of 2
U02.IMA Remote Terminal 2.1 1 of 1
Package
U03.IMA BSD Comp. Pkg. 2.1 1 of 2
U04.IMA BSD Comp. Pkg. 2.1 2 of 2
U05.IMA Networking Supp. 2.1 1 of 1
Util. Pkg.
U06.IMA Xenix Comp. Pkg 2.1 1 of 1
U07.IMA FACE Pkg. 2.1 1 of 1
U08.IMA FMLI Pkg. 2.1 1 of 1
U09.IMA Editing Utils. 2.1 1 of 1
U10.IMA OA&M Basic & Ext. 2.1 1 of 3
U11.IMA OA&M Basic & Ext. 2.1 2 of 3
U12.IMA OA&M Basic & Ext. 2.1 3 of 3
U13.IMA Foundation Set 2.1 1 of 10
Base System Pkg.
2 User System
U14.IMA Base 2.1a 1 of 10
U15.IMA Base 2.1 2 of 10
U16.IMA Base 2.1a 2 of 10
U17.IMA Base 2.1 3 of 10
U18.IMA Base 2.1 4 of 10
U19.IMA Base 2.1 5 of 10
U20.IMA Base 2.1 6 of 10
U21.IMA Base 2.1 7 of 10
U22.IMA Base 2.1 8 of 10
U23.IMA Base 2.1 10 of 10
U24.IMA Maintanance 1 2.1 1 of 2
U25.IMA Base 2.1 9 of 10
U26.IMA Printer Pkg 2.1 3 of 3
U27.IMA Printer Pkg 2.1 2 of 3
U28.IMA Printer Pkg 2.1 1 of 3
U29.IMA 16 to unlimited 2.1 1 of 1
User License
U30.IMA 2 to 16 User 2.1 1 of 1
License
提案されたように、私はセット内の以前のイメージからインストールしました。 U19は起動できないため、qemuここで説明するように を基本的にイメージ14（最初はlosetup /dev/loop0 U14.IMA、次に単純なqemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a）から開始します。ここでいいのは、OS自体でイメージをマウント/アンマウントする必要がないことです。qemuでctrl-alt-2または1を使用して、モニターにアクセスするか、モニターから離れ、list blocksを使用して何を参照するかを指定します。マウントされ、そのインターフェイスでchange floppy0 imagenameを使用して、たとえばインストール中にイメージファイルを変更します。
インストール中にU19.IMA（ディスク5）を提供する必要があり（インストールのテキストログについては this を参照してください-ハイライトはMS-DOSへの参照です！）、これで終わりましたつまり、適切にインストールされたAT＆T UNIX Sys V 386 OSなので、これはU19.IMAが正常に機能しているディスクイメージであることをほぼ確認しています。
デフォルトでは、/ dev/fdは/ dev/fdにマウントされ、ブロック（/ dev/dsk/f0）およびraw（/ dev/dsk/f0）デバイスを介したフロッピーアクセスもあります。ディレクトリをフロッピーに変更すると、1から23までの番号が付いたファイルが表示されます（これは私が推測するキャラクターデバイスの構造にすぎません）。 rawデバイスとblockデバイスをcatして、フロッピーデータが存在することを確認することもできますが、それは可能な限り近いです。
そのOSでは、たとえば解凍されたバイナリファイルの場合のように、スクリプトをディレクトリから起動してフロッピーからインストールしないことに気づきました。ここではpkgadd -d diskette1を使用します（最後のWordは確かに一部のエイリアスですが、SCO stuff for pkgadd（1M） に-dスイッチへの参照が見つかりました。通常、商用Unix（Oracle、HP share pkgadd（1M））コマンドを発行すると、フロッピーを提供し、ユーザーが制御できないルーチンが起動します。ただし、ルーチンがドライブに何があるかを見つけた後で「no」と言う場合を除きます。インストールシーケンスを開始するディスクの場合（U03 、U05など）、これはインストールされ、パッケージのインストールが完了するまで次のフロッピーなどを要求します。セットの先頭ではないフロッピーを置くと、基本的に何も検出されませんが、おそらく使用する必要があると通知されます。代わりにinstallpkgコマンド。
リグに物理フロッピードライブをインストールして、そのイメージファイルのデータにアクセスしますか？
イメージをマウントできない場合でも、cpioを使用して一部のデータを「ストリームアウト」できる場合があります。
画像が次のいずれであるかを確認したら、
- サポートされているファイルシステムとパーティションを使用したイメージ->
mount - サポートされているファイルシステムと複数のパーティションを使用するイメージ->
mount with offset、またはddを使用してオフセットのあるパーティションを抽出し、そのパーティションのみをマウントするか、kpartxのようなものを使用します - サポートされているファイルシステムを使用していない、またはファイルシステムがまったくないイメージ->カーネルのサポートと詳細な調査...
hexdump および strings ユーティリティを使用して、ヘッダーを分析し、画像からテキスト文字列を抽出して、画像ファイルとその構造に関する詳細情報を取得できます。
何かがそうすることに私の興味を引いた：
@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF
画像のすべてのバイナリにこのような行があるので、そこに何があるのか多少はわかります。また、この場合、installpkgを使用して元のプラットフォームでインストールプロセスがどのように行われるかを 詳しく見る すると、次のことがわかります。
ソフトウェアをフロッピーディスクからUNIX System V/386ハードディスクに転送する基本的なメカニズムは、cpioです。
基本的に、データは cpio を使用して/ usr/tmp/installに抽出され、一連のファイルがこれに含まれます（インストール、ASCII、ファイル、名前、サイズファイル）。この場合、次のコマンドが発生します。
cat U19.IMA | cpio -imdv
初めは不正な数エラーを出力しますが、その後、イメージの内容を含む/ usr/binフォルダーを作成します！私が探していたtrはそこにあります：
#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.
最初にcpioを試しても害はありません！