I've run into this problem as well while trying out the package, but I actually think this is a problem in SharpCompress rather than malformed headers (or, at least, a case where it doesn't handle the malformed data cleanly).
This is a dump of the first few bytes from a .epub (zip) file -
00000030 6E 2F 65 70 75 62 2B 7A 69 70 50 4B 03 04 14 00 n/epub+zipPK....
00000040 00 08 08 00 01 70 78 41 00 00 00 00 02 00 00 00 .....pxA........
00000050 00 00 00 00 09 00 00 00 4D 45 54 41 2D 49 4E 46 ........META-INF
00000060 2F 03 00 50 4B 03 04 14 00 00 08 08 00 01 70 78 /..PK.........px
If I'm reading this correctly, the META-INF/ local file header states that it has a 9 character filename, 2 bytes of compressed data, and 0 bytes of uncompressed data... and there does indeed seem to be 9 characters of filename followed by two bytes of data (the 03 00 before the next PK header).
I think the problem is that the data (whatever it actually IS) is never read, and then when we try to move to the next record we have this in AbstractReader:
privatevoid SkipEntry() {if (!Entry.IsDirectory) { Skip(); } }
... with the result that the 2 bytes aren't skipped. The next header read off is then '03 00 50 4B' instead of '50 4B 03 04'.
I hesitate to file it as a bug since I'm not sure the zip files aren't wrong in the first place :)