The XPK depacker could read uninitialized junk from the end of the data allocation. This behavior seems to be intentional, so I just made it clear these bytes.
The PowerPacker 2.0 depacker could attempt to skip more than 32 bits in a manner that results in invalid shifts. These files are now rejected. The source of a decompilation project suggests that skip values greater than 32 are impossible anyway.
Ports over two fixes from https://github.com/libxmp/libxmp/pull/492:
The XPK depacker could read uninitialized junk from the end of the data allocation. This behavior seems to be intentional, so I just made it clear these bytes.
The PowerPacker 2.0 depacker could attempt to skip more than 32 bits in a manner that results in invalid shifts. These files are now rejected. The source of a decompilation project suggests that skip values greater than 32 are impossible anyway.