Google通过应用签名服务签署的APK文件，为什么不能修改它？

Question

Google通过应用签名服务签署的APK文件，为什么不能修改它？

36

作为这个问题的后续，我正在尝试弄清楚什么阻止谷歌修改并分发我们签名的应用程序。无论我们是分发APK还是App Bundle，应用签名服务都会剥离我们所拥有的任何签名，并由谷歌签署它所分发的APK。对于App Bundle，这将导致几个APK，类似于bundletool生成的内容。

但由于APK只是编译代码和资源的ZIP归档文件，因此在签名之前，谷歌似乎可以随意修改它，包括添加或替换代码。谷歌已经声明：

我们不会未经您的知识和批准修改和分发您的应用程序代码。

以及：

如前所述，Play 不会在未经您的知识和批准时修改应用程序的功能。

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

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

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

此外，Amazon AppStore for Android在重新签署APK之前会对其进行修改：

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

Amazon会删除您的签名并使用唯一于您的Amazon帐户中所有应用程序相同的Amazon签名重新签署您的应用程序。

Amazon已经做了这样的事情十年了。

看起来谷歌应该拥有与亚马逊相同的技术能力。

那么，有什么东西阻止谷歌在重新签署和分发APK时添加或修改代码吗？

- CommonsWare

我认为你说得很对：通过使用谷歌的应用签名服务，你正在信任他们不会进行任何恶意更改。话虽如此，即使你自己进行签名，你已经在信任谷歌，因为他们还控制着Play商店应用程序，该应用程序（如果我理解正确）负责在安装之前验证应用程序签名。 - Thomas

@Thomas：“他们还控制着Play Store应用程序，该应用程序（如果我理解正确）负责在安装之前验证应用程序签名”--这由操作系统处理，而不是分发渠道客户端。 - CommonsWare

不是针对你的问题的答案，但谷歌不需要修改你的代码。Android系统本身“知道”你的应用程序正在做什么，并且可以在不修改你的文件的情况下完成所有必要的操作。 - Captain Kenpachi

1

@CaptainKenpachi：对于这个问题，我并不真正关心其他攻击向量，只关注这一个。 - CommonsWare

明白了，我这样理解。 - Captain Kenpachi

显示剩余2条评论

4个回答

1

在某个时刻，处理器需要能够读取您的应用程序中的指令，以知道它应该做什么。操作系统本身需要知道如何处理您的应用程序。

暂且不考虑应用程序的打包方式，出于上述原因，我认为没有技术原因阻止Google或任何具有相关知识和资源的技术实体修改您的应用程序。让我进一步解释：

无论应用程序如何打包 - 操作系统加载应用程序的那一刻，您就知道应用程序的功能。如果操作系统不知道如何处理应用程序，则该应用程序将毫无用处。您可以尝试混淆它，就像一些流行的蠕虫试图隐藏其目的一样，但这只是拖延不可避免的结果。人们从一开始就一直在反汇编和反编译软件，这就是为什么许多许可证曾经明确禁止反汇编。了解这一点后，显然，如果“谷歌”想要修改您的应用程序，他们可以这样做，因为即使包被混淆，当应用程序最终执行时，您可以看到它正在做什么，然后记录下来，根据需要修改应用程序。他们也拥有所有必要的技术技能和资源。

让我们暂停一下：

使用签名进行签署的目的是为了确定接收到的应用程序副本是否真实，即在这种情况下，最终用户接收到的应用程序是否与Play商店上的应用程序匹配。目的是确保您拥有的副本与分发给其他用户的副本相同。您问的是Google无法修改应用程序的技术原因 - 并没有。您自己提到apk只是一个zip文件。如果您的应用程序由您自己签名，并且该相同的签名包含在最终用户接收到的应用程序副本中，则最终用户可以验证Google是否篡改了您的应用程序。但是，如果您的签名被剥离，则用户只能信任Google。

您的问题很有趣，因为它让我想到了另一件事：我猜您提出问题的背景是“Google是否能够在分发之前修改应用程序”。随着现代设备变得越来越强大，什么能阻止操作系统（因为制造商可以定制他们的Android版本）在分发后或将来在执行期间动态修改应用程序呢？

我在下面留下这篇文章：

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

由于在我们今天使用的系统中，人类不可能单独验证每个软件的每一部分，因此这似乎将永远是一个长期存在的问题。

我也觉得有点有趣的是，人们认为只要应用程序的源代码可用，就意味着他们可以信任实际在设备上运行的应用程序 - 除非他们已经费力地检查了设备上的应用程序，否则从技术上讲，运行在他们设备上的应用程序可能与源代码描述的不同 - 它可能已被开发人员本身或分发应用程序的商店出于恶意或意外原因进行修改。

但信任必须从某个地方开始。未来，随着量子计算的发展，我们可能会改变做事的方式。但再次，能够真正理解系统每个部分的人很少，我们仍然必须把信任放在某个地方。即使我们理解某些东西，拥有资源来验证它也是另一回事...

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

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

