谷动谷力

标题: 让C语言源码可知自身函数的实际地址与大小 [打印本页]

作者: 鸣涧    时间: 2022-10-9 23:00
标题: 让C语言源码可知自身函数的实际地址与大小
让C语言源码可知自身函数的实际地址与大小

事情的起因大概是这样……

在很久很久以前,我最早用的是MASM(Win32ASM)写程序,从平台兼容性、开发效率和规范等方面考虑,后来我义无反顾地转成了C、C++和C++++……
主要是为了保持队形,但那真的是4个+
当然也很顺手,不用像汇编那样,x86是一份代码,x64又大相径庭,再换成ARM那就没法玩了。至于运行效率,更多的可以考虑开发效率、可维护性等等,至少我是没有蜜汁自信来认为自己所写的汇编源码全文会比当今C编译器所产生的更高效。如果MASM问我,我会说爱过。
很快,根据王境泽大师的真香定理,C语言在代码注入上让我一度考虑重操旧业(与MASM混编)。接下来我们先一起教科书式地复习Windows下传统远程代码注入的套路,如果学不会也没关系,你只需要记住这一套连招,1433223、1433223、1433223、1433223。
1. 打开远端进程(OpenProcess/NtOpenProcess),权限至少包含以下步骤所需。
2. 以可读可写可执行的页面保护属性(PAGE_EXECUTE_READWRITE)为远端进程分配新的内存区域(VirtualAllocEx/NtAllocateVirtualMemory),需要PROCESS_VM_OPERATION权限。
3. 将代码写入远端进程(WriteProcessMemory/NtWriteVirtualMemory),需要PROCESS_VM_WRITE权限。
4. 刷新指令缓存(FlushInstructionCache/NtFlushInstructionCache),严谨起见,根据MSDN描述,即使是刚申请下来用于执行代码的内存,也需要刷新。
5.以刚申请用于执行代码的内存为入口点,创建远端线程(CreateRemoteThread/RtlCreateUserThread/NtCreateThreadEx)并执行。后续可以自行发挥,比如同步和获取退出码
6. 最后记得收尾。有借有还,再借不难。

期间我们会遇到两个问题。
第一,远程注入的代码中,如果调用了外部函数,很可能导致违规访问、任意代码执行等问题,因为在远端进程中调用的外部函数很可能无法被正确地寻址,甚至都不存在于远端进程中。所以我们应该要保证所注入的代码没有直接的外部函数调用,而是自己寻址。
严谨的方式是从PEB中的模块链和这些模块的导出表出发,去一步步找需要的东西,这个不是我们现在要讨论的。只要对PEB、导出表结构理解到位便不复杂,顺带一提,DLL有按序号和名称两种导出方式,导出为重定向(Forwarder Name)的情况最好也纳入考虑,可以参考ReactOS的实现(GetProcAddress -> LdrGetProcedureAddress -> LdrpGetProcedureAddress -> LdrpSnapThunk)。
第二,在第3步,如果注入本地函数,我们需要知道本地函数的实际地址与大小,才能正确地写入到远端进程中。MASM中我们可以放飞自我地定义标签:

ExampleProc_Start:ExampleProc PROC a, b    MOV     EAX, a    ADD     EAX, b    RETExampleProc ENDPExampleProc_End:
"offset ExampleProc_Start"是过程"ExampleProc"的起始地址,"offset ExampleProc_End"是其结束地址,二者之差则是其大小。
在C语言中,我们还能如此顺风顺水地获得自身定义函数的实际地址和大小吗?
我们先看地址。C语言无法定义函数外标签,函数内标签从使用到访问处处受限,我们好像只剩函数名可以用。但函数名表达式未必等同于函数的实际地址,它可能会指向JMP stub,再由该JMP stub跳转到函数实际地址:

