
Ein PE-Loader und Windows-API-Tracer. Nützlich in der Malware-Analyse.
Dieses Projekt wurde erstellt, um die Malware-Analyse zu erleichtern. Ziel ist es, eine Aktivator-Binärdatei zu erstellen, die eine benutzerdefinierte Binärdatei lädt und die Ausführung mithilfe von Win32-API-Hooks überwacht. Relevante Daten werden dann auf der Festplatte gespeichert. Der Code unterstützt sowohl x86- als auch x64-Binärdateien.
Ich habe einen Blogbeitrag geschrieben, der die Funktionsweise erklärt: http://antonioparata.blogspot.com/2022/06/thematrix-process-inspection-tool-aimed.html
Um eine neue Binärdatei zu überwachen, muss ein Aktivator erstellt werden. Der Aktivator lädt und überwacht eine vom Benutzer eingegebene Binärdatei. Um einen Aktivator zu erstellen, verwenden Sie die Option -add. Ein Anwendungsbeispiel ist das folgende:
c:\>TheMatrix.exe -add c:\path\to\my\binary.dll
Activator file created
c:\>regsvr32.exe TheMatrix.build.dll
Dieser Befehl erstellt eine neue PE-Datei, die den Aktivator repräsentiert. Der Aktivator hat das gleiche Format (DLL oder EXE) wie die eingegebene Binärdatei.
Nach der Erstellung können Sie ihn einfach auf die gewünschte Weise ausführen (für DLLs wird empfohlen, das Dienstprogramm rundll32.exe zu verwenden).
Während der Ausführung werden die von den überwachten Funktionen generierten Daten in ./Desktop/thematrix/[Prozess-ID]/ gespeichert (dies hängt von der Funktion log_data ab, die in utility.c implementiert ist).
Einschränkung:
Das Projekt modifiziert die PEB.Ldr-Struktur, um bestimmte APIs (wie GetModuleHandle, ...) korrekt arbeiten zu lassen. Wenn Sie den Aktivator auf einem WOW64-System (x86-Binärdatei auf einem x64-Betriebssystem) ausführen, wird nur der x86-PEB.Ldr modifiziert (WOW64-Prozesse haben sowohl x86- als auch x64-PEB). Wenn die CPU zu x64 wechselt, verwenden die nativen Windows-APIs (ntdll.dll) die x64-Version von PEB.Ldr. Dies bedeutet, dass der Aktivator möglicherweise nicht richtig funktioniert. Um sicherzustellen, dass die x86-Version funktioniert, führen Sie die Binärdatei auf einem x86-Betriebssystem aus.
Die neu erstellte Datei exportiert nicht alle Methoden und enthält nicht die Ressourcen der Originaldatei. Dies kann zu Fehlern führen, z. B. wenn eine DLL GetModuleFileName -> LoadLibrary -> FindResource aufruft. Dieser Codepfad lädt die ursprüngliche TheMatrix-DLL, die die gewünschte Ressource nicht enthält.
Das Hinzufügen neuer Funktionen zum Monitor ist einfach. Sehen Sie sich die Datei hooks.c an, die einige Beispiele für Hooks von Kernel32.dll und bcrypt.dll enthält. Um einen neuen Hook hinzuzufügen, reicht es aus, die Funktion hook_add aufzurufen. Nachfolgend wird ein Beispiel für die Erstellung eines Hooks gezeigt:
LPVOID __stdcall hook_BCryptEncrypt(BCRYPT_KEY_HANDLE hKey, PUCHAR pbInput, ULONG cbInput, VOID* pPaddingInfo, PUCHAR pbIV, ULONG cbIV, PUCHAR pbOutput, ULONG cbOutput, ULONG* pcbResult, ULONG dwFlags)
{
// save plain data
if (cbInput) {
char name[MAX_PATH] = { 0 };
snprintf(name, sizeof(name), "BCryptEncrypt_%llx_%d", (uint64_t)pbInput, cbInput);
log_data(cbInput, pbInput, name);
}
LPVOID ret = call_original(
hKey,
pbInput,
cbInput,
pPaddingInfo,
pbIV,
cbIV,
pbOutput,
cbOutput,
pcbResult,
dwFlags
);
return ret;
}
hook_add("Bcrypt.dll", "BCryptEncrypt", hook_BCryptEncrypt);
Die Funktion muss die gleiche Signatur wie die gehookedte Funktion haben. Die Funktion call_original wird verwendet, um die ursprüngliche Funktion aufzurufen. Es reicht aus, diese Funktion mit den ursprünglichen Eingabeparametern der Funktion aufzurufen; das Framework erledigt die ganze Schwerstarbeit für Sie, um die richtige Funktion aufzurufen ;) Der Aufruf von call_original muss im selben Thread erfolgen, der den Hook ausführt, andernfalls stürzt der Prozess ab.