yashsingh1/xdaforums huggingface dataset:
[Java for Android App Development] S.D.Richards:
These solutions already exist, at least for normal PC-software. Don't know if anyone ported this to android, but it would be trivial. Of course, mostly this stuff is used for legitimate tests of software, but there's no reason to use it against some checks. Android software is usually pretty easy to decompile or otherwise reverse engineer, so it's rather easy to plug stuff in.

If it makes sense to use something like that against a $1 app is another question, but with today's hardware it's also no effort to check multiple apps in different vms at the same time.
[Java for Android App Development] Tolriq:
So you really are the kind of guys that always want to be right and have the last word to get this thread purged again ? (Please don't answer to this)

Test units exist for a long time and will for life :) But do you have any idea of the time needed to write those tests ?

Fully automated tests don't exist since you have to provide them with the waited result, a test that check that something happens on a button click is irrelevant in our case since this is exactly the trick, the result will not be the same but the action will work....

Like returning only half of the results on a query ?

Of course if you make a poor fart app with only one button there's nothing to be done (apart stop doing such apps :) ).

Using code coverage tools would be more efficient for the hackers and would work better .....

So as all have already agreed there's nothing you can do against someone that really want to hack an app on Android, you can only do (and it's recommended) some basics things not too hard to implement but still making the work for basic hackers (like all script kiddies) too long to worth it.

And doing those checks out of the non real user path will always finish to a poorly cracked application that will spread making you ads and giving you more users, and even if after a real correct cracked version goes out, it's already too late, the first one was spread and is referenced everywhere users will have more chance to find the bad one and became legit users.
[Java for Android App Development] jpepin:
There is no argument that developers have the right to protect their work. But there are plenty of reasons to not spend time and effort on developing and testing anti-piracy solutions that will inevitably be cracked. The question really boils down to cost versus benefit. How much money are you really losing, and how valuable is your time? For some developers, investing in novel anti-piracy solutions is worth it. For others, it's time that could be better spent improving their app.

That is just one man's opinion. I personally don't think it's a great idea. The fact is, it's up to the individual developer to make that choice.

Deciding not to invest too much effort in protecting your app is ABSOLUTELY on topic, because it's another alternative. Many of the comments made in the discussion of this post (found here: http://www.xda-developers.com/android/preventing-app-piracy-join-the-discussion/) reiterate exactly what I said. I can only assume that my original response in this thread was removed for having a different opinion, which leads me to wonder what other legitimate comments have been censored because a moderator has a personal disagreement.
[Java for Android App Development] zelendel:
Most of them were removed do to being off topic which is	[GUIDE][IDEAS] Protecting your app from the main piracy circumvention methods. And not doing anything is not an alternative. Also alot of the posts were people arguing back and forth. I respect everyone's opinion. Now I understand you are new here so I will let it slide. This once. XDA has a very strong stance on warez. We are against them all together. Posting warez, Posting how to crack apps, and such is a one way ticket out of here.
[Java for Android App Development] jpepin:
While I disagree, I'll respect your decision.

I think you may have my post confused with another. Not once did I ever mention warez or post how to crack apps, so I'm not sure what you're "letting slide." As a developer, I have great disdain for both of those topics, and completely agree with the XDA policy, regardless of the fact that I'm "new here."

To get back on topic...

For the OP (or any one else with insight): How much success have you seen through implementation of the methods you outlined? I think some actual empirical evidence woud help in deciding whether any of them (individually or combined) are actually worth the effort.
[Java for Android App Development] Quinny899:
It's dramatically decreased my refund rate of apps by introducing this after the licence verification, which made not much difference from none at all, unless that's just a total fluke
[Java for Android App Development] mateorod:
I do not support piracy. And I will probably not return here to reengage the thread...for the most part I try and leave debate to others. So feel free to ignore.

But I am very surprised at the number of experienced developers that seem totally okay with force uninstalling packages from a users system, presumably without warning or documentation before hand.

