We received a bug report from an internal user that archive/zip can't open certain
Android apk (zip) files.
The problem is the zip's Extra field appears to be short.
The extra field is "\xfe\xca\x00\x00\x00\x00".
An Extra field is supposed to be a repetition of (2 byte tag, 2 byte size, size-bytes of
data).
So that's tag 51966 ("CAFE", apparently: a Java thing?
https://issues.apache.org/bugzilla/show_bug.cgi?id=32649), size 0, and then we have
"\x00\x00" left over, but those two bytes aren't long enough (we always expect
at least 4 bytes: 2 for tag, 2 for size).
But the "zip" tool handles it fine, so perhaps we should just skip over extra
fields when they're short.
The zipdetails program is also confused with it a bit (despite exiting with status 0),
with an"Unexpecded" (sic) status:
$ zipdetails Contacts.apk
000000 LOCAL HEADER #1 04034B50
000004 Extract Zip Spec 0A '1.0'
000005 Extract OS 00 'MS-DOS'
000006 General Purpose Flag 0800
[Bit 11] 1 'Language Encoding'
000008 Compression Method 0000 'Stored'
00000A Last Mod Time 3F339D41 'Mon Sep 19 19:42:02 2011'
00000E CRC 1E85E138
000012 Compressed Length 00000086
000016 Uncompressed Length 00000086
00001A Filename Length 0030
00001C Extra Length 0006
00001E Filename '...(redacted)....'
00004E Extra ID #0001 CAFE 'Java Executable'
000050 Length 0000
000052 PAYLOAD ...PNG........IHDR....................4n
(redacted)
Unexpecded END at offset 000000D8, value 4B508260
Done
.... Perhaps we need to special case that extra field type, and say that at least a
"\x00\x00" extra tag without a size is an acceptable EOF, either always, or
only following a CAFE tag.
We received a bug report from an internal user that archive/zip can't open certain Android apk (zip) files. The problem is the zip's Extra field appears to be short. The extra field is "\xfe\xca\x00\x00\x00\x00". An Extra field is supposed to be a repetition of (2 byte tag, 2 byte size, size-bytes of data). So that's tag 51966 ("CAFE", apparently: a Java thing? https://issues.apache.org/bugzilla/show_bug.cgi?id=32649), size 0, and then we have "\x00\x00" left over, but those two bytes aren't long enough (we always expect at least 4 bytes: 2 for tag, 2 for size). But the "zip" tool handles it fine, so perhaps we should just skip over extra fields when they're short. The zipdetails program is also confused with it a bit (despite exiting with status 0), with an"Unexpecded" (sic) status: $ zipdetails Contacts.apk 000000 LOCAL HEADER #1 04034B50 000004 Extract Zip Spec 0A '1.0' 000005 Extract OS 00 'MS-DOS' 000006 General Purpose Flag 0800 [Bit 11] 1 'Language Encoding' 000008 Compression Method 0000 'Stored' 00000A Last Mod Time 3F339D41 'Mon Sep 19 19:42:02 2011' 00000E CRC 1E85E138 000012 Compressed Length 00000086 000016 Uncompressed Length 00000086 00001A Filename Length 0030 00001C Extra Length 0006 00001E Filename '...(redacted)....' 00004E Extra ID #0001 CAFE 'Java Executable' 000050 Length 0000 000052 PAYLOAD ...PNG........IHDR....................4n (redacted) Unexpecded END at offset 000000D8, value 4B508260 Done .... Perhaps we need to special case that extra field type, and say that at least a "\x00\x00" extra tag without a size is an acceptable EOF, either always, or only following a CAFE tag.