如何避免APK文件的逆向工程

1.如何完全避免Android APK的逆向工程？这可能吗？

AFAIK，没有任何技巧可以完全避免逆向工程。

@inazaruk也说得很好：无论您对代码做什么，潜在的攻击者都能够以她或他认为可行的任何方式更改它。您基本上无法保护您的应用程序不被修改。您在那里放置的任何保护都可以被禁用/删除。

2.如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

不过，您可以使用不同的技巧来使黑客攻击更加困难。例如，使用混淆（如果它是Java代码）。这通常会显着减慢逆向工程。

3.有没有办法让黑客攻击变得更加艰难甚至不可能？我还能做些什么来保护我的APK文件中的源代码？

正如大家所说，你可能知道，没有100%的安全性。但是谷歌内置的Android的起点是ProGuard。如果你可以选择包含共享库，你可以在C++中包含所需的代码来验证文件大小、集成、等等。如果您需要在每次构建时将外部本机库添加到APK的库文件夹中，那么你可以通过下面的建议来使用它。

将库放在默认为“libs”的本机库路径中您的项目文件夹。如果您为'armeabi'目标构建了本机代码，则将其放入在libs/armeabi下。如果它是用armeabi-v7a构建的，那么把它放在下面lib s/arme abi-v 7 a.

<project>/libs/armeabi/libstuff.so

1.如何完全避免Android APK的逆向工程？这可能吗？

不可能

2.如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

不可能

3.有没有办法让黑客攻击变得更加艰难甚至不可能？我还能做些什么来保护我的APK文件中的源代码？

更难-有可能，但实际上对普通用户来说会更难，他们只是在谷歌上搜索黑客指南。如果有人真的想入侵你的应用程序-它迟早会被黑客入侵。

100%避免对Android APK进行逆向工程是不可能的，但您可以使用这些方法来避免提取更多数据，例如源代码、APK中的资产和资源：

1. 使用ProGuard混淆应用程序代码

2. 使用NDK使用C和C++将应用程序核心和安全部分代码放在.so文件中

3. 要保护资源，请不要将所有重要资源包含在带有APK的资产文件夹中。在应用程序首次启动时下载这些资源。

AFAIK，您无法保护 /res目录中的文件，而不是现在保护它们。

但是，您可以采取一些步骤来保护您的源代码，或者至少保护它的功能（如果不是全部）。

1. 使用ProGuard等工具。这些工具会混淆您的代码，并使反编译时更难阅读，如果不是不可能的话。
2. 将服务中最关键的部分移出应用程序，进入网络服务，隐藏在PHP等服务器端语言后面。例如，如果你有一个花了你一百万美元编写的算法。你显然不希望人们将其从你的应用程序中窃取。移动算法并让它在远程服务器上处理数据，并使用应用程序简单地向其提供数据。或者使用NDK将它们本机写入. so文件，这些文件比apks被反编译的可能性要小得多。我不认为. so文件的反编译器现在甚至存在（即使存在，它也不如Java反编译器好）。此外，正如@nikolay在评论中提到的，您应该在服务器和设备之间交互时使用SSL。
3. 在设备上存储值时，请不要以原始格式存储它们。例如，如果您有一个游戏，并且您正在SharedPreev中存储用户拥有的游戏货币数量。让我们假设它是10000硬币。与其直接保存10000，不如使用((currency*2)+1)/13这样的算法保存它。所以，不是10000，而是将1538.53846154保存到SharedPre的设置中。然而，上面的例子并不完美，你必须努力想出一个不会因舍入错误等而损失货币的方程式。
4. 对于服务器端任务，也可以做类似的事情。现在举个例子，让我们实际使用你的支付处理应用程序。假设用户必须支付$200。不是向服务器发送原始的$200值，而是发送一系列较小的、预定义的值，这些值加起来为$200。例如，在你的服务器上有一个文件或表，将单词与值等同起来。假设Charlie对应于$47，John对应于$3。所以你可以发送Charlie四次和John四次，而不是发送$200。在服务器上，解释它们的意思并将其加起来。这可以防止黑客向您的服务器发送任意值，因为他们不知道哪个单词对应于哪个值。作为额外的安全措施，您也可以有一个类似于第3点的等式，并每$2000天更改一次关键字。
5. 最后，你可以随机插入无用的源代码到你的应用程序中，这样黑客就像大海捞针一样。随机插入包含互联网片段的类，或者只是计算斐波那契数列等随机事物的函数。确保这些类可以编译，但不被应用程序的实际功能使用。添加足够多的这些假类，黑客就很难找到你的真实代码。

