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

Question

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

但由于 APK 只是一个带有编译代码和资源的 ZIP 存档，似乎谷歌可以在签名之前按照他们认为合适的方式修改它，包括添加或替换代码。

谷歌已经声明：

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

和：

如前所述，Play 不会在您不知情和批准的情况下修改您的应用程序的功能。

值得注意的是，谷歌使用了“不要”和“不会”……而不是“不能”和“不能”。事实上，在同一篇文章中，我们看到：

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

因此，我们知道至少一种修改，尽管是元数据。

此外， Android 版 Amazon AppStore 在重新签署 APK 之前会修改它们：

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

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

十年来，亚马逊一直在做这种事情。

似乎谷歌应该拥有与亚马逊相同的技术能力。

那么，是否有任何我遗漏的东西会阻止 Google 添加或修改它重新签名和分发的 APK 中的代码？

Answer 1

谷歌不仅有能力修改.apk上传到它的 Google Play 签名程序的文件——他们已经有了。

诚然，这是目前的一个小变化，当然是一个非恶意的变化；但它仍然是您的.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 中逐个启用的功能。今天，当然，除了本视频之外，您在任何文档中都不会发现任何相关内容——那是因为他们后来提出了应用程序包，并且基本上将所有这些工作都转移到了其中。所以，这很重要，因为问题是“什么阻止 Google 修改我们通过应用签名服务签名的 APK？”，这表明即使专门针对.apk文件，他们也可以；他们打算；他们是。

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

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

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

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

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

Answer 2

在某些时候，处理器需要能够读取应用程序中的指令，以了解它\xe2\x80\x99s应该做什么。操作系统本身需要知道如何处理您的应用程序。

\n

出于上述原因，暂时忽略应用程序的打包方式，在我看来，没有技术原因可以解释为什么您的应用程序不能被 Google 或任何拥有相关知识和资源的技术实体修改。让我进一步解释一下原因：

\n

\xe2\x80\x99 应用程序的打包方式并不重要 - 当操作系统加载应用程序时，您就知道该应用程序的用途。如果操作系统不知道如何处理应用程序，则该应用程序将毫无用处。\n您可以尝试混淆它，就像一些流行的蠕虫试图隐藏其目的一样，但这实际上只是推迟了不可避免的事情。人们从一开始就对软件进行反汇编和反编译，\xe2\x80\x99 这就是为什么许多许可证都明确禁止反汇编。\n了解了这一点，应该很明显如果 \xe2\x80\x9cGoogle\xe2\x80\x9d想要修改您的应用程序，他们可以，因为即使包被混淆，当应用程序最终执行时，您可以看到它在做什么，记录它，然后根据需要修改应用程序。他们还拥有这样做所需的所有技术技能和资源。

\n

让\xe2\x80\x99s退一步：

\n

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

\n

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

\n

我\xe2\x80\x99m 将这篇论文留在这里：

\n

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

\n

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

\n

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

\n

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

\n

那么是什么阻止谷歌对其进行修改呢？

\n

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

\n

以上只是在考虑 Google 是否会修改您的应用程序时需要考虑的一些原因。它\xe2\x80\x99是一群蠕虫。最后，归结为成本效益和风险回报分析。他们会修改您的应用程序以实现什么目的？是否值得冒造成后果的风险？

\n

总而言之，没有任何技术原因可以解释为什么它们可以\xe2\x80\x99t。为什么他们不\xe2\x80\x99t / 不会\xe2\x80\x99t 归结为他们的商业动机和模式。没有什么可说的，为什么他们将来会或不会\xe2\x80\x99t。但没有理由任意修改应用程序 - 必须有有效的商业理由才能带来某种收益。

\n