Does copy protection make sense for a free app? - android

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.

Related

Need some information about reverse engineering and decompile (android app - jdk)

I'm new to android and I don't know much about software engineering. I wanna know about things should be done to make it harder to decompile an app. I made some research about it and I ran into this debugger JEB which seems like it can monitor some stuff while app running. Yet I don't know the advantages of using it since I don't get the critical points of an android app which is being monitored by JEB. for example:
enter image description here
appearantly the right side shows local variables. what does x / xh means for an int? or for the string value "secretKey" is the value of string seriously? if it is then all variables in my code are at risk!!!??
I think maybe one of the attempts is to make a lot of fake variables in code so that the real ones can't be seen easily. Does it make sense? And are there other leaks that I should try to prevent for example about this JEB? Does proguard have anything to do with this? As I said I donno much about soft-eng and I didn't get to understand what proguard actually does.
And another thing I've seen is https://ibotpeaches.github.io/Apktool. How to make it more mixed up for such tool to handle?
The last question, I code in java and don't think yet I have the opportunity to start native coding but for future; I've seen people say its safer to code natively. Is it by itself? or there are more libraries to keep more safety? or its because of the final apk structure?
sorry if some words look dumb. thanks in advance
You should not try to prevent reverse engineering, because doing so is largely futile. Instead, you should design your app to minimize the effect that reverse engineering would have (i.e. you should not include secret data like keys or passwords in the app).
The amount of effort that people are willing to put into reverse engineering your app depends on how important and popular it is, while obfuscation increases the effort required to reverse engineer the app. However, if your app becomes popular, no amount of obfuscation will stop people, while if it languishes in obscurity, nobody's going to bother to look at it, even if you post the source code on Github. Also, in rare cases, adding obfuscation will make people crack it just for the challenge.
Apart from that, there is the risk that obfuscation will give you a false sense of security. Anyone can devise a system that they themselves cannot break, but if you aren't an expert at reverse engineering, the measures you come up with are unlikely to stop those who are. It is best to instead assume that everything in your app is public information and design accordingly.
You can protect your code by using some powerful obfuscator tool like: Bg+Anti Decompile/Reverse Java
It has a lot of protection options:
Hide string value (helpful when you keep some sensitive info in java source, ex: "Hello world" ->ߤª )
Obfuscate with unicode characters
Hide packagename
Add fakecode to trap the decompiler tools
Check resource-string (helpful when someone try to edit the resources of your APK)
....

Android shared library integrity protection

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.

The library approach to release a free and paid version

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.

Protect against dalvik changes in android

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!

Copy-protection traps

Just about to release a free version of my app and I'm looking towards the free-mium model to give extra options to users. However, I'm definitely worried about it being pirated too quickly for me to make any anything.
Does anybody have some quality copy-protection techniques for Android? And I'm not talking about the pos LVL that is provided. I'm looking for some sneaky traps to detect if my code has been tampered with. Any ideas welcome; gotta make it hard enough on them that its just not worth it.
It will only get pirated if it's popular, so you have a long way to go :). Generally, obfuscate your code, don't use the LVL as is since there are tools that disable it automatically. Not sure what your idea of a 'sneaky trap' is, but watch this for some ideas on how to protect your app.
Those are mentioned in the video, but:
use ProGuard to obfuscate your code
to detect if your code has been changed, you can check the CRC of classes.dex or check if the APK has been signed with your certificate (if someone changes your code, they'll have to resign it). However the antilvl tool effectively disables the APIs you would use to check for tampering. So you need to do it in native code if you want it to be effective.
don't do your checks on startup, but later on so they are harder to detect.
if possible, have a server side component to your license/tampering checking. Think about how your app should behave if there is no network connection. Cache server responses? For how long? Deny access right away? Allow access always?, etc.
Protection can always be broken, all you can do is make it harder to break.
Something you might do would be writing some essential part(s) of your code in C and call it via the NDK. Then you can do some testing in there, because decompiling the C part will be much harder than decompiling bytecode.
You can use ProGuard in eclipse to obfuscate your code. It optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. That way your code will be more tamper proof.
Reference : developer.android

Categories

Resources