总而言之，没有办法100%保护您的应用程序。您可以使其变得更难，但并非不可能。您的Web服务器可能会受到攻击，黑客可以通过监控多个交易金额和您发送的关键字来找出您的关键字，黑客可以费尽心机地查看源代码并找出哪些代码是假的。

你只能反击，但永远不会赢。

这里的主要问题是dex文件可以反编译吗？答案是它们可以是“某种”。有像除尘器和smali这样的反汇编程序。

DexGuard是ProGuard的商业扩展版本，可能会有所帮助。但是，您的代码仍然可以转换为smali，具有逆向工程经验的开发人员将能够从smali中弄清楚您在做什么。

也许选择一个好的许可证，并以最好的方式依法执行。

1.如何完全避免Android APK的逆向工程？这可能吗？

这是不可能的

2.如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

当有人将. apk扩展名更改为. zip时，解压后，有人可以轻松获取所有资源（除了Manifest.xml），但使用应用程序也可以获取清单文件的真实内容。

3.有没有办法让黑客攻击变得更加艰难甚至不可能？我还能做些什么来保护我的APK文件中的源代码？

同样，没有，但你可以防止在某种程度上，也就是说，

• 从Web下载资源并进行一些加密过程
• 使用预编译的本机库（C、C++、JNI、NDK）
• 总是执行一些散列（MD5/SHA键或任何其他逻辑）

即使使用Smali，人们也可以玩你的代码。总而言之，这是不可能的。

在计算历史上的任何时候，当您将软件的工作副本提供给攻击者时，都不可能防止软件的逆向工程。此外，很可能，这永远都不可能。

有了这个理解，有一个明显的解决方案：不要把你的秘密告诉攻击者。虽然你不能保护APK的内容，但你可以保护的是任何你不分发的东西。通常这是用于激活、支付、规则执行和其他有趣的代码块的服务器端软件。你可以通过没有在APK中分发有价值的资产来保护它们。相反，设置一个服务器来响应来自你的应用的请求，“使用”这些资产（不管这意味着什么），然后将结果发送回应用。如果这种模式不适用于你想象中的资产，那么你可能需要重新考虑你的策略。

还有，如果您的主要目标是防止应用程序盗版：别费心了。你已经在这个问题上花费了比任何反盗版措施都要多的时间和金钱。解决这个问题的投资回报是如此之低，以至于想一想都没有意义。

我建议你看看保护软件应用程序免受攻击。这是一个商业服务，但我朋友的公司使用了这个，他们很高兴使用它。

你的客户应该雇佣一个知道自己在做什么、能做出正确决定并能指导你的人。

上面谈到你有能力在后端更改事务处理系统是荒谬的-你不应该被允许进行这样的架构更改，所以不要期望能够这样做。

我对此的理由：

由于您的领域是支付处理，因此可以肯定地假设PCI DSS和/或PA DSS（以及潜在的州/联邦法律）对您的业务具有重要意义——要合规，您必须证明您是安全的。要变得不安全，然后通过测试发现您不安全，然后修复，重新测试，等等，直到可以在合适的级别验证安全性=昂贵，缓慢，高风险的成功方式。要做正确的事情，请预先认真思考，投入经验丰富的人才到工作中，以安全的方式开发，然后测试，修复（较少），等等，直到可以在合适的级别验证安全性=廉价，快速，低风险的成功方式。

基本上这是不可能的。这永远不可能。然而，还是有希望的。您可以使用混淆器来使其更难以执行一些常见的攻击，包括：

1. 重命名方法/类（所以在反编译器中你会得到像a.a这样的类型）
2. 混淆控制流（因此在反编译器中代码很难阅读）
3. 加密字符串和可能的资源

