[Introduction]
So i wanted to poke around some android app and while at it get some idea about android/java reversing.
I've never dealt with java or android to any significant degree, all the more interesting stuff to discover.
I think what i discovered over past couple of day could be usefull to your community so i decided to share it.
Seems like it's a generally accepted fact on android scene that it's impossible to modify .class files at high level, as in by modifying their decompiled .java sources and everyone goes about it through disassembly to dalvik instructions(or perhaps smali is a bit higher level representation) and whatnot and then reassembling, using decompiled code just for reference...
When talking about programming languages/systems that compile to pseudo-code that's later jitted or translated into native code, i've dealt with something similar before
once before when i poked around flash/actionscript 3 reversing, while there were decompilers for actionscript 3 available and particular swf wasn't even obfuscated it wasn't really possible to use decompiled output to make some small changes to significally large project cause of decompiler errors, as in flash you have to compile it all at once or not at all.
There also existed tools that enabled disassembling to as3 AAVM opcodes level, making changes if you can wrap your head around that bytecode language and reassembling back.
But who is fluent in as3 or java or dalvik VM bytecode language except their creators and why would they be? Sure small changes are possible but a pain even at that...
When by some chance i ended up prodding some java i remembered hearing that people are making that Minecraft mods and they don't have original full sources, they just replace/add classfiles to minecraft.jar.
I though "hey that should be possible for android apps" and driven mostly with reverse-engineering curiousity set out to check my hypothesis.
Turns out there's no such thing as "android compiler", since android build process uses javac standard java sdk compiler and java allows compiling single class files and linking against .jar file containing compiled .class files as a library.
Requirements:
1. Dex2jar
2. Android adt bundle
3. Java jdk 1.7
4. Optional : apktool
The guide itself
1. Run dex2jar yourapp.apk
2. Use jd-gui or whatever to get source code of .class file you're interested in inside that apk.
Take note that decompilers don't always produce outright recompilable code
Simplest example jd-gui produces outputs that imports R.strings etc, while javac want it to be a single R import
You can try different java decompilers or fix up the code yourself. Some .class files most decomilers will fail to tackle but those are a minority.
If app is not proguarded it's mostly at your mercy.
3. Modify .java source code of class as you see fit.
4. (optional) You can also do some layout, drawable etc editing(obtained from apktool or whatnot) in a comfortable way if you re-import res folder contents into Eclipse project res.
5. Download android sdk stuff for android api version your app was made for with adt sdk manager tool You're interested particularly in android.jar library, perhaps andorid-support.jar. Maybe you can link against newer library versions, dunno. For my app developer stated minimum required android version so i linked against that jars, but as to how to find out what android version app requires, you can look at android folder in your undexed jar, android\support\v4
v4 = android api 4, android 1.6 version
6. javac -target 1.6(this is not android 1.6, it's java bytecode and source compliance, by default current jdk 1.7 produces "invalid magic cafebabe" error later from dx) -source 1.6 -classpath path_to\classes.jar(obtained from dex2jar);path_to_android_adt\sdk\platforms\android-(required version)\android.jar;(maybe include android-support classpath, worked for me without) path_to\your_modified_class(but named same as originally).java
Like
C:\Program Files\Java\jdk1.7.0_25\bin\javac -target 1.6 -source 1.6 -classpath C:\Users\User\Desktop\testapp\classes.jar;E:\adt-bundle-windows-x86-20130717\sdk\platforms\android-4\android.jar C:\Users\User\Desktop\testapp\someclass.java
If you fed javac valid java code it'll spit out valid .class file, otherwise read it's error output and perform steps to fix that errors.
7. Plug your newly created classfile back into it's jar, use winrar, windows explorer(by renaming it to zip) or whatever.
Javac can produce a differently fragmented classfile than one originally in jar so you may want to delete yourclassname.class
yourclassname$1.class yourclassname$2.class yourclassname$3$1.class ... from jar first.
8. Now it time for our java bytecode to go Dalvik
Dx your updated jar
E:\adt-bundle-windows-x86-20130717\sdk\build-tools\17.0.0\dx.bat --dex --no-optimize --output classes.dex classes.jar
9. Plug your updated classes.dex back into original apk
Delete META-INF folder from apk to "unsign" it while you're at it.
10. Re-sign apk with
C:\Program Files\Java\jdk1.7.0_25\bin\keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
C:\Program Files\Java\jdk1.7.0_25\bin\jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name
11. Zipalign
E:\adt-bundle-windows-x86-20130717\sdk\tools\zipalign\zipalign -v 4 your_project_name-unaligned.apk your_project_name.apk
12. Install modified apk
This whole thing relies on the fact that while fully recompilable autmatic decompilation of java project of any complexity isn't feasible like always, decompilers are capable of producing large portion of mostly correct code, and java allows you to recompile exclusively that parts you're interested in which could very well end up being correctly decompiled outright or require just minor fixups and you don't have to deal with the fact that your decompiler produced thousands of errors in OTHER classfiles that your class depends on.
I guess even in case target app is obfuscated/proguarded having ability to deal with it on .java level and not disassemly level could still be of great benefit.
thankfull for your efforts dude ...!!!
You did great job...
I have one problem i know how to convert .dex to .smali
but dont get that how to convert .smali to .java source code
i have read ur post after 4th point i dont get ur post can u please explain it deeply
I m new at xda as well in android I want to modify online game for that i want to convert that apk into java source code and then modify it please help
thankyou....!!!
:good::good::good::good::good::good::good:
---------- Post added at 09:28 PM ---------- Previous post was at 09:24 PM ----------
can u make a video tutorial for this project????
i m pressing thank button for your efforts...!!!!
:laugh::laugh::laugh:
Thanks man! That's what i have been looking for
@aashishb4u It's a bit late to answer this question maybe, but anyways...
I don't think there is a smali to java convertor out there, but anyways, you would not need it.
You can get the .jar with "dex2jar" (and then get the .java file after decompiling it with "jd-gui", for example) directly from the classes.dex file, as for the smali code. Which means converting this outputed .smali to .java would not give you more information than the converting .dex to .java (as we usually do), if not less, since it would just add 1 more intermediate than needed.
By the way, thanks for this post @Wrongusername, it was really what I was looking for.
Hello
I am new to this , how do you extract classes.cdex from zip files of stock rom
Related
I'm just wondering is anyone trying this yet? i mean is it even possible?
Just a thought for you big shot android devs out there JF, Haykuro, LucidREM
Google "android jni"
Well, a quick trip around google would have helped you.
Android is using java, and currently it's not possible to use anything else.
But anyway, would you rather compile all of your code for multiple architectures? J makes things easier here...
You can write cli-apps in C though... i heard something about that there was plans to make other languages available in android, but i wouldn't hold my breath
Also, why is this related to JF/Haykuro/LucidREM?
I think you can do this with JNI: http://en.wikipedia.org/wiki/Java_Native_Interface
Using an ARM native compiler (such as the ones at CodeSourcery, http://www.codesourcery.com/sgpp/lite/arm/portal/[email protected]=lite) you can compile your apps and run them fine on the G1
Code:
$ arm-none-linux-gnueabi-gcc -static foo.c -o foo
$ adb push foo /data/foo # we are pushing to /data as it is +rwx (read, write, execute) for a standard user.
$ adb shell /data/foo
a=1
b=2
foo=a+b
foo=3
^^^
OH I love when I stumble across a post like this and have something new to play with.
The problem is due to the different location of the linker and mainly the different libc you have to statically link everything.
I have been having a hell of a time getting DPKG to build statically.
I picked up a copy of the newly released book, Unlocking Android, at Barnes and Noble yesterday. There is a whole chapter devoted to writing native apps using C (and ARM assembler) with the CodeSourcery tools linked above. The author walks through the steps you need to do to dynamically link the libraries so you don't end up with enormous statically linked executables. Well worth the price.
It is surprising what you can do with C on the phone, its actually not too difficult. The method outlined below doesn't use the non native toolchains and if you use the sourcery toolchain (as mentioned above) you will end up with bigger binaries as you need to link in a standard glibc and not androids bionic libc. This may or may not be important for your project.
The other advantage of the steps below is that you will build and link against any library that is available to the android platform
The easiest way that I've found to start when porting or writing new applications is this method.
1) Check out the current git android source.
2) Build the entire tree, "make" in the top level directory.
3) Create a new directory in mydroid/external/packagename/
4) Copy one of the simple android Android.mk (Make) files from a "like" target.
(If doing a library, choose a library, if coding an executable , choose that).
5) source the mydroid/build/envsetup.sh in the users bashrc
6) cd to your directory, then instead of the usual "make" do an mm.
This should create a binary, which you can adb push to the phone and run at the console.
You can do all the usual things if linked properly, like write the framebuffer using sdl, play sounds, create network connections.
Just remember that you dont have a standard libc (glibc) to play around with you have "bionic". If you are missing your favourite glibc function , it is probably intention and not abug. You'll either need to port it or make do with the functions provided by bionic.
These instructions are for a "pure" C program. you can mix the java like dex calling by 'shelling' out to the C application when you need performance, however premature optimization is the root of all evil, you'll be surprised what performance you can pull from davlik (And I expect the VM guys to improve this even further).
I know that is a lot to digest. Will do the best I can to answer your questions. I'm by no means an expert in the area, but have learned a bit about C on android.
Well I don't know much about all this but what i know is that e.g.
ScummVM IS written in C++ , and so is g-arcade.
His FAQ says:
"How did you do this? Is it Java?
No. ScummVM is a C++ program. For this port, I turned it into a really big JNI library so Android still thinks it's running a Java program, but almost all of it is implemented in C++."
(http://sites.google.com/site/scummvmandroid/faq#TOC-How-did-you-do-this-Is-it-Java-)
So if some1 wanna port MAME, feel free to xD
Hi guys,
I know that there are a lot of people have been asking the same question but I couldn't find the right answer for it, except "it is not recommended". I understand why such approach is not recommended so let's not discuss that issue again here.
What I really want to do is to test some internal APIs in my app. We will, in the future, build our own ROM, but at the moment, we want to test some internal features to see if they serve our purposes. But once I import any internal Java class into my app's code, Eclipse displays errors (of course). And I am trying to get around by either copying that source code part from AOSD to our app or looking for some .jar files so that we can put them into Build Path and compile. But both ways didn't work.
Is there anyone here can help me to solve the problem?
And let's me know if I posted in the wrong forum.
reddevil00 said:
But once I import any internal Java class into my app's code, Eclipse displays errors (of course). And I am trying to get around by copying that source code part from AOSD to our app
Click to expand...
Click to collapse
That's what I did for an app just yesterday so I suppose that generally this approach is working. Though I had to include a hand full of classes until all errors were gone.
If you don't tell the detailed error messages then I guess noone can help any further.
Thanks ramdroid77. Seems that I got the right person
Ok, I want to use the following classes:
com.android.internal.telephony.Call
com.android.internal.telephony.CallManager
com.android.internal.telephony.Phone
Since these files depend on other classes as well, so I decided to copy the whole source code (.java files) in framework/base/telephony/com to src folder in my project. There were errors such as in AdnRecord.java "The method readStringArray(String[]) in the type Parcel is not applicable for the arguments()...".
But before trying to fix the errors, I realized that this seems not the correct way to do because those copied Java files will be compiled as well. But what I need is only the reference implementation of those classes to get over the compilation. When the app is run, it will invoke the real classes. That's why I changed to the second way looking for some .jar files that I can add to Build Path.
Btw, which approach did you use? Can you tell me roughtly how you did it? I'll follow and report the specific error messages then.
reddevil00 said:
But before trying to fix the errors, I realized that this seems not the correct way to do because those copied Java files will be compiled as well. But what I need is only the reference implementation of those classes to get over the compilation. When the app is run, it will invoke the real classes. That's why I changed to the second way looking for some .jar files that I can add to Build Path.
Click to expand...
Click to collapse
So compile all Android java files to jar and add it to classpath of your application.
Thanks guys. Sorted it out.
I had compiled Android source code earlier so I just needed to find those class files in the compiled source code and added to the classpath. Now it is working.
I brought up some thoughts about Dropbox in mamaich's thread and netham45 was nice enough to bring up some interesting facts about Dropbox, namely that it's compiled in Python.
I'm totally unqualified and have no idea how to actually do the tough stuff, but i'm just going to leave all my notes so far in this thread so someone perhaps more knowledgeable with Python can take it from here. I will try to play it around to get it working though.
Basically after extracting Python from the .exe I got left with a bunch of .pycs that need to be recompiled into the .py that made up the file. I have no idea how to do this. See here http://nixforums.org/about81754.html - if this can be built into some sort of functional program, then it may be very well possible to take this one step further and recompile an .exe for ARM that runs dropbox - or even more easily just compile a working python file for Dropbox
this also might be interesting http://kyl191.net/2012/04/dropbox-api-python-to-sync-a-folder/
I also thought it's worth pointing out this https://github.com/mdornseif/dropbox-client-python
last but not least http://stackoverflow.com/questions/2678180/how-does-dropbox-use-python-on-windows-and-os-x
Maybe someone will have a better idea about what's going on here
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Another thing that could be done is implement a client in .net. I played with doing just that a couple weeks ago, I had a semi functional (it worked, but had some issues still) offline client in not very many lines of code using a .net library for Dropbox. I'll see if I can get my code up sometime soon.
netham45 said:
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Click to expand...
Click to collapse
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
DarkoLord said:
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
Click to expand...
Click to collapse
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
SixSixSevenSeven said:
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
Click to expand...
Click to collapse
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
DarkoLord said:
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
Click to expand...
Click to collapse
The pycs are getting magic number errors when I try to look at them because i'm not running it through the interpreter - because I dont know what the interpreter is. I think the first step is to find a way to get it compiled and running to find out if its platform independent or if there are dependencies.
I also have no idea which .pyc to start with
Ah, magic number.
Apparently Dropbox uses a bit modified version of python interpreter with some encryption and mixed opcodes.
Here are some details: http://blog.codepainters.com/2012/09/17/python-care-and-feeding-the-dropbox-way/. It looks like it could be done
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
https://www.dropbox.com/developers/sync
Any idea if this would be helpful?
userno69 said:
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
Click to expand...
Click to collapse
I really agree, is this project still alive??
maxxie85 said:
I really agree, is this project still alive??
Click to expand...
Click to collapse
It's been six months since this thread was posted in. I doubt it.
netham45 said:
It's been six months since this thread was posted in. I doubt it.
Click to expand...
Click to collapse
yeah I noticed that to, never hurts to ask.
And by the way, maybe now the life in this project is getting resparkeld.
Sent fromy my ASUS Transformer Pad TF300T using XDA Premium HD app
Hi guys, I am currently in development of my program to analyse static code of apk files. However after using dex2jar to convert the dex file to a jar file, i noticed multiple .class files within it.
1.) I am wondering other than the use of JD-GUI or any other GUI programs, are there any cli programs (for linux) which can be used decompile classes file to java? JD-GUI allows me to save the file as a java, however it does not provide a CLI commands to do so.
2.) In addition to that, due to the large number of files in the jar file, are there any classes file which can be ignored for static analysis? For example classes which are know to be non-malicious in nature. But are often used in APKs.
Thanks for any help in advance
Bytecode Viewer is an Advanced Lightweight Java Bytecode Viewer, GUI APK Decompiler, GUI DEX Decompiler, GUI Procyon Java Decompiler, GUI CFR Java Decompiler, GUI FernFlower Java Decompiler, GUI Jar-Jar, Hex Viewer, Code Searcher, Debugger and more.
It's written completely in Java, and it's open sourced. It's currently being maintained and developed by Konloch.
There is also a plugin system that will allow you to interact with the loaded classfiles, for example you can write a String deobfuscator, a malicious code searcher, or something else you can think of.
You can either use one of the pre-written plugins, or write your own. It supports groovy, python and ruby scripting. Once a plugin is activated, it will execute the plugin with a ClassNode ArrayList of every single class loaded in BCV, this allows the user to handle it completely using ASM 3.3.
Key Features:
APK/DEX Support - Using Dex2Jar and Jar2Dex it's able to load and save APKs with ease!
Java Decompiler - It utilizes FernFlower, Procyon and CFR for decompilation.
Bytecode Decompiler - A modified version of CFIDE's.
Hex Viewer - Powered by JHexPane.
Each Decompiler/Viewer is toggleable, you can also select what will display on each pane.
Fully Featured Search System - Search through strings, functions, variables and more!
A Plugin System With Built In Plugins - (Show All Strings, Malicious Code Scanner, String Decrypters, etc)
Fully Featured Scripting System That Supports Groovy, Python And Ruby.
EZ-Inject - Graphically insert hooks and debugging code, invoke main and start the program.
Recent Files & Recent Plugins.
And more! Give it a try for yourself!
Code from various projects has been used, including but not limited to:
J-RET by WaterWolf
JHexPane by Sam Koivu
RSynaxPane by Robert Futrell
Commons IO by Apache
ASM by OW2
FernFlower by Stiver
Procyon by Mstrobel
CFR by Lee Benfield
CFIDE by Bibl
Contributors:
Konloch
Bibl
Fluke
Righteous
sahitya-pavurala
priav03
Afffsdd
Website: https://bytecodeviewer.com
Source Code: https://github.com/konloch/bytecode-viewer
Bin/Archive: https://github.com/konloch/bytecode-viewer/releases
Java Docs: https://the.bytecode.club/docs/bytecode-viewer/
License (Copyleft): https://raw.githubusercontent.com/Konloch/bytecode-viewer/master/LICENSE
Report Bugs (or below): https://github.com/Konloch/bytecode-viewer/issues
__________________________________________________________________________
Thanks for the hardwork, Will try it out...
Congrats!!
A "must-have" tool for sure... Thanks for your hard work!!!
Thanks! If any of you have any questions, or have a suggestion just reply here and I'll answer asap.
2.6.0 is out now! The biggest feature is smali editing. You can download it here https://github.com/Konloch/bytecode-viewer/releases/tag/v2.6.0
2.9.0 is released, contains LOTS of improvements for android APKs! If you've tried BCV in the past I urge you to try it again, you'll love the updates.
Konloch said:
2.9.0 is released, contains LOTS of improvements for android APKs! If you've tried BCV in the past I urge you to try it again, you'll love the updates.
Click to expand...
Click to collapse
I tried the v2.9.2 today, but was unable to make it work properly.
Used OpenJDK/JRE 7, 8, 9 on a ubuntu 14.04 with no success.
I get a blank window - I can open a file with control + o, but each time the app gives a message about not finding the temporary file which is supposed to be created (but isn't) in /home/user/.Bytecode-Viewer/bcv_temp/
I don't have any spaces in my path.
I see dex2jar running on the apk, but nothing gets created in the bcv_temp
I tried with different apks with no success.
I can decompile my apk just fine with jadx & apktool.
adwinp said:
I tried the v2.9.2 today, but was unable to make it work properly.
Used OpenJDK/JRE 7, 8, 9 on a ubuntu 14.04 with no success.
I get a blank window - I can open a file with control + o, but each time the app gives a message about not finding the temporary file which is supposed to be created (but isn't) in /home/user/.Bytecode-Viewer/bcv_temp/
I don't have any spaces in my path.
I see dex2jar running on the apk, but nothing gets created in the bcv_temp
I tried with different apks with no success.
I can decompile my apk just fine with jadx & apktool.
Click to expand...
Click to collapse
would you be able to add kalenkinloch on Skype to help me debug this issue more?
Bytecode Viewer on Android?!
Looks like an amazing tool!
Any chance it could be released as an Apk to run directly on Android devices?
Not having a PC and so using Show Java (com.njlabs.showjava) and AIDE (com.aide.ui).
Would be most interested to add Bytecode Viewer to my tool case!
Thank you!
Is there a quick start guide of sorts for this? Recompiling .java files seems promising as I am trying to disinfect a custom lockscreen APK to no avail.
And would it be possible for this to interface with the Android Studio/SDK, especially in case you're more comfortable with editing .java sources instead of having to decipher lines upon lines of bytecode?