Reversing Akira's Rust Experiment: A Breakdown, Part 3

2026-05-27T00:00:00+00:00

This post is a breakdown and commentary on Ben Herzog’s Check Point Research (December 2024), Inside Akira Ransomware’s Rust Experiment</a> & his talk in 2025</a>. All technical claims are grounded in the linked primary sources below. Combined with some methodologies of Cindy Xiao’s amazing reports/talks in 2024</a>, 2025</a> (mainly for reconstructing types). </blockquote>


If you haven’t read Part 1</a> and Part 2, it’s encouraged to read the threat reports at least (see References — Threat Reports below), so the activities of the binary are clear alongside the binary analysis, including the latest Tactics, Techniques, and Procedures (TTPs). </blockquote>
Table of Contents</h2>
Info of the binary in this analysis</li>
Section 5: lock and Thread Spawning</li>
Section 6: Lock_Closure and Encryption</li> </ul>
Further Reading</h3>

Why UAWAVAUATSH exists</li> </ol> </li>

REX — Register Extension.</li> </ol> </li>

Mutex</li> </ol> </li> </ul>
References</h3>
Reversing Akira’s Rust Experiment: A Breakdown Part 1</h2>

This post is a breakdown and commentary on Ben Herzog’s Check Point Research (December 2024), Inside Akira Ransomware’s Rust Experiment</a> & his talk in 2025</a>. All technical claims are grounded in the linked primary sources below. Combined with Cindy Xiao’s amazing reports/talks in 2024</a>, 2025</a> (about reconstructing types and more). </blockquote>
There will be a part 2 to break down the rest. I separate them so this article won’t be _too_long_.

For this analysis, Binary Ninja (v5.3.9434) is used without enabling any plugins. Binary: akirav2.elf , SHA25:60ee1d284ed663073872012c7bde7fac5ca1121403f1a5d2d5411317df282796c.
A note on source references</h3>

