826

我正在为 Android 开发一个支付处理应用程序，我想防止黑客访问APK文件中的任何资源、资产或源代码。

如果有人将 .apk 扩展名更改为 .zip，他们可以将其解压缩并轻松访问应用程序的所有资源和资产，并且使用dex2jar和 Java 反编译器，他们还可以访问源代码。对 Android APK 文件进行逆向工程非常容易 - 有关更多详细信息，请参阅 Stack Overflow 问题Reverse engineering from an APK file to a project。

我使用了 Android SDK 提供的 Proguard 工具。当我对使用签名密钥库和 Proguard 生成的 APK 文件进行反向工程时，我得到了混淆代码。

但是，Android 组件的名称保持不变，一些代码（如应用中使用的键值对）保持不变。根据 Proguard 文档，该工具不能混淆 Manifest 文件中提到的组件。

现在我的问题是：

  1. 如何完全防止Android APK 的逆向工程？这可能吗？
  2. 如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解 APK 文件？
  3. 有没有办法让黑客攻击变得更加困难甚至不可能？我还能做些什么来保护我的 APK 文件中的源代码？
4

33 回答 33

398

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

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

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

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

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

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

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

将库放在项目文件夹中默认为“libs”的本机库路径中。如果您为“armeabi”目标构建了本机代码，则将其放在libs/armeabi下。如果它是用armeabi-v7a构建的，则将其放在 libs/armeabi-v7a 下。

<project>/libs/armeabi/libstuff.so
于 2012-12-13T07:03:12.323 回答
139

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

但是，您可以采取一些措施来保护您的源代码，或者至少它的作用（如果不是全部）。

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

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

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

于 2012-12-13T07:07:32.593 回答
126

在计算历史上，当您将软件的工作副本提供给攻击者时，从来没有可能阻止软件的逆向工程。而且，在最有可能的情况下，它永远不可能。

了解了这一点，就有了一个明显的解决方案：不要将你的秘密透露给攻击者。虽然您无法保护 APK 的内容，但您可以保护的是您未分发的任何内容。通常，这是用于激活、支付、规则执行和其他有趣代码的服务器端软件。您可以通过不在您的 APK 中分发有价值的资产来保护它们。相反，设置一个服务器来响应来自您的应用程序的请求，“使用”资产（无论这可能意味着什么），然后将结果发送回应用程序。如果此模型不适用于您心目中的资产，那么您可能需要重新考虑您的策略。

此外，如果您的主要目标是防止应用盗版：请不要打扰。您在这个问题上花费的时间和金钱比任何反盗版措施都可能希望拯救您的时间和金钱还要多。解决这个问题的投资回报率是如此之低，以至于考虑它都没有意义。

于 2012-12-13T08:28:23.160 回答
97

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

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

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

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

现在，大多数计算机都不是在这些类型的环境下使用的；它们实际上是在户外，通过无线电频道连接到互联网。简而言之，它们很容易受到攻击，就像它们的软件一样。因此，他们不值得信任。计算机及其软件必须知道或做某些事情才能发挥作用，但必须注意确保它们永远不会知道或做的事情足以造成损害（至少不会造成超出单台机器范围的永久性损害） ）。

你已经知道了这一切；这就是您试图保护应用程序代码的原因。但是，这是第一个问题；混淆工具可以使代码变得一团糟，人类试图挖掘，但程序仍然必须运行；这意味着应用程序的实际逻辑流程及其使用的数据不受混淆的影响。只要有一点韧性，攻击者就可以简单地对代码进行去混淆处理，在某些情况下，这甚至是不必要的，因为他正在查看的内容只能是他正在寻找的内容。

相反，您应该努力确保攻击者无法对您的代码做任何事情，无论他多么容易获得它的清晰副本。这意味着，没有硬编码的秘密，因为一旦代码离开您开发它的建筑物，这些秘密就不是秘密了。

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

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

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

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

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

现在，攻击者想要的计算机是您的服务器，因为它而不是客户端应用程序/设备可以让他赚钱或让其他人为他的享受而痛苦。没关系; 与尝试保护所有客户端相比，花费金钱和精力来保护服务器会获得更多的收益。该服务器可以位于各种防火墙和其他电子安全系统之后，此外还可以在钢筋、混凝土、钥匙卡/密码访问和 24 小时视频监控之后进行物理保护。您的攻击者确实需要非常复杂才能直接获得对服务器的任何类型的访问权限，并且您将（应该）立即知道它。

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

于 2012-12-13T19:39:20.687 回答
68

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

这是不可能的

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

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

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

再说一次，不，但你可以在某种程度上阻止，也就是说，

  • 从 Web 下载资源并执行一些加密过程
  • 使用预编译的原生库（C、C++、JNI、NDK）
  • 始终执行一些散列（MD5 / SHA密钥或任何其他逻辑）

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

于 2012-12-13T07:11:32.750 回答
42

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

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

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

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

于 2012-12-13T07:07:24.350 回答
37

