vba2clr

TLDR:

Juste pour expérimenter différentes façons de charger des assemblys CLR (.NET) en VBA, localement et à distance, en utilisant AppDomain.ExecuteAssembly ou toute autre méthode pratique après avoir contourné AccessVBOM (l'accès programmatique au projet Visual Basic n'est pas approuvé) depuis VBA.

• vba2clr.*.vba:
  • Définit la clé de registre AccessVBOM à 1
  • Instancie un objet COM Word.Application. (pourrait être Excel.Application, MS PowerPoint, Access, etc.).
  • Ajoute une macro à partir d'une chaîne (la macro correspond à ExecuteAssembly.vba encodé en base64/hexadécimal)
  • Exécute la macro ExecuteAssembly.vba à l'aide de wordObj.Application.Run...

.NET depuis VBA:

• ExecuteAssembly.clr.2.0.vba: Jusqu'à .NET 3.5

  • Ajoute les références mscordlib requises
  • Instancie les objets requis (IDomain, ICRHost)
  • Empaquette les arguments requis de AppDomain.ExecuteAssembly dans deux tableaux séparés (variables, types).
  • Utilise DispCallFunc pour appeler AppDomain.ExecuteAssembly(Arg1, Arg2) (offset VFTable 51) où Arg1 est « l'URL de l'assembly .NET » ou « le chemin local » et Arg2 est la valeur de retour.
  • Les offsets VFTable des méthodes AppDomain peuvent être vérifiés sur l'IDL AppDomain _AppDomain.idl, gardez simplement à l'esprit que l'interface AppDomain hérite de l'interface IUnknown, donc les offsets VTable des fonctions/méthodes commencent à partir du troisième offset, car les interfaces qui héritent de IUnknown ont les 3 premières entrées de leur vtable définies sur les méthodes QueryInterface, AddRef, Release.
  • WinDbg ou IDA peuvent également être utilisés comme alternatives pour extraire les offsets VTable des fonctions/méthodes.

Notes OPSEC:

• La création d'un objet COM pour Word.Application (ou Excel.Application, etc.) entraîne le lancement d'un WinWord.exe supplémentaire comme processus enfant de svchost.exe au lieu du processus WinWord.exe principal.
• La clé de registre AccessVBOM est modifiée/restaurée via COM en utilisant WScript.Shell ; l'utilisation des API win32 pourrait être une meilleure alternative.
• Héberger le CLR en utilisant les API win32 en VBA est évidemment plus sûr que de modifier la clé de registre AccessVBOM ; je laisserai cela pour un autre jour...
• D'autres API .NET telles que System.CodeDom.Compiler peuvent être utilisées pour compiler/exécuter du code c# depuis VBA, voir la référence ci-dessous ;

Références:

• https://github.com/jet2jet/vb2clr
• https://github.com/med0x2e/NET-Assembly-Inject-Remote