我相信还有其他的，但这是主要的。我为一家名为Pre的公司工作，使用. NET混淆器。他们也有一个适用于Android的Java混淆器以及一个名为DashO的混淆器。

然而，混淆总是有代价的。值得注意的是，性能通常更差，并且通常需要一些额外的时间来发布。但是，如果您的知识产权对您来说非常重要，那么通常是值得的。

否则，您唯一的选择就是让您的Android应用程序直接传递到托管应用程序所有实际逻辑的服务器。这也有自己的问题，因为这意味着用户必须连接到Internet才能使用您的应用程序。

此外，不仅仅是Android有这个问题。每个应用商店都有这个问题。这只是一个获取包文件有多困难的问题（例如，我认为在iPhone上不容易，但它仍然是可能的）。

应用程序安全的第一条规则：攻击者获得不受限制的物理或电子访问权限的任何机器现在都属于您的攻击者，无论它实际在哪里或您为它支付了多少费用。

应用程序安全的第二条规则：任何离开攻击者无法渗透的物理边界的软件现在都属于您的攻击者，无论您花了多少时间编写它。

第三条规则：任何离开攻击者无法穿透的物理边界的信息现在都属于攻击者，无论它对您有多有价值。

信息技术安全的基础建立在这三个基本原则之上；唯一真正安全的计算机是锁在保险箱里、法拉第笼子里、钢笼子里的计算机。有些计算机的大部分使用寿命都处于这种状态；它们每年一次（或更少）为受信任的根证书颁发机构生成私钥（当着许多目击者的面，用摄像机记录它们所在房间的每一寸）。

现在，大多数计算机不是在这些类型的环境下使用的；它们实际上是在户外，通过无线无线电信道连接到互联网。简而言之，它们很脆弱，它们的软件也是如此。因此，它们是不可信任的。计算机和它们的软件必须知道或做某些事情才能有用，但必须小心，以确保它们永远不会知道或做足够的事情来造成损害（至少不会在单个机器的范围之外造成永久性损害）。

这些你都已经知道了；这就是为什么要保护应用程序的代码。但是，这就存在第一个问题；混淆工具会使代码变得一团糟，即使人类试图深入挖掘，程序仍然必须运行；这意味着应用程序的实际逻辑流程及其使用的数据不受混淆的影响。只要稍微坚韧一点，攻击者就可以简单地对代码进行解混淆，在某些情况下甚至没有必要，因为他所看的不可能是他要找的东西。

相反，你应该努力确保攻击者不能对你的代码做任何事情，不管他有多容易获得一份清晰的副本。这意味着，没有硬编码的秘密，因为一旦代码离开你开发它的大楼，这些秘密就不是秘密了。

你硬编码的这些键值应该从应用程序的源代码中完全删除。相反，它们应该位于以下三个地方之一：设备上的易失性内存，攻击者更难（但仍不是不可能）获得其的离线副本；永久在服务器集群上，你可以用铁腕控制对其的访问；或者在与你的设备或服务器无关的第二个数据存储中，例如物理卡或用户的内存（这意味着它最终会在易失性内存中，但不必很长时间）。

考虑以下方案。用户从内存向设备输入他们的应用凭据。不幸的是，你必须相信用户的设备还没有被键盘记录器或木马入侵；在这方面，你能做的最好的是实现多因素安全性，通过记住有关用户使用的设备（MAC/IP、IMEI等）的难以伪造的识别信息，并提供至少一个额外的通道，通过该通道可以验证在不熟悉设备上的登录尝试。

输入后的凭据会被客户端软件（使用安全哈希）混淆，纯文本凭据会被丢弃；它们已经达到了目的。混淆后的凭据通过安全通道发送到证书认证的服务器，服务器对它们进行再次哈希处理，生成用于验证登录有效性的数据。这样，客户端永远不知道实际与数据库值相比是什么，应用服务器永远不知道它接收到的用于验证的明文凭据背后是什么，数据服务器永远不知道它存储用于验证的数据是如何产生的，即使安全通道被破坏，中间的人看到的也只是胡言乱语。