A) I consider those to be the practices of malware.

B) I can almost guarantee you this violates the Play TOS, which bans interfering with other apps. Whether they would enforce them in this situation is another matter. The fact that Lucky Patcher also violates TOS is not lost on me...but two wrongs etc.etc.

I can support a developer disabling support for any system they choose, whether by hashing or LP detection...so be it. It is your program, you can provide or refuse service to whomever you choose.

But what is the difference between you modifying someone's system without their consent (sure...you will be under your declared permissions, I know. If you plan on running a process they did not ask for...that's without consent in my book) and their attempts to undermine your license checks? They are both economics by way of force...I think there could be a better way.
[Java for Android App Development] AdriannTheHunk:
The best way is to stop sideloading itself. Google needs to block the manual apk installer , which would dramatically decrease piracy.

If you are a developer and want to test your own app, use adb. Simple.

Non play store apps banned.

:)
[Java for Android App Development] nikwen:
I do not think that this is a good idea!

Android is open and we do not want Google to be as bossy as Apple is. That is one of the main ideas of Linux and therefore Android: Freedom!

I understand that this is a bad side-effect. However, I (as a dev) rather take this than a company restricting our OS.

Even if they did, ROM developers would remove this limitation.

I download from Google Play most times and do not think much of piracy, but I want free software to be free. That is why I dislike your idea.
[Java for Android App Development] m11kkaa:
Aside the fact that this would be completely against the sense of open source this would be totally useless because it wouldn't take much time to (re-)enable side loading apps.

You can compare this with windows. What would you think if you couldn't install your own Software you downloaded from the internet? Only installing things from the new Metro AppStore would be possible.
[Java for Android App Development] AdriannTheHunk:
I don't think most users know about custom Roms.

As for testing is concerned ....u SHOULD know about adb already.
[Java for Android App Development] lambstone:
Meh. Using root tools as an anti piracy measure?

I'm sure all of us abhor piracy whether it's genuinely so or simply pretence but deleting offending apps on the user's phone?

This should not be the way to go. This is dangerously close to malicious activity. If a prompt to uninstall the offending app instead of forcibly removing it, it might be acceptable.

But a forced uninstall? Doesn't this sound like malware?

I for one would delete any app that ask for root permissions if it's not supposed to. For example, if an app titled "AWESOME ICON SETS" asked me for root permissions, it raises red flags. I'll uninstall that app immediately and report it to google for suspicious activity.
[Java for Android App Development] ts1506:
Personally, I think usage of a method to detect if the app itself has been patched or not, instead of detecting Lucky Patcher/something like that is a better approach.

Maybe, if possible (I have no idea), you could verify the app license with a separate server everytime the app opens ?

Sorry if I dont make sense, as I dont really have much idea about app development.

Lastly, I use Play Store and F-Droid to get my apps, and for the most part, it has served me just fine. I cannot buy apps, since my card is not accepted in Play Store, but in the end, there are always alternative free apps, which IMHO is better than pirating a paid app.
[Java for Android App Development] Quinny899:
I suspect there's a way to verify the signature hash, that might be why it tells you it when exporting, which would solve a lot of issues. However, Lucky Patcher does not have to patch the APK, it can use odex files, and you'd need more than that

EDIT: Sure enough: http://android-know-how-to.blogspot.co.uk/2013/08/android-apk-signature-check.html
[Java for Android App Development] ts1506:
Hmm, lets see. It was a nice read.

I am hoping that Google Play starts Operator billing though. I came from Symbian, and there, you could buy apps using your mobile bill/balance. It was a really good thing for people like me without working cards.

I know lots of people in my school using pirated apps/games, tried convincing many to buy apps and support the devs, but they just turn a blind eye. Ultimately, you can do only so much to prevent piracy. People need to change their mindset too.
[Java for Android App Development] m11kkaa:
in times of the xposed framework it is very hard if not impossible to protect ur app against changes.

