#reversing

Abusing undocumented features to spoof PE section headers https://secret.club/2023/06/05/spoof-pe-sections.html | https://lobste.rs/s/sfvqfs #reversing #security #windows

Cindʎ Xiao :breathe:

22 hours ago

@dzervas The decompiler in all of the screenshots in this thread is @binaryninja !

There are a few additional things which make the decompilation look nicer here:

The Microsoft symbol servers provide symbols for these Rust binaries too; those have been downloaded and applied (automatically by Binary Ninja; IDA and Ghidra should also just do this automatically) to this binary.
The symbols have additionally been demangled by me, just using this plugin: https://github.com/inspier/BinjaRustDemangler

On top of that I have applied some additional type information, renamed variables and fields, etc. In general having symbols makes it a lot easier though!

The actual binaries I'm looking at are also available for download from the Microsoft Symbol Server, if you wanted to take a look at the binaries for yourself too; you can get them easily from there without needing an insider preview build of Windows. Details at https://infosec.exchange/@cxiao/110360594370994764

#rust #rustlang #reversing #reverseengineering #microsoft #windows #binaryninja

Cindʎ Xiao :breathe:

1 day ago

Finally, here's what's actually inside that custom panic handler function seh_unwind::implementation::raise_exception: setting up an EXCEPTION_RECORD structure using the information provided by Rust's panic implementation up to here, then calling RtlRaiseExceptionwith that EXCEPTION_RECORDpassed in.

#rust #rustlang #windows #microsoft #reversing #reverseengineering

$A screenshot of the decompilation of the function `seh_unwind::implementation::raise_exception`, with the following code contents: ``` int64_t seh_unwind::implementation::raise_exception::hc52a1220c03bdc19(int32_t exception_code, char* exception_message, int64_t exception_NumberParameters) __noreturn { int32_t var_ac = exception_code; int32_t status_code_ = win_defs::ntstatus::NTSTATUSError::status::h71e417d20a1a2c45(&var_ac); struct EXCEPTION_RECORD exception_record; __builtin_memset(&exception_record.ExceptionInformation, 0, 0x78); exception_record.ExceptionCode = status_code_; exception_record.ExceptionFlags = 0; exception_record.ExceptionRecord = 0; exception_record.ExceptionAddress = 0; *(uint32_t*)((char*)exception_record.ExceptionAddress)[4] = 0; exception_record.NumberParameters = exception_NumberParameters; int64_t* exception_info_ptr; int64_t exception_info_len; exception_info_ptr = core::slice::index::impl$4::index_mut<usize>(exception_NumberParameters, &exception_record.ExceptionInformation); core::slice::<impl [T]>::copy_from_slice::h17325824e865690e(exception_info_ptr, exception_info_len, exception_message, exception_NumberParameters, &str_"seh_unwind\src\lib.rs"); RtlRaiseException(&exception_record); trap(6); // ud2 instruction (invalid opcode panic) } ```$

Cindʎ Xiao :breathe:

1 day ago

The rust_begin_unwind function - more specifically, the rust_begin_unwind symbol - is a bit special. It is actually a symbol that the panic implementation in Rust's core library (specifically, the panic_impl function) expects to be resolved at link time, for any binary which doesn't just unconditionally abort upon panic: https://rustc-dev-guide.rust-lang.org/panic-implementation.html#core-definition-of-panic

For binaries which are using Rust's standard library, rust_begin_unwind normally just links against an implementation in the standard library (begin_panic_handler, in library/std/src/panicking.rs)

However, the Windows kernel code here is not using Rust's standard library - it has to be this way, because Rust's standard library assumes that it's running in an environment where an operating system is present underneath it to give it nice abstractions, which is clearly not the case here as the code is implementing part of the Windows operating system...

Rust programs which do not use the standard library are built with the attribute #[no_std], which means that they link against Rust's core library only, rather than both the core library and std library. The core library only provides a very limited set of APIs, does not do heap allocations, and makes no assumptions that your code is running on top of an operating system.

In this case, because the implementation of rust_begin_unwind doesn't have an implementation that the Rust core library can link against, the programmer must either provide one, or change the panic strategy to abort on panic instead (i.e. set panic = "abort" in Cargo.toml).

Luckily, other code in the kernel provides some facilities for handling and recording exceptions, via RtlRaiseException, so the code here can provide an implementation which calls that (via the wrapper function seh_unwind::implementation::raise_exception, which AFAIK is not part of any public crate)

The Rust Embedonomicon book, which is about writing Rust for embedded systems and similar restricted environments, has a chapter called "The smallest #![no_std] program" which explains this in a bit more detail, including the requirement for a panic handler implementation: https://docs.rust-embedded.org/embedonomicon/smallest-no-std.html

#rust #rustlang #windows #microsoft #reversing #reverseengineering

Cindʎ Xiao :breathe:

1 day ago

The Rust code in the new win32kbase_rs.sys in the Windows Kernel can also panic. What happens when it does?

There are several places where a panic is invoked in the code - they include bounds check failures (core::panicking::panic_bounds_check), indexing into a slice outside of the length of that slice (core::slice::index::slice_start_index_len_fail_rt), and assertion failures (core::panicking::assert_failed). These all eventually take a common code path through the following series of function calls:

core::panicking::panic_fmt::hd60a775b92204b91
-> rust_begin_unwind
--> seh_unwind::implementation::raise_exception::hc52a1220c03bdc19

This calls into a custom panic handler, seh_unwind::implementation::raise_exception, which calls RtlRaiseException, imported from the main ntoskrnl binary!

#rust #rustlang #windows #microsoft #reversing #reverseengineering