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.
Hi.
I'm trying to hack aapt to generate for each layout named xxx_layout.xml an extra num in R named R.id.xxx_layout_max_id which will contain the max id for that layout (since each id is an in num and each layout has several id's in it i assume one of them is the biggest).
I need it for adding custom components dynamically in runtime but for layouts like RelativeLayout which requires ID's.
Did anyone hacked appt before to know which file in aapt directory contains the code to genereate ids ?
10x.
Please use the Q&A Forum for questions Thanks
Moving to Q&A
I don't mean 12/24 hr format. I mean HH:mm:ss format. I want my status bar clock to display something like 23:59:59, I want the "seconds counter" included. How do I do this? Are there any app that can do this or I need to modify some system files (SystemUI.apk perhaps)? My phone is xperia mini pro (rooted). Thanks.
You would need to edit a bunch of files including xmls and smalis. I have looked and you may need to edit it on a source code level as the entry for the seconds is not present.
Thanks for your feedback. Do I really need to change the source that much? Is it possible to just change the value of the variable containing mm (HH:mm) to "mm:ss".
Ex.
HH=22
mm=39
ss=49
var hour=HH
string a="%mm%:%ss%"
string minute="%a%"
display contents of hour:minute
output = 22:39:49
I'm no programmer.
See that's the problem. The way it is written it just refs time format. Which is buried in the source code.
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 own a note 2 device where I've installed Cyanogenmod (version 11-20140827-nightly-n7100). I've been trying to mod the original stock camera from samsungs firmware (4.4 kitkat) to run on cyanogenmod with some success but now I'm stuck witch a dependency problem I don't know how to resolve and not even why it is possible. So here is a list of what i did, yet:
- using apktool and smali/backsmali to create deodexed SamsungCamera.apk.
- adding the library dependencies mentioned in androidmanifest.xml in the apktool decompiled folder
- searched for LoadLibrary calls in the smali code to find out that seccamera_jni.so is loaded at runtime
problem: the dependency tree of seccamera_jni.so is incompatible with the libs installed on cyanogenmod -> missing symbols for the Camera(->crash) versus missing symbols for the system (bootloop)
sollution: take seccamera_jni.so and all other libs from the stock ROM it (recursively) depends on and rename the files and their internal dependencies to something like lsb**.so instead of lib**.so.
- write a c progam that implements this sollution
- install everything on the phone and fix the permissions
- run SamsungCamera
results: While the described method removes all library not found issues while retaining the original libs of cyanogenmod i still get one f*ing symbol not found error message:
"java.lang.UnsatisfiedLinkError: dlopen failed could not load "lsbnativehelper.so" needed by "libseccamera_jni.so"; caused by [..endless chain leading to libc.so] Missing Symbol __cxa_finalize in lsbdl.so needed by lsbc.so"
I've looked it up: libdl.so has no external dependencies and refers to __cxa_finalize which is implemented in libc.so which has libdl.so as its only dependency.
So my Questions are: How is this possible? I've checked the libc.so integrated in cyanogenmod and even this one has the same dependencies in libc.so but if this was a problem how could any app using libc work on that system? What is different on the stock room that it won't get the missing symbol even though it has the missing dependency? what am I overlooking?