[jira] [Comment Edited] (COMPRESS-562) ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds

["Peter Lee (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266536#comment-17266536 ] 

Peter Lee edited comment on COMPRESS-562 at 1/16/21, 9:45 AM:
--------------------------------------------------------------

Disclaimer : not familiar with zpk

I checked the apk file(test-services-1.1.0.apk) and found something strange :

There are 237 bytes of zero before the actual apk signing block.

!apk.PNG!

These redundant bytes of zero broke the read of apk signing block - that's why we are throwing the unexpected record signature exception. And I can successfully read this apk file with these bytes removed.

Accoarding to the [apk signing block specification|[https://source.android.com/security/apksigning/v2],] these bytes are not mentioned. Please feel free to tell me if they are reasonable.

 

In short words, I believe the apk file is corrupted and could not be successfully read using ZipArchiveInputStream(but can be read with ZipFile).

 

BTW : Why java standard zip(ZipInputStream) can successfully read this apk?

I check the code of ZipInputStream and found they didn't check if a Central Directory File or APK signing block is met. They simply return null if the signature is not the one of Local File Header. That's why they didn't report any exceptions.

See also : [ZipInputStream in OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]


was (Author: peterlee):
Disclaimer : not familiar with zpk

I checked the apk file(test-services-1.1.0.apk) and found something strange :

There are 237 bytes of zero before the actual apk signing block.

!apk.PNG!

These redundant bytes of zero broke the read of apk signing block - that's why we are throwing the unexpected record signature exception. And I can successfully read this apk file with these bytes removed.

Accoarding to the [apk signing block specification|[https://source.android.com/security/apksigning/v2] ,|https://source.android.com/security/apksigning/v2],]these bytes are not mentioned. Please feel free to tell me if they are reasonable.

 

In short words, I believe the apk file is corrupted and could not be successfully read using ZipArchiveInputStream(but can be read with ZipFile).

 

BTW : Why java standard zip(ZipInputStream) can successfully read this apk?

I check the code of ZipInputStream and found they didn't check if a Central Directory File or APK signing block is met. They simply return null if the signature is not the one of Local File Header. That's why they didn't report any exceptions.

See also : [ZipInputStream in OpenJDK|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L284]

> ZipArchiveInputStream fails with unexpected record signature while ZipInputStream from java.util.zip succeeds
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-562
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-562
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.20
>         Environment: Zip 3.0 (July 5th 2008), by Info-ZIP, Compiled with gcc 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X) on Feb 22 2019.
> osx 10.14.6, AdoptOpenJDK 11.0.7
>            Reporter: Oleksii Khomchenko
>            Priority: Major
>         Attachments: apk.PNG, test-services-1.1.0.apk
>
>
> Thank you a lot for the library.
>  
> I recently encountered next issue:
> {code:java}
> Exception in thread "main" java.util.zip.ZipException: Unexpected record signature: 0X0
> {code}
> is thrown when reading test-services-1.1.0.apk from [https://maven.google.com/web/index.html?q=test-ser#androidx.test.services:test-services:1.1.0] via commons-compress:1.20 while java.util.zip reads it without the exception.
>  
> {code:java}
> public class UnzipTestServicesSample {
>     public static void main(String[] args) throws Exception {
>         Path p = Paths.get("test-services-1.1.0.apk");
>         System.out.println("\n=== java std zip ===\n");
>         try (InputStream is = Files.newInputStream(p); ZipInputStream zis = new ZipInputStream(is)) {
>             ZipEntry entry;
>             while ((entry = zis.getNextEntry()) != null) {
>                 System.out.println("entry: " + entry.getName());
>             }
>         }
>         System.out.println("\n=== apache compress zip ===\n");
>         try (InputStream is = Files.newInputStream(p); ArchiveInputStream ais = new ZipArchiveInputStream(is)) {
>             ArchiveEntry entry;
>             while ((entry = ais.getNextEntry()) != null) {
>                 System.out.println("entry: " + entry.getName());
>             }
>         }
>     }
> }{code}
>  
> zip -T says that archive is fine:
>  
> {code:java}
> $ zip -T test-services-1.1.0.apk 
> test of test-services-1.1.0.apk OK{code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)