[BUG] Camera APK has assets/obfu_res/res files which are real ones and dummy ones in res, failed to open app
Information
-
Apktool Version (
apktool -version) - 2.9.2 (whatever latest snapshot ongoing) - Operating System (Mac, Linux, Windows) - Linux
- APK From? (Playstore, ROM, Other) - ROM
-
Java Version (
java --version) - 21.0.1
Stacktrace/Logcat
Camera crashes, or misses many modes
Steps to Reproduce
-
apktool d MiuiCam.apk
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): Link of app and frameworks: https://drive.google.com/drive/folders/1lOKwBOKVR6S8D2mjADuYDNykUUIYX81M?usp=sharing
This app has some issues in decompiling, there is assets/obfu_res/res folder with drawables obfuscated names which are real ones, and dummy ones are placed for same name under apk/res/ which ofcourse wont work on repack.
Also there are issues with .9.png patch, i can see such extension files in apk/res folder but on decompile, all drawables of .9.png extension changed to .png only, which break many things i guess!
Also, is this normal? W: Could not find 9patch chunk in file: "aLb.9.png". Renaming it to *.png.
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
Nothing to do with Apktool. It's a proprietary Xiaomi encryption using a specific encryption key embedded in a native library. The lists of encrypted resources are stored as array resources with minified names that change every new app version.
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
Nothing to do with Apktool. It's a proprietary Xiaomi encryption using a specific encryption key embedded in a native library. The lists of encrypted resources are stored as array resources with minified names that change every new app version.
i know all that, i have analyzed and wrote a little script afterwards to fix that, whatever way Xiaomi decode it, but those can be replaced in real res/ and decodes well. apktools just have to replace them based on real/dummy res and decode the replaced one instead of dummy, seems not a big work, may be 3 lines of java code ;)
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
Nothing to do with Apktool. It's a proprietary Xiaomi encryption using a specific encryption key embedded in a native library. The lists of encrypted resources are stored as array resources with minified names that change every new app version.
i know all that, i have analyzed and wrote a little script afterwards to fix that, whatever way Xiaomi decode it, but those can be replaced in real res/ and decodes well. apktools just have to replace them based on real/dummy res and decode the replaced one instead of dummy, seems not a big work, may be 3 lines of java code ;)
Well, you report this as if it's a bug. It isn't. It's a custom behavior you can add to your own Apktool fork. Apktool can't make assumptions whether something is encrypted or not.
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
Nothing to do with Apktool. It's a proprietary Xiaomi encryption using a specific encryption key embedded in a native library. The lists of encrypted resources are stored as array resources with minified names that change every new app version.
i know all that, i have analyzed and wrote a little script afterwards to fix that, whatever way Xiaomi decode it, but those can be replaced in real res/ and decodes well. apktools just have to replace them based on real/dummy res and decode the replaced one instead of dummy, seems not a big work, may be 3 lines of java code ;)
Well, you report this as if it's a bug. It isn't. It's a custom behavior you can add to your own Apktool fork. Apktool can't make assumptions whether something is encrypted or not.
i said all that just because i saw apktool can decode apks which are encrypted by apkeditor tool, if thats the case, why not check stuff like this also? i did some after-patch thing but will be awesome if apktool do that by default, there is no assumptions thing, its name even telling what it does
You'll have to make your own tool to decrypt the resources in obfu_res, and also certain string resources that are stored encrypted. This is a special case limited to certain versions of Xiaomi's MiuiCamera.
well, i did already but shared here so if a tool can automatically adapt that, since it decode many other encoded apps too, anyways
Nothing to do with Apktool. It's a proprietary Xiaomi encryption using a specific encryption key embedded in a native library. The lists of encrypted resources are stored as array resources with minified names that change every new app version.
i know all that, i have analyzed and wrote a little script afterwards to fix that, whatever way Xiaomi decode it, but those can be replaced in real res/ and decodes well. apktools just have to replace them based on real/dummy res and decode the replaced one instead of dummy, seems not a big work, may be 3 lines of java code ;)
Well, you report this as if it's a bug. It isn't. It's a custom behavior you can add to your own Apktool fork. Apktool can't make assumptions whether something is encrypted or not.
i said all that just because i saw apktool can decode apks which are encrypted by apkeditor tool, if thats the case, why not check stuff like this also? i did some after-patch thing but will be awesome if apktool do that by default, there is no assumptions thing, its name even telling what it does
- Nothing is encrypted by apkeditor. Obfuscated and encrypted are two entirely different concepts.
- Apktool can only decode some basic forms of obfuscation by apkeditor, not obfuscated resource type names, for instance.
- obfu_res (which contains encrypted files, not obfuscated) is not the only kind of encrypted resource. Many strings are also encrypted.
- Like I said, names of arrays with IDs of encrypted resources are minified and cannot be determined with Apktool, they are not constant.
I can keep adding more reasons but there's no point.
- Nothing is encrypted by apkeditor. Obfuscated and encrypted are two entirely different concepts.
- Apktool can only decode some basic forms of obfuscation by apkeditor, not obfuscated resource type names, for instance.
- obfu_res (which contains encrypted files, not obfuscated) is not the only kind of encrypted resource. Many strings are also encrypted.
- Like I said, names of arrays with IDs of encrypted resources are minified and cannot be determined with Apktool, they are not constant.
I can keep adding more reasons but there's no point.
well, i saw that app already so i know whats going on, libresource_loader decrypting those resources at runtime and getting real ones, anyways, not a big issue :)