验证后，服务器通过通道发回一个令牌。该令牌仅在安全会话中有用，由随机噪声或会话标识符的加密（因此可验证）副本组成，客户端应用程序必须在同一通道上将此令牌发送给服务器，作为任何请求的一部分。客户端应用程序会这样做很多次，因为它不能做任何涉及金钱、敏感数据或任何其他可能对其本身造成损害的事情；它必须要求服务器完成此任务。客户端应用程序永远不会将任何敏感信息写入设备本身的持久内存，至少不会以纯文本形式写入；客户端可以通过安全通道向服务器请求对称密钥来加密任何本地数据，服务器会记住这些数据；在以后的会话中，客户端可以向服务器请求相同的密钥来解密数据以用于易失性内存。该数据也不会是唯一的副本；客户端存储的任何内容也应该以某种形式传输到服务器。

显然，这使得您的应用程序严重依赖于Internet访问；如果没有与服务器的正确连接和身份验证，客户端设备就无法执行其任何基本功能。

现在，攻击者想要的计算机就是你的服务器，因为能让他赚钱或让其他人为他的乐趣感到痛苦的是它，而不是客户端的应用程序/设备。没关系；花费金钱和精力来保护服务器比试图保护所有客户端更划算。服务器可以位于各种防火墙和其他电子安全后面，此外还可以在物理上受到钢铁、混凝土、钥匙卡/pin访问和24小时视频监控的保护。你的攻击者需要非常复杂才能直接获得任何类型的服务器访问权限，你会（应该）立即知道这一点。

攻击者能做的最好的事情就是窃取用户的手机和凭据，并以客户端的有限权限登录服务器。如果发生这种情况，就像丢失信用卡一样，应该指示合法用户拨打800号码（最好容易记住，而不是在他们钱包、钱包或公文包里的卡片背面，这些卡片可能会在移动设备旁边被盗）从他们可以访问的任何电话直接连接到您的客户服务。他们声明他们的手机被盗，提供一些基本的唯一标识符，账户被锁定，攻击者可能能够处理的任何交易都被回滚，攻击者又回到了原点。

这里其他投票赞成的答案是正确的。我只是想提供另一个选择。

对于您认为重要的某些功能，您可以在您的应用程序中托管WebView控件。然后，该功能将在您的Web服务器上实现。它看起来像是在您的应用程序中运行。

如果我们想让逆向工程（几乎）不可能，我们可以把应用程序放在一个高度防篡改的芯片上，该芯片在内部执行所有敏感的东西，并与一些协议通信，使控制主机上的GUI成为可能。即使是防篡改芯片也不是100%防破解的；它们只是设置了比软件方法高得多的标准。当然，这很不方便：应用程序需要一些小USB螺栓来固定芯片插入设备。

这个问题并没有揭示想要如此嫉妒地保护这个应用程序的动机。

如果目的是通过掩盖应用程序可能存在的任何安全漏洞（无论是否已知）来提高支付方式的安全性，那就完全是错误的。安全敏感位实际上应该开源（如果可行）。你应该让任何审查你的应用程序的安全研究人员尽可能容易地找到这些位并审查它们的操作，并与你联系。支付应用程序不应该包含任何嵌入式证书。也就是说，不应该有任何服务器应用程序仅仅因为设备有固定的工厂证书而信任它。支付交易应仅基于用户的凭据进行，使用正确设计的端到端身份验证协议，排除对应用程序、平台或网络等的信任。

如果目的是防止克隆，那么除了防篡改芯片之外，你没有办法保护程序不被反向工程和复制，这样某人就会将兼容的支付方式整合到他们自己的应用程序中，从而产生“未经授权的客户端”。有很多方法可以使开发未经授权的客户端变得困难。一种是基于程序完整状态的快照创建校验和：所有状态变量，所有东西。GUI，逻辑，等等。克隆程序不会有完全相同的内部状态。当然，它是一个状态机，有类似的外部可见的状态转换（可以通过输入和输出观察到），但内部状态几乎不一样。服务器应用程序可以询问程序：你的详细状态是什么？（即给我一个你所有内部状态变量的校验和）。这可以与在服务器上并行执行的虚拟客户端代码进行比较，经历真正的状态转换。第三方克隆将不得不复制真正程序的所有相关状态变化才能给出正确的响应，这将阻碍其开发。

