yamakadi/clroxideUna libreria Rust che consente di hostare il CLR ed eseguire binari dotnet.
ClrOxide è una libreria Rust che consente di ospitare il CLR ed eseguire dinamicamente binari dotnet.
Volevo chiamarla Kepler senza un motivo particolare, ma esiste già un pacchetto chiamato kepler su cargo. :(
Lavoro a intermittenza sull'hosting del CLR con Rust da 2 anni, e finalmente due settimane fa qualcosa è andato al posto giusto!
Questa libreria non sarebbe possibile senza i seguenti progetti:
winim/clr permette di sovrascrivere il buffer di output per Console.Write e di ottenere l'output! Cercare di raggiungere la stessa eleganza è l'unico motivo per cui questa libreria ha impiegato due anni. Come posso convincere Cas a cimentarsi con Rust se non può replicare tutto questo!? Il mio lavoro per un implant Rust per NimPlant è anche il modo in cui sono finito in questa tana del coniglio.go-clrgo-clr, il progetto dinvoke_rs di Kurosh ha chiarito alcune complessità di rust/win32 e ha permesso al progetto di andare avanti.ClrOxide funziona solo se compilata per x86_64-pc-windows-gnu o x86_64-pc-windows-msvc.
La compilazione per i686-pc-windows-gnu fallisce a causa di problemi noti con l'unwinding dei panic in Rust. Potrebbe funzionare con i686-pc-windows-msvc, ma non l'ho provato personalmente.
Anche se non ho riscontrato questo problema personalmente, potrebbero esserci casi in cui è necessario compilare specificamente l'assembly come x64 invece di Any CPU.
La crate windows non aveva definizioni di tipi per mscoree.dll fino a poche settimane fa. Sembra che le definizioni per mscoree.dll siano arrivate nella crate windows nella versione 0.48.0. Tuttavia, queste definizioni non sembrano funzionare correttamente. Solo per fare un esempio: una voce di vtable che dovrebbe puntare a una funzione all'interno del thread CLR (diciamo all'indirizzo 0x7ffef16821a0), in qualche modo restituisce un indirizzo ampiamente fuori portata (0x750003cac9053b48).
La crate windows fa molte cose elaborate con le vtable per motivi di sicurezza, ma ironicamente sono proprio queste a causare probabilmente la violation di accesso di cui sopra. Oppure sta succedendo qualcos'altro... Avevo intenzione di usare le definizioni ufficiali per la V2 per scaricare l'onere della manutenzione, ma questo è un ostacolo insormontabile.
Puoi trovare altri esempi nella cartella examples/.
ClrOxide caricherà il CLR nel processo corrente, risolverà mscorlib e reindirizzerà l'output di System.Console, infine caricherà ed eseguirà il tuo eseguibile restituendone l'output come stringa.
Lo streaming dell'output non è attualmente supportato, anche se sono sicuro che la magia di manipolazione del CLR usata per reindirizzare l'output possa essere una buona guida per chiunque voglia implementarlo.
use clroxide::clr::Clr;
use std::{env, fs, process::exit};
fn main() -> Result<(), String> {
let (path, args) = prepare_args();
let contents = fs::read(path).expect("Unable to read file");
let mut clr = Clr::new(contents, args)?;
let results = clr.run()?;
println!("[*] Results:\n\n{}", results);
Ok(())
}
fn prepare_args() -> (String, Vec<String>) {
let mut args: Vec<String> = env::args().collect();
if args.len() < 2 {
println!("Please provide a path to a dotnet executable");
exit(1)
}
let mut command_args: Vec<String> = vec![];
if args.len() > 2 {
command_args = args.split_off(2)
}
let path = args[1].clone();
println!("[+] Running `{}` with given args: {:?}", path, command_args);
return (path, command_args);
}
Puoi aggiornare il contesto per usare un dominio applicativo personalizzato. Questo può essere utile se vuoi evitare DefaultDomain. Consulta examples/custom_app_domain.rs per maggiori dettagli.
...
let app_domain = clr.using_runtime_host(|host| {
let app_domain = unsafe { (*host).create_domain("CustomDomain")? };
Ok(app_domain)
})?;
clr.use_app_domain(app_domain)?;
...
mscoree.dllDobbiamo caricare la funzione CreateInterface da mscoree.dll per avviare il CLR. Puoi fornire un loader personalizzato disabilitando le funzionalità predefinite.
Prima di tutto, aggiungi default-features = false alla dichiarazione della dipendenza.
clroxide = { version = "1.0.6", default-features = false }
E poi fornisci una funzione con firma fn() -> Result<isize, String> che restituisca un puntatore alla funzione CreateInterface quando crei l'istanza di Clr.
litcrypt::use_litcrypt!();
fn load_function() -> Result<isize, String> {
let library = custom_load_library_a(lc!("mscoree.dll\0"));
if library == 0 {
return Err("Failed".into());
}
let function = custom_get_process_address(library, lc!("CreateInterface\0"));
if function == 0 {
return Err("Failed".into());
}
Ok(function)
}
fn main() -> Result<(), String> {
// ...
let mut context = Clr::new(contents, args, load_function)?;
// ...
}
System.Environment.Exit per non uscire
Puoi usare i mattoni forniti da ClrOxide per applicare una patch a System.Environment.Exit come descritto in Massaging your CLR: Preventing Environment.Exit in In-Process .NET Assemblies di MDSec.
Puoi consultare l'implementazione di riferimento in examples/patch_exit.rs. Poiché questo richiede l'uso di VirtualProtect o NtProtectVirtualMemory, non ho intenzione di aggiungerlo come funzionalità a ClrOxide.