我正在为Android开发一款支付处理应用程序，我想防止黑客访问APK文件中的任何资源、资产或源代码。
如果有人将.apk扩展名更改为.zip，那么他们可以将其解压缩并轻松访问应用程序的所有资源和资产，并且可以使用dex2jar和Java反编译器访问源代码。对Android APK文件进行反向工程非常容易-有关更多详细信息，请参阅堆栈溢出问题从APK文件到项目的反向工程。
我已经使用了Android SDK提供的Proguard工具。当我对使用签名密钥库和Proguard生成的APK文件进行反向工程时，我得到了混淆的代码。
然而，Android组件的名称保持不变，一些代码（如应用程序中使用的关键值）保持不变。根据Proguard文档，该工具无法混淆Manifest文件中提到的组件。
现在我的问题是：
如何完全防止Android APK的反向工程？这可能吗？我如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？有没有办法让黑客攻击变得更加困难甚至不可能？我还能做什么来保护APK文件中的源代码？
当前回答
1.如何完全避免Android APK的反向工程？这可能吗？
AFAIK，没有任何技巧可以完全避免逆向工程。
@inazaruk也说得很好：无论你对代码做了什么，潜在的攻击者都可以以她或他认为可行的任何方式修改代码。你基本上无法保护你的应用程序不被修改。您在其中放置的任何保护都可以禁用/删除。
2.如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？
不过，你可以使用不同的技巧来提高黑客攻击的难度。例如，使用混淆（如果是Java代码）。这通常会大大降低逆向工程的速度。
3.有没有办法让黑客攻击变得更加困难甚至不可能？我还能做什么来保护APK文件中的源代码？
正如大家所说的，正如你可能知道的，没有100%的安全性。但谷歌内置的安卓系统的起点是ProGuard。如果您可以选择包含共享库，则可以在C++中包含所需的代码，等。如果您需要在每次构建时将外部本机库添加到APK的库文件夹中，那么你可以根据以下建议使用它。
将库放在默认为“libs”的本机库路径中您的项目文件夹。如果您为“armeabi”目标构建了本机代码，请将其放入在libs/armeabi下。如果它是用armeabi-v7a建造的，那么把它放在下面libs/armeabi-v7a。
<project>/libs/armeabi/libstuff.so
其他回答
当您将其放在最终用户手中时，没有什么是安全的，但一些常见的做法可能会使攻击者更难窃取数据。
将主要逻辑（算法）放在服务器端。与服务器和客户端通信；确保服务器和客户端之间的通信通过SSL或HTTPS进行安全；或者使用其他技术用于密钥对生成算法（ECC和RSA）。确保敏感信息保持端到端加密。使用会话并在特定时间间隔后使其过期。加密资源并按需从服务器获取资源。或者你可以制作一个混合应用程序，通过webview访问系统，保护服务器上的资源+代码
多种方法；很明显，您必须牺牲性能和安全性。
完全避免逆向工程是不可能的，但通过在内部使其更加复杂，攻击者可能更难看到应用程序的清晰操作，这可能会减少攻击向量的数量。
如果应用程序处理高度敏感的数据，则存在各种技术，这些技术会增加代码反向工程的复杂性。一种技术是使用C/C++来限制攻击者容易进行的运行时操作。有大量的C和C++库非常成熟，易于集成，Android提供JNI。
攻击者必须首先绕过调试限制，才能在较低级别上攻击应用程序。这增加了攻击的复杂性。Android应用程序应在应用程序清单中设置Android:debuggable=“false”，以防止攻击者或恶意软件轻易地进行运行时操作。
跟踪检查–应用程序可以确定调试器或其他调试工具当前是否正在跟踪它。如果被跟踪，应用程序可以执行任意数量的可能的攻击响应动作，例如丢弃加密密钥以保护用户数据、通知服务器管理员或其他此类类型的响应以试图自卫。这可以通过检查进程状态标志或使用其他技术来确定，如比较ptrace附件的返回值、检查父进程、进程列表中的黑名单调试器或比较程序不同位置的时间戳。
优化-为了隐藏高级数学计算和其他类型的复杂逻辑，利用编译器优化可以帮助混淆目标代码，使其不易被攻击者分解，从而使攻击者更难理解特定代码。在Android中，这可以通过使用NDK本地编译的库更容易地实现。此外，使用LLVM混淆器或任何保护器SDK将提供更好的机器代码混淆。
剥离二进制文件–剥离本机二进制文件是一种有效的方法，可以增加攻击者查看应用程序低级功能组成所需的时间和技能水平。通过剥离二进制文件，二进制文件的符号表被剥离，这样攻击者就无法轻松调试或反向工程应用程序。您可以参考GNU/Linux系统上使用的技术，如sstriping或使用UPX。
最后，您必须了解混淆和ProGuard等工具。
基本上这是不可能的。这永远不可能。然而，这是有希望的。你可以使用混淆器来实现，这样一些常见的攻击就更难执行了，包括：
重命名方法/类（因此在反编译器中，您可以获得像.a这样的类型）使控制流混乱（因此在反编译器中，代码很难阅读）加密字符串和可能的资源
我肯定还有其他的，但这是主要的。我在一家名为PreEmptive Solutions的公司工作，负责.NET混淆器。他们还有一个适用于Android的Java混淆器，一个叫做DashO的混淆器。
不过，困惑总是有代价的。值得注意的是，性能通常更差，通常需要一些额外的时间来发布。然而，如果你的知识产权对你来说非常重要，那么它通常是值得的。
否则，你唯一的选择就是让你的Android应用程序直接传递到一个承载你应用程序所有真实逻辑的服务器。这有其自身的问题，因为这意味着用户必须连接到Internet才能使用您的应用程序。
此外，不仅仅是Android有这个问题。这是每个应用商店的问题。这只是获取程序包文件有多困难的问题（例如，我不相信在iPhone上很容易，但仍然有可能）。
这里的主要问题是，dex文件是否可以反编译，答案是它们可以“有点”。有像dedexer和smali这样的拆装器。
正确配置的ProGuard会使代码变得模糊。DexGuard是ProGuard的商业扩展版本，它可能会有更多帮助。然而，您的代码仍然可以转换为smali，具有逆向工程经验的开发人员将能够从smali中了解您正在做什么。
也许选择一个好的许可证，并以最好的方式通过法律强制执行。
作为一个在支付平台（包括一个移动支付应用程序（MyCheck））上广泛工作的人，我想说，您需要将这种行为委托给服务器。移动应用程序中不应存储或硬编码支付处理器的用户名或密码（以其为准）。这是您最不希望看到的，因为即使您混淆了代码，也可以理解源代码。
此外，您不应在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。这也会让你以后更容易遵守PCI标准，信用卡公司也不会像对待我们那样，让你喘不过气来。
