我开发使用证书钢钉的Android应用程序（类似的方式，例如this）。
不过，我经历了动态测试库，如Frida，或更糟糕的是，Objection来了，可以绕过这一保障。
据我所知，安全必须在服务器端执行，但，我想继续我的API之外的窥视。而且我也明白，Java可执行程序易于拆卸和分析。
我怎样才能使攻击者这一过程更加困难，即使如objection的基本命令
android sslpinning disable
失败和变硬我的应用程序？我看到的是，根据这个过程中也崩溃资产的namings。
有任何想法吗？
几个哈丁框架可以使其更难以弗里达和类似的工具来连接和操作的应用程序。然而，随着时间充裕，动机和/或钱，你甚至可以打破这些框架。
但通常它不是“使用硬化框架或不是”的问题，但“多少钱，你愿意付出得到这个小小的额外的保护？
从我所知，没有自由，甚至廉价的硬化框架（请纠正我，如果我错了，并提供了指向具有良好的保护那些免费/廉价的解决方案），因此它只是你多少保护想一个问题，有多少你愿意付钱。
注：Proguard的和R8均为未硬化的框架！他们才刚刚混淆代码了一点，但特别是当它涉及到证书牵制，并通过弗里达禁用此他们没有提供任何保护！
我怎样才能使攻击者这一过程更加困难
您的问题可能的解决方案是使用移动应用认证的解决方案，在您的移动应用程序没有被MITM攻击的运行时间保证，没有被窜改，未在扎根设备上运行，没有连接到一个调试器和无仪表框架是否存在。这是通过运行在将与在云中运行以证明该移动应用的完整性的服务和设备运行上通信的背景上的SDK实现的。在移动应用的SDK不做出有关应用程序或移动设备的完整性，即在云服务中进行，基于移动应用程序提供的测量的任何决定。
因此，在移动应用程序的完整性的成功证明，通过云服务，时间短住JWT令牌发布，并且利用一个秘密，只有API服务器和云的移动应用认证服务都知道签名。在故障对移动应用程序认证的情况下，JWT令牌与API服务器不知道一个秘密签名。
现在每API发送应用程序必须调用请求的报头中的JWT令牌。这将允许API服务器只服务请求时，它可以在JWT令牌验证签名和到期时间，并拒绝他们时，它无法通过验证。
一旦由移动应用认证服务不是由移动应用已知所使用的秘密，是不可能进行反向工程它在即使当应用程序是否被篡改的运行时，在一个根设备运行或进行通信的，其是所述的连接在中间人攻击的目标。
所以这个解决方案可以在一个积极的检测模型不会产生误报，从而不阻止合法用户，同时保持坏人在海湾。
有任何想法吗？
您可以尝试推出自己的解决方案，也可以找一个现有的移动应用认证SaaS解决方案，像Approov（我在这里工作），即多种平台，包括iOS的SDK提供的Android，阵营原住民和其他人。该集成还需要在API服务器代码来验证云服务发布的JWT令牌的小额支票。这种检查是必要的API服务器能够决定什么请求服务，并拒绝什么的。
最终，该解决方案，以便用它来保护您的API服务器和移动应用，必须按照您要保护的是什么价值，并为该类型数据的法律要求，就像在欧洲GDPR法规来选择。
你似乎是为移动应用程序的安全性，不，我想向您推荐：
OWASP Mobile Security Project - Top 10 risks
OWASP的移动安全项目的目的是为开发人员和安全团队，他们需要建立和维护安全的移动应用程序的资源集中资源。通过该项目，我们的目标是移动的安全风险进行分类，并提供发展的控制，以降低他们被剥削的影响或可能性。