I have been doing lot of research on how to prevent people from accessing the manifest and layout files.
i know proguard is used for obfuscating code, but then it works only on Java code not on the res folder.
I have been through some answers like download content at run time instead of keeping them in assets and all that. But for now my concern is not to protect asset files. In my case it's manifest and the res folder I need to take care of. I have many types of keys stored in there like analytics xml file app_tracker.xml for example.
This isn't only about the secret keys I have in xml files, but also the logic of layout designing that is at risk.
These are the threads I found while I was doing research, but nothing was of any help to me.
1) How to avoid reverse engineering of an APK file?
2) How to protect a java application from reverse-engineering or code stealing?
I know reverse engineering cannot be avoided, but is there any way I can protect my manifest from being readable from hackers?
You could take a look at DexGuard, which is the commercial variant of ProGuard. It allows you to also encrypt the layout files and obfuscate the content of the manifest and other resource files (together with many other things).
If a phone can parse the manifest in order to install the app, then a user can parse the manifest too. It's as simple as that.
On a side note, obfuscation doesn't prevent people from seeing what's in your app - it just gives you a false sense of security. The security model of your app should assume that anything contained in the apk is public knowledge.
Related
I want protect some files inside my project source code so if I sent source code to anyone he can only read the specific files and the protected ones can't read it without something like password or something else
I need to send all the project source code to someone and he can edit it and build the application normally but prevent him from access or read specific
I am not sure if there is something do that so if someone know is that possible please answer me
You can't. This comes up sometimes with keys and other sensitive files. What we do in cases like these is to have separate development/test/production keys or files and the developer has only access to a repository with the developer keys or files. Then on merge we merge in a way which means the final build will contain the production files the developer has no access to.
If you want to defend source code parts you can use obfuscation. This will still make the build work but it only makes the code harder to understand, not that it is unavailable. Note that if the developer wants to build the project locally it needs to access all the files the build will need, and that means read access.
I'm developing an Android application which contains native code.
The native code is compiled in a .so file that has important algorithms inside.
I'm really worrying about the possibility that my .so file can be edited or modified and then re-build (re-pack). Like apks they can be modified and repacked to create a new one
I have several questions here:
1) Is there any way to edit/modify .so files and re-build?
2) If there are, how do people do that?
3) How to prevent .so files from being edited then re-built?
The short answer is that anything that a computer can read and understand, it can also modify. There is no bullet-proof signature mechanism in Android for Java or native code. Still, the so files are generally considered much less vulnerable than the Java code, even with obfuscation turned on.
Reverse engineering a shared library is hard but possible. Disassembly, change, and assembly back is not hard if one knows what to change.
There are many ways to strengthen protection of your C++ code against reverse engineering, but none will hold against a determined and well-funded attack. So, if the stakes are very high, consider running the important part of your algorithm on your server, and prey for its security.
I have been reading a lot about how malware writers repackage an existing benigh android .apk and repackage it to add malicious functionality.
Now, according to my understanding of the .apk file structure, each .apk file contains a single .dex file which is essentially java byte converted to .dex format. Also, the application has a binary XML called manifest.xml and other resource file and assets. If we have to add extra malicious functionality to the application then we have to modify the manifest.xml (which can be easily done by converting the binary xml back to normal xml), resources (which can be just replaced) and the .dex file.
But the .dex file has a particular structure. According to me any modification done to it should break the code. What techniques do the tools use to prevent the code from breaking because if are adding some malicious functionality to the original app, we are, in essence, adding an extra module.
What are some tools out there that support .apk file repackaging?
Thanks.
Edit: Some members might find it offending to discuss about reverse engineering. Iam research student working on Android Security. I need to know how .apk file repackaging works because this is my research topic. Also, talking openly about reverse engineering isn't a malicious act - books have been written on reverse engineering - using reverse engineering for malicious purposes is malicious :)
Security Information
Enable proguard in release mode. This will make it harder for reverse engineering. Also check this developer training documentation on security.
(from comment on this question)
Package signature validation
You can verify if a package has been repackaged by checking the signature. Some articles to help with that:
Retrieving APK signature during runtime.
Self checking an APK signature.
How to check APK signature.
(originally posted ad Verify Android apk has not been repackaged?)
Decompile DEX into Java
I answered a question about decompiling DEX code in the past. My original answer might be outdated by now but the question has been kept up to date by others. Here is an overview of some of the tools listed there.
A more complete version of
fred's
answer:
Manual way
First you need a tool to extract all the (compiled) classes on the
DEX to a JAR. There's one called dex2jar, which is made by a
chinese student.
Then, you can use jd-gui to decompile the classes on the JAR
to source code. The resulting source should be quite readable, as
dex2jar applies some optimizations.
1: http://code.google.com/p/dex2jar/
2: http://java.decompiler.free.fr/?q=jdgui
Automatic way
You can use APKTool. It
will automatically extract all the classes (.dex), resources
(.asrc), then it will convert binary XML to human-readable XML,
and it will also dissassemble the classes for you.
Disassembly will always be more robust than decompiling, especially with JARs obfuscated with Pro Guard!
Just tell APKTool to decode the APK into a directory, then modify
what you want, and finally encode it back to an APK. That's all.
Important: APKTool dissassembles. It doesn't decompile. The generated code won't be Java source. But you should be able to
read it, and even edit it if you're familiar with
jasmin. If you want Java source,
please go over the Manual way.
(original question: decompiling DEX into Java sourcecode)
Is very easy extract the apk app from the phone through application managers (like Astro).
Google had a base protection that has been abandoned in favor of the more effective license managing,
however the old protection made more complicate the indiscriminate share of the apk outside the Google Play market.
The LVL has an opensource library, but I haven't find anything about the implementation of the GooglePlay base anti-apk-copy protection.
Would be useful a similar solution in addition to the license managing protection.
I have seen that some apps still prevent the apk copy in the same way of the old Google Play protection.
Is there somebody that know how the anti-apk-copy works, or if there is a similar open source protection library?
Somebody have asked what should be the reason for this kind of operation.
The reasons are many:
-Avoid the indiscriminate diffusion of APK through unauthorized channels
-Avoid that the first noob simply opening your APK with winzip could extract all
resources (as PNG images, buttons, textures, DB etc.) for his use easily
-Improve the general security
PS
I know that for every protection there is always a workaround to break it, however this doesn't mean that leave very easy ways to abuse of your work is always the best choice.
I think it's difficult to prevent someone from copying files out of the device. But why do you want to achieve this? If you are only for secure reasons, there are some other methods.
Basicly you can take proguard to obscure the code. If this is not enough, I know in java, there is a mechanism that could encrypt .jar files and use custom ClassLoader to decrypt the file and load class.
This could also be used in android.
Use c and jni to provide encrypt/decrypt apis. (decompiling .so files is more complicated.)
Package the core to a jar file. Encrypt the jar and put it in the assets/.
Use a new DexClassLoader to replace the default one. Try to decrypt the .jar file and load class.
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."