有的甚至经由JMP stub跳转两次才到实际地址。这样的JMP stub自有用处,比如增量链接,或者兼容没有"__declspec(dllimport)"修饰的外部函数声明等等。关闭增量链接后,本地函数的函数名作表达式,应该就是正确的内存地址了。
至于函数体大小,"sizeof"操作符是用不了的。我看到网上有如下的写法:

int ExampleProc() {    return 0;}
void ExampleProcEnd() {}
然后用"ExampleProcEnd"减去"ExampleProc"。我用的是VS2019,关闭了MSVC编译器和链接器的各种优化选项、SDL和增量链接等操作,结果是从来没对过。
话说,编译器本身好像也没有责任去安排函数体的内存顺序,倒是恨不得给它们折叠一下(COMDAT)或者内联一下。
综上,关闭增量链接后,函数体实际地址有解,虽然算不上理想的解决方案;至于函数体大小,仍然是C语言本身不可及的地方。当然也可以硬编码将大小写大一些,足够覆盖该函数体,只要访问没越界应该还是可以正常工作的,我想寻求更为严谨的方式。
似乎此时我们不得不借助汇编语言。MSVC中,x86支持内联汇编,参考MSDN: Inline assembly in MSVC;x64不支持内联,但可以外置汇编源码在工程中,独立生成目标文件与其它源文件生成的目标文件链接,参考MSDN: MASM for x64 (ml64.exe)一文中"Add an assembler-language file to a Visual Studio C++ project"章节。用汇编来写要注入的函数(过程),此时可知其实际地址与大小,再供C语言中引用。
可是,这样x86写一份,x64写一份,说不准ARM也可以来凑个热闹,这不又回到了以前嘛,说好的兔子不吃……哦不,好马不吃回头草!是的,此时我们需要借助汇编,但未必非得以这样的方式。
我记得MSVC编译器可以产生相应的汇编输出,如果我们能利用它,那么或许可以保持注入函数一样使用C来编写了。下面举个栗子:
我们有C语言函数"ExampleProc",是我们要拿来注入的函数:

int __stdcall ExampleProc(int a, int b) {    return a + b;}
我们先只考虑Release构建,对应的x64汇编输出大概是这个亚子,x86在PROC的定义上大同小异:

ExampleProc PROC    lea eax, DWORD PTR [rcx+rdx]    ret 0ExampleProc ENDP
然后让我们朵蜜一下它,给它头上戴个帽子,还送一双鞋:
它就长这样了:

E4C_Start_ExampleProc:ExampleProc PROC    lea eax, DWORD PTR [rcx+rdx]    ret 0ExampleProc ENDPE4C_End_ExampleProc:
当然,"E4C_Start"之类的前缀自拟,后面用的时候对得上号就行。最后把我们需要的定义为常量,并且公开给其它模块使用:

PUBLIC E4C_Addr_ExampleProcPUBLIC E4C_Size_ExampleProc
CONST   SEGMENTE4C_Addr_ExampleProc DQ OFFSET E4C_Start_ExampleProcE4C_Size_ExampleProc DQ OFFSET E4C_End_ExampleProc - OFFSET E4C_Start_ExampleProcCONST   ENDS
x86就把DQ改为DD,对应到C语言中的size_t。汇编输出改好了,我们调用ml.exe或者ml64.exe把它重新汇编,生成新的目标文件并替换之前MSVC编译器生成的,此时它多了"E4C_Addr_ExampleProc"和"E4C_Size_ExampleProc"两个导出符号,分别是"ExampleProc"函数(过程)的实际地址和计以字节的大小。
在同一工程的其它C语言源文件中,添加以下外部符号定义,即可引用它们了:

typedef int(__stdcall* PEXAMPLEPROC)(int a, int b);
extern PEXAMPLEPROC E4C_Addr_ExampleProc;extern size_t E4C_Size_ExampleProc;
地址的定义可以直接void*,像上面这样声明成相同的proto就可以调用它,当然是多此一举(同一工程下的直接用函数名调用就好了)。大小这里用的是size_t,总之和之前在汇编输出里定义的一致就行。

