我正在为Android开发一款支付处理应用程序，我想防止黑客访问APK文件中的任何资源、资产或源代码。
如果有人将.apk扩展名更改为.zip，那么他们可以将其解压缩并轻松访问应用程序的所有资源和资产，并且可以使用dex2jar和Java反编译器访问源代码。对Android APK文件进行反向工程非常容易-有关更多详细信息，请参阅堆栈溢出问题从APK文件到项目的反向工程。
我已经使用了Android SDK提供的Proguard工具。当我对使用签名密钥库和Proguard生成的APK文件进行反向工程时，我得到了混淆的代码。
然而，Android组件的名称保持不变，一些代码（如应用程序中使用的关键值）保持不变。根据Proguard文档，该工具无法混淆Manifest文件中提到的组件。
现在我的问题是：
如何完全防止Android APK的反向工程？这可能吗？我如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？有没有办法让黑客攻击变得更加困难甚至不可能？我还能做什么来保护APK文件中的源代码？
当前回答
在计算历史上，当您将软件的工作副本提供给攻击者时，从未有过阻止软件逆向工程的可能。而且，在大多数情况下，这是不可能的。
明白了这一点，就有了一个显而易见的解决方案：不要把你的秘密泄露给攻击者。虽然你不能保护APK的内容，但你可以保护的是你没有分发的任何内容。通常，这是服务器端软件，用于激活、支付、规则执行和其他有趣的代码。您可以通过不在APK中分发有价值的资产来保护它们。相反，设置一个服务器来响应应用程序的请求，“使用”资产（无论这意味着什么），然后将结果发送回应用程序。如果这个模型不适用于你心目中的资产，那么你可能需要重新思考你的战略。
此外，如果你的首要目标是防止应用程序盗版，那就别费心了。你已经在这个问题上花费了比任何反盗版措施都能挽救你的时间和金钱。解决这一问题的投资回报率很低，甚至连思考都没有意义。
其他回答
可信平台模块（TPM）芯片不应该为您管理受保护的代码吗？
它们在个人电脑（尤其是苹果电脑）上越来越常见，并且可能已经存在于今天的智能手机芯片中。不幸的是，目前还没有任何OS API可以使用它。希望有一天，Android会增加对此的支持。这也是清洁内容DRM（Google正在为WebM开发）的关键。
工具：在应用程序中使用ProGuard，可以限制其对应用程序进行反向工程
不，不可能！
你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且，你在尝试做这件事上投入的越多，你的体验就会越差，最终，无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢，因为需要处理安全层和数学。层数越多，有人打开它的速度就越慢，但如果你真的想让它被阅读，那就永远不可能，这就是为什么它会被打包并交付的原因。
一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人能看到里面的东西，那么他们就可以拍一张照片，做一些完全类似的事情。更重要的是，在代码的情况下，有足够的专业人员可以创建该对象的精确副本，即使使用完全不同的过程。
假安全感
作为一个处理应用程序，你不应该关心你认为可以在二进制代码中创建的任何安全性，也不应该关心整个系统的完整性。假设来自客户机的任何信息都可能很快变得不可靠。保持应用程序简单、流畅、快速。相反，请担心您的服务器。例如，制定一个严格的通信协议以方便地监控服务器。这是我们唯一可以依靠的。
现在，坚持我的另一个想法，如何改进服务器端。。。
嘴上的钱
我正在开发支付处理应用程序
谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome，在总体上成功地避免了恶意黑客，我引述如下：
我们有50000美元的奖励，奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试
我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励，但即使是1k的奖励也会有很长的路要走，而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。
投资于人工智能来识别资金流动模式，以预测潜在风险并发现小的泄漏，这也比通过任何工程来防止这两种情况要便宜得多。
明显的例外
当然，这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害。。。但什么都不会。同时，如果设置得当，当系统重新调整时，后一组只会享受很少的时间。而一个疯子，我们只需要担心，以防它大到有一个克星。无论如何，这将是一个伟大的故事！：）
太长；没有阅读；
换言之，也许一个更好的问题可以问你自己，而不是“如何避免在我的应用程序中进行逆向工程”，而是“如何设计一个更安全的支付处理系统”，并专注于你实际想要实现的目标：一个安全的系统。
很久以前，我曾尝试写更多关于以上所有内容的文章，以回答一些问题，比如为什么我在引号中加上“安全”和“保护”（它们到底是什么意思？）。
作为一个在支付平台（包括一个移动支付应用程序（MyCheck））上广泛工作的人，我想说，您需要将这种行为委托给服务器。移动应用程序中不应存储或硬编码支付处理器的用户名或密码（以其为准）。这是您最不希望看到的，因为即使您混淆了代码，也可以理解源代码。
此外，您不应在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。这也会让你以后更容易遵守PCI标准，信用卡公司也不会像对待我们那样，让你喘不过气来。
基本上这是不可能的。这永远不可能。然而，这是有希望的。你可以使用混淆器来实现，这样一些常见的攻击就更难执行了，包括：
重命名方法/类（因此在反编译器中，您可以获得像.a这样的类型）使控制流混乱（因此在反编译器中，代码很难阅读）加密字符串和可能的资源
我肯定还有其他的，但这是主要的。我在一家名为PreEmptive Solutions的公司工作，负责.NET混淆器。他们还有一个适用于Android的Java混淆器，一个叫做DashO的混淆器。
不过，困惑总是有代价的。值得注意的是，性能通常更差，通常需要一些额外的时间来发布。然而，如果你的知识产权对你来说非常重要，那么它通常是值得的。
否则，你唯一的选择就是让你的Android应用程序直接传递到一个承载你应用程序所有真实逻辑的服务器。这有其自身的问题，因为这意味着用户必须连接到Internet才能使用您的应用程序。
此外，不仅仅是Android有这个问题。这是每个应用商店的问题。这只是获取程序包文件有多困难的问题（例如，我不相信在iPhone上很容易，但仍然有可能）。
