mxmssh/drltraceDrltrace est un traceur d'appels de bibliothèque pour les applications Windows et Linux.
Build de test Windows
Build de test Linux 
Drltrace est un traceur dynamique d'appels API pour les applications Windows et Linux. Drltrace est construit au-dessus du DynamoRIO, un framework d'instrumentation binaire dynamique. Drltrace a été initialement implémenté par Derek Bruening et distribué avec les frameworks DynamoRIO et DrMemory. Ce dépôt contient une version autonome de drltrace avec des scripts et du matériel supplémentaires sur la façon de l'utiliser pour l'analyse de logiciels malveillants. La version compilée peut être téléchargée ici.
L'utilisation de drltrace est très simple. Un utilisateur doit spécifier un répertoire de journalisation et le nom d'un processus cible de la manière suivante :
drltrace -logdir . -- calc.exe
C'est tout, l'outil injectera les DLL requises dans le processus cible, démarrera l'instrumentation et, en parallèle, enregistrera des informations sur tous les appels de bibliothèque exécutés dans le processus cible :
~~43600~~ msvcrt.dll!__wgetmainargs
arg 0: 0x010d2364
arg 1: 0x010d2368
and return to module id:0, offset:0x193a
~~43600~~ ntdll.dll!EtwEventRegister
arg 0: 0x002ff994
arg 1: 0x010d1490
and return to module id:0, offset:0x157e
~~43600~~ ntdll.dll!EtwEventSetInformation
arg 0: 0x007b4b40
arg 1: 0x00000033
and return to module id:0, offset:0x15a1
~~43600~~ SHELL32.dll!ShellExecuteW
arg 0: <null> (type=<unknown>, size=0x0)
arg 1: <null> (type=wchar_t*, size=0x0)
arg 2: calculator:// (type=wchar_t*, size=0x0)
arg 3: <null> (type=wchar_t*, size=0x0)
arg 4: <null> (type=wchar_t*, size=0x0)
arg 5: 0x1 (type=int, size=0x4)
and return to module id:0, offset:0x167d
Le format de la sortie est simple et peut être facilement analysé par un script externe :
~~[id du thread]~~ [nom de la DLL]![nom de l'appel API]
arg [numéro d'arg] : [valeur] (type=[nom du type Windows], size=[taille de l'arg])
and return to module id:[id unique du module], offset:[offset en mémoire]
L'analyse avec grep peut être effectuée lorsque l'argument -grepable est utilisé ; cela imprime les noms de fonctions et les arguments sur une seule ligne :
~~4824~~ KERNELBASE.dll!CreateFileW {0: C:\Windows\Fonts\staticcache.dat (type=wchar_t*, size=0x0)} {1: 0x80000000 (type=DWORD, size=0x4)} {2: 0x3 (type=DWORD, size=0x4)} {3: 0x005cde8c (type=<unknown>*, size=0x0)} {4: 0x3 (type=DWORD, size=0x4)} {5: 0x80 (type=DWORD, size=0x4)}
La table des identifiants uniques des modules est imprimée à la fin du fichier journal :
Module Table: version 3, count 70
Columns: id, containing_id, start, end, entry, checksum, timestamp, path
0, 0, 0x010d0000, 0x010da000, 0x010d1b80, 0x0000f752, 0xb5fe3575, C:\Windows\SysWOW64\calc.exe
1, 1, 0x6d4c0000, 0x6d621000, 0x6d563940, 0x00136d65, 0x59ce1b0b, C:\Users\Max\Downloads\drltrace\drltrace\dynamorio\lib32\release\dynamorio.dll
2, 2, 0x73800000, 0x73975000, 0x7380dbf7, 0x00000000, 0x59ce1b0f, C:\Users\Max\Downloads\drltrace\drltrace\bin\release/drltracelib.dll
3, 3, 0x742f0000, 0x742fa000, 0x742f2a00, 0x0000c877, 0x0adc52c1, C:\Windows\System32\CRYPTBASE.dll
4, 4, 0x74300000, 0x74320000, 0x7430c9b0, 0x0002c617, 0x245970b4, C:\Windows\System32\SspiCli.dll
5, 5, 0x74410000, 0x74431000, 0x74416900, 0x0002a940, 0x88a53c1d, C:\Windows\System32\GDI32.dll
6, 6, 0x74440000, 0x74500000, 0x7446fb20, 0x000cc410, 0xd343d532, C:\Windows\System32\RPCRT4.dll
7, 7, 0x74500000, 0x74525000, 0x745047d0, 0x00026737, 0xa39c8991, C:\Windows\System32\IMM32.DLL
8, 8, 0x74550000, 0x745c7000, 0x7456e8a0, 0x00081857, 0x73b971e1, C:\Windows\System32\advapi32.dll
9, 9, 0x748f0000, 0x74929000, 0x748febd0, 0x00045303, 0xa58be652, C:\Windows\System32\cfgmgr32.dll
10, 10, 0x74930000, 0x75c78000, 0x74aa09d0, 0x01377aa6, 0x4b39926b, C:\Windows\System32\SHELL32.dll
Drltrace peut facilement filtrer les appels inter-bibliothèques et n'afficher que les appels API effectués à partir du module principal (ou du tas) d'une application cible en spécifiant l'option -only_from_app, ce qui est très utile dans le cas d'applications générant d'énormes journaux. Pour un contrôle plus granulaire, l'option -filter permet à l'utilisateur de spécifier un fichier de configuration de filtre afin de filtrer les fonctions autorisées spécifiques (liste blanche) ou d'ignorer les fonctions de la liste noire (voir le fichier filter.config pour des exemples). Drltrace dispose également de plusieurs scripts externes utiles pour filtrer les appels API pour une certaine bibliothèque, n'afficher que les appels API et les chaînes potentiellement intéressants.
Les modules principaux de Drltrace sont distribués sous licence BSD.
Certains fichiers nécessaires à drltrace sont distribués sous LGPL. Voir les fichiers source pour plus de détails.
L'analyse de logiciels malveillants n'est pas une tâche facile. Des packagers logiciels sophistiqués comme Themida et Armadillo, ainsi que des dizaines de packagers non nommés écrits par des auteurs de malwares, plus le chiffrement du code et des données, facilitent considérablement (dans certains cas rendent complètement impossible) la rétro-ingénierie statique de tels échantillons, compliquant la vie des analystes de malwares. Dans ce cas, le traçage des appels API peut réduire considérablement le temps nécessaire pour comprendre l'intention malveillante réelle et révéler de nombreux détails techniques sur le code malveillant protégé.
Bien que la technique traditionnelle de hooking d'API ait été implémentée avec succès dans plusieurs solutions, cette approche est bien étudiée par les auteurs de malwares et peut être facilement détectée et/ou contournée. De plus, ces outils sont distribués sous forme d'applications GUI lourdes et autonomes (en tant que produits propriétaires), qui ne sont souvent pas faciles à intégrer dans un flux de travail d'analyse de malwares existant.
Si l'on regarde le monde Linux, il existe un outil formidable appelé ltrace. En utilisant une seule commande bash, nous pouvons facilement obtenir la trace complète des appels API d'un exécutable donné.
Pourquoi n'avons-nous pas un tel outil (comme ltrace sous Linux) pour Windows, qui soit également transparent face aux techniques anti-recherche utilisées par les malwares modernes ?
Il s'avère qu'il existe une technique qui peut nous aider à avoir un tel outil pour Windows et à tracer les appels API de manière transparente par rapport au programme exécuté. Cette technique s'appelle l'instrumentation binaire dynamique (DBI). La DBI est une technique d'analyse du comportement d'une application binaire au moment de l'exécution par l'injection de code d'instrumentation.
Cependant, l'application de la DBI à l'analyse de malwares est injustement limitée à l'automatisation du dépaquetage et à quelques preuves de concept pour le traçage d'instructions, de blocs de base et d'appels de fonctions. À notre connaissance, drltrace est le premier outil de traçage d'appels API basé sur la DBI pouvant être utilisé en pratique pour l'analyse de malwares. Nous avons fourni plusieurs exemples d'analyse de malwares dans notre wiki où nous avons décrit comment drltrace a permis de révéler en quelques minutes de nombreux détails techniques internes sur des échantillons malveillants sophistiqués sans même avoir à démarrer IDA ou un débogueur.
-logdir [ .] Répertoire des journaux pour écrire les données d'appels de bibliothèque
-only_from_app [ false] Signale uniquement les appels de bibliothèque provenant de l'application
-follow_children [ true] Tracer les processus enfants
-print_ret_addr [ false] Afficher l'adresse de retour de l'appel de bibliothèque
-num_unknown_args [ 2] Nombre d'arguments inconnus d'appel de bibliothèque à afficher
-num_max_args [ 6] Nombre maximum d'arguments à afficher
-default_config [ true] Utiliser le fichier de configuration par défaut.
-config [ ""] Chemin vers un fichier de configuration personnalisé.
-filter [filter.config] Chemin du fichier de liste blanche/noire.
-ignore_underscore [ false] Ignore les noms de routines de bibliothèque commençant par "_".
-help [ false] Afficher ce message.
-version [ false] Afficher le numéro de version.
-verbose [ 1] Modifier la verbosité.
-use_config [ true] Utiliser le fichier de configuration
-grepable [ false] Sortie exploitable avec grep
Drltrace prend en charge des fichiers de configuration externes dans lesquels un utilisateur peut décrire comment drltrace doit afficher les arguments pour certains appels API.
HANDLE|CreateRemoteThread|HANDLE|SECURITY_ATTRIBUTES*|size_t|THREAD_START_ROUTINE*|VOID*|DWORD|__out DWORD*
Chaque argument de fonction doit être séparé par |. Le premier argument est le type de retour, le second est le nom de la fonction elle-même et les autres sont les arguments de la fonction. Un jeton __out est utilisé pour marquer les arguments de sortie et ___inout pour marquer les arguments d'entrée+sortie.
Vous pouvez trouver des exemples d'utilisation de drltrace pour l'analyse de malwares complexes sur notre page Wiki.
Pour faciliter le travail avec les fichiers journaux, nous avons implémenté un script appelé api_calls_viz.py qui peut être utilisé pour générer des images RVB où chaque couleur de pixel représente un appel API unique. Par exemple, l'image ci-dessous représente le fichier journal du malware WannaCry.
Les grandes zones vertes sur l'image représentent des appels API (wcscmp/wcsicmp) qui sont utilisés pour sélectionner des fichiers avec des extensions intéressantes (par exemple docx, xls, py) afin de les chiffrer. Les zones violettes représentent des appels API (FindFirstFile/FindNextFile/CryptEncrypt) qui sont utilisés pour énumérer et chiffrer les fichiers et dossiers sur le disque.
Le script peut également générer une représentation HTML de l'image RVB générée où chaque élément peut être sélectionné pour afficher le nom d'un appel API.
Voir le répertoire api_calls_viz pour plus de détails.
Vous pouvez trouver un manuel détaillé sur cette page Wiki.
Windows, Linux (macOS dans le futur).
x86, x64 (ARM sur la liste).
Bibliothèque standard C et C++ (et scripts de gestion des journaux écrits en Python).
Nous avons décidé d'implémenter notre traceur d'appels API sur la base du framework d'instrumentation binaire dynamique DynamoRIO. Drltrace demande à DynamoRIO d'effectuer l'instrumentation de l'appel LoadLibrary afin de pouvoir gérer les nouvelles bibliothèques chargées par le processus cible. Lorsque le processus tente de charger une nouvelle bibliothèque, DynamoRIO redirige le flux de contrôle vers drltracelib.dll. À son tour, drltrace énumère les fonctions exportées dans la DLL nouvellement chargée et enregistre un rappel spécial pour chacune d'elles. Ainsi, si une fonction exportée est appelée par le malware, le rappel de drltrace sera exécuté avant cette fonction et l'outil pourra enregistrer toutes les informations requises telles que le nom de la fonction et ses arguments. Un autre rappel peut être enregistré après la fonction pour enregistrer les résultats de l'exécution.
Pourquoi pas Intel Pin ? Nous avons choisi d'utiliser DynamoRIO pour les raisons suivantes :
-syswide_on de drrun.exe). Cependant, à l'avenir, il est nécessaire d'implémenter un support spécial dans drltrace pour de telles situations.Notre gestionnaire de tickets contient plus de détails sur l'avenir de drltrace.
Maksim Shudrak https://github.com/mxmssh
Derek Bruening https://github.com/derekbruening
Joe Testa https://github.com/jtesta