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/)
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
With the advent of ASMDEX (ASM for dex files) and dexmaker, shouldn't it be possible to port Groovy to Android? Both frameworks allow the generation of dex bytecode at runtime.
As I understand it, it is impossible to modify dex classes from the APK in memory. But wouldn't it be possible to copy those classes to writable memory, modify those copies at runtime and use them?
What else needs to be ported to handle dex class files? CGLIB?
The original porting project is named discobot then some guys made a new project called discobot2 Afaik the first project had no runtime transformation of classes, but was able to run first Groovy programs on Android, with a very slow startup time. As for the second project the last to me known state is that they solved most issues and are now translating classes at runtime. But I never tried it out.
Update: since Groovy 2.4 a third version to run Groovy on Android is possible
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?
Is there any documentation for 'dx'?
In particular, I am interested in knowing what the --core-library option does.
What is the 'dx' tool?
The dx tool converts Java class files into a *.dex (Dalvik executable)* file.
Where is it?
The dx.jar file was original located under android-sdk/platforms/android-X/tools/lib/ before (especially in Android 3 and Android 4) and was moved to android-sdk/platform-tools/lib/ later.
How does it fit in Android?
The Java source files are converted to Java class files by the Java compiler.
The dx tool converts Java class files into a *.dex (Dalvik executable)* file. All class files of the application are placed in this .dex file. During this conversion process redundant information in the class files are optimized in the .dex file.
For example, if the same String is found in different class files, the .dex file contains only one reference of this String.
These .dex files are therefore much smaller in size than the corresponding class files.
The .dex file and the resources of an Android project, e.g., the images and XML files, are packed into an .apk (Android Package) file.
To understand better, look at the Android build process:
FYI:
The program AAPT (Android Asset Packaging Tool) performs APK creation.
The resulting .apk file contains all necessary data to run the Android application and can be deployed to an Android device via the ADB (Android device bridge) tool.
Reference
This is a special purpose flag that is only used when building some of the framework JAR files (core.jar, framework.jar, etc.). Normally, dx will refuse to process any java.* or javax.* classes. So this option is used for core.jar, where all those classes are actually defined.
Here's a relevant blurb from the dx source (dalvik/dx/src/com/android/dx/command/dexer/Main.java), that gets printed if you try to include a java.* or javax.* class in an application.
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
The --core-library option on Dx will bypass the stupidity check that prevents you from accidentally including Java core libraries in your Android app.
Dx will barf if you try to include a library that contains packages in the java.* or javax.* namespace. The thinking is that classes in that namespace are likely to depend on other JDK "core" classes, which will break your app since they (may) not be present on Android.
Now, of course, just because a Java package starts with java.* or javax.* does not necessarily mean that it depends on the JDK proper. It may work perfectly fine in Android. The recommendation, if you know what you are doing, if you know that your java/x.* classes don't depend on JDK core classes, is to use a tool like JarJar to repackage the JAR file under a different namespace.
That being said, to get around the stupidity check, add the --core-library option to dx. Change the last line of $ANDROID_HOME/platform-tools/dx from,
exec java $javaOpts -jar "$jarpath" "$#"
to,
exec java $javaOpts -jar "$jarpath" --core-library "$#"
In my case, I was including a library that depended on Jackson, which depends on JAXB. For me, overriding the stupidity check was acceptable because the library's use of Jackson was only for JSON and not for XML serialization (I only include the JAXB API library, not the implementation). of course I wish there was a cleaner way to go about this, but rewriting the top-level library to avoid using Jackson was not an option.
I am trying to use a third party jar file within an Android application. I have been able to use some of the classes in the jar file just fine. However, one of the classes references some Java classes that don't appear to be supported by the dalvik vm. These are some of the errors I am seeing in LogCat:
Unable to find class referenced in signature java/beans/PropertyDescriptor.
Unable to resolve virtual method java/beans/PropertyDescriptor.getName().
Unable to resolve virtual method java/beans/PropertyDescriptor.getReadMethod().
Unable to resolve static method java/beans/Introspector.getBeanInfo().
Unable to resolve exception class java/beans/IntrospectionException.
It appears that Java classes related to introspection and reflection are not supported by dalvik. I would like to find out two things. Is that a plan to support this in dalvik in the near future? Secondly, does anyone have a suggestion for a work around that would get around this problem?
It appears that Java classes related to introspection and reflection are not supported by dalvik.
Not on a blanket basis, AFAIK. One objective of the core Android team is to keep the firmware small, to reduce the cost of devices. One side-effect of this is to only include classes from java.* and javax.* that they feel are essential. Originally, none of java.beans.* existed in Android; now, a few classes and interfaces are available, but not the whole package.
Is that a plan to support this in dalvik in the near future?
You will know when the rest of us know, which is to say, only if it shows up in a release.
Secondly, does anyone have a suggestion for a work around that would get around this problem?
If the third-party JAR is an open source project:
Grab the necessary java.beans classes from Apache Harmony and put them in your project
Refactor them into a separate package (e.g., bondy.beans), since Android will not like it much if you try loading java.beans classes into your project
Modify the third-party JAR to use your refactored edition of the classes
It is possible that jarjar can do something about this as well -- I have not yet used the tool and do not know the extent of its capabilities.
Apache harmony is retired for a long time now. I am using openbeans. And it solves all the problem for me.