My idea isnt hacker proof, but might remove some of the interest for hacking the game.
Freemium model
1) Make the first 5-10 levels free so people can learn the game and have some fun without paying. Less will want to hack the first level and the game will spread even further by Freemium model.
Shareware/clustered levelpacks
2) Let part of the game levels or logic stay online. Eg. when reaching for level 5 or 10 or 15, then download small parts for the game, and every time submit the progress-log from the game and validate this against possible values + hashcodes. This could perhaps make it possible to automatically close down of hacked accounts.
Stealth cheater protection
3) You could also just count "small warning flags" that you place around in the game. Dont just check for the "validation" in the beginning, no build these flags into the game logic itself. Dont make it break the gameplay, because then noone will look for it. Then when the user reached the end of level monster, check if there were any logged warning flags. These will not show up inside the game, so the unknowing user with a hacked edition could be playing for hours/days and suddently realize that he/she couldnt finish the game or advance to next level, because the game had a "bug". What the user didnt know was that this bug only occures on hacked clients.
Conclusion
Be smarter than the crackers. Fool them into thinking the job was done. Make a copyprotection and know that the more advanced crackers will be able to remove it. But they probably dont want to play 50 levels to check if the crack also works all the way.
Once they realize this problem, they might start to crack it too. But if you break the game up into level-packs, you can still validate between each pack download. So once you receive hacked client hash data, then just execute an exeception and crash the game on the client. Whoops the game crashed. Dont tell its because its hacked. A program error can happend. :-)
Again, its not hacker proof. But it might annoy them enough to move on to the next game. Lastly, you could also put out regular updates for the game and only the latest version should be able to "post the records" etc. so the active users would have to update to keep in the loop.
I have been doing some apk decompiling and hacking for a while (not warez, but mods and hacks mostly to the google apps and the android framework, always abiding xda-developers policies).
Once you learn to read smali, it is almost as reading the original java code (but with way more LOCs). So, any code you add to check for keys can be found and deleted or replaced. You don't even need to recompile each time to eliminate more than one (some searches do miracles to find similar pieces of code) and, even if compilation/recompilation cycles are needed to find them, it's just a matter of one or two minutes to decompile: everything is automated by apktool and even more by apkmanager.
Having said that, my suggestion to you is to implement some sort of online scoring table or similar, and when the user looks at the score table online, you can check the hash code you implemented and compare it with the associated gmail account. That way you can report the hack to google and send a nasty message to the user of the warez, explaining why that is illegal.
Of course, a new hack could be implemented to eliminate the scoring table, but that would reduce the interest for the warez.
Good luck.
Update
After researching to answer this question: Injecting code into APK (really about the Amazon DRM mechanism), I can tell a little bit on how Amazon is protecting the apps: it includes methods for checking for the installation validity everywhere (you can see an example of how they do it in my answer to that question). This will make any attempt to hack an app not very difficult, but extremely tedious. I believe that is a strong point: hackers won't want to spend so much time doing so many repetitive tasks: it's not challenging and it's boring. The main flaw I see in that approach is the possibility to hack the Amazon app itself to always return a valid answer, of course. But, if you mix your current hash checks with some sort of online check scattered among your methods, I believe the chances of it getting hacked may be drastically reduced.
I know you're not really into obfuscation, but I really need to react to this:
From here, I don't want to obfuscate our code as I have seen it broken before. I want something a little more solid, and I also want to learn how to do this properly.
ProGuard is very reliable in my experience, and this although I use a couple of advanced features such as AIDL and some native code which calls Java method.. It takes a little work to read the documentation and do things properly, but once you're there ProGuard is extremely reliable and also optimizes your app.
Custom security/cryptographic tricks are good, but without obfuscation it's like throwing a stone in the water in my humble opinion.
I've used ProGuard in production for many months, and it just works flawlessly.
If you're into learning, then read the ProGuard manual carefully, experiment with it, and inspect its output logs.
拥有庞大的真实用户活跃用户群僵尸网络，使得归档类型的游戏玩家想要玩游戏 - 如果你玩游戏，而且看起来很酷，那么 Avarage Joe 也会想玩。如果 Avarage Joe 玩，那么他的朋友可能也想玩，而你可能不会关心其他任何事情，然后比他/她的朋友更好，消磨时间或有话可聊。普通乔的朋友很可能愿意花钱来变得比乔更好，但你更愿意投资一些能让他们变得更好的东西。
Chance, that there are more talented programmers then YOU (applies for all programmer), is 100%. And if that is true, you can not fix hacking. But you can spend as much time and effort on it to go bankrupt.
If you want to make some serious money you need to do some research on your target user group, and behavioral science. You need to make users playing that bring in new money, and thats it.
Besides, you got it all wrong. Hackers are most active members of your user base, thy just behave in a way you did not intend them to.
Take Zynga games on Facebook for example, do you think thy get hacked? - Sure, and about +100000 players only play, because thy can use bots, that automate everything.
Having huge active user base botnet of actual people, makes archiver type gamers want to play the game - and if thy play, and it looks cool, then Avarage Joe will also want to play. If Avarage Joe plays, then his friends might want to play, and thy probably will not care anything other, then being better then his/her friend, killing time or having something to chat about. Avarage Joe friends will most likely be willing to pay to be better then Joe, but rather thy would like to invest in something that makes them able to be better.
Besides if the real value is playing the game for free, then users who use the free hacked version, will most likely never would have payed for it. But thy are Avarage Joes and their friends just might. So this is like the cheapest commercial you can have. If you want to make money of your large userbase, then just make new versions of the game with small changes to levels and graphics.
What an interesting and disturbing question. :-) As an exercise, you might try releasing an app through Amazon; they have their own DRM mechanism; I wonder if it works any better than ProGuard...
One of the key elements in my opinion is to spread out the code so it's not all in one place. If you have a function called LicenseChecker.checkLicense() which retrieves the license and checks it, you can be sure it will be disabled promptly.
The one advantage you have is that the crackers cannot see the comments of your code (and, if you obfuscate, method/variable names), so come up with something weird. In the onCreate() of one activity, you get the license ID. In onResume(), you get another value to check it against. Maybe create a thread and do some checks there. And then, some other irrelevant piece of code (maybe the player control) might pick up the value and compare it and store the result somewhere. Then three other irrelevant pieces of code will all independently check that value and disable your application if it doesn't match.
Now I should say upfront that this can cause headache for yourself - obviously, cluttered, nasty code is harder to debug and prone to cause errors. Worst case, you create false positives in legitimately purchased applications.
And, of course, everything can be reverse-engineered - once the crackers find the place where the app is disabled, they trace back the value that's being read from. They could then trace back where it's being stored, and trace that back..... or, much easier, they can just disable the final check (which is why I recommended 3 different places, all triggering delayed). Security is only as good as the weakest link.
You will not be able to stop piracy. Your best bet is to delay the spreading of a pirated copy until the initial hype about your app has calmed down.
First, I do NOT consider myself a pro in the SW security field whatsoever, but:
I think an important thing is to let the application be dependent in some part(s) on the signature check. Don't let it affect immediately, but let it set some flags or change some values. later on, use those flags, check them, let the absence/incorrectness of them cause an exception of some kind which will terminate the application maybe. As long as the signature check is only relevant at the moment, it is easy to bypass it, to remove the line, once it touches more areas in the code, your application becomes harder (or less easier...) to hack. Also as I see it, not all checks should call the same routine for the sanction, because this will also make it easy to find the protection mechanism and terminate it.
Of course, the sanction to take in cases of illegal SW may vary, you might want to crash the application when used illegally, but you might as well want to keep it running, and only send message that asks the user to buy a legal copy of the application.
If this is just what you didn't want to hear, then I'm sorry for your time :)
Android users are just going to have accept the pain of constant phone-homes. The only secure Android app is an always-connected Android app.
This is, in large part, due to Google's refusal to lock-down the installation, like Apple has. On IOS you have to jailbreak the phone. On Android you can load any APK on a stock, factory install.
Keep some/most/all your content on the server; deliver it in chunks; validate the license/session on each call.
It will be incredibly hard to inhibit this kind ov behavior. Anything that is handled on the client-side is hackable using APK decompilation and modding, memory editing with software such as Game Guardian ect.
The only way I can see how partially getting around it, would be to make an online game instead. Or have certain functions handled online. Or if anti-tamper encryption like denuvo ever is available for Android / iOS.
发布评论
评论（11）
我的想法并不是防黑客的，但可能会消除一些黑客攻击游戏的兴趣。
免费增值模式
1) 前 5-10 个关卡免费，这样人们无需付费即可学习游戏并享受乐趣。想要破解第一关的人会越来越少，游戏将通过免费增值模式进一步传播。
共享软件/集群关卡包
2）让部分游戏关卡或逻辑保持在线。例如。当达到 5 级、10 级或 15 级时，下载游戏的小部分，每次提交游戏的进度日志，并根据可能的值 + 哈希码进行验证。这也许可以自动关闭被黑的帐户。
隐形作弊者保护
3) 您还可以只计算您在游戏中放置的“小警告标志”。不要只是在开始时检查“验证”，不要将这些标志构建到游戏逻辑本身中。不要让它破坏游戏玩法，因为那样就没有人会寻找它。
然后，当用户到达怪物关卡末尾时，检查是否有任何记录的警告标志。这些不会显示在游戏中，因此使用破解版本的不知情用户可能会玩几个小时/几天，然后突然意识到他/她无法完成游戏或晋级到下一个级别，因为游戏有一个“错误”。用户不知道的是，这个错误只发生在被黑的客户端上。
结论
比黑客更聪明。愚弄他们，让他们认为工作已经完成。进行版权保护，并知道更高级的破解者将能够删除它。但他们可能不想玩 50 个关卡来检查破解是否也能一直有效。
一旦他们意识到这个问题，他们可能也会开始解决它。但是，如果您将游戏分解为关卡包，您仍然可以在每个包下载之间进行验证。因此，一旦您收到被黑的客户端哈希数据，只需执行异常并使客户端上的游戏崩溃即可。哎呀游戏崩溃了。不要告诉它，因为它被黑了。可能会发生程序错误。 :-)
再说一遍，它不能防黑客。但这可能会让他们恼火到足以继续下一场比赛。最后，您还可以定期发布游戏更新，并且只有最新版本才能“发布记录”等，因此活跃用户必须更新才能保持循环状态。
My idea isnt hacker proof, but might remove some of the interest for hacking the game.
Freemium model
1) Make the first 5-10 levels free so people can learn the game and have some fun without paying. Less will want to hack the first level and the game will spread even further by Freemium model.
Shareware/clustered levelpacks
2) Let part of the game levels or logic stay online. Eg. when reaching for level 5 or 10 or 15, then download small parts for the game, and every time submit the progress-log from the game and validate this against possible values + hashcodes. This could perhaps make it possible to automatically close down of hacked accounts.
Stealth cheater protection
3) You could also just count "small warning flags" that you place around in the game. Dont just check for the "validation" in the beginning, no build these flags into the game logic itself. Dont make it break the gameplay, because then noone will look for it.
Then when the user reached the end of level monster, check if there were any logged warning flags. These will not show up inside the game, so the unknowing user with a hacked edition could be playing for hours/days and suddently realize that he/she couldnt finish the game or advance to next level, because the game had a "bug". What the user didnt know was that this bug only occures on hacked clients.
Conclusion
Be smarter than the crackers. Fool them into thinking the job was done. Make a copyprotection and know that the more advanced crackers will be able to remove it. But they probably dont want to play 50 levels to check if the crack also works all the way.
Once they realize this problem, they might start to crack it too. But if you break the game up into level-packs, you can still validate between each pack download. So once you receive hacked client hash data, then just execute an exeception and crash the game on the client. Whoops the game crashed. Dont tell its because its hacked. A program error can happend. :-)
Again, its not hacker proof. But it might annoy them enough to move on to the next game. Lastly, you could also put out regular updates for the game and only the latest version should be able to "post the records" etc. so the active users would have to update to keep in the loop.
我已经做了一些 apk 反编译和黑客攻击一段时间了（不是 warez，而是主要针对 google apps 和 android 框架的 mods 和 hacks，始终遵守 xda-developers 政策）。
一旦你学会阅读 smali，它几乎就像阅读原始的 java 代码一样（但是有更多的 LOC）。因此，您添加的用于检查密钥的任何代码都可以找到并删除或替换。您甚至不需要每次都重新编译来消除多个（某些搜索可以奇迹般地找到相似的代码片段），并且即使需要编译/重新编译周期来找到它们，也只需一两分钟的时间反编译：一切都由 apktool 自动化，甚至由 apkmanager 自动化。
话虽如此，我给你的建议是实现某种在线评分表或类似的，当用户在线查看评分表时，你可以检查你实现的哈希码并将其与关联的 gmail 帐户进行比较。这样你就可以向谷歌报告这次黑客攻击，并向该软件的用户发送一条令人讨厌的消息，解释为什么这是非法的。
当然，可以实施新的黑客攻击来消除评分表，但这会降低软件的兴趣。
祝你好运。
更新
经过研究回答这个问题：将代码注入APK（关于 Amazon DRM 机制），我可以稍微介绍一下 Amazon 如何保护应用程序：它包括检查安装有效性的方法随处（您可以查看他们如何做到这一点的示例在我的回答中这个问题）。这将使任何破解应用程序的尝试变得不是很困难，但极其乏味。我相信这是一个强点：黑客不想花这么多时间做这么多重复性任务：这没有挑战性而且无聊。当然，我认为这种方法的主要缺陷是有可能破解亚马逊应用程序本身以始终返回有效答案。但是，如果您将当前的哈希检查与分散在方法中的某种在线检查混合在一起，我相信它被黑客攻击的机会可能会大大减少。
I have been doing some apk decompiling and hacking for a while (not warez, but mods and hacks mostly to the google apps and the android framework, always abiding xda-developers policies).
Once you learn to read smali, it is almost as reading the original java code (but with way more LOCs). So, any code you add to check for keys can be found and deleted or replaced. You don't even need to recompile each time to eliminate more than one (some searches do miracles to find similar pieces of code) and, even if compilation/recompilation cycles are needed to find them, it's just a matter of one or two minutes to decompile: everything is automated by apktool and even more by apkmanager.
Having said that, my suggestion to you is to implement some sort of online scoring table or similar, and when the user looks at the score table online, you can check the hash code you implemented and compare it with the associated gmail account. That way you can report the hack to google and send a nasty message to the user of the warez, explaining why that is illegal.
Of course, a new hack could be implemented to eliminate the scoring table, but that would reduce the interest for the warez.
Good luck.
Update
After researching to answer this question: Injecting code into APK (really about the Amazon DRM mechanism), I can tell a little bit on how Amazon is protecting the apps: it includes methods for checking for the installation validity everywhere (you can see an example of how they do it in my answer to that question). This will make any attempt to hack an app not very difficult, but extremely tedious. I believe that is a strong point: hackers won't want to spend so much time doing so many repetitive tasks: it's not challenging and it's boring. The main flaw I see in that approach is the possibility to hack the Amazon app itself to always return a valid answer, of course. But, if you mix your current hash checks with some sort of online check scattered among your methods, I believe the chances of it getting hacked may be drastically reduced.
摘自我这篇文章的解决方案 避免 apk 破解
实现您自己的许可库
我还建议您查看 Google I/O 2011 YouTube 录制内容：
Evading海盗和阻止吸血鬼
编辑：
演示说明来自躲避海盗和阻止吸血鬼
一些基本要点
Taken from my solution from this post Avoid apk cracked
Implement your own licensing library
I'd also refer you to check out this from Google I/O 2011 YouTube recording:
Evading Pirates and Stopping Vampires
EDIT:
The Presentation Notes from Evading Pirates and Stopping Vampires
Some basic keypoints
我知道你并不是真的感到困惑，但我真的需要对此做出反应：
根据我的经验，ProGuard 非常可靠，尽管我使用了一些高级功能，例如 AIDL 和一些调用 Java 方法的本机代码。阅读文档并正确执行操作需要一些工作，但是一旦你ProGuard 非常可靠，并且还可以优化您的应用程序。
自定义安全/加密技巧很好，但在我看来，如果不进行混淆，这就像往水里扔一块石头。
我已经在生产中使用 ProGuard 好几个月了，它运行得非常完美。
如果您想学习，请仔细阅读 ProGuard 手册，进行试验并检查其输出日志。
I know you're not really into obfuscation, but I really need to react to this:
ProGuard is very reliable in my experience, and this although I use a couple of advanced features such as AIDL and some native code which calls Java method.. It takes a little work to read the documentation and do things properly, but once you're there ProGuard is extremely reliable and also optimizes your app.
Custom security/cryptographic tricks are good, but without obfuscation it's like throwing a stone in the water in my humble opinion.
I've used ProGuard in production for many months, and it just works flawlessly.
If you're into learning, then read the ProGuard manual carefully, experiment with it, and inspect its output logs.
有比你更有才华的程序员的机会（适用于所有程序员）是 100%。如果这是真的，你就无法修复黑客行为。但你可以花尽可能多的时间和精力来破产。
如果你想赚大钱，你需要对目标用户群和行为科学进行一些研究。你需要让玩游戏的用户带来新的钱，仅此而已。
此外，你全都错了。黑客是您的用户群中最活跃的成员，您只是以您不希望他们这样做的方式行事。
以 Facebook 上的 Zynga 游戏为例，你认为你会被黑吗？ - 当然，大约有超过 100000 名玩家只玩游戏，因为你可以使用机器人，让一切自动化。
拥有庞大的真实用户活跃用户群僵尸网络，使得归档类型的游戏玩家想要玩游戏 - 如果你玩游戏，而且看起来很酷，那么 Avarage Joe 也会想玩。如果 Avarage Joe 玩，那么他的朋友可能也想玩，而你可能不会关心其他任何事情，然后比他/她的朋友更好，消磨时间或有话可聊。普通乔的朋友很可能愿意花钱来变得比乔更好，但你更愿意投资一些能让他们变得更好的东西。
此外，如果真正的价值是免费玩游戏，那么使用免费破解版本的用户很可能永远不会付费。但你的 Avarage Joes 和他们的朋友可能会这么做。所以这就像你能拥有的最便宜的广告。如果您想从庞大的用户群中赚钱，那么只需制作游戏的新版本，对关卡和图形进行少量更改即可。
Chance, that there are more talented programmers then YOU (applies for all programmer), is 100%. And if that is true, you can not fix hacking. But you can spend as much time and effort on it to go bankrupt.
If you want to make some serious money you need to do some research on your target user group, and behavioral science. You need to make users playing that bring in new money, and thats it.
Besides, you got it all wrong. Hackers are most active members of your user base, thy just behave in a way you did not intend them to.
Take Zynga games on Facebook for example, do you think thy get hacked? - Sure, and about +100000 players only play, because thy can use bots, that automate everything.
Having huge active user base botnet of actual people, makes archiver type gamers want to play the game - and if thy play, and it looks cool, then Avarage Joe will also want to play. If Avarage Joe plays, then his friends might want to play, and thy probably will not care anything other, then being better then his/her friend, killing time or having something to chat about. Avarage Joe friends will most likely be willing to pay to be better then Joe, but rather thy would like to invest in something that makes them able to be better.
Besides if the real value is playing the game for free, then users who use the free hacked version, will most likely never would have payed for it. But thy are Avarage Joes and their friends just might. So this is like the cheapest commercial you can have. If you want to make money of your large userbase, then just make new versions of the game with small changes to levels and graphics.
盗版将永远是一个问题。总的来说，破解者比开发者更擅长玩这个通过模糊实现安全的游戏。
Piracy will always be an issue. By in large crackers are better at playing this Security Though Obscurity game than developers.
这是一个多么有趣又令人不安的问题。 :-) 作为练习，您可以尝试通过 Amazon 发布应用程序；他们有自己的DRM机制；我想知道它是否比 ProGuard 更好......
What an interesting and disturbing question. :-) As an exercise, you might try releasing an app through Amazon; they have their own DRM mechanism; I wonder if it works any better than ProGuard...
我认为关键要素之一是分散代码，这样它就不会全部集中在一处。如果您有一个名为 LicenseChecker.checkLicense() 的函数来检索许可证并进行检查，您可以确定它将立即被禁用。
你拥有的一个优势是破解者看不到你代码的注释（如果你混淆了方法/变量名称），所以想出一些奇怪的东西。在一项活动的 onCreate() 中，您可以获得许可证 ID。在 onResume() 中，您将获得另一个值来检查它。也许创建一个线程并在那里做一些检查。然后，其他一些不相关的代码（可能是播放器控件）可能会获取该值并进行比较并将结果存储在某处。然后，其他三个不相关的代码段将独立检查该值，并在不匹配时禁用您的应用程序。
现在我应该提前说一下，这可能会让你自己头疼——显然，混乱、令人讨厌的代码更难调试，并且容易导致错误。最坏的情况是，您会在合法购买的应用程序中产生误报。
当然，一切都可以进行逆向工程——一旦黑客找到应用程序被禁用的地方，他们就会追溯到正在读取的值。然后他们可以追溯它的存储位置，并追溯......或者，更简单的是，他们可以禁用最终检查（这就是为什么我推荐 3 个不同的位置，所有触发都延迟）。安全性取决于最薄弱的环节。
您将无法阻止盗版。最好的选择是推迟盗版副本的传播，直到有关您的应用程序的最初炒作平息下来。
One of the key elements in my opinion is to spread out the code so it's not all in one place. If you have a function called LicenseChecker.checkLicense() which retrieves the license and checks it, you can be sure it will be disabled promptly.
The one advantage you have is that the crackers cannot see the comments of your code (and, if you obfuscate, method/variable names), so come up with something weird. In the onCreate() of one activity, you get the license ID. In onResume(), you get another value to check it against. Maybe create a thread and do some checks there. And then, some other irrelevant piece of code (maybe the player control) might pick up the value and compare it and store the result somewhere. Then three other irrelevant pieces of code will all independently check that value and disable your application if it doesn't match.
Now I should say upfront that this can cause headache for yourself - obviously, cluttered, nasty code is harder to debug and prone to cause errors. Worst case, you create false positives in legitimately purchased applications.
And, of course, everything can be reverse-engineered - once the crackers find the place where the app is disabled, they trace back the value that's being read from. They could then trace back where it's being stored, and trace that back..... or, much easier, they can just disable the final check (which is why I recommended 3 different places, all triggering delayed). Security is only as good as the weakest link.
You will not be able to stop piracy. Your best bet is to delay the spreading of a pirated copy until the initial hype about your app has calmed down.
首先，我不认为自己是软件安全领域的专家，但是：
我认为重要的是让应用程序在某些部分依赖于签名检查。不要让它立即影响，而是让它设置一些标志或更改一些值。稍后，使用这些标志，检查它们，让它们的缺失/不正确导致某种可能会终止应用程序的异常。只要签名检查仅在此时相关，就很容易绕过它，删除该行，一旦它触及代码中的更多区域，您的应用程序就会变得更难（或不太容易......）被破解。另外，据我所知，并非所有检查都应该调用相同的制裁例程，因为这也将使找到保护机制并终止它变得容易。
当然，在非法软件的情况下采取的制裁可能会有所不同，您可能希望在非法使用时使应用程序崩溃，但您也可能希望保持其运行，并且仅发送要求用户购买合法副本的消息的应用程序。
如果这正是您不想听到的，那么我很抱歉占用您的时间:)
First, I do NOT consider myself a pro in the SW security field whatsoever, but:
I think an important thing is to let the application be dependent in some part(s) on the signature check. Don't let it affect immediately, but let it set some flags or change some values. later on, use those flags, check them, let the absence/incorrectness of them cause an exception of some kind which will terminate the application maybe. As long as the signature check is only relevant at the moment, it is easy to bypass it, to remove the line, once it touches more areas in the code, your application becomes harder (or less easier...) to hack. Also as I see it, not all checks should call the same routine for the sanction, because this will also make it easy to find the protection mechanism and terminate it.
Of course, the sanction to take in cases of illegal SW may vary, you might want to crash the application when used illegally, but you might as well want to keep it running, and only send message that asks the user to buy a legal copy of the application.
If this is just what you didn't want to hear, then I'm sorry for your time :)
Android 用户将不得不接受不断打电话回家的痛苦。唯一安全的 Android 应用程序是始终连接的 Android 应用程序。
这在很大程度上是由于谷歌拒绝像苹果那样锁定安装。在IOS上，你必须将手机越狱。在 Android 上，您可以加载库存、出厂安装中的任何 APK。
将部分/大部分/全部内容保留在服务器上；分块交付；验证每次调用的许可证/会话。
Android users are just going to have accept the pain of constant phone-homes. The only secure Android app is an always-connected Android app.
This is, in large part, due to Google's refusal to lock-down the installation, like Apple has. On IOS you have to jailbreak the phone. On Android you can load any APK on a stock, factory install.
Keep some/most/all your content on the server; deliver it in chunks; validate the license/session on each call.
抑制这种行为是非常困难的。在客户端处理的任何内容都可以通过 APK 反编译和修改、使用诸如 游戏守护者等。
我能看到如何部分解决这个问题的唯一方法就是制作一款在线游戏。或者在线处理某些功能。或者，像 denuvo 这样的防篡改加密是否可用于 Android / iOS。
It will be incredibly hard to inhibit this kind ov behavior. Anything that is handled on the client-side is hackable using APK decompilation and modding, memory editing with software such as Game Guardian ect.
The only way I can see how partially getting around it, would be to make an online game instead. Or have certain functions handled online. Or if anti-tamper encryption like denuvo ever is available for Android / iOS.