Android 防止幸运补丁/游戏许可的方法

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/10585961/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-20 04:15:20  来源:igfitidea点击:

Way to protect from Lucky Patcher / play licensing

android

提问by Marco

I'm about to release an application and don't want it pirated... There are apps like luckypatcher which crack the application for you even if you have licensing...

我即将发布一个应用程序,不希望它被盗版......即使你有许可,也有像luckypatcher这样的应用程序为你破解应用程序......

Anyone knows how to protect from this?

任何人都知道如何防止这种情况?

回答by zeroprobe

To stop your app from being distributed and repackaged in cracked form, see the below for a signature check. Then at least the only people who can make your app work are those who have got LuckyPatcher installed. Once LuckyPatcher creates a modified APK, the signature is changed.

要阻止您的应用以破解形式分发和重新打包,请参阅下面的签名检查。那么至少只有那些安装了 LuckyPatcher 的人才能使您的应用程序正常工作。LuckyPatcher 创建修改后的 APK 后,签名会更改。

You need to find out what your signature is when you have run a release version. In the example below it's -343553346 .

当您运行发布版本时,您需要找出您的签名是什么。在下面的示例中,它是 -343553346 。

String sigChk = MySigCheck.MySigCheck(context);
if (sigChk.equalsIgnoreCase("Y")){
    handle signature pass
}

Create a class

创建一个班级

public class MySigCheck {
public static String MySigCheck(Context context) {
    String sigChk = "B";

    Signature[] signature = new Signature[0];

    try {
        signature = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures;

        Log.d("yourapp", Integer.toString(signature[0].hashCode())); << Prints your signature. Remove once you know this and have changed it below.

    } catch (PackageManager.NameNotFoundException e) {
        e.printStackTrace();
    }

    if (signature[0].hashCode() == -343553346){
        sigChk = "Y";
    }

        return sigChk;
    }
}

回答by Idistic

The short answer is not really.

简短的回答不是真的。

You can watch a google IO chat about some best practices for using licensing API's etc Google IO Anti Pirate

您可以观看谷歌 IO 聊天,了解有关使用许可 API 等的一些最佳实践Google IO Anti Pirate

I know there is another talk about general patterns to thwart lazy pirates as well but can't seem to find the URL.

我知道还有另一个关于阻止懒惰海盗的通用模式的讨论,但似乎无法找到 URL。

In general if your protection is dependent on if/then logic all someone has to do is patch the code and invert that logic or bypass it all together which is pretty easy in Java.

一般来说,如果您的保护依赖于 if/then 逻辑,那么所有其他人所要做的就是修补代码并反转该逻辑或将其全部绕过,这在 Java 中非常容易。

You can make it harder by obfuscating where you are doing this, doing it in many places, doing it randomly, and adding pro-guard obfuscation etc. to dissuade casual hackers.

你可以通过混淆你在哪里做这件事,在很多地方做这件事,随机做,并添加亲卫混淆等来阻止随意的黑客,从而使事情变得更难。

Even server side logic is simple to bypass unless the return package is used in some way (like an encryption token that is synced with the user or phone information to unlock content, or a user id verification scheme that is required to access online community content etc.)

甚至服务器端逻辑也很容易绕过,除非以某种方式使用返回包(例如与用户或电话信息同步以解锁内容的加密令牌,或访问在线社区内容所需的用户 ID 验证方案等) .)

In the end if someone is determined and has skills they can get around all of it and unless you are losing serious revenue it's hardly worth losing sleep over in my opinion, which is a problem we ALL need to have!

最后,如果有人下定决心并拥有技能,他们就可以解决所有问题,除非您正在损失严重的收入,否则在我看来几乎不值得失眠,这是我们所有人都需要解决的问题!

After doing this for 20 years (commercial development) my approach is to make it difficult by using the above patterns, and change it occasionally. That weeds out the lazy pirates.

这样做了20年(商业开发),我的方法是通过使用上述模式使其变得困难,并偶尔更改它。这样就淘汰了懒惰的海盗。

Then forget about it and concentrate on making an application that is worth stealing by the pro-pirates.

然后忘记它并专注于制作值得盗版者窃取的应用程序。

MY APPROACH

我的方法

My app's are mostly content driven.

我的应用程序主要是内容驱动的。

In general if someone buys content it gets encrypted using tokens server side and un-encrypted using the same (which are not stored but generated each session using device and user tokens, which only makes it a bit harder to spoof honestly)

一般来说,如果有人购买内容,它会使用服务器端的令牌进行加密,并使用相同的令牌进行未加密(这些内容不会存储,而是使用设备和用户令牌生成每个会话,这只会让诚实欺骗变得有点困难)

