search

iBotPeaches / Apktool

A tool for reverse engineering Android apk files
https://apktool.org/
Apache License 2.0
19.79k stars 3.56k forks source link

[BUG] Native library not found on android pie #2490

Open blackfa1con opened 3 years ago

blackfa1con commented 3 years ago

Information

  1. Apktool Version (2.5.0) -
  2. Operating System (Linux, Windows) -
  3. APK From? (Other) -

Stacktrace/Logcat

2021-01-01 16:25:05.626 3760-3760/? E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.xxx.xxxx, PID: 3760
    java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/priv-app/xxxx/xxxxx.apk!/lib/arm64-v8a/xxxxx.so" not found
        at java.lang.Runtime.loadLibrary0(Runtime.java:1016)
        at java.lang.System.loadLibrary(System.java:1669)

Steps to Reproduce

  1. apktool
  2. Unpack the Original apk.
  3. Repack the apk and resign it.

Diagnose the problem

  1. Use apk tool (last version) and unpack then repack and sign without edit files.
  2. Diagnosis the problem.
  3. We find that the order when packing files into apk is important.
  4. When open the original apk by hex we see the first file in package is classes.
  5. When open the repacked apk by hex we see the first file in package is resources. original

repacked

Frameworks

If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files (.apks that live in /system/framework or /system/priv-app)

APK

If this APK can be freely shared, please upload/attach a link to it.

Questions to ask before submission

  1. Have you tried apktool d, apktool b without changing anything? yes
  2. If you are trying to install a modified apk, did you resign it? yes
  3. Are you using the latest apktool version? yes
iBotPeaches commented 3 years ago

We find that the order when packing files into apk is important.

How did you come to this conclusion? We leverage aapt/aapt2 to package the application and if order mattered - it would do it.

blackfa1con commented 3 years ago

We find that the order when packing files into apk is important.

How did you come to this conclusion? We leverage aapt/aapt2 to package the application and if order mattered - it would do it.

When i resign the package only in windows, this break the native lib and the system give the error "dlopen failed". then i moved to linux and used the apksigner, the error doesn't appear.

After compare the two files, original and resigned package i see the order difference. Anyway i try to use apktool in linux, without resign package, the error back again and i can't use the new package after resign with apksigner/linux.

Comnir commented 3 years ago

@blackfa1con , maybe it's related to extractNativeLibs in AndroidManifest.xml? It is set to "false" by default since Android Gradle plugin 3.6.0. If it's compressed by Apktool, it might be related.

But you also say "When i resign the package only in windows, this break the native lib", so it means this problem occurs also without Apktool being involved?

pashamcr commented 3 years ago

@blackfa1con this is not an apktool bug 1) The application is not installed correctly in /system/priv-app, the native library can be put next to it, i.e. So: /system/priv-app/xxxx/lib/arm64/xxxxx.so 2) The application is not compiled correctly for installation in /system/priv-app, add to apktool.yml:

doNotCompress:
- lib/arm64-v8a/xxxxx.so

in addition, it is desirable to include classes.dex here