这是一种技术，并非漏洞本身。可以用于大部分的二进制漏洞当中的技术，举个例子，写入shellcode的偏移量可能会因为系统原因而产生一些不同，但是漏洞确实存在，这个时候传统的通过偏移跳转shellcode的方式就不再稳定，或者，如之前我在SEH溢出当中提到的部分，也许数据发送成功了，但是数据位置，距离当前位置很远，传统模式我们就需要先手动去查找计算这个部分。EggHunter这个技术就是解决上述这类问题的。假设有一个程序的代码如下：

这个溢出发生在LogError ，但是由于 B区域缓冲区大小只有64，但是strcpy不管不顾的把 A*10000都写入这个部分，能不能写入不重要，重要的是，这个部分一定会崩溃。此时，首先要确认，这个部分崩溃以后，到底溢出了多少。假设这里溢出过后，发现B区域后续有1000字节的空间，那么就不用egg hunter技术了，直接写shellcode即可。但是更多的情况是，这10000个A只有很少一部分在溢出过后在区域B当中，比如只有100个A写进来了，后续的空间会因为权限或是其他原因根本没办法动，如何在这100个A的空间内想办法精准的跳到Full_Requests_Store当中的shellcode部分，就是egg hunter解决的问题。

内存图大概是这样

简单总结下原理，就是在shellcode之前放一串特定字符串，然后在内存当中搜索这个字符串，找到这个字符串以后，跳转到这里，就能够实现精准跳转shellcode了。Egg Hunter 的精髓在于：它利用系统调用 (Syscall) 或 异常处理机制 (SEH) 来判断一个内存地址是否可读。这个在接下来这个漏洞分析当中会详细说明。

详细原理可以参考这个论文：egghunt-shellcode.pdf

由于 Egghunter 通常用于可用空间受限的场景，所以它的代码设计得尽可能小巧精炼。

此外，扫描速度非常关键 —— Egghunter 越快找到目标标签，应用程序就越不容易出现长时间挂起或崩溃的现象。

因为手动读未映射的内存会直接崩溃程序，而系统调用访问时：

漏洞链接:CVE-2002-1120：Savant Web Server 3.1 及更早版本中的缓冲区溢出允许远程攻击者

Savant Web Server 3.1 及更早版本中的缓冲区溢出允许远程攻击者通过较长的 HTTP GET 请求执行任意代码。这个漏洞的溢出，不是单纯的溢出，Savant Web Server 3.1 的这个漏洞只有在进行 URL 解码（%xx 解码）时才会触发栈溢出。当 HTTP 请求的路径中出现 % 字符时，服务器会尝试对后面的两个十六进制数字进行解码，并把解码后的字节写入一个固定大小的栈缓冲区，这个过程没有边界检查，才导致了溢出。非常符合我们对于当前技术的研究背景。

OK，来写一个初始的Poc

程序加载windbg，可以很清楚的看到此时eip被A覆盖，但是查看栈顶(esp)会发现，溢出的位置并不像是常规的溢出

继续分析这个情况，查看esp，首先eip目前被A覆盖，然后发现esp + 4的位置实际上就是指向 Payload的指针（地址），可以清楚的看到这个地址当中存放了完整的发送的数据。


这个输出就是在概念部分举的例子，回顾伪代码

接下来，我们需要找到eip的位置

加载到windbg当中会发现，坏字符引发崩溃

二分法解决这个问题

加载windbg，可以看到在B的部分

然后循环往复找到这个位置，在253这里

加载windbg验证

这里我想到的处理逻辑比较简单，既然esp + 4存放的地址指向的是我整个发送的payload那么我先测试坏字符，测试完坏字符以后，再利用有序字符串查找位置。

然后修改exp

逐行测试坏字符，建议先注释一半，然后循环查找。程序应该会在第一行就“滑过去”，因为是Web服务，所以\x0a大多数情况下都会是坏字符，再排除一个\x0d这两个都是换行，\x0d是回车，基本上大部分的web服务对这两个字符都会敏感的。稍微提一下，在一些特定环境当中\x0a甚至可以当作sql注入的注释符平替。然后还有之前就遇到过的\x25百分号，这个符号在web服务当中也极其危险，所以手动先把这些排除掉。