但整个实现过程并不顺利,因为MSVC编译器似乎管汇编输出称为"Assembler Listing"(汇编列表),与源文件有不小差距。实际上我们之所以争取保持使用C语言写注入的函数就是因为需要它实现的逻辑相对复杂,而不像上述例子那样仅仅实现a+b这样的小儿科,从而生成的汇编输出也复杂。
这时,把MSVC生成的汇编输出直接丢给MASM汇编那可就凉了,会产生很多错误,尤其是语法错误。比如x86汇编输出缺少"assume fs:nothing",导致fs访问出错;x64输出了"FLAT:"这样只在x86中可用的标识;"$LN??"这样的标签被后向引用、重定义等;用到的浮点数被定义成以"__real@"开头的公开符号,与其它模块产生冲突等等。
最后,我将这套流程写成了PowerShell脚本(Export4C),可集成在VS生成过程中。关于之前提到MSVC汇编输出中的错误,已有一些相应修复措施,但我们仍应保持注入函数尽可能简单,没有外部函数调用,最好自己在一个独立的C源文件中凉快。
下面看一下效果:
在工程中,将要注入的函数独立放在一个源文件"InjectProc.c"中,这个函数定义为"LPTHREAD_START_ROUTINE",会给调用它的老铁返回666:

/**  * @warning Disable features like JMC (Just My Code) , Security Cookie, SDL and RTC to prevent external procedure calls generated.  * @see See also the C/C++ settings for this file  */
#include <Windows.h>
DWORD WINAPI InjectProc(LPVOID lpThreadParameter) {    UNREFERENCED_PARAMETER(lpThreadParameter);    return 666;}
打开"InjectProc.c"文件属性,【C/C++】设置里关闭JMC (Just My Code) 、Security Cookie、SDL和RTC,它们会在prologue和epilogue部分产生外部函数调用,注入到远程那就凉了。
在"Source.c"中我们把它注入指定进程里,例子中用的是当前进程PID:

