安徽省建设工程信息网宣城市公开招标信息,seo建站教学,网站估价,wordpress行业模版点击蓝字关注我们因公众号更改推送规则#xff0c;请点“在看”并加“星标”第一时间获取精彩技术分享来源于网络#xff0c;侵删事情的起因大概是这样……在很久很久以前#xff0c;我最早用的是MASM#xff08;Win32ASM#xff09;写程序#xff0c;从平台兼容性、开发…点击蓝字关注我们因公众号更改推送规则请点“在看”并加“星标”第一时间获取精彩技术分享来源于网络侵删事情的起因大概是这样……在很久很久以前我最早用的是MASMWin32ASM写程序从平台兼容性、开发效率和规范等方面考虑后来我义无反顾地转成了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
RET
ExampleProc ENDP
ExampleProc_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 MSVCx64不支持内联但可以外置汇编源码在工程中独立生成目标文件与其它源文件生成的目标文件链接参考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 [rcxrdx]
ret 0
ExampleProc ENDP然后让我们朵蜜一下它给它头上戴个帽子还送一双鞋它就长这样了E4C_Start_ExampleProc:
ExampleProc PROC
lea eax, DWORD PTR [rcxrdx]
ret 0
ExampleProc ENDP
E4C_End_ExampleProc:当然E4C_Start之类的前缀自拟后面用的时候对得上号就行。最后把我们需要的定义为常量并且公开给其它模块使用PUBLIC E4C_Addr_ExampleProc
PUBLIC E4C_Size_ExampleProcCONST SEGMENT
E4C_Addr_ExampleProc DQ OFFSET E4C_Start_ExampleProc
E4C_Size_ExampleProc DQ OFFSET E4C_End_ExampleProc - OFFSET E4C_Start_ExampleProc
CONST ENDSx86就把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语言写注入的函数就是因为需要它实现的逻辑相对复杂而不像上述例子那样仅仅实现ab这样的小儿科从而生成的汇编输出也复杂。这时把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.hDWORD 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 externs
EXTERN_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 processlpRemoteMem 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 resulthRemoteThread 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 666printf_s(Remote thread returns: %d, dwResult);
// Cleanup and exit
Label_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脚本已对其进行处理。这个脚本已开源于GitHubKNSoft/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是支持宏的。如果你年满18周岁以上又觉得学【C语言】太难想尝试其他编程语言那么我推荐你学Python现有价值499元Python零基础课程限时免费领取限10个名额▲扫描二维码-免费领取戳“阅读原文”我们一起进步
