I found today that when the block decoder is finding length of a block from file header that the block length can be odd. When decoded the length is divided by 4 as it decodes in sets of long words. This presents a problem as the decoder will be one long word short in cases of the length being odd or otherwise not divisible by four. I've seen this happen.
Can the block word count be safely increased to the next block word in alignment? Without trashing memory? Or corrupting data? With this calculation:
block_elements = (length_read + 3) / 4;
Can the decoder work with bytes or a byte decoder added for uneven length?
I found file font12 has an odd block.
As it is the blocks need to be aligned to a four byte boundary. Which I thought the blocks would be encoded as. Being the data is encoded in little endian presents another problem as the word will be pulled out in reverse, decoded and put back in reverse; so even if an extra byte is handled it needs to be decrypted with the right key. Then the next block of data is out of alignment.
Perhaps the MPQ is encoded like that on purpose and and I'm making much ado about nothing.
:-)
I found today that when the block decoder is finding length of a block from file header that the block length can be odd. When decoded the length is divided by 4 as it decodes in sets of long words. This presents a problem as the decoder will be one long word short in cases of the length being odd or otherwise not divisible by four. I've seen this happen.
Can the block word count be safely increased to the next block word in alignment? Without trashing memory? Or corrupting data? With this calculation:
block_elements = (length_read + 3) / 4;Can the decoder work with bytes or a byte decoder added for uneven length?
I found file font12 has an odd block.
As it is the blocks need to be aligned to a four byte boundary. Which I thought the blocks would be encoded as. Being the data is encoded in little endian presents another problem as the word will be pulled out in reverse, decoded and put back in reverse; so even if an extra byte is handled it needs to be decrypted with the right key. Then the next block of data is out of alignment.
Perhaps the MPQ is encoded like that on purpose and and I'm making much ado about nothing. :-)