vba2clr

TLDR:

Ich experimentiere gerade mit verschiedenen Möglichkeiten, CLR-Assemblies (.NET) in VBA lokal und remote zu laden, indem ich AppDomain.ExecuteAssembly oder eine andere praktische Methode verwende, nachdem ich von VBA aus AccessVBOM umgangen habe (der programmatische Zugriff auf das Visual-Basic-Projekt ist nicht vertrauenswürdig).

• vba2clr.*.vba:
  • Setzt den AccessVBOM-Registrierungsschlüssel auf 1
  • Instanziiert ein Word.Application-COM-Objekt (könnte Excel.Application, MS PowerPoint, Access usw. sein).
  • Fügt ein Makro aus einem String hinzu (das Makro entspricht einem b64/hex-kodierten ExecuteAssembly.vba)
  • Führt das ExecuteAssembly.vba-Makro mithilfe von wordObj.Application.Run... aus

.NET aus VBA:

• ExecuteAssembly.clr.2.0.vba: Bis zu .NET 3.5

  • Fügt die erforderlichen mscordlib-Verweise hinzu
  • Instanziiert die erforderlichen Objekte (IDomain, ICRHost)
  • Packt die erforderlichen AppDomain.ExecuteAssembly-Argumente in zwei separate Arrays (Variablen, Typen).
  • Verwendet DispCallFunc, um AppDomain.ExecuteAssembly(Arg1, Arg2) aufzurufen (VFTable-Offset 51), wobei Arg1 die „.NET Assembly URL" oder der „Local Path" ist und Arg2 den Rückgabewert darstellt.
  • Die VFTable-Offsets der AppDomain-Methoden können in der AppDomain-IDL _AppDomain.idl überprüft werden. Beachten Sie jedoch, dass das AppDomain-Interface vom IUnknown-Interface erbt, sodass die VTable-Offsets von Funktionen/Methoden erst ab dem dritten Offset beginnen. Dies liegt daran, dass Interfaces, die von IUnknown erben, die ersten 3 Einträge in ihrer VTable auf die Methoden QueryInterface, AddRef, Release gesetzt haben.
  • WinDbg oder IDA können ebenfalls als Alternativen zum Extrahieren von VTable-Offsets von Funktionen/Methoden verwendet werden.

OPSEC-Hinweise:

• Das Erstellen eines COM-Objekts für Word.Application (oder Excel.Application usw.) führt dazu, dass ein zusätzlicher WinWord.exe-Prozess als untergeordneter Prozess von svchost.exe erzeugt wird, anstatt des Hauptprozesses WinWord.exe.
• Der AccessVBOM-Registrierungsschlüssel wird über COM mithilfe von WScript.Shell geändert/wiederhergestellt; die Verwendung von Win32-APIs könnte eine bessere Alternative sein.
• Das Hosten der CLR in VBA mithilfe von Win32-APIs ist offensichtlich sicherer als das Ändern des AccessVBOM-Registrierungsschlüssels; das hebe ich mir für einen anderen Tag auf ...
• Andere .NET-APIs wie System.CodeDom.Compiler können verwendet werden, um C#-Code aus VBA zu kompilieren/auszuführen; siehe Referenz unten;

Referenzen:

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