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.
Related
I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.
I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.
How can I create a data-only APK file?
How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?
(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)
How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?
My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.
It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.
More in detail:
Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
Compile everything and distribute.
Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.
For what regards me, I'm not completely satisfied by this approach.
A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.
The general outline is something like this:
Make a "template" application. Leave your /res and /assset empty.
Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
Compile and distribute (with a new name, of course).
Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...
There are a few example of these approaches on the web. I'm not completely satisfied by them, either.
Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.
As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .
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 have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.
I am developing an application that has SQLite database to store personal information that must be protected. What are some ways of protecting these personal data? An APK can easily be de-compiled completely, so how can we secure an APK? Additionally, how can a database of a mobile application be protected?
Basically, there are 5 methods to protect your APK being cracking/ reversing/ repackaging:
1. Isolate Java Program
The easiest way is to make users unable to access to the Java Class program. This is the most fundamental way, and it has a variety of specific ways to achieve this. For example, developers can place the key Java Class on the server, clients acquire services by access relevant interfaces of the server rather than access to the Class file directly. So there is no way for hackers to decompile Class files. Currently, there are more and more standards and protocols services provided through interfaces, such as HTTP, Web Service, RPC, etc. But there are lots of applications are not suitable for this protection. For example, Java programs in stand-alone programs are unable to isolate.
2. Encrypt Class Files
To prevent Class files from being decompiled directly, many developers will encrypt some key Class files, such as registration number, serial number management and other related classes. Before using these encrypted classes, the program needs to decrypt these classes first, then loading these classes into JVM. These classes can be decrypted by hardware, or software.
Developers often loading cryptographic classes through a customed ClassLoader class (Applet does not support customed ClassLoader because of security). Customed ClassLoader will find cryptographic classes first, then decrypt them. And finally loading the decrypted classes to JVM. Customed ClassLoader is a very important class in this protect method. Because it itself is not encrypted, it may be the first target of a hacker. If the relevant decryption key and algorithm have been overcome, then the encrypted classes can easily be decrypted.
3. Convert to Native Codes
Convert program to native codes is also an effective way to prevent decompilation. Because native codes are often difficult to be decompiled. Developers can convert the entire application to native codes, or they can also convert only key modules. If just convert key part of the modules, it will need JNI technology to call when Java programs are using these modules. It abandoned Java's cross-platform feature when using this mothod to protect Java programs. For different platforms, we need to maintain different versions of the native codes, which will increase software support and maintenance workload. But for some key modules, sometimes this solution is often necessary. In order to guarantee these native codes will not be modified or replaced, developers often need to digitally sign these codes. Before using these native codes, developers often need to authenticate these local codes to ensure that these codes have not changed by hackers. If the signature check is passed, then developers can call relevant JNI methods.
4. Code Obfuscation
Code obfuscation is to re-organize and process Class file, making the treated codes accomplish the same function (semantics) with the untreated codes. But the obfuscated codes are difficult to be decompiled, i.e., the decompiled codes are very difficult to understand, therefore decompile staffs are hard to understand the really semantics. Theoretically, if hackers have enough time, obfuscated codes may still be cracked. Even some people are developing de-obfuscate tool. But from the actual situation, since the diversified development of obfuscation, the mature of obfuscation theory, obfuscated Java codes can well prevent decompilation.
5. Online Encryption
APK Protect was an online encryption website for APK, but activity has apparently been discontinued since 2013 or so. It provided Java codes and C++ codes protection to achieve anti-debugging and decompile effects.
I originally suggested you use this last method for it could save you more time. Based on my experience, it was very simple to operate and it wouldn't take long time.
With Jellybean this has now become a possibility.
$ openssl enc -aes-128-cbc -K 000102030405060708090A0B0C0D0E0F
-iv 000102030405060708090A0B0C0D0E0F -in my-app.apk -out my-app-enc.apk
$ adb install --algo 'AES/CBC/PKCS5Padding' --key 000102030405060708090A0B0C0D0E0F
--iv 000102030405060708090A0B0C0D0E0F my-app-enc.apk
pkg: /data/local/tmp/my-app-enc.apk
Success
Please read the following blog post for further details
If this is secret information that must not fall into the hands of your users, you cannot secure it. It is fundamentally impossible to put information on a device (code or data), and have your application access it, but not allow someone with the device to have access to that information.
Encrypting the information is pointless from a security point of view, because your application has to contain whatever is needed to decrypt it in order to use it, and a sufficiently motivated attacker can always extract that and decrypt it on their own.
All you can do is make it more annoying and time consuming to get access to that information, which only helps if there's not really that much of a need to keep it secret. This is what using proguard to obfuscate your .apk file can do.
Have you considered sqlite encryption? See this thread - sqlite encryption for android
As for protecting your .apk, try obfuscating your code using proguard. See http://developer.android.com/guide/developing/tools/proguard.html
You can try 'Anti Decompiler(Android)Trial'
https://play.google.com/store/apps/details?id=com.tth.AntilDecompilerTrial
It makes something Proguard doesn't:
Hide all const values (string, character), you will never see clear text like "my key", "my val"... in your apk file
Obfuscate file name, which is referenced in AndroidManifest.xml
Add fake code to your source code. Event the powerful decompilers likes: dex2jar, jd-gui,... can't reverse exactly your apk file. Most of functions will show with comment 'Error'.
=====
After transforming, if you give someone your source project, it will be nearly impossible to read and understand.
This solution doesn't exclude Proguard, You can combine them together. (function, field Obfuscation of Proguard is better than Obfuscation features of this solution)
You may read my post at: http://www.androidpit.com/en/android/forum/thread/567093/An-Analysis-of-Android-APK-Protect-Shell-APKProtect. The APK added with protect shell of APK Protect is seems unable decompile. I mean, the encrypt method is very advanced. Even a master hacker need long time to crack it.
If it is the database that contains sensitive data you can encrypt the values of several columns or the full database like mentioned in the other answer and make sure that the password is not stored on the device but has to be entered by the user on accessing the data.
If there are pieces of code you need to protect there's really no good way of securing it. All you can for a limited amount of use-cases is to create a dependency to an online service and secure the server. But for a lot of applications this would not be an option.
First, make apk that can never be modified and used. I do it by temper detection from the server. I use root check emulator check. Then on the important activity, it checks root and emulator on every oncreate and on resume, deletes important data on onpause, Great. Now encrypt data and place license to server, use SSL server. It app can not be modified and run, everything is safe for ever. Well, how to avoid decompiler and online tamper detection. I do placing a huge code to generate some sample string from apk file, and compare it with an apk copy placed on the server. I have converted apk file to string. Just enjoy.
We've been asked to create a thin web client on Android for a company with an existing web site, existing users.
They want to send an mms to their users, giving each user their own download URL. This URL will point to an Android apk file that has been created specifically for that user - it will include that user's login, and password, to the website.
i.e. the APK file would have embedded login details.
This would be done in J2ME by storing info in the JDK file.
I can see a simlar question on How to update resources file in apk - but not fully answered.
So:
is there a way to store an "asset" in the apk file that will be a text file, and easily editable by unzipping, editing, rezipping the apk file? (looks like answer is no)
do you know of any similar problems, or have worked on similar apps?
is there advice on how best to accomplish this application? Any sort of embedding of customer info on an automated level would be of interest...
would the best option be to set the app to build with an Ant script, and have the client actually customize the source code and build a new app per user? (this has the con that the client gets the source code, which we'd rather not have)
I have scanned apk tagged questions and can't seem to find a solution to this.
Many thanks,
Richard
I guess you could put it into the apk (or replace a dummy file there) if you use the assets folder for it.
You can obtain the data by filename instead resource-id quite easy:
getResources().getAssets().open(fileName)
Regards,
Oliver
If it absolutely has to be that way, consider distributing two APKs, one with the application and the other containing a file with the handset-specific information. Sign them both with the same key, arrange for them to share a UID and the application will be able to read the file as if it were its own.
The rest of this probably belongs in a comment and not this answer, but I see lots of problems with what you're being asked to do:
The standard behavior for just about every other application out there is to ask for a login and password once when needed and then remember it.
If the user changes his password on your customer's web site, he has to get a new APK for his device instead of just having to reauthenticate.
Any changes to the application will require generation and installation of a new APK for each user.
All it would take is some unwitting user sharing his unique APK with someone else and your whole security model goes right down the tubes.
Less relevant, but still important: If your customer is able to reconstitute a plaintext password from what they have stored, I question their security scheme.