1.如何完全避免Android APK的逆向工程？这可能吗？

那是不可能的

2.如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

开发人员可以采取措施，例如使用ProGuard等工具来混淆他们的代码，但到目前为止，完全阻止某人反编译应用程序是相当困难的。

这是一个非常棒的工具，可以增加“反转”代码的难度，同时缩小代码的占用空间。

集成的ProGuard支持：ProGuard现在与SDK工具一起打包。开发人员现在可以将他们的代码混淆为发布版本的集成部分。

3.有没有办法让黑客攻击变得更加艰难甚至不可能？我还能做些什么来保护我的APK文件中的源代码？

在研究过程中，我了解了HoseDex2Jar。此工具将保护您的代码免受反编译，但似乎无法完全保护您的代码。

一些有用的链接，你可以参考它们。

• ProGuard， Android， and the Licensing Server
• 保护Android LVL应用程序
• 堆栈溢出问题保护Android应用程序免受逆向工程攻击真的是不可能的吗？
• 堆栈溢出问题如何防止对Android APK文件进行逆向工程以保护代码？

作为一个在支付平台（包括一个移动支付应用程序（MyCheck））上大量工作的人，我会说你需要将这种行为委托给服务器。支付处理器的用户名或密码（无论是谁）都不应该存储或硬编码在移动应用程序中。这是你最不想要的，因为即使你混淆了代码，源代码也可以被理解。

此外，您不应该在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。它还将允许您以后更轻松地符合PCI标准，信用卡公司也不会像他们为我们所做的那样让您喘不过气来。

如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

APK文件受SHA-1算法保护。您可以在APK的META-INF文件夹中看到一些文件。如果您提取任何APK文件并更改其任何内容并再次压缩它，当您在Android机器上运行该新APK文件时，它将无法工作，因为SHA-1哈希永远不会匹配。

以下是一些你可以尝试的方法：

1. 使用混淆和ProGuard之类的工具。
2. 对部分源代码和数据进行加密。
3. 在应用程序中使用专有的内置校验和来检测篡改。
4. 引入避免在一个调试器中加载的代码，即让app具备检测到调试器并退出/杀死调试器的能力。
5. 将身份验证作为在线服务分开。
6. 使用应用程序多样性
7. 使用手指打印技术，例如，在验证设备之前对来自不同子系统的设备的硬件签名。

可信平台模块（TPM）芯片不应该为您管理受保护的代码吗？

它们在PC上变得越来越普遍（尤其是Apple的），它们可能已经存在于今天的智能手机芯片中。不幸的是，还没有任何操作系统API来使用它。希望有一天，Android会增加对这一点的支持。这也是清洁内容DRM的关键（谷歌正在努力WebM）。

只是对上面已经很好的答案的补充。

我知道的另一个技巧是将有价值的代码存储为Java库。然后将该库设置为您的Android项目。与C. so文件一样好，但Android Lib会做。

这样，存储在Android Library上的这些有价值的代码在反编译后将不可见。

基本上，有五种方法可以保护您的APK文件：

1. 隔离Java程序，
2. 加密类文件，
3. 转换为本地代码，
4. 代码混淆问题
5. 在线加密

我建议你使用在线加密，因为它既安全又方便。你不需要花太多时间来实现这一点。

如APK保护。是一个针对APK的在线加密网站。它提供Java代码和C++代码保护，以达到反调试和反编译的效果。操作过程简单易行。

所以如果你想防止它被黑客入侵，你可以尝试让它，这样你就不能直接使用调试器获取静态内存地址.他们可以做一个堆栈缓冲区溢出，如果他们有地方可以写，他们有一个限制.所以试着让它如此，当他们写东西时，如果你必须有一个限制，如果他们发送的字符比限制多，如果（输入>限制）然后忽略，所以他们不能把汇编代码放在那里。

不，不能做！

