xfocus logo xfocus title
首页 焦点原创 安全文摘 安全工具 安全漏洞 焦点项目 焦点论坛 关于我们
添加文章 Xcon English Version

Do All In One EXE File Under Win32


创建时间:2006-10-07
文章属性:原创
文章提交:icelord (icelord_at_sohu.com)

希望题目没有语法错误。
    Exe可执行,可以使用系统提供的各种服务,do all in one exe看起来是句废话。仅作技术研究,各位不要为几个文字争论。
很早就看过高手写过的文章,<<脚本的故事>>、<<do all in smd shell>>,今天我也来班门弄斧一把。做后门、木马,现在的技术不知道是什么样的,但是个人认为将他们做到内核之中,将更有威力。当然,这也是把双刃剑。见过一些rootkit,通常做法是写驱动,然后将驱动包含在exe中,运行时释放驱动为一个独立文件,然后加载驱动,由驱动完成Rootkit的各种功能,这样就会生成两个文件。为什么不把它们在一个exe文件中实现呢?今天我们就试验一下,能不能在exe中实现驱动的功能。
其实这个想法来自一个程序。当时想试验一下arp攻击,还以为win32下有相关的系统调用,google了一把,不,baidu了一把,google看不懂,说win32下发包IpPacket到可以,Arp只能用IpHlpApi提供的SendARP()函数发送(可能孤陋寡闻),而且不能手动构造arp包,而且SP2下发送TCP SYN是不允许的。晕。借助工具的话就要使用WinPcap,或者自己写驱动。我当时想是否能像Fport那样,直接操作AFD(好像是TDI,还是\device\tcp udp?),会不会能成功。看了看网上流传的源码,好复杂。WinPcap导出的调用很简单,而且linux下可以平滑过渡。不过,我的初始想法是一个比较隐蔽的程序,这就要求它有很高的独立性。所以,很自然的落到了exe驱动上来。
第一个想法:在exe中导出DriverEntry,看了看sys文件,好像没有这个导出函数,那么程序入口就是DriverEntry,但是win32下exe的ImageBase是4MB,驱动好像是0x10000,不知道win32在加载时会不会对程序作重定位。将EXE的入口修改为DriverEntry…,然后在入口函数中作判断,是用户态还是ring0。好像VC的编译器会在入口加入xxx代码,这样很麻烦,而且相当麻烦。以上证明这个想法暂时不对。不过突然有个想法,程序里面包含main 和DriverEntry,入口为main,运行后修改入口为DriverEntry,然后加载驱动…,弊端很多…
第二个想法,在exe中执行ring0代码。这是老想法了,网上有无驱执行ring0的源码,我当初也装模作样的分析了一下。具体的实现方法是使用\Device\PhysicalMemory对象映射物理内存并修改(GDT,IDT,或者hook内核函数),对此有篇文章有精彩的解说(baidu关键字’/dev/kmem ring0’)。个人觉得hook内核函数比较简单快速,进入ring0后不需要作任何环境修改。如果使用中断门或者调用门,构造就很麻烦,而且好像在哪见过门的段地址要自己重新构造…。没试验过,仅是猜测。
具体思路:
(1)    使用ZwQuerySystemInformation获取ntoskrnl.exe的基址
(2)    用户态加载ntoskrnl.exe,获取内核api相对于它所在模块基址的偏移,加上内核镜像的基址获得真正的api的地址,计算需要使用的Kernel API的地址。
(3)    将api地址减去0x80000000(NT使用flat内存映射,前512Mb物理内存直接映射到2GB,不知道打开/3GB开关是什么情况,暂不考虑),获得api的物理内存地址
(4)    映射物理内存并写入hook代码
(5)    调用Kernel API对应的NaiveAPI,进入ring0
(6)    系统调用在当前进程的内存空间执行,所以可以使用整个进程空间,直接调用(2)计算的KernelAPI完成任务(注意Irql)
看到这里,问题似乎解决了。但是,以上方法只能执行ring0代码并不能实现驱动所实现的功能,功能还非常弱,对于一个简单的MemoryDump/ProcessList还可以,其它很多都受限制。由于代码运行于进程用户内存空间,使用内核栈,如果在别的进程空间调用将KeBugCheck之类的…。很自然,我们会想到把代码拷贝到内核空间去运行。这的确是解决方法。
第一种方案:由于KernelAPI大部分由ntoskrnl.exe和HAL.DLL导出,我们可以计算这些导出函数的地址,调用ExAllocatePool()分配空间(设pKeApiSet),拷贝。然后使用同样的方法来拷贝函数代码到内核,然后将pKeApiSet作为拷贝函数的参数,调用,这样代码就运行在内核空间了,但是还是只能在当前线程的时间片下运行。如果向其它驱动注册回调函数就麻烦了,因为这些函数都有固定的格式,而且调用时无法取得我们自己的参数。使用过下面的方法解决了这个问题:
//===========================================
//修改堆栈,对于_fastcall没试过 !!!!!
#define X_RELOC_CODE "\xFF\x34\x24"\
    "\xC7\x44\x24\x04\x00\x00\x00\x00"

