I have download an apk from the internet and decpress it using dex2jarf tool so its gives compiled,.classes files which i convert into .java file through decompiler but it gives me classes toa proper way like it gives a.java,b.java c.java which is difficult to me read.Can i get proper classes name through apk file same as it is used in project.plz help
Thanks
What you are trying to achieve is called deobfuscation.
Programmers who wish to protect their intellectual property obfuscate their code to make it more difficult to read for those who might want to steal/copy/plagiarise their hard work.
Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.
Src: http://android-developers.blogspot.ie/2010/09/securing-android-lvl-applications.html
There is no way to recover identifiers if they have been stripped out. Compilation is a lossy process, like converting a RAW image to a low quality JPEG. There's no way to go from JPEG back to RAW.
However, there are tools like jeb and ida that allow you to rename the classes yourself. When renamed, all references to that class also get renamed. This feature is sometimes called "refactoring". This is about the best way to do it, but it takes more time.
Also, there are plugins for jeb that help automate the refactoring by generating new, more descriptive names than 'a', 'b', etc. Here's an example from jcase, which you can modify to suit your needs: https://github.com/CunningLogic/myJEBPlugins/blob/master/DeCluster.java
Related
I want to encrypt .jar file of my android application so that it can't be decoded by any one to view the source code.
How can I achieve this?
It will always be possible to decompile it.
You can only obfuscate your code to make it harder to understand for humans. If your project insists of more than a few classes the effort to understand it will be higher than any one is willing to invest.
One tool to achieve this, which also reduces the size of your class-files is
ProGuard: http://proguard.sourceforge.net/
But there are quite some similar tools out there.
Firstly - you can exclude source code from jar files. It is not required at runtime. Class files are sufficient.
Encrypting will not help you, if you encrypt the files JVM will not be able to understand it.
As responded in the earlier answer, there will always be tools to decompile the byte codes, you can make it harder for the attacker to read so that it is not worth his time
Unfortunately I deleted my Android source code. Tried to get jar using dex2jar and baksmali and used jd-gui to get java source files using my .apk file. Yes I got the files but the problem I have is, in more places in the java file, the code is in byte format. Need to get that to readable format to get myself to move forward.
Decompiling is not a perfect science, and you rarely get back the exact Java code you typed.
When you compile your code, a bunch of optimizations are done on it, which make decompiling more difficult if you're aiming to get the original code.
At best, you'll get a lot of decently decompiled code, along with some byte code. You should be able to figure out what Java code to substitue for that byte code based on where in the program it is, seeing as you wrote the original code.
For most simple apps, it is easier to rewrite from scratch than it is to decompile and try to fix that decompiled code.
tl;dr: Don't forget to backup your code. Ever.
Generally if your goal is to get readable source back, then something like JD-Gui is your best bet. But for cases where it fails, you could try Krakatau, a decompiler I've written.
Krakatau is designed to be able to decompile classfiles, even if they're obfuscated or not compiled from Java. However, the result is less readable then something like JD-Gui because it doesn't take advantage of the patterns left by the Java compiler. It's not perfect, but I think it's definitely worth a try.
P.S. Krakatau only supports JVM bytecode. You'll need a way to convert it from Android back into Java bytecode before you can decompile it.
I want to restrict my Android Application code to regenerate a code using reverse engineering process form my android .apk file. So then my application code will be secure but i don't know how to do this, please help me to restrict reverse engineering process to my android .apk file.
Thanks,
Android Developer.
The best you can do as far as I am aware is to obfuscate your code before deploying it.
Obfuscating, minifying etc will make the original code unreadable even if the code is decompiled. By unreadable I mean people will not easily be able to tell what variables are used for etc since they will no longer have meaningful names. The same goes for methods, etc.
"You cannot completely restrict Android apk from decompilation.
Because it uses dex formats any one can easily convert these dex files into jar file using publicly available tools like dex2jar.
But you can Obfuscate code to reduce code readability, you can also use native codes to prevent easy decompilation of code.
You can store some part your code in server and download them at runtime call function in library using Reflection concept,
which will help you to prevent your code from decompilation."
I am trying to prevent the app from being de-compiled and thus getting exposed. I know there is proguard which I can use to convert the java files to .smali files. But my question is, how secure are these .smali files?
When I did R&D on that, I got some results that .smali files can be converted back to java files. Is that true? Or else what is the best way to prevent the apk from decompiling? My app includes lot of financial details, so at any cost I should not be able to reveal them to the outside world or at least I am trying to make it very difficult to decompile it.
Note: I have already did lot of work on getting the working of proguard
Your answer would be greatly appreciated
Proguard is built in to later versions of the Android SDK. You just point to proguard.cfg and it will be used during release. I assume you know this bit.
Proguard is not related to smali. In the end all these tools output working bytecode and you can always recompile bytecode. Can't stop that. What proguard can do is rename all the symbols in your code so that the result is very hard to understand.
If you mean you are storing sensitive info in string literals in your app then don't do that. These can't be obfuscated or else your app wouldn't work. They are always visible as literals in the byte code.
I have done some significant re-coding on one of my Android programs and now I am unsure if certain xml strings are used anymore. In addition I have a few translations which makes the task even more difficult. Is there a tool to test this? This would be useful for drawables also.
I am using the eclipse plugin.
This question has been discussed in the irc channel before. There is no tool to test it, but I agree it would be useful. Note that resources can be referenced in xml, but they can also be referenced from code. Furthermore, resources can also be looked up by their identifier, and such lookup could be determined by runtime.
So actually you cannot determine 100% whether a resource is used or not anymore, but you can probably determine which resources are referenced in a static way (in xml or code). Depending on your code/app which you know best yourself, such approach might be sufficient in many cases.
The approach would be to write a tool that parses xml and java source files and also take the import statements into consideration. With that information you should be able to determine which resources you can get rid of.
The easiest way is to remove them all, attempt to compile, and re-add those the compiler says are lacking. It's a little tiresome, but it's certainly tractable.
Note, as Mathias already pointed out, that it's technically possible to access resources by name with a string at runtime, and the way I suggest here would remove such resources though they are, in fact, needed. However, this pattern should be really rarely seen in any application, and if you are the one who wrote it, you already know if/where you do such treatment.
Use grep to extract a list of resources to a file by way of sort
Use recursive grep through sort and uniq to create a list of those mentioned in any source file (make a copy of project without unused files or dispatch grep on a list of used ones, of course commented out code will be an issue)
Use diff on the two lists