你的三个问题都围绕着100%保护应用程序不被阅读。原则上，这是做不到的。你在这方面投入的越多，对你来说体验就越糟糕，最终，无论哪台机器试图读取你的应用程序。想想HTTP的0本质上有多慢，因为需要处理的安全层和数学。层越多，有人解包的速度就越慢，但绝不是不可能的，因为你真的希望它被阅读，这就是为什么它被制作成一个包并交付。

一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人可以看到里面的东西，那么他们就可以拍照并做一些完全一样的事情。更重要的是，就代码而言，足够专注的人可以创建该对象的精确副本，即使使用完全不同的过程。

伪造安全意识

作为处理应用程序，为了整个系统的完整性，你不应该关心你认为可以在二进制代码中创建的任何安全性。假设来自客户端的任何东西都可以很快成为不可靠。保持应用程序简单、流畅和快速。相反，担心你的服务器。例如，为轻松的监控服务器制定严格的通信协议。这是我们唯一可以依靠的。

现在，继续和我一起讨论如何改进服务器端的另一个想法…

嘴巴上的钱

我正在开发支付处理应用程序

谷歌一直是通过使用简单的财务方法来“保护”GoogleChrome，在避免恶意黑客方面非常成功，我引用：

我们为参与者提供了50,000美元的长期奖励，这些参与者可以在访客模式下破坏Chromebook或Chromebox的设备持久性

我们真正接近100%“安全”的最佳选择是为我们的钱选择正确的战斗。也许大多数人都无法提供50k奖励，但即使是1k奖励也能起到很大的作用，而且这也比把钱投资于设计任何类型的bug捕手便宜得多。

投资人工智能来识别资金流动模式以预测潜在风险并发现小漏洞也比试图通过任何工程来预防两者要便宜得多。

明显异常

当然，这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害……但没有什么能保护我们。与此同时，如果设置得当，后一组人只会在系统重新调整的时候享受很少的时间。我们只需要担心一个疯子，以防它变得足够大，有一个克星。不管怎样，这会成为一个很棒的故事！：）

太长；没有读取；

换句话说，也许一个更好的问题是问自己，而不是“如何在我的应用程序中避免逆向工程”可以是“如何设计一个<强>更安全的支付处理系统”，并专注于你真正想要实现的目标：一个安全的系统。

^{很久以前，我试着写更多关于上述所有内容，来回答为什么我把“安全”和“保护”放在引号中的问题（它们到底是什么意思？）。}

完全避免逆向工程是不可能的，但是通过在内部使它们更加复杂，可以使攻击者更难看到应用程序的清晰操作，这可能会减少攻击向量的数量。

如果应用程序处理高度敏感的数据，则存在各种技术，这可能会增加逆向工程代码的复杂性。一种技术是使用C/C++来限制攻击者轻松的运行时操作。有大量非常成熟且易于集成的C和C++库，Android提供了JNI。

攻击者必须首先绕过调试限制才能对应用程序进行低级攻击。这会增加攻击的复杂性。Android应用程序应在应用程序清单中设置android:debuggable=”false”，以防止攻击者或恶意软件轻松操纵运行时。

跟踪检查-应用程序可以确定它当前是否被调试器或其他调试工具跟踪。如果被跟踪，应用程序可以执行任意数量的可能攻击响应操作，例如丢弃加密密钥以保护用户数据、通知服务器管理员或其他类似类型的响应以试图自卫。这可以通过检查进程状态标志或使用其他技术来确定，例如比较pTrace附加的返回值、检查父进程、进程列表中的黑名单调试器或比较程序不同位置的时间戳。

优化-为了隐藏高级数学计算和其他类型的复杂逻辑，利用编译器优化可以帮助混淆目标代码，使其不容易被攻击者分解，从而使攻击者更难理解特定代码。在Android中，通过使用带有NDK的本机编译库可以更容易地实现这一点。此外，使用LLVM混淆器或任何保护器SDK将提供更好的机器代码混淆。

