Firmware and Hacking
Let’s say you want to access the application shared preferences in /data/data/com.mypackage.
You could try to run
adb shell and then
adb shell run-as com.mypackge ls /data/data/com.mypackage/shared_prefs),
but on a production release app downloaded from an app store you’re most likely to see:
run-as: Package 'com.mypackage' is not debuggable
adb backup command will pull many of the files from the application’s data directory,
the files can be inconsistent with what is actually on the device. If you want to see what is
actually on the device, you need to make the application debuggable.
For this task, we’ll need
apktool ( http://ibotpeaches.github.io/Apktool/ ). Once you have it setup,
you’ll need to find the path to the APK to pull it off the device. Run:
$ adb shell pm list packages -f -3
Find the package in the list (it should look something like
and pull it off the device:
$ adb pull /data/app/com.mypackage.apk
Next, we need to disassemble the apk using
$ apktool d -o output-dir com.mypackage.apk
AndroidManifest.xml and open it up in the text editor of your choice.
application xml node, add the following xml attribute:
Now we need to reassemble the application. We do this by running:
$ apktool b -o com.mypackge.apk output-dir
Finally, we need to resign the APK so that the device will accept it:
$ keytool -genkey -v -keystore resign.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000 $ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore resign.keystore com.mypackage.apk alias_name
That’s it! You should now be able to transfer the new com.mypackage.apk back to the device and run it.
Now you should be able to run
adb shell run-as ls /data/data/com.mypackage/ without getting the debuggable error.