iPhone 已释放密码的内存管理（Malloc Scribble 在生产中？，用零填充已释放内存？）答案

【问题标题】：iPhone Memory management for a deallocated password (Malloc Scribble in production?, fill with zeroes deallocated memory?)iPhone 已释放密码的内存管理（Malloc Scribble 在生产中？，用零填充已释放内存？）
【发布时间】：2015-08-12 21:13:47
【问题描述】：

我正在对 iPhone 如何管理堆和堆栈进行一些研究，但很难找到关于这方面的良好信息来源。我正在尝试追踪密码是如何保存在内存中的，即使在 NSString 被释放后也是如此。

据我所知，一旦 ARC 中的释放计数降至 0，iPhone 将不会清除内存内容（写入零或垃圾）。因此，带有密码的字符串将一直存在于内存中，直到该内存位置为被覆盖。

Xcode 中有一个调试选项Malloc Scribble，通过启用/禁用此选项（和禁用 Zombies）以及在模拟器的内存转储之后（使用gcore) 我可以检查内存中的内容是否已替换为 0x55。

我想知道这是否可以通过 Apple Store 构建完成，用垃圾数据填充已释放的内存，我假设 iPhone 默认不会这样做是否正确，或者是否有任何其他更好的选择处理内存中的敏感数据，以及使用后应该如何清除（可能是可变数据？写入那个内存位置？）

【问题讨论】：

标签： ios objective-c iphone c security

【解决方案1】：

我认为在构建设置级别上没有什么可以做的。但是，您可以通过将内存归零来应用某种内存清理（使用 memset 和指向您的字符串的指针）。

【讨论】：

谢谢，你指出了正确的方向，我找到了一些有用的信息
@pablobart 问题是可能存在 NSString 数据的中间实例。真正确定的唯一方法是使用字节数组并在使用后清除或子类NSString。如果您将NSString 子类化，您必须做的一件事就是管理内存，这正是您想要做的。如果您使用 GUI 元素输入密码，则可能会留下另一个副本。没有真正好的方法来处理安全字符串，我们中的许多人都创建了错误报告，要求安全的 NSString 实现，请也这样做。

【解决方案2】：

正如@Artal 所说，memset 可用于写入内存位置。我发现这个框架"iMAS Secure Memory" 可以用来处理这个问题：

“iMAS Secure Memory”框架提供了一套工具，用于保护、清除和验证内存区域和个人变量。它允许对象的数据部分被覆盖在内存中使用加密版本或空字节

他们有一个方法，应该有用的清除内存位置：

// Return NO if wipe failed
extern inline BOOL wipe(NSObject* obj) {
    NSLog(@"Object pointer: %p", obj);
    if(handleType(obj, @"", &wipeWrapper) == YES) {
        if (getSize(obj) > 0){
            NSLog(@"WIPE OBJ");
            memset(getStart(obj), 0, getSize(obj));
        }
        else
            NSLog(@"WIPE: Unsupported Object.");
    }
    return YES;
}

【讨论】：

假设你有一个有效的内存指针，它是连续的内存并且全长是已知的。
@zaph 是否存在NSString 内容不会存储在连续内存中的情况？如果您检查方法getSize 和getStart，iMAS 框架正在使用github.com/project-imas/memory-security/blob/master/IMSHandler/…，似乎它们正在获取完整长度并跳过 NSString 对象的标题
可能是也可能不是。我当然不会打赌内部 NSString 不会改变，特别是考虑到 UTF-16 的多个代码单元的问题，Swift 比 Objective-C 处理这个问题要好得多。然后是NSMutableString如何处理添加字符的问题，如果需要增加大小，是否会留下一个旧副本，或者是否会为添加的字符分配不连续的分配？我们似乎知道其他基于数据的基础类使用非连续分配。如果一个人是为了安全而去的，那一定不要猜测。