如果您使用调试器动态分析进程，这可能比使用静态分析容易得多。

如果应用程序使用普通的 windows API，您可以尝试使用 spy++ 之类的软件来获取对话框过程的地址，每当对话框中发生有趣的事情时就会调用该地址，或者，您可以在DialogBoxAPI 函数上放置一个断点（有几个其中，DialogBoxA对于 ascii 字符串、DialogBoxW宽字符字符串和一些DialogBoxEx变体）。一旦知道地址，就可以在 IDA 中查找。

如果应用程序使用一些窗口工具包（比如gtk, qt，swing如果它是一个 java 应用程序，不管怎样），这可能会有点困难，因为这些工具包可能只使用 Windows API 的一小部分并自行处理事件。但是，如果您在GetWindowText和/或GetDlgItemText（同样在多个 A/W/Ex 变体中）放置断点以检查应用程序实际读取您输入的内容的时间和位置，它可能仍然会成功。

如果由于某种原因，您绝对不能使用调试器而只能使用 IDA，您仍然可以尝试交叉引用上述函数并从那里开始工作。但是，由于您不知道密码检查代码中使用了哪个交叉引用，这可能会更难/更耗时。

除此之外，我对类似问题的回答中的一些想法可能会对您有所帮助。

最初，您可以简单地搜索打印在对话框中的任何字符串，并且在用户输入之后执行的代码应该很容易找到，前提是没有使用混淆。例如，在 IDA Pro 中：

如果它是一个简单的密码crackme，您应该寻找遍历字符串的每个字符（即用户输入）并将其与某个硬编码值进行比较的代码。或者，正如其他人所阐述的那样，您可以查找 Win32 API 的特定用途并查找交叉引用。

我会运行目标并让它显示对话框，然后我将它附加到调试器。我会闯入调试器，在线程之间切换，直到我看到哪个调用了对话框。如果找到，我会打印调用堆栈。

如果通过地址计算运行时（虚拟函数）调用对话框，静态分析可能会很困难，但您始终可以尝试上述方法。

不确定我应该接受上述哪个答案。我将在此处仅使用 IDA 报告对我有用的方法：

1. 由于主窗口和主菜单在启动程序时已经存在，我寻找了一个断点，该断点将密码挑战对话框作为其下游。在这种情况下，它是一个 FileOpen 子例程。
2. 单击 File -> Open 菜单项并选择受密码保护的文件会导致断点被命中，从而暂停程序的执行。
3. 继续踩下去，直到弹出密码挑战对话框。
4. 通过将最后执行的指令设置为断点来回溯。
5. 重复步骤 2 到 4，直到识别出启动对话框的代码。

检查诸如“check”、“password”和其他预期关键字之类的字符串不起作用，因为它们无处可寻。

幸运的是，在这个过程中，遇到了一个标记为“chk_pass”的子程序，我能够从暂时存储密码的 EDX 寄存器中提取密码。