vba2clr

TLDR:

Apenas experimentando diferentes maneiras de carregar assemblies CLR (.NET) em VBA local e remotamente usando AppDomain.ExecuteAssembly ou qualquer outro método útil depois de contornar o AccessVBOM (acesso programático ao projeto do Visual Basic não é confiável) a partir do VBA.

• vba2clr.*.vba:
  • Define a chave de registro AccessVBOM para 1
  • Instancia um objeto COM Word.Application. (poderia ser Excel.Application, MS PowerPoint, Access ..etc).
  • Adiciona Macro a partir de String (a Macro corresponde ao ExecuteAssembly.vba codificado em b64/hex)
  • Executa a Macro ExecuteAssembly.vba usando wordObj.Application.Run...

.NET a partir do VBA:

• ExecuteAssembly.clr.2.0.vba: Até .NET 3.5

  • Adiciona as referências necessárias da mscordlib
  • Instancia os objetos necessários (IDomain, ICRHost)
  • Empacota os argumentos necessários de AppDomain.ExecuteAssembly em dois arrays separados (variáveis, tipos).
  • Usa DispCallFunc para chamar AppDomain.ExecuteAssembly(Arg1, Arg2) (offset 51 da VFTable) onde Arg1 é a "URL do Assembly .NET" ou "Caminho Local" e Arg2 é o valor de retorno.
  • Os offsets da VFTable dos métodos do AppDomain podem ser verificados no IDL do AppDomain _AppDomain.idl, apenas lembre-se que a interface AppDomain herda da interface IUnknown, então os offsets da VTable de funções/métodos começam a partir do terceiro offset em diante, isso ocorre porque interfaces que herdam de IUnknown têm as 3 primeiras entradas da vtable definidas como métodos QueryInterface, AddRef, Release.
  • WinDbg ou IDA também podem ser usados como alternativas para extrair offsets da VTable de funções/métodos.

• ExecuteAssembly.clr.x.vba: suporta .NET 2, 3.5 e 4.x

Notas de OPSEC:

• Criar um objeto COM para Word.Application (ou Excel.Application ..etc), resultará na criação de um WinWord.exe adicional como processo filho de svchost.exe em vez do processo principal WinWord.exe.
• A chave de registro AccessVBOM é modificada/restaurada via COM usando WScript.Shell; usar APIs win32 pode ser uma alternativa melhor.
• Hospedar o CLR usando APIs win32 em VBA é obviamente mais seguro do que atualizar a chave de registro AccessVBOM, deixarei isso para outro dia...
• Outras APIs .NET, como System.CodeDom.Compiler, podem ser usadas para compilar/executar código c# a partir do VBA, consulte a referência abaixo;

Referências:

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