最近一直在做往年腾讯游戏安全PC端的复现,但是2023年决赛的题做到第三问就开始有点做不动了,想在网上找找题解但是并没有找到,于是便想分享一下自己的解题经验和第三问的思路。鉴于知识的局限性,文中可能存在疏漏或不足之处,如果发现任何错误或不准确之处,请不吝赐教。
题目
image-20240813190641633.png (135.45 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
(一)解题过程
第一问让我们杀死进程,可以尝试根据windowsAPI提供的TerminateProcess函数去停止进程,写份代码测试下
bool KillProcessByName(const char* processName) {
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
PROCESSENTRY32 pe;
pe.dwSize = sizeof(PROCESSENTRY32);
if (Process32First(hSnapshot, &pe)) {
do {
if (strcmp(pe.szExeFile, processName) == 0) {
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pe.th32ProcessID);
if (hProcess) {
TerminateProcess(hProcess, 0);
CloseHandle(hProcess);
Num++;
printf("Kill suc:[%d]\n", Num);
}
}
} while (Process32Next(hSnapshot, &pe));
}
CloseHandle(hSnapshot);
return true;
}
int main()
{
while(1)
{
KillProcessByName("WorkingService.exe");
}
return 0;
}
以管理员身份启动测试
启动前:
image-20240813191830392.png (16.44 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
启动后
image-20240813191935364.png (46.86 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240813192038178.png (14.34 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
(二)解题过程
先DIE查壳发现有VMP,只能动调入手,先观察程序功能。程序启动后会有两个进程启动,并且其中之一占用CPU性能较高;程序目录会创建十六个文件,并会做重复的删除和重新创建的操作;观察任务管理器发现进程会自动重启,手动杀死进程后就会重生一个新的进程。
拖进xdbg里观察符号,发现引入了ShellExcuteA这个函数,正好是启动进程函数,对这个函数下断点,发现确实断了下来,观察传参窗口。
image-20240810184600095.png (42.05 KB, 下载次数: 0)
下载附件
2024-8-13 20:02 上传
第六个参数不同,对应的是lpParameters(传入进程的参数),一个是working,一个是daemon restart
根据这个在控制台上运行加上参数working,发现只有一个工作进程,CPU占用100%,同理加上daemon restart,只有一个守护进程CPU占用不到1%。
调试参数为working的进程,观察线程发现有16个线程运行同一个函数,刚好对应16个txt日志文件的输出!!!
image-20240810190419709.png (21.63 KB, 下载次数: 0)
下载附件
2024-8-13 20:00 上传
于是进入线程入口开始分析,对所有可能的写入文件的windowsAPI下断,发现都没有断下来,于是向CreateFile等API下断,
所有线程在CreateFileA上成功断下,观察传参确定这是对日志文件的操作函数
image-20240810192612468.png (16.14 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
有了这个依据,能确认的就是16个线程会循环通过CreateFileA打开文件,这可能是占用CPU的一个主要因素。但是跟之前运行的结果不同,调试发现,写入文件的API一直没有被调用,而正常运行的结果是,十六个文件会循环的做一个过程,文件被创建->文件被写入->文件被删除->新文件创建…。我通过加working参数运行,只会有一个循环过程,即不会有新文件诞生,文件内容也不会被修改。所以,十六个线程循环CreateFileA打开文件过程是无用功,只会徒增CPU负担!那么我们是不是可以HOOK CreateFileA这个函数,然后每个线程调用它的第二次的时候我们进行线程终止,是不是可以减少CPU的压力了呢?写份代码跑一下看看
#include "pch.h"
#include
#include
#include
#include
#pragma comment(lib,"detours.lib")
#define _DEBUG
#define DBGMGEBOX(fmt, ...) \
do { \
/* 假设最大长度为1024,根据需要调整大小 */ \
wsprintfA(out, fmt, __VA_ARGS__); \
MessageBoxA(NULL, out, "提示", MB_OK); \
} while(0)
char out[100];
DWORD tlsIndex;//tls索引
typedef BOOL(WINAPI* ShellExecuteExA_t)(SHELLEXECUTEINFOA*);
typedef HANDLE (WINAPI* CreateFileA_t)(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
ShellExecuteExA_t TrueShellExecuteExA = NULL;
CreateFileA_t TrueCreateFileA = NULL;
BOOL WINAPI HookedShellExecuteExA(SHELLEXECUTEINFOA* pExecInfo) {
#if 1
//执行第一个ShellExecuteExA守护进程
static int Num = 0;
DBGMGEBOX("ShellExecuteExA 被调用:Num = %d\nhProcess = %p", Num, pExecInfo->hProcess);
if (Num == 0)
{
Num++;
return TrueShellExecuteExA(pExecInfo);
}
else
{
return TrueShellExecuteExA(pExecInfo);
}
#else
//执行第二个ShellExecuteExA病毒进程
static int Num = 0;
DBGMGEBOX("ShellExecuteExA 被调用:Num = %d \n调用者窗口句柄 = 0x%p\n", Num, pExecInfo->hwnd);
if (Num == 0)
{
Num++;
DBGMGEBOX("[2]:当前线程ID:%d", GetCurrentThreadId());
pExecInfo->lpFile = "C:\\Users\\Administrator\\Desktop\\自动F8直到call.txt";//修改参数导致重启失败;
return TrueShellExecuteExA(pExecInfo);
}
else
{
DBGMGEBOX("[1]:当前线程ID:%d", GetCurrentThreadId());
return TrueShellExecuteExA(pExecInfo);
}
#endif
}
HANDLE WINAPI HookCreateFileA(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
)
{
//判断线程是否是第一次运行CreateFileA,是的话就放行,不是第一次运行就终止线程
// 获取当前线程的TLS值
LPVOID tlsValue = TlsGetValue(tlsIndex);
if (tlsValue == NULL)
{
// 第一次运行,设置TLS值
#ifdef _DEBUG
DBGMGEBOX("放行\nlpFileName:%s\n", lpFileName);
#endif
TlsSetValue(tlsIndex, (LPVOID)1);
}
else
{
// 不是第一次运行,终止线程
#ifdef _DEBUG
DBGMGEBOX("终止\nlpFileName:%s\n", lpFileName);
#endif
ExitThread(0);
}
return CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
switch (ul_reason_for_call) {
case DLL_PROCESS_ATTACH:
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
/*TrueShellExecuteExA = (ShellExecuteExA_t)DetourFindFunction("shell32.dll", "ShellExecuteExA");
DetourAttach(&(PVOID&)TrueShellExecuteExA, HookedShellExecuteExA);*/
tlsIndex = TlsAlloc();//初始化TLS
TrueCreateFileA = (CreateFileA_t)DetourFindFunction("kernelbase.dll", "CreateFileA");
DetourAttach(&(PVOID&)TrueCreateFileA, HookCreateFileA);
DetourTransactionCommit();
break;
case DLL_PROCESS_DETACH:
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourDetach(&(PVOID&)TrueShellExecuteExA, HookedShellExecuteExA);
DetourDetach(&(PVOID&)TrueCreateFileA, HookCreateFileA);
TlsFree(tlsIndex);//清理TLS
DetourTransactionCommit();
break;
}
return TRUE;
}
注入进去查看CPU,与不注入的CPU情况对比如图,进程CPU占比显著下降
image-20240810205144922.png (14.8 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240810205250729.png (23.48 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
现在我们能够确定,是这十六个线程循环打开文件(也可能做了其他的事情)占用CPU大量资源。但是直接线程退出的方式也会导致日志文件被删除,题目意思是说在保持WorkingService.exe正常运行不崩溃、主体功能无损的前提下,使之占用CPU下降到平均5%以下,WorkingService.exe的主体功能为写入信息。在没有源码的情况下提取这个部分,自行编写一个性能更佳的服务,现在直接退出线程的方式会导致日志文件删除过快,虽然写入了信息,但是根本没法看啊,所以我们为了日志文件更方便的浏览,应该在WriteFile之后保存文件。那我们得先hook一下删除文件的函数,看一下在哪调用的,然后选择过滤掉这个函数从而保存日志文件。
尝试hook一下DeleteFileA这个函数
image-20240810215436792.png (67.83 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
发现没有被调用。
翻阅了下CreateFileA的文档,找到dwFlagsAndAttributes这个参数,发现这个参数包含了FILE_FLAG_DELETE_ON_CLOSE这个属性,意思是文件将在关闭所有句柄后立即删除
HANDLE CreateFileA(
LPCSTR lpFileName, // 文件名
DWORD dwDesiredAccess, // 访问模式
DWORD dwShareMode, // 共享模式
LPSECURITY_ATTRIBUTES lpSecurityAttributes, // 安全属性
DWORD dwCreationDisposition, // 创建或打开文件的方式
DWORD dwFlagsAndAttributes, // 文件属性
HANDLE hTemplateFile // 模板文件句柄
);
FILE_FLAG_DELETE_ON_CLOSE0x04000000 | 文件将在关闭所有句柄后立即删除,其中包括指定的句柄和任何其他打开或重复的句柄。 |
因此,只要我们改了这个属性,日志文件就不会再被删除,写代码测试下
HANDLE WINAPI HookCreateFileA(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
)
{
//缩小每个线程执行CreateFileA的次数,CPU降低到%5以下
// 获取当前线程的TLS值
LPVOID tlsValue = TlsGetValue(tlsIndex);
if ((DWORD_PTR)tlsValue
image-20240810230358085.png (63.5 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240810230525262.png (65.9 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
测试得到文件确实没有被删除,并且密文也成功写入文件,CPU占用也少于5%(峰值3%,最后趋近于0)
到这工作进程已经差不多分析完了,但是别忘了还有一个守护进程,守护进程应该也算是正常功能的一部分,那我们现在要开始结合守护进程分析。根据之前分析得到工作进程启动是通过守护进程调用ShellExcuteExA来传入working参数实现的,而这个后面启动的进程才是我们应该去注入的。而且因为程序有循环自生自灭的一个功能,我们可能要考虑循环注入实现对所有工作进程的hook。首先考虑第一个问题,如何去注入ShellExcuteExA启动的工作进程,第一个方式是Hook ShellExcuteExA这个函数,在其启动前获取ShellExcuteExA返回值->进程句柄,然后通过进程句柄进行注入;第二个方式是编写一个辅助程序,循环对每一个WorkingService.exe进程进行注入,这个要考虑到hook是否会影响守护进程的正常功能。我想先试一下第二个方式,较为简单一点,先测试一下守护进程是否会调用CreateFileA函数,如果会的话,我们要进行一下过滤操作。Hook测试了下,守护进程先启动,然后是工作进程,但是迟迟没有调试弹窗出现,说明守护进程没有调用CreateFileA。
image-20240812004624693.png (16.44 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
因此,采用方式二,只要对所有WorkingService.exe进程进行注入,Hook CreateFileA函数即可在正常程序功能执行的情况下,降低CPU能耗,写一个程序测试一下
int main() {
while (1)
{
int Num = 0;
ve = GetPidByProcName("WorkingService.exe");
if (!ve.empty())
{
printf("There are currently %d processes\n", ve.size());
//依次注入并用map标记是否被注入过
for (auto i : ve)
{
auto it = mp.find(i);
if (it == mp.end())//没有被注入过
{
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, i);
if (InjectDll(hProcess, dllPath))
{
Num++;
mp.insert({ i,true });
printf("Inject process Success!\n", Num);
}
}
else //曾经注入过该进程
{
printf("[%d] Has Been Injected\n",i);
continue;
}
}
}
else
{
printf("Wating WorkingService.exe ...\n");
}
system("cls");
//Sleep(200);
}
return 0;
}
这里使用Vector去接受所有WorkingService.exe进程的pid,然后用Map去映射一个bool值来判断是否这个进程被注入过,程序运行起来发现CPU能耗还是100%,但是程序告诉我注入成功。???疑惑住了
image-20240812014325913.png (81.62 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
因为之前注入的时候可以成功降低CPU能耗的,我很确信我的dll是没问题的,所以问题可能就是注入的方式了。考虑到之前注入使用工具注入,在进程启动的同时注入dll,而现在注入是在程序完全跑起来之后,所以怀疑是被下了钩子破坏了注入。在ARK工具里扫一下钩子看一眼。
image-20240812015018472.png (31.54 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
豁然开朗!第一个钩子勾住了NtProtectVirtualMemory函数,而我们注入模块的时候就会调用这个内核函数去修改内存权限,第二个钩子勾住了DbgUiRemoteBreakin函数,我也不知道这个函数是干什么的,问一下GPT得知
DbgUiRemoteBreakin函数是一个Windows API函数,它的作用是向指定的进程发送一个远程调试器的断点请求。当这个函数被调用时,目标进程会触发一个断点异常(通常是访问违规异常),如果目标进程已经有一个调试器附加,那么调试器就会捕获这个异常并进行处理。
这个函数通常用于以下情况:
[ol]
[/ol]
看来是能附加调试的,勾住这个来反调试,哇哦,不错的方式。但是我们就先不管它了,先成功注入dll再说。所以现在看来还得先还原NtProtectVirtualMemory函数取消钩子,再调用注入函数,修改一下代码跑一下发现日志文件不能循环写入,应该是线程都退出之后,进程并未停止,猜测是线程函数里有计数的东西,到某个值之后会通知进程结束,从而让守护进程再生工作进程,于是我改了一下hook代码,让线程终止16次后终止进程,从而实现日志文件循环再生。
效果图:
image-20240812031842620.png (18.02 KB, 下载次数: 1)
下载附件
2024-8-13 20:01 上传
image-20240812033834444.png (198.74 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
题目二的结果应该就是这样了,能保持写入日志文件功能的同时不破坏工作进程循环启动的机制,大功告成!!!
附一份exe源码和一份dll源码
//main.cpp
#include
#include
#include
#include
#include
char dllPath[] = R"(C:\Users\15386\Desktop\temp\hookDll.dll)";
std::vectorve;
std::mapmp;
BYTE jmpBytes[] = {
0xE9, 0xE0, 0x26, 0x16, 0x00
};
BYTE originBytes[] = {
0x4C, 0x8B, 0xD1, 0xB8, 0x50, 0x00, 0x00, 0x00, 0xF6, 0x04, 0x25, 0x08, 0x03, 0xFE, 0x7F, 0x01,
0x75, 0x03, 0x0F, 0x05, 0xC3, 0xCD, 0x2E, 0xC3
};
std::vector GetPidByProcName(const char* processName) {
HANDLE hProcessSnap = INVALID_HANDLE_VALUE;
PROCESSENTRY32 pe32 = { 0 };
std::vector vec;
vec.clear();
hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (hProcessSnap == INVALID_HANDLE_VALUE) {
vec;
}
pe32.dwSize = sizeof(PROCESSENTRY32);
if (Process32First(hProcessSnap, &pe32)) {
do {
if (strcmp(pe32.szExeFile, processName) == 0) {
vec.push_back(pe32.th32ProcessID);
}
} while (Process32Next(hProcessSnap, &pe32));
}
CloseHandle(hProcessSnap);
return vec;
}
DWORD64 GetModuleBase(DWORD64 pid,const char* ModuleName)
{
HANDLE hModuleSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, pid);
if (hModuleSnap != INVALID_HANDLE_VALUE) {
MODULEENTRY32 me32;
me32.dwSize = sizeof(MODULEENTRY32);
if (Module32First(hModuleSnap, &me32)) {
do {
if (_stricmp(me32.szModule, ModuleName) == 0) {
return (DWORD64)me32.modBaseAddr;
}
} while (Module32Next(hModuleSnap, &me32));
}
CloseHandle(hModuleSnap);
}
return 0;
}
BOOL InjectDll(HANDLE hProcess, LPCSTR dllPath) {
LPVOID pRemoteDllPath = VirtualAllocEx(hProcess, NULL, strlen(dllPath) + 1, MEM_COMMIT, PAGE_READWRITE);
if (pRemoteDllPath == NULL) {
printf("VirtualAllocEx Failed:[%d]\n", GetLastError());
return FALSE;
}
if (!WriteProcessMemory(hProcess, pRemoteDllPath, dllPath, strlen(dllPath) + 1, NULL)) {
printf("WriteProcessMemory Failed:[%d]\n", GetLastError());
VirtualFreeEx(hProcess, pRemoteDllPath, 0, MEM_RELEASE);
return FALSE;
}
LPTHREAD_START_ROUTINE lpLoadLibrary = (LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA");
if (lpLoadLibrary == NULL) {
printf("GetProcAddress Failed:[%d]\n", GetLastError());
VirtualFreeEx(hProcess, pRemoteDllPath, 0, MEM_RELEASE);
return FALSE;
}
HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, lpLoadLibrary, pRemoteDllPath, 0, NULL);
if (hThread == NULL) {
printf("CreateRemoteThread Failed:[%d]\n", GetLastError());
VirtualFreeEx(hProcess, pRemoteDllPath, 0, MEM_RELEASE);
return FALSE;
}
WaitForSingleObject(hThread, INFINITE);
DWORD dwExitCode;
if (GetExitCodeThread(hThread, &dwExitCode) && dwExitCode == 0) {
printf("LoadLibraryA Failed in remote process\n");
CloseHandle(hThread);
VirtualFreeEx(hProcess, pRemoteDllPath, 0, MEM_RELEASE);
return FALSE;
}
CloseHandle(hThread);
VirtualFreeEx(hProcess, pRemoteDllPath, 0, MEM_RELEASE);
return TRUE;
}
BOOL RemoveHook(HANDLE hProcess,PVOID unHookAddr, BYTE* originBytes)
{
PDWORD oldProtect = 0;
if (!WriteProcessMemory(hProcess, (PVOID)unHookAddr, originBytes, sizeof(originBytes), 0))
{
printf("RemoveHook Failed!!!: [%d]\n", GetLastError());
return FALSE;
}
}
int main() {
while (1)
{
int Num = 0;
ve = GetPidByProcName("WorkingService.exe");//获取所有进程pid
if (!ve.empty())
{
printf("There are currently %d processes\n", ve.size());
//依次注入并用map标记是否被注入过
for (auto i : ve)
{
auto it = mp.find(i);
if (it == mp.end())//没有被注入过
{
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, i);//要用管理员权限运行,要不然为返回空
if (!hProcess) printf("OpenProcess Error:[%d]", GetLastError());
DWORD64 unHookAddr = GetModuleBase(i,"ntdll.dll") + 0xA0990;//NtProtectVirtualMemory地址,ntdll + 0xA0990
if (RemoveHook(hProcess, (PVOID)unHookAddr, originBytes))//先取消NtProtectVirtualMemory钩子再注入
{
if (InjectDll(hProcess, dllPath))
{
Num++;
mp.insert({ i,true });//注入成功后进行标记
printf("Inject process Success!\n", Num);
}
}
}
else continue;//曾经注入过该进程
}
}
else printf("Wating WorkingService.exe ...\n");
Sleep(1000);
system("cls");
}
return 0;
}
//dllmain.cpp
#include "pch.h"
#include
#include
#include
#include
#include
#pragma comment(lib,"detours.lib")
#define _KDEBUG
#define DBGMGEBOX(fmt, ...) \
do { \
/* 假设最大长度为1024,根据需要调整大小 */ \
wsprintfA(out, fmt, __VA_ARGS__); \
MessageBoxA(NULL, out, "提示", MB_OK); \
} while(0)
char out[100];
DWORD tlsIndex;//tls索引
typedef BOOL(WINAPI* ShellExecuteExA_t)(SHELLEXECUTEINFOA*);
typedef HANDLE (WINAPI* CreateFileA_t)(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
ShellExecuteExA_t TrueShellExecuteExA = NULL;
CreateFileA_t TrueCreateFileA = NULL;
BOOL WINAPI HookedShellExecuteExA(SHELLEXECUTEINFOA* pExecInfo) {
#if 1
//执行第一个ShellExecuteExA守护进程
static int Num = 0;
DBGMGEBOX("ShellExecuteExA 被调用:Num = %d\nhProcess = %p", Num, pExecInfo->hProcess);
if (Num == 0)
{
Num++;
return TrueShellExecuteExA(pExecInfo);
}
else
{
return TrueShellExecuteExA(pExecInfo);
}
#else
//执行第二个ShellExecuteExA病毒进程
static int Num = 0;
DBGMGEBOX("ShellExecuteExA 被调用:Num = %d \n调用者窗口句柄 = 0x%p\n", Num, pExecInfo->hwnd);
if (Num == 0)
{
Num++;
DBGMGEBOX("[2]:当前线程ID:%d", GetCurrentThreadId());
pExecInfo->lpFile = "C:\\Users\\Administrator\\Desktop\\自动F8直到call.txt";//修改参数导致重启失败;
return TrueShellExecuteExA(pExecInfo);
}
else
{
DBGMGEBOX("[1]:当前线程ID:%d", GetCurrentThreadId());
return TrueShellExecuteExA(pExecInfo);
}
#endif
}
HANDLE WINAPI HookCreateFileA(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
)
{
//判断线程是否是第一次运行CreateFileA,是的话就放行,不是第一次运行就终止线程
// 获取当前线程的TLS值
LPVOID tlsValue = TlsGetValue(tlsIndex);
if ((DWORD_PTR)tlsValue
(三)思路分享
接着是第三题,要求是WorkingService.exe的主体功能为写入信息。在没有源码的情况下提取这个部分,自行编写一个性能更佳的服务,完全替代WorkingService.exe写入同样的密文信息,且运行时平均占用CPU时间低于5%。(2分)
根据之前分析,现在一直的程序功能主要体现在,创建守护进程启动->启动工作进程->创建十六个线程->每个线程创建一个日志文件->向文件写入密文->进程退出->守护进程循环创建工作进程,大致功能应该就是这些,而现在要解决的问题就是日志文件名和日志密文是怎么产生的。
在WriteFile下个断点看一眼密文的大致模样。
image-20240812044203214.png (38.3 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
猜测有可能是base64加密,因为之前查看字符串有看到base64的码表,还是一个魔改码表,直接丢cyberchef试一下解密
image-20240812045110783.png (73.33 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240812045242653.png (39.55 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
好熟悉的字符串,这不正是初赛题的明文嘛,这个明显就是base64加密明文了,但是还有一个疑问,就是不同的文件会打印出不同的密文,把十六个文件的密文提取出来对比一下
1 F2FU4Wht52lm+2dV4WFu 6128
2 4WECF2ht52lm+2dV4WFu 20512
2 4WECF2ht52lm+2dV4WFu 22060
3 Fx9U4RY7ERcwDRkDFx84 22708
4 Fx8CFxY7ERcwDRkD4WFu 25296
5 Fx9U4RZt5xcwDRkDFx84 25376
6 Fx8CFxY7ERcwDRkDFx84 25620
3 Fx9U4RY7ERcwDRkDFx84 25756
2 4WECF2ht52lm+2dV4WFu 26136
3 Fx9U4RY7ERcwDRkDFx84 27704
7 4R9U4RY7ERcwDWdV4WE4 27976
8 4WECF2ht5xcwDRkDFx84 28380
3 Fx9U4RY7ERcwDRkDFx84 28624
9 Fx9U4RY7EWlm+xkDFx84 28764
10 4WECFxY7ERcwDWdV4WFu 29904
11 Fx9U4RY7ERcwDWdV4WE4 31648
对比发现十六个线程有十一个密文,16:11的不规则性我觉得甚至不止十一个,因为这个采样只是采取了一个进程创建的十六个线程,如果有更多进程可能就意味着更多种密文。
根据base64编码规则,如果码表和明文都一致的话,那密文就只能有一个,说明每个线程的码表和明文至少有一个不一致。那现在只能继续分析他的加密方式,在现有的码表处下断追踪到加密函数
image-20240812073322391.png (162.29 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
在内存窗口发现传入的第一个参数是一个字符串地址->c tc me an,貌似跟catchmeifyoucan明文很像,所以这是修改了明文,然后再通过正常的码表进行base64加密?提取出这个明文,试一下对着这个码表加密,对比运行后的密文就知道了,
明文:0x15, 0x61, 0x02, 0x15, 0x68, 0x1B, 0x13, 0x69, 0x66, 0x79, 0x6F, 0x75, 0x63, 0x17, 0x18
实际密文:F2ECF2g7EWlm+2dV4R84
正常base64密文:F2ECF2g7EWlm+2dV4R84
明文:0x63, 0x17, 0x74, 0x63, 0x1E, 0x6D, 0x65, 0x1F, 0x10, 0x0F, 0x19, 0x03, 0x15, 0x61, 0x6E
实际密文:4R9U4RZt5xcwDRkDF2Fu
正常base64密文:4R9U4RZt5xcwDRkDF2Fu
对比了多组,确信了码表是对的ABCDEFGHIJKLMNOPwxyz0123456789+/ghijklmnopqrstuvQRSTUVWXYZabcdef,但是调试这个加密的过程中发现,一个线程至少会有两组明文,上面就是出自同一个线程。并且这个函数加密后的密文跟实际文件密文不同,下面是提取的两组密文和实际文件密文
//34288线程
文件密文:4WFU4Wht52lm+2dV4WFu
密文1 :Fx8C4Wg7ERcwDWdV4WE4
密文2 :4WFUFxZt52lm+xkDFx9u
现在还有很多问题在里面,首先是明文为什么一个线程有两组,加密得到的两组密文跟文件密文有什么关系?两组密文实在是太奇怪了,我试着把他们联系起来,于是我将两组密文用base64还原得到明文也进行了对比,发现了一个惊喜。
image-20240812080716501.png (13.86 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240812080739360.png (14.17 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
这两个明文的有效字符组合起来刚好是catchmeifyoucan!!! 接着就是其他无效字符了,提取出十六进制看看有没有联系
Fx8C4Wg7ERcwDWdV4WE4->0x15,0x17,0x02,0x63,0x68,0x1b,0x13,0x1f,0x10,0x0f,0x6f,0x75,0x63,0x61,0x18
4WFUFxZt52lm+xkDFx9u->0x63,0x61,0x74,0x15,0x1e,0x6d,0x65,0x69,0x66,0x79,0x19,0x03,0x15,0x17,0x6e
貌似没什么关系,考虑到多个文件的写入密文不同,继续提取其他线程的密文
//14032 线程
文件密文:Fx8CFxY7ERcwDRkDFx84
密文1 :Fx8C4Wg7ERcwDWdV4WE4
密文2 :4WFUFxZt52lm+xkDFx9u
拿这个线程的文件密文拿去解密,得到十六进制数组:0x15,0x17,0x02,0x15,0x1e,0x1b,0x13,0x1f,0x10,0x0f,0x19,0x03,0x15,0x17,0x18,刚好由34288线程的两组非可视字符十六进制组成。根据这个思路我把之前提取的密文进行了解密,发现线程之间的非字符不一定是成对的,但是非字符的十六进制跟所在索引是一定的,也就是说所有非可视字符的十六进制都是从上面这个数组里取,我试图多运行几遍进程反驳我这个猜想,因为这个十六进制数组并没有什么规律,但是运行结果都显示这个数组是一定的。
所以现在可以确定的是,明文catchmeifyoucan会和这个数组以某种方式进行混合,最后组成真正的明文进行base64换表加密得到文件密文。现在就需要继续研究这个混合的方式,因为进程会启动十六个线程来写日志,而且在之前的观察中看到在CreateFileA函数之前,密文就已经储存在寄存器中,所以是CreateThread和CreateFileA函数之间进行了明文混合和base64加密,对这三个关键地方下断点调试
image-20240812095555791.png (157.75 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
{
0x15, 0x17, 0x02, 0x15, 0x1E, 0x1B, 0x13, 0x1F, 0x10, 0x0F, 0x19, 0x03, 0x15, 0x17, 0x18
};
可以看到,第一个参数即为之前分析的十六进制数组的指针,做一层栈回溯找明文替换方式
image-20240812100645901.png (145.28 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
对base64的第一个参数位置(明文指针)下硬件访问断点,找到写入明文内存的位置
image-20240812101030609.png (154.01 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
image-20240812101825299.png (89.81 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
明文进行了一个字节一个字节的写入,仔细看这段VM给的混淆汇编代码, 其实就是一个
mov r8, qword ptr ds:[rdi]
mov r9b, byte ptr ds:[rdi+0x8]
mov byte ptr ds:[r8], r9b
那就意味着我们要追踪[RDI]看看是怎么来的,由于这段代码已经被VM了,控制流混淆导致根本没法手动追踪,用xdbg自动追踪功能打印日志看看
image-20240813181835965.png (86.27 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
足足有30000行汇编
image-20240813181952050.png (98.05 KB, 下载次数: 0)
下载附件
2024-8-13 20:01 上传
往上回溯第一层发现[rdi]从RFLAGS寄存器来的,如果真要手动回溯的话,就要回溯十多个标志位,手动分析逻辑写源码不大现实(不禁再次感叹VM的强大)
根据题目要求
提取WorkingService.exe的主体功能可以以二进制指令块的形式,也可以以自写源码的形式
可以考虑提取二进制指令块的形式写功能,那我们就可以把这段追踪得来的汇编代码转成ShellCode写入到自己程序的内存里,然后通过VirtualProtect修改成可执行的运行一下从而提取这份功能。只要获取这份功能就可以完成第三问了,感觉工程量挺大的就不写了。
程序分析总结
启动程序后会先默认按照参数daemon restart启动一个守护进程,守护进程通过设置参数working和调用ShellExcuteA来启动工作进程,工作进程会创建16个线程来循环调用CreateFileA保持文件存在(第二问需要通过修改参数实现相同功能并减少CPU占用率)并调用一次WriteFile来写入密文,密文由两个明文和两种加密组成,明文是catchmeifyoucan字符串和{
0x15, 0x17, 0x02, 0x15, 0x1E, 0x1B, 0x13, 0x1F, 0x10, 0x0F, 0x19, 0x03, 0x15, 0x17, 0x18
}数组,第一种加密是某种替换加密,第二种加密是base64变表加密。