语言列表导出xlxs_让C语言源码可知自身函数的实际地址与大小

本文为看雪论坛优秀文章

看雪论坛作者ID&＃xff1a;Ratin

事情的起因大概是这样……在很久很久以前&＃xff0c;我最早用的是MASM(Win32ASM)写程序&＃xff0c;从平台兼容性、开发效率和规范等方面考虑&＃xff0c;后来我义无反顾地转成了C、C&＃43;&＃43;和C&＃43;&＃43;&＃43;&＃43;……主要是为了保持队形&＃xff0c;但那真的是4个&＃43;当然也很顺手&＃xff0c;不用像汇编那样&＃xff0c;x86是一份代码&＃xff0c;x64又大相径庭&＃xff0c;再换成ARM那就没法玩了。至于运行效率&＃xff0c;更多的可以考虑开发效率、可维护性等等&＃xff0c;至少我是没有蜜汁自信来认为自己所写的汇编源码全文会比当今C编译器所产生的更高效。如果MASM问我&＃xff0c;我会说爱过。很快&＃xff0c;根据王境泽大师的真香定理&＃xff0c;C语言在代码注入上让我一度考虑重操旧业(与MASM混编)。接下来我们先一起教科书式地复习Windows下传统远程代码注入的套路&＃xff0c;如果学不会也没关系&＃xff0c;你只需要记住这一套连招&＃xff0c;1433223、1433223、1433223、1433223。1. 打开远端进程(OpenProcess/NtOpenProcess)&＃xff0c;权限至少包含以下步骤所需。2. 以可读可写可执行的页面保护属性(PAGE_EXECUTE_READWRITE)为远端进程分配新的内存区域(VirtualAllocEx/NtAllocateVirtualMemory)&＃xff0c;需要PROCESS_VM_OPERATION权限。3. 将代码写入远端进程(WriteProcessMemory/NtWriteVirtualMemory)&＃xff0c;需要PROCESS_VM_WRITE权限。4. 刷新指令缓存(FlushInstructionCache/NtFlushInstructionCache)&＃xff0c;严谨起见&＃xff0c;根据MSDN描述&＃xff0c;即使是刚申请下来用于执行代码的内存&＃xff0c;也需要刷新。5.以刚申请用于执行代码的内存为入口点&＃xff0c;创建远端线程(CreateRemoteThread/RtlCreateUserThread/NtCreateThreadEx)并执行。后续可以自行发挥&＃xff0c;比如同步和获取退出码6. 最后记得收尾。有借有还&＃xff0c;再借不难。期间我们会遇到两个问题。第一&＃xff0c;远程注入的代码中&＃xff0c;如果调用了外部函数&＃xff0c;很可能导致违规访问、任意代码执行等问题&＃xff0c;因为在远端进程中调用的外部函数很可能无法被正确地寻址&＃xff0c;甚至都不存在于远端进程中。所以我们应该要保证所注入的代码没有直接的外部函数调用&＃xff0c;而是自己寻址。严谨的方式是从PEB中的模块链和这些模块的导出表出发&＃xff0c;去一步步找需要的东西&＃xff0c;这个不是我们现在要讨论的。只要对PEB、导出表结构理解到位便不复杂&＃xff0c;顺带一提&＃xff0c;DLL有按序号和名称两种导出方式&＃xff0c;导出为重定向(Forwarder Name)的情况最好也纳入考虑&＃xff0c;可以参考ReactOS的实现(GetProcAddress -> LdrGetProcedureAddress -> LdrpGetProcedureAddress -> LdrpSnapThunk)。第二&＃xff0c;在第3步&＃xff0c;如果注入本地函数&＃xff0c;我们需要知道本地函数的实际地址与大小&＃xff0c;才能正确地写入到远端进程中。MASM中我们可以放飞自我地定义标签&＃xff1a;

ExampleProc_Start:ExampleProc PROC a, b MOV EAX, a ADD EAX, b RETExampleProc ENDPExampleProc_End:"offset ExampleProc_Start"是过程"ExampleProc"的起始地址&＃xff0c;"offset ExampleProc_End"是其结束地址&＃xff0c;二者之差则是其大小。在C语言中&＃xff0c;我们还能如此顺风顺水地获得自身定义函数的实际地址和大小吗&＃xff1f;我们先看地址。C语言无法定义函数外标签&＃xff0c;函数内标签从使用到访问处处受限&＃xff0c;我们好像只剩函数名可以用。但函数名表达式未必等同于函数的实际地址&＃xff0c;它可能会指向JMP stub&＃xff0c;再由该JMP stub跳转到函数实际地址&＃xff1a;有的甚至经由JMP stub跳转两次才到实际地址。这样的JMP stub自有用处&＃xff0c;比如增量链接&＃xff0c;或者兼容没有"__declspec(dllimport)"修饰的外部函数声明等等。关闭增量链接后&＃xff0c;本地函数的函数名作表达式&＃xff0c;应该就是正确的内存地址了。至于函数体大小&＃xff0c;"sizeof"操作符是用不了的。我看到网上有如下的写法&＃xff1a;

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

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

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

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

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 ENDSx86就把DQ改为DD&＃xff0c;对应到C语言中的size_t。汇编输出改好了&＃xff0c;我们调用ml.exe或者ml64.exe把它重新汇编&＃xff0c;生成新的目标文件并替换之前MSVC编译器生成的&＃xff0c;此时它多了"E4C_Addr_ExampleProc"和"E4C_Size_ExampleProc"两个导出符号&＃xff0c;分别是"ExampleProc"函数(过程)的实际地址和计以字节的大小。在同一工程的其它C语言源文件中&＃xff0c;添加以下外部符号定义&＃xff0c;即可引用它们了&＃xff1a;

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

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

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

看雪ID&＃xff1a;Ratin

https://bbs.pediy.com/user-853701.htm

  *本文由看雪论坛 Ratin 原创&＃xff0c;转载请注明来自看雪社区。

推荐文章&＃43;&＃43;&＃43;&＃43;

* Win10 1909逆向(反向计算Windows内核内存布局及代码实现)

* Chunk Extend and Overlapping笔记

* Frida 入门小练习

* 索然无味的勒索病毒

* 初试so文件解密

好书推荐

﹀﹀﹀公众号ID&＃xff1a;ikanxue官方微博&＃xff1a;看雪安全商务合作&＃xff1a;wsc&＃64;kanxue.comps. 觉得对你有帮助的话&＃xff0c;别忘点分享&＃xff0c;点赞和在看&＃xff0c;支持看雪哦~戳