It's a hard truth but u should really try to use ur hackers for advertising instead of blocking them.
[Java for Android App Development] Quinny899:
You can in some places, I think another thing they need to allow is alternative methods of IAPs. I know people who would happily buy with PayPal but if it means setting up Wallet and adding a card, nope. That and you can easily add support for mobile payments there
[Java for Android App Development] TheBasterd:
Thanks a lot. Needed this.

As far as ad removal is concerned, there are two options we have : 1)AdAway 2)Ad-Block Add-on

Both are free, open source and do their jobs real good.

As far as piracy is concerned, for people who don't know how to much work is put into app making, go to the google developer section on the official android website and see the amount of code required to make just a simple app with a textbox and a button, to print on the screen any text that you entered. Blew by brain clean off, I thought I could learn android in a day(like HTML5/CSS), but I guess it will take some weeks now.

So, again, really helpful code, thanks for sharing. I will implement it for sure.
[Java for Android App Development] giuliomvr:
But for this, you need to have SOME kind of developing skill. And if you obfuscate your app, they need to dig through your whole code. I think the best idea, If you are using in app purchases is the following: Before starting the purchase, check whether freedom is installed(or running) and show a dialog telling that piracy is bad for the developer, then offering the function to either uninstall the app(and pay) or proceed(possibly cracking it). From my point of view thats a pretty good idea, as there are countries where you can't pay in the play store.
[Java for Android App Development] m11kkaa:
for developers it doesn't matter if he uses xposed or if he decompiles your app. he'll always have to work with your obfuscated code.

The difference is that with xposed you can't prevent these hacks anymore.

And the devs are very good and obfuscation doesn't irritate them. Look at the GEL launcher xposed module or at all the assembly hackers who are hacking bootloaders etc. And believe me: it's not that hard.

All that desn't mean that you should remove all protection from your app. But just don't invest too much time into it.

It's faster to crack apps then developing the security protections.
[Java for Android App Development] giuliomvr:
But there are not that many developers in comparison to the people that would crack it with lp or freedom. And i think that the devs understand it better, as they encounter the issue as well. Of course, you only need to findAndHook the method in the most cases, but xposed isn't fully documented, which makes it harder to learn.

Gesendet von meinem SM-N9005 mit Tapatalk
[Java for Android App Development] m11kkaa:
that would be worth further research because personally I think xposed is pretty good documented and easy to learn.

The question is how the target group thinks about this.
[Java for Android App Development] Quinny899:
The thing is, this isn't really targeting the Xposed usergroup.

What this prevents is people who don't want to buy x, so just google "x apk". They won't be rooted, so unless someone has decompiled and smali hacked or lucky patched the app, they'll give up. Some will then buy, some won't.

If they are rooted, chances are they will search more anyway
[Java for Android App Development] sak-venom1997:
I had thought of a concept to prevent hacking of apps.The basic algorithm is

*Build the app release version(the one that will be distributed)

*Genrate the sha or md5 checksum of the .dex file / assets / mainfest / others things that could be tampered.

*In the app check regenrate these checksums and check if they match the ones above.

It will tell if the files are tampered or not.

It is a common method to check integrity of files downloaded over internet and extensively used in many .net framework based apps

though i have never implemented this but it should work.
[Java for Android App Development] m11kkaa:
You'd have to use signatures instead of checksums. if you add the checksem into your code that changes the checksum again - you just can't calculate it :D

anyway. this protecton is useless since you can easily remove this code.
[Java for Android App Development] giuliomvr:
Reading this, I think we(the community) should create some kind of generic library to perform basic checks like these mentioned in the thread. It also could be reusable.
[Java for Android App Development] sak-venom1997:
God equipped me with a decent brain so i wont add the checksum to the code instead the code will verify cheksum over a web service :) :D

Checking for signatures would be of much help as the code can be edited easily retaining the orignal signature :)

