InjectorCli + ManagedHookHostProj

Ce dépôt contient deux projets conçus pour être utilisés ensemble :

InjectorCli : Un injecteur console .NET Framework 4.8 basé sur frida-clr (Frida.dll)
ManagedHookHostProj : Une DLL d'assistance .NET Framework 4.8 avec exports natifs (via 3F .NET DllExport) utilisée pour résoudre les méthodes managées en points d'entrée natifs afin que Frida puisse s'attacher
TestTarget32 : Un exemple de programme .NET Framework 4.8 pour tester le hooking.

Ces projets ciblent Windows et supposent que vous instrumentez des processus que vous possédez ou pour lesquels vous avez la permission de tester.

Pourquoi deux projets ?

Frida accroche les adresses de code natif. Sur .NET Framework, les méthodes managées sont compilées en JIT en code natif, mais :

Frida ne fournit pas d'API stable pour « accrocher une méthode managée par nom » pour .NET Framework
Les adresses des méthodes ne sont pas connues tant que le JIT n'a pas compilé la méthode

Ainsi, le schéma général est le suivant :

Utiliser InjectorCli pour attacher/générer une cible et charger un agent JavaScript Frida.
À l'intérieur de la cible, utiliser ManagedHookHostProj.dll pour :
- Trouver une méthode managée par réflexion
- Forcer sa compilation JIT (RuntimeHelpers.PrepareMethod)
- Retourner le point d'entrée natif de la méthode (GetFunctionPointer)
De retour dans l'agent, appeler Interceptor.attach(entrypoint, ...) pour tracer les appels, journaliser les arguments et (éventuellement) modifier le comportement.

Comment ils fonctionnent ensemble (flux de données)

InjectorCli (C#)

crée un Frida.DeviceManager et sélectionne un périphérique
génère ou s'attache à un processus
crée un Frida.Script à partir de votre fichier JavaScript et le charge
affiche les messages de l'agent via script.Message

Agent (JavaScript)

peut accrocher directement les API Win32 normales (ex. CreateFileW, MessageBoxW)
peut éventuellement charger la DLL d'assistance managée avec Module.load()
appelle les fonctions d'assistance exportées (ex. ResolveMethod) via NativeFunction
utilise des tampons UTF-16 gérés par l'assistance (DescribeObjectUtf16 + FreeUtf16) au lieu d'analyser la disposition des chaînes CLR
peut interroger les diagnostics de l'assistance avec GetLastErrorUtf16 en cas d'échec de résolution
utilise les adresses retournées pour attacher des hooks

ManagedHookHostProj (bibliothèque de classes C# avec exports)

s'exécute à l'intérieur du CLR de la cible
utilise la réflexion pour localiser la méthode souhaitée par nom (+ signature de surcharge optionnelle)
force la compilation JIT et retourne l'adresse du point d'entrée natif
fournit des exports sécurisés de lecture/écriture de primitives pour les valeurs par référence (ReadInt32 / WriteInt32 / WriteBool)
expose des diagnostics d'assistance locaux au thread (GetLastErrorUtf16, ClearLastError)

Démarrage rapide (cible 32 bits)

Pour illustrer le fonctionnement de l'ensemble, nous supposerons que le processus cible est compilé pour une architecture CPU 32 bits (WoW64).

1) Compilation de `frida-clr` x86

Vous avez besoin d'une Frida.dll x86 pour injecter dans un processus cible x86.
Exemples de commandes (depuis une invite de commandes développeur Visual Studio) :

cd C:\path\to\frida-clr
configure.bat --prefix="%CD%\dist-x86" --build=windows-x86-md

cd build

make.bat

make.bat install

Confirmez que vous avez :

dist-x86\bin\Frida.dll (PE32)

2) Compilation de `InjectorCli` (x86)

Vous devez ouvrir InjectorCli.sln dans Visual Studio et définir la cible de compilation sur Release | x86.
Ou depuis une invite de commandes développeur :

msbuild \InjectorCli\InjectorCli.sln /p:Configuration=Release /p:Platform=x86

Si votre Frida.dll ne se trouve pas dans dist-x86\bin\Frida.dll, mettez à jour la référence dans InjectorCli.csproj en conséquence.

3) (Facultatif) Compilation de `ManagedHookHostProj` (x86)

Vous devez ouvrir ManagedHookHostProj.sln dans Visual Studio et définir la cible de compilation sur Release | x86.
Ou depuis une invite de commandes développeur :

msbuild \ManagedHookHostProj\ManagedHookHostProj.sln /p:Configuration=Release /p:Platform=x86

Vous pouvez ensuite vérifier les exports en exécutant la commande suivante dans l'invite de commandes développeur :

dumpbin /exports examples\ManagedHookHostProj\bin\Release\ManagedHookHostProj.dll

Remarque : sur x86 + StdCall, vous pouvez voir des noms d'export décorés (ex. _ResolveMethod@16). Le script d'agent fourni inclut un mécanisme de secours qui localise les noms décorés.

4) Exécution : traçage natif (aucune assistance managée nécessaire)

Attacher à un PID existant :

FridaClrInjector.exe --pid 1234 --script hooks\hook_createfilew.js

Générer suspendu, injecter, reprendre :

FridaClrInjector.exe --spawn "C:\Windows\SysWOW64\notepad.exe" --script hooks\hook_messagebox.js

5) Exécution : résolution de méthode managée + traçage (utilise la DLL d'assistance)

Vous devez d'abord modifier hook_managed.js, en définissant :
- helperDllPath vers la ManagedHookHostProj.dll compilée
- targetAssemblyPath, targetTypeName, targetMethodName, paramSig
Ensuite exécutez :

FridaClrInjector.exe --pid 1234 --script "C:\path\to\hook_managed.js"

Limitations

Inlining : les petites méthodes peuvent être inlinées dans les versions Release, et votre hook ne se déclenchera pas.
Surcharges : utilisez paramSig pour sélectionner la bonne surcharge, sinon vous risquez d'accrocher la mauvaise.
La compatibilité de bits est obligatoire : une cible x86 nécessite un injecteur x86 + Frida.dll x86 + DLL d'assistance x86.
Les références managées brutes sont fragiles : les exports d'assistance hérités (MakeString/Box*/DescribeObject) doivent être traités comme étant uniquement pour la compatibilité.

Documentation complémentaire

Documentation de l'injecteur :
Documentation de la DLL d'assistance :
Documentation de l'exemple de cible de test :
- README de TestTarget32
- Exécution des cas de test

DotNetHookerToolkit

Populaires