Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LuckyPatcher easily bypasses simple LVL implementation #13

Open
franciscofranco opened this issue Feb 16, 2017 · 7 comments
Open

LuckyPatcher easily bypasses simple LVL implementation #13

franciscofranco opened this issue Feb 16, 2017 · 7 comments
Labels
enhancement New feature or request

Comments

@franciscofranco
Copy link

Hi Javier. Thanks for your efforts. As much as we try to protect our apps other 3rd party tools keep finding new ways to fuck us up.

For example LuckyPatcher detects this string https://github.com/javiersantos/PiracyChecker/blob/master/library/src/main/java/com/google/android/vending/licensing/LicenseValidator.java#L105
and simply returns true.

My suggestion is simply change the methods name, move strings around, just make it a tad harder for automated programs to understand what's going on. Seems simple, but it'll bypass some of the automated scripts. And yes, it'll work even if the app is properly obfuscated etc.

@jahirfiquitiva
Copy link
Collaborator

jahirfiquitiva commented Mar 12, 2017

@franciscofranco

Hi Francisco, what LuckyPatcher detects is the CHECK_LICENSE permission.

In one of my apps, I have been using this library for a long time. This library didn't have that permission on versions 0.0.1 or 0.0.2, but I added it and it was merged in 0.0.3

This wasn't on purpose. I just didn't know about this then.

Anyways, I made a fork of the library removing it again, and have tested and Lucky Patcher says it isn't "patcheable", and the library still checks for license properly ...

I saw your other issue regarding checking if certain apps are installed. I have been working on a library, that does the same as PiracyChecker, (it even uses its code) but also checks those apps you mentioned in the other issue (the ones in the link to the xda thread).

It works fine for me.

I don't mind adding those extra checks I made, to the source code of my fork of PiracyChecker and creating a Pull Request.

I'm almost sure @javiersantos would merge it since we know each other for some time already, and he might be quite busy with other projects.

Anyways, my code isn't the best, I tried making it "not easy to understand" by complicating the code read, which isn't neither the best practice nor an actual thing to avoid pirates, but still I did it.

So, knowing how good of a developer you are, and considering your interest in this library and maybe these things, I wanted to ask you if you would like to check my code and help me improve it a bit, so when I merge the changes it is clean and good enough.

Let me know what you think about this. Thanks in advance.

@franciscofranco
Copy link
Author

franciscofranco commented Mar 12, 2017

297f180 looks fine to me, and it's a good idea to remove some automatic patching capability.

82ae6a4 this looks good for me too. Although lucky patcher guys can easily just parse this new values as well, it breaks the automation part.

e7d4756 looks fine to me too!

All in all this will help a lot. As long as automated processes can't parse this lib I'm happy. I'm sure all the other users will be happy too.

Can you push 0.0.4? Would like to try these changes 👍

@javiersantos
Copy link
Owner

javiersantos commented Mar 13, 2017

I have just released the v1.0 update. Thank you @jahirfiquitiva for your PR and @franciscofranco for your suggestions and testing!

dependencies {
    compile 'com.github.javiersantos:PiracyChecker:1.0.1'
}

@jahirfiquitiva
Copy link
Collaborator

@javiersantos

No problem. Always glad to help. 😀

@Jasi2169
Copy link
Contributor

Jasi2169 commented Apr 3, 2017

franciscofranco no changing names wont help you to be honest,the tools does not even work on strings or as the other guys saying CHECK_LICENSE permission,permission is checked just to show the app has license library,you can still patch by removing license verification,there is other ways which you guys do not know which can protect it properly from these tools and checks but i am not in mood to let you know,the library is good but is 5 steps back in security but gives a good idea to people.

Good Luck

@franciscofranco
Copy link
Author

franciscofranco commented Apr 3, 2017

@Jasi2169 Thank you for the very informative and detailed post. None would be possible without your infinite wisdom and profound knowledge. Please grace us with your presence and enlightment in the near future. Luckily my mood was in good shape to even bother to reply.

Repository owner deleted a comment from LelandBowen Apr 13, 2020
@apkunpacker
Copy link

apkunpacker commented Oct 21, 2020

No offense to my master Jasi2169 he is the greated guy i ever seen. lucky patcher still work even if you guys randomize things specially against xposed based emulation . you can slow down root based user from emulating though . to make it hard - do hard obfuscation on 2 things -

  1. android.content.Intent ;- > its init method take 1 string argument which have all intent list like
    "com.android.vending.billing.InAppBillingService.BIND" or License intent , if lucky patcher found it then it replace it with own intent action and then it check to setPackage , if setPackage(" ") = "com.android.vending" it replace it with its own package name and then rest of all purchase /LVL handled by lucky patcher
  2. so encrypt those 2 thing - intent name and setpackage name . dont try to use base64 encode them , base64 will be catched by lucky patcher

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants