从逆向工程Android保护您的API密钥

Question

我对ProGuard有点失望。 我正在使用Gradle来隐藏我的Google MAP API密钥。我也在这里阅读了这个问题Manage Google Maps API Key with Gradle in Android Studio 并做了同样的事情。如果您按照此问题中的接受答案，您的api密钥将不会被ProGuard混淆。问题是为什么？ 有两个很好的答案。一个使用ManifestPlaceHolder，一个使用@string

但是，如果我反编译我的应用程序，仍然可以看到我的天气api键。 我正在使用private String myweatherapikey = BuildConfig.MY_API_WEATHER_KEY;并且令人惊讶（以一种糟糕的方式）ProGuard如何不对此进行模糊处理，即使使用Gradle也是如此。 进行逆向工程时，它看起来像private String myweatherapikey ="MY KEY IN PLAIN TEXT";

我试图模糊我的密钥，因为几天但没有任何效果，即使使用Gradle。 你怎么隐藏你的钥匙？当你反编译我的应用程序时，我的所有密钥都是公开的，这真让我很烦。

第二个问题：我认为隐藏你的谷歌地图api密钥是不可能的。有2个键，一个用于发行版，另一个用于调试版。它们都存储在src / debug和src / release中。你不能隐藏这个，对吗？

Answer 1

混淆

您的api密钥不会被ProGuard混淆

如果Proguard或任何其他工具混淆了API密钥，则还需要在运行时对其进行混淆，否则您将无法使用它。

无论您具有混淆机制还是加密机制，攻击者只需在运行时将诸如Frida之类的检测框架挂接到反混淆或解密后返回API的代码即可。

Frida：

将您自己的脚本注入黑盒进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。

攻击者的另一种方法是在他控制或能够入侵的设备上执行MitM攻击，并拦截移动应用程序和后端之间的所有请求，以便从标头中提取API密钥，然后阅读我的文章Steal that API Key with a Man in the Midlle Attack，以了解如何实现：

因此，在本文中，您将学习如何设置和运行MitM攻击以在您控制的移动设备中拦截https流量，以便您可以窃取API密钥。最后，您将在更高层次上看到如何缓解MitM攻击。

是的，这是公共的

自几天以来，我一直在努力混淆我的密钥，但是即使使用Gradle也无济于事。您如何隐藏钥匙？当您反编译我的应用程序时，我所有的密钥都是公开的，这真让我感到烦恼。

从您将移动应用发布到Google，Apple商店或任何其他商店的那一刻起，就可以下载二进制文件并对其进行反向工程，因此，二进制文件中的任何内容（无论是秘密的还是只是代码。

隐藏API密钥并对它们进行反向工程的技术

我最喜欢的对移动应用程序二进制文件进行反向工程的工具是MobSF：

移动安全框架（MobSF）是一种自动化的多合一移动应用程序（Android / iOS / Windows）可以进行静态和动态分析的笔测，恶意软件分析和安全评估框架。

您可以阅读我的文章How to Extract an API key from a Mobile App with Static Binary Analysis，以了解它是如何完成的，同时还可以学习用于隐藏API密钥的几种技术，并了解如何轻松地绕过它们：

在本文中，我们将使用 Android Hide Secrets 研究存储库，该存储库是一个虚拟的移动应用，其中API密钥使用几种不同的技术隐藏。

是时候寻找一种更先进的技术来隐藏API密钥了，这种方式很难对APK进行反向工程，为此，我们将利用本机C ++代码通过以下方式存储API密钥：利用引擎盖下使用NDK的JNI接口。

GOOGLE MAPS API密钥

第二个问题：我认为无法隐藏您的Google Maps API密钥。有2个键，一个用于发行版，一个用于调试版。它们都存储在src / debug和src / release中。您无法隐藏它，对吧？

如果您已经阅读了我上面发布的所有链接，那么现在您可能已经意识到，将移动应用程序二进制文件中的任何秘密隐藏在不可能的事上。

>

最重要的是，如果是二进制文件，则可以通过静态分析或在运行时将其提取。

我对移动应用中的Google Maps用法并不十分熟悉，因此我不知道是否有可能将其调用转移到后端，因为这是任何使用Third都必须完成的工作移动应用中的Party API，否则该API密钥很容易被提取和滥用，并且如果您基于该API进行计费或费率限制，那么当攻击者获得您的API密钥时，您可能会遇到麻烦。

第三方API

当前您正在使用第三方API，将移动应用置于此位置：

但是，您的移动应用最好位于以下位置：

在图形中，我提到了反向代理，它可能是您的移动应用程序的后端。

注意：这些图形属于我目前正在写的一篇文章，内容涉及使用反向代理访问第三方API。

将API的访问权限委派给我们控制的反向代理或后端时，保护API密钥的访问要容易得多，此方法的直接好处是可以使用Thrid Party服务的API密钥不再是公共领域，也就是您的移动应用程序的二进制文件。

因此，从图形中，我们只剩下一个要保护的API密钥，一个要访问反向代理或后端的API密钥，您可以在其中使用尽可能多的安全措施来防止未经授权的访问。

可能的解决方案

如何隐藏键？

最好不要在移动应用中完全隐藏任何键，因为这将是理想的解决方案。所以上面的图形看起来更像：

要处于不需要在移动应用程序中发布任何秘密的位置，您需要诉诸“移动应用程序证明”概念，然后从this article section中提取相关内容，以说明问题所在。角色：

在深入研究移动应用证明服务的作用之前，我们首先需要了解什么和谁在访问API服务器之间的区别。 this article中对此进行了更详细的讨论，我们可以阅读：

什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？

谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流。

移动应用程序证明服务的作用是验证发送请求的什么，从而仅响应来自真正移动应用程序实例的请求，并拒绝来自未授权来源的所有其他请求。

为了知道什么正在将请求发送到API服务器，移动应用程序证明服务将在运行时高度确定您的移动应用程序是否存在已被篡改/重新打包，未在有根设备中运行，尚未被工具框架（Frida，xPosed，Cydia等）钩住，并且不是Man in the Middle Attack (MitM)的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性。

在成功证明移动应用程序完整性之后，发布并签名了一段短暂的生存期JWT token，并带有一个秘密，只有云中的API服务器和移动应用程序证明服务才能知道。在证明失败的情况下，将使用错误的机密对JWT令牌进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使在应用程序被篡改，在有根设备中运行或通过连接通信时，也无法在运行时对其进行反向工程这是MitM攻击的目标。

移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名且尚未过期时才服务请求。所有其他请求将被拒绝。换句话说，有效的JWT令牌会告诉API服务器正在发出请求的是上载到Google或Apple商店的正版移动应用，而无效或丢失的JWT令牌则表示 正在发出未经授权的请求，因为它可能是机器人，重新打包的应用程序或发起MitM攻击的攻击者。

使用移动应用程序证明服务的一大好处是其主动和肯定的身份验证模型，该模型不会产生误报，因此不会阻止合法用户，同时又阻止了坏人。

移动应用程序证明将您的移动应用程序释放为在其代码中包含嵌入式机密，而现在，它仅需要传递给反向代理或后端处理从该证明中收到的JWT令牌。现在，反向代理或后端可以验证JWT令牌，并且在成功验证后，他们可以非常有信心地完成请求，这些请求是来自他们期望的 what （移动应用程序的真实实例）的，无需公开 API密钥即可访问您的第三方服务的额外好处。

走得更远

我不禁推荐在OWASP - Mobile Security Testing Guide中所做的出色工作：

移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。