Hacking VBA to support native scripting runtime with no COM dependencies | Hacker News Reader

Hacking VBA to support native scripting runtime with no COM dependencies

github.com

24 pointsn01310 comments

Open articleView on HN

This will be really useful for my coworkers who get stuck in SCIFs with nothing but Excel available to them.

Also: https://github.com/PerditionC/VBAChromeDevProtocol

VBA (Excel) based wrapper for Chrome Developer Protocol (CDP) - sorta a VBA version of Puppeteer/Selenium

Friendly reminder for MS Access fiends:

It's ok to store code in tables and then pass it to VBA for evaluation via Eval, or to ASF via the engine.Compile

But what if i want to debug my code?

Great question! Programmatically copy your snippet to a module, then call it:

Public Sub AppendCode() Dim cm As Object Set cm = Application.VBE.VBProjects(1).VBComponents("GeneratedLogic").CodeModule

    cm.InsertLines cm.CountOfLines + 1, _
        "Public Sub NewProc()" & vbCrLf & _
        "    MsgBox ""Dynamically added""" & vbCrLf & _
        "End Sub"

End Sub

I've written my fair share of evil shit in VBA.

But... what is effectively eval() just in VB? Yikes.

For the people who would be using this, they would almost never even have other people's code, say nothing of whether it's untrusted.

Honestly, ASF is literally sandboxed. Objects cannot be injected in the runtime. Also, VBA Expressions is intentionally limited to receive and return VBA strings. So, the system is safe for execute code from (almost) anyone.

You can inspect the AST in order to debug your code. For syntax highlighting, use tools like Notepad++ (ASF shares most of the syntax with Javascript). Each piece of code is commented, no obscure machine code.

This looks so useful.

Reply on news.ycombinator.com