You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2018/07/01 10:45:00 UTC
[jira] [Commented] (COMPRESS-455) Cannot open certain APK file
(Unexpected record signature)
[ https://issues.apache.org/jira/browse/COMPRESS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16529044#comment-16529044 ]
Stefan Bodewig commented on COMPRESS-455:
-----------------------------------------
I think what you see is the APK signing block [https://source.android.com/security/apksigning/v2] which sits between all local file headers and the central directory. Commons Compress doesn't know how to parse the block or just to detect it and skip over it.
Unfortunately the block does not start with a signature (but rather ends with it) so it is difficult to know whether what we see is such a block. The block starts with eight bytes holding the length, so we could try to interpret the next eight bytes as a length, skip over a block of that size, see whether we find the "APK Sig Block 42” and call it a day.
In order to have a testcase we probably need a very small apk that is signed and can be distributed as part of our source tree.
> Cannot open certain APK file (Unexpected record signature)
> ----------------------------------------------------------
>
> Key: COMPRESS-455
> URL: https://issues.apache.org/jira/browse/COMPRESS-455
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.17
> Environment: Android 8.1.0
> Reporter: Hai Zhang
> Priority: Major
>
> I'm developing a file manager for Android and noticed that ZipArchiveInputStream throws an exception for certain APK files (but not all) I have at hand:
>
> {noformat}
> 06-12 23:01:03.043 26960-4050/me.zhanghai.android.materialfilemanager W/System.err: java.util.zip.ZipException: Unexpected record signature: 0X621
> 06-12 23:01:03.044 26960-4050/me.zhanghai.android.materialfilemanager W/System.err: at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:258)
> at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:406)
> at me.zhanghai.android.materialfilemanager.filesystem.Archive.readEntries(Archive.java:79)
> at me.zhanghai.android.materialfilemanager.filesystem.Archive.read(Archive.java:36)
> at me.zhanghai.android.materialfilemanager.filesystem.ArchiveFile.loadFileList(ArchiveFile.java:112)
> at me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:32)
> at me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:28)
> at android.os.AsyncTask$2.call(AsyncTask.java:333)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
> at java.lang.Thread.run(Thread.java:764){noformat}
>
> However, these APKs installs fine, and can be viewed by the system Files app (by changing extension to zip) and some other opensource file managers built upon java.util.zip.
> Some links to APKs I found with this problem:
> 1. [https://github.com/paphonb/PixelLauncherModV5/releases/download/5.3_23/Pixel.2.Launcher.modded.5.3.build.23.apk]
> 2. [https://github.com/Yink/Amadeus/releases/download/0.9.6-alpha.5/amadeus.apk]
> My code for reading the APK archive entries:
>
>
> {code:java}
> private static void readEntries(InputStream inputStream, List<ArchiveEntry> entries)
> throws ArchiveException, IOException {
> try (ArchiveInputStream archiveInputStream = sArchiveStreamFactory.createArchiveInputStream(
> new BufferedInputStream(inputStream))) {
> while (true) {
> ArchiveEntry entry = archiveInputStream.getNextEntry();
> if (entry == null) {
> break;
> }
> entries.add(entry);
> }
> }
> }
> {code}
> Also note that if I catch the exception while keeping the list of already-read entries, it seems that (almost) all entries have been read.
> I wonder how this can be fixed, or if this is because those files have some kind of weird format, how can I possibly work around this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)