是什么阻止Google修改通过应用签名服务签名的APK？

问题描述

作为this question的后续活动，我试图找出阻止Google修改其签名和分发的应用程序的原因。无论我们分发的是APK还是应用程序捆绑包，“应用签名”服务都会剥夺我们拥有的任何签名，然后Google会对其分发的APK进行签名。对于App Bundle，这将导致多个APK，类似于bundletool生成的APK。

但是，由于APK只是具有已编译代码和资源的ZIP归档文件，因此Google似乎可以在签名之前对其进行适当修改，包括添加或替换代码。

Google has stated：

在您不了解和未批准的情况下，我们不会修改和分发您的应用程序代码

和：

如前所述，未经您的了解和认可，Play不会修改您的应用程序的功能。

值得注意的是，与“不能”和“不能”相比，Google使用了“不要”和“不会”...。实际上，在同一篇文章中，我们看到：

对于作为应用程序捆绑包上传的应用程序，我们将通过引入所谓的源戳来提高这种安全性。此源元数据通过bundletool插入到应用的清单中。

因此，我们知道至少进行了一次修改，即使对元数据也是如此。

另外， the Amazon AppStore for Android modifies APKs before re-signing them：

无论您是否选择应用Amazon DRM，Amazon都会使用使应用程序与Amazon Appstore客户端进行通信以收集分析，评估和实施程序策略以及与您共享汇总信息的代码来包装您的应用程序。即使您选择不应用DRM，您的应用程序在启动时将始终与Amazon Appstore客户端通信。

Amazon删除您的签名，并使用对您来说唯一的，不变的且对您帐户中所有应用程序都相同的Amazon签名对应用程序重新签名。

Amazon一直在做这种事情for a decade。

似乎Google应该具有与Amazon相同的技术能力。

那么，我缺少什么阻止Google添加或修改其重新签名和分发的APK中的代码了吗？

解决方法

Google不仅具有修改上传到其Google Play签名程序中的.apk个文件的功能，而且已经可以。

当然，这是次要的更改，肯定是非恶意的更改；但实际上仍然是您的.apk的更改。他们添加

<meta-data
      android:name="com.android.vending.derived.apk.id"
      android:value="1" />

到AndroidManifest.xml

以下是我在2018年研究此主题时所做的比较。它具有上传前的apk（使用上传密钥签名），以及从Google Play下载且启用了Google Play签名的apk。 正如您从该图中看到的；仅有两处更改-删除了旧的签名（上传密钥），并替换为Google签名。并且还稍微附加了AndroidManifest.xml（带有上面提到的元数据）

我还将指出2017年的Google IO视频，他们将在其中介绍Google Play签名：https://www.youtube.com/watch?v=5tdGAP927dk&feature=youtu.be。从11:25开始，他们谈论的是所谓的“应用签名+优化”。他们的想法是他们可以为您优化apk，并生成子应用。 您可以在Google Play中逐个启用此功能。当然，今天，除了该视频外，您在任何文档中都没有提到任何这些内容，因为这是因为他们后来提出了应用程序捆绑包，并且实质上将所有这些工作都移到了其中。因此，这主要是相关的，因为问题是“什么阻止Google修改通过应用签名服务签名的APK？”，这表明即使是.apk文件，它们也可以做到；他们打算；他们是。

正如其他人指出的那样；拥有签名密钥并有权访问给定应用程序的Google Play帐户的人可以上传任何包含任何内容的.apk或.aab；只要packageName保持不变，并且versionCode递增1。启用Google Play签名后，Google当然也是如此。如果他们愿意，他们可以更改，删除或添加到应用程序的任何及所有部分。

值得记住的是，是的； Google可以修改Google Play签名的.apk文件中的所有内容，而这些修改不一定是邪恶的或有恶意的。是否出于优化目的，兼容性或热修复； Google有很多理由可以或会修改上传的apk并证明这些修改是合理的。他们并不一定会警告开发人员。开发人员也不必大声疾呼对这一发现做出反应。

我确实相信我们不太可能看到Google对上传的应用程序进行故意的恶意内容更改，主要是出于业务，声誉和道德风险的考虑，这些问题已在此处的其他答案中进行了概述。我只是无法想象这对Google来说是有价值的攻击媒介，它超过了相当沉重的成本风险，并考虑了他们可以使用的其他通常更强大的媒介。

最后，我将提到完整性检查，这是一种发现完整性检查的方法。在这个领域中，有几种解决方案比签名检查更进一步，以验证应用程序的完整性。应用程序开发人员是自己开发应用程序还是使用现成的解决方案-这些检查通常在运行时在设备上运行，以验证apk的完整性；与在编译时或接近编译时获取的记录进行比较。在运输过程中对apk所做的修改确实会被此修改，包括Google Play可能所做的任何更改。

免责声明：我为一家应用安全公司工作，该公司在我们保护的应用上执行此类完整性检查（其他许多检查和验证）。我们必须计划并考虑Google Play对常规apk文件和应用程序捆绑包可能对应用程序所做的所有更改-因此我们可以区分Google Play做优化和恶意参与者重新打包应用程序。

,

在某个时候，处理器需要能够阅读您应用程序中的指令以了解其功能。操作系统本身需要知道如何处理您的应用。