修改坏字符测试

然后加载windbg，可以观察到，所有字符显示正常，说明除了手动排除的那几个字符，其他字符都安全

再次验证eip位置，生成一个字符串。

基于对漏洞原理的理解，所以我们需要在生成的字符串前面加一个\x25来让漏洞触发

加载到windbg，然后查询35694134

查看位置，254 减去 手动添加的一个 \x25还是253 重复验证了eip的位置

加载narly可以看到，这个程序几乎没有自带的dll，所以一切就只能从这个程序本身想办法解决。

程序本身的地址范围当中包含\x00 ，常规情况下，应该寻找安全地址的dll来利用，但是分析这个程序的崩溃，可以发现一个很巧妙的事情，eip之后的部分，默认就是\x00。可以通过只写入3个字节的地址，然后让程序本身自动补齐\x00的方式解决这个问题。

加载到windbg查看，eip和预期一样变成了00424242，那也就是说可以构造eip让他指向程序本身当中的某个可用的地址。

到此为止，剩下要解决的就是如何跳转到esp + 4的位置，这个位置存放着一个地址，这个地址里面放着发送过去的完整payload，那么首先最好的选择肯定是jmp这样的跳转指令需要一个jmp [esp + 4]。可惜这样的指令本身就特别罕见，尤其是目前的程序并不大，只是一个小程序就更不太可能有这样的指令了。所以，还是需要PR系列的指令，选择一个其余三位不包含坏字符的地址比如0x00418674这个就可以。

修改代码

加载windbg验证，eip成功指向esp + 4的位置，成功跳转

分析windbg的输出，\x47对应字符G也就是请求方法的部分（GET），尝试修改这个部分，可以观察到这中间有24字节的可写部分。必须要保持这个结构，GET / 或者 xxxx /简而言之就是，/这个字符必须存在。

修改代码

加载windbg，可以看到，这个部分，是可以写一部分指令进去的。

接下来需要让执行流顺利的走到inputBuffer处，修改一下代码

查看windbg，重点在于，完全没有在预期当中看到写入的跳转指令，跳转指令被替换成了\x3f 也就是aas指令。在较老的系统版本当中EB会被换成retf，这是字符编码的问题，是一个关于坏字符的问题。

Savant这个程序的内部处理逻辑是分裂的：

结论：\xeb 在“URL路径”里是好人，但在“HTTP Method”里就是坏人。这就是所谓的上下文相关坏字符。

这就是为什么不同版本的 Windows 表现不同是默认的语言包/代码页设置不同，最终会导致这里的jmp被转换成不同的东西。

既然知道了无法跳转的原因，处理这个问题也很简单，用条件跳转即可，jz/je之类的跳转。空间上有24字节左右的大小，足够写一个条件跳转。

把上述这个条件跳转放进HTTP请求方法的部分当中去

加载windbg，一切符合预期，成功跳转到预想的部分。

开始之前，首先需要知道shellcode在什么位置，因为很显然，剩下的这些空间肯定不够写入shellcode，即使算上请求方法，这个空间也太小了，368字节，并且还有一些限制（比如请求方法必须有一个/字符）。

所以，首先要做的是尝试发送一个shellcode，然后在内存当中找到这个部分。

加载windbg，搜索设定好的特定字符，可以明确观察到，shellcode确实是写入了内存里面的

使用!address指令查看这个地址属性，发现这个地址在堆上，这个大小，写shellcode也绝对够用了

在 Windows 操作系统中，当进程启动时，堆管理器会自动创建一个新的堆，称为默认进程堆。从高层次上讲，堆是大块内存，被分割成更小的块以满足动态内存分配请求。由于我们的二级缓冲区( secondary buffer)存储在动态内存中，因此无法预先确定其位置。这排除了通过向当前指令指针添加静态偏移量来到达辅助缓冲区的可能性。我们需要探索其他方法来查找缓冲区的位置。

简单来说就是这个地址不固定无法固定使用，每次执行都不太一样，所以不能通过偏移量，或是地址，直接jmp或是PR这种手段，简单跳转过去。

