Little/Big Endian interpretation of "General purpose flag" on OS X

Issue #45 new
Anonymous created an issue

Using: - OS x 10.7 - Python 2.7.1 - wxPython2.8-osx-unicode- - hachoir-core-1.3.3 - hachoir-parser-1.3.4 - hachoir-wx-0.3

I zipped the same source (test.txt) with two options 1) zipped only 2) zipped and encrypted (pw: "test")

Hachoir-wx shows the file which is "zipped only" with a "General purpose flag" of the first entry in the hex-view (top half) as "00 00" like expected: All zero (screenshot zipped-only.png)

The zipped and encrypted file displays the "General purpose flag" of the first entry in the hex view as "09 00" but interprets the 2-byte flag (16 bit Little Endian) as Big Endian, the two bytes are swapped. (screenshot zipped-encrypted.png)

Best regards, MiKa from Vienna

Comments (1)

  1. MiKa_Vienna

    1) in hachoir_parser 1.3.4 interprets the 16 bit General Purpose Flag of e.g. a file entry in the reverse order (lines 83 to 108).

    2) Additionally the conditional yield at lines 287/288 is not needed, it only creates a wrong offset for the next zip header which disturbs the parsing of all following zip entries.

    I fixed it locally and would like to provide it...

    Rgds, MiKa

  2. Log in to comment