iOS中的反编译可能性以及如何防止

我最近读到了有关iOS应用程序反编译的文章，现在我真的很关心它。如以下文章（和）所述，可以对分发到应用商店的iOS进行反编译。这可以通过越狱来实现，我认为可以通过将应用程序从内存复制到硬盘来实现。使用一些工具可以

• 读取字符串（字符串工具）
• 转储头文件
• 装配代码的逆向工程

似乎不可能对Cocoa代码进行反向工程

由于安全性是我创建的软件的一项功能，我希望防止坏用户重建我的安全功能（使用密钥加密或登录网站）。因此，我提出了以下问题：

有人能用assembly重建我的保存、加密或登录方法吗？我的意思是他能理解到底发生了什么（在什么时候保存到哪个路径，使用哪个密钥等等，登录到哪个网站需要什么凭据）？我不了解装配，对我来说它看起来像矩阵

如何安全使用不能用字符串读取或在程序集中读取的

NSStrings

？我知道可以对字符串进行模糊处理，但这仍然不安全，不是吗

---

这是人们多年来一直在关注的一个问题，任何有足够动机、有技能的人都能够找到方法，找出任何你不想让他们发现的信息，如果这些信息存储在设备上的话

无需越狱，就可以使用购买或下载的二进制文件反汇编应用程序。这是静态检查，通过标准拆卸工具方便。尽管您需要一个足够好的工具来添加链接器中的符号，并充分理解方法调用，以便能够梳理出发生了什么。如果您想了解它是如何工作的，请查看，它是一个非常好的拆卸/逆向工程工具

特别是对于您的安全登录问题，如果您有一个有动机的攻击者，您会遇到更大的问题：基于系统的中间人攻击。在这种情况下，攻击者可以填充系统使用的网络代码，并查看通过标准网络发送的任何内容。因此，您不能指望能够将任何形式的未加密数据发送到操作系统或库级别的“安全”管道中，并期望它不会被看到。在将数据放入管道之前，您至少需要加密（即，您不能依赖于向标准SSL库发送任何纯文本）。您可以编译自己的一组SSL库，并将它们直接链接到您的应用程序中，这意味着您不会随着时间的推移获得任何系统性能和安全增强，但您可以根据需要手动升级SSL库。您也可以创建自己的加密，但这充满了潜在的问题，因为有动机的黑客可能会发现在这一点上更容易攻击您的有线协议（公开测试的协议，如SSL，通常比你自己能拼凑起来的协议更安全，除非你是一个具有多年安全/加密经验的特别有天赋的开发人员）

然而，所有这些都假设攻击者有足够的动机。如果你移除了这些低挂果实，你可能能够阻止一个偶然的黑客简单地尝试了解你的系统。需要避免的一些事情：

• 存储加密任一侧的纯文本加密密钥
• 将密钥存储在特定命名的资源中（名为

  serverkey.text的文件或名为
  key
  的plist中存储的密钥都是经典的）

• 尽可能避免使用简单的密码

但是，最重要的是创建这样的系统：如果没有用户必须输入的信息（直接或通过OAUTH等系统间接输入），那么存储在应用程序中的密钥（如果有）就毫无用处。服务器不应在未与可信任的用户进行某些交互的情况下，信任客户端执行任何重要操作

苹果的钥匙链提供了一个很好的存储身份验证令牌的地方，比如在OAUTH序列中检索到的令牌。API有点难以使用，但系统是可靠的

---

最后，问题是，无论你做什么，你只是在增加击败你的措施所需的工作量。攻击者可以控制等式的所有重要部分，因此他们最终将击败设备上的任何东西。你需要决定在保护这些措施上投入多少努力客户端，vs保护服务器和监控滥用。由于攻击者持有设备上的所有卡，因此更好的方法是可以在服务器上实现的方法，以增强您的目标。

无需越狱来进行反向工程，而且是的，您可以在代码中编写的任何方法都可以被某些人理解e有足够的时间这样做。使用SDK提供的方法，因为它们的源代码不会直接出现在您的应用程序中，但不要梦想太多。这不是一种100%安全的方法，可以读取的所有内容都可以复制，可以复制的所有内容都可以破解。因此，当我使用SDK类方法时（例如，

[NSString stringWithFormat:…]<或代码>或保存文件，这在汇编程序中是不可见的吗？我的意思是任何应用程序都包括基础框架……当你使用[nScReStuffFieldFrame:…]可见的是对stringWithFormat的调用，不可见的是这个方法背后的内容=>我们知道调用的是什么，而不是它在itok背后是如何完成的。但是我认为一个能够进行反向工程的人也知道SDK方法背后的内容（或者他可以通过文档找到）。几乎不可能进行SDK方法调用，因为只有开发人员知道