Android 7.0中的APK签名方案v2（Nougat）

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

为了保持向后兼容性，APK必须在使用v2签名方案签名之前使用v1签名方案（JAR签名方案）签名。使用v2签名方案，如果在使用v2方案签名后使用附加证书对APK进行签名，则验证失败。

APK签名方案v2支持稍后将在N开发者预览版中提供。

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

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

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

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

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

不，不可能！

你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且，你在尝试做这件事上投入的越多，你的体验就会越差，最终，无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢，因为需要处理安全层和数学。层数越多，有人打开它的速度就越慢，但如果你真的想让它被阅读，那就永远不可能，这就是为什么它会被打包并交付的原因。

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

假安全感

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

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

嘴上的钱

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

谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome，在总体上成功地避免了恶意黑客，我引述如下：

我们有50000美元的奖励，奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试

我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励，但即使是1k的奖励也会有很长的路要走，而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。

投资于人工智能来识别资金流动模式，以预测潜在风险并发现小的泄漏，这也比通过任何工程来防止这两种情况要便宜得多。

明显的例外

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

太长；没有阅读；

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

很久以前，我曾尝试写更多关于以上所有内容的文章，以回答一些问题，比如为什么我在引号中加上“安全”和“保护”（它们到底是什么意思？）。

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

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

应用程序安全的第一条规则：攻击者获得不受限制的物理或电子访问权限的任何机器现在都属于您的攻击者，无论其实际位置或您为此支付的费用。应用程序安全的第二条规则：任何离开攻击者无法穿透的物理边界的软件现在都属于您的攻击者，无论您花费了多少时间对其进行编码。第三条规则：任何离开攻击者无法穿透的物理边界的信息都属于您的攻击者，无论它对您有多大价值。

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

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

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

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

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

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

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

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

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

现在，攻击者想要的计算机是你的服务器，因为它而不是客户端应用程序/设备是可以让他赚钱或让其他人痛苦的东西。没关系；与试图保护所有客户机相比，您花费金钱和精力来保护服务器会获得更大的回报。该服务器可以位于各种防火墙和其他电子安全装置的后面，此外，还可以在钢铁、混凝土、钥匙卡/插针访问和24小时视频监控的后面进行物理保护。您的攻击者需要非常老练才能直接访问服务器，而且您应该立即了解这一点。

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

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

重命名方法/类（因此在反编译器中，您可以获得像.a这样的类型）使控制流混乱（因此在反编译器中，代码很难阅读）加密字符串和可能的资源

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

不过，困惑总是有代价的。值得注意的是，性能通常更差，通常需要一些额外的时间来发布。然而，如果你的知识产权对你来说非常重要，那么它通常是值得的。

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

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