postrequest / dynamic-winapi Goto Github PK

First off, thanks for writing all of these bits in Rust - very handy stuff.
I started a thread in the MSF Mettle repo about this, since with Brent's departure i'm not sure how long MSF's POSIX C payloads will be viable/maintainable, so looking to the future and... Rust is it. Many moons ago, we had a single Meterpreter codebase which was ifdefd to death and eventually with the advent of Mettle by Brent and Adam, we were able to leave meterpreter under OJ's loving guidance for Win-only, and split out to two payload codebases which are feature-related but not exactly in-sync. Mettle uses the same tricks Rust does for multi-target compilation on a small musl toolchain targeting the ABI, making Rust (among tons of other reasons) look like a natural successor which may get new blood into development on MSF.
Ideally, in my potentially mad mind's eye, we could use a Rust-based Mettle to supercede meterpreter as well, restoring a single codebase with build targets and features determining the resulting payload and thus providing a fair amount of entropy to the resulting bin. If we were to go down that path, we'd need a winapi resolver for Railgun, which today is still the same ungodly hack it was a decade ago reading byte-by-byte and having very little payload-side intelligence.
This lib appears to have very similar intentions to what RG was meant to do, but with a much better semantic for sized access and an interpretation of what's read to perform error handling at interface-rate as opposed to C&C channel-rate. Any objections to it being earmarked in my book for that sort of utilization down the line? Figure its better to ask nowadays than just use something based on license to make sure authors know we're not actual bad guys, but people teaching other people how the real bad guys do things.