//若想对齐,此代码后面可以加入 nop nop
//若想跳转,此处加入push addr;   ret即可,好像不能直接jmp abs_addr??(VC)
//vc编译使用相对地址
//    __asm push dword ptr [esp]
//    __asm mov dword [esp+4],lpParam

#define X_RELOC_HEADER_SIZE     11
#define X_RELOC_CODE_SIZE        11

//辅助结构,便于抽象理解,汗
typedef struct
{
    char b1[7];
    void *lpParam;
}X_RELOC_HEADER;

//=================================================

X_RELOC_HEADER *pCode=( X_RELOC_HEADER *)__KeApiSet.ExAllocatePool(NonPagedPool,UPALIGN(size+ X_RELOC_CODE_SIZE,4096));

Memcpy((char *)pCode, X_RELOC_CODE, X_RELOC_CODE_SIZE);
pCode->lpParam=(void *)&__KeApiSet;
//x_size>=MyCallback函数的大小
memcpy((void *)((ULONG)pCode+11),(void *)MyCallback,x_size);

//这里将pCode注册到其它驱动或者对象的回调函数去,对于新的回调函数添加一个参数(指向__KeApiSet)在最左边。
例如,原来的回调函数为
    OriginalCallback(Type1 Param1,Type2 Param2….)
新的回调函数如下
    MyCallback(void *lpParam, Type1 Param1,Type2 Param2…)
其实就是在调用函数时修改函数堆栈
----------------------------------------------------------------------------------------
NewCallback    |EIP    |         OriginalCallback |EIP    |                    |MyParam    |            |Param1    |                |Param1    |            |Param2    |                |Param2    |
                堆栈状态
----------------------------------------------------------------------------------------
CodeAddr&#61664;                NewCodeLayout&#61664;
|push ebp     |                |push dword ptr [esp]|
|mov ebp,esp    |                |movdword [esp+4],xParam    |
|sub esp,xxxx    |                |push ebp            |
|    ….    |                     |mov ebp,esp        |
                      代码状态
---------------------------------------------------------------------------------------

还有一种方法是使用EIP定位。Linux下的动态库有一种浮动代码的技术,其中就用到了使用EIP定位,原理如下
Call Nextaddr___        //&#61663;&#61664;push eip(=Nextaddr___)  +   jmp addr
Nextaddr___:        //
    Pop ebx        //ebx=EIP
在刚进入函数时获取EIP值,将参数拷贝到代码前面,eip减去一个数值就可以找到参数。不过这样好象有点麻烦。

    后来想起来VC编译器支持一种naked函数,用这个函数__declspec(naked)写就可以了,白白花费了这么长时间。

    应用:使用第一种方法(代码拷贝到内核空间,修改堆栈),在进入ring0后,可以注册一个回调函数到IPFilterDriver,实现一个简单的Ip过滤,美其名曰:“放火墙”。IoGetDevicePointer&#61664;IoBuildDeviceIoControlRequest&#61664;IofCallDriver。细节可以看网上的高手写的xxxWndows下防火墙。

    第三种方法,好像有篇文章说可以使用ZwSetSystemInformation(SysLoadAndCallImage),可以直接加载并运行,而且有种rootkit就使用了这种方法。具体没有看过,可以到网上看看。

    本来到这里基本算结束了,但是上面的方法只能实现简单的功能,而且代码有点复杂,对于第二种方法,特别是函数调用,必须使用额外参数来定位。这样还不如单独写一个sys文件快。这时我考虑到了代码重定位,于是baidu一下,找到了局部变量大哥写的《NT环境下进程的隐藏》,如获珍宝,自己按着方法把代码重写了一遍,学到不少。其实PE教程说的很明白,就是看不下去…。
    对EXE进行重定位方法我就不多说了。具体方法就是在内核空间中分配代内存,拷贝自身镜像到内核,然后对内核空间的镜像作重定位。由于进入ring0后,在win2k下还可以调用用户态API(printf()还可以使用,在当前进程空间),在xp下调用会导致进程退出,估计对调用前后状态或者地址作了限制。
    有了重定位,就可在函数中使用全局变量,这样对函数的限制大大减小。但还有个问题,就是对kernel API的调用还是使用的显式调用,非常麻烦,对每个函数都要GetProcAddress(),于是我将ntoskrnl.lib和hal.lib加入到程序中,原本以为这样就可以了,可是编译通过,程序根本运行不起来,运行便出错。不知道是机器上的VC有问题,还是…,估计是加载EXE时,回加载它所使用的所有库,估计在加载ntoskrnl.exe时出错了。我手动修改PE的导入表,去掉ntoskrnl.exe模块,程序便能正常运行。
卡到了这里,决定使用先编译,再用工具修改导入表,去掉ntoskrnl.exe的引用。方法就是将ntoskrnl.exe的描述符放到导入表的最后一项,然后将ntoskrnl.exe的IMAGE_IMPORT_DESCRIPTOR拷贝到程序的其他地方(就像病毒那样,将代码写入到PE的间隙处,VC默认对齐大小是4096,这样会有很多空隙),然后将这项置零。这样加载时就不会加载ntoskrnl.exe。说起来容易,实际根本不可行,也没试,因为我查到了VC编译器的延时加载功能(/DelayLoad:dll_name)。
    通常在调用dll导出函数时,编译器为所调用的函数生成导入地址表,将函数所在模块生成IMAGE_IMPORT_DESCRIPTOR,win32在加载程序时会自动加载指定的模块,并确定导入函数的实际地址。DelayLoad将所调用的导出函数生成一个stub,类似如下:
Pid=PsGetCurentProcessId();
Call 40E68E    //这里使用了Debug模式/增量编译,所以会有个跳转
        //release/static/GZ估计为call dword ptr[xxxxxxxx]
-------------------------------------------------------------------------------
0040E682    Push ecx
         Push edx
         Push 00429364        //压入IAT地址
         Jmp 40E66E
-------------------------------------------------------------------------------
0040E68E    jmp dword ptr [00429364]//&#61664;0040E682
-------------------------------------------------------------------------------
0040E66E     Push 00429000    //压入PCImgDelayDescr地址,类似导入表
         Call 00401087    //__delayLoadHelper(pImgDelayDesc,ppfnIATEntry)
         Pop edx        //__ delayLoadHelper计算API真正地址,填入IAT
         Pop ecx
         Jmp eax        //eax=Real Address==[IAT]
-------------------------------------------------------------------------------
由于PCImgDelayDescr被放置在单独的延时输入描述符目录中,而不是通常的输入表目录,所以win32在加载时,这些延时加载的模块不会被加载。第一次调用函数时IAT间接指向__delayLoadHelper函数,而__delayLoadHelper根据函数所在模块名和函数名计算函数地址,然后写会IAT,下次执行直接跳转到真正的函数地址上去。
    DelayLoad的这种特性正好解决了当前的问题。方法就是连接ntoskrnl.lib和hal.lib,然后将ntoskrnl.exe和hal.dll延时加载,自己重写__delayLoadHelper函数来取得KernelAPi的地址,这样问题迎刃而解了。VC6自己的__delayLoadHelper函数在文件DELAYHLP.CPP中实现,其中加入了对函数Hook的功能,就是导出两个函数指针,在__delayLoadHelper中先调用指针指向的函数,若为空怎使用默认的LoadLibrary()和GetProcAddress()。这样如果想hook函数只需要将模块延时加载然后自己实现__pfnDliNotifyHook即可。
    问题:
(1)    由于在内核之中,(同一进程空间)不能调用win32API (XP下不行,2K下可以,注意:非GUI API),如果还可能在其它进程空间使用,则根本不能使用UserAPI
(2)    经过重定位的镜像在获取API名称时有问题,镜像基址大于0x80000000,地址的最高位肯定为1,这在PE中与函数的INT冲突,信息会丢失。
解决方法:
(1)    其实使用的API就是LoadLibrary() 和GetProcAddress,重写LoadLibrary和GetProcAddress函数即可。对于LoadLibrary(),只需要调用ZwQuerySystemInformation获得模块的基址即可;对于GetProcAddress,根据模块镜像的基址找到IMAGE_NT_HEADERS->IMAGE_EXPORT_DIRECTORY逐个查找即可,注意函数使用序号(ordinal)的查找。
(2)    WIN32 PE文件的导入表和延时加载描述符表都有各自的INT和IAT(暂时这样理解),对于函数地址的确定都使用类似的机制。从INT获得函数名称或者函数ordinal,然后从模块里查找函数地址,填入IAT,只是确定函数地址时间有不同。对于函数名称,,PE使用IMAGE_THUNK_DATA来描述,它其实是一个DWORD指针,指向一个DWORD数组,对于数组中的每个DWORD,如果最高位为1(&IMAGE_ORDINAL_FLAG32),则此函数按序号引入,否则此DWORD指向一个IMAGE_IMPORT_BY_NAME结构,此结构包含函数名称字符串的RVA。普通Win32进程运行在0-2GB中,所以这没问题。但我们的镜像被拷贝到0xFExx xxxx ,重定位后IMAGE_THUNK_DATA的地址肯定>0x80000000,所以只能根据经验,全部按名称引入,理由是NT、95的函数序号并不一致(从书上看的,很简单,xp导出的函数比2K多,如果按序号肯定出问题)。就在这个地方,没有调试器,只有printf,浪费了两天的时间,晕。还以为是VC自带的代码决不会有问题,重写__delayLoadHelper后解决(__delayLoadHelper对函数Ordinal & IMAGE_ORDINAL_FLAG做了判断…)。