剥离二进制文件-剥离本机二进制文件是增加攻击者查看应用程序低级函数组成所需时间和技能水平的有效方法。通过剥离二进制文件，二进制文件的符号表被剥离，因此攻击者无法轻松调试或逆向工程应用程序。您可以参考GNU/Linux系统上使用的技术，如sStriping或使用UPX。

最后，你必须意识到混淆和工具，如ProGuard

当您将其放在最终用户手中时，没有什么是安全的，但一些常见的做法可能会使攻击者更难窃取数据。

• 将您的主要逻辑（算法）放在服务器端。
• 与服务器和客户端通信；确保服务器和客户端之间的通信通过SSL或HTTPS得到保护；或使用其他技术进行密钥对生成算法（ECC和RSA）。确保敏感信息保持端到端加密。
• 使用会话并在特定时间间隔后过期。
• 加密资源并按需从服务器获取它们。
• 或者你可以做一个<强>杂交通过#0权限系统保护服务器上的资源+代码的应用程序

多种方法；很明显，你必须在性能和安全之间做出牺牲。

APK签名方案v2在Android 7.0

PackageManager类现在支持使用APK签名方案v2验证应用程序。APK签名方案v2是一种全文件签名方案，可通过检测对APK文件的任何未经授权的更改来显着提高验证速度并加强完整性保证。

为了保持向后兼容性，APK必须先使用v1签名方案（JAR签名方案）进行签名，然后再使用v2签名方案进行签名。对于v2签名方案，如果在使用v2签名方案签名后使用其他证书对APK进行签名，则验证失败。

APK签名方案v2支持将在稍后的N Developer Preview中提供。

http://developer.android.com/preview/api-overview.html#apk_signature_v2

没有办法完全避免APK文件的逆向工程。要保护应用程序资产、资源，您可以使用加密。

• 加密会使不解密的使用变得更加困难。选择一些强大的加密算法会使破解变得更加困难。
• 在主逻辑中添加一些恶搞代码，使其更难破解。
• 如果你可以用任何母语编写你的关键逻辑，那肯定会使反编译变得更加困难。
• 使用任何第三方安全框架，例如Quixxi

如果您的应用程序如此敏感，那么您应该考虑服务器端的支付处理部分。尝试更改您的支付处理算法。仅使用Android应用程序收集和显示用户信息（即账户余额），而不是在Java代码内处理付款，请使用带有加密参数的安全SSL协议将此任务发送到您的服务器。创建完全加密且安全的API与您的服务器通信。

当然，它也可以被黑客攻击，它与源代码保护无关，但可以将其视为另一个安全层，使黑客更难欺骗您的应用程序。

同意@Muhammad Saqib在这里：https://stackoverflow.com/a/46183706/2496464

而@Munair给出了很好的开始步骤：https://stackoverflow.com/a/35411378/474330

假设您分发到用户设备上的所有内容都属于用户，这始终是安全的。简单明了。您可能可以使用最新的工具和程序来加密您的知识产权，但没有办法阻止一个坚定的人“研究”您的系统。即使当前的技术可能使他们难以获得不需要的访问权限，明天甚至下一个小时可能会有一些简单的方法！

因此，这里是等式：

说到钱，我们总是认为客户是不可信的。

即使是在简单的游戏内经济中。（尤其是在游戏中！那里有更多“老练”的用户，漏洞在几秒钟内传播！）

我们如何保持安全？

我们的大部分（如果不是全部）密钥处理系统（当然还有数据库）位于服务器端。在客户端和服务器之间，存在加密通信、验证等。这就是瘦客户端的想法。

工具：在您的应用程序中使用ProGuard，它可以被限制为对您的应用程序进行逆向工程

我可以看到这个问题有很好的答案。除此之外，你可以使用FacebookReDex来优化代码。ReDex工作在.dex级别，ProGuard工作在.class级别。

在Android中，源代码和资源的100%安全性是不可能的。但是，你可以让逆向工程变得有点困难。您可以在下面的链接中找到有关此的更多详细信息：

访问安全地保存常量值应用程序开发人员的移动应用程序安全最佳实践

我知道一些银行应用程序正在使用DexGuard，它提供混淆以及类、字符串、资产、资源文件和本机库的加密。