C++ char数组清空后仍可被Process Hacker转储出明文如何解决

你现在遇到的问题核心是从根上的实现逻辑就错了，叠多少种清零函数都没用，具体错误点如下：

• 你根本没清到真正的原始字符串副本
  你代码里用双引号包裹的"This is a string literal. See the double quotes?"是字符串字面量，这个值在程序编译的时候就会被直接写到二进制文件的只读数据段（.rdata节），程序运行后会被加载到进程内存的只读页里。你定义的char str[49]是栈上的数组，初始化的时候只是把只读段里的字面量拷贝了一份到栈上，你后面调用的所有清零函数全是在擦除栈上的这份拷贝，完全碰不到只读段里的原始字面量，这个原始值会一直存在到进程退出，内存转储的时候当然能扫到。
• 部分清零操作存在被编译器优化掉的可能
  普通的memset和你自己写的cleanse如果没有做防优化处理，只要编译器判定后续代码不会再访问str数组，就会把这些清零操作当成无意义的死代码直接删掉。虽然你用了SecureZeroMemory和OPENSSL_cleanse这两个自带防优化属性的清零函数，但它们也只能处理你传进去的栈上str缓冲区，处理不到前面说的只读段副本。
• 你没考虑其他位置的残留副本
  哪怕你真的把栈上数组和只读段的副本都清掉了，只要敏感值曾经被传入过其他函数——比如你注释掉的cout输出、strlen调用——这些函数会在自己的栈帧、内部缓冲区、甚至寄存器里留下敏感值的临时拷贝，这些位置你根本没法全部追踪到，更别说逐个擦除。比如你如果调用过cout输出字符串，iostream的内部缓冲区就会留一份明文，没清掉的话一样能被转储出来。
• 你用的编译参数对解决这个问题毫无作用
  你加的-s是剔除二进制符号、-fdata-sections -ffunction-sections -Wl,--gc-sections是链接时删除未使用的代码段/数据段、-fstack-protector是防栈溢出攻击，这些参数没有一个是用来阻止敏感数据留副本、或者保证内存清零逻辑不被优化的，完全解决不了你当前的问题。

• 绝对不要用字符串字面量存放密码这类敏感数据：敏感值必须从安全输入接口（比如关闭回显的安全输入API，避免输入过程留日志/缓存）直接读入到你提前申请的专用缓冲区里，从根源上避免敏感明文被硬编码到二进制的只读段。
• 敏感内存要做专属保护：Windows平台下可以用VirtualLock把存敏感值的缓冲区锁在物理内存中，避免被系统换到页面文件留下磁盘残留；用完之后必须用自带防优化属性的清零函数（比如SecureZeroMemory、OPENSSL_cleanse）彻底擦除，再释放内存。
• 严格收敛敏感数据的传递路径：尽量减少敏感值的拷贝次数，不要把敏感值传给会做内部缓存的不可控函数（比如默认的iostream输出、未做安全改造的字符串操作函数），每一段处理敏感值的逻辑执行完立刻清理对应缓冲区，减少残留可能。
• 外层可以加进程防护：通过系统权限配置阻止其他进程获取你的进程的高权限句柄，降低被恶意转储内存的概率，但这属于外围防护，不能替代内存擦除的核心逻辑。

内容的提问来源于stack exchange，提问作者Kaspek