I have built a flutter apk in release mode and I would like to test if my app is really obfuscated and my code cannot be read. So I tried to decompile the apk using the APK Decompiler.
I had many files after decompiling. The question now is: What is the file that contains the source code and how do I know if it can be read or not?
I have some doubt on libapp.so, is it?
I confirmed my doubt when I was to able to open the libapp.so (shared object) file using Ghex and I have found some words of my code (like text and some style proprieties) but the source code is really obfuscated and it cannot be simply read.
Related
Background info
When uploading an app to the play store that uses a native library its necessary to also upload the native debug symbols to get useful crash/ANR info.
If you upload without symbols you receive the following warning: "This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug."
In the past when uploading apps as .apk files it was necessary to manually upload such debug info. Now using .aab if the native library is built via android studio its possible to set android.defaultConfig.ndk.debugSymbolLevel = 'FULL' at which point when you build a the .aab it will include the debug info automatically, you upload this single file and everything is done/working.
pre-built libraries
However its not always possible/ideal/necessary to build a library inside android studio. Sometimes there are reasons for libraries to be externally pre-built and just used by android studio not built by it; Android studio supports this via a directory structure which is described here https://developer.android.com/studio/projects/gradle-external-native-builds#jniLibs
In short you just copy the libraries into the correct src/main/jniLibs/{ABI} path(s) and it is picked up and made part of the bundle.
Problem
Android studio can build a .aab that contains debug info that play store can understand so that you don't need to upload it manually.
Android studio can use pre built native libraries if you place them in the right path structure
I am unable to find any documentation or way to do both of these things together, use native pre-built libraries but include their debug info in the .aab. Even though logically it should be possible to do this.
I have searched everywhere I think but can't find anyone even talking about this really, how/where do you place the corresponding debug information so that that also can be included as part of the .aab? Is there a separate path for this, do they just need a specific file extension, does gradle need to be told what to do with them somehow?
Is it really just not possible?
Things I have tried:
Don't split the debug info just leave them in the .so files - play store does not strip them then so you deliver giant debug versions of your builds to your users
Split the debug info into files with .so.dbg extension and place them alongside the .so files - they aren't included in the .aab
Following the instructions (here https://support.google.com/googleplay/android-developer/answer/9848633 and elsewhere) to manually zip and upload the symbols after uploading the .aab - this appears to work but isn't the same convenience wise as having them in the .aab
I've tried building a sample app with android studio building a lib instead of using a pre-built lib just to verify that it does then include the debug info and what file extension it uses.
After some more digging I found the task responsible for this is "ExtractNativeDebugMetadataTask" with which some effort can likely be tailored/altered to do custom things here.
However this ended up being unnecessary as while digging into this I discovered that it actually already works.
At least as of now in latest gradle versions (not sure about the past).
It was only failing due to some NDK path confusion which doesn't fail the build/creation of the bundle building but just logs an easy to miss informational message.
Ultimately all you need to do to make this work is:
Build your external .so files with -g -g3 or similar
Do not strip them in any way
Place them in jniLibs directory structure un-stripped
Configure your build.gradle appropriately android{ ndk { debugSymbolLevel 'FULL' } ndkPath "$projectDir/path/to/NDK" }
Resulting .aab will contain the stripped .so files and the split-debug .so.dbg files all in the right location.
I just recently extracted source code of an apk from playstore. When I opened the source code all the function names, variable names were renamed with some random numbers and letters.
So does playstore does that automatically when we upload our apk?
If not then how can I do that in android studio?
thats Proguard feature, check this doc: Shrink, obfuscate, and optimize your app
when you use it then your code will be obfuscated for harder reverse engineering (besides some optimisation). you have to enable this feature in your gradle file (minifyEnabled), some same how to declare under link above
So does playstore does that automatically when we upload our apk?
-no it was done by some other application
the application you unpacked was previously obfuscated.
you can read more about this here:
https://en.wikipedia.org/wiki/Obfuscation_(software)
Java obfuscator
https://www.preemptive.com/products/jsdefender?gclid=EAIaIQobChMI4bXBqZn48AIVbxitBh1OyQnqEAAYASAAEgJ_XPD_BwE
I created ios and android apps, so now i have to deliver to my customer in IPA and APK file formate.
I want to know, is it possible for them to extract the ipa and apk files and get into my main codes ?
Friends please educate me. Thanks guys.
For android,
Consider enabling your ProGuard
ProGuard obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names which make the code base, smaller and more efficient. The result is a smaller sized .apk file that is more difficult to reverse engineer.
to enable proguard
set minifyEnabled to true and add rules you need on proguard-rules.pro file.
Useful reference
https://developer.android.com/studio/build/shrink-code
For iOS
I don't think there is an easy way to reverse engineer an ipa file
Seem like they can get your code from your APK file (Android) and IPA file (iOS). (I'm not trying it, just for consult)
For android, the answer can be found here
Is there a way to get the source code from an APK file?
For iOS
https://reverseengineering.stackexchange.com/questions/1594/possibilities-for-reverse-engineering-an-ipa-file-to-its-source
I have seen that there are decompilers that works pretty well to show on fly code and resources of compiled APK.
I'm wondering if there is a way to edit and rebuild APK classes without export all sources and resources recreating a new project manually adding all libraries resources code etc. Since the APK already contains all the needed dependencies and resources configured to work together should be possible.
Often there are apps that have small bugs that would be easy to fix if only was possible edit and rebuild APK on fly
You can use Virtuous Ten Studio that allows you to import an APK edit smali code and resources and rebuild the edited version of the APK.
(You can also configure it to show Java code but since uses a "smali to Java" approach the generated code is imperfect.)
https://ibotpeaches.github.io/Apktool/
You can use Apktools to extract and compress APK-files
It is possible to manage/edit Smali files. They are similar to Java-files.
I can open apk, but can`t see files . Why ?
Normally, would be seen xml files, manifest file and so on , but all can i see are question marks and bars.
Text Wrangler is code editor used for mac.
Although Java is normally an interpreted language, the architecture of android is set up to compile the code you write when generating the .apk. Basically, the .apk does not contain your source code, only your compiled code.