终于到这个部分了，这是全篇文章的重点，简单来说，就是在内存当中写一个特征查找的功能，之后让其去自动遍历内存页，查找预设好的特定字符，然后跳转。

Syscall Hunter依赖Windows当中自带的API：NtAccessCheckAndAuditAlarm，这个API的功能是 Windows 内核中用于安全审计的函数。它的本职工作是检查某个用户是否有权限访问某个对象，并生成审计日志（Alarm）。它的工作过程:

简单来说就是在读取的时候如果报没权限，就返回，如果有权限， 就查找蛋壳直到找到，就跳转到蛋壳的位置。下面是一个经典的Egg hunter代码，这种Hunter就是 Syscall Hunter，注意这种查找方式有一个致命的缺陷，微软为了系统安全和架构调整，会经常修改系统调用号。这个代码当中的调用号是写死的，这是Windows XP时代的调用号，当前运行系统是Win 10所以下面的代码一定会走到一个莫名其妙的地方，然后崩溃的。

执行这个代码，然后把结果加入exp代码当中，需要多次调整位置，在之前的跳转当中是直接跳转了0x1E，所以在这里需要多加一些nop

然后加载windbg查看，由于这段日志非常长，我直接复制到下面，然后再分段截图解释。

首先在PR指令处打断点，断点顺利命中，符合预期

接着单步执行，走到条件跳转，这里的跳转地址和地址内容，都符合代码预期

接着就是重点部分，Syscall Hunter的代码部分，不需要关注前面的nop和后面的填充，直接在int 2Eh这个指令处打断点，这里是在系统调用。

断点命中后，会循环往复的命中，这里看起来也属于是正常行为，因为逻辑上这段代码应该正在遍历查找。

为了方便，在调试的时候，直接在shellcode部分打断点，因为按照预设逻辑，应该是会找到shellcode，然后跳转，那么断点一定会触发

但是，这个时候就会发现，这个断点完全不会命中，这就是Syscall Hunter的坏处，XP的系统调用号在Win 10上并不适用，所以需要手动查一下当前系统的调用号。
当前我的系统调用号0x1C6

修改Hunter代码

但是执行过后，会看到一个非常明显的问题，存在坏字符\x00

那么还需要处理这个\x00，面对这种\x00的问题其实有一个算是统一的解决方案就是，用减法 neg指令

然后最终修改Hunter代码

这样执行过后就不会存在坏字符的问题了

之后再次更新exp并且执行，观察windbg的输出，这里有两个非常简单的验证方式，可以在shellcode的部分打断点，或是在jmp之前打断点。可以观察到，顺利跳转到预想的shellcode处，由于上个部分已经分析过了这个内存，这里就不再赘述了，这里是成功跳转的样子，很好分辨，不做二次解释。


接下来的部分就很简单了，把shellcode替换一下。反弹shell。顺便一提，这个漏洞当中的shellcode部分，对坏字符不敏感，也就是说，生成shellcode时，不用考虑坏字符。

Syscall Hunter 完整exp

在上述的Syscall Hunter当中，已经看出非常直观的问题，那就是exp的通用性。假设这样一个场景，对方存在这个漏洞，但是，不确定是Windows哪个版本，那就只能一个一个去尝试调用号，这样效率低，并且很容易被察觉。黑盒角度来说，这个exp就非常不稳定，需要一个更加通用的方案。

首先，知道问题出在NtAccessCheckAndAuditAlarm这个API的调用号上，直接抛弃调用API来解决这个问题的想法。利用Windows的SEH机制来处理这个问题。这个想法分为以下几步

整体 Handler 代码非常短，它的作用只有一个：修改寄存器上下文（Context）。

它告诉操作系统：不好意思，刚才那个地址确实读不了。请把指令指针（EIP）往后挪一挪，跳过这一页，然后让主程序恢复执行。

不得不说，我在第一次看到这个思路的时候，惊艳我一脸，这个想法太天才了。不需要知道系统调用号。SEH 机制从 Win95 到 Win11 是一样的。了解这个部分原理，开始SEH Egg Hunter代码

然后修改exp

获取shell

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！