Correct mszip extraction on some cabs currently relies on an exception being thrown #17

New Issue

Closed

opened 2026-01-29 21:16:35 +00:00 by claunia · 1 comment

claunia commented 2026-01-29 21:16:35 +00:00

Owner

Copy Link

Originally created by @HeroponRikiBestest on GitHub (Nov 30, 2025).

To preface; technically, there's no issue with mszip extraction (that I know of) right now; what I describe results in the proper file data being extracted.

At the moment, on some mszip cabs, extraction will hit the following:

4b39ee8d00/SabreTools.Serialization/Wrappers/MicrosoftCabinet.cs (L268)

The program will pad the block out to 32768 bytes, and write it to the stream.
Every time this happens, the immediate subsequent block will throw an exception on this line:

4b39ee8d00/SabreTools.Serialization/Wrappers/MicrosoftCabinet.cs (L262)

Resulting in log output looking like this:

Data block 27168 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
Data block 10321 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
Data block 16068 in folder 0 had mismatching sizes. Expected: 32768, Got: 16904
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)

However, this doesn't actually seem to cause any issues. The resulting files that are extracted have all the right data, and match 1:1 against extraction from other programs like 7z.

Despite this, I'm opening an issue since it seems potentially dangerous to rely on an exception being thrown for proper output, especially if any other changes are made to this section. It also makes it more difficult to find actual issues in the console output.

This happens on some number of mszip cabs, but not all of them. The cab used in this issue was the 27-part cab inside 2K Sports Major League Baseball 2K9 (USA).iso http://redump.org/disc/59967/ , where this occurs several times.

Other examples include the multi-part cab inside Singularity (Europe) (En,Fr,Es,It).iso http://redump.org/disc/52122/ , inside Lost Planet - Extreme Condition - Colonies Edition (Russia) (En,Ja,Fr,De,Es,It,Ko,Pl,Ru) (Disc 1) http://redump.org/disc/80571/ , and inside Brothers in Arms - Hell's Highway (Germany) (En,De) http://redump.org/disc/85478/ . More examples can be provided if necessary.

Originally created by @HeroponRikiBestest on GitHub (Nov 30, 2025). To preface; technically, there's no issue with mszip extraction (that I know of) right now; what I describe results in the proper file data being extracted. At the moment, on some mszip cabs, extraction will hit the following: https://github.com/SabreTools/SabreTools.Serialization/blob/4b39ee8d0058ce20101c0ae41ef755e6fe6e3f50/SabreTools.Serialization/Wrappers/MicrosoftCabinet.cs#L268 The program will pad the block out to 32768 bytes, and write it to the stream. Every time this happens, the immediate subsequent block will throw an exception on this line: https://github.com/SabreTools/SabreTools.Serialization/blob/4b39ee8d0058ce20101c0ae41ef755e6fe6e3f50/SabreTools.Serialization/Wrappers/MicrosoftCabinet.cs#L262 Resulting in log output looking like this: ```cs Data block 27168 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139 System.IO.InvalidDataException: source at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug) System.IO.InvalidDataException: source at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug) Data block 10321 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139 System.IO.InvalidDataException: source at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug) Data block 16068 in folder 0 had mismatching sizes. Expected: 32768, Got: 16904 System.IO.InvalidDataException: source at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug) ``` However, this doesn't actually seem to cause any issues. The resulting files that are extracted have all the right data, and match 1:1 against extraction from other programs like 7z. Despite this, I'm opening an issue since it seems potentially dangerous to rely on an exception being thrown for proper output, especially if any other changes are made to this section. It also makes it more difficult to find actual issues in the console output. This happens on some number of mszip cabs, but not all of them. The cab used in this issue was the 27-part cab inside `2K Sports Major League Baseball 2K9 (USA).iso` http://redump.org/disc/59967/ , where this occurs several times. Other examples include the multi-part cab inside `Singularity (Europe) (En,Fr,Es,It).iso` http://redump.org/disc/52122/ , inside `Lost Planet - Extreme Condition - Colonies Edition (Russia) (En,Ja,Fr,De,Es,It,Ko,Pl,Ru) (Disc 1)` http://redump.org/disc/80571/ , and inside `Brothers in Arms - Hell's Highway (Germany) (En,De)` http://redump.org/disc/85478/ . More examples can be provided if necessary.

claunia closed this issue 2026-01-29 21:16:35 +00:00

claunia commented 2026-01-29 21:16:36 +00:00

Author

Owner

Copy Link

@mnadareski commented on GitHub (Jan 5, 2026):

Reopening as the first PR doesn't fully cover this, as already discussed with @HeroponRikiBestest

@mnadareski commented on GitHub (Jan 5, 2026): Reopening as the first PR doesn't fully cover this, as already discussed with @HeroponRikiBestest

claunia referenced this issue 2026-01-29 21:16:45 +00:00

[PR #17] [MERGED] Add extra validity checks for GCF #41

claunia referenced this issue 2026-01-29 21:16:45 +00:00

[PR #17] Add extra validity checks for GCF #44

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

zlib-transition

rolling

2.2.1

2.2.0

2.1.0

2.0.2

2.0.1

2.0.0

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.3

1.4.2

1.4.1

1.4.0

1.3.3

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

Labels

Clear labels

pull-request

Mirrored from GitHub Pull Request

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

claunia

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/SabreTools.Serialization#17