Montage d'un ancien fichier image de disquette (format .ima) - à quel point cela peut-il être difficile?

10

J'essaie d' mountaccéder à un fichier image de disquette au format .ima (vidage brut vers disquette, similaire à .img ) sur ArchLinux.

Ce fichier fait partie d'un ensemble de 30. Il n'est pas amorçable, mais plutôt une continuation d'un ensemble. Le but n'est pas la manipulation pour des raisons d'installation ou de clonage. Je suis intéressé par la documentation contenue avec d'autres données sur le disque.

Informations sur le fichier image

Voici quelques informations sur ce fichier image:

# 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:

Échec du montage

Voici le message d'erreur générique:

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

J'ai essayé de nombreuses combinaisons en essayant de spécifier un type avec -t, c'est-à-dire ntfs, msdos, iso9660, vfat et en obtenant toujours la même erreur. Je pensais que c'était peut-être une sorte de format de fichier ntfs mais ntfs-3G ne fait pas beaucoup mieux donc non ce n'est pas:

# 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)

Quelqu'un a suggéré peut-être un Minix fs. Bien qu'il ne soit pas clair si je peux vraiment monter un tel système de fichiers avec ma configuration actuelle, j'ai essayé:

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.

Il semble que ce ne soit pas concluant, car lorsque vous spécifiez un type spécifique de système de fichiers, vous aurez un type d'erreur spécifique dans le journal. A également essayé [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..

Où je peux voir de telles choses avec dmesg:

[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem

En outre, lsmod | grep loopdonne

loop 18511 0

Il n'y a aucun superbloc alternatif d'aucune sorte:

# 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

Contrairement à de nombreux cas que j'ai lus, il ne semble pas nécessaire de spécifier de décalage ici car il n'y a pas de partition construite dans l'image. Dans de tels cas, la ddcommande est parfois utilisée pour transférer le contenu vers une image similaire en utilisant une valeur de décalage qui permet le montage. Cela semble identique à la spécification mountdirecte d' un décalage par rapport à la commande. Mais cela devrait être facile, comme dans cet autre cas où un simple losetupest utilisé, puis le dispositif de boucle est monté. Je peux lier le fichier .ima avec losetup mais lorsque j'essaie de monter le périphérique de boucle, je me retrouve avec mon message d'erreur initial.

Intégrité des données

Enfin, safecopy --stage1ne signale aucun problème avec les données et la sortie jusqu'à l'étape 3 reste la même et génère la même erreur:

# 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)

Voici le haut du fichier et le contenu semble être intact:

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 |................|

"Forensics"

Puisqu'une image brute se compose d'une copie binaire secteur par secteur du support source, le format réel du contenu du fichier dépendra du système de fichiers du disque à partir duquel l'image a été créée (comme une version de FAT). [...] Étant donné que les fichiers IMG ne contiennent aucune donnée supplémentaire au-delà du contenu du disque, ces fichiers ne peuvent être gérés que par des programmes capables de détecter leurs systèmes de fichiers.

Suite aux suggestions, j'ai procédé à l'analyse de certains des autres fichiers image de l'ensemble (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

Désolé mais cela ressemble à une table de partition mais c'est inhabituel. Il comprend la propriété 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)

Donc, en essayant de monter l'image que j'obtiens:

# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv'  <-----

Comme quelqu'un l'a laissé entendre, vous devez avoir quelque chose de spécifique comme ' System V and Coherent filesystem support ' compilé dans le noyau afin d'utiliser quelque chose comme mount -t sysv. La chaîne sysv n'est pas si surprenante, car elle fait partie du support d'installation d'AT & T UNIX System V / 386 Release 4 Version 2.1 - un port qui a été pris en charge par Sun jusqu'en 2006 - et ces images ont fini dans la nature en 2007. En fait, un texte Le fichier fourni avec les images indique qu'elles sont requises pour l'installation en raison de la nature du secteur de démarrage et du format utilisé. Il indique que le matériel était à l' origine Teledisk (TD0) Format. Je tiens à souligner ici qu'il ne s'agit pas d'un matériau original. Dans tous les cas, je ne peux pas réellement calculer les décalages comme expliqué dans la question - soit je ne me retrouve pas avec des entiers lors de la division par 512, et même si j'essaie, il semble que je ne trouve pas le bon décalage - dd: cannot skip to specified offset, 0 writesetc. à ce stade, la réponse concerne la criminalistique et non plus un fichier image.

Émulation rapide du système d'exploitation de source d'image historique avec qemu

AT&T UNIX System V version 4 version 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

Comme cela a été suggéré, j'ai installé à partir d'une image précédente dans l'ensemble. Cela implique d'utiliser qemu comme expliqué ici en commençant essentiellement par l'image 14 (d'abord losetup /dev/loop0 U14.IMAun simple qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a), car U19 n'est pas amorçable. Ce qui est bien ici, c'est que vous n'avez pas besoin de monter / démonter des images dans le système d'exploitation lui-même, vous utilisez simplement ctrl-alt-2ou 1 avec qemu pour accéder ou quitter le moniteur et vous utilisez list blockspour voir ce qui est monté et change floppy0 imagenamedans cette interface pour changer l'image par exemple lors de l'installation.

