当前位置：首页 > wzjs >正文

在招聘网站做销售技巧软文代发平台

wzjs 2025/8/19 16:01:29

在招聘网站做销售技巧,软文代发平台,企业网站系统手机版,那个网站是做辅材批发的引言在网上搜索Windows平台的远程代码注入时，经常可以看到类似下面的代码，但在实际测试环节中，会发现以上代码执行时会出现目标进程崩溃的问题。 // 打开进程 HANDLE proc OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid); // 申请可执行内…

引言

在网上搜索Windows平台的远程代码注入时，经常可以看到类似下面的代码，但在实际测试环节中，会发现以上代码执行时会出现目标进程崩溃的问题。

// 打开进程
HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
// 申请可执行内存
PDWORD pCodeRemote = (PDWORD)VirtualAllocEx(proc, 0, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
// 写入shellcode
WriteProcessMemory(proc, pCodeRemote, &ThreadProc, 4096, NULL);
// 执行远程线程
CreateRemoteThread(proc, NULL, 0, (LPTHREAD_START_ROUTINE)pCodeRemote, NULL, 0, NULL);

分析

开发环境 VS2022 + Win11 24H2

VS在编译时默认开启/GS安全编译选项。这个操作会给每个函数增加一些额外的数据和操作，用于检测栈溢出。在函数调用时，会在EBP之前压入一个额外的Security Cookie，函数执行完成后调用__security_check_cookie验证是否发生栈溢出。而由于Security Cookie是直接存储在.text段中，因此注入远程线程后会导致非法访问的错误。

DWORD WINAPI ThreadProc(FuncParamater* argvs)
{
006710C0 55                   push        ebp  
006710C1 8B EC                mov         ebp,esp  
006710C3 83 EC 58             sub         esp,58h  
006710C6 A1 00 50 67 00       mov         eax,dword ptr [__security_cookie (0675000h)]  
006710CB 33 C5                xor         eax,ebp  
006710CD 89 45 FC             mov         dword ptr [ebp-4],eax  if(argvs)
006710D0 83 7D 08 00          cmp         dword ptr [argvs],0  
006710D4 74 63                je          ThreadProc+79h (0671139h)  {**************************return 1;
00671132 B8 01 00 00 00       mov         eax,1  
00671137 EB 05                jmp         ThreadProc+7Eh (067113Eh)  }return 0
00671139 B8 02 00 00 00       mov         eax,0
}
0067113E 8B 4D FC             mov         ecx,dword ptr [ebp-4]  
00671141 33 CD                xor         ecx,ebp  
00671143 E8 38 08 00 00       call        __security_check_cookie (0671980h)  
00671148 8B E5                mov         esp,ebp  
0067114A 5D                   pop         ebp  
0067114B C2 04 00             ret         4

从根源上来讲，导致远程线程失败的原因就在于注入的代码中访问了汇编指令中使用的相对或者绝对地址，而对应的地址在远程进程中不可访问。

类似问题

常量字符串

由于字符串实际上存储在数据段，因此也会出现同样的问题。

    char buffer[] = { "1234" };
00A0171B A1 C8 61 A0 00       mov         eax,dword ptr ds:[00A061C8h]  
00A01720 89 45 F4             mov         dword ptr [ebp-0Ch],eax  
00A01723 8A 0D CC 61 A0 00    mov         cl,byte ptr ds:[00A061CCh]
00A01729 88 4D F8             mov         byte ptr [ebp-8],cl

系统调用

正常情况下，外部函数调用都是通过读取进程导入表来间接完成的，因此远程注入后也会出现不可访问异常。
通常的做法就是先通过GetProcAddress找到函数的地址，然后通过参数传递给注入代码。

        CreateProcess(NULL, (LPWSTR)argvs->command,
009D19C8 8B F4                mov         esi,esp  
009D19CA 8D 45 EC             lea         eax,[ebp-14h]  
009D19CD 50                   push        eax  
009D19CE 8D 4D A0             lea         ecx,[ebp-60h]  
009D19D1 51                   push        ecx  
009D19D2 6A 00                push        0  
009D19D4 6A 00                push        0  
009D19D6 6A 10                push        10h  
009D19D8 6A 00                push        0  
009D19DA 6A 00                push        0  
009D19DC 6A 00                push        0  
009D19DE 8B 55 08             mov         edx,dword ptr [ebp+8]  
009D19E1 83 C2 04             add         edx,4  
009D19E4 52                   push        edx  
009D19E5 6A 00                push        0  
009D19E7 FF 15 14 60 9D 00    call        dword ptr ds:[009D6014h]  
009D19ED 3B F4                cmp         esi,esp  
009D19EF E8 4C 07 00 00       call        009D2140  
009D19F4 90                   nop  NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);

基本运行时检查RTC和支持仅我的代码调试

这两个选项是Debug模式下默认开启的，分别对应/RTC1和/JMC，前者用于检测是否存在栈溢出和未初始化变量，后者用于检测是否本地代码，与/GS选项类似，由编译器在代码前后插入指令用于验证，因此注入后同样导致寻址异常。

增量链接

Debug模式默认开启的增量链接将生成的汇编中对函数的直接call引用都转化为跳转指令jmp，避免全量重建，减少链接时间，但这也会导致注入远程的实际上变成了跳转指令，而非实际代码。

示例

struct FuncParamater
{BOOL(__stdcall* CreateProc)(__in_opt    LPCWSTR lpApplicationName,__inout_opt LPWSTR lpCommandLine,__in_opt    LPSECURITY_ATTRIBUTES lpProcessAttributes,__in_opt    LPSECURITY_ATTRIBUTES lpThreadAttributes,__in        BOOL bInheritHandles,__in        DWORD dwCreationFlags,__in_opt    LPVOID lpEnvironment,__in_opt    LPCWSTR lpCurrentDirectory,__in        LPSTARTUPINFOW lpStartupInfo,__out       LPPROCESS_INFORMATION lpProcessInformation);wchar_t command[MAX_PATH];
};// 原始函数
DWORD WINAPI ThreadProc(FuncParamater* argvs)
{if(argvs){PROCESS_INFORMATION pi;STARTUPINFO si;RtlZeroMemory(&pi, sizeof(pi)); // 使用/O2优化时，memset调用会被优化，不会导致非法访问RtlZeroMemory(&si, sizeof(si)); si.cb = sizeof(STARTUPINFO);si.wShowWindow = SW_SHOW;si.dwFlags = STARTF_USESHOWWINDOW /*|STARTF_USESTDHANDLES*/;argvs->CreateProc(NULL, (LPWSTR)argvs->command,NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);return 1;}return 2;
}FuncParamater fc;PVOID func = GetProcAddress(GetModuleHandleW(L"Kernel32.dll"), "CreateProcessW");wchar_t buffer[] = { L"ConsoleApplication1.exe" };memcpy(&fc, &func, sizeof(func));memcpy(fc.command, buffer, sizeof(buffer));DWORD pid = GetTargetProcessID(L"ConsoleApplication2.exe");DWORD err = 0;HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);if (proc == NULL) {return false;}void* pDataRemote = (char*)VirtualAllocEx(proc, 0, sizeof(fc), MEM_COMMIT, PAGE_READWRITE);
if (pDataRemote == NULL) {return false;
}err = WriteProcessMemory(proc, (byte*)pDataRemote, &fc, sizeof(fc), NULL);
if (err == NULL) {return false;
}PDWORD pCodeRemote = (PDWORD)VirtualAllocEx(proc, 0, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);if (pCodeRemote == NULL) {return false;}err = WriteProcessMemory(proc, (byte*)pCodeRemote, &ThreadProc, 4096, NULL);if (err == NULL) {return false;}HANDLE hThread = CreateRemoteThread(proc, NULL, 0, (LPTHREAD_START_ROUTINE)pCodeRemote, pDataRemote, 0, NULL);if (hThread == 0) {return false;}::WaitForSingleObject(hThread, INFINITE);DWORD h;::GetExitCodeThread(hThread, &h);std::cout << "remote function return : " << h;::CloseHandle(hThread);::VirtualFreeEx(proc, pCodeRemote, 0, MEM_RELEASE);::VirtualFreeEx(proc, pDataRemote, 0, MEM_RELEASE);CloseHandle(proc);