以上只是考虑谷歌是否会修改您的应用程序时要考虑的一些原因。这是一个棘手的问题。最终，这归结于成本效益和风险回报分析。他们会修改您的应用程序用于什么目的，这是否值得承担任何后果的风险？

总之，技术上没有理由他们不能这样做。他们不这样做的原因是由于他们的商业动机和模式。没有什么可以说明他们将来会或不会这样做。但是，没有任何理由武断地修改应用程序 - 必须有一个有效的业务原因，从而产生某种收益。

- Rahul Iyer

2

精美的代码，但它是否是提问者寻求的答案？实际问题的答案是否技术上可行/可能？即使有这样的方法，为什么谷歌甚至亚马逊会让它在公共平台上停留？难道这不是我们通过修改应用程序的方式来妥协谷歌和其他商店（试图）实施的安全性吗？如果有一种防止谷歌修改apk的方法可用，那么谁会确保开发人员的意图（如果恶意）？我同意信任必须从某个地方开始，但是什么实际上阻止了谷歌修改应用程序的代码？价值观？道德？ - Lalit Fauzdar

1

我猜你提出问题的背景是“Google在分发应用之前能否修改应用”——嗯，是的。我的意思是，字面上的问题是：“有什么东西阻止Google在重新签名和分发APK时添加或修改代码吗？”我熟悉汤普森的论文等等。你的回答从粗体“那么是什么阻止了Google的修改呢？”开始，就是我想知道是否有我不知道的技术障碍的原因——感谢你的回答！ - CommonsWare

@CommonsWare 我在第二段回答了这个问题。但是如果你觉得这个答案与主题无关或以某种方式分散了你的注意力，我可以删除它。 - Rahul Iyer

@CommonsWare，另外，关于你的引用“我猜上下文......”，我想表达的是，随着处理能力的提高，将来可能会在分发后修改apk。 - Rahul Iyer

“分发后修改 APK 可能是可能的”- 就此问题而言，我不太关心其他攻击矢量，只关心这一点。 “我在第二段回答了那个问题”- 我认为你的分析是正确的。然而，按照问题的描述，它旨在寻求“这是障碍”的答案或者不回答。你的分析隐含了一个“据我所知”的免责声明，这也是我没有投票或接受它的原因，但我希望你会得到奖励。 - CommonsWare

事实上，我的问题处于 SO 可接受范围的边缘。如果它被投票关闭，我也不会争辩。我认为你的回答增加了价值，并建议你保留它。 - CommonsWare

0

在此可能会出现时代错误，敬请谅解。

当您说

应用签名服务会去除我们所拥有的任何签名

您确定它是这样做的吗？我们可以想象一种替代方案，它可以实现其他答案/评论中所述的所有内容：

假设开发者已上传其工件（例如 .obb 文件）并使用其上传密钥进行了签名。Google 附加其额外的元数据（将其视为一种差异文件）并重新对结果进行签名以产生扩展后的负载。在接收到设备时，Android 检查其收到的负载是否由 Google 正确签名（是的），删除（但保留）Google 添加的元数据，然后检查剩余的负载（开发者的 .obb）是否与开发者的签名一致。如果这个检查通过，而且这很可能是的，那么就将隐含在添加的元数据中的更改应用于原始的 .obb 中。

那个 .obb 变成了 Android 安装的工件。它不是开发者上传的那个。Google 没有剥夺开发者的上传签名，他们只是以一种不使原始签名失效的方式添加了额外的负载，然后添加了一些额外的负载和他们自己的签名。

我并不是在说他们正在这样做，只是他们可能会这样做。一旦您下载了有效负载并将其安装到设备上，您就能够检测到这一点。根据发送哪个设备的下载情况，它能否实现呢？我认为那不难。在这种情况下，除非您能够访问到被针对修改的设备，否则您将无法检测到它。在修改过程进行时检测到修改过程将非常困难。接收设备可以通过元数据“diff”的存在或缺失来立即区分修改后的有效负载和未修改的有效负载。

我不知道bundletool是否支持这种方案。我想那是您可以寻找线索的地方。

他们可能只是剥离开发者上传签名并用自己的签名替换它。对签名剥离的唯一保护来自接收方的检查。

当涉及到这个问题时，如果接收端可能会被入侵，您不能信任任何加密方案。无论有效负载是否加密（在这种情况下没有），或者仅仅是签名，如果接收端不执行方案，则发送者和用户都可能遭受攻击。

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

- JamesD

“你确定这就是它的功能吗？”-- 考虑到旧的签名已经消失，是的。更不用说谷歌自己也说这就是他们所做的了。 - CommonsWare

@commonsware：我在你的原始帖子中看到亚马逊明确表示它正在剥离开发者的签名。我没有看到Google有类似明确的声明。delkan发布的证据很有说服力，但我不确定他的屏幕截图是否代表了在Google Play上存储的工件（在设备下载和安装之前）或代表了从Google Play在设备上正常业务过程中安装的东西。如果是前者，则是签名剥离的决定性证据；如果是后者，则不是。 - JamesD

@JamesD，我帖子中的图片所呈现的工件代表了Before和After两种状态。其中，“After”指的是从Google Play下载并安装到设备上后的状态。 - Dellkan

