This is a place to document ideas or projects for EvilVM’s future. Sometimes I implement something that works, but could (or should) be expanded in the future. Or sometimes I’ll be thinking about EvilVM in the shower, and a neat idea occurs to me, but I have no time to work on it. These ideas live here, so they don’t disappear forever.
Implement a payload that functions as a “hypervisor” of sorts, which can spawn compilers in separate threads, and proxy communications between them. This will be the best way, I think, to make it possible for the user to interrupt an infinite loop, stop execution that goes awry, and recover from the worst of errors.
I realized that I can add exception handling easily, but creating a stack of exception restarts, and some handling in the “reset” word so that it can resume execution somewhere other than the standard error handler.
Implement block/retransmit reliability at first; maybe implement a rolling window…
Github user @BEN00262 asked about running EvilVM entirely on Windows. It turns out this might not be too hard to achieve, at least for the vast majority of the system (ICMP shim being the hardest, I think, since it will require some real effort for the server side). Primary hurdles: account for `readline` differences, and make `build.rb` work well on a Windows box with necessary prereqs installed.
After writing the ICMP transport basically as a clone of the HTTP transport, just with a different Win32 calls for the protocol guts, I realized that there is a common shape that can be refactored. The buffering, delay timing, preparing and consuming of data can be abstracted out, and the transports can concern themselves with the protocol-specific details.
The one byte at a time Queue in the server is the predominant source of slowness. And rearranging the code a bit will make it easier to add more semantic output modes (ala the “seeasm” mechanism for disassembling on the server).
I’ve often found it useful in weird situations while pen-testing, and EvilVM can’t be complete without an ICMP tunnel transport!
ICMP transport exists! It’s an unreliable protocol, but the transport does attempt to retransmit appropriately. I’ve had one mysterious failure, but otherwise been able to keep links up for days with it in testing.
Can probably use the ruby_smb project to write the shim.
The ruby_smb library turned out to be awesome, and the named pipe transport seems to be working well in testing.
Current download is hackish. The `seeasm` control code for adding metadata to output could make this much better.
Added ^Kupload command and changed download command so they use alternate streaming support in the server. They should generally work like one would expect now.