113
Contents |
Distributions
Iomega released several versions of a 1-Step backup Program. This program ran on Win9x operating systems, ie Win95, Win98, and WinME. The signatures mentioned below assume an Intel Chip-set and little-endian numeric format. Its probable there were Macintosh versions for the Motorola 68000 Chip-set If Mac versions exist, the signature bytes are probably swapped.
There are known to be two downloadable versions of this software package available for installation on Win9x systems:
w32_iom221a_en.exe version 4.1 distribution date 08/27/2001 iobackup-w32-x86-44.exe version 4.4 distribution date 02/29/2000 The distribution dates above are from the time stamps on the files and the version numbers are from the enclosed readme.txt files. You figure it out.
You should be able to find these with an internet search for the installer file name. Version 4.1 is also know to be available on some of the IomegaWare distribution CDs.
The installers above created dtiom98.exe which is the backup and restore program and dtsc.exe allows file selection and controlling whether the backup will be compressed.
Backup File Identification
The backup program would only run if a Iomega disk was connected to the system and then the backup was written to one or more 'Image.113' files on the removable media. Only one such file was allowed on each media disk. If more than one disk was required additional 'Image.113' files were created on additional disks in the set. These were normal files and could be copied or renamed later. Each backup file starts with a header similar to the dump of a sample below:
00000: 55 AA 55 AA FF 00 02 00 00 00 DB 00 00 00 AE B0 |U.U............. 00010: 03 5E AE B0 03 5E 00 00 95 06 02 00 00 00 42 61 |.^...^........Ba 00020: 63 6B 75 70 20 4A 6F 62 20 32 2C 20 44 69 73 6B |ckup Job 2, Disk 00030: 20 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | 1 00040: 20 20 20 20 20 20 20 20 20 20 EB BA 05 5E 00 00 | ...^.. 00050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 00060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 00070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 00080: 00 00 00 00 00 00 00 00 00 00 AE B0 03 5E 01 00 |.............^.. 00090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
all begin with the 4 bytes signature shown at offset 0. a descriptive string begins at offset 0x1E Job # reflects the backup number on the host machine. Disk # refects the disk # in this backup series. There appears to be no information on the number of disks in the set in the header. The 4 byte long beginning at offset 0xA is the next available block in the file. Most of the other 4 byte longs in the header starting at offsets 0xE,0x12,0x4A,0x8A appear to be similar time stamps with unknown significance.
File Format
These files appear to use an internal block size of 0x7400 bytes. The next available block above = (file size)/0x7400 The file data region begins after block 3, offset 0x15C00.
If the file contains compressed data the 1st 8 bytes will all be zeros. The 1st 8 bytes in each block of a compressed file appear to be the initial offset in an output file at which to begin decompression and the next 4 byte long is the number of data bytes to decompress <= 0x7400. For each sequential block in a backup file the 8 byte long increases. This is sufficient to identify a compressed backup. Unfortunately the file compression method has not been identified so at this time the data cannot be extracted from these files without using the original software.
If the file contains uncompressed data the 3rd block at offset 0x15C00 will begin with the 4 signature bytes shown in the sample dump below.
15c00: CC 33 CC 33 86 00 A8 00 00 00 00 00 00 00 04 00 |.3.3............ 15c10: 0A 00 49 07 00 00 00 00 00 00 00 00 00 00 00 00 |..I............. 15c20: 00 0A 00 00 00 00 00 00 00 00 00 1C 00 10 00 00 |................ 15c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 15c40: 00 00 00 00 00 00 00 00 00 04 00 63 00 3A 00 02 |...........c.:.. 15c50: 00 00 00 00 00 00 00 00 00 09 00 00 00 00 00 00 |................ 15c60: 00 00 00 00 04 00 63 00 3A 00 00 00 00 00 00 00 |......c.:....... 15c70: 00 00 00 00 10 00 4F 49 4D 47 03 00 00 00 00 00 |......OIMG...... 15c80: 00 00 00 00 00 00 04 00 63 00 3A 00 0A 00 00 00 |........c.:..... 15c90: 99 66 99 66 07 00 99 66 99 66 0A 00 99 66 99 66 |.f.f...f.f...f.f 15ca0: 02 00 99 66 99 66 00 00 CC 33 CC 33 C2 00 A6 01 |...f.f...3.3....
The signature hex byte sequence CC 33 CC 33 indicates the beginning of a data header region. The signature hex byte sequence 99 66 99 66 occurs at the beginning and end of the file data region. Each file header contains the file properties including the file name and path (if it exists) as variable length unicode strings. At offset 0x15C14 in the dump above is a 8 byte number representing the file length. Its 0 as this is a drive specification for 'c:' which occurs 3 times in the header as unicode strings. All headers contain the 'OIMG' bytes shown above. If the file length were greater than zero the file data would be present between the two file data signatures 99 66 99 66. At offset 0x15CA8 above is another header region signature CC 33 CC 33 where the next file header begins. This is more than enough to identify an uncompressed data file.
links
The following links are to a reverse engineering project where C source code was created to validate the information above and create a program that can list or extract files from an uncompressed backup. Unfortunately as mentioned above the compression method used in the compressed backups has not yet been identified so file extraction from compressed archives is currently not available.
113-format provides more detail on the internal file format rd113-info provides some help and examples on program useage rd113.lzh contains WinNT console applications that run under Win32 rd113-src.tar.gz contains the source code to build the console programs for Linux, DOS, or Win32
unfortunately the system won't let me save the page with these links displayed what a pain