1 ISZ File Format Specification
\r
3 Revised: July 3, 2006
\r
4 Copyright (c) 2002-2006 EZB Systems, Inc., All Rights Reserved.
\r
8 This specification is intended to define an interoperable
\r
9 ISO CD/DVD image storage and transfer format.
\r
14 Although EZB Systems will attempt to supply current and accurate
\r
15 information relating to its file formats, algorithms, and the
\r
16 subject programs, the possibility of error or omission cannot
\r
17 be eliminated. EZB Systems therefore expressly disclaims any warranty
\r
18 that the information contained in the associated materials relating
\r
19 to the subject programs and/or the format of the files created or
\r
20 accessed by the subject programs and/or the algorithms used by
\r
21 the subject programs, or any other matter, is current, correct or
\r
22 accurate as delivered. Any risk of damage due to any possible
\r
23 inaccurate information is assumed by the user of the information.
\r
24 Furthermore, the information relating to the subject programs
\r
25 and/or the file formats created or accessed by the subject
\r
26 programs and/or the algorithms used by the subject programs is
\r
27 subject to change without notice.
\r
29 3. General Format of a .ISZ file
\r
30 --------------------------------
\r
32 Large .ISZ files can span multiple disk media or be split into
\r
33 user-defined segment sizes.
\r
35 Overall .ISZ file format:
\r
38 [Segment defination table]
\r
39 [Chunk defination table]
\r
46 3.1 ISZ file header:
\r
48 typedef struct isz_file_header {
\r
49 char signature[4]; // 'IsZ!'
\r
50 unsigned char header_size; // header size in bytes
\r
51 char ver; // version number
\r
52 unsigned int vsn; // volume serial number
\r
54 unsigned short sect_size; // sector size in bytes
\r
55 unsigned int total_sectors; // total sectors of ISO image
\r
57 char has_password; // is Password protected?
\r
59 __int64 segment_size; // size of segments in bytes
\r
61 unsigned int nblocks; // number of chunks in image
\r
62 unsigned int block_size; // chunk size in bytes (must be multiple of sector_size)
\r
63 unsigned char ptr_len; // chunk pointer length
\r
65 char seg_no; // segment number of this segment file, max 99
\r
67 unsigned int ptr_offs; // offset of chunk pointers, zero = none
\r
69 unsigned int seg_offs; // offset of segment pointers, zero = none
\r
71 unsigned int data_offs; // data offset
\r
77 The 'has_password' field should be one of the following values:
\r
79 #define ADI_PLAIN 0 // no encryption
\r
80 #define ADI_PASSWORD 1 // password protected (not used)
\r
81 #define ADI_AES128 2 // AES128 encryption
\r
82 #define ADI_AES192 3 // AES192 encryption
\r
83 #define ADI_AES256 4 // AES256 encryption
\r
85 3.2. Segment defination table (SDT)
\r
87 This descriptor exists only if 'seg_offs' field of ISZ header is not zero.
\r
89 Immediately following the ISZ file header to define segment information.
\r
91 typedef struct isz_seg_st {
\r
92 __int64 size; // segment size in bytes
\r
93 int num_chks; // number of chunks in current file
\r
94 int first_chkno; // first chunk number in current file
\r
95 int chk_off; // offset to first chunk in current file
\r
96 int left_size; // uncompltete chunk bytes in next file
\r
99 If an ISZ file is not segmented (has only one segment), no SDT should be
\r
100 stored. The 'seg_offs' field in ISZ file header should be zero.
\r
102 For ISZ files with N segments, N+1 SDT entries should be stored. 'size' field of
\r
103 the last SDT entry should be zero.
\r
105 3.3. Chunk defination table (CDT)
\r
107 This descriptor exists only if 'ptr_offs' field of ISZ haeder is not zero.
\r
109 Immediately following the SDT to define chunk information.
\r
111 typedef struct isz_chunk_st {
\r
116 'chunk_flag' and 'blk_len' defination is variable according to 'ptr_len' field of
\r
119 The 'chunk_flag' should be one of the following values:
\r
121 #define ADI_ZERO 0x00 // all zeros chunk
\r
122 #define ADI_DATA 0x40 // non-compressed data
\r
123 #define ADI_ZLIB 0x80 // ZLIB compressed
\r
124 #define ADI_BZ2 0xC0 // BZIP2 compressed
\r
126 Number of CDT entries should equal to 'nblocks' field in ISZ header, 'blk_len'
\r
127 field in CDT entry MUST be less or equal to 'block_size' in ISZ header.
\r
131 According to 'chunk_flag' defination, a chunk may have no data (ADI_ZERO) or
\r
132 'blk_len' bytes of compressed (ADI_ZLIB or ADI_BZ2) or non-compressed data (ADI_DATA)
\r
134 3.5. Splitting and Spanning ISZ files
\r
136 Spanning is the process of segmenting a ISZ file across multiple removable media.
\r
137 This support has typically been provided for floppy diskettes, CD-R discs and DVD-R discs.
\r
139 File splitting is a newer derivative of spanning. Splitting follows the same
\r
140 segmentation process as spanning, however, it does not require writing each
\r
141 segment to a unique removable medium and instead supports placing all pieces onto
\r
142 local or non-removable locations such as file systems, local drives, folders, etc...
\r
144 Split ISZ files are typically written to the same location and are subject to name
\r
145 collisions if the spanned name format is used since each segment will reside on the same
\r
146 drive. To avoid name collisions, split archives are named as follows.
\r
148 Segment 1 = filename.isz
\r
149 Segment 2 = filename.i01
\r
150 Segment n = filename.i(n-1)
\r
152 The .ISZ extension is used on the first segment to support quickly reading the ISO image
\r
153 information directory. The segment number n should be a decimal value.
\r
155 Capacities for split archives are as follows.
\r
157 Maximum number of segments = 99
\r
158 Minimum segment size = 100KB
\r
159 Maximum segment size = 4TB - 1 (64 bits)
\r
161 Segment sizes may be different however by convention, all segment sizes should be the same
\r
162 with the exception of the last, which may be smaller.
\r
164 4. Encryption Method
\r
166 Only chunk data is encrypted if 'has_password' filed of ISZ header is defined.
\r
168 There are three encryption method may be used: AES128, AES192 and AES256.
\r
170 Reference implementations for these algorithms are available from either commercial or
\r
171 open source distributors. Readily available cryptographic toolkits make implementation of
\r
172 the encryption features straight-forward.
\r
174 Encryption is always applied to a chunk after compression. The block oriented algorithms
\r
175 all operate in Cypher Block Chaining (CBC) mode. The block size used for AES encryption is 16.
\r
177 5. Compression Method
\r
179 Chunk data may be compressed by ZLIB or BZIP2 method.
\r
181 ZLIB is a compression library written by Jean-loup Gailly (compression) and Mark Adler (decompression).
\r
182 BZIP2 is an open-source data compression algorithm developed by Julian Seward.
\r
183 Information and source code for these algorithm can be found on the internet.
\r
185 The length of compressed data is defined by CDT entries, and the length of uncompressed data
\r
186 is always less than 'block_size' field in ISZ header.
\r
190 1) Capacity of an ISZ file can be caculated by 'total_sectors' field ('sect_size' is always 2048 for
\r
192 2) SDT and CDT are the central information of an ISZ file. Sector data can be located this way:
\r
193 - Calculate chunk number by: chk_no = (sector_no * sect_size) / block_size
\r
194 - Search in CDT, get chunk length and offset
\r
195 - Search in SDT, get which segment file to read. For data of last chunk, you may need to read left
\r
196 byte from next segment file
\r
197 - Decrypt chunk data as needed
\r
198 - Uncompress chunk data as needed
\r
199 - Get sector data from chunk buffer
\r
200 3) Sengment files may be located in differnet folder. A dialogue box for asking file location is needed
\r
201 for this situation. Segment file can be verified by 'seg_no' and 'vsn' field in ISZ header.
\r
206 In order for the .ISZ file format to remain a viable definition, this specification should be
\r
207 considered as open for periodic review and revision. Although this format was originally
\r
208 designed with a certain level of extensibility, not all changes in technology (present or future)
\r
209 were or will be necessarily considered in its design. If your application requires new definitions
\r
210 to this format, or if you would like to submit new data structures, please forward your request to
\r
211 isz@ezbsystems.com. All submissions will be reviewed for possible inclusion into future versions
\r
212 of this specification. Periodic revisions to this specification will be published to ensure
\r
213 interoperability. We encourage comments and feedback that may help improve clarity or content.
\r
215 8. Incorporating ISZ format into Your Product
\r
216 ------------------------------------------------------------------
\r
218 EZB Systems offers a free license for certain technological aspects described above under certain restrictions
\r
219 and conditions. A free SDK package is also available. Please contact EZB Systems at isz@ezbsystems.com with
\r
220 regard to acquiring a license.
\r