开发人员可以采取以下步骤来防止 APK 以某种方式被盗，

  • 最基本的方法是使用ProGuard混淆代码之类的工具，但到目前为止，要完全阻止某人反编译应用程序是相当困难的。

  • 我也听说过一个工具HoseDex2Jar。它Dex2Jar通过在 Android APK 中插入无害的代码来停止，这些代码会混淆和禁用Dex2Jar并保护代码免于反编译。它可以以某种方式阻止黑客将 APK 反编译为可读的 Java 代码。

  • 仅在需要时才使用某些服务器端应用程序与应用程序进行通信。它可以帮助防止重要数据。

根本无法完全保护您的代码免受潜在黑客的攻击。不知何故，您可能会使他们反编译您的代码变得困难且令人沮丧。最有效的方法之一是编写本机代码（C/C++）并将其存储为编译库。

于 2012-12-13T06:55:28.927 回答
30

您可以尝试以下几种方法：

  1. 使用混淆和ProGuard等工具。
  2. 加密部分源代码和数据。
  3. 在应用程序中使用专有的内置校验和来检测篡改。
  4. 引入代码避免在调试器中加载，即让应用程序具有检测调试器并退出/杀死调试器的能力。
  5. 将身份验证分离为在线服务。
  6. 使用应用程序多样性
  7. 在对设备进行身份验证之前，使用指纹技术，例如，来自不同子系统的设备的硬件签名。
于 2013-01-01T15:49:48.367 回答
25

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

不可能的

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

不可能的

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

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

于 2012-12-13T07:04:17.243 回答
22

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

那是不可能的

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

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

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

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

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

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

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

于 2012-12-14T05:11:14.480 回答
21

这里的主要问题是 dex 文件是否可以反编译，答案是它们可以是“某种”。有dedexer和smali等反汇编程序。

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

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

于 2012-12-13T07:11:26.243 回答
12

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

上面谈论你有能力改变后端的事务处理系统是荒谬的——你不应该被允许做这样的架构改变，所以不要指望能够做到。

我对此的理由：

由于您的域是支付处理，因此可以安全地假设 PCI DSS 和/或 PA DSS（以及潜在的州/联邦法律）对您的业务很重要——要合规，您必须证明您是安全的。要不安全，然后（通过测试）发现您不安全，然后修复、重新测试等，直到可以在合适的级别验证安全性 = 昂贵、缓慢、高风险的成功方式。做正确的事，提前思考，让有经验的人才投入工作，以安全的方式开发，然后测试、修复（更少）等等（更少），直到可以在合适的水平上验证安全性 = 便宜、快速、低风险的成功之路。

于 2012-12-13T12:16:08.287 回答
10

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

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

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

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

于 2012-12-14T00:30:29.580 回答
10

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

此外，您不应在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。它还可以让您以后更轻松地符合 PCI 标准，并且信用卡公司不会对您嗤之以鼻（就像他们为我们所做的那样）。

于 2012-12-16T15:17:44.497 回答
9

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

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

于 2012-12-13T19:45:29.223 回答
7

Agreed with @Muhammad Saqib here: https://stackoverflow.com/a/46183706/2496464

And @Mumair gives good starting steps: https://stackoverflow.com/a/35411378/474330

It is always safe to assume that everything you distribute to your user's device, belong to the user. Plain and simple. You may be able to use the latest tools and procedure to encrypt your intellectual property, but there is no way to prevent a determined person from 'studying' your system. And even if the current technology may make it difficult for them to gain unwanted access, there might be some easy way tomorrow, or even just the next hour!

Thus, here comes the equation:

When it comes to money, we always assume that client is untrusted.

Even in as simple as an in-game economy. (Especially in games! There are more 'sophisticated' users there and loopholes spread in seconds!)

How do we stay safe?

Most, if not all, of our key processing systems (and database of course) located on the server side. And between the client and server, lies encrypted communications, validations, etc. That is the idea of a thin client.

于 2018-01-25T10:01:50.827 回答
5

我建议您查看Protect Software Applications from Attacks。这是一项商业服务，但我朋友的公司使用了它，他们很高兴使用它。

于 2012-12-13T08:29:14.143 回答
4

APK signature scheme v2 in Android 7.0 (Nougat)

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

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

于 2016-05-16T11:09:32.580 回答
4

There is no way to completely avoid reverse engineering of an APK file. To protect application assets, resources, you can use encryption.

  • Encryption will make harder to use it without decryption. Choosing some strong encryption algorithm will make cracking harder.
  • Adding some spoof code into your main logic to make it harder to crack.
  • If you can write your critical logic in any native language and that surely will make harder to decompile.
  • Using any third party security frameworks, like Quixxi
于 2016-10-12T04:16:19.717 回答
3

基本上是不可能的。这永远不可能。不过，还是有希望的。您可以使用混淆器来制作它，这样一些常见的攻击就更难执行了，包括：

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