As for the removing code part obfuscating could be helpful !
[Java for Android App Development] m11kkaa:
That's a security bug in my opinion. APK's contain signatures for all files but only AndroidManifast.xml is checked? Someone should report this to google - seriously.
[Java for Android App Development] sak-venom1997:
indeed this is a serious issue and nothing has been done so far
[Java for Android App Development] m11kkaa:
It is fixed:

http://puu.sh/950qb/494a3ebf4e.png
[Java for Android App Development] sak-venom1997:
what class is this ?

---------- Post added at 11:49 PM ---------- Previous post was at 11:45 PM ----------

a more feasable option wpuld be Play Strore doing this instead of their crappy Lisence Check (*With due respect to google devs*):D
[Java for Android App Development] m11kkaa:
https://android.googlesource.com/pl...re/java/android/content/pm/PackageParser.java
[Java for Android App Development] m11kkaa:
I think, google should have made the dex language more assembler like(don't preserve functions, classes, ...).

This open platform seems to have some problems with closed source software :D

Actually the License check was good - but then it got cracked :D

I think that everything google will do to protect apps will be cracked. It would be good to use non-standard protections so the hackers have to manually hack every app which takes way more time.
[Java for Android App Development] sak-venom1997:
may be there is scope for it in the ART !

dalvik was designed with the sole intention of lowering the memory footprint of loaded classes
[Java for Android App Development] m11kkaa:
ART won't change it because they use the dex code, too.

They can't provide the art compiled binaries because they aren't platform independent and will break compatibility for non-ART devices.
[Java for Android App Development] tudor007:
Apk copy/extracting/backing up protection

Hi.

My story is a bit different: the apk is not for sale on PlayStore or any other marketplace. Is installed by myself on every cell phone that I sell.

I am trying to protect an apk from being copied/extracted/backed up off the phone and installed later, on another phone.

I have to mention that the app is not (and will not be) for sale on PlayStore or on any web store, being sold along with the phone. This is why I can not use apk protection offered by GooglePlay, which is anyway cracked at his time.

But I want to take advantages on this situation: every single phone will pass trough my hands (I will install myself the app) before hitting users. How can I use this advantage in order to protect my app?

At this time my app is not visible in Running Apps drawer, is having a default Android icon and the name is disguised in something pretty innocent. GUI access by dialing a code. No worries, is not malware but only a security app regarding GSM connection security.

Also, is running as a system app, which make it invisible for apps like Astro file manager, thus impossible to copy/back up by such file manager apps. Unfortunately there are a bunch of system app managers, that can convert a system app on user app, and then copying the apk file is easy.

I know that security sucks big time when it comes about Android OS, but I am determined to find a way to protect my app.

I know also that even a licensing scheme based on IMEI, WiFi MAC or Bluetooth MAC addresses can be bypassed by some skilled crackers. This values can be spoofed or even null.

I have tried apk encryption. Doesn't work: some apps supposed to encrypt other Android apps are actually encrypting only app libraries, not the apk file itself. By encrypting apk file, the app obviously will not work.

Code obfuscation is not an option as long the app can be duplicated off the phone and installed later on another phone.

The last idea that I had: pulling some app resources (like drawables) from a server. What do you think?

At this time I'm in a dead end. I have no more ideas how to protect my app. That's why I need your help. Can you give me please some feasible ideas, based on your huge experience?

Thank you very much for your time.
[Java for Android App Development] sak-venom1997:
art runs binaries :confused: ???

i thought i worked in a similar fashion to jrockit

n i guess if we can provide three different apks(one for ARM,one for MIPS and one for x86)

we could do the same with dalvik and art
[Java for Android App Development] m11kkaa:
ART converts apps to executable binaries.

The resulting file won't even work with different versions of android.

http://www.xda-developers.com/android/the-art-of-android/
[Java for Android App Development] sak-venom1997:
ok ! thanks for the info :)
[Java for Android App Development] tudor007:
external resources

[MENTION=5106366]sak-venom1997[/MENTION]:

