In 2007, I made a backup copy of my original Deus Ex CD that I had owned since 2000 (bundled along with a Sound Blaster Audigy). The backup consists of two files:
deusex_v1003c.iso (824148576 bytes)
deusex_v1003c.toc (50 bytes)
I would have ripped these using a NEC ND-3540A drive, and a then-current version of Ubuntu, probably using either Brasero or k3b.
I am convinced that, despite the file extensions, the first file is not in ISO 9660 format, and the second file is not in cdrdao TOC format.
The 50 bytes of the second file are reproduced in full below:
$ hexdump -C deusex_v1003c.toc
00000000 00 2e 01 01 01 14 00 a0 00 00 00 00 01 20 00 01 |............. ..|
00000010 14 00 a1 00 00 00 00 01 00 00 01 14 00 a2 00 00 |................|
00000020 00 00 4a 32 3e 01 14 00 01 00 00 00 00 00 02 00 |..J2>...........|
00000030 42 52 |BR|
00000032
There seems to be very little usable information here.
The "iso" file does not respond to standard tools:
$ sudo mount deusex_v1003c.iso -o loop -t iso9660 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop12, missing codepage or helper program, or other error.
$ file deusex_v1003c.iso deusex_v1003c.toc
deusex_v1003c.iso: data
deusex_v1003c.toc: data
It does not seem to be in bin/cue format:
$ bchunk deusex_v1003c.iso deusex_v1003c.toc out.iso
binchunker for Unix, version 1.2.2 by Heikki Hannikainen <[email protected]>
Created with the kind help of Bob Marietta <[email protected]>,
partly based on his Pascal (Delphi) implementation.
Support for MODE2/2352 ISO tracks thanks to input from
Godmar Back <[email protected]>, Colas Nahaboo <[email protected]>
and Matthew Green <[email protected]>.
Released under the GNU GPL, version 2 or later (at your option).
Reading the CUE file:
Writing tracks:
(And I tried the above after physically renaming the files to .bin
and .cue
respectively - same result).
Diving into the .iso
file, the first 4096 bytes seem unenlightening:
$ hexdump -n 4096 -C deusex_v1003c.iso
00000000 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 02 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000930 00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40 |.@.....@.......@|
00000940 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 |.......@........|
00000950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 |...............@|
00000960 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000970 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 40 |......@........@|
00000980 40 00 00 40 00 00 40 00 00 40 00 00 00 00 40 00 |@..@..@..@....@.|
00000990 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 01 02 |................|
000009a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000
It's not until offset 0x9910 that we get something more interesting:
00009910 00 00 09 00 00 00 09 00 01 43 44 30 30 31 01 00 |.........CD001..|
00009920 43 44 2d 52 54 4f 53 20 43 44 2d 42 52 49 44 47 |CD-RTOS CD-BRIDG|
00009930 45 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |E |
00009940 44 45 55 53 45 58 5f 56 31 30 30 33 43 20 20 20 |DEUSEX_V1003C |
00009950 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
00009960 00 00 00 00 00 00 00 00 55 21 05 00 00 05 21 55 |........U!....!U|
00009970 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00009990 01 00 00 01 01 00 00 01 00 08 08 00 6c 00 00 00 |............l...|
000099a0 00 00 00 6c 17 00 00 00 00 00 00 00 00 00 00 18 |...l............|
000099b0 00 00 00 00 30 00 1b 00 00 00 00 00 00 1b 00 08 |....0...........|
000099c0 00 00 00 00 08 00 64 08 1c 0b 32 3b 00 02 00 00 |......d...2;....|
000099d0 01 00 00 01 01 00 20 20 20 20 20 20 20 20 20 20 |...... |
000099e0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
*
00009c40 20 20 20 20 20 32 30 30 30 30 38 32 38 31 33 35 | 20000828135|
00009c50 39 35 35 30 30 00 32 30 30 30 30 38 32 38 31 33 |95500.2000082813|
00009c60 35 39 35 35 30 30 00 30 30 30 30 30 30 30 30 30 |595500.000000000|
00009c70 30 30 30 30 30 30 30 00 30 30 30 30 30 30 30 30 |0000000.00000000|
00009c80 30 30 30 30 30 30 30 30 00 01 00 00 00 00 00 00 |00000000........|
00009c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00009d10 00 00 00 00 00 00 00 00 43 44 2d 58 41 30 30 31 |........CD-XA001|
This made me think that somehow the image was in CD-ROM XA format. I downloaded the referenced atari.iso
and observed that the magic string CD001
occurred at offset 0x8000+1 prepended by only zero bytes. I stripped the first 0x9918 bytes off deusex_v1003c.iso
and replaced them with 0x8000 zero bytes (calling the result dx.iso
).
file
now thinks it recognises the format:
$ file dx.iso
dx.iso: ISO 9660 CD-ROM filesystem data 'DEUSEX_V1003C'
However, it still doesn't mount. My final idea was to try running ddrescue
over either the original or the generated .iso
file:
$ ddrescue deusex_v1003c.iso rescue.iso
GNU ddrescue 1.23
Press Ctrl-C to interrupt
ipos: 824115 kB, non-trimmed: 0 B, current rate: 254 MB/s
opos: 824115 kB, non-scraped: 0 B, average rate: 412 MB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 824148 kB, bad areas: 0, run time: 1s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished
Although it claims success, rescue.iso
still does not mount.
I'm now at a loss for what to try next. The data does appear to be there if I keep scrolling through the hexdump (I can see filenames). I realise that at this point it would be easier just to repurchase the game, but I feel it would be a shame to have maintained this file for the last 12 years for it to turn out to be useless.
The need for ISOs to be read and understood was once satisfied by mount
. Now I wonder if we can implement the same functionality with data-mining algorithms.
00 02 00
which means the sector at 00:02:00 (2 seconds) and the following02
means a Mode 2 sector. (Found here.) But I've yet to find a tool (Linux/macOS) to actually read/extract it.