我敢肯定还有其他的，但这是主要的。我在.NET混淆器上为一家名为 PreEmptive Solutions 的公司工作。他们还有一个适用于 Android 的 Java 混淆器以及一个名为DashO的混淆器。

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

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

此外，不只是安卓有这个问题。这是每个应用商店的问题。这只是获取包文件的难度问题（例如，我不相信在 iPhone 上这很容易，但仍然有可能）。

于 2012-12-13T15:31:22.507 回答
3
于 2015-11-26T07:17:01.853 回答
3

If your app is this sensitive then you should consider the payment processing part at the server side. Try to change your payment processing algorithms. Use an Android app only for collecting and displaying user information (i.e., account balance) and rather than processing payments within Java code, send this task to your server using a secure SSL protocol with encrypted parameters. Create a fully encrypted and secure API to communicate with your server.

Of course, it can also be hacked too and it has nothing to do with source code protection, but consider it another security layer to make it harder for hackers to trick your app.

于 2017-09-12T19:05:26.823 回答
3

100% security of the source code and resources is not possible in Android. But, you can make it little bit difficult for the reverse engineer. You can find more details on this in below links:

Visit Saving constant values securely and Mobile App Security Best Practices for App Developers.

于 2019-05-24T07:02:59.767 回答
2

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

它们在个人电脑（尤其是苹果电脑）上变得越来越普遍，而且它们可能已经存在于今天的智能手机芯片中。不幸的是，还没有任何操作系统 API 可以使用它。希望有一天，Android 会增加对此的支持。这也是清理内容 DRM（Google 正在为WebM开发的）的关键。

于 2013-01-08T13:32:58.633 回答
2

Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

  • Put your main logic (algorithms) on the server side.
  • Communicate with the server and client; make sure communication between server and client is secured via SSL or HTTPS; or use other techniques for key-pair generation algorithms (ECC and RSA). Ensure that sensitive information is remain end-to-end encrypted.
  • Use sessions and expire them after a specific time interval.
  • Encrypt resources and fetch them from the server on demand.
  • Or you can make a hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security.

于 2016-02-15T14:02:10.613 回答
2

Tool: Using ProGuard in your application, it can be restricted to reverse engineering your application

于 2018-03-14T10:25:34.343 回答
2

I can see that there are good answers for this question. In addition to that, you can use Facebook ReDex to optimize the code. ReDex works on the .dex level where ProGuard works as .class level.

于 2018-09-05T10:46:32.673 回答
2

I know some banking apps are using DexGuard which provides obfuscation as well as encryption of classes, strings, assets, resource files and native libraries.

于 2020-05-08T15:00:30.957 回答
1

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

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

于 2012-12-19T05:16:36.047 回答
0

当他们在手机上安装该应用程序时，他们可以完全访问它的内存。因此，如果您想防止它被黑客入侵，您可以尝试使其无法使用调试器直接获取静态内存地址。如果他们有地方可以写并且有限制，他们可以进行堆栈缓冲区溢出。所以尽量做到这一点，当他们写东西时，如果你必须有一个限制，如果他们发送的字符多于限制，如果（输入>限制）然后忽略，所以他们不能把汇编代码放在那里。

于 2015-09-03T09:58:58.240 回答
-1

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

我知道的另一个技巧是将有价值的代码存储为 Java 库。然后将该库设置为您的 Android 项目。可以作为 C .so 文件使用，但 Android Lib 可以。

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

于 2013-04-05T05:44:48.363 回答
-3

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

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

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

比如APK 保护。这是一个APK的在线加密网站。提供Java代码和C++代码保护，实现反调试和反编译效果。操作过程简单易行。

于 2013-07-16T07:25:11.907 回答
-5

不行，做不到！

您的三个问题围绕 100% 保护应用程序不被阅读。原则上是做不到的。你投入的越多，你的体验就越糟糕，最终，任何一台机器试图读取你的应用程序都会变得更糟糕。想想HTTPS本质上比 HTTP 有多慢，因为需要处理安全层和数学。层数越多，别人打开它的速度就越慢，但绝不是不可能的，因为你真的希望它被阅读，这就是为什么它被做成一个包并交付的原因。

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

虚假的安全感

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

现在，就如何改进服务器端，坚持我的另一个想法......

嘴上的钱

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

谷歌通过使用简单的财务方法来“保护”谷歌浏览器，成功地避免了一般的恶意黑客，我引用：

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

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

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

明显的例外

诚然，这不会保护我们免受“疯子”和“幸运的恶作剧者”的伤害......但没有什么可以。同时，如果设置得当，后一组只能在里面享受很少的时间，而系统会重新调整。我们只需要担心一个疯子，以防它变得大到有克星。无论如何，这将是一个伟大的故事！:)

太长; 没读过；

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

很久以前，我尝试写更多关于上述所有内容的内容，以回答诸如为什么我将“安全”和“保护”放在引号中的问题（它们的真正含义是什么？）。

于 2015-11-12T10:37:34.440 回答