Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ext2rd seems make apex in system.img fail to unzip #13

Open
butterl opened this issue Aug 2, 2021 · 2 comments
Open

ext2rd seems make apex in system.img fail to unzip #13

butterl opened this issue Aug 2, 2021 · 2 comments

Comments

@butterl
Copy link

butterl commented Aug 2, 2021

Hi,
Thanks for sharing this great tool for rom analysing !
I meet one thing that, after I run the ext2rd system_ext.img ./:savedir there is no error show and the jar file in system image is good to unzip.

the system.img in the test below is from https://dl.google.com/developers/android/sc/images/factory/coral-spb3.210618.016-factory-b1598d08.zip

file system.img
system.img: Android sparse image, version: 1.0, Total of 204832 4096-byte output blocks in 21 input chunks.

file system_ext.img
system_ext.img: Linux rev 1.0 ext2 filesystem data, UUID=ac16ea36-9e78-5adc-92ff-3e6fd0ccedcc (extents) (large files) (huge files)

When it comes to file under system/apex/ , the unzip is not success,seems all the apex file are broken

savedir/system/apex$ unzip -l com.android.appsearch.apex
Archive:  com.android.appsearch.apex
error [com.android.appsearch.apex]:  missing 32768 bytes in zipfile
  (attempting to process anyway)
  Length      Date    Time    Name
---------  ---------- -----   ----
      761  2009-01-01 00:00   apex_build_info.pb
       29  2009-01-01 00:00   apex_manifest.pb
  1355776  2009-01-01 00:00   apex_payload.img
     1032  2009-01-01 00:00   apex_pubkey
     1359  2009-01-01 00:00   assets/NOTICE.html.gz
       40  2009-01-01 00:00   resources.arsc
     1340  2009-01-01 00:00   AndroidManifest.xml
       32  2009-01-01 00:00   stamp-cert-sha256
      868  2009-01-01 00:00   META-INF/CERT.SF
     2244  2009-01-01 00:00   META-INF/CERT.RSA
      733  2009-01-01 00:00   META-INF/MANIFEST.MF
---------                     -------
  1364214                     11 files

while the jar xvf com.android.appsearch.apex returns

savedir/system/apex$ jar xvf com.android.appsearch.apex
extracted: apex_build_info.pb
extracted: apex_manifest.pb
java.util.zip.ZipException: invalid entry CRC (expected 0xdb6c7410 but got 0x2c51a2fa)
        at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:222)
        at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
        at jdk.jartool/sun.tools.jar.Main.copy(Main.java:1249)
        at jdk.jartool/sun.tools.jar.Main.copy(Main.java:1277)
        at jdk.jartool/sun.tools.jar.Main.extractFile(Main.java:1454)
        at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1364)
        at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
        at jdk.jartool/sun.tools.jar.Main.main(Main.java:1681)

I tried several system image including the newest android-s-beta 3.1 , the result seems same, all apex file is croupted while the other jar file is good to unzip.

Any idea if some log I could help to catch to debug this ? the tool build is using the HEAD version.

@butterl
Copy link
Author

butterl commented Aug 2, 2021

more information find in test

I tried pull out the apex file from phone with same apex and compare two files, it seems that the ext2rd exacted apex file added more 00 after the end of apex file ( should be zip structure in the end ), while the same size 00 is before AVB0 tag in the phone pulled apex filed

the AVB0 tag copied

41 56 42 30 00 00 00 01 00 00 00 00 00 00 00 00 00 00 02 40 00 00 00 00 00 00 05 80 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00 00 00 00 00 02 00 00 00 00 00 00 00 01 40 00 00 00 00 00 00 04 08 00 00 00 00 00 00 05 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 76 62 74 6F 6F 6C 20 31 2E 32 2E 30

after move those 00 in the end to before AVB0 , the zip is good to open, not sure if some code in ext2rd makes this wrong?

@nlitsme
Copy link
Owner

nlitsme commented Aug 14, 2021

I think the problem is that ext4 filesytem support is known to be broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants