好友 阅读权限 10
听众 最后登录 1970-1-1
本帖最后由 LseKit 于 2018-2-19 20:37 编辑 一.概述 转眼间就在科锐步入了第三阶段,近日课堂上钱老师从一个简单的Hello World 引发出一系列BUG,并带着我们修复BUG.这些问题设计到了开发,脱壳 ,调试技巧等一系列知识点,在解决这些问题的过程中我不仅学到了脱壳,调试的技巧,更是被逆向的艺术给折服.现在我就来将这个题目和我个人解决问题的过程分享给吾爱破解 的各位朋友.此文虽力求完美,却因小弟才疏学浅难免有不足之处,希望各位朋友点评,让小弟进步. 1.使用VC6编译出的obj文件与汇编联合编译.因为VC6使用的kernel32.LIB和masm32使用的kernel32.LIB中对GetEnvironmentStrings这个函数的声明不一致遇到第一个错误. 二.环境 Microsoft Visual 6.0 RadASM Windows 7 三.C工程 3.1 新建VS工程,编写函数 使用VC新建控制台工程TestHello,编写函数ShowHello()输出Hello World. [C] 纯文本查看 复制代码
1
2
3
4
5
6
7
8
9
#include <stdio.h>
extern "C" void fnShowHello();
void fnShowHello()
{
printf("Hello World.\r\n");
}
3.2 查看.obj文件 在工程目录下Debug文件夹中查看Test.obj文件,并将滚动条拖动到尾部,查看ShowHello()函数是否生成. 可以看到我们的函数已经存在.其实从名称中可以看出调用约定, cdecl 一般都喜欢在函数名前加下划线,而 stdcall 则喜欢在函数名后加@与参数字节总和,例如我在函数中加个Messagebox,编译后再查看Test.obj. 四.汇编工程 4.1 新建汇编控制台工程 使用RadASM新建汇编控制台工程TestBug后,将C语言TestHello工程中的Test.obj复制到TestBug目录下,并拖到工程中. 4.2 Link错误 尝Link接时报了几个错误,不要灰心,钱老师常教导我们的,有错误是好事,在解决错误的过程中成长. 4.2.1 分析错误一: _main 之所以提示缺少 _main 符号这个错误,是因为在我们的.obj里使用了printf,而 printf 的实现在LIBCD.LIB里.所以我们C语言的工程在生成Test.obj的时候将LIBCD.LIB一起链接.而在LIBCD.LIB里有一个crt0.obj,其中包含了VC6的入口代码.有两种方法可以验证我们的想法. 4.2.1.1 IDA 查看 可以将LIBCD.LIB用IDA打开查看其中的crt0.obj.(注意两点,(1)LIBCD.LIB在VC6安装目录->VC98->LIB中. (2)测试的时候发现IDA打开VC安装目录下的LIBCD.LIB时,因为权限问题打开失败.所以将其复制到桌面打开.) 双击crt0.obj进去就会看到入口代码. 向下翻,会执行一些初始化的工作,如下图: 4.2.1.2 桟回溯 打开VC工程,通过桟回溯窗口进入 WinMainCRTStartup 函数中. 可看到 WinMainCRTStartup 函数中会进行一些初始化的工作,如根据定义的宽字节或者多字节的标志选择A版还是W版的获取环境变量函数. 最后根据条件编译调用到mian函数. 4.2.2 解决错误一: _main 由上可知由于链接了LIBCD.LIB,而LIBCD.LIB中又有入口函数被链接.而拷贝到RadASM工程中的Test.obj并没有定义入口函数,缺少一个main的实现.而我们链接的流程又需要调用main符号.基于此,只要能检测到main符号,就能解决掉这个错误.有两个解决方案,任选其一都可以解决. 4.2.2.1 修改入口点 方法一,将工程中的程序入口点改为为main: 4.2.2.2 定义main函数 方法二,定义main的空函数. 4.2.3 分析错误二: GetEnvironmentStrings 链接时的第二个错误提示没找到GetEnvironmentStrings函数实现,GetEnvironmentStrings的实现是在kernel32.LIB这个库中.VC6使用的kernel32.LIB这个库位于安装目录/VC98/Lib,RadASM链接时使用的kernel32.LIB这个库位于masm32/Lib下.我们分别去看看VC6与RadASM使用GetEnvironmentStrings这个函数的声明. 4.2.3.1 masm32-GetEnvironmentStrings函数声明 RadASM使用的GetEnvironmentStrings函数声明位于masm32的include目录下的kernel32.inc中. 如果定义了 UNICODE,则用GetEnvironmentStrings 替换 GetEnvironmentStringsW.(GetEnvironmentStrings是宏,GetEnvironmentStringsW是真正的函数名.) 如果没定义了 UNICODE,则用GetEnvironmentStrings 替换 GetEnvironmentStringsA.(GetEnvironmentStrings是宏,GetEnvironmentStringsA是真正的函数名.) 4.2.3.2 VC6-GetEnvironmentStrings函数声明 如果定义了 UNICODE,则用GetEnvironmentStrings 替换 GetEnvironmentStringsW.(GetEnvironmentStrings是宏,GetEnvironmentStringsW是真正的函数名.) 如果没定义 UNICODE,则用GetEnvironmentStringsA 替换 GetEnvironmentStrings.(GetEnvironmentStringsA是宏,GetEnvironmentStrings是真正的函数名.) 4.2.3.3 分析结论 通过对比,我们发现了masm32与微软VC6对 GetEnvironmentStrings 这个函数声明不一致导致上文链接错误.那么这个锅该谁背呢?大部分人都会认为微软是巨头,潜意识中都认为以微软为标准,这个错误是masm32的过. 我们再看看微软声明的其他API,看看微软定义API时的风格,如MessageBox. 如果定义了 UNICODE,则用MessageBoxW 替换 MessageBox.(MessageBox是宏,MessageBoxW是真正的函数名.) 如果没定义 UNICODE,则用MessageBoxA 替换 MessageBox.(MessageBox是宏,MessageBoxA是真正的函数名.) 微软声明的API时大部分情况下都以带W或者带A后缀为函数名.偏偏声明GetEnvironmentStrings却相反.所以,谁的锅,真不好说. 解决错误二: GetEnvironmentStrings 既然发现问题是出于masm32与VC6对 GetEnvironmentStrings 函数声明不一致导致的错误,那么我们将masm32中的函数声明修改与VC6中的函数声明一致,是不是就能解决问题了呢?(修改前记得备份,惨痛的教训...) 修改后保存,再尝试编译链接. 为什么依旧报错呢?因为masm32中已经根据没修改前的kernel32.inc打包成kernel32.LIB了.我们必须重新将修改后的kernel32.inc打包,再替换. 在masm32/tools/inc2l中提供了打包工具inc2l.exe.(inc:头文件扩展名 |2: 谐音 to | l:lib ),从inc转成lib文件格式. 将inc2l.exe与修改后的kernel32.inc文件拷贝到D:\Tool,用命令行运行. 并没有如愿产生我们所期待的kernel32.inc.好吧,那下面动手分析下为什么没有产生LIB文件吧. 五.ESP定律脱壳 5.1 查壳 用Exeinfo查壳结果如下,可看出程序加了PEcompact壳.ESP定律手动脱壳几乎通杀全部于压缩壳和部分加密壳.(前提是无对抗) 5.2 寻找OEP 一般的加壳程序的入口处有保存环境的代码,因为要跳到OEP(入口点称为EP,原始入口点称为OEP),势必要在它恢复代码后还原环境,否则会产生不兼容.一般都会将寄存器环境保存到桟中.所以很多壳在程序的伪入口点会看到push之类的代码,就是为了保存环境,那么等它push后,我们找到栈顶的位置,等壳恢复环境时,肯定会读.于是乎,我们找到了脱壳的通用思路,我们通过它保存环境的第一个push.一旦它push后,栈顶保存了初始寄存器的内容.找到栈顶的内存位置,下硬件访问断点.等它读这个数据的时候,那么就离还原寄存器环境很近了.还原完寄存器环境后,就开始跳OEP了. 载入OD push eax,F8单步步过这条指令.(PUSH后,可看到ESP和EIP数值变化了.ESP定律中,其实变化的只有子模块.) 选中ESP,右键->数据窗口跟随 下硬件访问断点,因为它保存了环境,势必会在它恢复代码后还原环境. 按F9,注意下方触发的断点,直到断在主程序入口. 上下翻动,找回复环境的JMP.(一般还原代码后都会有个jmp跳回OEP) 在JMP处下断点.并取消刚才下的硬件断点. F7单步过去.,回到OEP. 5.3 Dump脱壳 右键->OllyDumpEx->Dump.保存为inc2l_dump.exe 六.impREC修复导入表 上文中脱壳后的程序,运行后崩了.是因为脱壳后IAT还没填写就被dump了.(导入表有一部分被毁掉了.) 还原的思路如下:因为dump后程序导入表被毁掉了.所以得重建导入表.因此得根据脱壳前程序的导入表还原脱壳后程序的导入表.OD载入inc2l.exe.走到已经被填充IAT的位置.记下IAT的起点: 找到IAT终点,根据IAT起点算出IAT大小.写个自动化程序,取出其中每一个地址,由写的程序自动识别是哪个函数哪个库,这些信息一旦获取,就可以重新建立一个新的导出表.庆幸的是,这个工具已经有人写出来了,就是impREC. 6.1 impREC附加活动进程 用OD载入inc2l.exe(Dump前的程序),在impREC中附加进程.(之前一直找不到inc2l.exe的活动进程,感谢张老师的提示,权限问题,右键管理员运行impREC即可) 6.2 手动定位IAT表信息 impREC修复导入表需要IAT的起始位置和大小.上文中我们已经找到IAT起点 :00408050 , IAT 终点 : 0040823B .那么大小就是1EC. 当然impREC也有自动搜索的功能,但貌似不是很精准,所以,建议手动. 已经采集到了IAT信息. 6.3 修复导入表. 点击Fix Dump,选择脱壳后的程序,根据采集的IAT信息重建导入表. 重建导入表后,并没有覆盖原文件,而是新存为inc2l_dump_.exe.尝试运行,发现已经可以运行.那么我们开始载入OD分析吧. 七.调试,定位原因. 7.1 带参调试 这是控制台程序,需要带命令行参数.一开始直接载入OD才发现是浪费时间.加上参数后再调试. 7.2 断点 该程序会生成LIB文件,而一般生成Lib文件需要中间文件的支持.因此必然要进行文件操作.(当然不排除变态的做法).因此我们在CreateFileA,CreateFileB(因为不知道调用的是A版还是W版,所以干脆都下断点),ReadFile,WriteFile.然后F9运行. 打开Kernel32.inc.文件句柄为 0x0000007C 读取Kernel32.inc. 创建kerenel32.def.文件句柄为 0x00000080 创建kerenel32.asm.文件句柄为 0x00000084 多次往Kernel32.asm写数据代码 往kerenl32.def写代码 目录下创建了kernel32.asm和kernel32.def文件,并且写入很多数据 7.3 初步判断 根据以上分析:读inc, 写asm,def文件.按照一般思路,有了asm,def文件,想要生成lib.一般都会使用微软提供的ml/cl程序(至少我是这样的).如果在程序调用这些程序,那么应该会有CreateProcess来创建进程.因此,我们在CreateProcessA,CreateProcessW来创建进程. 查看MSDN,CreateProcess失败返回值为0.使用 GetLastError 查看错误代码. 为了查看详细的错误代码,我们写个DEMO程序,模拟inc2l的CreateProcess.输出错误原因. [C++] 纯文本查看 复制代码
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
void ShowErrorMsg();
int main(int argc,char *argv[])
{
char szCommandLine[] = "\\masm32\\bin\\ml /c /coff kernel32.asm";
STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = TRUE;
BOOL bRet = CreateProcess(
NULL,
szCommandLine,
NULL,
NULL,
FALSE,
NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&si,
&pi
);
if (bRet)
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
}
else
{
ShowErrorMsg();
}
system("pause");
return 0;
}
void ShowErrorMsg()
{
LPVOID lpMsgBuf;
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR)&lpMsgBuf,
0,
NULL
);
MessageBox(NULL, (LPCTSTR)lpMsgBuf, TEXT("Error"), MB_OK | MB_ICONINFORMATION);
LocalFree(lpMsgBuf);
}
拷贝到inc2l_dump.exe同目录下.发现系统找不到指定文件.是不是CreateProcess中路径参数 \masm32\bin\ml 的错误呢,将DEMO程序中的路径换成相对路径再试试. 那我们再将DEMO程序和kernel32.asm,拷贝到\masm32\tools\inc2l目录下运行.运行正常还生成了obj文件. 经过测试,相对路径错误,绝对路径正确.那么说明是环境变量的问题.猜想inc2l中是不是需要哪个环境变量指向\masm32\bin里呢.抱着疑问,我们继续回到OD调试.通过桟回溯找到取环境变量的位置. 有两个跳转,拼接的命令行参数不同. 大致跟进去查看后,猜测大致流程如下图: 7.4 修复 既然是因为取环境变量"mdir",而我们又没有这个环境变量.那是不是加上了环境变量就正常了呢.加个环境变量测试下. 总结 因为默认的没有盘符,所以inc2l.exe必须与masm32处于同一盘下才能正常使用.之前我们将inc2l.exe复制到D盘,而masm32安装在C盘,因此没有正确打包成LIB文件.为了验证我们的猜想,我们将 "mdir" 环境变量删除,并在inc2l_dump.exe所在的D盘根目录新建文件夹masm32,在d:\masm32中新建文件夹bin,并且将ml.exe | link.exe拷贝其中.再尝试编译. 我们 已经 从上诉的实验中得知,之所以没有打包成功,是因为编译链接时候找不到ml.exe 与 link.exe. 而我们在安装VC6和masm32后,已经把,ml.exe 与link.exe加入环境变量中,那么我们如果我们将inc2l_dump.exe中 没有取到环境变量"mdir", 则直接使用ml.exe link.exe 编译链接呢? OD中看到默认的"masm32\bin\ml 与 "masm32\bin\link" 全局字符串,那么我们打开WinHex定位到此处. 注意,此处用的是Pascal,前4字节所以放长度,后面放字符串,0结尾. 所以修改时注意. 总结修复方案 八.Hello World 8.1 替换kernel32.lib 将打包好的kernel32.lib替换C:\masm32\lib\kernel32.lib. 8.2 入口函数mainCRTStartup. 尝试编译链接已经成功. 但运行却依旧出问题. 这是因为我们给RadAsm提供的.obj是VC环境下编译的,因此对应的入口函数也应该改为mainCRTStartup. 运行编译出的EXE,久违的Hello World.终于出来了. 九. 尾声 此文断断续续写了一个星期,结笔之时已是大年初一,希望新的一年,科锐越办越好,桃李满天下.希望科锐的老师身体健康,万事如意.希望吾爱破解 越来越辉煌.貌似愿望有点多,不过可都是真心的... 本文固定链接: http://blog.050k.com/?p=406 | 简单生活's Blog
查看全部评分
发表于 2018-2-19 18:30
|
发表于 2018-2-20 01:03
四.汇编工程4.1 新建汇编控制台工程
4.2 Link错误
4.2.1 分析错误一: _main
看完了 很多底层相关的知识大概能跟上 但是都没学过所以很不系统 期待多写一些这样的笔记~