2

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.

1
  • I'm having the same issue with a lonely ISO file of some VideoCD I've backed up years ago. I've found out that the file has the raw sectors in it. The first 12 Bytes are the sync field followed by 00 02 00 which means the sector at 00:02:00 (2 seconds) and the following 02 means a Mode 2 sector. (Found here.) But I've yet to find a tool (Linux/macOS) to actually read/extract it.
    – mbirth
    Aug 1, 2023 at 20:50

1 Answer 1

0

I can't help with identifying the format without knowing the name of the utility that created it. It is also not sure that, if restored, it would still be playable on a modern computer.

But if the idea is to play the game, I can help with that.

At the moment, the game "Deus Ex: Game of the Year Edition" is on promotion on Steam for about 1$ (offer ends in two days).

1
  • Yeah, that's tough to pass up - only 69p here in the UK. Bought. Still want to find out what that ISO file is though! :)
    – jl6
    Nov 10, 2019 at 17:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .