[BUG] Repacked version crashes with SEGFAULT only if sources are decoded

[peret]

Information

1. Apktool Version (apktool -version) - 2.6.1
2. Operating System (Mac, Linux, Windows) - macOS Monterey 12.5.1
3. APK From? (Playstore, ROM, Other) - Development build

Stacktrace/Logcat

Build fingerprint: 'google/redfin/redfin:13/TPB4.220624.005/8812298:user/release-keys'
Revision: 'MP1.0'
ABI: 'arm64'
Timestamp: 2022-10-31 16:37:50.147315281+0100
Process uptime: 10s
Cmdline: com.X.Y
pid: 16528, tid: 16546, name: Thread-3  >>> com.X.Y <<<
uid: 10334
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x0000000000000231
    x0  0000000000000231  x1  000000734d772780  x2  000000734d772780  x3  0000000000000068
    x4  0000000000000020  x5  0000000000000005  x6  0000000000000008  x7  0000000000000002
    x8  0000000000000231  x9  0000000000000000  x10 000000734d218000  x11 000000734d218cd8
    x12 000000003e9e0463  x13 000000734d218ccc  x14 000000734d218cc4  x15 000000734d218ccc
    x16 0000000000000001  x17 000000734d209694  x18 000000701bbac000  x19 0000000047907279
    x20 00000000faae7fba  x21 fffffffff5ce6e68  x22 0000000000000012  x23 000000000000000c
    x24 000000005901cbd7  x25 0000000000000009  x26 000000007dc413fa  x27 0000000000000015
    x28 000000701db6d220  x29 0000000000000231
    lr  0000000000000231  sp  000000701da24b10  pc  0000000000000231  pst 0000000020001000
backtrace:
      #00 pc 0000000000000231  <unknown>

Steps to Reproduce

1. apktool decode
2. apktool build
3. jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -storepass ${PASS} -keystore ${KEYSTORE} ${OUTPUT_DIR}/unaligned.apk key_alias
4. ${ANDROID_HOME}/build-tools/27.0.1/zipalign -f 4 ${OUTPUT_DIR}/unaligned.apk ${OUTPUT_DIR}/aligned.apk
5. ${ANDROID_HOME}/build-tools/27.0.1/apksigner sign --ks ${KEYSTORE} --ks-pass ${PASS} --ks-key-alias key_alias ${OUTPUT_DIR}/aligned.apk

Frameworks

N/A

APK

Unfortunately, I'm not allowed to share the APK :/

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

Hi @iBotPeaches 👋

So, I have this APK that I tried unpacking and repacking. Decoding, building, and installing are no problem, but when I try to start the app, it fails with one of two exceptions. One is the BUS_ADRALN I pasted above. The other one is a SEGFAULT and looks surprisingly similar to the one in this old issue. (Or at least the fault addr 0000002b is the same. Not sure if that means much, I can try to get and paste my other stacktrace as well, if it helps.) The APK includes a lot of native code/libraries and at first I thought that might be related to the issue, but extractNativeLibs is true and using the -p flag to page align .so-files with zipalign doesn't make a difference.

What does make a difference is using --no-src for the decode step! The app starts without issue, when I decode and build without decompiling the dex files. Unfortunately, I need to be able to modify the .smali files, so using this flag is not really an option in my situation.

I'm wondering whether you have seen this before. I realize there is not much to go on, since I can't share the APK here, but if you can give me any pointers on what to look into, that would be extremely helpful.

Thank you, as always!

[iBotPeaches]

Does adb logcat have anything before that crash? Otherwise my guesses are:

• anti-tamper at native layer
• public resources in AndroidManifest.xml that can no longer be public (We use public resources to keep static resIds)

[peret]

There are no other relevant logs as far as I can tell, I will double-check tomorrow though.

Could you please elaborate a little on your second guess? I'm not sure I understand what the problem would be, i.e. what exactly do you mean by resources "that can no longer be public"? Also, how would you determine whether this is indeed the issue, i.e. how would this manifest in the output of decode or the rebuilt APK?

[auermich93]

Did you repackage the APK without modifying the underlying dex code? Decoding and repackaging the APK with or without --no-src shouldn't make any difference IMO, or does smali/baksmali fail during decoding/re-assembling?

[peret]

Did you repackage the APK without modifying the underlying dex code?

Exactly, I did not modify the dex/smali code in any way. Any difference in the dex files is only due to apktool decompiling + recompiling the files.

Decoding and repackaging the APK with or without --no-src shouldn't make any difference IMO, or does smali/baksmali fail during decoding/re-assembling?

Yes, that's what's so weird about it. It shouldn't make a difference, but it does. Decoding and building is not a problem, the app crashes during runtime.

[peret]

Speaking of differences:I can see that there are differences between the binary dex files before and after decompiling+recompiling. I assume some differences are to be expected though?

[auermich93]

I have to double check that first.

[auermich93]

You are right. Using baksmali d and smali a will lead to a different dex file in terms of size (bigger). This applies only the first time, i.e. if you iteratively call the two commands the resulting dex file will be of the same size. I have no idea what it is, but I would guess some sort of optimization that dx/d8 can perform and baksmali is not capable of. @JesusFreke, you know what's going on here?

[RenateUSB]

I've seen that apps with explicit static boolean x = false get turned into static boolean x (with implicit false). The same goes for static int x = 0.

I also see (uncompressed) data getting bigger.