THIS IS A SUPER ALPHA VERSION!!!
This is a Rust version of XMT that attempts to 1-to-1 feature match the Golang version. (Some caveats apply)
Currently this library isn't publushed into crates.io and won't be until we reach
a quasi-stable state. This repo is currently used for building and testing, which
is why we're using main.rs instead of lib.rs. The main.rs is structured for
compatibility between nix and Windows (CRT and MSVC).
Feature wise, most of the Rust "std emulation" features work completely and well.
The next steps are making the "C2" part work. Right now we can just send Oneshot
packets (should be the example in the main.rs file).
Currently I'm planning on next:
- Profiles support
- Tasking
- Sessions!!
These will happen sometime AFTER DEFCON31!
- The Capabilities flag that XrMT implants report will carry a special "Rust" (0x40000) flag that will be used to differentiate implant build types.
- Windows DLL Loader
- Loads ntdll.dll directly from PEB
- Only uses Hash/FNV32 loading of DLL functions.
- Funcmap support is enabled by default and cannot be disabled. (Implants always carry this capability flag).
- Windows implants built with the
piefeature flag have no imports.
- State of certain
constandvarobjects from Go are no longer Globally mapped.- An example would be the
device.Shellconstant is nowdevice::shell().
- An example would be the
- All function names (minus WinAPI names) use the Rust snake_case naming schema.
- Many Windows functions that were
kernel32oradvapi32in Golang have been converted to their respectiventdllcalls in Rust to remove more dependencies. - Yes, we are compatible all the way back to Windows XP SP0. (I tested it!)
- Crypt support is not complete and will be different than the Golang version! (ie: They won't be compatible).
ALL XrMT BUILDS REQUIRE THE NIGHTLY CARGO VERSIONS!!
Just cargo +nightly build lol.
The Windows builds should be build using the x86_64-pc-windows-msvc or
i686-pc-windows-msvc targets. This can be accomplisted on *nix by installing
clang, lld and using the msvc-wine
repository.
It is recommended to use msvc targets over gnu as this will prevent the Microsoft
C-Runtime library from being included. If you build using GNU you will loose
Windows Xp Compatibility!
The Windows version does not use the Rust standard library (std) and instead uses
core and alloc. This is combined with the "abridged" std library stx and device
which emulate most of the features for thread, env, sync, sync/mpsc (I'm so
proud of this one), fs,
process and net. (See Library Mappings for more into).
The Windows version also includes it's own Heap Allocator!
Most mappings will transparently redirect on the XrMT side, meaning you can drop-in replace code and cross-compile without any issues!
If you really want to use std with Windows, enable it with the std feature flag.
| std | xrmt |
|---|---|
| std/io | xrmt::util::stx::io |
| std/fs | xrmt::device::fs |
| std/env | xrmt::device::env |
| std/sync | xrmt::sync |
| std/thread | xrmt::thread |
| std/net | xrmt::net |
| std/process | xrmt::process |
| std/ffi | xrmt::util::stx::ffi |
| std/path | xrmt::util::stx::ffi (path & ffi are combined) |
| std/preclude | xrmt::util::stx::preclude (uses 2021 preclude) |
- Solaris
- Can't get the Mac Address for some reason. The OS does not give it to us.
- Not possible to determine threads for processes.
- MacOS
- No thread support. We can do it, but you have to have a signed binary with a special permission set to read other processes's threads
- NetBSD
- Thread support works, but it's not super stable as the way it indicates Threads is kina weird. THey don't have TIDs but can be enumerated at least