I can then track access by user/device pairings. The downside for the hacker is that they have to pay once, and if their tokens are suddenly getting used beyond reasonable limits it alerts me to the fact, and I can turn off that account if I want to ( and I have )

然后我可以通过用户/设备配对跟踪访问。黑客的缺点是他们必须支付一次,如果他们的代币突然超出合理限制使用,它会提醒我注意这一事实,如果我愿意,我可以关闭该帐户(并且我有)

I have found that socially people are far less likely to let someone use information to cheat if it's associated with them (though it has happened) and it will come back on them.

我发现社交方面的人不太可能让某人使用与他们相关的信息来作弊(尽管它已经发生了)并且它会回到他们身上。

I still follow all of the advice from IO/Dev Blog etc. and if I detect tampering then I inform the user and then let it go for N period of time so they can contact me or self correct.

我仍然遵循 IO/Dev 博客等的所有建议,如果我检测到篡改,那么我会通知用户,然后将其放置 N 时间段,以便他们可以与我联系或自我纠正。

I also never kill an app, but I do tell the user they are using malware, and ask them if they really trust the person that stole it with their data etc. those kind of pop up's have bit'd messages so simple string searches won't work etc. and throw a scare into people

我也从不杀死应用程序,但我确实告诉用户他们正在使用恶意软件,并询问他们是否真的信任窃取其数据的人等。那些弹出窗口的消息很简单,所以简单的字符串搜索就赢了不工作等等,吓唬人

I also have a way to send a poison token set to the device that will in essence lock out any data they have accumulated with the device unless I unlock it BUT you better be really sure they are thieves before you go nuclear on them.

我还有一种方法可以向设备发送一组毒物令牌,该令牌基本上会锁定他们在设备上积累的任何数据,除非我将其解锁,但您最好在对它们进行核攻击之前确定它们是小偷。

Also don't discount analytic's as a way to detect, and determine the proper action to take when a pirated copy is detected.

也不要轻视分析作为一种检测方式,并确定在检测到盗版时采取的正确行动。

Follow the guidelines the blog post and IO mentioned, then be creative in applying them, and mixing a some what unique solution, then change it every so often to give the pirates fits.

遵循博客文章和 IO 提到的指导方针,然后创造性地应用它们,并混合一些独特的解决方案,然后经常更改它以适应海盗。

回答by Oasis Feng

Base on the fact that LuckyPatcher uses odex replacement for its hacking purpose. I think the modest way to defeat its current implmentation is to compile your important piece of code in separate dex, and load it via DexClassLoader.

基于 LuckyPatcher 使用 odex 替换来进行黑客攻击这一事实。我认为击败其当前实现的适度方法是在单独的 dex 中编译您的重要代码段,并通过 DexClassLoader 加载它。

Ref: http://android-developers.blogspot.pt/2011/07/custom-class-loading-in-dalvik.html

参考:http: //android-developers.blogspot.pt/2011/07/custom-class-loading-in-dalvik.html

回答by PerracoLabs

The way I do it, is to keep an eye in the package name of lucky patcher, in case they change it. So at runtime I check if it is installed, and I simply do not allow to use my app if this one is actually installed on the phone, even if they purchased the app. I warn the user and kill my app. So he will have to find another way to crack it. The worse I can get is that he has to buy my app and will sure put 1 bad review. But honestly, I prefer 1 bad review from a hacker than 1000 pirated copies a day.

我这样做的方法是留意幸运补丁程序的包名,以防他们更改。因此,在运行时我会检查它是否已安装,如果手机上确实安装了这个应用程序,即使他们购买了该应用程序,我也不允许使用我的应用程序。我警告用户并杀死我的应用程序。所以他将不得不寻找另一种方法来破解它。我能得到的更糟糕的是,他必须购买我的应用程序,并且肯定会留下 1 条差评。但老实说,我更喜欢黑客的 1 条差评,而不是每天 1000 份盗版。

回答by Barak

Only way I have heard of is to do server verification... have your app contact a server and verify they purchased your app.

我听说过的唯一方法是进行服务器验证...让您的应用联系服务器并验证他们购买了您的应用。

This is about in-app billing through Google, Why is signature verification on remote server more secure than on device?

这是关于通过 Google 进行的应用内计费,为什么远程服务器上的签名验证比设备上的更安全?

Some good info on the dev site about Google Play in general hereand in-app billing specifically here

开发网站上的一些关于 Google Play 的一般信息和应用内结算特别在这里

Unfortunately I'm not finding much else...