由于上述原因，暂时忽略了应用程序的打包方式，在我看来，没有任何技术原因可导致您的应用程序无法被Google或任何具有相关知识和资源的技术实体修改。让我进一步解释原因：

应用程序的打包方式无关紧要-操作系统加载应用程序后，您便知道应用程序的功能。如果操作系统不知道如何处理应用程序，则该应用程序将无用。 您可以尝试以一些流行的蠕虫试图隐藏其目的的方式对其进行混淆，但这实际上只是在延迟不可避免的情况。人们从一开始就一直在拆卸和反编译软件，这就是为什么许多许可证用来明确禁止拆卸。 知道了这一点，很明显，如果“ Google”想要修改您的应用程序，则可以进行修改，因为即使软件包被混淆了，当该应用程序最终执行时，您也可以查看其操作，然后对其进行记录，然后修改该应用程序按要求。他们还拥有这样做的所有技术技能和资源。

让我们退后一会儿：

使用签名对某物进行签名的目的是使人们可以确定他们收到的应用程序的副本是否是真实的-在这种情况下，如果最终用户收到的应用程序与游戏商店中的内容匹配。目的是确保您拥有的副本与分发给其他用户的副本相同。 您是在问Google无法修改应用程序的技术原因-没有。您已经提到自己apk只是一个zip文件。如果您的应用是您自己签名的，并且最终用户收到的应用副本中包含相同的签名，则最终用户可以验证Google是否篡改了您的应用。但是，如果您的签名被删除，那么用户就不得不信任Google。

您的问题很有趣，因为它使我想到了其他事情：我猜您问问题的上下文是“ Google能够在发布前修改该应用程序”。随着现代设备功能的日益强大，该阻止操作系统（因为制造商可以自定义其android版本），阻止它在发布后或以后在应用执行时立即对其进行修改？

我将这篇论文留在下面

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

原因似乎是，这将永远是一个长期的问题，因为人类不可能单枪匹马地验证我们今天使用的那种系统中的每个软件。

我还觉得有些奇怪，因为人们认为仅因为源代码可用于应用程序，这意味着他们可以信任实际在其设备上运行的应用程序-除非他们经历了检查其设备上的应用程序，从技术上讲，其设备上运行的应用程序可能与源代码描述的不一样-开发人员本身或商店出于恶意或意外原因分发了该应用程序都可能对其进行了修改

但是信任必须从某个地方开始。将来，借助量子计算，也许我们做事的方式将会改变。但是，实际上我们当中很少有人真正了解系统的每个部分是如何工作的，我们仍然必须将信任放在某个地方。即使我们了解某些内容，也有资源进行验证也是另一回事...

那么阻止Google对其进行修改的原因是什么？

• 他们真的需要吗？开发人员通过创建和提交其应用来为Google Play创造价值。
• 如果Google未经您的许可修改了您的应用，您会信任他们吗？由于隐私已经是一个主要问题，它将如何影响您对它们作为公司的看法。
• 如果对它们的修改导致您的应用程序运行不正常，并损害客户，您自己或某些第三方实体，谁将承担责任？

以上只是考虑Google是否会修改您的应用时要考虑的一些原因。一罐蠕虫。最后，可以归结为成本效益和风险回报分析。他们会为您的应用程序修改些什么，这是否值得引起反响？

总而言之，没有技术原因不能做到。为什么他们不/不会归结为他们的商业动机和模型。没有什么可说的，为什么他们将来会或不会。但是没有理由随意修改应用程序-必须有有效的商业理由才能获得某种收益。

,

简单答案：Google愿意的话。在数字签名方案中，签名者具有在签名之前修改文档的完整功能。

为什么不这样做：因为开发人员可以轻松检测到它，并且最重要的有效负载-实际上包含代码的classes * .dex可以很容易地被感兴趣的第三方（或应用程序创建者）反编译找出任何添加的代码。 （将代码添加到JNI库的可能性很小）。要澄清的是，开发人员的检测就像解压缩APK并将其内容与开发人员提交的内容进行比较一样容易。

在未通知开发人员的情况下向应用程序添加代码的影响可能会引起强烈反响（如果发现）。当然，在任何其他日期，Google都可以决定更改其使用条款，从DEX迁移到LLVM位码，或执行其他操作，这可能会改变这种行为。

澄清：的确，从理论上讲，Google可以仅将修改后的应用程序交付给特定的目标，但再次足以检测到一个此类事件（也许是由相关的应用程序用户将其APK邮寄给开发人员？ ），对Google的影响是深远的。

顺便说一句，Apple也是如此，它是所有App Store应用程序的签名者。在Apple案例中，这甚至是个问题，因为Apple可能会重新编译应用程序（从BitCode到底层的ARMv8变体），并且应用程序通过FairPlay进行加密部署，这实际上使得在越狱设备外解密应用程序几乎是不可能的。

作为轶事，您可能想知道恶意设备供应商是否无法在设备本身安装并编译应用程序时更改dex2oat（设备上编译器）以注入任意代码。这将很难检测到，因为在没有root权限的设备上，将没有一种简单的方法来访问应用程序的已编译art / atat文件。但是，恶意供应商也可以直接修改Android框架。