首页
社区
课程
招聘
[原创]第一阶段第四题提交
发表于: 2008-10-13 19:26 3651

[原创]第一阶段第四题提交

2008-10-13 19:26
3651
lpBitBase即通过.text:77D1D01C _FindResourcePE@20 (MapViewOfFile) 找到的资源地址
所以 lpBit的地址的对齐方式跟文件中资源的对齐方式有关.
(3)
在函数SmartStretchDIBits中我们发现
text:77D1CA5E                 mov     eax, [ebp+pBITMAPINFO]
.text:77D1CA61                 cmp     [eax+BITMAPINFOHEADER.biCompression], ebx
.text:77D1CA64                 jnz     short loc_77D1CA88
.text:77D1CA66                 mov     ax, [eax+BITMAPINFOHEADER.biBitCount]
.text:77D1CA6A                 cmp     ax, 4
.text:77D1CA6E                 jz      _conver
.text:77D1CA74                 cmp     ax, 8
.text:77D1CA78                 jz      _conver
.text:77D1CA7E                 cmp     ax, 18h
.text:77D1CA82                 jz      _conver
.text:77D1CA88
.text:77D1CA88 loc_77D1CA88:                           ; CODE XREF: SmartStretchDIBits(x,x,x,x,x,x,x,x,x,x,x,x,x)+36j
.text:77D1CA88                                         ; SmartStretchDIBits(x,x,x,x,x,x,x,x,x,x,x,x,x)+43j ...
.text:77D1CA88                 pop     edi
.text:77D1CA89
.text:77D1CA89 loc_77D1CA89:                           ; CODE XREF: SmartStretchDIBits(x,x,x,x,x,x,x,x,x,x,x,x,x)+1Ej
.text:77D1CA89                 push    [ebp+arg_30]    ; DWORD
.text:77D1CA8C                 push    [ebp+arg_2C]    ; UINT
.text:77D1CA8F                 push    [ebp+pBITMAPINFO] ; BITMAPINFO *
.text:77D1CA92                 push    [ebp+lpBits]    ; void *
.text:77D1CA95                 push    [ebp+arg_20]    ; int
.text:77D1CA98                 push    [ebp+arg_1C]    ; int
.text:77D1CA9B                 push    [ebp+arg_18]    ; int
.text:77D1CA9E                 push    [ebp+arg_14]    ; int
.text:77D1CAA1                 push    [ebp+arg_10]    ; int
.text:77D1CAA4                 push    [ebp+arg_C]     ; int
.text:77D1CAA7                 push    [ebp+arg_8]     ; int
.text:77D1CAAA                 push    [ebp+arg_4]     ; int
.text:77D1CAAD                 push    [ebp+arg_0]     ; HDC
.text:77D1CAB0                 call    ds:__imp__StretchDIBits@52 ; StretchDIBits(x,x,x,x,x,x,x,x,x,x,x,x,x)
当 pBitMapInfo->biBitCount位4,8,18的时候, 有一个转换的过程
转换的时候会有内存重新分配, 导致我们精心构造的不对齐内存不被使用
所以我们修改exe的这个字段位1.

==========================
修改方式

找了ollydbg目录下的DLL_Loader.exe做试验
(1)
icon的资源在0dc8, 上一个dialog的大小不是4的倍数,
所以之间有2个字节的空闲, 我们吧icon的资源位置定位在0dc7,
同时吧整个2e8的大小的内容都上移动一字节
(2)
资源开头即是BITMAPINFO的结构体,
修改biBitCount为1, 同时修改biHeight为0x100040 (原先为40)

修改好的exe放到一个目录中, explorer打开成功崩溃.

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!

上传的附件:
收藏
免费 0
支持
分享
最新回复 (3)
雪    币: 101
活跃值: (12)
能力值: ( LV12,RANK:210 )
在线值:
发帖
回帖
粉丝
2
从记事本拷贝出来的时候,没有拖动到最上
这是文章的头, 上个帖子应该接着这里读
-----------------------------------------------

当恶意给lpBitsInfo->bmiHeader.biHeight一个极大值的话,拷贝过程中会出现
读源的内存访问越界, explorer崩溃, 现在就是要想办法让explorer用畸形参数调用这个api

=============================
explorer打开文件夹时, 如果发现是pe或者ne格式, 则会把图标提取出来显示在listview中
调用api 7d5ced4a ShExtractIconsW , 并产生下列的调用栈
.....
77D1D354 _CreateIconFromResourceEx@28      API
-->77D1D3A7                 call    _ConvertDIBIcon@28

77D1C2BC _ConvertDIBIcon@28
-->77D1C33F                 call    _ConvertDIBBitmap@24

77D1B9B2 _ConvertDIBBitmap@24    (a)
-->77D1BA98                 call    _BitmapFromDIB@40

77D1BAC6 _BitmapFromDIB@40
-->77D1CB31                 call    _SmartStretchDIBits@52

77D1CA19 _SmartStretchDIBits@52
-->77D1CAB0                 call    ds:__imp__StretchDIBits@52

