is there any possible to convert dex2.jar file into classes.dex again without compile.here i sucessfully coverted the apk file to normal java source code using reverse enginerring process.
If your goal is to modify the application, do not modify it at the java level. This will fail for all but the most trivial of projects! Decompilers such as dex2jar, jeb, and enjarify are too low fidelity to trust not to alter behavior (read: break the code).
At best, use a decompiler (like dex2jar) to view the java and understand what you want to change. Then, get the smali disassembly using baksmali and make your changes at the smali level. Finally, use the smali tool to compile it back into a dex file.
It's more difficult, but it's much more likely to be successful. There are lots of guides online for how to modify smali code. It will take a little more time, but it's really the only way.
The 'dx' tool will let you do this.
dx inputfile.jar --output classes.dex
Why don't you want to just run it through the standard compiler, again?
Related
Recently I decompiled some Android APKs with dex2jar, jd-gui and Android studio.
Why can some classes' methods see the source code, and some classes' method can only see /compiled code/?
What's the difference between these two class when compiling?
What's more, I want to do the same compile work to my code to ensure the security. What tools can I look for ?
When Android Studio opens a .class file and cannot decompile the code, it just displays the "compiled code" message. There are lots of things that could prevent a decompilation because a lot of stuff is legal in byte code that is illegal in Java. (For instance, it's perfectly legal byte code to have a method named if or for, but those are Java keywords and cannot be used to name a Java method.) These sorts of things can easily show up when the .class files are processed by ProGuard, and possibly by other tools in the APK build process.
It can be happens because, your JAVA file cannot be readable due to improper bytecode or it may be encrypted. You cannot differentiate correct and incorrect JAVA files type.
Anyways, to properly compile your JAVA file, you can alternatively use Luyten (same as the jd-gui).
Source Link
My server needs to keep building a large amount of Android projects. All of them are almost identical except for minor change on manifest.xml or any resource file (if it's better for the task) for each build. To reduce cost and improve efficiency, I try to implement incremental build. My planned procedures are:
after the first successful build, skip all the previous
procedures (aapt to generate R.java, adle to make java, etc.)
directly call aapt to make resource files, e.g., *.ap_
call apkbuilder to make classes.dex and usigned.apk
make signed.apk
So my question is whether the above solution is possible? And any clue about how to implement it?
This isn't necessarily a solution for your particular requirements but perhaps it will provide you with some useful pointers.
I have an Antlib that I use for building Android projects. You probably won't want to use it yourself as it has some drawbacks, but it should serve as an example of how to perform the various steps to build an Android app using Ant. In particular, it shows how to call the various Android SDK tools from Ant and how to use the Ant uptodate task and Ant's if and unless attributes to avoid processing files that haven't changed.
The source for the Android Ant macros is here (the Antlib documentation might help you to make sense of what it's doing).
There are a few questions on SO about using .jar files in an Android project. But I am wondering if the reverse is possible - is it possible to use .apk files in a Java desktop project?
The reason for this is that I created a Java desktop app for object database management, but it needs the model classes from whichever application database it is looking at. With an object database, you need the model classes to define you database schemas. Side question - forgive me for my ignorance but can you run a runnable .apk in a desktop environment? something like this:
http://www.techday.in/how-to-run-android-apk-apps-on-computer/
Anyway, my goal is to kick off my personal object manager program from an individual android application. So in that case the .apk files would have to be able to talk with .jar files. If that fails, I could try just the opposite - kick off the jar file, and use the -vm argument as a location of the .apk files to put in the classpath. Either way. Which is easier? ---> .apk files in a Java program's classpath or .jar files in an Android program's path? Please, just expound away, I want all your thoughts.
APKs contain DEX files, not Java Classes so you would need to translate from one VM file format DEX Davlik to another. The link you provided is for Bluestack's Android VM which would run a APK as it is running the Android OS. If you want to look up how VirtualBox does things that would be the closest match.
The source for Android projects do use standard JAR files for libraries and class files are generated as part of the build process however once you start to package into something you can put on a Android device/emulator/environment you are in a different world.
However as the DEX file format is open-sourced, what you are trying to do isn't impossible, but it might be easier to use the intermediate class files instead.
I have asked this on android platform, but did not receive a reply.
I have referred to this thread, but could not find what post he was referring to (Dynamically Generating Dalvik Bytecode into a running Dalvik/Android application)
Also, This issue was raised(http://code.google.com/p/android/issues/detail?id=6322)
So, my question is,
has there been any progress in this regard?
Is it possible to inject new bytecode into a class that is being loaded?
if so, any pointers to the same?
Cheers.
Earlence
Android's Dalvik team is intending to create an API that generates dex files at runtime, but we have nothing to show at the moment.
Your best bet today is to use a Java bytecode injection framework (ASM, cglib, etc.) and to include dx.jar (that is, the guts of the dx tool) in your program to convert generated .class files into a .dex file at runtime. If that (hacky) strategy isn't sufficient, you're on your own. This problem is a good opportunity for open source!
You can also check tools like redexer (http://www.cs.umd.edu/projects/PL/redexer/) and smali (https://code.google.com/p/smali/)
I'm trying to modify framework.jar. My purpose is to modify the contents of SQLiteDatabase.java inside this jar. I've googled this quite a lot, and found that the way is to edit the .smali file and repackage and pushing the updated jar to the system. But the source of .smali seems to be hard enough to edit (as it's assembly code), so I was wondering if there's any other workaround to avoid this, and edit the Java source instead and then pushing it to the device. I'd really appreciate some help, thanks.
One possible hybrid approach might be to download a version of AOSP as close to what's used on your device as possible, make the changes you want to SQLiteDatabase.java in the AOSP source, and then build a framework.jar from AOSP, disassemble it with baksmali, and then copy over the SQLiteDatabase.smali from the AOSP build to your device-specific framework.jar.
There's one other kink you should be aware of - If your device is pre-odexed/pre-oated, then you'll need to deodex the entire framework and all pre-odexed/pre-oated apps, because modifying framework.jar will invalidate any existing oat/odex file.