Non-false-positive data errors on isCAB extraction #12

New Issue

Closed

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

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

Owner

Copy Link

Originally created by @HeroponRikiBestest on GitHub (Oct 31, 2025).

It's been a while, but if I remember correctly, the comment at eae75c5943/SabreTools.Serialization/Wrappers/InstallShieldCabinet.Extraction.cs (L342) about "// If we didn't get a positive result that's not a data error (false positives)" ignores zlib data errors due to the issues they were causing. For tombraideranniversary_1.0_d2d.zip, extracting the installshield cabinets inside results in a data error when extracting bigfile.017 from the installshield cabinets, and it's genuine, as it results in a hash mismatch that unshield doesn't have about halfway through the file, rendering the back half incorrect. The incorrect block wounds up being written after the byte at offset 79429631 in bigfile.017. It happens in the loop where totalWritten is 79495168 and writeBytesLeft is 77658112.

I know that there's minimal desire to have to dive back into this, which I understand; I'm only opening an issue because I noticed the problem, will forget in the future, and figure it's good to have a documented real issue for if the future comes.

Originally created by @HeroponRikiBestest on GitHub (Oct 31, 2025). It's been a while, but if I remember correctly, the comment at https://github.com/SabreTools/SabreTools.Serialization/blob/eae75c5943e9f3129514ae58abf3704f78b1ac2b/SabreTools.Serialization/Wrappers/InstallShieldCabinet.Extraction.cs#L342 about "// If we didn't get a positive result that's not a data error (false positives)" ignores zlib data errors due to the issues they were causing. For tombraideranniversary_1.0_d2d.zip, extracting the installshield cabinets inside results in a data error when extracting bigfile.017 from the installshield cabinets, and it's genuine, as it results in a hash mismatch that unshield doesn't have about halfway through the file, rendering the back half incorrect. The incorrect block wounds up being written after the byte at offset 79429631 in bigfile.017. It happens in the loop where totalWritten is 79495168 and writeBytesLeft is 77658112. I know that there's minimal desire to have to dive back into this, which I understand; I'm only opening an issue because I noticed the problem, will forget in the future, and figure it's good to have a documented real issue for if the future comes.

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

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

Author

Owner

Copy Link

@HeroponRikiBestest commented on GitHub (Nov 15, 2025):

Seems to be fixed as of 425d13a2ac

@HeroponRikiBestest commented on GitHub (Nov 15, 2025): Seems to be fixed as of https://github.com/SabreTools/SabreTools.Serialization/commit/425d13a2ac7db5939192649a113a7f19e8fa9cf7

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#12