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

Question

作为this question 的后续行动，我试图弄清楚是什么阻止了 Google 修改它签名和分发的应用程序。无论我们是分发 APK 还是 App Bundle，App Signing 服务都会剥离我们拥有的任何签名，而 Google 会对它分发的 APK 进行签名。对于 App Bundle，这将产生多个 APK，类似于 bundletool 生成的内容。

但由于 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 客户端通信。

亚马逊会删除您的签名并使用您独有的亚马逊签名重新签署您的应用程序，该签名不会更改，并且对于您帐户中的所有应用程序都是相同的。

亚马逊一直在做这种事情for a decade。

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

那么，我是否遗漏了什么可以阻止 Google 添加或修改它重新签名和分发的 APK 中的代码？

Answer 1

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。 从这张图中可以看出；只有两个变化——旧的签名（上传密钥）被删除，并被谷歌签名所取代。并且还略微附加了 AndroidManifest.xml（带有上面提到的元数据）

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

正如其他人指出的那样；谁拥有给定应用程序的签名密钥和访问 Google Play 帐户的权限 - 可以上传任何包含任何内容的 .apk 或 .aab；只要 packageName 保持不变，并且 versionCode 加一。当启用 Google Play 签名时，这同样适用于 Google。如果他们愿意，他们可以更改、删除或添加到应用程序的任何和所有部分。

值得记住的是，虽然是； Google 可以修改 Google Play 签名的.apk 文件中的所有内容，这些修改不一定是邪恶的或出于恶意。无论是出于优化目的、兼容性还是热修复； Google 可以或将修改上传的 apk 并证明这些修改的理由有很多。他们不一定会就此警告开发人员；开发人员也不一定会对这一发现做出强烈反应。

我确实相信我们不太可能看到 Google 故意对上传的应用程序进行恶意内容更改，主要是为了商业、声誉和道德风险，这里的其他答案已经很好地概述了。我只是无法想象这对 Google 来说是一个有价值的攻击媒介，它超过了相当高的成本风险，并且考虑到其他通常更强大的攻击媒介可供他们使用。

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

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

Answer 2

在某些时候，处理器需要能够读取您应用中的指令以了解它应该执行的操作。操作系统本身需要知道如何处理您的应用。

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

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

让我们退后一步：

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

您的问题很有趣，因为它让我想到了其他事情：我猜您提出问题的上下文是“Google 能否在分发之前修改应用程序”。随着现代设备变得越来越强大，有什么办法可以阻止操作系统（因为制造商可以自定义他们的 android 版本）在分发后修改应用程序，或者将来在运行时动态修改应用程序？

我把这篇论文留在下面：

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

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

我还觉得有些有趣的是，人们认为仅仅因为应用程序的源代码可用，就意味着他们可以信任实际在他们的设备上运行的应用程序 - 除非他们经历了实际的麻烦检查他们设备上的应用程序，从技术上讲，他们设备上运行的应用程序可能与源代码描述的不同 - 它可能由开发人员自己修改，或者出于恶意或意外原因分发应用程序的商店.

但信任必须从某个地方开始 ?‍♂️。未来，有了量子计算，我们做事的方式也许会改变。但同样，我们中真正了解系统的每个部分如何工作的人太少了，我们仍然必须把我们的信任放在某个地方。即使我们理解了一些东西，有资源来验证它也是另一回事......

那么是什么阻止了 Google 对其进行修改？

• 他们真的需要吗？开发者通过创建和提交应用为 Google Play 创造价值。
• 如果 Google 在未经您许可的情况下修改了您的应用，您会相信 Google 吗？这将如何影响您对他们作为一家公司的看法，因为隐私已经是一个主要问题。
• 如果他们的修改导致您的应用行为不正确并对客户、您自己或某些第三方实体造成损害，谁将承担责任？

以上只是考虑 Google 是否会修改您的应用时需要考虑的一些原因。这是一罐蠕虫。最后，它归结为成本效益和风险回报分析。他们会为了什么修改您的应用，是否值得冒任何影响的风险？

总而言之，他们不能这样做没有技术原因。为什么他们不/不会归结为他们的商业动机和模式。没有什么可说的，为什么他们将来会或不会。但没有理由任意修改应用程序 - 必须有正当的商业理由才能带来某种收益。

Answer 3

简单的答案：Google 可以，如果他们愿意的话。在数字签名方案中，签名者具有在签名之前修改文档的完整能力。

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

在不通知开发人员的情况下将代码添加到应用程序的影响一旦被发现，很可能会引起强烈反对。当然，在任何进一步的日期，Google 都可以决定更改他们的使用条款，从 DEX 迁移到 LLVM 位码，或者做其他事情，这可能会改变这种行为。

澄清：确实，Google 理论上只能将修改后的应用程序发送到某些目标，但再次检测到这样的事件就足够了（可能是相关的应用程序用户将他或她的 APK 邮寄给开发人员？ ) 对谷歌的影响将是深远的。

顺便说一句，这也适用于 Apple，它是所有 App-Store 应用程序的签名者。在 Apple 案例中，这更是一个问题，因为应用程序可能会被 Apple 重新编译（从 BitCode 到底层 ARMv8 变体），并且应用程序部署由 FairPlay 加密，这使得几乎不可能在越狱设备之外解密应用程序。

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

Answer 4

在此为可能的不合时宜道歉。

当你说

App Signing 服务会剥离我们拥有的任何签名

你确定这就是它的作用吗？可以想象一种替代方案，它可以实现其他答案/ cmets 中提到的所有实际情况：

假设开发人员已经上传了他们的人工制品（比如说 .obb）并使用他们的上传密钥对其进行了签名。谷歌附加其额外的元数据（将其视为一种差异文件）并重新签署生成的扩展有效负载。在设备上收到后，android 检查它收到的有效负载是否由 Google 正确签名（确实如此），删除（但保留）Google 添加的元数据，然后根据开发人员的签名检查剩余的有效负载（开发人员的 .obb） .如果检查出来，它可能会检查，它将添加的元数据中隐含的更改应用于原始 .obb

那个 .obb 成为 android 安装的工件。这不是开发人员上传的内容。 Google 并没有剥离开发者的上传签名，他们只是以一种不会使原始签名无效的方式添加了额外的有效负载，然后添加了更多有效负载和他们自己的签名。

我并不是说这就是他们正在做的事情，只是说这就是他们可能正在做的事情。一旦您下载了有效负载并将其安装在设备上，您就可以检测到这一点。是否可以根据下载发送到哪个设备来实现？我希望这不会很难。在这种情况下，除非您可以访问已针对修改的设备，否则您将无法检测到它。在修改过程发生时很难检测到修改过程。您可以在设备收到时立即区分修改后的有效负载和未修改的有效负载，因为元数据“差异”的存在与否会改变文件大小。

不知道bundletool能否支持这样的方案。我想这就是你可以寻找线索的地方。

他们可能只是剥离了开发者的上传签名并用他们自己的替换它。防止签名剥离的唯一保护措施是接收方进行的检查。

归根结底，如果您认为接收端点受到威胁，您就不能信任任何加密方案。无论负载是加密的（在这种情况下它不是）还是仅签名，如果端点不打算执行该方案，发送者和用户都可能被暴露。

从技术上讲，在这种情况下，端点上的加密由设备制造商控制，尽管他们是否会在违背操作系统提供商（谷歌）的意愿或利益的情况下实际行使这种控制权是值得怀疑的，假设制造商甚至检查这些东西。