Presently i am a newbie in android development .. I need to develop a secured android application so that i can save it from getteg pirated.
For security of application i have used RMS in J2ME.In J2ME i use to do following steps :
generate a serial number(some random number)
save that number in rms,on next launch of application display the
same serial number on screen and ask user to input valid activation
code then if user enters correct activation code then application
activates and flag is set to true and i save this flag value in
other rms
if flag value is true then home screen is displayed to user on
launching app again else activation page is displayed.
I want to implement this concept in android ..Please guide me how to do it.Or tell me if any body knows some better way for doing this in android.
Secondly I want to obfuscate the apk file before releasing the application..after goggling for 2 days i found that it can be done using proguard.But i am not getting how to obfuscate the code.Please guide and help me for sorting both issues.
Thanks
There isn't really a way to protect any sort of client-side code, whether it is an Android *.apk, a Java *.jar file, or a bit of JavaScript code that runs in your user's browser. The best way to protect yourself from piracy is to make the application dependent on some server-side computation that you provide.
Since you are using RMS, it sounds like you already require a server-side computation. Rather than bothering users to enter an activation code, why don't you associate this activation code with the user's email address when they purchase the application, and then why don't you use OAuth with their Google Account to verify that the user has an email address that is known to have purchased the application?
About RMS
Michael Aaron Safyan said everything, nothing to add.
About ProGuard
ProGuard is now integrated to the Android framework, and requires basically no work to be set up. You just have to enable it as explained in this article and if needed to customize its configuration. "If needed", as the default configuration is suitable for most of the projects. You just have to be careful with the use if the reflexion as most of the packages, classes and methods are going to be renamed by the obfuscation process.
The parallel to RMS in Android is SharedPreferences.
However, the sharedPreferences xml file is not as protected as the RMS files in J2ME (at least in some devices). Anyone with a rooted device can read and write this file easily...
Therefore, I suggest you read about Android's Application Licensing. It's far from perfect, but it's a built in feature you can integrate easily.
http://developer.android.com/guide/publishing/licensing.html
EDIT:
Obfuscation:
To obfuscate your project all you have to do is add proguard.config=proguard.cfg to your default.properties file.
The obfuscation will occur according to the configuration stated in the defult proguard.cfg file.
Note that your code will only be obfuscated when you build the final APK (Android Tools -> Export ...) and I recommend testing the final APK after obfuscation, especially when 3rd party libs are part of the build process
Related
I'm working on a drag and drop app builder. The concept is simple: users can build their apps visually, then the app's settings get turned into a configuration file which will be used by the app to decide how to construct itself (which views should be shown, how should the navigation look like, etc.)
My main concern is once the users download the apk (or ipa) file, they can decompile it, change things in the configuration file and re-compile/re-sign it to be published as a brand new app.
I was thinking about putting part of the logic on server side but that would introduce me the following problems:
If 1000 people built and published an app with my software, and each app sends only 10,000 daily requests to my server, that's already 10,000,000 requests per day, which would be pretty expensive.
If my server is down for any reason, I will have a lot of angry users coming at me.
Got any ideas?
There is no exact way of stopping decompilation/reverse engineering process of android app or apk !
But there Some chances to reduce the scope of code visiblity after decompilation/reverse engineering process !
Here are some habits I am sharing
1) Put important code on a Server : You may rely on remote procedure calls to a well protected server. This reduces the chance of your codes being stolen as the code will always remain on the server and nothing other than the results can be seen.
2) Debugger Detection Techniques : Insted of using the hard coated values or string use some formula or encryption methods which can help to hide the actual values
3) Write important parts of code in C/C++ :You can also write the important parts of your code in C/C++ and add them as a compiled library. While it can be disassembled into assembly code, reverse engineering a large library from assembly is extremely time-consuming. Java is easier to decompile in comparison to C/C++.
These are some key habits which are be taken care by good developer , You should also check out this answer as well !
Huh, I knew it wasn't possible to stop the decompilation/reverse engineering process on any android app. But, I thought maybe everything was possible! Like, perhaps something has changed since then, but no. Basically, I use the same steps as Nisarg Jani described. But, you have to pay some special attention to the C++ code. Any mistake will destroy everything that you have built to that moment. So, if you use a no-code desktop app builder, you should be aware of those "tips and tricks." Besides that, you should keep in mind that without the C++ code, you won't be able to do anything.
I'm developing an android application for my client. He wants me to submit the apk to him for testing. I almost finished the application and i want to implement some kind of security to make sure that my client doesn't cheat me, until the payment is done.
Is there any way to implement any kind of security in the code?
If you just need to send him/her the apk, you should obfuscate your source code . You can refer to this link——http://developer.android.com/tools/help/proguard.html，If you have finished it ,you needn't worry too much since the source code is in your hand and it's hard to get the source code by reserving. Besides your project has not finished . Last, even if your project is finished , it still works.
Did you ever hear of Proguard? This feature that you want is called Code obfuscation. Like pointed out in the comments, this is a duplicated question.
This library on github called AndroidTimeLock might be useful. It's specifically designed for sending a dev/test build that will expire and stop working. Of course if the person in question is technical and determined they could decompile the app, remove the timelock check and recompile.
Adding code obfuscation proguard (or as I prefer the paid DexGuard) would of course increase the difficulty of this.
You can make your core code builded a dex-format file.Then use some algorithms such as RC5 and others to encrypt your dex file.At last ,put the dex file in Asset file.Then when your project need the core code,you can dynmic loading/.
I have compiled almost all security vulnerabilities and what measures to take before submitting your application to the play store. You can have a look here.
Mark Murphy makes a good case on his blog what kind of information should be kept out of public repositories. Key material, e.g. OAuth keys or API keys to various services, are a prime example for this.
The application in question would be a mobile android app, so someone decompiling it to get at the secret keys is not in scope of this question.
How would a build job on a public CI instance, for example cloudbees, be configured so the secret is not leaked in the build log or the compile directory? My main intent is demonstrating the architecture and build process of an app with OAuth-based authentication without disseminating my private keys all over the internet. Therefore, the need for a public code repository and a publicly visible build server.
Currently, I am using maven filtering and placeholders in my java code to create static constant classes but those classes are always visible in the target directory. A post-build cleanup of target still leaves a short time slot in which the resulting java file is visible to the world.
From your description it sounds like you are talking about a key which should not be in the SCM repository, yet needs to be included in the final application. Presumably the application binary is not freely downloadable as such, or else anyway could open it up and get your key, but this is fine if the build result is simply being deployed to some server.
In such a case there is not necessarily any problem in having the key present in the target directory (i.e. Jenkins workspace), or indeed in build artifacts (e.g. lastSuccessfulBuild/artifact/target/myapp.war), so long as these things are not publicly readable. In the case of a CloudBees DEV#cloud Jenkins instance, you can use role-based access control to allow the public to see the changelog for your project, and perhaps the build logs (after vetting them to make sure secrets are not printed), but deny access to the workspace and artifacts.
(As far as artifact read permission is concerned, it seems that this is granted to anyone with overall read permission unless Jenkins is run with -Dhudson.security.ArtifactsPermission=true which is not an option for hosted Jenkins. Probably a plugin needs to be created which enables this permission, and probably also “workspace wipe-out” permission, akin to the existing Extended Read Permission plugin. Workspace browse permission is a standard part of Jenkins at least, which would suffice if you are not archiving artifacts but deploying directly at the end of a successful build.)
This is a problem even if you'r not using public build servers.
Think of it: If the key is in the final package, everyone can see it. No matter at what step of the build it got there, it's public. Anyone can download the package (JAR, APK, etc), explode it, decompile the .class and see the key. It's easy to do it all.
In CloudBees you can put this kind of information in an enviroment variable. See this link:
http://developer.cloudbees.com/bin/view/RUN/Configuration+Parameters .
I don't know much about CloudBees, but I think all public servers have this kind of option, putting sensitive information somewhere that is not public.
The app I am working on is automatically cracked by antiLVL (although I am not using the LVL in my app).
In order of protecting my app from "one-click piracy", I am implementing tampering detection techniques explained at Google IO.
I have tried checking the signature both with getPackageInfo() and reflection (invoke()), but AntiLVL was able to crack the app automatically in both cases.
How can I write code that will not be automatically cracked by the current version of antiLVL (1.4.0)? I mean, apart from using JNI.
PS: I am not talking about preventing piracy in general. I just want the pirate to dig into the code by hand rather than using an automatic cracker.
The problem is, any API that only serves to check the validity of your application can be subverted and replaced with a version that always returns the result you expect. I haven't looked at Anti-LVL in detail, but I would imagine it is doing this, which is why your attempts to verify your code using Dalvik's built-in APIs for this purpose are failing.
In order to make it work, you'll have to do the work yourself, using only APIs that have multiple purposes and cannot be so easily subverted.
One way of doing it is to calculate a checksum of either your .apk file or just the classes.dex file inside it, and verify it against some external resource (online server with list of known correct versions, file downloaded to SD card on first execution, etc, resource in the .apk file that isn't included in classes.dex). This prevents code modification, which I believe is how anti-LVL works. I haven't tried this myself, but suspect it should work.
The Presentation Notes from Evading Pirates and Stopping Vampires
Some basic keypoints
Modify the LVL
Implement LVL Tamper Resistance
Use obfuscation
Add reflection
Please note, the #:r.page.X at the end of the links I've provided will not always bring you to that specific slide page number for whatever reason. If it doesn't, take note and browse manually.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.