/*    Example3:        Inject and execute code in a process.*/
#include <Windows.h>#include <stdio.h>
// Export4C externsEXTERN_C LPTHREAD_START_ROUTINE E4C_Addr_InjectProc;EXTERN_C SIZE_T E4C_Size_InjectProc;
int main() {    DWORD   dwPID, dwLastError, dwResult;    HANDLE  hProc, hRemoteThread;    LPVOID  lpRemoteMem;    dwLastError = ERROR_SUCCESS;    // Use current process ID in this example.    // Architecture (x64/x86) of target process should be the same with this example.    dwPID = GetCurrentProcessId();    hProc = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | SYNCHRONIZE, FALSE, dwPID);    if (hProc == INVALID_HANDLE_VALUE) {        dwLastError = ERROR_INVALID_HANDLE;        goto Label_3;    }    // Allocate memory for the process    lpRemoteMem = VirtualAllocEx(hProc, NULL, E4C_Size_InjectProc, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);    if (!lpRemoteMem) {        dwLastError = GetLastError();        printf_s("Allocate memory failed with error: %d", dwLastError);        goto Label_2;    }    // Write code to the memory and flush cache    if (!WriteProcessMemory(hProc, lpRemoteMem, E4C_Addr_InjectProc, E4C_Size_InjectProc, NULL)) {        dwLastError = GetLastError();        printf_s("Write code failed with error: %d", dwLastError);        goto Label_1;    }    FlushInstructionCache(hProc, lpRemoteMem, E4C_Size_InjectProc);    // Create remote thread and wait for the result    hRemoteThread = CreateRemoteThread(hProc, NULL, 0, lpRemoteMem, NULL, 0, NULL);    if (!hRemoteThread) {        dwLastError = GetLastError();        printf_s("Create remote thread failed with error: %d", dwLastError);        goto Label_1;    }    WaitForSingleObject(hRemoteThread, INFINITE);    if (!GetExitCodeThread(hRemoteThread, &dwResult)) {        dwLastError = GetLastError();        printf_s("Get exit code of remote thread failed with error: %d", dwLastError);        goto Label_0;    }    // "InjectProc" function returns "666"    printf_s("Remote thread returns: %d", dwResult);    // Cleanup and exitLabel_0:    CloseHandle(hRemoteThread);Label_1:    VirtualFreeEx(hProc, lpRemoteMem, 0, MEM_RELEASE);Label_2:    CloseHandle(hProc);Label_3:    return dwLastError;}
打开项目属性,【C/C++】 - 【Output Files】,设置“Assembler Output”为"Assembly Only"(/FA)或者"Assembly With Source Code"(/FAs)。切换到【Advanced】,关闭“Whole Program Optimization”,至此,在默认情况下,汇编输出会生成于中间目录$(IntDir)。
切换到【Build Events】 - 【Pre-Link Event】,命令行输入“PowerShell -ExecutionPolicy RemoteSigned -File $(SolutionDir)Export4C\Export4C.ps1 -IntDir $(IntDir) -Source InjectProc.c -NoLogo”以在相应的时候调用Export4C。
注意Export4C路径、IntDir(包含了汇编输出和原目标文件输出的中间目录)、Source(要Export4C公开其中函数实际地址和大小的源文件)要配置正确。
至此,项目可以正常生成和运行了,预期会输出“Remote thread returns: 666”。Export4C会为输入的源文件(InjectProc.c)增加其中所有函数实际地址和大小的公开符号,函数实际地址命名为"E4C_Addr_[函数名]",可定义为LPVOID或该函数实际原型;函数体大小命名为"E4C_Size_[函数名]",数据类型为SIZE_T。如同例子中"Source.c"对"E4C_Addr_InjectProc"和"E4C_Size_InjectProc"的引用。
如上,我们可以在C语言中引用源码自身中函数的实际地址与大小,全程不需要手动写一句汇编指令,并且编译器、链接器可以按原本的方式工作,支持x86和x64目标,基本不需要强行关闭什么优化。
上述例子中关闭了全程序优化,是因为它将影响汇编输出的位置,手动处理一下也可以保持它开启的状态,只要Export4C的IntDir参数目录能找到它和目标文件即可。
关闭"InjectProc.c"文件的JMC (Just My Code) 、Security Cookie、SDL和RTC功能是远程代码注入的业务需要,防止产生外部函数调用。JMC与RTC启用时是会导致一些汇编输出里的语法错误,但在Export4C脚本已对其进行处理。
这个脚本已开源于GitHub:KNSoft/Export4C,包含VS解决方案和3个示例工程(Example1 ~ Example3, VS 2019),脚本本身由PowerShell所写,在"Export4C"工程(目录)内,可以用"Get-Help" cmdlet获取它参数的详细说明。
有空的时候会继续维护和更新,增加更多的功能,导出更多有用的符号供使用。最早写这个脚本的时候,分析汇编输出时我在正则中放飞自我,结果速度有些感人,现在尽量老老实实匹配字符串去了。目前只是用它满足个人需求,进而分享,所以不算完善,暂时也只能确保在我个人的使用场景下(如VS 2019,业务需求等)符合预期。
目前只是在个人所写的小程序中使用,通过Export4C获取线程函数"RProc_LoadProcAddr_InjectThread"的实际地址与大小,供注入远端进程使用。而在"RProc_LoadProcAddr_InjectThread"线程函数中,可以根据传入的DLL模块名与函数名,得到该函数在远端进程的地址。
先遍历PEB的已加载模块链表,查找指定的DLL。如果找到,则遍历其导出表,获取指定的函数实际地址。若未被加载,则调用ntdll!LdrLoadDll尝试加载进来,再进行操作。
这或许是个新的思路,借助MASM的特性,来扩展C的功能。MASM中的第一个M是Macro而不是Microsoft,它对宏的支持可谓功能强大,并且现在ML64是支持宏的。







欢迎光临 谷动谷力 (http://bbs.sunsili.com/) Powered by Discuz! X3.2