Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
archive/zip: ignore malformed Extra field #13166
I have problem with golang zip reader. We have apk builder which build apk and then encrypted this apk with dex protector.
When i try to open apk file, go return err "zip: not a valid zip file". But when i try to open with unzip or zipinfo, worked fine.
I try open to debug golang archive/zip pckage and found that error returned in this line https://github.com/golang/go/blob/master/src/archive/zip/reader.go#L269.
Then i try to debug this line like this:
fmt.Printf("%+v", f) fmt.Println( "len(f.Extra):", len(f.Extra), "len(b):", len(b), "tag:", tag, "size:", size, )
And have this results:
Problem in extra headers (i think this extra headers add dex protector when encrypt apk). Size more then length of extra bytes. But unzip util and ZipArchive in php5.5 woked perfect with this extras. How to fix this ?
I want to rewrite this piece in go archive/zip package, so that the extras do not interfere golang zip reader.
It's very important for me, because i rewrite build apk from php to golang and I came across a problem that can not decide :(. Please help me.
Brad can you help me :).
I was thinking.
The extra field contains these bytes:
That's obviously wrong, since it's supposed to contain a sequence of entries each beginning with a 2-byte tag + 2-byte size. Maybe dexprotector even does this intentionally, to make some analysis tools reject the zip file.
However, this is something that was added late to zip files, and early versions of the tools are expected to ignore the extra fields, and most do. The only reason we parse the extra fields is to look for the zip64 extension. Obviously it's not present in this file, so I think rather than return ErrFormat we should just stop looking and keep going.
This is the second time we've had problems with our extra field parsing being too strict. Let's just make it best effort and be done with it. It's clearly something zip implementations disagree about.