Is there a way to protect my app from those tools that change the dalvik cache?
I use licensing (heavily modified) and I want to protect it against "lucky patcher tool" found here.
Any idea how?
Please help
Thanks a lot
Have you actually researched it?
To quote from that site linky:
Lucky Patcher is a great Android tool to bypass premium applications
license verification, remove ads, modify Permissions, and more.
To use this application, you need a rooted device.
Know: Although stable, functioning of Lucky Patcher can't be
guaranteed at 100%. So you are solely responsible of use of this
application. Under no circumstances Netbew be responsible for any
problems caused to your device (rebooting loop, unstable system,
etc...).
Do not bother wasting time in protecting your app from that!
Sorry, if this answer is not what you're looking for, but it is plain and simple, forget anti-cracking - use proguard.
One is bound to find out how to crack it, don't use LVL, regardless if you claim its heavily modified.
And anyway, crackers out there has the time and resource to pirate and crack apps and any anti-cracking is bound to be broken in a very short space of time!
Focus on functionality and satisfying your end users!
Related
Is there a way to somehow 'protect' a native shared library (.so) for the Android platform against binary changing?
E.g. someone could overwrite a JMP instruction with a NOP after reverse engineering the application, and distribute that library to rooted devices.
Is there anything someone can do?
What I'm looking for here is ideas about implementing a series of checks (e.g. encryption, checksumming etc).
Of course since the platform does not look like it offers support for this (correct me if I'm wrong) it would have to be all 'client-side'. Thus the whole thing is a bit futile, but at least will hinder reverse engineering some.
Yes there are things you can do, and they will make it very challenging for the Reverse Engineer, but I doubt you'd be able to do anything that would stop Chris Eagle.
The best way to protect from modification is to take a SHA-2 of the .so after you compile it, and rehash each time at runtime, matching it against the known value. This check will be enforced on the client side, so a skilled RE could just modify the binary to ignore the check. It does make it a bit harder though. If you put checks all throughout your code and use different checking techniques then it extends the amount of work the RE has to do. Do know however that Microsoft has poured millions of dollars into anti-RE techniques and there are still pirated copies of Office and Windows out there. You'll never stop them all. My personal philosophy (now that I've studied RE myself) is that it is ultimately too much of a pain to try and stop them. Just make a good app, make it cheap, and people will buy. The miscreants that steal your stuff wouldn't have bought it anyway.
If your app calls home you could also submit the hash to the server for verification. Of course and RE can still bypass this but it is one more thing to do.
I am going to release multiple versions of an app to the Android market / Google Play Store. Now I am looking into the best way to do this.
I've read a lot of questions here about how this is achieved in the easiest way.
I do not want to create application version specific activities, because this could easily lead to code inconsistencies between the different versions. So I want to use the library approach. This also seems to be the easiest way, instead of all the examples I've seen which require hefty amounts of ANT scripting etc
For argument's sake I am going to have:
com.app.library
com.app.free
com.app.paid
com.app.paidmore
My idea is to base code in the library on the package name.
Parts of my activities would not show, or disable functionality based only on package name.
What are the downsides to this approach? I can't seem to find any, but I am curious about the opinions. Ofcourse all application versions would in a sense contain all functionality, but the functionality is disabled on the fly by code. I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.
What are the downsides to this approach?
Your app winds up bigger than it needs to be (e.g., paid functionality residing on a free user's device). And, as you note, it puts all the functionality on the user's device.
I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
If it takes more than five minutes, the script kiddie is typing too slow. Decompile, search-and-replace your package name, recompile.
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.
That approach actually might take more time -- to perhaps ten whole minutes -- as it may take longer for the script kiddie to figure out exactly what resource needs changing.
Of course, the script kiddies can just grab your paidmore version and attack that, so the fact that your free and paid apps happen to have paidmore functionality is not much of a problem. So, the biggest difference IMHO is APK size, and only you'll know how much that differs between the versions and whether or not it's a problem.
My free app is occupying 2x space on the device, because it has copy protection enabled, in Google Play.
I didn't enable this. I'm wondering if it's necessary. The 2x space is very negative and I would like to disable it.
I know also that copy protection is deprecated, and LVM encouraged instead, but I don't know if that's usable for my use case. Maybe I just have to disable copy protection.
There's probably no reason besides wanting to protect the code? But I don't think I have any abnormally, outstanding code there, only good programming and some clever tricks :)
So does it make any sense, in my case, to use copy protection / LVM or do I just disable it?
To protect the code a bit maybe only obfuscate with ProGuard?
Especially with the ease of rooting a device and copying it anyway, obfuscation is your friend here, especially if copy protection is making your app sp much larger. And copy protecting a free app is kinda pointless anyway, no? I'd just disable it, and obfuscate if you're worried.
Neither copy protection nor obfuscation will help against determined attacker with some skills and cheap time. I would be more worried and embarassed if nobody copied my free application ( basucally I have no problem with it unless somebody tries to steal copyright
- but I make my money with programming for money, so apps are my showcase)
People who use good programming and clever tricks are usually eager to share their knowledge with the community. Concealing them won't make you neither happy nor rich.
I see very little point in using any kind of protection.
Copy protection is usually used to prevent unauthorized copying which basically means 1 purchase 10 installs. If your app is free, there's no point of using any type of copy protection because you do not really care where people got your app from. So neither obsolete Play's mechanism, nor LVL nor anything else of that type is of any use in case of free app like yours.
A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.
This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.
Recently, I found my application is crack by some anti-lvl tools.
This tool could easily crack the "Android License Verification Library" in my application, and generate a new cracked apk.
It also provide lots of function hooks to prevent the developer from detecting their application is cracked. Such as get file length function or check signature function ...
Any one know how to defeat it?
Thanks.
I don't like the standard response of "go check the google i/o presentation" simply because many of the techniques mentioned are defeated by antilvl. It is bad advice in my opinion as the topics, such as reflection and crc checking are already defeated.
Doing further research on antilvl, i came across the svn trunk to antilvl, with a very descriptive hint in a readme.txt file. Here is to prevent antilvl according to the author, prettied up by me. this will return true/false depending on the presence of smaliHook.java, which antilvl uses to hook normal package checks. This only works as a first line of defense, since the class name could be changed with a modded version of antilvl which is likely circulating somewhere. This is a good first check however, since it will defeat the average script kiddie.
protected boolean isAntiLVL(){
try{
Class.forName("smaliHook");
return true;
}catch(Exception e){}
return false;
}
In general - there is no way to fully protect your application in the wild. User might have root access on his/her device and then all bets are off. You can introduce some manual "hackarounds", but if your app is a high-profile one, you will be cracked anyway.
Its just power-play between you and crackers. And if you fight crackers too hard you might hurt your fair users as well.
I'd also refer you to check out this from Google I/O 2011:
Taken from: Avoid apk cracked
Thought it may be very useful to you!
Evading Pirates and Stopping Vampires
http://www.youtube.com/watch?v=TnSNCXR9fbY
EDIT The Presentation Notes: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.google.com%2Fevents%2Fio%2F2011%2Fstatic%2Fpresofiles%2Fdgalpin_android_pirates_and_vampires.pdf
Some basic keypoints
Modify the LVL
Implement LVL Tamper Resistance
Use obfuscation
Use reflection