[ scummvm-Patches-2968610 ] Zak C64 German: crash due to padding bytes

[SourceForge.net]

Patches item #2968610, was opened at 2010-03-11 12:17
Message generated for change (Tracker Item Submitted) made by tobigun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=2968610&group_id=37116

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tobias Gunkel (tobigun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zak C64 German: crash due to padding bytes

Initial Comment:
The German version of zak c64 crashes when the intro (zak's dream) starts.
The crash is caused by a 0xFFFF padding word in room 47 that precedes the correct 16bit length of sound resource 95. The 0xFFFF is erroneously handled as the size of resource 95 and causes an overflow of reslen.
This 0xFFFF padding occurs only in the german version and only once in room 47.

Here the section of room 47 
          v= end of sound resource[1]
... FD 00 | FF FF | 1B 0B 00 04 ...
   padding =^       ^= start of resource[95], first two bytes: size

Some more info:
- the index file (00.LFL) stores the correct index for resource 95 (room: 47, offset: 5596)
- the sizes of resource 95 according to the length field (value: 2843) are the same in the German and English version
- the 0xFFFF padding is at offset 5594
- the preceding resource (resource 1) starts at offset 4516. Its length field (which already includes the 2 bytes for the length field) has a value of 1078 (same as the English version)
-> 4516+1078=5594 points to the padding bytes and hence the 0xFFFF must be skipped
	  
I already checked if my (original and uncracked) disk copy was corrupted or if there was some transmission error from my VC1541 to my computer but the disk image is correct.

The solution is very simple. The patch simply does not handle 0xFFFF (none of the LFL files is that large that a resource could be of that size) as a valid length and seeks for a non 0xFFFF value before handling the resource. The 0xFFFF is still written to the output, otherwise the 00.LFL offsets would not match.

The patch is just for ScummVM but the zak-c64 resource extractor has to be changed accordingly. It returns a 70KB sized 47.LFL (as it interprets 0xFFFF as resource length) which is not correct.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=2968610&group_id=37116