掛載舊的磁片映像文件(.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
與我讀到的許多情況相反,似乎不需要在此處指定任何偏移量,因為映像中沒有內置分區。在這種情況下,有時該
dd
命令用於使用允許安裝的偏移值將內容傳輸到類似圖像。這似乎與mount
直接指定命令的偏移量相同。但這應該很容易,就像在其他情況下使用簡單losetup
然後安裝循環設備一樣。我可以將 .ima 文件與 losttup 連結,但是當我嘗試掛載循環設備時,我最終會收到最初的錯誤消息。數據的完整性
最後,
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 |................|
“取證”
由於原始映像由源介質的逐個扇區二進制副本組成,因此文件內容的實際格式將取決於創建映像的磁碟的文件系統(例如 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 90 屬性:
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 ’ ,才能使用. sysv 字元串並不令人驚訝,因為它是 AT&T UNIX System V/386 Release 4 Version 2.1 安裝介質的一部分——Sun直到 2006年才支持該埠——而這些圖像在 2007 年被廣泛使用。實際上是一個文本與映像捆綁在一起的文件表明,由於引導扇區的性質和使用的格式,安裝需要它們。有跡象表明該材料最初是Teledisk (TD0)格式
mount -t sysv
. 我想在這裡強調,這不是原始材料。在任何情況下,我實際上都無法像問題中解釋的那樣計算偏移量 - 要麼我在除以 512 時不會得到整數,即使我嘗試似乎也找不到合適的偏移量 -dd: cannot skip to specified offset, 0 writes
等等。所以在這一點上,答案是關於取證,而不是關於圖像文件。使用 qemu 快速歷史圖像源作業系統仿真
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
正如建議的那樣,我從集合中的先前圖像安裝。它涉及使用
qemu
這裡解釋的基本上從圖像 14 開始(首先losetup /dev/loop0 U14.IMA
是簡單的qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a
),因為 U19 不可啟動。這裡的好處是您不必在作業系統本身中掛載/解除安裝映像,您只需使用ctrl-alt-2
or 1 和 qemu 即可訪問或離開監視器,您可以使用list blocks
查看已安裝的內容並change floppy0 imagename
在該界面中更改映像文件,例如在安裝期間。我必須在安裝過程中提供 U19.IMA(磁碟 5)(有關安裝的文本日誌,請參閱這個- 一個亮點是對 MS-DOS 的引用!),我最終得到了這個,即正確安裝的 AT&T UNIX Sys V 386 OS,所以這幾乎證實了 U19.IMA 是一個工作磁碟映像:
預設情況下 /dev/fd 安裝在 /dev/fd 上,並且還可以通過塊 (/dev/dsk/f0) 和原始 (/dev/dsk/f0) 設備進行磁片訪問。將目錄更改為磁片僅顯示編號為 1 到 23 的文件(這只是我猜的字元設備的結構)。您還可以
cat
查看原始設備和塊設備並查看磁片數據,但這是盡可能接近的。我注意到,在那個作業系統中,您不會像使用解壓縮的二進製文件那樣從磁片上的目錄啟動一些腳本來從磁片上安裝東西 - 在這裡您使用
pkgadd -d diskette1
(當然最後一個詞是一些別名,但我在pkgadd(1M)的 SCO 資料中找到了對 -d 開關的引用通常它經常出現在商業 Unix 中(Oracle、HP 共享 pkgadd(1M) )。發出命令會啟動一個常式,在該常式中您提供磁片並且您無法控制,除了在常式發現驅動器中的內容後說“不”。對於開始安裝順序的磁碟(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
不會有傷害!