Basically I want to be able to decompile apks. And jar files directly on my phone. Can I do that?
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Sweet, thanks for your input. I was out last night and I had this idea for an edit to make, only to become sad because I didn't have access to a computer.
This will help me out a lot.
JesusFreke said:
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Click to expand...
Click to collapse
The problem seems to be within the buildprocess as the generated classes for baksmali and smali are added twice to the *-dev-jar-with-dependencies.jar. As I'm not familar with maven I didn't fixed the source of the error but I managed to get it working.
I attached a small pythonscript which is able to remove the dublicated files within the jar. Just run it over the file and get a fixed version which is processable by dx.
The script:
Code:
#!/usr/bin/python
import sys
from zipfile import *
if len(sys.argv) != 3:
print("Usage: %s input.jar output.jar" % sys.argv[0]);
sys.exit(-1)
input = ZipFile(sys.argv[1], "r")
output = ZipFile(sys.argv[2], "w")
seen = []
for file in input.namelist():
if file not in seen:
output.writestr(file, input.read(file))
seen.append(file)
else:
print("dub found: %s" % file)
input.close()
output.close()
sorry ...
Wrong place
JesusFreke said:
Yes, you can. At least, for the most part. The main constraining factor is the small amount of memory available on the device.
1. run the dx util on baksmali.jar, to produce a classes.dex file
2. add the classes.dex file to a new jar (or you can just add it to baksmali.jar)
3. push the jar containing classes.dex to the device somewhere (let's say /data/local/baksmali.jar)
4. dalvikvm -classpath /data/local/baksmali.jar org.jf.baksmali.baksmali <normal baksmali options>
5. bonus points if you then proceded to run baksmali on baksmali.jar (and then the universe implodes)
note: I just tried this with the latest version of baksmali, and there's some weird issue with the baksmali jar file, where it contains duplicate entries of every class file, which causes dx to choke on it. I'll see if I can get that fixed soon, and get a new build out. In the meantime, you can probably find an older version without that problem.
Click to expand...
Click to collapse
I realize this is a very old thread, but it is exactly what I am looking for However, it seems there are Java 8 features in smali/baksmali now and dx does not work. Is there a workaround for this or any other way to run smali/baksmali from terminal on Android? Thanks!
The older versions of smali may still work for you. Or what I've done is use Termux and download the jdk for arm64 and used the ndk to compile smali on my device.
Delgoth said:
The older versions of smali may still work for you. Or what I've done is use Termux and download the jdk for arm64 and used the ndk to compile smali on my device.
Click to expand...
Click to collapse
Thanks for the reply
However, I am not trying to compile smali on my device. I am trying to run the latest smali/baksmali on my device in Termux. Unfortunately, the older versions will not work for my needs. If you can help I would really appreciate it
But compiling the latest build of small on the device will allow you to use the latest build of smali.
Hello !!!
I'm not a real developper but I manage to make a little tool FOR DEVS to accelerate java src decompile
I don't know if it can be useful, but I wanted to share it ...
I don't really create something, all the tools already exist, you know them all :
JD-GUI : Java decompiler
Dex2jar : useful tool to transform .dex in readable .jar to get java src
Why did I made this ?
I searched how to get java src, useful to build apk or even compile sources, but only found manual way.
Ok decompiling one or 2 files is not a big deal ... but when you need to decompile a whole rom ......
What can this tool do ?
getting the java src from an apk and / or a .jar (framework.jar for eg) dex2jar and jd-gui already allow it
can decompile several files (.jar and or .apk)
rename each file to is native name
How to use it ?
This tool only works on Linux
Download attached zip or here
Unzip the file in home folder The folder must be in home and musn't be renamed or it won't work properly
launch the dex.sh (double click in graphic or use ./dex.sh commande in terminal)
Follow the instructions
.classes files need to be associated to JD-GUI use this programm. If you don't know if they already are or not, don't worry let the command do it ...
For more information, I included lines to make .jar files open by JD-GUI.
If you don't need / want these files to be associated after you use this tool type in terminal
PHP:
cd ~/.gnome2/nautilus-scripts
sudo rm open-in-jd-gui.sh
This tool is not perfect ... firstly I made it for me ....but finally wanted to share it ...
if you like it just tell me and use it ... if you don't .... ok just tell me why I would improve it ...
Huge thanks to :
JD-GUI Developpers : http://java.decompiler.free.fr/?q=jdgui
DEX2JAR Developpers : http://code.google.com/p/dex2jar/
tommytomatoe : for his wonderful Android Utility and for the command lines that helped me more than a lot !!! :good:
this is really useful
especially to decompile stock sony jar/apk to port some java classes from their frameworks
@Tof37
Bro, please reupload file, link is down
Thanks
EDIT:
sorry, i am dumb. THX a lot!
Hi guys,
Sorry in advance if I posted this to the wrong place as I am not allowed to post into Android devs-only forum.
I am currently investigating the extra fields flaw in apk signature verification discovered in juli 2013 by trying to replicate it on the AVD.
First of all...this is research only as I am trying to understand my system's internals and especially permissions handling.
What i try to achieve is to root the AVD by using the elevated permissions of a apk signed with the platform key.
1. I have an apk signed with the platform key from my cyanogenmod 10.2 device and a classes.dex with size under 65k that will try to install SuperSU on my AVD
2. When creating a new apk I put the original classes.dex into the extras field of the corresponding ZIP entry and pad it to have a size of 65533
3. The rooting classes.dex goes into the data field of the ZIP entry and extra lengh is set to 65533 or -3 as seen by the buggy verifier. This classes.dex is also padded to have the exact size of the original classes.dex
4. My MainActivity tries to install the just assembled apk
Expected result: As the verifier is validating the original classes by jumping 3 backwards instead of 65533 forward the apk should be installed having elevated system privileges.
Actual result: AVD refuses installation of the apk with error code -103 as the "digest of classes.dex does not match those in the apk".
My thoughts on what may cause this:
A) I know that google merged the fix for this bug into HEAD but it still should work on AVD 2.3 and 4.1.
Or are all versions of AVD patched agains extras field expliotation? As I update my APIs everyday the fix is likely to be in my AVD.
Correct me if i am wrong.
B) As I use a cyanogenmod 10.2 apk as the base the platform keys may not match those of the AVD.
If so the error should be different to -103 but something like "system user signature does not match"
Please would someone point me into the right direction?
Hi,
I have a signed jar that cannot be allowed to be modified.
By adding it to the /libs folder in Android Studio, when the app is built into an .apk because of it (the .jar) being included in classes.dex the checksum changes and the jar's classes will crash.
Is there a way to import a jar into a project and ensure it does not get obfuscated/compressed/changed etc or kept outside of classes.dex and able to run the apk without problems?
I would have added it to the developers forum but I have a low post count.
Thanks in advance.
Given that I have root and custom ROM/recovery?
There is an apk from the different ROM thus different signatures, and the phone's package installer doesn't want to install this apk, same as "adb install" command.
adb: failed to install samsung_service_mode_10.apk: Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Reconciliation failed...: Reconcile failed: Package com.sec.android.app.servicemodeapp has no signatures that match those in shared user android.uid.system; ignoring!]
Click to expand...
Click to collapse
Will I brick my phone if I simply rename this .apk to .zip and flash it with TWRP?
Why not to sign the APK using the apksigner tool by yourself?
because it requires downloading thousands of megabytes of Android SDK and learning how to use it.
I would prefer a simpler way like "adb install --force", if possible.
The err msg " INSTALL_FAILED_SHARED_USER_INCOMPATIBLE" triggered by ADB really has NOTHING to with fact whether APK is signed or not.
> dat laughing smiley
I'm glad that you have an optic fibre with unlimited 1Gbps connection at home, however some people on our planet still reside on slow Internet connections with limited traffic, and downloading
android-studio-ide-202.7486908-linux.tar.gz 950 MiB
Click to expand...
Click to collapse
with
Google Maven dependencies 2724 MB
Click to expand...
Click to collapse
will take many hours and $$$s in traffic cost.
jwoegerbauer said:
The err msg " INSTALL_FAILED_SHARED_USER_INCOMPATIBLE" triggered by ADB really has NOTHING to with fact whether APK is signed or not.
Click to expand...
Click to collapse
thanks for pointing that out! I've googled for the second part of the error - "has no signatures that match those in shared user android.uid.system" instead of the first part, and that lead me to the wrong conclusions.
So the fix was relatively simple - download apktool.jar and signapk.jar (no need to download full 3 GBs of Studio stuff), decompile the app with apktool, delete the "android.uid.system" part from the manifest file, compile app back and sign it with signapk.jar using the stock AOSP platform keys.
However in my particular case that did not work because an app requires Samsung libs absent on my device:
adb: failed to install samsung_service_mode_10_EDIT_signed.apk: Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY: Reconciliation failed...: Reconcile failed: Package com.sec.android.app.servicemodeapp requires unavailable shared library sec_platform_library; failing!]
Click to expand...
Click to collapse
P.S. few links for the future self:
apktool.jar:
Apktool - A tool for reverse engineering 3rd party, closed, binary Android apps.
Apktool - A tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications
ibotpeaches.github.io
signapk.jar: (NOTE: use Java 8!)
SignApk/signapk.jar at master · techexpertize/SignApk
SignApk is used to sign the apk file after repack. The easiest way ever. - SignApk/signapk.jar at master · techexpertize/SignApk
github.com
AOSP stock keys:
platform_build/shared.x509.pem at master · aosp-mirror/platform_build
Contribute to aosp-mirror/platform_build development by creating an account on GitHub.
github.com
platform_build/shared.pk8 at master · aosp-mirror/platform_build
Contribute to aosp-mirror/platform_build development by creating an account on GitHub.
github.com