Conversation
APKs that AOSP accepts can set the encrypted-entry bit (or bogus compression methods) without actually encrypting entries. java.util.zip rejects those CEN headers while libziparchive ignores them. Repair headers in a temp copy when ZipFile fails with invalid CEN header, so apktool d works on the same class of packages reported in iBotPeaches#4028. Fixes iBotPeaches#4028 Signed-off-by: Atirna <288419661+atirna@users.noreply.github.com>
Track the user path separately from the repaired zip source, delete the repair copy after decode, and set zip64 validation bypass for library entrypoints. Extend the regression test to cover apktool.yml and rebuild output naming. Signed-off-by: Atirna <288419661+atirna@users.noreply.github.com>
|
Always thought we'd need a complex return of ZipUtils, but this creation with AI might be a shortened version. |
e38997c to
f7cef94
Compare
|
yeah its a shorter path than wrapping ZipUtils. decode still repairs CEN/local flags in a temp copy when java.util.zip rejects encrypted-entry bits that AOSP accepts, then it keeps the original apkFileName for rebuild. |
|
So ultimately its a choice whether maintaining a chunk of code is worth it vs an alternative library. I'm sure @IgorEisberg has some opinions as well |
|
So here are my impressions:
|
|
If we make |
iBotPeaches
left a comment
iBotPeaches
left a comment
There was a problem hiding this comment.
As discussed a bit. Onboard if we introduce a new area (brut.j.zip) and can do with no userland changes, as everything should be handled via ExtFile.
If you have to change anything elsewhere. Please let me know what led to that and why.
Per review: introduce a dedicated brut.j.zip module owning the tolerant zip behavior, and reduce the change outside it to swapping the backing ZipFile in brut.j.dir. ApkDecoder and ZipUtils return to their original shape; decode routes through ExtFile -> ZipRODirectory as before. RepairingZipFile repairs central-directory / local-header fields AOSP tolerates (spurious encrypted bit, non-DEFLATE/STORE methods) in a temp copy and removes it on close. Clean archives open in place. The old apktool-lib test needed the full testapp apparatus; the module test builds a minimal zip and flips the header bits directly. Refs iBotPeaches#4028
…o fix/encrypted-cen-header-4028
The method rewrite relabeled unknown compression methods as stored, which corrupts entries whose bytes are actually deflated. The repair now only clears the encrypted-entry bit from CEN and LFH general purpose flags, which is the behavior issue iBotPeaches#4028 needs; unknown methods surface the underlying zip error instead of producing garbage. Also fixes the byte-reversed CEN signature scan in the module test.
Add the new zip module to the Maven publication set so brut.j.dir resolves it with the project version instead of unspecified. Simplify the ZIP mutation fixture and assert that repair leaves the original archive byte-identical. Signed-off-by: Atirna <288419661+atirna@users.noreply.github.com>
|
moved this into a dedicated brut.j.zip module. only ZipRODirectory swaps its backing ZipFile now, the repair stays out of Apktool userland and preserves the source bytes. also wired the new module into Maven publication metadata. tests are 3/3 for brut.j.zip and 186/186 for apktool-lib. |
Signed-off-by: Atirna <288419661+atirna@users.noreply.github.com>
|
also redesigned the zip test in 3df5889. it now uses one fixed 138-byte malformed fixture instead of rebuilding/parsing zip headers in test code, so the file is down from 125 to 75 lines and keeps only the repair + reject cases. brut.j.zip is 2/2 and apktool-lib is 186/186. |
|
thank you! We are working API 37 right now, but will come back and visit this in a few days. |
Signed-off-by: Atirna <288419661+atirna@users.noreply.github.com>
|
did one more full boundary review in 7accf90. prefixed zip offsets and EOCD signatures inside comments are handled now, temp copies are cleaned on repair/open/close failures, and the fallback only runs for the exact encrypted-entry error. ZIP64/multi-disk are rejected explicitly instead of partly rewritten. the 2 tests pass on Java 8/11/17 and apktool-lib is 186/186. |
|
Not exactly what I meant by "our own ZIP handling library", but this could actually be serviceable until/if we decide to have our own ZIP library that "just works" similarly to Android. |
|
One thing I'm curious about. Is our goal more-so to repair the Zip so the existing library can handle it? Or can we go low enough level that our parser just ignores the things (much like AOSP) does for like encrypted bit, general access bit, etc? I'm guessing there are limitations in Java on how low level you can go. Which is probably why we had to byte-adapt our way around a recovery. Or is the ZipSpec roughly easy enough that we have to build our own small library much like I think ARSCLib/JadX did in order to have full control. |
Of course, I'd prefer opening those ZIPs like Android does without making any fixes or copies. |
3 participants
Description
I added a dedicated
brut.j.zipmodule for classic single-disk APK ZIPs that only have the spurious encrypted-entry flag which Android accepts butjava.util.zip.ZipFilerejects.ZipRODirectorynow swaps its backingZipFileforRepairingZipFile. The repair stays inside the ZIP layer, clears only that flag in a temporary copy, and leaves the source archive unchanged. Prefixed ZIP offsets and EOCD signatures inside comments are handled; ZIP64 and multi-disk inputs remain explicitly unsupported instead of being partially rewritten. No Apktool decode or rebuild code changes are needed.The new module is included in Maven publication metadata so
brut.j.dirresolvesorg.apktool:brut.j.zipwith the project version.Fixes #4028
Verification
./gradlew :brut.j.zip:teston Java 8, 11 and 17 (2/2 each)./gradlew :brut.apktool:apktool-lib:test(186/186)./gradlew :brut.j.zip:generatePomFileForMavenJavaPublication :brut.j.dir:generatePomFileForMavenJavaPublication