(1)
程序用CreateFileW, CreateFileMappingW, MapViewOfFile 的方式,定位到资源项,
显然, 如果图标资源在pe中不是4字节对齐, 那么读出来的内存也不是4字节对齐。
可是正常编译器编译出来的资源, 都是4字节对齐的, 我们手动手该出一个这样的icon资源来
(2)
跟踪发现, _SmartStretchDIBits中的lpBit在(a)中获取
.text:77D1B9C6                 call    _CopyDibHdr@12  ; CopyDibHdr(x,x,x)
.text:77D1BC48                 push    ebx
.text:77D1BC49                 push    esi
.text:77D1BC4A                 call    _HowManyColors@12 ; HowManyColors(x,x,x)
.text:77D1BC4F                 mov     edi, eax
.text:77D1BC51                 mov     ecx, [ebp+lpBitBase]
.text:77D1BC54                 lea     eax, [ecx+edi*4]
.text:77D1BC57                 mov     edx, [ebp+ppBit]
.text:77D1BC5A                 mov     [edx], eax
2008-10-13 19:28
0
雪    币: 101
活跃值: (12)
能力值: ( LV12,RANK:210 )
在线值:
发帖
回帖
粉丝
3
这是文章第一部分
第二贴是第二部分
主题帖是最后一部分

以下地址来自 xp sp3,  程序在sp3下explorer崩溃, sp2没有环境,
理论上是一样的

=====================
WINGDIAPI BOOL WINAPI StretchDIBits(
  HDC hdc,
  int XDest,
  int YDest,
  int nDestWidth,
  int nDestHeight,
  int XSrc,
  int YSrc,
  int nSrcWidth,
  int nSrcHeight,
  CONST VOID* lpBits,
  CONST BITMAPINFO* lpBitsInfo,
  UINT iUsage,
  DWORD dwRop
);
为了调试方便, 先下载出gdi32.dll, user32.dll对应的pdb
可以在windbg目录找到symchk.exe, 配置系统环境变量
_NT_SYMBOL_PATH = SRV*d:\symbols*http://msdl.microsoft.com/download/symbols
命令行运行  symchk.exe d:\user32.dll 来得到对应的pdb
拷贝和dll同一目录, 极大的方便ida分析

StretchDIBits 最后转接到NtGdiStretchDIBitsInternal去实现
但是Nt系列函数要求lpBits必须是4字节对齐的,
而我们的lpBits经常是从程序某个BITMAPHEADER的区域+offset读取
所以很有可能没有对齐, 这样tretchDIBits发现不是4字节对齐
则会分配过一快内存拷贝进入对齐, 于是BUG来了。
.text:77EFB0FF                 mov     eax, large fs:18h
.text:77EFB105                 test    byte ptr [ebp+lpBits], 3
.text:77EFB109                 mov     [eax+6D0h], edi
.text:77EFB10F                 jnz     loc_77F0CA34
.text:77F0CA34 loc_77F0CA34:                           ; CODE XREF: StretchDIBits(x,x,x,x,x,x,x,x,x,x,x,x,x)+71j
.text:77F0CA34                 mov     eax, large fs:18h
.text:77F0CA3A                 push    [ebp+var_2C]
.text:77F0CA3D                 mov     eax, [eax+30h]
.text:77F0CA40                 push    edi
.text:77F0CA41                 push    dword ptr [eax+18h]
.text:77F0CA44                 call    ds:__imp__RtlAllocateHeap@12 ; RtlAllocateHeap(x,x,x)
.text:77F0CA4A                 cmp     eax, edi
.text:77F0CA4C                 mov     [ebp+var_3C], eax
.text:77F0CA4F                 jz      loc_77EFB115
.text:77F0CA55                 mov     ecx, [ebp+var_2C]
.text:77F0CA58                 mov     esi, [ebp+lpBits]
.text:77F0CA5B                 mov     edx, ecx
.text:77F0CA5D                 shr     ecx, 2
.text:77F0CA60                 mov     edi, eax
.text:77F0CA62                 rep movsd
.text:77F0CA64                 mov     ecx, edx
.text:77F0CA66                 and     ecx, 3
.text:77F0CA69                 rep movsb
很明显, 程序认为lpBits的大小由lpBitsInfo的width和height等决定,
但是之前却是通过从资源读取,即lpBits的大小由资源大小和lpBitsInfo共同决定,
当恶意给lpBitsInfo->bmiHeader.biHeight一个极大值的话,拷贝过程中会出现
读源的内存访问越界, explorer崩溃, 现在就是要想办法让explorer用畸形参数调用这个api

=============================
2008-10-13 19:30
0
雪    币: 2134
活跃值: (14)
能力值: (RANK:170 )
在线值:
发帖
回帖
粉丝
4
结果提交时间 55 小时 25 分钟
结果提交时间长度 = 3325 分钟
结果提交次数 = 1
结果提交为可以利用的BUG地点,并构造出PE文件
得分 = [(4320 - 3325)/4320]^1/10 x 1.0 x 100 - (1 -1 ) x 5 = 86.34
2008-11-13 13:47
0
游客
登录 | 注册 方可回帖
返回
//