不幸的是,我没有找到更多...

回答by Gwalchgwyn

As a professional IT engineer and general power user (Linux, Windows, Android, OS X, iOS) as comfortable in command line interfaces as graphical, I use the tools at my disposal to achieve my ends. I could not imagine using an Android device that isn't rooted, and I'm normally loaded with a plethora of utilities that require it. At the very least, I enjoy the freedom of controlling the obligatory bloatware that normally comes with my favourite device, inserting my own system apps, and making legitimate modifications for aesthetics, comfort, and convenience.

作为一名专业 IT 工程师和普通高级用户(Linux、Windows、Android、OS X、iOS),既熟悉命令行界面又熟悉图形,我使用可用的工具来实现我的目标。我无法想象使用没有 root 的 Android 设备,而且我通常加载了大量需要它的实用程序。至少,我可以自由地控制我最喜欢的设备通常随附的强制性膨胀软件,插入我自己的系统应用程序,并为美观、舒适和方便进行合理的修改。

I have been forced down some dodgy avenues just to achieve proper functionality in apps whose authors choose to cripple rooted users. Being told that my device has 'unauthorised modifications' by (for instance) Virgin TV Anywhere makes my blood boil, and I'll happily break their code and contravene some license agreements if it's the only option available to me in pursuit of expected functionality.

我被迫走上了一些狡猾的道路,只是为了在作者选择削弱 root 用户的应用程序中实现适当的功能。被告知我的设备有(例如)Virgin TV Anywhere 的“未经授权的修改”让我热血沸腾,如果这是我追求预期功能的唯一选择,我会很乐意破坏他们的代码并违反一些许可协议。

In this regard, I agree that you're inviting a lot of users, whether through indignant spite or mere utility, to foil your efforts should you choose such a draconian path as the aforementioned media application. This might even encourage piracy of your app altogether when 'fixed' versions of your code become more prevalent as torrents than your legitimate sales.

在这方面,我同意您正在邀请许多用户,无论是通过愤慨的怨恨还是单纯的效用,如果您选择上述媒体应用程序这样严厉的途径来挫败您的努力。当您的代码的“固定”版本变得比您的合法销售更普遍时,这甚至可能会助长您的应用程序的盗版。

Personally, I always go for the paid option, even when I'm forced to swallow my sense of security and break it with tools I scarcely trust in order to make it work. For many, though, the initial exposure they'll have to your product is through nefarious channels, and they're hardly going to go paying for the legitimate and hopelessly crippled version.

就我个人而言,我总是选择付费选项,即使当我被迫吞下我的安全感并用我几乎不信任的工具打破它以使其工作时也是如此。然而,对于许多人来说,他们最初接触你的产品是通过邪恶的渠道,他们几乎不会为合法的、无可救药的残缺版本买单。

I understand why some coders are forced to make these choices, and its good to see sensible questions asked about the right way to protect intellectual property.

我理解为什么有些程序员被迫做出这些选择,很高兴看到人们就保护知识产权的正确方法提出了明智的问题。

It is even more reassuring to see sense in the answers.

在答案中看到意义更令人放心。

Just my tuppence.

只是我的头巾。

回答by Josh

If they have a rooted device the can hide the su binary to use the app too checking root is the best method unless your can be used with the non rooted version of freedom and then you will need to fix that. Putting a check for hacking tool like game killer is going to stop lazy people but not one that can decompile an change the string to another.

如果他们有 root 设备,则可以隐藏 su 二进制文件以使用该应用程序,检查 root 是最好的方法,除非您可以与非 root 版本的自由一起使用,然后您需要修复它。检查像游戏杀手这样的黑客工具将阻止懒惰的人,但不会阻止那些可以反编译将字符串更改为另一个的人。

回答by esideli

Lucky Patcher work in rooted device. i check the phone is rooted or not.in my first activity i check if phone is root, my app locked Otherwise my app opening.

Lucky Patcher 在 root 设备中工作。我检查手机是否root。在我的第一个活动中,我检查手机是否root,我的应用程序被锁定,否则我的应用程序打开。

check is root with bellow method :

检查是根与波纹管方法:

    private static boolean isRooted() {
    return findBinary("su");
}



public static boolean findBinary(String binaryName) {
    boolean found = false;
    if (!found) {
        String[] places = {"/sbin/", "/system/bin/", "/system/xbin/", "/data/local/xbin/",
                "/data/local/bin/", "/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/"};
        for (String where : places) {
            if ( new File( where + binaryName ).exists() ) {
                found = true;
                break;
            }
        }
    }
    return found;
}