4

是否有人强化他们的代码以试图检测注入？例如，如果有人试图通过 NSUrlConnection 拦截用户名/密码，他们可以使用LD_PRELOAD/DYLD_LIBRARY_PATH，为我的调用提供导出到 NSUrlConnection，然后将调用转发到真正的 NSUrlConnection。

阿里在下面提供了很好的信息，但我试图确定在恶劣的环境中应该采取什么措施，手机可能会被越狱。大多数应用程序不必关心，但一类应用程序需要 - 高完整性软件。

如果您正在硬化，您使用什么方法？是否有一种标准方法可以检测 Mac 和 iPhone 上的注入？你是如何打败框架注入的？

4

2 回答 2

1

对于 iOS / CocoaTouch，不允许加载动态库*（系统框架除外）。要通过 AppStore 构建和分发应用程序，您只能链接静态库和系统框架，不能链接动态库。

因此，在 iOS 上，您不能将其用于代码注入，LD_PRELOAD当然也不能使用（因为您无法在 iOS 上访问此类环境变量）。

除了越狱的 iPhone 可能之外，但是越狱他们的 iPhone 的人应该自己承担越狱的定义是解除 iOS 提供的所有证券以避免诸如注入之类的事情（所以你不能指望移除门上的锁以避免不得不使用你的钥匙......并且仍然希望你仍然可以防止小偷抢劫你的房子;-))

这就是 iOS 上 Sandboxing + CodeSigning + No dylib 约束的优势。无法进行代码注入。

（在 OSX 上它仍然是可能的，特别是使用 LD_PRELOAD）

[编辑] 从 iOS8 开始，iOS 还允许动态框架。但由于这仍然是沙盒（您只能加载应用程序包内的代码签名框架，而不能加载来自应用程序包外的框架）注入仍然是不可能的*

*除非用户越狱了手机，但这意味着他/她选择摆脱所有保护和目的，从而将手机置于危险之中——我们无法破解手机安全，但仍然期望它提供所有保护提供的证券

于 2012-09-05T19:27:29.397 回答
0

这是一个特定于类 UNIX 操作系统的答案，如果它对您的问题没有意义，但我不太了解您的平台，我深表歉意。只需不要创建动态链接的可执行文件。

我可以想到两种方法来做到这一点。方法#2 可能最适合您。他们都很相似。

对两者都很重要，可执行文件必须-static在构建时使用静态编译

  1. 方法 1 - 静态 exe，通过其受信任的完整路径手动加载共享库

通过完整路径手动dlopen获取所需的每个库，然后dlsym在运行时通过获取函数地址并将它们分配给函数指针以使用它们。您需要为要使用的每个外部函数执行此操作。我相信可重入不安全函数不会喜欢这样，所以对于那些使用静态变量的函数 - 你需要使用可重入安全版本，这些以“_r”结尾，即使用strtok_r而不是strtok

这将是困难或简单，具体取决于您的应用程序做什么以及您正在使用多少功能。

  1. 方法 2 - 静态链接可执行文件，句号

您可以通过仅链接静态可执行文件来完全避免使用动态库来解决您的颠覆问题。dlopen()/dlsym()这将生成比该方法大得多的 exe 。使用-static编译标志而不是使用来构建，例如gcc bah.c -o bah lssl使用gcc -static bah.c -o bah /usr/lib/libssl.a您需要的库的静态编译版本而不是动态共享库。换句话说，在构建时使用-static和不使用-l

对于任何一种方法：

  1. 构建后，用于file bah确认可执行文件是静态链接的。ldd或通过运行确认
  2. 请注意，您需要系统中存在的所有要链接的库的静态编译版本。这些文件以.a而不是.so)结尾
  3. 另请注意，升级系统库不会更新您的可执行文件。如果 OpenSSL 中有新的安全漏洞，您需要获取最新的 libssl.a 并重新编译它。如果您使用该dlopen()/dlsym()方法，则不会出现此问题，但如果符号在不同版本中发生更改，则会出现可移植性问题

根据您的需求，每种方法都有其优点和缺点。

采用方法 1dlopen和dlsym方法会使您的代码更加“模糊”且更小，但在大多数情况下会牺牲可移植性，因此可能不是您想要的。好处是，当安全漏洞在系统范围内得到修复时，它可能会受益。

于 2017-04-09T15:33:41.300 回答