Can I use external resources (like pulling app graphics and even libraries) from a server - other that GooglePlay-, along with IMEI filter in order to protect my app from sharing, once installed on the phone?
[Java for Android App Development] m11kkaa:
yes, so-files(native libs) are easy. dex classes are a little bit more complicated but it's possible, too(with a custom class loader).

But I think this would make the app even more insecure since they just need to remove/exchange the library. It's better to hide the code deeply inside your spaghetti code :)
[Java for Android App Development] sak-venom1997:
yes indeed as [MENTION=3530648]m11kkaa[/MENTION] said it could make the app more vernuralble what i intended was a file integrity check like in BitTorrent protocol each peice has an assosiated chesum but that is validated on the client side but for our apps I'd want that to be on the server side.

Now this idea seems superflous as it fails to solve the issue that this code too could be just removed from.the dex.
[Java for Android App Development] tudor007:
PIN code + code obfuscation

At this time, my app is protected by a PIN code (needed at installation time) along with obfuscation. Is that a decent protection? How can I improve this?

Please remember that my goal is only to protect my app from being copied off the phone and installed later, on another phone.

Once again, many thanks to m11kkaa and sak-venom1997!
[Java for Android App Development] m11kkaa:
I think that it always depends on the obfuscation and the complexity of the protective code.

Because as already said - in theory u can remove any protection.

Which app are you talking about? If you've released it already it may be worse searching the internet for cracked versions to check how they cracked it.

If there aren't any/much cracks for your apps and/or the download numbers of these are too small in comparison too the paid downloads it may not be worth investigating too much time into this topic.

Also, a PIN protection could be annoying for users and u may loose more users than u gain.
[Java for Android App Development] tudor007:
Re:

I have to mention that the app is not (and will not be) for sale on PlayStore or on any other marketplace. Also, is not available for free download anywhere on the Internet: is not released, and will not be ever. The app is being sold along with the phone (pre-installed on the phone by myself).

I want to take advantages on this situation, in order to protect my app: every single phone will pass trough my hands (I will install myself the app) before hitting users.

At this time, app is asking for PIN only on installation time. User will never know this PIN since I will install myself the app on the phone.

Once again, thanks for helping me out.
[Java for Android App Development] giuliomvr:
What does your app offer? If it's always the same code(hardcoded), it will be easy to find in the code, even if obfuscated, but keep in mind that you need some knowledge to perform this, and of course you really want to put some work in it.
[Java for Android App Development] m11kkaa:
Does anyone know how to configure proguard more aggressive?

this code:

private void x() {Log.e(TAG, "X");}
private void y() {Log.e(TAG, "Y");}

@Override
protected void onCreate(Bundle savedInstanceState) {
x(); y();
}

could be simplified to this:

@Override
protected void onCreate(Bundle savedInstanceState) {
Log.e(TAG, "X");
Log.e(TAG, "Y");
}

The C code optimizer would do that. but proguard doesn't(I just tried it)
[Java for Android App Development] tudor007:
Re:

Thx GalaxyInABox!

My app is having this functions:

- random number generator (persistent after phone reboot or exit app) - kinda Token generator;

- displaying some GSM values (MCC, MNC, IMEI, IMSI, CellID, LAC, neighboring cell, GSM user position on the map (pulling this map from a server). The app need Internet connection only when GSM location feature is active.

Every single phone will pass trough my hands (I will install myself the app) before hitting users. How can I take advantages on this situation?

I have managed to block access to phone Settings by using a "protect apk" app from GooglePlay. User need to type an access code in order to open Settings GUI, but this will be pretty annoying by obvious reasons. Do you know a way to protect only Apps section from Settings? There ois a custom ROM that can do like this?
[Java for Android App Development] m11kkaa:
Do you own the phones? if yes you could try to prevent root, adb, and bootloader unlocks somehow.
[Java for Android App Development] tudor007:
agressive

What would do this?

In my opinion aggressive means for example destroying bootloader. Can be achieve this?