Remove windows build support

[adfoster-r7]

Placeholder ticket to decide if we want to remove windows build support from Mettle.

At the minute the Windows support isn't fully implemented, and we're currently paying the maintenance cost for windows support when CI builds break - but it's not functionality that the average user is aware of. The support mettle process creation on windows doesn't seem quite right for instance

Do we want to remove this functionality and declare that Mettle is not intended to support windows?

[adfoster-r7]

@sempervictus Are you currently using mettle on Windows at all?

[zeroSteiner]

Four of my last 5 PRs broke the build or had to dance around it with the precompiler.

• https://github.com/rapid7/mettle/pull/230/files#diff-10d3a8489fe9a5b40b9ddbf28d041fd6e0dc4cd85ec9585dbc6c68394321d39f
• https://github.com/rapid7/mettle/pull/228/files
• Only return the username for getuid #225 (comment)
• Update Linux Process Names #216 (comment)

It was also an issue on this PR from a community member I reviewed: #243 (comment)

We also have two open issues regarding the MinGW builds:

• Failing to build for Windows targets due to libcurl redefinition #208
• win32 build needs a replacement for libpcap #101

[sempervictus]

This has actually been a very useful feature over the years - windows EDRs have no idea what this is :).
Given that we have a windows meterp, and that this code is not in active development, i could see cause to drop the support if its adding burden to an already "red headed" project. However, i have found significant utility from this in the past and from a functional perspective vote to keep it in. Personally, id be inclined to mark the test cases inert and throw some words in the readme to users who might have time/talent to contribute to making it work properly. Call it "tier 2 supported target" and put out a call for contributors to make it tier1 since the alternative is to ask R7 for resources to apply to this somewhat esoteric use case (and there are bigger fish to fry if making such asks, IMO).

Long term, i have a "re-consolidate meterp on Rust" effort on my TODO list - C is pretty much dead, IMO we need a modern language base to attact new talent/interest, and Rust provides a great set of mechanisms by which to do x-platform work in a single repo (hell, we can write payloads targeting things without vmem/alloc). Plus, we need clean-sheet. My meterp is unrecognizable at this point, and the functionality in there should be implemented from the gorund up, correctly, not like the garbage truck parking job we did in a parking space meant for a sub-compact 🙄. NIM looked for at time like it might serve the purpose, but i dont see its longevity or momentum toward maturity competing w/ Rust at this point...

[adfoster-r7]

i have a "re-consolidate meterp on Rust" effort on my TODO list

I have a Rust Meterpreter PoC working from a year ago; but I'm not sure if we'd want the maintenance overhead of another Meterpreter that doesn't quite have the same semantics as the other implementations

[sempervictus]

I think the push to Rust would actually ease maintenance - all the cool kids are learning that these days, not C.
Clean-sheet implementation at current state of industry should give you something like a Brute Rattel (switching semantcs from syscalls+ROP to WinAPI calls with and without ROP on the fly, mem obfu, unhooking, built & runtime obfuscation, etc), allow us to re-think how session state is managed to handle C2+ better, and eventually deprecate the C versions (though, IIRC Adam's point regarding the payload size of a Rust meterp compared to Mettle's still stands - Rust's runtime does bring in some overhead so a nostd approach might be the way to go, and that's a "ground-up" decision to be made).

Any chance you might be able to publish whatever you've got? Would make a hell of a springboard for a GSoC effort or tinker-toy for payload writers to expand upon in copious "spare" time 😄.

[Ishaanahuja7]

@adfoster-r7 I agree with @sempervictus If you could publish the code in a repo somewhere, the community can help achieve a working rust meterpreter faster since number of rust developers are growing exponentially faster than C/C++ developers now + its become a somewhat faster and cleaner alternative to C/C++ nowadays (Look at ripgrep and fd).