Fix/crash corrupted iso

[r-fogash]

What

• If an ISO 9660 file contains a malformed SUSP extension XADMaster crashes.

Impacted Areas

• XADUnarchiver

Details

Let's open an ISO image file with malformed CE SUSP section and view the memory of that section

Lets read the SUSP, IEEE P1281 standard which says:

The format of the "CE" System Use Field is as follows:
[1] "BP 1 to BP 2 - Signature Word" shall indicate that the System Use Field is a "CE" type System Use Field. The bytes in this field shall be (43)(45) ("CE")
[2] "BP 3 - Length (LEN_SUF)" shall specify as an 8-bit number the length in bytes of the "CE" System Use Field. The number in this field shall be 28 for this version. This field shall be recorded according to the ISO 9660:1988 Format section 7.1.1.
[3] "BP 4 - System Use Field Version" shall specify as an 8-bit number an identification of the version of the "CE" System Use Field. The number in this field shall be 1 for this version. This field shall be recorded according to the ISO 9660:1988 Format section 7.1.1.
[4] "BP 5 to BP 12 - Location of Continuation of System Use Area" shall specify as a 32-bit number the Logical Block Number of the first Logical Block of the Logical Sector that contains the start of this Continuation of the Sytem Use Area. This field shall be recorded according to the ISO 9660:1988 Format section 7.3.3.
[5] "BP 13 to BP 20 - Offset to Start of Continuation" shall specify as a 32-bit number the offset, in bytes, from the start of the block specified in [4] above to the start of the area that is to be used for this Continuation of the System Use Area. This field shall be recorded according to the ISO 9660:1988 Format section 7.3.3.

ISO 9660:1988 Format section 7.1.1:

8-bit unsigned numerical vaiues
An unsigned numerical value shall be represented in binary notation by an 8-bit number recorded in a one-byte field.

ISO 9660:1988 Format section 7.3.3:

Both-byte orders
A numerical value represented by the hexadecimal representation (st uv wx yz) shall be recorded in an eight- byte field as (yz wx uv st st uv wx yz).
NOTE 14
For example, the decimal number 305419896 has (12 34 56 78) as its hexadecimal representation and is recorded as (78 56 34 12 12 34 56 78).

Lets check it with our memory
43 45 1C 01 00 00 00 BF 00 00 00 4D 00 00 00 4D DB 29 00 00

[1] (43, 45) - Correct
[2] (1C) - Correct
[3] (01) - Correct
[4] (00 00 00 BF 00 00 00 4D) Not correct, because this field is Both byte order (see above), so 0xBF000000 should be equal to 0x0000004D
[5] (00 00 00 4D DB 29 00 00) Not correct, because this field is Both byte order (see above), so 0x4D000000 should be equal to 0xDB290000

[alek-prykhodko]

🚀

[nekrich]

[PaulTaykalo]

shouldn't nextLength be lengthLE? or lengthBE?
this should be probably be nextLength = lengthBE

[PaulTaykalo]

@r-fogash can you look into it?

[r-fogash]

you are right, Xcode "forgot" to rename the variable in line 674 in the second commit. Fixed

[PaulTaykalo]

🔥 nice