The commit hash is updated on 10th Jun 2026. 79e9716c… is rustc 1.74.0 stable (released 2023-11-16). Akirav2’s .rodata contains std panic-path strings of the form /rustc//library/....db034cee… is a master/nightly commit from ~1 year later, which I was mistakenly pinned in the article. If you see any links related to db034cee… , please consider it was based on previosu wrong assumption but it works to some degree. </blockquote>
The Rust standard library is under active development and files move between releases. Source links in this post are pinned to commit 79e9716c980570bfd1f666e3b16ac583f0168962 — rustc 1.74.0 stable</a>, the toolchain that compiled this Akira v2 binary. This is recoverable directly from the binary: its .rodata embeds /rustc/79e9716c…/library/... panic paths, and it is corroborated by version-pinned FunctionID analysis resolving the sample to 1.74.0.
This matters because stdlib code is inlined directly into the final binary at compile time: what you see in the disassembly reflects the stdlib at that specific commit, not the current main branch. Following a newer version of the same file risks misidentifying inlined boilerplate or drawing incorrect conclusions about what the malware authors wrote versus what the compiler contributed.
If a pinned link returns a 404, the file has likely been relocated. Navigate to the repository root</a> and search by filename. </blockquote>
Section 5: lock and Thread Spawning</h2>
After flag processing, default_action calls lock, which is a thin wrapper. Its job is to spawn threads worker threads, each running lock_closure, and then join them. The structure mirrors yarnish.rs almost exactly, with the indicatif MultiProgress handle passed into each thread via Arc.
lock</code>" loading="lazy" decoding="async" />
Xref panel of `lock`
This binary is a bit different from the CheckPoint report</a> that I didn’t find tick_chars(“⠁⠂⠄⡀⢀⠠⠐⠈ “) . Instead, it showed up as UTF-8 encoding.
If you check the source code of yarnish.rs :
pub fn main() { let mut rng = rand::rng(); let started = Instant::now(); let spinner_style = ProgressStyle::with_template("{prefix:.bold.dim} {spinner} {wide_msg}") .unwrap() .tick_chars("⠁⠂⠄⡀⢀⠠⠐⠈ "); </code></pre> In .rodata section, all the strings are combined without null-terminator default_action</code>, the structure is clearer with the string slice" loading="lazy" decoding="async" /> In `default_action`, the structure is clearer with the string slice If you check the disassembly of default_action , you can see the pattern of source code yarnish.rs aligned in order. Where are the tick_chars ? The real situation
The tick_chars("⠁⠂⠄⡀⢀⠠⠐⠈ ") call is compiled in, but the Braille</a> spinner string is what is not finding. The figure above shows .rodata at 0x4414eb containing e2 a0 81 e2 a0 82 e2 a0 84 e2 a1 80 e2-a2 80 e2 a0 a0 e2 a0 90 followed by e2 a0 88 20 at 0x441500.
Decoding those as UTF-8:
e2 a0 81 = ⠁ (U+2801) e2 a0 82 = ⠂ (U+2802) e2 a0 84 = ⠄ (U+2804) e2 a1 80 = ⡀ (U+2840) e2 a2 80 = ⢀ (U+2880) e2 a0 a0 = ⠠ (U+2820) e2 a0 90 = ⠐ (U+2810) e2 a0 88 = ⠈ (U+2808) 20 = (space) </code></pre> That is exactly "⠁⠂⠄⡀⢀⠠⠐⠈ ", the tick string from yarnish.rs, present verbatim in .rodata. Binary Ninja has labelled this region data_4414eb and is rendering the bytes as literal dots rather than recognising the Braille Unicode. The string is there; it is a display/encoding issue in how Binary Ninja is showing that .rodata range. For yarnish.rs reconstruction The tick_chars call and its argument string are both present in the binary. Your reconstructed source should include .tick_chars("⠁⠂⠄⡀⢀⠠⠐⠈ "). The chain is with_template(...).unwrap().tick_chars(...), matching yarnish.rs exactly.

RE relevance: this is a clean example of a Unicode string literal surviving into .rodata with full fidelity, recoverable by UTF-8 decoding of the raw hex even when the decompiler renders it as garbage. Worth noting as a corpus evidence tier (.rodata string recovery) in your detection pipeline. </blockquote>
Reconstructing the lock function</h2>
Before beginning reconstruction, the build environment is fixed from binary evidence. </blockquote>

The source file for lock is confirmed as akiranew/src/lock.rs from the .data.rel.ro log format metadata at 0x5e7028:
"akiranew/src/lock.rs#>- File crypting... File lock started: , thread id: ..." </code></pre> The Graphic Overview of lock</h2> The yarnish.rs template</h2> The structural origin of lock is based onindicatif's</a> yarnish.rs example</a>. The relevant section is: let handles: Vec<_> = (0..4u32) .map(|i| { let count = rng.random_range(30..80); let pb = m.add(ProgressBar::new(count)); pb.set_style(spinner_style.clone()); pb.set_prefix(format!("[{}/?]", i + 1)); thread::spawn(move || { // ... work ... pb.finish_with_message("waiting..."); }) }) .collect(); for h in handles { let _ = h.join(); } m.clear().unwrap(); </code></pre> The Akira authors adopted this skeleton and replaced the dummy work body with encryption logic, the fixed range (0..4u32) with an iterator over the file list, and the thread count with a runtime semaphore. The differences are documented in each step below. Step 1 — Function prologue and argument layout</h2> Address range: 0x4d38a5 -- 0x4d38d2 push rbp, r15, r14, r13, r12, rbx sub rsp, 0x2a8 </code></pre> The frame size is 0x2a8 (680 bytes). Six callee-saved registers are preserved, consistent with a function that holds many live values across multiple call sites. The following comments are based on Checkpoint report, if you was investigating without reviewing it, you will see more clues later. int64_t* akira_v2::lock::lock( int64_t* arg1, // Vec<PathBuf> -- the file list int64_t arg2, // thread limit (u64) char* arg3, // exclude regex (*const u8) int64_t* arg4 // operator options struct ) </code></pre> The compiler saves the incoming registers to the stack immediately after the prologue. The System V AMD64 ABI, which governs all Linux x86–64 binaries including akirav2.elf, specifies that the first six integer or pointer arguments are passed in registers rdi, rsi, rdx, rcx, r8, r9 in that order (x86-psABIs project, 2024, §3.2.3). The authoritative primary source is the System V Application Binary Interface AMD64 Architecture Processor Supplement</a>, version 1.0. Maintained at with the compiled PDF at github.com/hjl-tools/x86-psABI/wiki/x86–64-psABI-1.0.pdf</a>, section 3.2.3, Figure 3.4 (register usage table: %rdi = 1st argument, %rsi = 2nd, %rdx = 3rd, %rcx = 4th). </blockquote> The save sequence in the binary is: mov r12, rdi ; r12 = arg1 (rdi) mov qword [rsp+0x188 {var_150}], rsi ; var_150 = arg2 (rsi) mov qword [rsp+0x38 {var_2a0}], rdx ; var_2a0 = arg3 (rdx) mov qword [rsp+0x40 {var_298}], rcx ; var_298 = arg4 (rcx) </code></pre> The compiler does not save in ABI order, it schedules saves however suits instruction throughput. The mapping from ABI position to stack slot must be read from the registers, not from the order of the mov instructions. arg1 is Vec confirmed from the later imul rcx, [r12+0x10], 0x18 (capacity * 24, where 24 = sizeof(PathBuf) = ptr + len + cap = 3 × 8 bytes). </blockquote> The semantic labels for arg2 (rsi / var_150), arg3 (rdx / var_2a0), and arg4 (rcx / var_298) are training-derived, which of these holds the thread limit, the exclude regex pointer, and the operator options struct requires tracing the read sites of each stack variable through the function body. Binary Ninja's resolved signature labels them arg2: int64_t, arg3: char*, arg4: int64_t*, but the semantic assignment cannot be confirmed from the prologue alone. Step 2 — ProgressStyle initialisation</h2> Address range: 0x4d38cb -- 0x4d390c This is the direct binary equivalent of yarnish.rs: let spinner_style = ProgressStyle::with_template("...").unwrap().tick_chars("..."); </code></pre> lea rsi, [rel data_441490[0x24]] ; template string in .rodata lea r15, [rsp+0x100 {var_1d8}] ; destination on stack push 0x37 / pop rdx ; template length = 55 bytes mov rdi, r15 call indicatif::style::ProgressStyle::with_template ; 0x4d38e0 </code></pre> The with_template call returns Result<ProgressStyle, TemplateError>. The Result-returning signature confirms indicatif >= 0.17.0 (versions prior to 0.17 returned ProgressStyle directly). The .rodata panic path confirms 0.17.7 exactly. call core::result::Result::unwrap ; 0x4d38f4 call indicatif::style::ProgressStyle::tick_chars ; 0x4d3904 </code></pre> The completed ProgressStyle lives in r15 / var_1d8 for the duration of the function. Step 3 — MultiProgress and Arc allocation</h2> Address range: 0x4d390c -- 0x4d3951 Two consecutive exchange_malloc calls allocate the MultiProgress and its internal shared state. Both follow the same Arc field initialisation pattern: call alloc::alloc::exchange_malloc ; size=0x8, align=0x8 (first call) mov qword [rax], r13 {0x1} ; ArcInner.strong = 1 mov qword [rax+0x8], r13 {0x1} ; ArcInner.weak = 1 and dword [rax+0x10], 0x0 ; ArcInner.data zeroed </code></pre> The field offsets are Verified from the pinned stdlib source at library/alloc/src/sync.rs</a>. ArcInner is declared #[repr(C)], which guarantees field order matches declaration order. The fields in source order are: #[repr(C)] struct ArcInner<T: ?Sized> { strong: atomic::AtomicUsize, // +0x00, 8 bytes on x86-64 weak: atomic::AtomicUsize, // +0x08, 8 bytes on x86-64 data: T, // +0x10 (for T with align <= 8) } </code></pre> Arc::new initialises both counts to 1, confirmed in the same source file: let x: Box<_> = Box::new(ArcInner { strong: atomic::AtomicUsize::new(1), weak: atomic::AtomicUsize::new(1), data, }); </code></pre> The #[repr(C)] annotation is load-bearing: without it, Rust's default repr(Rust) would permit field re-ordering and the offset claim would not be verifiable from source inspection alone. call alloc::alloc::exchange_malloc ; size=0x30, align=0x8 (second call) ; same initialisation pattern, larger payload </code></pre> The 48-byte second allocation is the MultiProgress inner state. These correspond to MultiProgress::new() in yarnish.rs. No MultiProgress::new symbol survives in the binary because the constructor is fully inlined. Step 4 — File iterator construction</h2> Address range: 0x4d397d -- 0x4d39b0 This is the single most important structural divergence from yarnish.rs. The yarnish.rs example iterates (0..4u32) which is a fixed range. Akira iterates the file list directly: mov rax, qword [r12] ; rax = files.ptr mov rdx, qword [r12+0x8] ; rdx = files.len imul rcx, qword [r12+0x10], 0x18 ; rcx = files.cap * 24 add rcx, rax ; rcx = end pointer (ptr + cap*stride) mov qword [r15 {var_1d8}], rax ; IntoIter.buf = ptr mov qword [r15+0x8 {var_1d0}], rdx ; IntoIter.len = len mov qword [r15+0x10 {var_1c8}], rax ; IntoIter.start = ptr mov qword [r15+0x18 {i_1}], rcx ; IntoIter.end = end ptr </code></pre> The imul multiplier 0x18 (24) equals sizeof(PathBuf) on x86-64: PathBuf = Vec = (ptr: *mut u8, len: usize, cap: usize) = 3 × 8 = 24 bytes. This construction is the IntoIter struct being built on the stack. Loop head at 0x4d39b0: cmp rax, rcx ; current_ptr == end_ptr? je 0x4d3a22 ; yes → drop IntoIter and exit </code></pre> Loop exit at 0x4d3a22: call _$LTalloc..vec..into_it...op..Drop$GT$::drop </code></pre> The IntoIter destructor runs when the file list is exhausted. This is the outer boundary of the entire map(...).collect() equivalent. Step 5 — Per-iteration seed generation (Akira-specific)</h2> Address range: 0x4d3c69 -- 0x4d3d1c There is no equivalent in yarnish.rs. This block is unique to Akira. SystemTime::now and duration_since(symbol names read directly from disassembly). Signatures are defined in the pinned stdlib at library/std/src/time.rs</a>. SystemTime::now() returns the current wall-clock time. SystemTime::duration_since returns Result<Duration, SystemTimeError>; the jne 0x4d42de at 0x4d3c82 is the error branch for the SystemTimeError case (time went backwards). call std::time::SystemTime::now ; 0x4d3c69 -- Verified mov qword [rsp+0x50 {var_288}], rax ; store seconds mov dword [rsp+0x58 {var_280_1}], edx ; store subsec_nanos mov rdi, r12 {var_1d8} mov rsi, r13 {var_288} call std::time::SystemTime::duration_since ; 0x4d3c7d -- Verified cmp qword [rsp+0x100 {var_1d8}], 0x0 jne 0x4d42de ; error path </code></pre> getpid(symbol name read directly from disassembly). getpid() is a POSIX system call returning the calling process's PID as pid_t (a 32-bit integer on Linux x86-64), returned in eax (Linux man page: getpid(2)</a>). call qword [rel getpid] ; 0x4d3c99 -- Verified mov dword [rsp+0x98 {var_240_1}], eax ; pid stored as u32 mov byte [rsp+0xa8 {var_230_1}], 0x1 mov qword [rsp+0x9c {var_23c_1}], 0xde ; constant -- see note below and dword [rsp+0xa4 {var_234_1}], 0x0 </code></pre> Note on 0xde: the constant at +0x9c is binary-observed. Its semantic meaning whether it is a version tag, a seed format discriminant, or an unrelated constant is unknown and cannot be determined without source code for akiranew. </blockquote> HashStruct::hash (mangled symbol name read from disassembly). This is an internal function in the akiranew workspace crate; no public source is available. The 64-byte output size is hand-calculated from the four consecutive movups instructions each loading 16 bytes (4 × 16 = 64): call akira_v2::prng::HashStruct::hash::h869e36ed471afafc ; 0x4d3ce0 -- Verified (symbol) movups xmm0, xmmword [rsp+0x50 {var_288}] ; bytes 0-15 -- Hand-calculated movups xmm1, xmmword [rsp+0x60 {var_278}] ; bytes 16-31 movups xmm2, xmmword [rsp+0x90 {var_248_1}] ; bytes 32-47 movups xmm3, xmmword [rsp+0xa0 {var_23c_1+0x4}] ; bytes 48-63 </code></pre> The interpretation of these 64 bytes as encryption key material is functional inference, the output is passed into the closure capture struct (Step 8) and ultimately into lock_closure, but the claim that it constitutes a key rather than, say, an IV or a nonce requires further analysis of lock_closure to confirm. Log string evidence (binary-observed from .data.rel.ro at data_5e7018 / 0x5e7018): the string "File crypting... File lock started: , thread id: ..." is emitted from akiranew/src/lock.rs and references a thread ID, consistent with getpid() being used to identify threads. This is corroborating evidence, not proof of the key derivation mechanism. Step 6 — ProgressBar construction and MultiProgress::add</h2> Address range: 0x4d3d29 -- 0x4d3d83 call alloc::alloc::exchange_malloc ; size=0x58 (88 bytes) -- ProgressBar Arc mov qword [rax], r15 {0x1} ; strong = 1 mov qword [rax+0x8], r15 {0x1} ; weak = 1 and dword [rax+0x10], 0x0 mov byte [rax+0x14], 0x0 lea rdi, [rax+0x15] </code></pre> push 0x43 / pop rdx {0x43} ; length = 67 -- the file path string length call qword [rel data_611b10] {memcpy} ; copy file path into ProgressBar prefix </code></pre> The file path (67 bytes) is copied directly into the ProgressBar internal buffer. In yarnish.rs, the prefix is format!("[{}/?]", i + 1). In Akira, it is the target file path, giving the operator a live view of which file is being encrypted on each progress bar line. call indicatif::draw_target::...DrawTarget::stderr ; 0x4d3d65 call indicatif::progress_bar::...::with_draw_target ; 0x4d3d73 call indicatif::multi::MultiProgress::add ; 0x4d3d83 </code></pre> This is let pb = m.add(ProgressBar::new(count)) from yarnish.rs, expanded into three calls because ProgressBar::new and the draw target setup are not merged by the compiler at this optimisation level. The result (the managed ProgressBar) is held in r13 / var_288. Step 7 — Shared mutex and thread-limit semaphore</h2> Address range: 0x4d3d91 -- 0x4d3dab Mutex::lock and Result::unwrap</h3> The source for Mutex::lock at the pinned commit is at library/std/src/sync/mutex.rs</a> . </blockquote> call std::sync::mutex::Mutex<T>::lock ; 0x4d3d91 -- Verified call core::result::Result::unwrap ; 0x4d3da3 -- Verified </code></pre> The mutex at data_5ebe00 is a static object in .data.rel.ro. The claim that it is distinct from the MultiProgress internal mutex is a functional inference based on two different static addresses appearing at two different mutex call sites in the disassembly. What data_5ebe00 actually guards requires tracing its read sites, the thread-limit interpretation is not binary-confirmed. Further into the loop body: call std::thread::scoped::Sco...um_running_threads::hb34fb126c362d0f3 ; 0x4d4062 </code></pre> std::thread::scoped::Scope::num_running_threads.</h3> The function lives inside ScopeData in library/std/src/thread/scoped.rs</a>: </blockquote> pub(super) struct ScopeData { num_running_threads: Atomic<usize>, a_thread_panicked: Atomic<bool>, main_thread: Thread, } </code></pre> Scoped threads were stabilised at Rust 1.63.0, confirmed by the #[stable(feature = "scoped_threads", since = "1.63.0")] attribute visible in the same source file. The toolchain used to compile akirav2.elf is nightly-2024-10-06, which is well past 1.63, so the stable API is available. The claim that num_running_threads is used as a semaphore enforcing arg2 as a thread limit is functional inference, the observation is that num_running_threads is called before Thread::new in the loop body, which is consistent with a throttle. The exact blocking mechanism (whether the loop spins, parks, or uses a condition variable, A.K.A. condvar) requires further disassembly of the code between 0x4d4062 and 0x4d3e7e. Step 8 — Closure capture struct construction</h2> Address range: 0x4d406d -- 0x4d40a0 r13</code>" loading="lazy" decoding="async" /> Review `r13` exchange_malloc size and alignment: call alloc::alloc::exchange_malloc ; size=0x58 (88 bytes), align=0x8 </code></pre> The field mapping for closure fields +0x00, +0x08, +0x10 is therefore: +0x00 r14 -- (ptr-sized value) +0x08 rbx -- (ptr-sized value) +0x10 r13 -- output_capture: Option<Arc<Mutex<Vec<u8>>>> (return value of set_output_capture at 0x4d4026) +0x18 xmm0 -- 16 bytes from HashStruct::hash output +0x28 rcx -- pointer (var_268) +0x30 rcx -- pointer (var_2b0) +0x38 rcx -- pointer (var_148_1) </code></pre> +0x10 resolved: At 0x4d4026, r13 is assigned the return value of std::io::stdio::set_output_capture, which returns Option<Arc<Mutex<Vec>>>, the previous stdout capture handle. The test rax, rax / je 0x4d403e / lock inc qword [r13] sequence immediately after (binary-observed) is the Option handling: if Some, bump the refcount; if None, skip. This matches the output_capture variable captured by the main shim closure in the verified thread.rs source at the pinned commit: crate::io::set_output_capture(output_capture); </code></pre> PathBuf layout</h3> The layout of PathBuf on x86_64-unknown-linux-gnu at the pinned commit is (ptr, len, cap) = 3 × 8 = 24 bytes. The proof chain is: PathBuf { inner: OsString } → OsString { inner: Buf } → #[repr(transparent)] pub struct Buf { pub inner: Vec<u8> } → Vec<u8> = (ptr: *mut u8, len: usize, cap: usize) </code></pre> PathBuf { inner: OsString } (single-field, library/std/src/path.rs</a>)</li> OsString { inner: Buf } (single-field, library/std/src/ffi/os_str.rs</a>)</li> #[repr(transparent)] pub struct Buf { pub inner: Vec } (Verified from library/std/src/sys/os_str/bytes.rs</a>)</li> Vec = (ptr: *mut u8, len: usize, cap: usize) = 3 × 8 = 24 bytes.</li> </ul> The #[repr(transparent)] on Buf is the load-bearing guarantee: it makes the Vec equivalence a language specification rather than a compiler implementation detail. The two outer single-field structs (PathBuf, OsString) are not formally repr(transparent) and their layout is technically an implementation detail, but the chain is consistent with the imul rcx, [r12+0x10], 0x18 stride evidence in Step 4. The field mapping for closure fields +0x00, +0x08, +0x10 is therefore: +0x00 r14 -- Vec<u8>.ptr (PathBuf data pointer) +0x08 rbx -- Vec<u8>.len (PathBuf byte length) +0x10 r13 -- output_capture: Option<Arc<Mutex<Vec<u8>>>> (set_output_capture return value -- see above) </code></pre> Note that +0x10 is not Vec.cap. The r13 register was loaded from set_output_capture at 0x4d4026, not from the PathBuf capacity field. The capacity field of PathBuf is not stored in the closure -- only ptr and len are needed to reference the file path slice inside lock_closure. +0x18 key material: Functional inference. The movups xmmword [rax+0x18], xmm0 stores the value in xmm0, which was loaded from the HashStruct::hash output region in Step 5. This is a register-trace inference across intervening instructions, not a direct binary observation of the key derivation path end-to-end. Fields beyond +0x38. The exact field count and types beyond +0x38 require further disassembly of lock_closure. Step 9 — First Thread::new: the encryption thread</h2> Address range: 0x4d3e6f -- 0x4d3e91 Disassembly HLIL in Binary Ninja Starting from High Level IL</h2> **Thread::new call site (**0x4d3e7e): char const (** rax_24)[0x28] = std::thread::Thread::new::h977b0e8df4ff7524() </code></pre> Binary Ninja has typed rax_24 as char const (**)[0x28], a pointer to a pointer to a 0x28-byte (40-byte) array. This is Binary Ninja's best-effort type inference for the return value. The key observation is that rax_24 is a pointer, not an integer. Thread::new is returning a pointer in rax. 0x4d3e83: char const (** var_2c0)[0x28] = rax_24 </code></pre> The return value is stored into var_2c0. 0x4d3e8d: char const (* temp5_1)[0x28] = *rax_24 *rax_24 = &(**rax_24)[1] </code></pre> This is the lock inc in HLIL form. Binary Ninja has lifted it as: dereference rax_24 to get temp5_1 (the current value), then write (**rax_24)[1] back, i.e., increment the qword at the address rax_24 points to. This is an atomic increment of a counter at the address returned by Thread::new. 0x4d3e91: if (temp5_1 s> -1) </code></pre> This is the jle 0x4d42da overflow check. The s> -1 (signed greater than -1) is the jle taken when the incremented value was ≤ -1 (i.e., overflow/underflow). This is exactly the Arc refcount overflow guard from sync.rs</a>: if old_size > MAX_REFCOUNT { abort(); } </code></pre> 0x4d3e9a: the else branch (overflow path): uint64_t rax_25 = alloc::alloc::exchange_malloc::hc6dbbe43d4abbe5a .1241 *rax_25 = 1 *(rax_25 + 8) = 1 *(rax_25 + 0x10) = zx.o(0) var_268 = rax_25 </code></pre> A fresh allocation of size .1241 (some allocation size). Two fields set to 1, third field zeroed. This is another Arc allocation: strong=1, weak=1, data=0. The var_268 assignment is storing this new Arc pointer. This is the JoinHandle's packet Arc being allocated in the success path of Thread::new. Then Disassembly</h2> call std::sys_common::thread::min_stack ; 0x4d3e6f mov qword [rsp+0x1b0 {var_128_1}], rax xor edi, edi {0x0} ; stack = 0 (use default) call std::thread::Thread::new ; 0x4d3e7e </code></pre> std::thread::Thread::new is observed at 0x4d3e7e. The symbol name is read directly from the disassembly. The pinned source is at library/std/src/sys/pal/unix/thread.rs</a>: pub unsafe fn new(stack: usize, p: Box<dyn FnOnce()>) -> io::Result<Thread> </code></pre> The xor edi, edi setting stack = 0 is verified against the Thread::new source: when stack = 0 is passed, the implementation uses cmp::max(0, min_stack_size(&attr)), which collapses to min_stack_size. min_stack is called at 0x4d3e6f immediately before to cache that value. The implementation details (double-boxing, Box::into_raw(Box::new(p)), pthread_create, thread_start) are Verified from library/std/src/sys/pal/unix/thread.rs</a> at commit db034cee: let p = Box::into_raw(Box::new(p)); </code></pre> and thread_start</a> is the extern "C" callback at the end of Thread::new</a> in the same file. After Thread::new returns: mov qword [rsp+0x18 {var_2c0}], rax lock inc qword [rax] ; Arc refcount bump </code></pre> lock inc: Binary Ninja HLIL evidence. The HLIL at 0x4d3e7e--0x4d3e91 reads: char const (** rax_24)[0x28] = std::thread::Thread::new::h977b0e8df4ff7524() char const (** var_2c0)[0x28] = rax_24 char const (* temp5_1)[0x28] = *rax_24 *rax_24 = &(**rax_24)[1] // ← this is the lock inc if (temp5_1 s> -1) { ... } // ← overflow guard </code></pre> The overflow guard if (temp5_1 s> -1) matches the Arc refcount overflow check in pasted alloc/src/sync.rs</a>: if old_size > MAX_REFCOUNT { abort(); } </code></pre> where MAX_REFCOUNT = (isize::MAX) as usize . On x86–64, isize::MAX = 2^63 - 1 = 9_223_372_036_854_775_807 = 0x7fff_ffff_ffff_ffff. </blockquote> At the pinned commit, Thread is defined in library/std/src/thread/mod.rs</a> as: pub struct Thread(Inner); enum Inner { Main(&'static (ThreadId, Parker)), Other(Pin<Arc<OtherInner>>), } </code></pre> The Arc being incremented by lock inc is therefore the Arc inside Inner::Other, accessed via the Thread handle returned from Thread::new. The subsequent basic block at 0x4d3e9a allocates JoinInner::packet : struct JoinInner<'scope, T> { native: imp::Thread, thread: Thread, packet: Arc<Packet<'scope, T>>, } </code></pre> The Arc is the communication channel between the spawned thread and its JoinHandle. Then immediately: xor edi, edi call std::io::stdio::set_output_capture ; 0x4d3ec4 </code></pre> This is inside the inlined main shim closure body. The main shim is constructed in Builder::spawn_unchecked_ in library/std/src/thread/mod.rs</a> . The shim at db034cee is: let main = move || { if let Err(_thread) = set_current(their_thread.clone()) { rtabort!("something here is badly broken!"); } if let Some(name) = their_thread.cname() { imp::Thread::set_name(name); } crate::io::set_output_capture(output_capture); let f = f.into_inner(); let try_result = panic::catch_unwind(panic::AssertUnwindSafe(|| { crate::sys::backtrace::__rust_begin_short_backtrace(f) })); ... </code></pre> set_output_capture is defined at library/std/src/io/stdio.rs</a>. It returns Option<Arc<Mutex<Vec>>>, the previous capture state. xor edi, edi passes None (null pointer as the first argument), confirmed by the SysV ABI (rdi = first argument, cited in Step 1 via x86-psABIs v1.0 §3.2.3). Step 10 — Second Thread::new: the indicatif ticker thread</h2> Address range: 0x4d3fbf -- 0x4d4016 yarnish.rs</a> line pb.set_style(spinner_style.clone())</a>: let handles: Vec<_> = (0..4u32) .map(|i| { let count = rng.gen_range(30..80); let pb = m.add(ProgressBar::new(count)); pb.set_style(spinner_style.clone()); pb.set_prefix(format!("[{}/?]", i + 1)); thread::spawn(move || { let mut rng = rand::thread_rng(); let pkg = PACKAGES.choose(&mut rng).unwrap(); for _ in 0..count { let cmd = COMMANDS.choose(&mut rng).unwrap(); thread::sleep(Duration::from_millis(rng.gen_range(25..200))); pb.set_message(format!("{pkg}: {cmd}")); pb.inc(1); } pb.finish_with_message("waiting..."); }) }) .collect(); </code></pre> This block maps directly to yarnish.rs lines 34--36 at commit 0c037edc</a>: pb.set_style(spinner_style.clone()); // yarnish.rs line 34 pb.set_prefix(format!("[{}/?]", i + 1)); // yarnish.rs line 35 thread::spawn(move || { ... }) // yarnish.rs line 36 </code></pre> Ticker::drop_in_place at 0x4d3f95. This is dropping the Ticker handle from the previous loop iteration, not spawning a new thread. The Ticker is an indicatif-internal struct managing the spinner animation. call core::ptr::drop_in_place...ss_bar..Ticker$GT$ ; 0x4d3f95 -- Verified </code></pre> pb.set_style(spinner_style.clone()) (mapped to yarnish.rs line 34). ProgressStyle::clone produces the cloned style; set_style applies it to the ProgressBar: call _$LT$indicatif::style::...Clone$GT$::clone ; 0x4d3fbf -- Verified ; = spinner_style.clone() mov rdi, qword [rsp+0x50 {var_288}] mov rsi, r12 {var_1d8} call indicatif::progress_bar::...ressBar::set_style ; 0x4d3fd1 -- Verified ; = pb.set_style(...) </code></pre> thread::spawn(move || { ... }) -- the spawn call:</h3> This is the same encryption thread spawn as Step 9, not a separate ticker thread. The thread::spawn call chain is inlined; Thread::new at 0x4d3fe3 is its innermost call: call std::sys_common::thread::min_stack ; 0x4d3fd9 -- Verified mov r15, rax xor edi, edi ; stack = 0 (default) call std::thread::Thread::new ; 0x4d3fe3 -- Verified ; = thread::spawn(move || {...}) </code></pre> ProgressStyle::clone + set_style before Thread::new does not indicate a separate enable_steady_tick ticker thread. It maps to pb.set_style(spinner_style.clone()) in yarnish.rs. There is only one encryption-related Thread::new call visible in the screenshots provided. Whether enable_steady_tick spawns a second thread cannot be confirmed without additional disassembly showing a second Thread::new call. Arc::new and lock inc after Thread::new -- Verified as part of JoinInner construction (established from HLIL in Step 9): call alloc::sync::Arc<T>::new ; 0x4d4008 -- Verified mov qword [rsp+0x70 {var_268}], rax lock inc qword [rax] ; 0x4d4012 -- Verified (Arc::clone) </code></pre> Arc::clone confirmed from pasted alloc/src/sync.rs</a>. Step 11 —Mutex-protected Vec::push and loop back-edge</h2> Address range: 0x4d39e0 -- 0x4d3a20 The Vec::push at 0x4d39ff does not occur in isolation, it is wrapped in a Mutex::lock guard: 004d39e0 call std::sync::mutex::Mutex<T>::lock ; acquire Mutex<Vec<JoinHandle>> 004d39eb mov rsi, r12 {data_5e7080} 004d39ee call core::result::Result::unwrap 004d39f3 mov r13, rax ; r13 = MutexGuard 004d39ff call alloc::vec::Vec::push ; push JoinHandle under guard 004d3a0b call core::ptr::drop_in_place(...) ; drop MutexGuard (unlock) 004d3a10 mov rax, qword [rsp+0x110 {var_1c8}] ; IntoIter.start advance 004d3a18 mov rcx, qword [rsp+0x118 {i_1}] ; IntoIter.end 004d3a20 jmp 0x4d39b0 ; loop back-edge </code></pre> The Mutex is Akira's own code, not from the stdlib -- Verified from the pasted library/std/src/thread/scoped.rs</a>. ScopeData contains no Mutex whatsoever: pub(super) struct ScopeData { num_running_threads: AtomicUsize, a_thread_panicked: AtomicBool, main_thread: Thread, } </code></pre> The scope() function waits for all threads using park/unpark exclusively -(Verified from the pasted scoped.rs): while scope.data.num_running_threads.load(Ordering::Acquire) != 0 { park(); } </code></pre> Each finishing thread calls self.main_thread.unpark() via decrement_num_running_threads. There is no Mutex, no Condvar, and no Vec anywhere in the scoped thread stdlib machinery at db034cee. The Mutex at data_5e7080 therefore belongs to akiranew/src/lock.rs. What the Mutex guards -- unknown. The Vec::push argument is var_d0 / r15 (binary-observed). Tracing r15 back to its assignment site has not been completed from the available screenshots. The guarded Vec could hold encrypted file paths, progress records, ransom note entries, or something else entirely. The earlier label Vec was wrong and is retracted -- scoped threads do not need a Mutex for handle management. Mutex::lock : Source at library/std/src/sync/mutex.rs</a>.</li> Vec::push: Source at library/alloc/src/vec/mod.rs</a>.</li> MutexGuard drop: Verified (symbol binary-observed).</li> Loop back-edge — Verified (binary-observed). jmp 0x4d39b0 returns to the loop head from Step 4.</li> yarnish.rs comparison: No mutex appears in the yarnish.rs template at 0c037edc</a>. The presence of a mutex-protected Vec::push in every loop iteration is an Akira-specific addition whose purpose requires further analysis of lock.rs.</li> </ul> More details about tracing back mutex can be found in the sectin of Further Reading below. </blockquote> Akira deviation from yarnish.rs: The yarnish.rs template at commit 0c037edc</a> pushes handles into a plain Vec<_> with no mutex: }).collect(); </code></pre> Akira wraps the Vec in a Mutex, acquiring it before each push. This is binary-observed, no such mutex appears in yarnish.rs. The mutex at data_5e7080 is distinct from the one at data_5ebe00 seen in Step 7. Step 11b — Real Thread::new: sys::unix::thread::Thread::new</h2> Address range: 0x4d4062 -- 0x4d40d2 High Level IL Disassembly Graphi View The graph view reveals the actual pthread_create-invoking Thread::new, which was not visible in the earlier screenshots. num_running_threads and closure struct: 004d405e add rdi, 0x10 004d4062 call std::thread::scoped::Sco...um_running_threads ; semaphore check </code></pre> Immediately after the semaphore check, the closure capture struct is built: 004d406d push 0x58 / pop rdi {0x58} ; size = 88 bytes 004d406c push 0x8 / pop rsi {0x8} ; align = 8 004d406d call alloc::alloc::exchange_malloc ; allocate closure struct </code></pre> Then 14 mov instructions fill the struct fields from stack variables (var_288, var_278, var_2b0, var_148_1, var_150, var_2a8 etc.) followed by two movups for the XMM key material, and at 0x4d40cb: 004d40cb lea rcx, [rel data_5e66a8] ; vtable pointer </code></pre> Then the actual spawn: 004d40d2 call std::sys::unix::thread::Thread::new::hd257ed4d46662134 </code></pre> This is a different mangled symbol from 0x4d3e7e (h977b0e8df4ff7524). </blockquote> The symbol hd257ed4d46662134 resolves to std::sys::unix::thread::Thread::new, the PAL-level function in library/std/src/sys/pal/unix/thread.rs</a> that calls pthread_create directly. This is imp::Thread::new in the spawn_unchecked_ closing lines (Verified from library/std/src/thread/mod.rs</a>): Ok(JoinInner { native: unsafe { imp::Thread::new(stack_size, main)? }, thread: my_thread, packet: my_packet, }) </code></pre> JoinInner is defined in library/std/src/thread/mod.rs</a>: struct JoinInner<'scope, T> { native: imp::Thread, thread: Thread, packet: Arc<Packet<'scope, T>>, } </code></pre> Thread at db034cee is pub struct Thread(Inner) where Inner is an enum with Other(Pin<Arc>)(Verified from library/std/src/thread/mod.rs</a>). Error path after Thread::new: 004d40f2 call core::ptr::drop_in_place...P$$RPS$GT$ ; drop Box<dyn FnOnce()> 004d40fc call core::ptr::drop_in_place...Thread$GT$ ; drop partial Thread </code></pre> This matches the verified sys/pal/unix/thread.rs source: return if ret != 0 { drop(Box::from_raw(p)); // drop the double-boxed closure Err(io::Error::from_raw_os_error(ret)) } else { Ok(Thread { id: native }) }; </code></pre> The data_5e66a8 vtable pointer at 0x4d40cb is the Box<dyn FnOnce()> vtable, the call_once slot pointing to the main shim, as described in the report</a> (Herzog, 2024, Figures 24--26). Step 12 — Loop back-edge and IntoIter drop</h2> Address range: 0x4d3a10 -- 0x4d3a22 mov rax, qword [rsp+0x110 {var_1c8}] ; load updated IntoIter.start mov rcx, qword [rsp+0x118 {i_1}] ; load IntoIter.end jmp 0x4d39b0 ; back to loop head </code></pre> When start == end, execution falls through to: call _$LTalloc..vec..into_it...op..Drop$GT$::drop ; 0x4d3a2a </code></pre> The file list memory is freed. The Vec now contains one handle per file. A post-loop log call confirms completion before the join phase. Step 13 — Join loop and Mutex cleanup</h2> Address range: 0x4d3b40 -- 0x4d3b9f call std::sync::mutex::Mutex<T>::lock ; 0x4d3b43 (data_5e7028) call core::result::Result::unwrap // ... call std::sync::mutex::Mutex<T>::lock ; 0x4d3b73 (data_5e7040) call core::result::Result::unwrap call core::ptr::drop_in_place(...) ; MutexGuard drop </code></pre> The two static addresses data_5e7028 and data_5e7040 are now fully identified from .data.rel.ro. Binary Ninja's annotation shows both point into the log format vtable for "File lock started: , thread id: ...", these are not user-visible mutex objects but the Debug formatter vtables for the log call arguments. The actual join loop (pthread_join via Thread::join) follows: call Thread::join → libc::pthread_join(id, ptr::null_mut()) </code></pre> This corresponds to yarnish.rs: for h in handles { let _ = h.join(); } </code></pre> Reconstructed source</h2> Combining all steps, the reconstructed lock function is: fn lock( files: Vec<PathBuf>, thread_limit: u64, exclude: *const u8, opts: *const OperatorOptions, ) { // Step 2: ProgressStyle let spinner_style = ProgressStyle::with_template("...").unwrap() .tick_chars("..."); // Step 3: MultiProgress let m = MultiProgress::new(); // Step 7: scoped thread scope with semaphore std::thread::scope(|scope| { // Step 4: iterate files (NOT (0..n) as in yarnish.rs) let handles: Vec<_> = files.into_iter().map(|path| { // Step 5: per-file seed (Akira-specific) let now = SystemTime::now() .duration_since(UNIX_EPOCH) .unwrap(); let pid = unsafe { libc::getpid() }; let key = akira_v2::prng::HashStruct::hash(now, pid); // key = 64 bytes stored in closure // Step 6: ProgressBar with file path as prefix let pb = m.add(ProgressBar::new(...)); pb.set_style(spinner_style.clone()); // Step 10: yarnish.rs line 34 pb.set_prefix(path.display().to_string()); // file path, not "[i/?]" // Note: enable_steady_tick presence unconfirmed from screenshots // Step 7: wait for semaphore slot while scope.num_running_threads() >= thread_limit as usize {} // Step 9/10: spawn encryption thread scope.spawn(move || { log::info!("File lock started: , thread id: {}", ...); lock_closure(path, key, pb, ...); }) }).collect(); // Step 11: Mutex<Vec<??>> -- contents unknown // Step 13: join all for h in handles { h.join().unwrap(); } }); } </code></pre> Section 7: lock_closure and Encryption</h2> lock (user code, inlined) → Builder::spawn_unchecked_ (inlined) → main shim (inlined) → catch_unwind (inlined) → __rust_begin_short_backtrace (NOT inlined -- #[inline(never)]) → lock_closure (the encryption function) </code></pre> This is the symmetric key generated by random number (ThreadRng</a>). As identifed in CheckPoint report, Akirav2 malware author used dalek.rs</a>- curve25519</a> to implement “a high-speed, secure elliptic curve used primarily for ECDH key exchange (X25519) and digital signatures (Ed25519), offering 128-bit security with 256-bit keys” (source</a>). Ransom note Correction (24 June 2026). An earlier version of this section described the symmetric primitive as ChaCha20 and the key-wrapping as RSA. That is the scheme used by the older C++ Akira lineage, not the Rust v2 ESXi encryptor analysed here. The Rust v2 pipeline is X25519 (curve25519-dalek 4.1.1) for asymmetric key wrapping and SOSEMANUK (via rust-crypto 0.2.36) for symmetric per-file encryption, with the session key drawn from a ChaCha12 CSPRNG (rand 0.8.5 / rand_chacha 0.3.1, surfaced as thread_rng / ThreadRng). I independently confirmed SOSEMANUK in my own static recovery: the FSM multiplier 0x54655307 with a rotate-left-7 appears 20 times in the HLIL/SSA, the Serpent24 key-schedule constant 0x9E3779B9 is present, and the literal string “sosemanuk” survives in .rodata. Crate versions come from my 29-crate recovery; algorithm roles are corroborated by Check Point. Apologies for the earlier conflation. </blockquote> The actual encryption logic lives in lock_closure. Key points from Check Point's analysis: File targeting: the closure walks the filesystem, filtering by extension. ESXi-relevant extensions (.vmdk, .vmx, .vmsn, .nvram and others) are the primary targets.</li> Symmetric encryption: a per-file session key is generated per run, and the file payload is encrypted with SOSEMANUK, a software-oriented stream cipher chosen (like other stream ciphers) for throughput on targets without hardware AES acceleration. The implementation comes from the legacy rust-crypto 0.2.36 crate (DaGenix), where SOSEMANUK is heavily inlined and must be recovered from its characteristic constants rather than a named import. In this sample the fingerprints are unambiguous: the FSM multiplier 0x54655307 followed by a rotate-left-7 (the SOSEMANUK FSM update, recovered 20 times in the HLIL/SSA), the Serpent key-schedule constant 0x9E3779B9, and the residual string “sosemanuk” in .rodata.</li> Randomness: the session key is drawn from ThreadRng (thread_rng), which in rand 0.8.5 is a ReseedingRng<ChaCha12Core, OsRng>. In other words the CSPRNG is ChaCha12 from rand_chacha 0.3.1, reseeded from the OS via getrandom 0.2.10. This is the only place ChaCha appears in the Rust v2 binary: as the RNG that produces key material, not as the file cipher. (See Part 2 for the thread_rng recovery.)</li> Key protection: the session key is wrapped with a per-binary hardcoded X25519 (curve25519) public key, the dalek curve25519-dalek 4.1.1 stack, not RSA. The public key is embedded in the binary and written alongside the encrypted files; only the operator’s matching private key can recover the session key, enabling decryption upon ransom payment.</li> </ul> Further Reading</h2> 1. Why UAWAVAUATSH exists</h2> Source: https://github.com/torvalds/linux/blob/v6.11/arch/x86/lib/x86-opcode-map.txt</a> </blockquote> It is Binary Ninja’s hex view ASCII column rendering the raw machine code bytes of the HumanDuration::fmt function prologue. There is no string UAWAVAUATSH anywhere in the ELF. The encoding mechanics</h3> The opcode map file is stable across kernel versions for x86–64, the encodings do not change. But I pin v6.11 rather than master, for the same reason the Rust stdlib commit pinned here: reproducibility. </blockquote> The Linux kernel opcode map (canonical reference for x86 instruction encoding) lists: 0x55 = PUSH rBP/r13, 0x56 = PUSH rSI/r14, 0x57 = PUSH rDI/r15, 0x54 = PUSH rSP/r12 (GitHub</a>). The REX prefix range (0x40–0x4f)</h3> In 64-bit mode (o64), opcodes 0x40–0x4f are REX prefix bytes, not instructions. Specifically: 0x41 = REX.B, 0x48 = REX.W (github</a>, OSDev Wiki</a>). In 32-bit mode those same bytes were single-byte INC/DEC instructions, but in 64-bit mode they are all repurposed as REX prefix encodings. top row: INC eAX INC eCX INC eDX ... (i64) bottom row: REX REX.B REX.X ... (o64) mode 0x41 means -------- ---------- 32-bit INC eCX (top row, superscript i64 = illegal in 64-bit) 64-bit REX.B prefix (bottom row, superscript o64 = only in 64-bit) </code></pre> Intel SDM Table A-2, row 4 INC(i64) general register / REX(o64) Prefixes 40 41 42 43 44 45 46 47 eAX eCX eDX eBX eSP eBP eSI eDI REX REX.B REX.X REX.XB REX.R REX.RB REX.RX REX.RXB </code></pre> The two superscripts do all the work: i64 = invalid in 64-bit mode: the INC eAX meaning of 0x40 is illegal in 64-bit mode</li> o64 = only in 64-bit mode: the REX meaning of 0x40 only exists in 64-bit mode</li> </ul> And row 5 shows the PUSH encoding you need: PUSH(d64) general register 50 51 52 53 54 55 56 57 rAX/r8 rCX/r9 rDX/r10 rBX/r11 rSP/r12 rBP/r13 rSI/r14 rDI/r15 </code></pre> The /r8–/r15 disambiguation in row 5 is exactly what REX.B from row 4 provides. 0x55 alone = push rbp. 0x41 0x55 = REX.B prefix + 0x55 = push r13. Same opcode byte, extended register selected by the preceding REX.B. This is the primary source. The Linux v6.11 opcode map entry 41: INC eCX (i64) | REX.B (o64) is a direct transcription of this SDM table. Both sources agree, and the SDM is the ground truth since it is the processor specification. So the connection to UAWAVAUATSH is: akirav2.elf is a 64-bit ELF → CPU is in 64-bit long mode → 0x41 = REX.B (not INC eCX) → 0x41 0x57 = REX.B + PUSH rDI/r15 = push r15 → Binary Ninja renders 0x41 as 'A', 0x57 as 'W' → hence "AW" in the ASCII column </code></pre> 2. REX — Register Extension.</h2> REX</a> stands for Register Extension. It is a one-byte prefix introduced in x86–64 to extend the instruction set beyond what the original 32-bit encoding could address. The byte has the fixed high nibble 0100 (hence 0x4_), with the low nibble encoding four flag bits: 0100 W R X B │ │ │ └─ REX.B — extends the r/m field, SIB base, or opcode reg field │ │ └─── REX.X — extends the SIB index field │ └───── REX.R — extends the ModRM reg field └─────── REX.W — promotes operand size to 64 bits </code></pre> Why it was needed The original x86 encoding only had 3 bits to identify a register, giving eight registers (rax–rdi). x86-64 added eight more (r8–r15). Rather than redesigning the entire encoding, Intel and AMD added the REX prefix to supply a fourth bit for each register field, doubling the addressable register count. The four specific bits REX.W (0x48) — use 64-bit operand size instead of the default 32-bit. Most mov, add, sub etc. instructions need this when operating on 64-bit values. REX.B (0x41) — extends the register encoded in the opcode byte itself (e.g. the low 3 bits of a push/pop opcode), or the r/m field of ModRM. This is how 0x41 0x57 becomes push r15 instead of push rdi — the B bit flips the register selection from the base-8 register to the extended one. REX.R (0x44) — extends the reg field of the ModRM byte. REX.X (0x42) — extends the index field of the SIB byte. Why 0x41 renders as A in ASCII 0x41 is the ASCII code for A. Since REX prefixes occupy 0x40–0x4f, and that range maps directly onto uppercase Latin letters @ABCDEFGHIJKLMNO, every REX.B prefix byte in a hex viewer renders as A. This is purely coincidental — the x86-64 architects chose that range because it freed up the old INC/DEC opcodes in 64-bit mode, not because of any ASCII consideration. When pushing extended registers, 0x41 precedes the base push opcode. For example, to push r9 the encoding is 0x41 followed by 0x50 + (9 - 8) = 0x51. The original eight registers push with a single byte; extended registers require two bytes: the REX.B prefix plus the base opcode (Eklitzke</a>). Applying this to UAWAVAUATSH: BytesASCIIInstruction0x55Upush rbp0x41 0x57AWpush r15 (REX.B + 0x57)0x41 0x56AVpush r14 (REX.B + 0x56)0x41 0x55AUpush r13 (REX.B + 0x55)0x41 0x54ATpush r12 (REX.B + 0x54)0x53Spush rbx0x48HREX.W prefix (start of next instruction, e.g. sub rsp, N) All eleven bytes fall in the printable ASCII range (0x41–0x57 are uppercase letters, 0x53–0x55 likewise, 0x48 is H), so Binary Ninja's hex view renders all of them as characters rather than dots. Why this specific prologue</h3> Compilers save callee-preserved registers at function entry when the function needs to use them. The System V AMD64 ABI designates rbx, rbp, r12–r15 as callee-saved. A function that uses all six must push all six on entry. The HumanDuration::fmt function is complex enough (formatting a duration string requires multiple branches and temporaries) that LLVM assigned all six callee-saved registers, producing exactly this push sequence (Eklitzke</a>). Why 0x41 renders as A</h3> 0x41 is the ASCII code for uppercase A. The REX prefix range 0x40–0x4F was chosen by the x86-64 architects precisely because those opcodes were the legacy single-byte INC/DEC instructions, which were retired in 64-bit mode to free the space. They happen to sit in the middle of the uppercase ASCII Latin alphabet. So every REX-prefixed push of an extended register produces an A in the ASCII column followed by the push target letter (OSDev Wiki</a>). The byte sequence is entirely mechanical and deterministic. Any function in any x86–64 ELF that saves rbp, r15, r14, r13, r12, rbx in that order will produce UAWAVAUATSH in a hex viewer. 3. Mutex</h2> Looking back to (0x4d3c2b--0x4d3c63) we saw: 004d3c2b cmp qword [rsp+0x48 {var_290}], 0x0 004d3c31 lea r13, [rsp+0x50 {var_288}] 004d3c36 je 0x4d4153 </code></pre> And the three lock inc atomics immediately before SystemTime::now. The je 0x4d4153 target was never shown in the screenshots, that is where control goes when the count is zero. From the figure below, we also see std::thread::scoped::Sco...um_running_threads at 0x4d4062. From thread/mod.rs at db034cee</a>, the exact lines in spawn_unchecked_: if let Some(scope_data) = &my_packet.scope { scope_data.increment_num_running_threads(); } </code></pre> From scoped.rs at db034cee</a>, increment_num_running_threads is: pub(super) fn increment_num_running_threads(&self) { if self.num_running_threads.fetch_add(1, Ordering::Relaxed) > usize::MAX / 2 { self.overflow(); } } </code></pre> And from thread/mod.rs, Packet contains: struct Packet<'scope, T> { scope: Option<Arc<scoped::ScopeData>>, ... } </code></pre> ScopeData is in scoped.rs. From the earlier session search result, ScopeData contains: pub(super) struct ScopeData { num_running_threads: Atomic<usize>, a_thread_panicked: Atomic<bool>, main_thread: Thread, } </code></pre> And from the scoped.rs source at the pinned commit, scope() blocks until num_running_threads reaches zero using a Condvar: https://github.com/rust-lang/rust/blob/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/thread/scoped.rs </code></pre> The connection is:</h3> Mutex + Condvar is the standard Rust pattern for scope() to wait for all spawned threads to finish. The Condvar is used inside ScopeData to park the scope-owning thread until num_running_threads drops to zero. The Mutex guards the condition variable's predicate check. In the disassembly, the Mutex::lock at 0x4d3b40/0x4d3b73 on data_5e7028 and data_5e7040, and the Mutex::lock at 0x4d39e0 on data_5e7080 are the Condvar-associated mutexes inside ScopeData. This is the scope() call blocking after all threads are spawned, waiting for them to complete via decrement_num_running_threads calling notify_all on the Condvar. So the connection is: std::thread::scope(|s| { for path in files { s.spawn(|| lock_closure(path, ...)); } // scope() blocks here on Condvar::wait_while(Mutex, num_running == 0) }) </code></pre> The Mutex and Condvar pair are from scoped.rs , not Akira's own code. </blockquote> The Vec::push at 0x4d39ff question therefore changes: it may be pushing into a Vec inside ScopeData or a related structure managed by the scope machinery, not a user-visible Vec. References</h2> x86-psABIs project (2024) System V application binary interface: AMD64 architecture processor supplement, version 1.0. GitLab. Available at: https://gitlab.com/x86-psABIs/x86-64-ABI</a> (PDF: https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf</a>) Herzog, B. (2024) Inside Akira ransomware’s Rust experiment. Check Point Research. Available at: https://research.checkpoint.com/2024/inside-akira-ransomwares-rust-experiment/</a> Klabnik, S. and Nichols, C. (2019) The Rust programming language. San Francisco: No Starch Press. RalfJung (2024) PathBuf incorrectly transmutes OsString to Vec — issue #124409. GitHub. Available at: https://github.com/rust-lang/rust/issues/124409</a> RalfJung (2024) PathBuf: replace transmuting by accessor functions — PR #124410. GitHub. Available at: https://github.com/rust-lang/rust/pull/124410</a> The Linux man-pages project (2024) getpid(2). Available at: https://man7.org/linux/man-pages/man2/getpid.2.html</a> Tompkins, W. et al. (2024) Akira ransomware continues to evolve. Cisco Talos Intelligence. Available at: https://blog.talosintelligence.com/akira-ransomware-continues-to-evolve/</a> console-rs (2024) indicatif 0.17.7 progress_bar.rs source. Available at: https://github.com/console-rs/indicatif/blob/0c037edc86449d84aa457d7d5db80b4166c18d6b/src/progress_bar.rs</a> console-rs (2024) indicatif 0.17.7 style.rs source. Available at: https://github.com/console-rs/indicatif/blob/0c037edc86449d84aa457d7d5db80b4166c18d6b/src/style.rs</a> console-rs (2024) indicatif 0.17.7. crates.io. Available at: https://crates.io/crates/indicatif/0.17.7</a> console-rs (2024) indicatif yarnish.rs example, commit 0c037edc86449d84aa457d7d5db80b4166c18d6b. GitHub. Available at: https://github.com/console-rs/indicatif/blob/0c037edc86449d84aa457d7d5db80b4166c18d6b/examples/yarnish.rs#L29</a> Xiao, C. (2025) Reconstructing Rust types. RE//verse 2025. Available at: https://recon.cx/2025/schedule/events/reverse.html</a> UAWAVAUATSH Linux kernel opcode map (ground truth for opcode assignments): https://github.com/torvalds/linux/blob/master/arch/x86/lib/x86-opcode-map.txt</a></li> REX prefix encoding: https://wiki.osdev.org/X86-64_Instruction_Encoding</a></li> Push/pop register encoding arithmetic: https://eklitzke.org/x86-register-encoding</a></li> </ul> Thanks for reading

Reversing Akira's Rust Experiment: A Breakdown, Part 1

2026-05-06T00:00:00+00:00

This post is a breakdown and commentary on Ben Herzog’s Check Point Research (December 2024), Inside Akira Ransomware’s Rust Experiment</a> & his talk in 2025</a>. All technical claims are grounded in the linked primary sources below. Combined with Cindy Xiao’s amazing reports/talks in 2024</a>, 2025</a> (about reconstructing types and more). </blockquote>

The technique of recovering the rustc compiler version from embedded
/rustc//strings and recovering third-party crates from
registry/src/index.crates.io-…/-/ panic paths was
independently developed by Juan Andrés Guerrero-Saade and Nicole Fishbein
in their Proj-0xA11c toolset, presented at Recon 2024:
https://github.com/juanandresgs/Proj-0xA11c</a> </blockquote>
There will be a part 2 to break down the rest. I separate them so this article won’t be _too_long_.

For this analysis, Binary Ninja (v5.3.9434) is used without enabling any plugins. Binary: akirav2.elf , SHA25:60ee1d284ed663073872012c7bde7fac5ca1121403f1a5d2d5411317df282796c.
A note on source references</h3>

The commit hash is updated on 10th Jun 2026. 79e9716c… is rustc 1.74.0 stable (released 2023-11-16). Akirav2’s .rodata contains std panic-path strings of the form /rustc//library/....db034cee… is a master/nightly commit from ~1 year later, which I was mistakenly pinned in the article. If you see any links related to db034cee… , please consider it was based on previosu wrong assumption but it works to some degree. </blockquote>
The Rust standard library is under active development and files move between releases. Source links in this post are pinned to commit 79e9716c980570bfd1f666e3b16ac583f0168962 — rustc 1.74.0 stable</a>, the toolchain that compiled this Akira v2 binary. This is recoverable directly from the binary: its .rodata embeds /rustc/79e9716c…/library/... panic paths, and it is corroborated by version-pinned FunctionID analysis resolving the sample to 1.74.0.
This matters because stdlib code is inlined directly into the final binary at compile time: what you see in the disassembly reflects the stdlib at that specific commit, not the current main branch. Following a newer version of the same file risks misidentifying inlined boilerplate or drawing incorrect conclusions about what the malware authors wrote versus what the compiler contributed.
If a pinned link returns a 404, the file has likely been relocated. Navigate to the repository root</a> and search by filename. </blockquote>
Table of Contents</h2>

Background</li>
Summary for Part 1</li>
VM Setup for malware analysis</li>
Binja plugins for Rust binary</li>
Is this a Rust binary?</li>
(Updated) It’s a release build</li>
.rodata strings are extraordinarily revealing</li>
The Control Flow Map</li>
Section 1: How args().collect() Works</li>
Further Reading</li>
References</li> </ul>
Background</h2>
In early 2024, Akira ransomware-as-a-service operators circulated a new variant, internally called “Akira v2”, written in Rust and aimed specifically at ESXi bare-metal hypervisor servers. Cisco Talos first documented the variant in their ongoing Akira evolution tracking</a>.
Check Point Research</a> published a detailed assembly-level analysis in December 2024. Unlike most ransomware reports that answer only targeted questions (“what encryption is used?”, “what extensions are targeted?”).
Talos</a> documented Akira v2 from a March 2024 incident response engagement, where they observed the Rust ESXi variant deployed alongside a Windows encryptor called Megazord. The v2 sample they analysed is version 2024.1.30 and uses rust-crypto 0.2.36 for encryption, replacing the Crypto++ library used in the original C++ variant. Here rust-crypto supplies the SOSEMANUK symmetric stream cipher (not ChaCha20 or AES); the asymmetric key wrapping is X25519 via curve25519-dalek 4.1.1. See the Part 3 correction note for the full pipeline.
Summary for Part 1</h2>

Because this article and following ones in the series will be fairly_long, so I put the summary before the in-depth breakdown. </blockquote>
Layer 1: Crate/Dependency Recovery via .rodata Panic Strings</h2>
Every entry here was recovered purely from static string analysis, no execution, no DWARF.
Recovery mechanism: Cargo embeds full filesystem paths into panic messages at compile time. Format is always:
/mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/<crate-name>-<version>/src/<file>.rs </code></pre> In conclusion, Indicatif version is 0.17.7</a>. </blockquote> Updated 17 May 2026: I’m still writing the analysis part 2 at the moment, Indicatif</a> version has actually found but I was drown in the piles of strings, so accidentally ignored it. </blockquote> Internal workspace crates (not on crates.io, custom): Developer platform also recoverable: WSL on Windows, username user, consistent registry hash 6f17d22bba15001f across all paths confirming single build environment. Struct names leaked via aho-corasick SIMD backends (panic strings referencing internal type names): SlimSSSE3 : 128-bit SSSE3 Teddy searcher</li> SlimAVX2: slim 256-bit AVX2 variant</li> FatAVX2 : fat 256-bit AVX2 Teddy searcher</li> </ul> These tell you the SIMD capability branch taken at runtime even without executing. Layer 2: Internal Module Map (recovered from panic strings + format literals)</h2> akiranew/ ├── src/ │ ├── main.rs — CLI parsing, fork/stopvm, interactive prompt │ ├── lock.rs — encryption logic (akira_v2::lock namespace confirmed) │ ├── path_finder.rs — filesystem enumeration (akira_v2::path_finder confirmed) │ └── prng.rs — custom PRNG └── Cargo.toml (workspace member: akira_utils) </code></pre> Top-level call chain confirmed: main → default_action → lock → lock_closure Layer 3: Type Layout Recovery via args().collect() Unwrapping Chain</h2> This is another type-unwrapping chain showing how a single source call maps to assembly. The document traces five layers: IntoIter concrete layout on x64 Linux (32 bytes): phantom (PhantomData) and alloc (Global) are ZSTs: zero bytes in binary. OsString on Linux (24 bytes, stride value for heap iteration): RE implication directly stated in document: the confusing pointer arithmetic in the binary is stride-8 (reading argv[]) then stride-24 (OsString iteration). Knowing those two values makes the assembly readable. Linux vs Windows OsString stride difference (relevant if you ever need cross-platform comparison in the paper): Linux: OsString = Vec internally = 24 bytes</li> Windows: OsString = Wtf8Buf = 32 bytes (ptr, len, cap, is_known_utf8 bool padded to 8 bytes)</li> </ul> What‘s still uncertain for Part 1</h2> rust-crypto 0.2.36 comes from the Talos report reference, not from .rodata recovery in this document.</li> indicatif</a> version is not discovered (in Part 1), only confirmed by format strings, not a panic path.</li> Source links in this post are pinned to commit 79e9716c980570bfd1f666e3b16ac583f0168962 — rustc 1.74.0 stable, the toolchain that compiled this Akira v2 binary. This is recoverable directly from the binary: its .rodata embeds /rustc/79e9716c…/library/... panic paths, and it is corroborated by version-pinned FunctionID analysis resolving the sample to 1.74.0 (Updated on 10th Jun 2026).</li> unicode-width version is unconfirmed (the path is truncated to unicode-wi...</li> </ul> There will be more to be discovered in Part 2… VM setup for malware analysis</h2> To ensure this is an air-gapped VM (Windows 10) Step 1: VM network adapter (most important)</h3> In whatever hypervisor you are using: VMware Workstation/Player: VM Settings > Network Adapter > set to “Host-only” first, then ideally “No network connection” (disconnect entirely)</li> Tick “Connected” checkbox OFF</li> </ul> VirtualBox: Settings > Network > Adapter 1 > untick “Enable Network Adapter” entirely</li> Do this for all adapters (check Adapter 2, 3, 4 tabs too)</li> </ul> Hyper-V: VM Settings > Network Adapter > set to “Not Connected”</li> </ul> Step 2: Disable network inside the guest OS</h3> Even with the adapter disconnected at hypervisor level, do this inside the VM as defence in depth: # In PowerShell as Administrator Disable-NetAdapter -Name "*" -Confirm:$false </code></pre> Or via GUI: Device Manager > Network Adapters > right-click each > Disable. Step 3: Shared folders and clipboard</h3> These are your biggest risk vectors for accidental data movement: VMware: VM Settings > Options > Shared Folders > Disabled; Guest Isolation > untick both clipboard and drag-and-drop VirtualBox: Devices > Shared Folders > remove all; Devices > Shared Clipboard > Disabled; Devices > Drag and Drop > Disabled Step 4: Snapshot before touching the sample</h3> Take a clean snapshot now, before the sample is on the VM, labelled something like clean-pre-analysis. This is your recovery point if anything goes wrong. # VMware CLI alternative vmrun snapshot "path/to/vm.vmx" "clean-pre-analysis" </code></pre> Step 5: Transfer the sample safely</h3> Since shared folders should be off, transfer via: ISO mounting: package the sample into an ISO on the host, mount it read-only in the VM. The sample cannot write back through a mounted ISO.</li> Password-protected zip (password: infected is the malware research convention) mounted or copied in, then extracted inside the VM only.</li> </ul> Do not re-enable shared folders or clipboard to transfer the file. </blockquote> Step 6: Strip execute permissions immediately on arrival</h3> Once inside the VM, in PowerShell: # Confirm it is an ELF, not a PE - it should not execute on Windows anyway # but strip any accidental execute association $file = "akira_sample" # Rename with a safe extension to prevent accidental double-click Rename-Item $file "$file.bin" </code></pre> Renaming to .bin prevents Windows from accidentally associating it with anything executable. Verify your air-gap</h3> Inside the VM after setup: # Should show no active connections Get-NetAdapter | Select Name, Status ping 8.8.8.8 # Should time out with no response </code></pre> If ping times out and adapters show as Disabled or Disconnected, you are properly isolated. For the analysis involving debuggers/execution like dynamic analysis, you can also install inetSim</a>. It’s recommended to check the book Practical Malware Analysis</a>. </blockquote> Find the sample</h3> It’s encouraged to check out the CISCO Talos threat report</a> and discover the details and the hashes. Binja plugins for Rust binary & Some useful links</h2> According to Cindy Xiao’s talk/report in 2024</a>, when you discover some clues of Rust types, considering the links: https://cheats.rs/#owned-strings</a></li> https://doc.rust-lang.org/std/primitive.str.html</a></li> </ul> I would certainly recommend readers to enable those plugins before the binary analysis/REing (I didn’t enable them this time, and you can still work through it manually). Rust String Slicer (by Cindy Xiao)</a></li> Rust Demangler (by inspier)</a></li> Rust Type Layout Helper (by Cindy Xiao)</a></li> </ul> rust_string_slicer: the string problem The core issue it solves is that Rust strings are not null-terminated. A &str is a fat pointer: a (pointer, length) pair. Binary Ninja's default string scanner looks for null terminators, so it systematically misses Rust string literals or truncates them at the first zero byte in the data. This means your strings view in a naive analysis of Akira v2 will be incomplete or misleading. The plugin runs two heuristics: Recover from readonly data: it scans .rodata for cross-referenced addresses and checks whether the cross-reference site has the pattern QWORD ptr_to_string_data followed immediately by QWORD length. This recovers string slice structs laid out statically in read-only data, which is where Rust places string literals used in static contexts. Recover from code: it follows cross-references into code sections and looks for the idiom: lea rax, <string_data_addr> mov [rsp+var.ptr], rax mov [rsp+var.len], <immediate_length> </code></pre> The immediate value after the lea is the length the plugin extracts. This catches strings constructed on the stack at runtime, which the data-section heuristic cannot see. Once recovered, the plugin defines a &str type in Binary Ninja's type system with fields char* address and int64_t length, then annotates every recovered instance. The practical payoff is that you get cross-references to the &str type, which means you can enumerate all recovered string literals and their usage sites in one pass. For Akira v2, this would surface file extension lists, ransom note content, C2 strings, and any additional developer path leaks that the naive string scanner missed. Rust symbol mangling: v0 scheme</a> Rust has had two mangling schemes. The legacy scheme</a> was borrowed loosely from C++ Itanium ABI and was never formally specified. The v0 scheme</a> was stabilised in Rust 1.37 (2019) and is now the default. It is designed to be unambiguous, fully encode Rust’s type system, and be demangleable without compiler knowledge. Every v0 symbol begins with the prefix _R. After that, the symbol encodes a path followed optionally by a generic argument list and a disambiguator. The grammar is roughly: _R <path> [<generic-args>] [<instantiating-crate>] </code></pre> A concrete example: _RNvCs6XXXXXXX_5akira8compress </code></pre> Breaking this down: _R — v0 prefix</li> N — indicates a nested path follows</li> v — item type: function (v = value namespace)</li> Cs6XXXXXXX_ — crate disambiguator (a hash derived from crate metadata, ensuring uniqueness across crates with the same name)</li> 5akira — crate name, length-prefixed (5 characters: akira)</li> 8compress — function name, length-prefixed (8 characters: compress)</li> </ul> For a method on a type, the path nests further: _RNvNtCs..._5akira9Encryptor8run_pass </code></pre> Where Nt indicates a type namespace and the path encodes akira::Encryptor::run_pass. Generic instantiations Monomorphised generics encode their type arguments inline. For example, a function fn process instantiated with u64 encodes the concrete type in the symbol. This means every monomorphisation of a generic function has a distinct, demangleable symbol that tells you exactly what type it was instantiated with. In a non-stripped binary this is extremely informative for RE. In a stripped binary the symbols are gone, but if any survive (e.g. in a partially stripped binary or in exported symbols), the type information is recoverable directly from the name. Crate disambiguator The hash component (Cs6XXXXXXX_) is derived from the crate's metadata hash at compile time. This means two builds of the same crate with different dependencies or compiler flags will produce different disambiguators. It is not useful for version fingerprinting directly, but it does mean you can cluster functions by crate of origin even in a mixed binary, since all functions from the same crate share the same disambiguator hash. Why enabling the Rust demangler in Binary Ninja matters Without demangling, every Rust symbol in the function list appears as raw _RNvCs... garbage. With demangling enabled, Binary Ninja resolves these to human-readable akira::Encryptor::run_pass style names, which gives you several concrete advantages in your workflow: Crate boundary recovery: the demangled name includes the crate component, so you can immediately see which functions belong to akira, which belong to akira_utils, and which belong to std or third-party dependencies. This is directly relevant to your akira_utils finding: if any symbols survived stripping, demangling would confirm the crate attribution rather than requiring you to infer it from panic strings alone.</li> Type information from generics: monomorphised function names encode their concrete type arguments. alloc::vec::Vec::push tells you the vector element type. This is information you would otherwise have to recover through data flow analysis.</li> Call graph legibility: Binary Ninja’s call graph and cross-reference views become significantly more readable. Instead of a graph of hashes, you see a graph of akira::encrypt::* functions calling into akira_utils::*, which immediately surfaces the module structure the developer intended.</li> </ul> Caveat for stripped binaries For a fully stripped release build like Akira v2, most symbols are gone and the demangler has nothing to work with for internal functions. However it still applies to: any exported symbols (ELF binaries sometimes retain a small export table), any symbols recovered by Binary Ninja’s analysis heuristics, and any strings in .rodata that happen to contain mangled names (uncommon but not impossible). The demangler costs nothing to enable and pays off immediately if any symbols surface during analysis. rust_type_layout_helper_bn: the type layout problem This addresses a different but equally serious problem. Rust’s type system allows the compiler to reorder struct fields for optimal alignment, and enum discriminants use niche optimisation (for example, Option<Box> has no discriminant byte because a null pointer represents None). You cannot safely assume a struct's field order in the binary matches its source order. Without knowing the actual layout, every memory access in HLIL is ambiguous. The plugin works by ingesting the output of rustc's -Zprint-type-sizes flag, which emits the exact field offsets, sizes, alignment padding, and enum variant layouts for every type in a compilation. The plugin parses that output and imports it directly into Binary Ninja's type library as proper struct and enum definitions, including padding bytes, packed variants, and discriminant fields. The workflow requires you to compile a version of the target code (or a close proxy) with -Zprint-type-sizes on a nightly toolchain and redirect the output to a file, then load that file via the plugin. For malware analysis where you do not have source, you would compile the closest available open-source equivalent, or reconstruct a proxy crate that uses the same dependencies at the same versions, then import the resulting type layout. The caveat the author flags is that layout is not stable across compilations: different compiler versions, different optimisation flags, or different target platforms can change field ordering and padding. So the imported types are a strong approximation, not a guarantee. For Akira v2, given that you have aho-corasick 1.1.2 and can narrow the rustc version window via the .rustc section, you could construct a fairly tight proxy. Is this a Rust binary?</h2> Rust binaries have a distinctive fingerprint across multiple analysis layers. The confidence of identification increases as more signals converge. Panic infrastructure is the strongest single indicator. Every Rust binary compiled with std embeds panic handling machinery. Look for strings matching src/ paths with .rs extensions, often referencing crate names or Rust standard library internals. The string called Option::unwrap() on a None value or similar is essentially a Rust signature. Akira v2's TODO: panic message you found is directly in this family. Crate name recovery from panic strings is your second tier. The panic formatting system preserves file paths at compile time. You can recover internal crate names, sometimes even dependency crate names (you found aho-corasick 1.1.2 this way), and frequently leaked workspace paths such as the WSL dev path in your Akira sample. Symbol and section naming gives structural confirmation. Even in stripped release builds, section names like .rustc, rustc_debug_gdb_scripts_section (on ELF), or the presence of Rust-specific metadata embedded in the binary give it away. On Windows PE, look for .rdata strings referencing core::panicking or alloc::. Monomorphisation artefacts are visible in the function count. Rust generics are monomorphised at compile time, so a Rust binary typically has an unusually large number of small, similar functions relative to its feature surface. This is measurable in Binary Ninja by comparing function count to code size. Trait vtable layout is distinguishable from C++ vtables. Rust vtable entries for a trait object are: size, alignment, destructor pointer, then method pointers in trait-definition order. No RTTI string, no virtual inheritance complexity. C++ vtables typically have a RTTI pointer at offset -8. Standard allocator fingerprint: Rust’s default global allocator calls through __rust_alloc, __rust_dealloc, __rust_realloc. These names survive in the import table or as internal symbols even after stripping. Absence of C++ indicators is a useful negative signal: no _ZN Itanium mangled names, no type_info strings, no exception handling personality routine (__gxx_personality_v0). (Updated 10 Jun 2026) It’s A Release Build</h2> The std-DWARF leak is conditional on linking the backtrace machinery, which substantial std use pulls in. </blockquote> Akirav2 is an optimised Release build: debug = 0, overflow-checks OFF. The .debug_* sections present are **leaked precompiled-**libstd DWARF; the attacker's own code and its application dependencies carry no DWARF. "Debug" is true only colloquially (DWARF sections exist); the consequential point stands, there is no user-code debug information. AK=$(ls ~/samples_elf_v2/Akira_v2_0ee1d284*4625664 | grep -v STRIPPED | head -1) readelf -S "$AK" | grep -iE '\.debug' # are .debug_* sections present? objdump --dwarf=info "$AK" 2>/dev/null | grep -ic 'akira' # does DWARF name attacker code? objdump --dwarf=info "$AK" 2>/dev/null | grep -i 'DW_AT_name' | grep -iE 'lock|encrypt|prng' | head </code></pre> Triage summary in Binary Ninja No**.debug_* sections anywhere in the list of Binary Ninja though.** .eh_frame and .eh_frame_hdr: these are unwind tables for exception handling, present in both debug and release Rust builds, but they are not DWARF debug info</li> .gcc_except_table: exception handling landing pads, again not debug info</li> .rodata (0x438540-0x49700b): this is large at ~370KB, which is where all the Rust panic strings, format strings, and string literals live. This is your goldmine for understanding program behaviour without symbols.</li> .text (0x4c8030-0x5e529c): code segment, approximately 1.2MB of actual executable code</li> .dynsym and .dynstr: dynamic symbol table, minimal since most code is statically linked</li> </ul> Though to be honest, it’s not 100% confirming this is a release build, especially > Rust 1.77 release, the way Rust binary stored debug info changed. </blockquote> To be more confident, you might want to investigate .rodata strings are extraordinarily revealing</h2> Summary info graph of sections for this analysis In addition to the infograph above, it’s not 100% confirmed when the .debugxxx sections are absent. </blockquote> panic</code> in the string panel" loading="lazy" decoding="async" /> Search result of `panic` in the string panel .rodata</code>" loading="lazy" decoding="async" /> Some interesting strings found in the section of `.rodata` Looking at the strings section and it contains multiple critical findings: ESXi targeting confirmed: /vmfs/volumes vim-cmd vmsvc/getallvms | tail -n +2 | awk '{system("vim-cmd vmsvc/power.off " $1)}' </code></pre> This is the exact shell command to enumerate and power off all VMs on an ESXi host, confirming the Check Point analysis. ESXi is VMware’s bare-metal hypervisor. It runs directly on server hardware (no host OS underneath) and hosts multiple virtual machines. In enterprise environments it is extremely common: one physical server running ESXi might host dozens of VMs for databases, domain controllers, file servers, etc. </blockquote> Why ransomware authors love targeting it?</h3> One infection, massive blast radius. Encrypt the ESXi host and every VM it manages goes down simultaneously, rather than having to compromise each machine individually.</li> Often poorly monitored. EDR agents are rarely deployed on hypervisor hosts the way they are on Windows endpoints.</li> Critical infrastructure. Organisations are under extreme pressure to pay because their entire virtualised environment is offline.</li> NFS/VMFS datastores. VM disk images (.vmdk files) live on shared storage volumes that ESXi mounts directly, so the ransomware can enumerate and encrypt them efficiently without touching individual guest OSes.</li> </ul> The --path /vmfs/volumes default you saw in the Check Point article</a> is the standard ESXi datastore mount point. That single directory contains the disk images for every hosted VM. CLI argument strings: akiranew/src/main.rs Valid values for --logs: trace, debug, error, info, warn Root path: Starting path: /vmfs/volumes Exclude expression: Wrong regexp provided: No exclude expression </code></pre> This reveals the seahorse CLI parser argument names directly from the source path embedded in panic strings. Build ID string: Build ID not provided. </code></pre> Build ID detail useful for the analysis: The build ID for v2 (version 2024.1.30) is located at offset 0x41970 for 10 bytes. The ransomware requires either the /vmfs/volumes/ path to exist or a path to be explicitly specified, otherwise it will fail to execute entirely. This matches what Talos documented about the build ID check. Crate paths leaking source structure: /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/automaton.rs </code></pre> This is extraordinarily useful. It reveals: The developer compiled on WSL (/mnt/c/Users/user/) on a Windows host</li> The exact crate version: aho-corasick-1.1.2</li> The Cargo registry path, confirming this is a standard Cargo build</li> </ul> TODO comment leaked into binary (0x4419ce): char const data_4419ce[0xb2] = "Continuing execution in parent process, new child has pid: New child processshFailed to stop vms: TODO: panic messageFork stopvm failed" </code></pre> The string TODO: panic message appears embedded within a stopvm error handling path in .rodata, suggesting the VM shutdown error branch uses a todo!() macro or placeholder panic rather than a proper error message, indicating incomplete error handling in that specific code path. The full string at 0x4419ce is: Continuing execution in parent process, new child has pid: New child processsh Failed to stop vms: TODO: panic message Fork stopvm failed </code></pre> These are not separate panic messages concatenated by the Rust runtime. They are multiple &str literals that LLVM merged into a single**.rodata entry** at compile time. Here is why. How Rust panic strings reach .rodata</h3> Every panic!(), eprintln!(), or string literal in Rust source becomes a &'static str pointing into .rodata. The Rust compiler lowers panic!("some message") roughly to: core::panicking::panic_fmt(format_args!("some message")) </code></pre> The format_args! macro constructs a fmt::Arguments struct at compile time. For simple string literals with no format arguments, LLVM sees these as adjacent static string data and, during its string merging optimisation pass (-O2/-O3), physically concatenates adjacent string literals that share no null terminator dependency into a single .rodata blob. The individual strings are then referenced by pointer and length pairs into offsets within that blob. What you are seeing at 0x4419ce</h3> Binja is showing you a single 178-byte (0xb2) merged blob containing what were originally four separate string literals in the source: Why LLVM merges them</h3> With --release and LTO enabled, LLVM's MergeGlobals and ConstantMerge passes fold adjacent read-only string data into contiguous blobs. Binja then displays the entire blob as one char const array from the start address to the end of the last string in the merged region. The individual strings are still referenced separately in the code via (ptr, len) fat pointer pairs pointing into offsets within the blob. Verifying this in Binja</h3> Cross Ref of 0x4419ce To confirm the individual string boundaries, look at the cross-references to 0x4419ce. Each xref will use a different offset into the blob with a different length, corresponding to one of the original source strings. For example: 0x4419ce + 0x00, len=0x3c = "Continuing execution..."</li> 0x4419ce + 0x3c, len=0x12 = "New child process..."</li> 0x4419ce + 0x4e, len=0x27 = "Failed to stop vms: TODO: panic message"</li> 0x4419ce + 0x75, len=0x12 = "Fork stopvm failed"</li> </ul> In Binja: right-click on data_4419ce > Cross References, and you will see each reference using a different offset, confirming the individual string boundaries. </blockquote> Windows version regex in**.rodata:** win10-3(.*)(.*)|win10-4(.*)(.*)|win10-5(.*)(.*) </code></pre> Interesting: Windows version detection strings in a Linux ELF. This likely comes from a dependency that includes cross-platform compatibility checks. </blockquote> aho-corasick crate confirmed: This is a string searching library, used here likely for file extension matching when deciding which files to encrypt. Additional crate paths confirmed: /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/util/alphabet.rs /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/util/debug.rs /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/util/remapper.rs /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/util/primitives.rs </code></pre> Standard library paths: library/alloc/src/raw_vec.rs library/alloc/src/ffi/c_str.rs library/alloc/src/sync.rs library/alloc/src/vec/mod.rs library/alloc/src/fmt.rs </code></pre> lazy_st crate (truncated): /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lazy_st... </code></pre> This is almost certainly lazy_static or once_cell, used for global state initialisation. Common in Rust malware for initialising encryption keys or configuration once at startup. Xref This is the cross-reference panel for the lazy_st blob, not the next address. But the code reference is extremely revealing: _$LT$alloc..string..FromUtf8Error$u20$as$u20$core..fmt..Debug$GT$::fmt::h510500198db9042f </code></pre> And the instruction: lea rsi, [rel 0x442525] </code></pre> This tells you the code is loading a pointer into the middle of the blob at 0x442525, which is an offset within data_4424b7. The mangled symbol name FromUtf8Error confirms this blob is primarily about the alloc::string::FromUtf8Error Debug implementation, and lazy_st is simply the tail end of an adjacent panic path that got merged into the same blob. Navigate to 0x442525 directly in Binja to see what the string looks like from that offset. But more importantly, to find the continuation of lazy_st, go to: g -> 0x442580 </code></pre> That is 0x4424b7 + 0xc9, the first byte after this blob ends. What Binja shows there will either be a new char const entry starting with atic or a completely unrelated string. Share that screenshot and we will know definitively. Now confirmed. Look at address 0x500ba0: lea rsi, [rel data_4424b7[0x6e]] </code></pre> And Binja’s inline comment shows the full string at that offset: "FromUtf8Error/mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lazy_static-1.4.0/src/inline_lazy.rs/mnt/c/Users/user/.c </code></pre> Confirmed: lazy_static-1.4.0 The exact version is 1.4.0, not unknown. The source file is inline_lazy.rs, which is the internal implementation file for lazy_static's hidden static guarding mechanism. .../lazy_static-1.4.0/src/inline_lazy.rs/mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/unicode-wi </code></pre> New crate partially confirmed: unicode-wi... This is almost certainly unicode-width, a standard Rust crate for determining the display width of Unicode characters. It is a very common dependency pulled in by terminal/CLI output crates. Given Akira v2 uses indicatif</a> for progress bars and simplelog for logging, unicode-width as a transitive dependency makes complete sense. To confirm the full name and version, navigate to the next address after this blob ends in Binja. The continuation should show dth-x.x.x completing unicode-width. Rust struct names leaking: FatAVX2, SlimSSSE3, SlimAVX2 are Rust struct names defined inside aho-corasick</a>'s Teddy packed search engine</a>. They are not algorithm names in the abstract sense. Specifically for SIMD backend implementations of the Teddy packed search algorithm.: SlimSSSE3 is a struct wrapping a 128-bit SSSE3 Teddy searcher</li> FatAVX2 is a 256-bit AVX2 fat Teddy searcher.</li> These are selected at runtime based on CPU feature detection: SlimSSSE3 is chosen when AVX2 is unavailable, FatAVX2 when AVX2 is available and the fat variant is preferred.</li> </ul> FatAVX2fat256teddymasksFatInvalidInputAnchoredInvalidInputUnanchoredUnsupportedStreamgotUnsupportedOverlappingPackedRareByteOffsetRa... /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aho-corasick-1.1.2/src/util/remapper.rsLeftmostLongestRabinKarpsearch_kindby_idordertotal_pattern_bytesbucketsimpmemory_usageSlimSSSE3slim128sl </code></pre> akira_utils/src/lib.rs: /mnt/c/Users/user/.cargo/registry/src/...akira_utils/src/lib.rs </code></pre> Look carefully at line 004423e0: a_utils/src/lib.rs. Combined with the prefix on the line above ending in akir, this reads as akira_utils/src/lib.rs. This is a custom internal crate named akira_utils, not a public crates.io dependency. This means the malware authors structured their code as a Cargo workspace with at least one internal library crate. What this tells you about the binary structure</h2> You can now reconstruct a partial Cargo.toml dependency tree purely from .rodata: [dependencies] aho-corasick = "1.1.2" # confirmed, multiple source files lazy_static = "1.4.0" # Confirmed [workspace] members = [ "akira_utils", # internal crate confirmed ] </code></pre> The crates.io registry hash 6f17d22bba15001f is consistent across all paths, confirming these all came from the same Cargo build environment and the same registry snapshot. Panic String Analysis</h2> This is a strong methodological point: panic string analysis recovers the internal crate architecture of a stripped Rust binary without any symbol information. Specifically: </blockquote> Internal workspace crate names (akira_utils) recoverable</li> Exact third-party crate versions (aho-corasick-1.1.2) recoverable</li> Developer platform (WSL on Windows, same username user throughout) recoverable</li> SIMD feature flags (AVX2, SSSE3) inferable from algorithm variant names</li> </ul> None of this requires DWARF, symbol tables, or dynamic analysis. It is purely static .rodata recovery </blockquote> Additional crates and internal paths Additional crates and internal paths</h2> New crate confirmed: block-buffer-0.10.4 /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/block-buffer-0.10.4/src/lib.rs </code></pre> This is a cryptography support crate used by digest algorithm implementations. Confirms the crypto pipeline more precisely. New crate confirmed: sha3-0.10.8 /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sha3-0.10.8/src </code></pre> SHA-3 hashing, likely used for key derivation or integrity checking. New crate confirmed: simplelog-0.12.1 /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/simplelog-0.12.1/src/loggers/writelog.rs </code></pre> This is the logging crate. Confirms the --logs trace/debug/error/info/warn CLI argument you saw earlier. New crate confirmed: seahorse-2.2.0 /mnt/c/Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/seahorse-2.2.0/src/flag.rs </code></pre> The CLI argument parser, version now precisely pinned. Internal source paths: akiranew/src/path_finder.rs akira_v2::path_finder </code></pre> Confirms a dedicated path_finder module for filesystem enumeration. akiranew/src/lock.rs </code></pre> The encryption locking module, source path directly visible. ESXi path exclusions visible: /proc/sbin/lib64/locker/productLocker/lost+found/bootbank/altbootbank/tardisks/vmfs/volumes/BOOTBANK1/vmfs/volumes/BOOTBANK2/vmfs/devices/vmimages/vmupgrade/bootpart.gz/local.tgz/local.tgzlog </code></pre> These are ESXi-specific paths that the ransomware skips during encryption. Directly recoverable from static analysis. ThreadPool::execute error string: ThreadPool::execute unable to send job into queue. </code></pre> Confirms a custom thread pool implementation with explicit error handling. indicatif</a> spinner format strings: {spinner:.green} [{elapsed_precise}] {msg} [{wide_bar:.cyan/blue}] {bytes}/{total_bytes} ({eta}) </code></pre> The progress bar format string from the indicatif</a> crate, directly confirming its use for operator-facing encryption progress display. mpmc/mod.rs path: /mpmc/mod.rs </code></pre> Multi-producer multi-consumer channel, part of the threading architecture for parallel encryption workers. The ransom note is embedded directly in .rodata</h2> This is a significant finding. The entire akiranew.txt ransom note text is stored as a static string literal in .rodata starting around 0x440da0. Visible fragments include: Decryptor offer and negotiation text</li> .3. The security report or the exclusive first-hand information</li> Reference to darkmarket sale threat</li> Onion address: akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad[.]onion</li> TOR browser instructions</li> Chat link: https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id[.]onion</a></li> Code: 7818-NX-VVGG-FSFV</li> </ul> This is the complete ransom note hardcoded as a single static string, not generated dynamically at runtime, it is a compile-time constant embedded verbatim. Encryption operational strings</h2> prng.rs internal source path: akiranew/src/prng.rs </code></pre> A first-party PRNG module (akiranew/src/prng.rs) in the malware’s own source tree. Correction (24 June 2026): an earlier version suggested the authors hand-rolled a generator instead of using a crate. The binary shows otherwise. It links rand 0.8.5, rand_chacha 0.3.1 and getrandom 0.2.10, and the demangled symbols expose ThreadRng as ReseedingRng<ChaCha12Core, OsRng>, that is, the standard ChaCha12 CSPRNG reseeded from OsRng. No hand-rolled LCG or xorshift constants are present. So prng.rs is best read as a thin first-party wrapper over the rand crate (used for key material and random IDs), not a bespoke generator. Threading and file locking strings: num_threads: Free threads available: /akiranew.txt note write fail File crypting File crypted Thread crashed. File doesn't locked. Error: Count of locking attempts for file is exceeded Done </code></pre> These are all operator-facing runtime status messages. Crucially akiranew/src/prng.rs is the source file for the PRNG, and the locking attempt counter confirms a retry mechanism for file locking during encryption. Encryption progress format strings: ; stepsize MB was read from the file Unable to seek to position Seek position of file : [] MB, buffer size is , block counter = Current buffer for ] MB is filled of zeros, skipping...{prefix:.bold.dim} {spinner} {wide_msg} {bytes_per_sec} </code></pre> These reveal the chunked encryption algorithm: the binary reads files in blocks (stepsize MB), seeks to positions, skips zero-filled blocks, and reports bytes per second to the operator. akira_v2::lock namespace confirmed: akira_v2::lock6edd23fc19cbb91fa5574afbcfc81fb0e368be2b42f825e3e9f48dcbc38a0525 </code></pre> This mangled symbol name contains what appears to be a hash suffix, consistent with Rust’s symbol mangling scheme for disambiguating generic instantiations. Wrong secret key format error: Wrong secret key format. A hex string of 64 chars is expected </code></pre> Reveals the encryption key is passed as a 64-character hex string (32 bytes), consistent with a 256-bit key. Updated Cargo dependency table</h2> Internal modules recovered: akira_utils, path_finder, lock, prng All of this is recoverable purely from .rodata static analysis without executing the binary, without DWARF, and without symbols. That is your core thesis demonstrated in practice. The full CLI help string recovered at 0x441603</h2> This is the most valuable string in the screenshot. The complete help text is visible: Start path. Default value: /vmfs/volumes idstopvm vmonlyCrypt only .vmdk, .vmem, .vmx, .log, .vswp, .vmsd, .vmsn files threadsNumber of threads (1-1000). Default: number of logical CPU cores epPercent of crypt. Default - 15% Work in background Print logs. Valid values for: trace, debug, error, info, warn. Default: off excludeSkip files by "regular" extension. Example: --exclude="startf" </code></pre> This reconstructs the complete CLI interface of Akira v2: The --ep 15% default is particularly significant: Akira v2 only encrypts 15% of each file by default, which is a deliberate speed optimisation. Enough to corrupt the file but fast enough to maximise the number of files encrypted before detection. Regex exclusion pattern at 0x441780</h2> ilename(.*)(.*)" using this regular expression will skip all files starting with startfilename and having any extensions. Multiple regular expressions using "|" can also be processed: --exclude="(win10-3(.*)(.*))|(win10-4(.*)(.*))|(win10-5(.*)(.*)) </code></pre> This is the help text for --exclude, and the example regex win10-3|win10-4|win10-5 is revealing: it shows the operators were using Windows version strings as exclusion patterns, suggesting they selectively avoided encrypting certain Windows VM guests while targeting others. akiranew/src/main.rs source path confirmed at 0x4418a5</h2> akiranew/src/main.rstraced </code></pre> The source file name akiranew/src/main.rs is directly embedded, confirming the project root crate name is akiranew, not akira_v2. The v2 designation is a researcher label, not the developer's own naming. The 0x4419ce string context now fully clear</h2> With this screenshot you can see the string immediately above 0x4419ce: d vmsvc/getallvms | tail -n +2 | awk '{system("vim-cmd vmsvc/power.off " $1)}' </code></pre> Then at 0x4419ce: Continuing execution in parent process, new child has pid: New child processsh Failed to stop vms: TODO: panic message Fork stopvm failed Logical CPUs: Threads are set: EP values </code></pre> This gives you the full operational sequence of the --stopvm and --fork flow: Execute shell command to power off all VMs</li> Fork child process for encryption</li> Report child PID to operator</li> If stopvm fails: emit the TODO: panic message placeholder error</li> Report thread and EP configuration</li> </ol> The TODO: panic message is definitively the stopvm failure error handler, confirming it is a developer placeholder left in the stopvm error branch specifically. Interactive prompt strings at 0x441a80</h2> is 0 to 100. EP are set: %[1/2] Do you want to continue? (y/n). </code></pre> And at 0x441abe: Failed to read line Invalid input. Please enter 'y' or 'n'. Exiting... Continuing... </code></pre> This reveals Akira v2 has an interactive confirmation prompt before beginning encryption, where the operator confirms the EP percentage and thread settings. This is an operator safety check, not something visible in prior published analyses. Updated internal module map</h2> You can now reconstruct the project structure almost completely from .rodata alone: akiranew/ ├── src/ │ ├── main.rs (CLI parsing, interactive prompt, fork/stopvm) │ ├── lock.rs (encryption logic) │ ├── path_finder.rs (filesystem enumeration) │ └── prng.rs (custom PRNG) └── Cargo.toml (workspace member: akira_utils) </code></pre> All recovered without symbols, without DWARF, purely from panic strings and format literals in .rodata. This is now a very strong empirical demonstration of your thesis. Updated dependency table</h2> The Control Flow Map</h2> The top-level call chain is: main -> default_action -> lock -> lock_closure </code></pre> main: collects CLI arguments, initialises the seahorse App struct, calls app.run(args).</li> default_action: the seahorse callback; reads flag values, optionally shuts down VMs, then calls lock.</li> lock: launches worker threads.</li> lock_closure: the actual encryption logic, running per thread.</li> </ul> Section 1: How args().collect() Works</h2> The malware’s first action is: let program_args: Vec<String> = args().collect(); </code></pre> Tracing what this produces in memory requires following a four-layer type unwrapping chain. The unwrapping chain</h2> The article traces the type system from the public API down to bytes. Each step is a wrapper that hides the real representation. std::env::args() -> returns Args -> wraps ArgsOs -> wraps sys::args::Args (PAL type, OS-specific) -> on Unix: Vec<OsString>.into_iter() -> IntoIter<OsString> </code></pre> The key insight: the public type Args and its iterator wrapper are thin newtypes. By the time you reach the PAL implementation, the real data is a Vec that was built by reading argc/argv from C FFI, then converted to OsString entries. </blockquote> The std::env::args()</a> function returns Args, which wraps ArgsOs, which wraps sys::args::Args. Both outer wrappers are zero-overhead newtypes. The real work happens in sys/pal/unix/args.rs</a>, the PAL (Platform Abstraction Layer) implementation for Unix targets. This file does not live in the main std source tree. It is swapped in at compile time based on the target OS, which is why you cannot find sys::args::args by grepping the standard library directly. Step 1: The Public API</h2> From env.rs</a> (line ~756): pub struct Args { inner: ArgsOs, } pub struct ArgsOs { inner: sys::args::Args, } pub fn args() -> Args { Args { inner: args_os() } } pub fn args_os() -> ArgsOs { ArgsOs { inner: sys::args::args() } } </code></pre> Args and ArgsOs are pure newtypes. They add zero bytes of overhead. The only real data lives in sys::args::Args, which is a PAL type. sys::args::Args</a> is a PAL type because its concrete definition lives inside one of those OS-specific directories, not in a shared location. On Unix (which includes ESXi/Linux), it is defined in sys/pal/unix/args.rs</a>(line ~61) as: pub struct Args { iter: vec::IntoIter<OsString>, } </code></pre> On Windows it would be defined differently, potentially with a different internal representation. I will list them in the section of Further Reading below. Note: The practical consequence for RE is that if you look for sys::args::Args in the main standard library source you will not find it, because there is no single canonical definition. You have to know which PAL branch was compiled in, which is determined by the binary's target OS. For Akira v2 targeting ESXi, that means the Unix branch, and therefore the vec::IntoIter layout we traced through. </blockquote> Step 2: The PAL Implementation (Unix)</h2> PAL stands for Platform Abstraction Layer. It is a pattern in the Rust standard library where OS-specific implementations are swapped in at compile time based on the target platform. </blockquote> The way it works structurally is that std has a module sys::pal with subdirectories for each supported OS: std/src/sys/pal/ unix/ windows/ wasi/ ... </code></pre> Each subdirectory implements the same interface, but with platform-native code inside. The compiler selects the correct one via #[cfg(target_os = "...")] attributes. The rest of std calls into sys::pal without knowing or caring which OS is underneath. Because Akira v2 targeted ESXi (Linux-based), the relevant PAL is sys/pal/unix/args.rs</a>. The article quotes the full function: /// Returns the command line arguments pub fn args() -> Args { let (argc, argv) = imp::argc_argv(); // (1) let mut vec = Vec::with_capacity(argc as usize); for i in 0..argc { let ptr = unsafe { argv.offset(i).read() }; // (2) if ptr.is_null() { break; } let cstr = unsafe { CStr::from_ptr(ptr) }; // (3) vec.push(OsStringExt::from_vec(cstr.to_bytes().to_vec())); // (4) } Args { iter: vec.into_iter() } // (5) } </code></pre> What each line does: (1) argc_argv() calls into the C runtime via FFI. On Linux, argc and argv are passed into the process by the kernel via the ELF aux vector and made available through glibc's .init_array mechanism. This gives you the classic C int argc, char** argv pair. (2) argv.offset(i).read() is raw pointer arithmetic. argv is a *const *const c_char. .offset(i) moves the pointer by i * 8 bytes (on x64), then .read() dereferences it, giving you a *const c_char pointing to the i-th argument string. (3) CStr::from_ptr(ptr) wraps that pointer as a null-terminated C string, no copy yet. (4) cstr.to_bytes().to_vec() copies the raw bytes (excluding the null terminator) into a Vec, then OsStringExt::from_vec wraps that as an OsString. On Linux, OsString is literally just a Vec (three words: ptr, len, cap). (5) vec.into_iter() is the key transformation. It consumes the Vec and produces a vec::IntoIter. This is what sys::args::Args actually stores. Step 3: The Concrete Memory Layout</h2> The definitionof IntoIter</a> in the current compiler source (lines 45–61 of into_iter.rs</a>) is: pub struct IntoIter<T, A: Allocator = Global> { pub(super) buf: NonNull<T>, // pointer to start of heap allocation pub(super) phantom: PhantomData<T>, // zero-size, no bytes pub(super) cap: usize, // total capacity pub(super) alloc: ManuallyDrop<A>, // allocator (Global = zero-size) pub(super) ptr: NonNull<T>, // pointer to next element to yield pub(super) end: *const T, // pointer one-past last remaining element } </code></pre> With the default Global allocator (which is zero-sized), the in-memory layout on x64 is: Total: 32 bytes on x64. phantom and alloc (Global) contribute zero bytes. The actual OsString</a> objects live on the heap at the address buf points to. </blockquote> Each OsString</a> on that heap is, on Linux, a Vec</a> internally: [ ptr: 8 bytes ][ len: 8 bytes ][ cap: 8 bytes ] </code></pre> RawVec</a> struct definition</h3> PhantomData is zero-sized. Global allocator is zero-sized. Cap is #[repr(transparent)] over usize. Unique is a non-null pointer, 8 bytes on x64. pub(crate) struct RawVec<T, A: Allocator = Global> { inner: RawVecInner<A>, _marker: PhantomData<T>, } struct RawVecInner<A: Allocator = Global> { ptr: Unique<u8>, cap: Cap, alloc: A, } </code></pre> So if you ran the binary with three arguments, the heap buffer at buf would contain three consecutive 24-byte structs, each pointing to its own heap allocation holding the raw argument bytes. Quick recap</h2> We still have a long road to go from here… 1. Entry point</h3> pub fn args() -> Args { Args { inner: args_os() } } pub fn args_os() -> ArgsOs { ArgsOs { inner: sys::args::args() } // calls into PAL } </code></pre> Both Args and ArgsOs are newtypes. Zero overhead. 2. PAL for Linux ( sys/pal/unix/args.rs)</h3> The imp module for Linux stores argc/argv as two atomics set during process init (link</a> here, line 129–130): static ARGC: AtomicIsize = AtomicIsize::new(0); static ARGV: AtomicPtr<*const u8> = AtomicPtr::new(ptr::null_mut()); </code></pre> These are populated via .init_array.00099</a> (on glibc Linux) before main runs. The function argc_argv()</a> simply reads them with Ordering::Relaxed</a>. Then args()</a> builds the Vec</a>: pub fn args() -> Args { let (argc, argv) = imp::argc_argv(); let mut vec = Vec::with_capacity(argc as usize); for i in 0..argc { let ptr = unsafe { argv.offset(i).read() }; if ptr.is_null() { break; } let cstr = unsafe { CStr::from_ptr(ptr) }; vec.push(OsStringExt::from_vec(cstr.to_bytes().to_vec())); } Args { iter: vec.into_iter() } } </code></pre> And sys::args::Args</a> is defined immediately below in the same file: pub struct Args { iter: vec::IntoIter<OsString>, } </code></pre> So sys::args::Args is just a newtype over vec::IntoIter. Nothing more. 3. Concrete memory layout</h3> After vec.into_iter(), on x64 Linux with Global</a> allocator: IntoIter<OsString> (32 bytes on stack or in parent struct): +0x00 buf (NonNull<OsString>) = pointer to heap buffer +0x08 cap (usize) = total allocated slots +0x10 ptr (NonNull<OsString>) = next element to yield +0x18 end (*const OsString) = one past last element </code></pre> Each OsString on the heap is a Vec</a> (on Linux), so each slot in the buffer is 24 bytes: OsString (24 bytes): +0x00 ptr (*mut u8) = pointer to the argument string bytes +0x08 len (usize) = length of the string +0x10 cap (usize) = capacity </code></pre> 4. What next() looks like in assembly</h3> Each call to next() does: Compare ptr against end. If equal, return None.</li> Read the OsString at ptr (24 bytes).</li> Increment ptr by 24 (size_of::() on Linux).</li> Return Some(osstring).</li> </ol> When the outer Args::next() in env.rs is called, it additionally calls .into_string().unwrap() on the OsString, which validates UTF-8 and either reuses the allocation or panics. The Key RE Insight</h2> When you see the assembly for args().collect() in the Akira v2 binary, the confusing pointer arithmetic is exactly this: reading the ARGC/ARGV globals, looping over argv with stride-8 pointer arithmetic, copying each C string into a heap Vec, and building the IntoIter header. The collect() on top then walks ptr..end with stride-24 arithmetic, converting each OsString to String. Once you know those two stride values (8 for *const c_char, 24 for OsString on Linux), the assembly becomes readable. What argc_argv() does on Linux</h3> The PAL’s argc_argv() function reads two atomics, ARGC and</a> ARGV</a>, that were written during process initialisation. On glibc Linux, a function registered in .init_array.00099 receives (argc, argv, envp) from glibc before main runs and stores them in these atomics. Reading them back is a single Ordering::Relaxed load on each. Building the Vec</h3> The args() function then: Calls Vec::with_capacity(argc as usize) to pre-allocate.</li> Iterates 0..argc, using raw pointer arithmetic (argv.offset(i).read()) to read each *const c_char.</li> Wraps each pointer as a CStr, copies the bytes into a Vec via to_bytes().to_vec(), and pushes it as an OsString via OsStringExt::from_vec.</li> Calls vec.into_iter(), producing a vec::IntoIter.</li> </ol> On Linux, OsString is a Vec internally: a 24-byte (ptr, len, cap) triple. The concrete memory layout</h3> The vec::IntoIter</a> struct (actual source, not the simplified nomicon version) has these fields: buf: NonNull<T> // 8 bytes: pointer to heap allocation cap: usize // 8 bytes: total capacity alloc: ManuallyDrop<A> // 0 bytes: Global allocator is ZST ptr: NonNull<T> // 8 bytes: next element to yield end: *const T // 8 bytes: one-past-last element </code></pre> Total header: 32 bytes on x64. The heap buffer at buf holds argc consecutive 24-byte OsString values. Iteration advances ptr by 24 bytes per call to next() and stops when ptr == end. When collect() runs on the outer Args iterator, each OsString is validated as UTF-8 and converted to String. The final result is a Vec, itself a 24-byte (ptr, len, cap) on the stack. RE implication: the confusing pointer arithmetic around args().collect() in the binary is stride-8 (reading argv[]) followed by string copies followed by stride-24 iteration. Once you know those two stride values, the assembly becomes readable. Further Reading</h2> 1. Some useful crates for CLI development</h3> There are several established approaches in Rust: Full-featured crates: clap</a> : the dominant choice, supports derive macros, subcommands, validation, shell completions</li> argh</a> : Google’s crate, derive-based, optimised for binary size</li> </ul> Minimal/lightweight crates: pico-args</a> : zero dependencies, manual parsing, very small</li> lexopt</a>: low-level, explicit, good for when you want full control</li> seahorse</a> : what Akira used, builder pattern, minimal</li> </ul> Manual approaches: std::env::args() directly: no dependency, just iterate and match strings yourself</li> std::env::args_os(): same but keeps OsString, useful when arguments may not be valid UTF-8</li> </ul> Other: structopt</a>: older derive-based approach, now largely superseded by clap v3+</li> </ul> For malware authors, the interesting trade-off is binary size and recognisability. clap produces very identifiable strings and patterns in the binary. seahorse or pico-args leave a much smaller and less distinctive footprint, which may be part of why it was chosen here. 2. Windows vs Linux: Building the Vec</h2> The two implementations are fundamentally different because Windows and Unix have different models for how arguments reach a process. The core difference</h3> On Linux, the kernel passes arguments as a char** argv array: each argument is already a separate null-terminated byte string. The PAL just reads them one by one. On Windows, there is no argv array. The Win32 API delivers the entire command line as a single UTF-16 string via GetCommandLineW(). The PAL has to parse that string itself to split it into individual arguments. What the Windows args() does</h3> Source code is here</a> (line 21), path is Rust/library/std/src/sys/pal/windows/args.rs#L21 </blockquote> pub fn args() -> Args { // SAFETY: `GetCommandLineW` returns a pointer to a null terminated UTF-16 // string so it's safe for `WStrUnits` to use. unsafe { let lp_cmd_line = c::GetCommandLineW(); // (1) let parsed_args_list = parse_lp_cmd_line( // (2) WStrUnits::new(lp_cmd_line), || current_exe()... ); Args { parsed_args_list: parsed_args_list.into_iter() } } } </code></pre> (1) GetCommandLineW() is a Win32 API call returning a pointer to a null-terminated UTF-16 string. The entire command line is one blob, e.g. myapp.exe --threads 8 --stopvm. (2) parse_lp_cmd_line is a hand-written parser implementing the Microsoft C/C++ argument parsing rules</a>. It handles: Whitespace as argument separators</li> Quoted strings (space inside quotes is literal)</li> Backslash escaping before quotes (odd number of backslashes escapes the quote)</li> Double-quote escaping inside a quoted string</li> </ul> Each parsed token is pushed as OsString::from_wide(&cur[..]), converting UTF-16 code units into a WTF-8</a> encoded OsString. Wtf8Buf</a> has exactly two fields: bytes (a Vec, which is 24 bytes on x64: ptr, len, cap) and is_known_utf8 (a bool, 1 byte, padded to 8 bytes by alignment). So Wtf8Buf is 32 bytes on x64. </blockquote> pub struct Wtf8Buf { bytes: Vec<u8>, is_known_utf8: bool, } </code></pre> Step-by-step comparison table</h3> RE implication</h3> The final Args struct on both platforms is identically vec::IntoIter, so the iteration pattern in assembly looks the same. The difference is everything before that: on Windows you will see a call to GetCommandLineW followed by a parsing loop with quote and backslash handling, where on Linux you will see atomic loads and a simple copy loop. The 32-byte vs 24-byte OsString stride difference also means the heap buffer iteration uses stride-32 on Windows vs stride-24 on Linux. References</h2> Check Point Research (2023) Rust Binary Analysis Feature by Feature. Available at: https://research.checkpoint.com/2023/rust-binary-analysis-feature-by-feature/</a> Check Point Research (2024) Inside Akira Ransomware’s Rust Experiment. Available at: https://research.checkpoint.com/2024/inside-akira-ransomwares-rust-experiment/</a> Cisco Talos (2024) Akira Ransomware Continues to Evolve. Available at: https://blog.talosintelligence.com/akira-ransomware-continues-to-evolve/</a> console-rs (no date) indicatif. Available at: https://github.com/console-rs/indicatif/blob/0c037edc86449d84aa457d7d5db80b4166c18d6b/examples/yarnish.rs</a>. ksk001100 (no date) seahorse. Available at: https://github.com/ksk001100/seahorse</a> Rust Project (no date) std::vec::IntoIter source. Available at: https://doc.rust-lang.org/src/alloc/vec/into_iter.rs.html#45-48</a> Rust Project (no date) sys/pal/unix/args.rs. Available at:https://github.com/rust-lang/rust/blob/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys/unix/args.rs</a> Sapin, S. (no date) WTF-8: A superset of UTF-8. Available at: https://simonsapin.github.io/wtf-8/</a> Wikipedia (no date) cgroups. Available at: https://en.wikipedia.org/wiki/Cgroups</a> Vector 35 (no date) Signature libraries. Binary Ninja. Available at: https://binary.ninja/2020/03/11/signature-libraries.html</a> Microsoft Security (no date) Unveiling RIFT: Enhancing Rust malware analysis through pattern matching. Microsoft Security Blog. Available at: https://www.microsoft.com/en-us/security/blog/2025/06/27/unveiling-rift-enhancing-rust-malware-analysis-through-pattern-matching/</a> Vector 35 (no date) binaryninja.demangle — Binary Ninja API documentation. Binary Ninja. Available at: https://api.binary.ninja/_modules/binaryninja/demangle.html</a> Vector 35 (no date) binaryninja::demangle — Binary Ninja Rust API. Binary Ninja. Available at: https://rust.binary.ninja/binaryninja/demangle/index.html</a>

References</h3>

The Graphic Overview of lock</h2>
</p>

Step 7 — Shared mutex and thread-limit semaphore</h2>
Address range:</strong> 0x4d3d91 -- 0x4d3dab</p>
</p>

Further Reading</h2>

References</h3>

Info of the binary in this analysis</h2>

Section 3: Inlining Cascade</h2>

Indicatif</h2>

Section 4: available_parallelism()</h2>

Further Reading</h2>

Common SIMD instructions worth recognising</h3>
</p>
vzeroupper in particular is a useful marker: it almost always appears at the end of a function that used AVX, so it helps you identify function boundaries in stripped binaries.</p>

2. How aho-corasick uses memchr and SIMD</h2>

Lock-Free Programming</h2>
Let’s have a quick recap before discussing this instruction…</p>

Where lock cmpxchg comes from in your binary</h2>

VM setup for malware analysis</h2>
To ensure this is an air-gapped VM</strong> (Windows 10)</p>

Find the sample</h3>
It’s encouraged to check out the CISCO Talos threat report</a> and discover the details and the hashes.</p>

Updated dependency table</h2>
</p>

Quick recap</h2>
</p>
We still have a long road to go from here…</p>

Step-by-step comparison table</h3>
</p>

Yen Wang

What Happens to Rust Ownership When You Compile It?

Comparison Table</h2>
</p>

Reversing Akira's Rust Experiment: A Breakdown, Part 3

Reversing Akira's Rust Experiment: A Breakdown, Part 2

Decoding UTF-8 Hex Strings in Python

Demangling the Symbol in Rust Binary:

Interesting instructions in Rust binary: lock cmpxchg

Assembly Breakdown: x86-64 structure alignment examples

Reversing Akira's Rust Experiment: A Breakdown, Part 1

Voldemort Type in Rust, C/C++, Zig, Go and Haskell

Rust Syntax Sugars That Make Your Code Sweeter

Yen Wang

What Happens to Rust Ownership When You Compile It?

Comparison Table</h2> </p>

Reversing Akira's Rust Experiment: A Breakdown, Part 3

Table of Contents</h2> Info of the binary in this analysis</li> Section 5: lock and Thread Spawning</li>

Further Reading</h3> Why UAWAVAUATSH exists</li> </ol> </li>

References</h3>

Reconstructing the lock function</h2> Before beginning reconstruction, the build environment is fixed from binary evidence.</p> </blockquote> </p> The source file for lock is confirmed as akiranew/src/lock.rs from the .data.rel.ro log format metadata at 0x5e7028:</p>

The Graphic Overview of lock</h2> </p>

Step 1 — Function prologue and argument layout</h2> Address range:</strong> 0x4d38a5 -- 0x4d38d2</p> </p>

Step 3 — MultiProgress and Arc allocation</h2> Address range:</strong> 0x4d390c -- 0x4d3951</p> </p> Two consecutive exchange_malloc calls allocate the MultiProgress and its internal shared state. Both follow the same Arc field initialisation pattern:</p>

Step 4 — File iterator construction</h2> Address range:</strong> 0x4d397d -- 0x4d39b0</p> </p> This is the single most important structural divergence from yarnish.rs. The yarnish.rs example iterates (0..4u32) which is a fixed range. Akira iterates the file list directly:</p>

Step 5 — Per-iteration seed generation (Akira-specific)</h2> Address range:</strong> 0x4d3c69 -- 0x4d3d1c</p> </p> There is no equivalent in yarnish.rs. This block is unique to Akira.</p>

Step 7 — Shared mutex and thread-limit semaphore</h2> Address range:</strong> 0x4d3d91 -- 0x4d3dab</p> </p>

PathBuf layout</h3> The layout of PathBuf on x86_64-unknown-linux-gnu at the pinned commit is (ptr, len, cap) = 3 × 8 = 24 bytes.</p> The proof chain is:</p>

Step 13 — Join loop and Mutex cleanup</h2> Address range:</strong> 0x4d3b40 -- 0x4d3b9f</p> </p>

Reconstructed source</h2> Combining all steps, the reconstructed lock function is:</p>

Further Reading</h2>

The encoding mechanics</h3> The opcode map file is stable across kernel versions for x86–64, the encodings do not change. But I pin v6.11 rather than master, for the same reason the Rust stdlib commit pinned here: reproducibility.</p> </blockquote>

Reversing Akira's Rust Experiment: A Breakdown, Part 2

Table of Contents</h2> Info of the binary in this analysis</li> LLVM’s picks on scalar moves</li> Section 2: The CLI Framework (seahorse)</li> Section 3: The inlining cascade</li> Section 4: available_parallelism()</li>

Further Reading</h3> SIMD</li> </ol> </li>

References</h3>

Info of the binary in this analysis</h2>

Section 3: Inlining Cascade</h2>

Indicatif</h2>

Section 4: available_parallelism()</h2>

Quick Recap</h3> Before diving deeper, Let’s recap what we had found so far:</p>

What we are going to discover:</h3> The structure of the threading code</strong> in default_action matches yarnish.rs's pattern: spawning N threads, collecting handles into a Vec, joining them</li>

How to verify bitmask</h3> Verify the bitmask with correct</strong> libc version:</strong></p>

Proving the chain: count_ones() to llvm.ctpop.i64</h2> A brief summary:</strong></p>

Now let’s breakdown step by step.</h3> Layer 1:</strong> count_ones() to</strong> core::intrinsics::ctpop</strong></p>

Further Reading</h2>

1. SIMD</h2> SIMD stands for Single Instruction, Multiple Data</strong>. It is a CPU execution model where one instruction operates on multiple data elements in parallel, using wide registers.</p> </blockquote>

Common SIMD instructions worth recognising</h3> </p> vzeroupper in particular is a useful marker: it almost always appears at the end of a function that used AVX, so it helps you identify function boundaries in stripped binaries.</p>

2. How aho-corasick uses memchr and SIMD</h2>

How to confirm in the Akira binary</h2> In Binary Ninja, search for vpshufb or pcmpeqb instructions in the disassembly</li> If found in a loop iterating over a buffer, cross-reference against the panic string offsets you already recovered for aho-corasick</li>

References</h2> Source Code & API Documentation</strong></p>

Decoding UTF-8 Hex Strings in Python

Demangling the Symbol in Rust Binary:

Quick Reference: Source Location</h2> The actual Debug impl is in the Rust stdlib:</p>

Interesting instructions in Rust binary: lock cmpxchg

Lock-Free Programming</h2> Let’s have a quick recap before discussing this instruction…</p>

The problem it solves</h3> In concurrent programming, multiple threads share data. The naive solution is a mutex:</p>

The hardware foundation: atomicity</h3> On x86–64, certain operations are guaranteed atomic by the ISA:</p> Aligned reads and writes up to 64 bits are naturally atomic (no tearing)</li>

Where lock cmpxchg comes from in your binary</h2>

Assembly Breakdown: x86-64 structure alignment examples

Reversing Akira's Rust Experiment: A Breakdown, Part 1

Summary for Part 1</h2> Because this article and following ones in the series will be fairly_long</strong>, so I put the summary before the in-depth breakdown.</p> </blockquote>

VM setup for malware analysis</h2> To ensure this is an air-gapped VM</strong> (Windows 10)</p>

Comparison Table</h2>
</p>

The Graphic Overview of lock</h2>
</p>

Step 7 — Shared mutex and thread-limit semaphore</h2>
Address range:</strong> 0x4d3d91 -- 0x4d3dab</p>
</p>

Common SIMD instructions worth recognising</h3>
</p>
vzeroupper in particular is a useful marker: it almost always appears at the end of a function that used AVX, so it helps you identify function boundaries in stripped binaries.</p>

Lock-Free Programming</h2>
Let’s have a quick recap before discussing this instruction…</p>

VM setup for malware analysis</h2>
To ensure this is an air-gapped VM</strong> (Windows 10)</p>