J'ai dû fournir U19.IMA (disque 5) pendant l'installation (pour un journal textuel de l'installation, voir ceci - un point culminant est la référence à MS-DOS!), Et je me suis retrouvé avec cela, c'est-à-dire un AT&T UNIX Sys correctement installé V 386 OS, donc cela confirme à peu près U19.IMA est une image disque fonctionnelle:

entrez la description de l'image ici

Par défaut, / dev / fd est monté sur / dev / fd et il existe également un accès par disquette via un périphérique bloc (/ dev / dsk / f0) et brut (/ dev / dsk / f0). Changer de répertoire sur la disquette ne montre que les fichiers numérotés de 1 à 23 (c'est juste la structure du périphérique de caractères, je suppose). Vous pouvez également catles périphériques bruts et bloqués et voir les données de la disquette, mais c'est aussi proche que possible.

J'ai remarqué que dans ce système d'exploitation, vous n'installez pas de trucs à partir de disquettes en lançant un script à partir d'un répertoire sur eux comme vous le faites avec des fichiers binaires décompressés par exemple - ici vous utilisez pkgadd -d diskette1(ce dernier mot est sûrement un alias, mais je trouvé une référence au commutateur -d dans les trucs SCO pour pkgadd (1M)et généralement il apparaît souvent dans Unix commercial (Oracle, HP share pkgadd (1M)). L'exécution de la commande lance une routine dans laquelle vous fournissez des disquettes et vous n'avez aucun contrôle, sauf en disant «non» après que la routine a découvert le contenu du lecteur. Dans le cas des disques qui commencent une séquence d'installation (U03, U05, etc.), cela va installer puis demander la disquette suivante, etc. jusqu'à ce que l'installation du package soit terminée. Si vous mettez une disquette qui n'est pas le début d'un ensemble, elle ne trouve pratiquement rien mais vous indique peut-être que vous devez utiliser la installpkgcommande à la place.

Vais-je installer un lecteur de disquette physique sur ma plate-forme pour accéder aux données de ce fichier image?


la source
Juste une supposition: il pourrait s'agir d'un système de fichiers Minix. Vous devrez probablement recompiler votre noyau pour le prendre en charge. L'installation d'un lecteur de disquette physique n'aide pas. Quelle est la taille du fichier image? Si votre fichier n'est qu'une image brute, il ne contient certainement aucun des systèmes de fichiers (actuels / modernes) que vous avez essayés. Il semble qu'il ne soit pas amorçable sur les systèmes i386.
jofel
@jofel Le fichier fait 1475 Ko. Si j'essaye de le monter comme ça mount -t minix -o loop U19.IMA /mnt/cdet que j'obtiens l'erreur générique mais cela atterrit dans dmesg VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.Est-ce une indication que le noyau l'a déjà ou je ne peux pas compter dessus?. Quoi qu'il en soit, je vais enquêter sur ce que vous avez dit. Je sais que ce n'est pas amorçable, je veux cependant accéder au contenu. Merci.
La sortie de filesuggère qu'il n'y a pas de système de fichiers sur l'image. Êtes-vous sûr que vos données sont réellement là? On dirait que vous essayez de monter une image d'un lecteur brut sans partitions ni système de fichiers.
terdon
@terdon C'est exactement ce que je veux faire. Est-ce un échec logique? Il s'agit d'un ensemble d'installation. J'espérais trouver des "fichiers", y compris de la documentation. Puis-je ne pas y accéder en dehors de l'installation du tout?
2
S'il s'agit d'un disque d'installation, il se peut que seul le premier disque contienne un système de fichiers / soit amorçable. Les autres disques ne pouvaient contenir que des données dans un format personnalisé sans surcharge de système de fichiers.
jofel

Réponses:

4

Si vous ne pouvez pas monter l'image, vous pourrez peut-être dans certains cas "diffuser" certaines de ses données cpio.

Une fois que vous avez vérifié si l'image est:

  • Une image utilisant un système de fichiers pris en charge et une partition -> mount
  • Une image utilisant un système de fichiers pris en charge et plusieurs partitions -> mount with offset, ou utiliser ddpour extraire une partition avec décalage puis monter cette partition uniquement ou utiliser quelque chose commekpartx
  • Une image n'utilisant pas de système de fichiers pris en charge ou sans aucun système de fichiers -> Prise en charge du noyau et recherche plus approfondie ...

Vous pouvez utiliser les utilitaires hexdumpet stringspour essayer d'analyser l'en-tête et d'extraire des chaînes de texte de l'image et obtenir plus d'informations sur le fichier image et sa structure.


Quelque chose a capté mon intérêt à le faire:

@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF

Il y a une ligne comme celle-ci pour chaque binaire dans l'image, donc vous savez un peu ce qu'il y a dedans. De plus, dans ce cas, lorsque vous examinez de plus près comment se déroule le processus d'installation sur la plate-forme d'origine installpkg, vous découvrez que:

Le mécanisme de base pour transférer des logiciels d'une disquette vers le disque dur UNIX System V / 386 est cpio.

Fondamentalement, les données sont extraites avec cpio/ usr / tmp / install et une série de fichiers sont inclus avec cela (un fichier d'installation, ascii, fichier, nom et taille). Il arrive donc ici que cette commande:

cat U19.IMA | cpio -imdv

génère des erreurs de nombre malformées pour commencer, mais crée ensuite un dossier / usr / bin avec le contenu de l'image! Le que trje cherchais est là:

#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.

Essayer cpioen premier lieu ne peut pas faire de mal!


la source
Soyez juste prudent avec l'option -d et cpio. Il me semble que cela a essayé d'extraire directement sur mon lecteur racine!