Iomega 113 Backup File FormatInitial post 02/11/17 This information was last updated 3/10/18
Latest news: I did the original work below a year ago by inspection of some sample backup files as described below. I worked out most of the uncompressed format, at least enough to extract files from the backups. However the few people who were interested in this tended to have compressed backups and I was not able to figure out the compression method used in these *.113 backup files. I originally got interested in this project due to an email from 'Arron' email : private@redweather.net. He got in touch again this spring and told me he had determined the compression method and had new information about the overall file format. After telling me the solution I felt really stupid. Sigh. It turns out the key documents are: I should have noticed this as I worked with this Quarter Inch Tape format during my MSbackup review in 2010. I now have a Beta release of a decompression engine that runs as a 32 bit Windows NT console application on most current windows systems. File extraction from compressed backups is a 2 step process, first decompress the original file with the new vtbl.exe program. This will produce a new uncompressed file, 'dcomp.out'. The 2nd step is to run the existing rd113.exe extraction program on this new uncompressed file. The current release is on my downloads page as vtbl.zip. If you have an old backup like this, give it a try. It works with my smaller sample files but has not been rigorously tested with large backups. My original documentation follow For an overview, see the introductory comments in the 1-Step Backup summary page. This page describes the physical file format I have worked out by inspection for Iomega 1-Step Backup version 4.1 files (version 4.4 is believed to be the same). The work was performed on a WinME system running on a Intel 386 chip set. The Iomega distribution w32_iom221a_en.exe which created the following directory on the system 'C:\Program Files\Iomega'. Below this it installed the a number of programs and subdirectories including main backup program, dtiom98.exe and 'C:\Program Files\Iomega\Iomega Backup' which it populates with the executables and what appear to be database files that control which files are included in a particular backup job. The majority of this file discusses the format of the Image.113 backup files created on the selected Iomega Drive attached to the system, but at the end I have a short discussion of the format of the *.dbf database files which appear to control the contents of the backup. The formats described below are my best guess at the file layout and are derived solely by reverse engineering a number of sample files created on the system above. This description may contain errors and is known to contain omissions. I obtained enough information that I can parse an uncompressed Image.113 backup file and extract the files it contains onto the system hard disk. At this time the compression method has not been identified so listing or extraction from compressed files is not yet possible. C source code for a program to automate this process is available in rd113-src.tar.gz. This program was used to validate the information presented here. A short description of the rd113 program is also provided. Iomega *.113 file formatThe sample files I have examined where created on an Intel 386 based system. So the numeric data is arranged in Intel byte order, ie little-endian format. So when a I display the value of a hex integer in the discussion below the byte order will be reversed from that shown in a dump of the region that contains the data. Its possible there were *.113 files out there that were created on Macintosh machines which I believe used a Motorola chipset and stored data in big-endian format. One can only hope that byte swapping was done on these files so they are compatible, but I have no data to support this.These backup files appear to be arranged in blocks of 0x7400 bytes. They start which a header and a dump from one of my sample files is shown 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 |................The four byte signature at offset 0 occurs in all files as does the descriptive machine generated string starting at offset 0x1E. The system increments the Job # each time a backup is created. In my sample files, which almost all fit on a single zip drive, the disk # is '1'. I created two sample backups which required two zip disks. I see no significant difference in the dump of the 2nd disk's header except for the disk # in the descriptive string. I wish I could see a byte that reflected the total number of disks in the backup set or the compression method, but do not see this data in the header.
The only other field in this header that has been identified is what appears
to be a 4 byte unsigned long starting at offset 0xa. This is the number of the next
available 0x7400 byte data block in the file. IE let numb be the value of the long
at 0xa, then offset to the next block = 0x7400 *numb. In an uncompressed file with a
catalog the offset to the beginning catalog region has ben 0x7400 * (numb -1).
To date all sample uncompressed files contain a catalog. This catalog lists all
entries which have been proceeds so far. IE in a muti media disk image the
catalog of disk #n contains all records on preceding disk as well as the
records on this disk. In larger files the catalog may start in an earlier block
of its large enough to span multiple blocks (have yet to see an example of this).
If the catalog doesn't start with the id=0x00A80086 try searching backwards
by another block (see below). file backup file timestamp header value output from ctime() ImageD.113 01/14/17/ 01:18 0x5E11DEA1 01/05/2020 08:03:29 ImageE.113 01/21/98 12:34 PM 0x381B0EDC 10/30/1999 11:29:32I don't really care about this as the file and directory time stamps in the structures described below are time_t values, but since there are 4 of these in each header I thought I should mention them.
The files data region starts at offset 0x15c00, ie the 4th 0x7400 block in
the file. All samples I have seen to date for the disk 1 of a backup have zeros
between the end of the file header and the start of the data region. A modest
waste of space to the casual observer. I've only created one uncompressed backup
which spans 2 media disks. In this the dumps below show these short data
segment at the beginning of each block: at the beginning of the 2nd block in the file: 07400: 55 AA 55 AA FF 00 02 00 00 00 F4 0C 00 00 25 39 |U.U...........%9 07410: 20 5E 25 39 20 5E 00 00 7A 06 02 00 00 00 20 20 | ^%9 ^..z..... 07420: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | 07430: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | 07440: 20 20 20 20 20 20 20 20 20 20 25 39 20 5E 00 00 | %9 ^.. 07450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 07460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 07470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ 07480: 00 00 00 00 00 00 00 00 00 00 25 39 20 5E 01 00 |..........%9 ^.. 07490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................ at the beginning of the 3rd block in the file: 0e800: 56 54 42 4C 6E 00 00 00 4F 6E 65 53 74 65 70 20 |VTBLn...OneStep 0e810: 2D 20 31 2F 32 35 2F 32 30 31 37 20 2D 20 31 30 |- 1/25/2017 - 10 0e820: 3A 33 35 20 41 4D 20 20 20 20 20 20 20 20 20 20 |:35 AM 0e830: 20 20 20 20 DD 38 20 5E 22 02 71 00 00 00 00 00 | .8 ^".q..... 0e840: 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 |................ 0e850: 71 00 00 00 00 00 00 00 00 00 00 00 FE 5A 00 00 |q............Z.. 0e860: 0A C2 31 00 00 00 00 00 00 00 00 00 00 00 00 00 |..1............. 0e870: 00 00 00 00 00 00 00 00 00 00 03 00 00 07 00 00 |................ 0e880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................too soon to speculate what these might indicate other than a multi disk backup without more sample data. The remainder of the blocks contained zeros.
If the file is compressed it begins with 8 bytes = 0, if it is not
compressed it begins with the signature unsigned long 0x33CC33CC. Sample
dumps of the start of this region for a compressed and uncompressed file below: compressed backup 15c00: 00 00 00 00 00 00 00 00 F0 73 66 0C F0 42 18 00 |.........sf..B.. uncompressed backup 15c00: CC 33 CC 33 86 00 A8 00 00 00 00 00 00 00 04 00 |.3.3............This is the first clue as to whether the file contains compressed or uncompressed data. In the sample data seen to date, the file data region extends to offset 0x15c00 to (numb-1) *0x7400 where numb is the block count from the file header and the beginning of the catalog region in an uncompressed file. The signature byte above, 0x33CC33CC, occurs at the beginning of each file, drive, or sub directory region in an uncompressed file as described below. One can search the directory region for this signature and will find one such signature for each of the headers which proceed these definitions. No such signatures are found in the data region of a compressed file which is another more cumbersome way to identify the file type. Wish I knew a better way!
It appears that the compressed file's data region is a compressed image of the
uncompressed data region. The limited information I have on this is presented later,
but until the compression method is known this is just speculation.
Uncompressed file formatIf the file contains a catalog, it will be found at the offset (numb -1) * 0x7400 where numb is obtained from the file header as described above. Its a little easier to describe the data in the files region header after describing the headers in the catalog as the catalog headers are a subset of the file region headers. This description is self contained, but it maps to 'struct dir_head' and 'struct cat_head' in the source file rd113.c.Below is a dump of the first header in the catalog region from one of the sample backups, the offsets shown are relative to the start of the header: 000: 86 00 A8 00 00 00 00 00 00 00 04 00 0A 00 41 07 |..............A.
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 0A 00 00 |................
020: 00 00 00 00 00 00 00 1C 00 10 00 00 00 00 00 00 |................
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
040: 00 00 00 00 00 04 00 64 00 3A 00 02 00 00 00 00 |.......d.:......
050: 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 00 |................
060: 04 00 64 00 3A 00 00 00 00 00 00 00 00 00 00 00 |..d.:...........
070: 10 00 4F 49 4D 47 03 00 00 00 00 00 00 00 00 00 |..OIMG..........
080: 00 00 04 00 64 00 3A 00 |....d.:.
This is a variable length structure as it contains 3 unicode strings.
A unicode string starts with a 2 byte word for the # of bytes in string
Its followed by the string bytes, in ascii these are repeats of {%c,0}
ie the ascii char value and a Nul byte.
In this dump the ascii for the unicode strings is "d:"
in all sample files so far all 3 unicode strings have been identical.
Both the catalog and file data region begin by listing the disk drives contained in
the backup, there will be one or more that begin with the id signature 0xA8086. I
have not figured out what these bytes mean, but apparently only the drives have
this id. Hence one can determine the number of drives in the archive by counting the
occurences of this id at the beginning of the catalog or files regions.
listed below are the identified hex offsets in dump above: The first 0x45 bytes have fixed offsets before the 1st unicode string If you look at the source code this is unsigned char unknw1[] 000: a 4 byte id, always as show above for one of the drives in the archive. 00A: byte path length in sample files = 4 for a drive spec, > 4 if a subdir 00E: byte path flag, see bitmap below 011: file length, probably a 64 bit int but works as 4 byte long in sampe files 029: byte file attribute 02D: 4 byte time_t (1st of 4) 035: 4 byte time_t (2nd of 4) 03D 4 byte time_t (3rd of 4) 045: start first variable length name string, two byte length +2 * lens bytes data the following offsets shown relative to after the last string byte at 0x4b above 015: start of 2nd variable length name string the following offsets shown relative to after the last string byte at 0x66 above 00c: id string always "IOMG" 01c: start of 3rd variable length name stringAs shown in this and the following dump, all the variable length name strings have been identical for all three fields in the record, in the example above "d:" is the ascii version of the string. In the dump below the ascii version of the string is "lancia.txt". The four time_t fields have also been identical for each record encountered in the sample data.
The path flag at offset 0xE from the start of this structure is a bitmapped byte
as is the file attribute byte. The following bit definitions seem to work
for the path flag: 0 contine processing
1 a new entry, typically a drive or subdir
8 last entry at this nesting level
0x20 indicates end of data after this record
0x40 this record contains a drive specification
Below is a dump of the files region header from part way through the catalog in one of the sample backups, the offsets shown are relative to the start of the header: 000: CC 33 CC 33 B6 00 97 0A 00 00 00 00 00 00 24 00 |.3.3..........$. 010: 0A 00 08 07 00 9F 09 00 00 00 00 00 00 00 00 00 |................ 020: 00 0A 00 00 00 00 00 00 00 00 00 1C 00 00 00 00 |................ 030: 00 60 5C 1D 4B 00 00 C0 12 50 B0 79 58 00 00 C0 |.`\.K....P.yX... 040: 12 54 79 E1 46 00 00 C0 12 14 00 6C 00 61 00 6E |.Ty.F......l.a.n 050: 00 63 00 69 00 61 00 2E 00 74 00 78 00 74 00 02 |.c.i.a...t.x.t.. 060: 00 00 00 00 00 00 00 00 00 09 00 00 54 79 E1 46 |............Ty.F 070: 00 00 C0 12 14 00 6C 00 61 00 6E 00 63 00 69 00 |......l.a.n.c.i. 080: 61 00 2E 00 74 00 78 00 74 00 00 00 00 00 00 00 |a...t.x.t....... 090: 00 00 00 00 10 00 4F 49 4D 47 03 00 00 00 26 19 |......OIMG....&. 0a0: 00 00 00 00 00 00 14 00 6C 00 61 00 6E 00 63 00 |........l.a.n.c. 0b0: 69 00 61 00 2E 00 74 00 78 00 74 00 0A 00 49 00 |i.a...t.x.t...I. 0c0: 6E 00 65 00 74 00 00 00 48 00 54 00 4D 00 4C 00 |n.e.t...H.T.M.L. 0d0: 00 00 6C 00 61 00 6E 00 63 00 69 00 61 00 00 00 |..l.a.n.c.i.a... 0e0: 99 66 99 66 07 00 |.f.f..I intentionally choose a different record in the file to show the contrast between the variable length strings which break up the sections of this structure. The file data regions headers all begin with the signature id 0x33CC33CC as shown above at offset 0. This is followed by an exact copy of the catalog region header (except for the last header record which only differs in the last few bytes). So in the dump above if ones starts counting at offset 4 after the four byte signature, the files region data above matches the field offsets for the catalog region data above, although the data in the field differs, assuming one accounts for the variable length uni-code data fields.
However the files region structure also contains additional information after
the 3rd unicode string. The byte following the 3rd unicode string, "lancia.txt" in
ascii, is at offset 0xBC above. The next two bytes function are unknow but always
appear to be (0xa,0). This is followed by a forth variable length unicode path
string, but its in a slightly different format from the three unicode strings
above as there is no preceding length word. The total number of bytes
in this define by the unicode path as the path length byte described at offset 0xA
of the catalog record (and in this file record dump its at offset 0xE as the
4 byte signature precedes the catalog data in this record). The number of bytes
in this path string at the end of the record is This is the end of the file structure. If its a file and there is file data to be written to disc when its extracted the file length bytes will be greater than 0. If no data needs to be extracted the file length at offset 0x11 is 0. If the file length is greater than zero this number of bytes must be skipped over or written out for extraction.
Finally there is another trailer record after the file data if it exists. This
trailer is 18 bytes long and contains three instances of the signature 0x66996699:
Following this trailer the sequence repeats with the next file beginning with
the signature byte 0x33CC33CC. If this attempt at an English description doesn't work for you try looking at the source code for rd113.c in rd113_src.tar.gz. Iomega *.DBF file formatThis is shorter and less specific as I doubt anyone is really interested or likely to still have the need to look at the format of the configuration files the dtiom98 program maintains to control the backup generation. However a little documentation is of interest as these file use a format that is very similar to the one used in the later 1-Step backup program version 5.3.
The files of potential interest in the Program Files\Iomega\Iomega Back\: FILEINFO.DBF, FILEINFO.CDX FILES.DBF, FILES.CDX, FILES.FTP, FILES.STK TAPES.DBF, TAPES.CDX. TAPES.FPT, TAPES.STK VOLUMES.DBF, VOLUMES.CDX, VOLUMES.STK Recover.Cfg OneStep.Cfg LOG_FILEI have looked casually at the *.DBF files as described below. The LOG_FILE is as the name implies a log of all the backups done on the current machine. Its appended to after each backup so it contains a history of the backups that were done. The other files above are overwritten with new data after each backup or when the configuration options are changed.
The OneStep.Cfg file is text file that seem to contain the following:
1st line has always been the same on my test machine.
2nd line Job # and # of disks in last backup
3rd line date and time backup was done
The recover.cfg might be the same format, but I've never created a recovery disk
so am not sure, in my samples only the 1st line has text. Both my *.Cfg
files contain the following text in line 1:
*.dbf files are a mix of binary and text data listing backup files
*.cdx files are primarily binary, but have regions of text data.
*.fpt files are primarily binary, but have some text data.
these seem to begin with the missing name data in *.dbf files
*.stk files are binary, but typically just 8 bytes long
|
File Format > Iomega 1-Step Backup >