场景：
假设您有一个使用服务器上某些API的Android应用程序。
该应用程序没有登录功能（由于用户在服务器上没有任何个人数据，因此不需要此功能）
为了将请求发送到服务器，请在服务器上创建OAuth2功能。您向服务器发出请求，它返回一个Auth Token。
但是，如果用户监视网络请求，则可以很容易地接受此请求。因此，您将创建一个与Auth请求的POST正文一起发送的密钥。
问题从这里开始：
您创建的此密钥必须保留在应用程序中，并且应用程序中的任何代码都可以分解（反编译），并且可以访问该密钥。
密钥不能在服务器上，否则将需要获取密钥，因此可以对其进行监视。
您无法以任何方式对其进行编码，因为解码功能必须在Android方面，因此可以反编译。
问题：
至少有什么方法可以使秘密密钥更难解码吗？
PS：：仅使用R8或Proguard会使代码模糊。如果黑客或攻击者进行了尝试，他们可以轻松地查看应用程序的整个代码，并可以继续了解编码或解码的流程，或者在代码内找到密钥。
答案 0 :(得分：1)
为了将请求发送到服务器，请在服务器上创建OAuth2功能。您向服务器发出请求，它返回一个Auth Token。
在这里，您将自己暴露于应用程序的Trust on First Use(TOFU)，这意味着API服务器必须接受该请求确实来自您相信自己是真正且不受干扰的移动设备的什么应用程序。
但是，如果用户监视网络请求，则可以很容易地接受此请求。因此，您将创建一个与Auth请求的POST正文一起发送的密钥。
这就像使用Man in the Middle(MitM)或mitmproxy之类的工具进行wireshark攻击一样容易，攻击者就如同学习如何执行请求一样是什么，您认为它是真正的移动应用，因此无需在MitM攻击的Auth请求的POST正文中窃取秘密密钥。
TOFU：
首次使用信任（TOFU）或首次使用信任（TUFU）是客户端软件使用的安全模型，需要与未知或尚未信任的端点建立信任关系。
MitM：
面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理。
Wireshark是用于Linux，macOS，* BSD和其他Unix和类Unix操作系统以及Windows的网络流量分析器或“嗅探器”。
您创建的此密钥必须保留在应用程序中，并且应用程序中的任何代码都可以分解（反编译），并且可以访问该密钥。
是的，这确实是一个巨大的问题，即使像我在this repo中所示的那样，即使在本机C代码中隐藏了秘密，您仍然可以使用工具对移动应用的二进制文件进行静态分析，例如MobSF，以提取其中的所有机密或找到处理这些机密的逻辑。
您无法以任何方式对其进行编码，因为解码功能必须在Android方面，因此可以反编译。
一旦您是对的，则只需要使用已经提到的MobSF，或者通过在运行时将检测框架挂接到代码上来进行更高级的设置，这将允许动态提取密钥，和/或修改代码的任何行为。这种工具的一个很好的例子是Frida
移动安全框架（MobSF）是一种自动化的多合一移动应用程序（Android / iOS / Windows）可以进行静态和动态分析的笔测试，恶意软件分析和安全评估框架。
将您自己的脚本注入黑盒进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。
至少有什么方法可以使秘密密钥更难解码吗？
正如我已经提到的，Frida可用于在运行时修改代码的行为，因此攻击者会发现这样做的代码，并钩住代码的返回，以提取已解码的密钥。
比加强秘密更好的是，在移动应用程序代码中根本不包含任何秘密，无论它是静态的还是由移动应用程序本身在运行时动态生成的。为此，您需要研究“移动应用证明”概念。
移动应用证明的作用
这将是一个解决方案，可让您的API服务器知道正在发出的请求确实是您已上传到Google Play商店的真正移动应用程序，而不是自动脚本，邮递员要求或任何其他形式的模仿。它由在云上运行的证明层组成，将挑战移动应用程序，并且基于返回的度量，它将为移动应用程序发布短暂的JWT令牌，以便在每个请求中向下传递给API服务器，以对其进行验证有效的签名和到期时间。我将在文章this section上进行更详细的介绍：
在深入研究移动应用证明服务的作用之前，我们首先需要了解什么和谁在访问API服务器之间的区别。本文将对此进行更详细的讨论，我们可以阅读：
什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流。
移动应用程序证明服务的作用是验证发送请求的什么，从而仅响应来自真正移动应用程序实例的请求，并拒绝来自未授权来源的所有其他请求。
为了知道什么正在将请求发送到API服务器，移动应用程序证明服务将在运行时高度确定您的移动应用程序是否存在已被篡改/重新打包，未在有根设备中运行，尚未被工具框架（Frida，xPosed，Cydia等）钩住，也不是中间人攻击（MitM）的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性。
在成功证明移动应用程序完整性后，将发布并使用一个秘密的短时间JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务才能知道。在证明失败的情况下，将使用错误的机密对JWT令牌进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使在应用程序被篡改，在有根设备中运行或通过连接通信时，也无法在运行时对其进行反向工程这是MitM攻击的目标。
移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名且尚未过期时才服务请求。所有其他请求将被拒绝。换句话说，有效的JWT令牌会告诉API服务器正在发出请求的是上载到Google或Apple商店的正版移动应用，而无效或丢失的JWT令牌则表示 正在发出未经授权的请求，因为它可能是机器人，重新打包的应用程序或发起MitM攻击的攻击者。
使用移动应用程序证明服务的一大好处是其主动和肯定的身份验证模型，该模型不会产生误报，因此不会阻止合法用户，同时又阻止了坏人。
根据问题的内容判断，保护API服务器和移动应用程序免受攻击是一项非常艰巨的工作，并且通过提供更多的上下文和工具，我试图使阅读此答案的人更加明确曾经这样做。
归根结底，这都是关于深度安全性的问题，您应该尽可能使用尽可能多的防御层，这是法律对用例的要求，并且您认为足以保证数据的价值您正在尝试保护。
在我回答的任何安全性问题中，我总是想向您推荐OWASP的出色工作，尤其是以下内容：
The Mobile Security Testing Guide
移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。
答案 1 :(得分：0)
假设您需要在应用程序端保留一个秘密密钥，则可以对应用程序进行加固以防止密钥提升，反向工程和篡改。
如果您已经熟悉Proguard / R8，那么您可能会发现DexGuard非常适合您的用例。
或者，您也可以考虑更改应用程序逻辑，以便不需要在应用程序端存储密钥。
在做出决策时，您需要权衡：