我目前正在Android应用程序中使用Spotify，但我需要使用Secret才能刷新令牌等。我想将机密从Backend传输到应用程序，因此该机密不存在于APK中，并且在反编译时无法找到。我只读过很多关于保护应用程序中的秘密的文章，通过各种方式，比如代理，只需使用自己的后端，将代码放入应用程序的原生C++代码(NDK)中，或者使用应用程序的哈希来确定应用程序是否在调用后端，而不是计算机后面的某个人试图窃取秘密。
找到的选项：
- 代理：这意味着通过我自己的服务器进行路由，不希望这样
- 自己的后端：与代理相同，不希望所有请求都通过我自己的服务获得
- 本机代码：使用它似乎会减慢反编译器的速度，但并不能阻止它们
- 哈什：据我所知，这篇帖子暗示了一些我认为奇怪的事情。它正在检索SHA-1并将其传递到网络标头中，以验证应用程序是否正在调用。奇怪的是，当您只
unzipAPK文件时，运行printcert(keytool -printcert -file CERT.RSA)命令将显示APK的所有SHA和MD5哈希。据我所知，这并不是万无一失的，因为有人可以获得APK文件的哈希值并将其提交给服务器
有其他方法可以解决这个问题吗？
您的问题
我目前正在我的Android应用程序中使用Spotify，但我需要使用Secret才能刷新代币等。我想把这个秘密从我的后端传输到应用程序，这样这个秘密就不存在于APK中，在反编译时也找不到。我只读过很多关于保护应用程序中的秘密的文章，通过各种方式，比如代理，只需使用自己的后端，将代码放入应用程序的原生C++代码(NDK)中，或者使用应用程序的哈希来确定应用程序是否在调用后端，而不是计算机后面的某个人试图窃取秘密。
祝贺您努力理解这个问题，似乎您在很大程度上理解了移动应用程序中的秘密总是可以通过静态二进制分析提取的，但我没有看到任何提及诸如之类的工具框架
弗里达
将您自己的脚本注入黑盒进程。挂钩任何函数，监视加密API或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都没有编译步骤或程序重新启动。
或
x曝光
Xposed是一个模块框架，可以在不接触任何APK的情况下更改系统和应用程序的行为。这很好，因为这意味着模块可以在不做任何更改的情况下为不同版本甚至ROM工作(只要原始代码没有更改太多)。它也很容易撤消。
但还有很多其他的存在，所有这些都将在运行时挂接到您的代码中，并提取您存储在移动应用程序中的任何秘密，无论您存储得多么安全，即使您使用硬件支持的密钥库，也可以在受信任的执行环境中运行：
安卓硬件支持的Keystore
芯片上系统(SoC)中可信执行环境的可用性为安卓设备提供了一个机会，可以为安卓操作系统、平台服务甚至第三方应用程序提供硬件支持的强大安全服务。
在某个时刻，从该密钥库检索到的密钥将需要用于向第三方服务发出请求，此时，攻击者所需要做的就是挂接对该函数的调用，并在传递给它时提取密钥。
因此，无论你最终做了什么，移动应用程序中的秘密总是可以被提取出来的，这取决于攻击者的技能以及他愿意投入的时间和精力
话虽如此，这让我想到了我一直建议开发者不要这样做的一点，那就是在他们的移动应用程序中调用第三方服务。
从移动应用程序访问第三方服务
找到的选项：
代理：这意味着通过我自己的服务器进行路由，不希望这样自己的后端：与代理相同，不希望所有请求都通过我自己的服务获得
是的，我知道你不想使用代理或后端，但这是你确保访问第三方服务的最佳机会，在这种情况下是Shopify。
我写了这篇文章，解释了为什么你不应该从你的移动应用程序中这样做，我引用了：
通常，所有第三方API都需要API密钥、访问令牌或其他机制形式的机密，以便远程客户端向希望与其通信的后端服务器标识自己。这就是从你的移动应用程序中访问它的问题的症结所在，因为你需要在代码中发送所需的秘密(上图中的彩色键)。
现在你可能会说，你已经混淆了代码中的秘密，将其隐藏在本机C代码中，在运行时动态组装，甚至加密了它。然而，最终，攻击者需要做的就是通过静态二进制分析对二进制进行反向工程，或者在运行时将像Frida这样的工具框架挂接到函数中，该函数将返回机密。或者，攻击者可以通过执行MitM(man-in-the-middle)来检查移动应用程序与其连接的第三方API之间的流量。
有了他们掌握的秘密，攻击者可以对一个组织造成很大的破坏。损害可能是金钱、声誉和/或监管方面的。在财务上，攻击者可以使用提取的机密以您的名义访问您的云提供商和按次付费的第三方API，从而给您带来额外的成本。此外，您可能会因数据泄露而受到经济损失，这些数据可能会被出售给竞争对手或用于实施欺诈。当攻击者使用提取的秘密代表你在社交网络上发帖时，你的声誉可能会受到影响，从而造成公关噩梦。当攻击者使用第三方API并违反其条款&条件(例如频繁使用API会触发速率限制)，从而阻止您使用服务，给最终用户带来痛苦。最后但并非最不重要的是，当提取的机密是保护第三方API访问机密信息的唯一机制时，会导致监管问题。如果攻击者能够检索到个人身份信息(PII)等机密信息，则可能会对您的企业强制执行与欧洲违反GDPR或加利福尼亚州新的CCPA数据隐私法有关的监管罚款。
因此，要记住的信息是，从发布应用程序或将代码推送到公共存储库的那一刻起，你在代码中发布的任何秘密都必须被视为公开的。到目前为止，最好的方法是完全避免从移动应用程序中访问第三方API；相反，您应该始终将此访问委派给您可以信任和控制的后端，例如反向代理。
您现在可能会说，问题刚刚从移动应用程序转移到反向代理或后端服务器，这是一件积极的事情，因为后端或反向代理在您的控制之下，但移动应用程序超出了您的控制范围，因为它在客户端，因此攻击者可以对它为所欲为。
在后端或反向代理中，您不会向公众公开访问第三方服务的秘密，攻击者想要代表您对该第三方服务器进行的任何滥用都需要经过您控制的地方，因此您可以应用法律要求的尽可能多的防御机制。
深度安全
将代码放入本机C++代码(NDK)
当在原生C代码中隐藏秘密时，通过静态二进制分析很难找到它，至少对于脚本孩子和季节性黑客来说，它需要一套大多数人可能没有的更好的技能，因此我真的建议你将其用作额外的安全层，但要保护访问自己服务的秘密，而不是我之前提到的第三方服务。
如果你真的决定听从我的建议，转而保护你可以控制的第三方秘密，比如你自己的后端，那么我建议你阅读我对以下问题的回答如何确保移动应用程序的API REST有关保护API服务器和可能的更好解决方案的章节
如果你阅读了上面的答案，那么你已经意识到，如果你在后端保留对第三方服务的访问，你可以通过使用移动应用验证概念，以非常高的可信度将API服务器锁定到移动应用。
你想多走一步吗
我看到你很了解情况，所以你已经知道我要分享什么了，但在我对安全问题的任何回应中，我总是喜欢引用OWASP基金会的出色工作，因此如果你允许，我会在这里这样做：)
对于移动应用程序
OWASP移动安全项目-十大风险
OWASP移动安全项目是一个集中的资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供开发控制，以减少其影响或被利用的可能性。
OWASP-移动安全测试指南：
《移动安全测试指南》(MSTG)是一本关于移动应用程序安全开发、测试和逆向工程的综合手册。
对于APIS
OWASP API安全前10名
OWASP API安全项目旨在通过强调不安全API中的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API安全项目将创建并维护API十大安全风险文档，以及创建或评估API时最佳实践的文档门户。
所有由人工创建的东西都可以由人工分解-没有完全安全的选项。
不过，你可以尝试的东西很少。
使用端到端加密与服务器建立安全连接，然后从后端将机密发送到应用程序。在SharedPrefs或文件或数据库中存储通过KeyStore保护的机密。
此外，您还可以利用基于Vernam算法的一次性填充密码。它具有绝对的密码强度，因此无法破解。与Diffie-Hellman相结合，它可能会带来很好的安全性提升。
不过，它仍然可以被破解——在应用程序处于活动状态并进行秘密解密时，通过对根设备进行内存扫描，通过中间人攻击等。正如我所说，一切都可以被破解(目前可能除了Vernam算法)。
不过，不要太在意——犯罪分子很难严重滥用你的秘密。一般来说，他们甚至不会那么在意这些东西。
希望这个答案能对你有所帮助。