超级任天堂游戏模拟器被曝安全漏洞

超级任天堂(SNES，Super Nintendo Entertainment System)是任天堂全球知名主机NES(国内称为小霸王)的后续主机，主机采用16位色表现，令主机的画面表现在当时非常之棒。而作为当时的主机霸主，任天堂SNES主机上出现了非常多经典的游戏，现在大红大紫的游戏系列很多都是在SNES上发迹的。像勇者斗恶龙系列、传说系列、最终幻想系列、超时空之轮系列等等。当年的超级任天堂凭借全球数千万台的销量一直占据着游戏机市场的鳌头，在这个优秀的平台上，诞生过无数优秀的精品游戏，很多作品即使拿到现在与PS2，XBOX的游戏相比在游戏性方面也毫不逊色(其实是比他们还要好很多)。如果你对那些令人激动的游戏念念不忘的话，而Snes9x可以在你的电脑上网模拟超级任天堂，让你再次回到童年。软件可根据不同硬件方便的调节声音，图象等。

上图中的那个程序是一个 SNES 模拟器，很有游戏爱好者都使用过它。从网上找到这些东西并不难，但我不会在文章里说，因为从技术上讲，这么做属于传播盗版。

首先，我拿出旧的外部硬盘，找到了我的SNES9x模拟器的压缩副本，启动它，就发现了一个 DLL 劫持漏洞。

Snes9x是款让你重温童年游戏的SNES模拟器，能够在Windows平台上运行经典SNES/SFC游戏的模拟器软件，支持.smc, .sfc, .fig, 和 .1等格式的游戏，可用键盘，也能用手柄进行操作，支持键位修改。

以 x86 和 x64 架构编写的程序利用动态链接库 (DLL) 在软件开发过程中提供灵活性和可移植性。 DLL 基本上是包含可重用代码、资源和变量的小程序。就其性质而言，它们没有入口点并且需要父级可执行文件在运行时调用它们。如果你只有一个 DLL，则可以使用 Rundll32.exe 之类的东西来运行该特定 DLL 的内容，而无需父级程序。否则，DLL 中的函数可以由父级可执行文件调用，使用 LoadLibrary API 调用将它们动态导入到程序中。

有时软件开发并不完全按计划进行，并且你可能会经常编写一个程序来调用加载一个不存在的 DLL。或者，在 SNES 模拟器的情况下，你可能会遇到相当于路径漏洞的问题，这基本上意味着程序尝试从当前工作目录加载 DLL，然后在别处查找。

以下就是我加载Procmon并运行SNES模拟器时的情况：

在上图中，SNES 模拟器已放置在我的 FlareVM 主机的桌面上。当程序尝试加载opengl32.dll时，它首先检查当前工作目录C:\Users\Husky\Desktop\SNES32bit\。当它在这里找不到指定的 DLL 时，它会转到SysWOW64目录，并加载成功存在其中的DLL。这个SNES模拟器是一个32位应用程序，因此它检查SysWOW64是否需要dll是有意义的。

注意，System32和SysWOW64有点像冰岛/格陵兰的情况。在标准的x64设备上，64位系统目录是System32, 32位系统目录是SysWOW64。

总之，这是一个漏洞。程序试图从一个可以写入的目录中装入DLL。这是因为该程序已被复制到桌面，而不是安装在标准程序目录中，例如“程序文件”。

这就很容易发生这个软件被共享即从硬盘驱动器共享它，然后将文件复制到他们自己的笔记本电脑上。

另外，在这里需要注意的是，SNES模拟器有DEP但没有ASLR，将来可能会回到那个状态。

现在在一些攻击场景中，DLL劫持是通过以下方式实现的：只需要做一个MSFVenom DLL有效载荷，并将其替换为程序试图加载4head的载荷即可。直到程序崩溃或无法加载：

DOS不在这个范围内，要做得更好，可以进入DLL代理。

DLL 代理

DLL 代理实现 DLL 劫持的成功率更高。

你可能能够从 DLL 劫持中获得 shellcode 执行，但程序仍然需要解析它想要从原始 DLL 进行的函数调用。而且你的 MSFVenom 生成的 DLL 不知道如何处理这些请求的函数，所以calc.exe运行，程序崩溃。

在 DLL 代理中，你可以创建一个新的 DLL，其中包含指向原始 DLL 的导入函数的指针。有效载荷隐藏到这个DLL的一个部分中，并使用剩余的空间将可执行文件指向它想要加载的原始DLL。

该程序以其原始预期功能执行，得到有效载荷执行。

使用 Procmon，过滤以下内容：

打开一个可执行文件或 10 并确定一个尝试加载到 DLL 中但没有成功的程序。在本文的示例中，我专注于 OpenGL32.dll：

重新配置过滤器，以查看该DLL是否在程序执行的任何时刻被成功加载。因此，只需过滤即可扩大你的搜索条件：

如果你已经找到一个好的DLL代理候选，你可能会看到如下内容：

可以看到，将成功加载的 DLL 从主机复制到攻击者的设备上，并将其命名为 [dllName]_original.dll。幸运的是，这个DLL可能在所有Windows系统上都是本地的，因此你甚至可能不需要从目标主机复制它，只需从你自己的 Windows 主机复制它即可。

在攻击者的设备上，使用这个简单的Python脚本从原始DLL中取出导出的函数并将它们写入一个模块定义文件 (.def)：

请注意引用原始DLL的两个位置，并确保相应地更改这些值。

在编译程序时，模块定义文件向编译器提供有关链接导出的信息。在本文示例中，我们将告诉编译器创建代理DLL，并将它链接到原始DLL，以指向它导出的所有函数。

所以，每当可执行文件问“嘿，DLL，函数在哪里?”代理DLL便回复到:“哦，是的，去检查[dllName]_original.dll，它应该在那里。”

现在，我们制作我们的代理 DLL。这是一个用 C 编写的非常简单的程序，它导出一个 DLLMain 函数作为 DLL 的入口点。在 DLLMain 方法中，我们偷偷调用了 Payload 函数。该函数执行，然后所有其他请求的函数调用都传递给 [dllName]_original.dll：

创建此 C 文件并将其命名为 [dllName].c：

到目前为止，一切顺利。

最后，我们需要创建这个代理 DLL 并将它与我们的模块定义文件链接起来。这可以通过 mingw-w64 来完成，它拥有编译DLL所需的必要工具链。注意这里的架构：我代理了32位SNES模拟器，所以我需要为32位架构编译它。

如果你的攻击设备上没有 mingw-w64，只需输入：

然后，编译我们的 DLL：

当 DLL 编译时，你现在应该有四个文件可以使用：

• [dllName]_original.dll：我们从主机上拉下来的原始DLL，重命名为“_original”
• [dllName].c：包含我们的有效载荷的代理 DLL 的 C 代码。
• [dllName].def：使用Python脚本从原始dll中提取导出的函数调用创建的模块定义文件。
• [dllName].dll：新编译的代理DLL。

最后一步是将原始DLL和代理DLL在目标主机的程序目录下登陆，这两个 DLL 必须与彼此和原始程序位于同一目录中。

找到两个 DLL 后，启动程序!

此时，已经有了一个加载到代理DLL中的功能完整的程序。没有崩溃，没有段错误，只有calc。

本文翻