呵呵,终于到主题了,其实前面的要困难些。
当代运行在ring0时,它已经能实现多数功能了,但是如果要作个木马,后门之类的,还要解决与用户态通信的问题(其实并不是这样),所以想到了事件之类的,或者ring0 call ring0,apc…最后还是落到了文件设备上。通过文件设备,任何进程都可以与ring0通信,而且创建驱动的宿主可以安全撤退。如果使用ring0 代码(call gate,hook),则进程不能退出,因为线程的系统调用没有返回,所以即使强行中止也无济于事。如果通过ring0代码创建一个驱动,然后ring0返回到ring3,进程就可以安全退出。而这时的代码还驻留在内核的未分页区,以回调的方式响应请求。
    学过操作系统都知道,VFS的特性,就是所有设备都是用文件来表示,其实质就是分层的函数调用,使用注册机制来处理各种设备之间的差异。实际实现表现为一个文件对象对应一个设备对象,同时设备对象又对应一个驱动对象,不同的i/o请求通过文件对象分发到不同的设备,进而转发到设备对应的驱动对象,由驱动完成最终请求。这种分层的设计有何多优点,特别适合扩展和抽象,下面深略3000字。
    要创建驱动,无非就是创建一个驱动对象,创建一个设备对象,注册函数到设备对象,然后创建设备链接以使win32可以访问到设备。看win2K 源码(\private\ntos\io\internal.c),驱动加载的基本过程为

&#61664;一堆注册表操作
&#61664;取得驱动文件名
&#61664;MmLoadSystemImage()加载驱动到内存
&#61664;ObCreateObject()创建驱动对象
&#61664;对驱动对象的各成员初始化
&#61664;ObInsertObject()
&#61664;ObReferenceObjectByHandle()    //取得对象指针
&#61664;NtClose()            //关闭ObInsertObject()创建的句柄
&#61664;驱动名称操作..
&#61664;status = driverObject->DriverInit( driverObject, &registryPath->Name );
                                    //调用驱动入口DriverEntry进行驱动初始化
&#61664;检查驱动对象的合法性(MajorFunction函数,驱动是否创建设备…)
&#61664;IopBootLog()
&#61664;MmFreeDriverInitialization()
&#61664;IopReadyDeviceObjects()            //VIP!!!!!

有了上面的过程,基本可以自己手动创建驱动并加载了,看了看搜索结果,发现ntoskrnl.exe导出了IoCreatDriver这个函数,其中实现了IopLoadDriver的大部分功能,事情变得简单起来。
NTKERNELAPI
NTSTATUS
IoCreateDriver (
    IN PUNICODE_STRING DriverName,   OPTIONAL
    IN PDRIVER_INITIALIZE InitializationFunction
    );
    具体方法就是:用exe中的DriverEntry做为参数,调用IoCreateDriver,即可实现驱动的加载。
    当在win2K下运行程序后,用WinObj居然打开失败。晕,再次看IoLoadDeiver,才发现漏掉了一个重要地方,创建驱动时,驱动对象的标志Flags和所创建设备的标志都有限制,使用IopReadyDeviceObjects()来添加驱动DRVO_INITIALIZED标志和,去掉驱动创建的所有设备的DO_DEVICE_INITIALIZING标志。IopReadyDeviceObjects()函数没有被ntoskrnl.exe导出?简单,自己写就行了。曾找不到问题原因时,还重写过IopfCompleteRquest和IopCompleteRequest,那才叫痛苦呢。
    Finally,搞定。为了方便,写了一个库,下次使用时就简单多了

#include “DrvHlpApi.h”
NTSTATUS Driverentry(void *pDriverObject,void *pRegPath)
{
//    ….IoCreateDevice()..
    Return STATUS_SUCCESS;
}

Int main(int argc.char **argv)
{
    x_InitRing0Utils();    
    x_StartDriver((ULONG)DriverEntry,0,0);
    return 0;
}
使用这个方法,完全可以实现驱动的所有功能,同时将它与win32程序结合在一起。在XP SP2和win2k SP4下测试通过(就试过IpFilter那个)。就这么简单。有兴趣的朋友可以mail来取得代码,头文件和库可以在http://icelord.bokee.com下载到。

参考文章:
1.《NT环境下进程的隐藏》
2.Win2K Source Code
3.PE文件格式详解
4.Ring0Demo.c v1.0 by zzzEVAzzz
5.《开发Windows 2K/XP 下的防火墙》
6. ...