谢谢您澄清。我宣布自己被说服了。 - JamesD

0

简单回答：如果谷歌想的话，他们是可以的。在数字签名方案中，签署者在签名之前完全有能力修改文档。

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

如果在未通知开发人员的情况下向应用程序添加代码，可能会引起相当大的反弹。当然，在任何进一步的日期，谷歌都可以决定更改他们的使用条款，从DEX迁移到LLVM位码，或者做其他事情，这可能会改变这种行为。

澄清一下：确实，理论上谷歌可以仅向某些目标发送修改后的应用程序，但再次强调，只需发现一个这样的事件（也许是一个关注的应用程序用户将他或她的APK邮寄给开发人员？）就足以对谷歌产生深远的影响。

顺便提一下，这也适用于苹果公司，因为它是所有应用商店应用的签名者。在苹果的情况下，这更是一个问题，因为应用程序可能会被苹果重新编译（从BitCode到底层的ARMv8变体），并且应用程序由FairPlay加密部署，这使得在越狱设备之外解密应用程序几乎不可能。

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

- Technologeeks

澄清：因此添加。 - Technologeeks

开发者的检测只需要解压APK并将其内容与开发者提交的内容进行比较，这一点非常容易。但是，由于应用程序包和生成的N个APK文件，情况会比这更加复杂，无论是开发者获得被篡改的应用程序还是用户获得被篡改的应用程序并以某种方式向开发者发送信息。虽然不是不可能，但在我看来，“容易”相当乐观，这就是为什么我认为几乎没有开发者实际检查此类篡改的原因。谢谢！ - CommonsWare

我要表达的意思是，无论有多少变体，它们仍然是相同的*.dex文件。在我的经验中，这些变体（在我看来）很容易检查是否被篡改。然而，我完全同意你的观点，大多数开发人员不会费心去检查。话虽如此，如果确实有人能够证明篡改，并且足以证明，那么对于谷歌的反弹将会非常严重 - 因此他们不会在未告知开发人员的情况下随意更改任何内容。 - Technologeeks

最好的情况是，这可能适用于将一个APK与另一个进行比较。即使在那里，我也不100%确信它是安全的，因为据我所知，Google可以重命名/重新编号DEX文件（除了classes.dex），或者甚至重新调整DEX中的内容（再次提醒，除了classes.dex），而不会破坏兼容性。然后，在此基础上添加应用程序包和Play交付方案。而且，这仅涵盖开发人员获得修改后的应用程序并可以将其与原始应用程序进行比较的情况。在您的情况下，这可能很简单；但在生态系统范围内，依我之见，它并不简单。但感谢您的澄清！ - CommonsWare

“他们为什么要改名/重新编号？” - 我不知道。我只是试图计划测试一百万个应用程序的规模，而不仅仅是一个。“即使如此，反编译方法也应该可行” - 是的，但与您的shell脚本片段相比，算法会变得更加困难，仅此而已。“除非你意味着他们也会应用混淆？” - 如果他们能够在不破坏东西的情况下可靠地做到这一点，我会感到惊讶。因此，这是我不预期的一个特定变化。 - CommonsWare

显示剩余4条评论

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dellkan · Accepted Answer

谷歌不仅有能力修改上传到其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，并生成子apk。这是一种可以在Google Play中为每个apk启用的东西。当然，今天你在任何文档中都找不到这些内容的提及，除了这个视频 - 这是因为他们后来想出了应用程序包，并将所有这些工作基本上都移到了应用程序包中。因此，这主要与问题有关：“什么阻止Google通过应用签名服务签署的APK文件跟踪我们的APK文件？” 这表明即使对于.apk文件，他们可以；他们打算；他们正在处理。

正如其他人所指出的那样，拥有给定应用程序的签名密钥和Google Play账户访问权限的人可以上传任何包含任何内容的.apk或.aab，只要packageName保持相同并且versionCode递增1。当然，在启用Google Play签名时，Google也适用于此。如果他们想，他们可以更改，删除或添加应用程序的任何部分。

值得记住的是，虽然是的，Google可以修改Google Play签名的.apk文件中的所有内容，但这些修改并不一定是恶意或有恶意意图的。无论是为了优化、兼容性还是热修复，都有很多理由可以或者会修改上传的apk并证明这些修改的合理性。而且他们不一定会警告开发人员；开发人员也不一定会对此进行抗议。

我相信谷歌不会故意对上传的应用程序进行恶意内容更改，主要原因是商业、声誉和伦理风险，在其他答案中已经很好地概述了。我无法想象这对谷歌来说是一个超过成本风险的有价值的攻击向量，尤其考虑到其他更强的可用向量。

最后，我将提到完整性检查作为发现此类操作的一种方式。在这个领域中有几种解决方案，可以进一步验证应用程序的完整性，比签名检查更加严格。无论应用程序开发人员自己开展还是使用现成的解决方案，这些检查通常在设备上的运行时运行，以验证apk的完整性；与编译时间或接近编译时间记录进行比较。在传输期间执行的apk修改也会被此类检查捕获，包括Google Play可能进行的任何更改。

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