目前的系列目录(后面会根据实际情况变动):
在注入Python之前,先使用Python写一个注入器。原理和C++的远程线程注入是一样的,使用CreateRemoteThread在进程内部调用LoadLibrary加载dll。
核心代码如下:
# 通过微信进程pid获取进程句柄
hProcess = OpenProcess(PROCESS_ALL_ACCESS, False, pid)
# 在微信进程中申请一块内存
lpAddress = VirtualAllocEx(hProcess, None, MAX_PATH, MEM_COMMIT, PAGE_EXECUTE_READWRITE)
# 往内存中写入要注入的dll的绝对路径
WriteProcessMemory(hProcess, lpAddress, c_wchar_p(dllpath), MAX_PATH, byref(c_ulong()))
# 因为注入的微信是32位的,所以运行的Python也需要是32位的
if platform.architecture()[0] != '32bit':
raise Exception("需要使用32位Python才能正常执行,请更换后重试!")
# 在微信进程内调用LoadLibraryW加载dll
hRemote = CreateRemoteThread(hProcess, None, 0, LoadLibraryW, lpAddress, 0, None)
time.sleep(0.1)
# 关闭句柄
CloseHandle(hProcess)
CloseHandle(hRemote)
其中像OpenProcess这样的函数都是Windows提供的API,在Python中可以使用ctypes库调用它们。完整代码这里就不放了,想了解的可以看后面的github。另外,后面会有一篇文章单独讲ctypes,里面就会涉及调用Windows API和定义C结构体
众所周知,Python的核心函数都在python310.dll里,然后再加上pyd、dll和py这些基础库和一些exe可执行文件,python.exe和pythonw.exe只是调用了python310.dll里的导出函数。
既然核心都在python310.dll,我是不是只需要将这个dll注入到其他进程,然后参考python.exe的代码进行初始化就能完成Python的注入。
实际上有一个Python库(Pymem)就是这么干的:Injecting a python interpreter into any process,不过测试下来局限性很大,首先是调用远程函数的API是CreateRemoteThread,它只支持调用的函数传递一个参数,虽然可以是结构体,但是Python构造结构体也不方便,然后是代码比较繁琐,所以还是自己研究了。
可以看到整个exe只调用了一个函数Py_Main,如果我用C++写一个exe,在里面加载python310.dll,然后调用Py_Main是不是能写一个python.exe
先测试一下,这里我不去引入python的头文件和lib库,而是使用LoadLibraryW加载python310.dll
C++代码如下:
#include
#include
int wmain(int argc, wchar_t* argv[]) {
// 指定要加载的DLL,这里我打算放到同一目录,就不写绝对路径了
const wchar_t* dllFileName = L"python310.dll";
// 加载DLL
HMODULE hModule = LoadLibraryW(dllFileName);
// 获取导出函数地址
FARPROC Py_Main_addr = GetProcAddress(hModule, "Py_Main"); // 替换为导出函数的名称
// 定义函数指针和调用函数
typedef int(*Py_Main_Type)(int, wchar_t**);
Py_Main_Type Py_Main = (Py_Main_Type)Py_Main_addr;
int result = Py_Main(argc, argv);
return 0;
}
编译后把它放到python310.dll同级目录,然后双击运行,测试发现和python.exe的功能是一模一样的
因为dll无法传递进程参数,所以我将argv写死了,python310.dll也使用绝对路径,完整代码如下:
#include "pch.h"
void run_python() {
const wchar_t* dllFileName = L"T:\\Code\\compile_python\\Inject_dll\\python-3.10.11-embed-win32\\python38.dll";
HMODULE hModule = LoadLibraryW(dllFileName);
FARPROC Py_Main_addr = GetProcAddress(hModule, "Py_Main");
typedef int(*Py_Main_Type)(int, wchar_t**);
Py_Main_Type Py_Main = (Py_Main_Type)Py_Main_addr;
// 获取当前进程可执行文件的路径
wchar_t exePath[MAX_PATH];
GetModuleFileNameW(NULL, exePath, MAX_PATH);
int argc = 1;
wchar_t* argv[2];
argv[0] = exePath;
argv[1] = nullptr;
Py_Main(argc, argv);
}
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH: {
run_python();
}
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
当我将编译好的dll注入到其他进程内却什么也没有发生,为了不受其他进程影响,我先把他注入到我自己写的进程里,就用之前帖子写的SubProcess了。
先验证下python有没有运行成功,调用PyRun_SimpleString来执行代码写文件测试看看
将上面的Py_Main(argc, argv);
换成PyRun_SimpleString("with open('D:\\\\1.txt', 'w') as f: f.write('aaaaa')");
文件并没有被写到指定的路径,谷歌搜索了下,是因为没有调用Py_InitializeEx或Py_Initialize初始化,加上下面两行代码就可以了。
Py_SetProgramName(exePath);
Py_InitializeEx(1);
PyRun_SimpleString("with open('D:\\\\1.txt', 'w') as f: f.write('aaaaa')");
我用同样的dll注入到微信时,界面没有什么变化,但是文件正常写到指定路径,说明Python执行没有问题。猜想可能是Py_Main不会自己打开终端,因为之前的进程本来就是控制台程序,注入之后能看到Python输出再控制台。而微信没有控制台,所以没办法看到。
那么看看能不能打开进程的控制台,搜索发现还真有这样的函数,一行代码即可AllocConsole();
,另外还需要三行代码来将Python的输入输出重定向到这个控制台,不然还是看不到Python的输出和交互式终端
freopen("CONIN$", "r+t", stdin);
freopen("CONOUT$", "w+t", stdout);
freopen("CONOUT$", "w+t", stderr);
这样需要添加一个宏来允许不安全的函数,或者用下面的代码
FILE* conin = stdin;
FILE* conout = stdout;
FILE* conerr = stderr;
freopen_s(&conin, "conin$", "r+t", stdin);
freopen_s(&conout, "conout$", "w+t", stdout);
freopen_s(&conout, "conout$", "w+t", stderr);
这样就能在注入dll后打开Python的交互式终端,查看进程id也是注入进程的id,到此本篇文章的目的已经达到了。 这里有个特别无语的坑,freopen函数无法在Debug模式下生效,也就是说如果你dll编译成Debug的话,能打开终端,但是看不到Python输出和交互式终端,为此我还谷歌了搜了一天,以为是freopen没效果。
在知道上面不显示交互式终端是因为Debug模式不生效之前,我还尝试了一些操作,比如这篇
PyObject* sys = PyImport_ImportModule("sys");
PyObject* io = PyImport_ImportModule("io");
PyObject* pystdout = PyObject_CallMethod(io, "open", "ss", "CONOUT$", "wt");
if (-1 == PyObject_SetAttrString(sys, "stdout", pystdout)) {
/* Announce your error to the world */
}
Py_DECREF(sys);
Py_DECREF(io);
Py_DECREF(pystdout);
如果不想去Python源码里拷贝PyObject的定义,可以直接定义成void *
,然后定义PyObject_SetAttrString函数指针时参数也是void*
类型的就可以
改完以后的代码(Py_DECREF不是导出函数,调用起来比较麻烦就不调了):
void* sys = PyImport_ImportModule("sys");
void* io = PyImport_ImportModule("io");
void* pystdout = PyObject_CallMethod(io, "open", "ss", "CONOUT$", "wt");
if (-1 == PyObject_SetAttrString(sys, "stdout", pystdout)) {
}
在c代码中设置sys.stdout来将Python输出打印到终端,测试是可以将print显示到终端的。上面的代码应该和freopen("CONOUT$", "w+t", stdout);
是一样的,所以只要在加上设置stdin和stderr的就能打开交互式终端。这里我就不测试了。
另外,我还尝试了多种打开终端的方式
python -i test.py
: 在执行python脚本时,可以指定-i选项进入交互式终端,当然也可以不指定脚本用python -i
,见这篇
。 大概意思是,Python只有在启动是控制台应用时才会打开终端,必须指定-i选项强制打开终端import code;code.interact()
: 这两行代码也能打开交互式终端,可以在代码任意位置插入,就能访问当前的变量code.InteractiveConsole(locals()).interact()
: 这个和上面的一样,只是添加到locals里的变量到终端import os;os.environ["PYTHONINSPECT"] = "1"
: 可以通过设置PYTHONINSPECT这个环境变量来控制python打开交互式终端,不一样要代码设置,在系统添加这个环境变量也可以上面是通过LoadLibraryW来动态加载Python的dll,这里我测试下通过lib库和头文件来链接Python。这样做的优点是可以不用写函数指针这种,少了很多代码。
代码如下:
#include "pch.h"
#include "Python.h"
#include
DWORD WINAPI run_python(PVOID pParam) {
AllocConsole();
freopen("CONIN$", "r+t", stdin);
freopen("CONOUT$", "w+t", stdout);
freopen("CONOUT$", "w+t", stderr);
wchar_t exePath[MAX_PATH];
GetModuleFileNameW(NULL, exePath, MAX_PATH);
int argc = 1;
wchar_t* argv[2];
argv[0] = exePath;
argv[1] = nullptr;
Py_SetProgramName(exePath);
Py_InitializeEx(1);
PyRun_SimpleString("print('hello')");
Py_Main(argc, argv);
return 0;
}
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH: {
CreateThread(NULL, 0, run_python, NULL, 0, NULL);
}
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
这里又出现个比较麻烦的问题,编译后的dll和python里的所有文件都得放到被注入进程的目录才能生效,这个应该是跟Windows下dll搜索路径有关。对Windows编程不是很熟悉,搜了下也没找到解决办法,有知道的大佬请指教下
在功能上和上面使用LoadLibraryW基本一样,所以这样写会简洁很多,不用定义那么多的函数指针和类型
https://github.com/kanadeblisst00/PyRobot-part2