Issue 8186 in go: archive/zip: can't handle certain Java-generated zip (apk) files
12 views
Skip to first unread message
g...@googlecode.com
Jun 11, 2014, 1:28:26 PM6/11/14
to golan...@googlegroups.com
Status: Accepted
Owner: ----
CC: a...@golang.org
Labels: Release-Go1.4 Repo-Main
New issue 8186 by brad...@golang.org: archive/zip: can't handle certain
Java-generated zip (apk) files
http://code.google.com/p/go/issues/detail?id=8186
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.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Owner: ----
CC: a...@golang.org
Labels: Release-Go1.4 Repo-Main
New issue 8186 by brad...@golang.org: archive/zip: can't handle certain
Java-generated zip (apk) files
http://code.google.com/p/go/issues/detail?id=8186
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.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
g...@googlecode.com
Jun 17, 2014, 3:07:48 PM6/17/14
to golan...@googlegroups.com
Comment #1 on issue 8186 by a...@ashishgandhi.org: archive/zip: can't
Maybe I'm being stupid but can't seem to be able to reproduce the problem.
Here's what I tried:
1. Get Contacts.apk from Gingerbread. (Going by the date in the dump and
the fact that later versions don't seem to have CAFE. Source:
http://forum.xda-developers.com/showthread.php?t=923292.)
2. zipdetails Contacts.apk on the Contacts.apk attached here exhibit the
same things as the dump in this report.
3. Move Contacts.apk into src/pkg/archive/zip/testdata.
4. Add a test case in src/pkg/archive/zip/reader_test.go.
(https://gist.github.com/ashishgandhi/e88d5399a219ca1703d4)
5. All tests pass.
Attachments:
Contacts.apk 572 KB
g...@googlecode.com
Jun 17, 2014, 3:08:59 PM6/17/14
to golan...@googlegroups.com
Comment #2 on issue 8186 by brad...@golang.org: archive/zip: can't handle
It's not all versions of the misc Java/Android toolchains. It's only
happening more recently with later versions, it seems. Gingerbread was fine.
g...@googlecode.com
Jun 17, 2014, 5:06:11 PM6/17/14
to golan...@googlegroups.com
Comment #3 on issue 8186 by a...@ashishgandhi.org: archive/zip: can't
Tried with ICS Contacts.apk from
http://forum.xda-developers.com/showthread.php?t=1735507. The tests passed.
What would be a good way get hold of a misbehaving archive?
Attachments:
Contacts.apk 1.7 MB
g...@googlecode.com
Jun 18, 2014, 7:44:59 PM6/18/14
to golan...@googlegroups.com
Comment #4 on issue 8186 by ash...@exceptional.io: archive/zip: can't
Or if there's a way to produce these misbehaving archives that'd be best.
That way I could create a version that's smaller than a Contacts.apk would
be and add it to testdata.
g...@googlecode.com
Jun 18, 2014, 7:46:00 PM6/18/14
to golan...@googlegroups.com
g...@googlecode.com
Jun 18, 2014, 7:56:13 PM6/18/14
to golan...@googlegroups.com
Comment #6 on issue 8186 by brad...@golang.org: archive/zip: can't handle
I will create a synthetic one when I fix the bug for testdata.
The apk I have is of an unreleased Android app and is also too large.
g...@googlecode.com
Jun 18, 2014, 9:28:35 PM6/18/14
to golan...@googlegroups.com
Comment #7 on issue 8186 by a...@ashishgandhi.org: archive/zip: can't handle
To document one more thing that I tried (in hope it may help someone avoid
the same pitfalls). I created an executable JAR using Oracle's latest JDK.
$ zipdetails Noop.jar
0000 LOCAL HEADER #1 04034B50
0004 Extract Zip Spec 14 '2.0'
0005 Extract OS 00 'MS-DOS'
0006 General Purpose Flag 0808
[Bits 1-2] 0 'Normal Compression'
[Bit 3] 1 'Streamed'
[Bit 11] 1 'Language Encoding'
0008 Compression Method 0008 'Deflated'
000A Last Mod Time 44D28AE1 'Wed Jun 18 17:23:02 2014'
000E CRC 00000000
0012 Compressed Length 00000000
0016 Uncompressed Length 00000000
001A Filename Length 0009
001C Extra Length 0004
001E Filename 'META-INF/'
0027 Extra ID #0001 CAFE 'Java Executable'
0029 Length 0000
002B PAYLOAD ..
(redacted)
$ hexdump -C Noop.jar | grep "fe ca 00 00"
00000200 2d 49 4e 46 2f fe ca 00 00 50 4b 01 02 14 00 14 |
-INF/....PK.....|
I failed to get tests to fail.
(https://gist.github.com/ashishgandhi/335918f19261f05de4ba)
I guess I might be being stupid. Apologies for the wasted effort.
Attachments:
Noop.jar 665 bytes
g...@googlecode.com
Aug 4, 2014, 2:45:24 PM8/4/14
to golan...@googlegroups.com
Updates:
Status: Started
Owner: brad...@golang.org
Labels: -Release-Go1.4 Release-Go1.3.1
Comment #8 on issue 8186 by brad...@golang.org: archive/zip: can't handle
Sent https://codereview.appspot.com/117550044
Tagging for consideration for Go 1.3.1 because there is no real workaround
(short of forking the package) and this is affecting users.
Status: Started
Owner: brad...@golang.org
Labels: -Release-Go1.4 Release-Go1.3.1
Comment #8 on issue 8186 by brad...@golang.org: archive/zip: can't handle
Sent https://codereview.appspot.com/117550044
Tagging for consideration for Go 1.3.1 because there is no real workaround
(short of forking the package) and this is affecting users.
g...@googlecode.com
Aug 4, 2014, 2:48:26 PM8/4/14
to golan...@googlegroups.com
Comment #9 on issue 8186 by go...@golang.org: archive/zip: can't handle
certain Java-generated zip (apk) files
http://code.google.com/p/go/issues/detail?id=8186#c9
CL https://codereview.appspot.com/117550044 mentions this issue.
g...@googlecode.com
Aug 4, 2014, 7:13:17 PM8/4/14
to golan...@googlegroups.com
Updates:
Status: Fixed
Comment #10 on issue 8186 by brad...@golang.org: archive/zip: can't handle
This issue was closed by revision 8ab50c14cd95.
Status: Fixed
Comment #10 on issue 8186 by brad...@golang.org: archive/zip: can't handle
This issue was closed by revision 8ab50c14cd95.
g...@googlecode.com
Aug 11, 2014, 3:36:43 PM8/11/14
to golan...@googlegroups.com
Updates:
Cc: r...@golang.org
Labels: -Release-Go1.3.1 Release-Go1.4
Comment #11 on issue 8186 by r...@golang.org: archive/zip: can't handle
Inclined to say no for Go 1.3.1.
People being affected do have a workaround: copy the zip package for now.
Nothing hard-codes a dependency on zip (like things do for net/http or
database/sql/driver) so that shouldn't be too bad.
Arguments to the contrary welcome.
Cc: r...@golang.org
Labels: -Release-Go1.3.1 Release-Go1.4
Comment #11 on issue 8186 by r...@golang.org: archive/zip: can't handle
Inclined to say no for Go 1.3.1.
People being affected do have a workaround: copy the zip package for now.
Nothing hard-codes a dependency on zip (like things do for net/http or
database/sql/driver) so that shouldn't be too bad.
Arguments to the contrary welcome.
Reply all
Reply to author
Forward
0 new messages