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
Related
We are using android-maven-plugin to build a multidex application targeting Jelly Bean (4.3.x) with greater than 65k methods. The approach described here helps create a MainDexList.txt file, but does not automatically include classes that will be loaded by reflection.
Are any tools or processes available that can create a MainDexList.txt file with reflection support? [The majority of the classes we are loading via reflection are named via String constants...]
We are attempting to avoid manually running the app and dealing with NoClassDefFoundError messages one at a time.
To deal with the NoClassDefFoundError, you just need to add the MainDexList.txt to each of your projects. This should solve your initial errors right away. However, since your MainDexList.txt will still be empty, you will run into further issues.
To load the MainDexList.txt with a script instead of doing it manually, you can use this open source script by Google which will generate the exact class names that should be included in MainDexList.txt. Here is a link to the actual commit by Google:
https://android.googlesource.com/platform/dalvik/+/2bb6fe45bf620525ba34bd7303d7ecb597aa0689
To learn more (and also my source of information):
http://blog.osom.info/2014/10/generating-main-dex-list-file.html
Notes: This unfortunately does not support reflection however, DexClassLoader loads classes from .jar and .apk files containing a classes.dex entry. This may be worth looking at as well.
Hope this helps!
There are several ways that Andorid aka-native code (Java code) could be integrated into Xamarin project. Official ways are listed in this article.
We are trying to use a Java Library Binding approach discribed in the article.
Our test andoid library is published on Github for this question specifically.
We've created it in Android Developer tools setting it as Java Android Library. It is built in Eclipse into a .jar format that tutorial on Xamarin site assumes to be sufficient.
If we are trying to bind .jar into our project in Visual Studio, the Object Explorer will show us the binding asseblie's namespace, but in code, even though the assembly is referenced, we can't access the methods and classes in the namespace, decleared in our test java android lib..
On the other hand, when we take almost any .jar, which is an android library on the internet (for example this one), we can bind it and access it's methods without a problem.
Please compare two .jar and if possible, let me know what is wrong with our test android library on github, that causes our namespace to be unavailable from code.
I read the same Binding a Java Library article you did, went through the instructions, and had no build errors. When I attempted to use the classes from my jar file, intellisense was not recognizing anything. Then I read the follow-on article on API Metadata Reference. This got me thinking that perhaps I should try editing the Transforms/Metadata.xml file. After editing that briefly to include a rename of the package, Visual studio allowed (after a compile) a reference to a class from the jar file. I then attempted to call a method from the class, and again, got another compiler error. So, I went back into the Metadata.xml file and added an entry to rename the method in question. I edited my code to call the renamed method, and Visual Studio compiled fine. I integrated this call into a unit test case, and it passed!
From my reading, it didn't seem necessary to edit the Metadata.xml file, but at least in my experience it seemed necessary. It uses XPATH on the obj/Release/api.xml file (as stated in API Metadata Reference). From that article there were examples for renaming both package & method names, so it wasn't much work for me to insert into my Metadata.xml file. In addition, I downloaded the OsmBindingDroidExample from the Binding a Java Library article and checked out their Metadata.xml file as well.
Here's my XML for reference as well:
<metadata>
<attr path="/api/package[#name='com.abc.def']" name="managedName">MyRenamedPackage</attr>
<attr path="/api/package[#name='com.abc.def']/class[#name='MyClass']/method[#name='originalJavaMethod']" name="managedName">RenamedDotNetMethod</attr>
</metadata>
So, now in my .NET code, I could write:
MyRenamedPackage.MyClass.RenamedDotNetMethod(...);
Hope this helps!
EDIT:
I've gotten a bit more familiar with the Xamarin toolkit, and have an update to make using this easier.
In order to limit the involvement of code that needs to interact with the jar methods, Xamarin allows you to create C# classes in the Additions folder. So, I created a wrapper class that exposes the methods in a managed C# class that other projects can access. Since it's C# there's no complaints from Visual Studio.
Here's what a wrapper class would look like going with my earlier example (obviously you'd pick a name more meaningful to the task at hand):
public class InovcationWrapper
{
public static void InvokeMethod(...)
{
MyRenamedPackage.MyClass.RenamedDotNetMethod(...);
}
}
Then in your project code, you'd have full intellisense if you just call your wrapper class:
InvocationWrapper.InvokeMethod(...);
This makes it much easier to work with and limits the amount of red squiggles to be ignored in your code. Hope this helps!
Does anyone know how to show all of the functions available via an NDK compiled shared library with public facing JNI functions / methods?
I have a lib*jni.so file which I need to access its methods. Using nm -Dg lib*jni.so outputs all of the symbols found within the Shared Library. I'm only looking for the ones defined as JNI hooks.
Thanks,
Kevin
There are a few tricks you could use to find this out.
Inspect the corresponding .class files. If you have the .class files for the library, you can open them up in Eclipse and search for the native keyword to see which methods that have been declared to be implemented in native.
Use the strings command to dump all strings. Unless the library does runtime concatenation of Java method names etc (unlikely) you should be able to list most Java methods and classes referenced from the .so with strings. Using regexps, you can filter out the interesting strings. For example will strings lib*jni.so | grep 'L[^;]*;' list all classes referenced from the .so (for example Lcom/somecompany/project/SomeClass;). It will probably be tricky to match methods with classes, but depending on your needs this maybe is enough.
Build a version of the Dalvik VM that prints a logcat message everytime a native method is registered. This is the most advanced and time consuming but the most accurate. Simply follow the instructions at http://source.android.com/source/index.html to build an Android emulator, but before you build, enable the debug print at the end of dvmRegisterJNIMethod in dalvik/vm/Jni.cpp so it becomes: LOGI("JNI-registered %s.%s:%s", clazz->descriptor, methodName, signature);
Run javap on the .class file with the native methods.
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?
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/)