Saya mencoba mount
dan mengakses file gambar floppy dalam format .ima (dump mentah ke floppy, mirip dengan .img ) di ArchLinux.
File ini adalah bagian dari set 30. File ini tidak dapat di-boot, tetapi merupakan kelanjutan dari set. Tujuannya bukan manipulasi demi instalasi atau kloning. Saya tertarik pada dokumentasi yang berisi data lain pada disk.
Informasi file gambar
Berikut ini beberapa info tentang file gambar ini:
# 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:
Gunung gagal
Inilah pesan kesalahan umum:
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
Saya sudah mencoba banyak kombinasi mencoba menentukan jenis dengan -t yaitu ntfs, msdos, iso9660, vfat, dan selalu mendapatkan kesalahan yang sama. Saya pikir itu mungkin semacam format file ntfs tetapi ntfs-3G tidak melakukan jauh lebih baik sehingga tidak itu tidak:
# 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)
Seseorang menyarankan mungkin Minix fs. Walaupun tidak jelas apakah saya benar-benar dapat me-mount filesystem tersebut dengan konfigurasi saya saat ini, saya mencoba:
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.
Tampaknya ini tidak konklusif, karena ketika Anda menentukan jenis sistem file tertentu, Anda akan memiliki jenis kesalahan tertentu dalam log. Juga mencoba [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..
Di mana saya bisa melihat hal-hal seperti itu dengan dmesg
:
[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem
Juga, lsmod | grep loop
berikan
loop 18511 0
Tidak ada superblock alternatif dalam bentuk apa pun:
# 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
Berlawanan dengan banyak kasus yang saya baca, sepertinya tidak perlu menentukan offset apa pun di sini karena tidak ada partisi yang dibangun pada gambar. Dalam kasus seperti itu, kadang-kadang dd
perintah digunakan untuk mentransfer konten ke gambar yang serupa menggunakan nilai offset yang memungkinkan pemasangan. Ini tampaknya sama dengan menentukan offset ke mount
perintah secara langsung. Tapi ini harus mudah, seperti di ini kasus lain di mana yang sederhana losetup
digunakan dan kemudian perangkat loop dipasang. Saya dapat menautkan file .ima dengan losetup tetapi ketika saya mencoba memasang perangkat loop saya berakhir dengan pesan kesalahan awal saya.
Integritas data
Akhirnya, safecopy --stage1
tidak melaporkan masalah apa pun dengan data dan output hingga tahap 3 tetap sama dan menghasilkan kesalahan yang sama:
# 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)
Inilah bagian atas file dan kontennya tampaknya utuh:
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 |................|
"Forensik"
Karena gambar mentah terdiri dari salinan biner sektor per sektor dari media sumber, format sebenarnya dari isi file akan tergantung pada sistem file dari disk dari mana gambar itu dibuat (seperti versi FAT). [...] Karena file IMG tidak menyimpan data tambahan di luar isi disk, file ini hanya dapat ditangani oleh program yang dapat mendeteksi sistem file mereka.
Berikut saran, saya melanjutkan untuk menganalisis beberapa file gambar lain di 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
Maaf, tetapi memang terlihat seperti tabel partisi tapi itu tidak biasa. Ini termasuk properti 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)
Jadi mencoba me-mount gambar yang saya dapatkan:
# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv' <-----
Seperti yang diindikasikan oleh seseorang, Anda perlu memiliki sesuatu yang spesifik seperti ' System V dan dukungan sistem file yang koheren ' dikompilasi di kernel untuk menggunakan sesuatu seperti mount -t sysv
. String sysv tidak begitu mengejutkan, karena ini adalah bagian dari AT&T UNIX System V / 386 Release 4 Versi 2.1 instal media - port yang didukung oleh Sun hingga 2006 - dan gambar-gambar ini berakhir di alam liar pada tahun 2007. Sebenarnya sebuah teks file yang dibundel dengan gambar menunjukkan bahwa mereka diperlukan untuk instalasi karena sifat dari sektor boot dan format yang digunakan. Ada indikasi bahwa materi awalnya di Teledisk (TD0) Format. Saya ingin menekankan di sini bahwa ini bukan bahan asli. Bagaimanapun saya tidak dapat benar-benar menghitung offset seperti dijelaskan dalam pertanyaan - baik saya tidak berakhir dengan bilangan bulat ketika membagi dengan 512, dan bahkan jika saya coba sepertinya saya tidak dapat menemukan offset yang tepat - dd: cannot skip to specified offset, 0 writes
dll. Jadi pada titik ini jawabannya adalah tentang forensik, dan tidak lagi tentang file gambar.
Sumber emulasi OS sumber historis cepat dengan qemu
AT&T UNIX System V Rilis 4 Versi 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
Seperti yang disarankan, saya menginstal dari gambar sebelumnya di set. Ini melibatkan penggunaan qemu
seperti yang dijelaskan di sini pada dasarnya dimulai dengan gambar 14 (pertama losetup /dev/loop0 U14.IMA
kemudian yang sederhana qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a
), karena U19 tidak dapat di-boot. Yang menyenangkan di sini adalah Anda tidak perlu me-mount / umount gambar di OS itu sendiri, Anda hanya menggunakan ctrl-alt-2
atau 1 dengan qemu untuk mengakses atau meninggalkan monitor dan Anda menggunakan list blocks
untuk melihat apa yang sudah terpasang dan change floppy0 imagename
di antarmuka itu untuk mengubah gambar file yaitu saat menginstal misalnya.
Saya harus menyediakan U19.IMA (disk 5) selama instalasi (untuk log teks instalasi, lihat ini - sorotan adalah referensi ke MS-DOS!), Dan saya berakhir dengan ini yaitu AT&T UNIX Sys yang diinstal dengan benar V 386 OS, jadi ini cukup banyak menegaskan U19.IMA adalah image disk yang berfungsi:
Secara default / dev / fd dipasang pada / dev / fd dan ada juga akses floppy melalui perangkat blok (/ dev / dsk / f0) dan mentah (/ dev / dsk / f0). Mengubah direktori ke floppy hanya memperlihatkan file-file bernomor 1 hingga 23 (ini hanya struktur perangkat karakter yang saya kira). Anda juga dapat cat
menggunakan perangkat mentah dan blok dan melihat data floppy ada di sana, tetapi itu sedekat mungkin.
Saya perhatikan bahwa di OS itu, Anda tidak menginstal hal-hal dari disket dengan meluncurkan beberapa skrip dari direktori pada mereka seperti yang Anda lakukan dengan file biner terkompresi misalnya - di sini Anda menggunakan pkgadd -d diskette1
(tentunya kata terakhir itu adalah beberapa alias, tapi saya menemukan referensi ke -d switch di SCO stuff for pkgadd (1M)dan umumnya muncul sering di Unix komersial (Oracle, HP share pkgadd (1M)). Mengeluarkan perintah meluncurkan rutin di mana Anda memasok disket dan Anda tidak memiliki kontrol, kecuali mengatakan "tidak" setelah rutin mengetahui apa yang ada di drive. Dalam kasus disk yang memulai urutan instalasi (U03, U05 dll), ini akan menginstal kemudian meminta disket berikutnya dll sampai paket instalasi selesai. Jika Anda meletakkan floppy yang bukan awal dari set, pada dasarnya tidak menemukan apa pun selain memberitahu Anda mungkin Anda harus menggunakan installpkg
perintah.
Apakah saya akan menginstal floppy drive fisik ke rig saya untuk mengakses data dalam file gambar itu?
mount -t minix -o loop U19.IMA /mnt/cd
dan saya mendapatkan kesalahan generik tetapi ini mendarat di dmesgVFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.
Apakah ada indikasi kernel sudah memilikinya atau saya tidak dapat mengandalkan itu ?. Bagaimanapun, saya akan menyelidiki apa yang Anda katakan. Saya tahu ini tidak bisa di-boot, saya ingin mengakses isinya. Terima kasih.file
menyarankan tidak ada sistem file pada gambar. Apakah Anda yakin data Anda benar-benar ada? Kedengarannya seperti Anda mencoba memasang gambar drive mentah tanpa partisi dan tanpa sistem file.Jawaban:
Jika Anda tidak dapat memasang gambar, Anda mungkin masih bisa "mengalirkan" beberapa datanya
cpio
.Setelah Anda memastikan apakah gambarnya adalah:
mount
mount with offset
, atau gunakandd
untuk mengekstrak partisi dengan offset lalu pasang partisi itu saja atau gunakan sesuatu sepertikpartx
Anda dapat menggunakan
hexdump
danstrings
utilitas untuk mencoba menganalisis header dan untuk mengekstrak string teks dari gambar dan mendapatkan informasi lebih lanjut tentang file gambar dan strukturnya.Sesuatu menarik minat saya untuk melakukannya:
Ada garis seperti ini untuk setiap biner tunggal dalam gambar sehingga Anda agak tahu apa yang ada di sana. Juga, dalam hal ini, ketika Anda melihat lebih dekat bagaimana proses instalasi terjadi pada platform asli
installpkg
, Anda mengetahui bahwa:Pada dasarnya, data diekstraksi dengan
cpio
ke / usr / tmp / install dan serangkaian file disertakan dengan ini (file instalasi, ascii, file, nama dan ukuran). Kebetulan di sini bahwa perintah ini:output kesalahan nomor salah untuk memulai, tetapi kemudian membuat folder / usr / bin dengan isi gambar! Yang
tr
saya cari ada di sana:Mencoba
cpio
di tempat pertama tidak ada salahnya!sumber
cpio
. Sepertinya saya ingat ini mencoba mengekstrak langsung ke drive root saya!