我的程序允许用户输入密码。密码立即用sha1和常量盐进行哈希处理并存储在内存中。 让我们假设攻击者可以物理访问运行我的应用程序的计算机，并希望检索最后一个用户的密码。
他是否有可能通过逆向工程和一些内存观察魔法在内存中找到哈希值？我的应用程序使用MFC图形界面并在Windows上运行。如果他自己输入密码，他会怎么看？他可以监控哈希过程吗？
如果我的用户的密码真的很糟糕，比如“1234”，那么SHA1哈希的所有安全性都取决于SALT。 salt也必须存储在内存中的某个位置（现在是#defined char *数组）。他能用足够的努力找到它吗？
输入流程：
用户在文本编辑中输入密码。完成后，用户单击“确定”按钮，发出BN_CLICKED消息，调用OnOK函数。该函数从编辑字段中获取文本，调用哈希函数，这是（在代码中）另一个库的一部分，因此我认为它必须放在内存中的其他位置。哈希字符串也存储在其他地方。如果重要，项目结构如下：
答案 0 :(得分：1)
如果您对Win32 / MFC应用程序进行反向工程，那么您应该注意到这些数据存储在.data部分中，而const数据存储在.rdata部分中，除非开发人员明确创建了另一个部分来存储这些数据。我使用OllyDbg进行逆向工程应用虽然IDA是最好的应用程序。现在回答你的问题：
他是否有可能通过逆向工程和一些内存观察魔法在内存中找到哈希值？我的应用程序使用MFC图形界面并在Windows上运行。如果他自己输入密码，他会怎么看？他可以监控散列过程吗？
答：是的，可以通过逆向工程在内存中找到哈希值。您只需要找到该数据的内存地址。任何逆向工程师/黑客都可以在GetDlgItem / GetDlgItemText中设置一个断点，然后捕获输入的密码并监控散列过程。
如果我的用户的密码真的很糟糕，比如“1234”，SHA1哈希的所有安全性都取决于SALT。 salt也必须存储在内存中的某个位置（现在是#defined char *数组）。他能用足够的努力找到它吗？
答：找到SALT也需要很少的努力。可以轻松地浏览这些部分或使用我上面提到的技术来调试并在监视过程的同时找出SALT。
如果您真的担心保护这些数据，那么您应该考虑使用加密。我希望能回答你的问题