fast16: From Stripped Binary to Sabotage Finding in Minutes → Delphos Labs

SentinelLABS published research on fast16, a 2005-era cyber sabotage framework that predates Stuxnet by five years. Their analysis required days of expert reverse engineering work. It revealed a kernel driver that silently corrupts floating-point calculations in high-precision engineering software, a Lua-powered worm carrier, and a connection to the Shadow Brokers leak.

How much of that analysis could the Delphos agent reproduce, starting from the raw binaries and no prior context? Within minutes per component, the agent independently identified the framework’s architecture, recovered its encrypted payloads, reconstructed the propagation chain, and reached the same core conclusion: this driver deliberately corrupts numerical results in targeted software.

How do you understand a binary without context or symbols?

We gave the Delphos agent two binaries: fast16.sys (a 44KB kernel driver) and svcmgmt.exe (a 315KB service executable). No context, no hints about what they do, no symbols. Just compiled code from 2005. We then asked questions, the same way an analyst would approach an unknown sample.

The Driver

What can you tell me about this driver?

Within seconds, the agent identified the core architecture:

This is a Windows filesystem filter-style driver, not a typical user-facing device driver.

Its entry point creates \Device\fast16 and the DOS-visible link \??\fast16.

It registers a filesystem-registration callback, which creates and attaches filter device objects to filesystems using IoCreateDevice, IoAttachDeviceToDeviceStack, and IoRegisterFsRegistrationChange.

It does runtime kernel export resolution instead of importing allocation APIs directly. The names are XOR-obfuscated with 0x53; decoded strings include ExAllocatePool, ExAllocatePoolWithTag, ExFreePool, ExFreePoolWithTag.

The agent immediately flagged what makes this unusual, and identified the standout capability:

It has explicit logic around executable names: one decoded suffix is .EXE, another decoded full name is EXPLORER.EXE. The dispatch code uppercases file names and compares them against those obfuscated strings. That means the driver is selectively interested in executables.

This driver appears to intercept executable image data and patch/augment PE metadata in flight… it manufactures unwind/exception sections and adjusts the PE header to describe them.

That’s a filesystem filter driver doing on-the-fly binary rewriting, identified with no prior context in a single question.

What is it patching exactly?

The agent mapped the full patch architecture:

sub_11a20 is a pattern-based patch engine driven by the rule table at 0x12ff0. Its rules search for instruction sequences with wildcards and then either: overwrite bytes, capture values from matched code, write captured values back elsewhere, or add image-dependent RVAs from the per-image context. The table at 0x12ff4 contains 0x65 rule records. Several replacement records inject far calls, for example:


pattern      48 89 84 24 9c 00 00 00 4b 0f 8f 79 ff ff ff   →   replacement   9a 00 02 00 00 1b 00
pattern      8b 5d 0c 8b 55 08 8b 36 8b                     →   replacement   9a e4 02 00 00 1b 00 90

pattern      48 89 84 24 9c 00 00 00 4b 0f 8f 79 ff ff ff   →   replacement   9a 00 02 00 00 1b 00
pattern      8b 5d 0c 8b 55 08 8b 36 8b                     →   replacement   9a e4 02 00 00 1b 00 90

101 pattern-matching rules. Far-call hooks into injected code. A rule engine that could match an advanced AV scanner’s complexity, repurposed for surgical code modification.

Where do the far calls point?

The agent traced the hooks into newly injected code:

The far calls do not point to normal functions already present in the driver image. They point into code that the driver injects into the target executable. sub_11fb0 adds two new PE sections named .xdata and .pdata. It also records new RVA/size pairs in the per-image context. sub_113e8 then copies one of the embedded stub blobs into the image’s mapped first page and applies relocations. The far-call targets line up with offsets inside that injected stub page, not with any existing function in the original driver.

What is the injected code doing to floating-point operations?

We asked the agent to use Binary Ninja to force-create code at the hook targets and recover the disassembly:

The shellcode implant is not a single tiny hook. It is a full FPU/math emulation stub with shared state. All three primary entries begin with the same pattern:


call $+5
pop  ecx
sub  ecx, imm

call $+5
pop  ecx
sub  ecx, imm

That computes a base pointer into the implanted page. After that, the code accesses a large internal state block. At 0x13c9f, 0x13e03, and 0x13e2a the code uses fnsave [esp] and frstor [esp]. This is strong evidence the implant is intercepting floating-point instructions and preserving the caller’s FPU environment.

What is the state machine actually computing?

The agent carved out the shared dispatcher and mapped its operation:

The shared dispatcher is a numeric/FPU state machine, not a generic control-transfer hub. This is a hard split between two operand classes:


<= 0x16   →   32-bit / scalar path
>  0x16   →   64-bit / extended path

<= 0x16   →   32-bit / scalar path
>  0x16   →   64-bit / extended path

The larger body computes:


fld  qword [ebx+eax*4]
fstp qword [ecx+0xfd4]
fsub qword [ecx+0xfd4]
fld  qword [ecx+0xfa8]
fmul qword [ecx+0xf9c]
...
fdivp st1, st0
fst  qword [ecx+0xfc0]
fmul qword [ecx+0xfb0]
fchs
faddp st1, st0
fstp qword [ecx+0xfc8]

fld  qword [ebx+eax*4]
fstp qword [ecx+0xfd4]
fsub qword [ecx+0xfd4]
fld  qword [ecx+0xfa8]
fmul qword [ecx+0xf9c]
...
fdivp st1, st0
fst  qword [ecx+0xfc0]
fmul qword [ecx+0xfb0]
fchs
faddp st1, st0
fstp qword [ecx+0xfc8]

That is not simple arithmetic. It is coefficient-based approximation logic: table lookup, scaling, divide, negate, and accumulate. This is the signature of a software implementation of transcendental/math library behavior.

Would the results be correct?

This is where the analysis reaches the same conclusion as SentinelLABS. We asked: given that this code replaces floating-point operations, would the program’s output still be correct?

The injected blob is not a faithful general x87 software emulator. It is a table-driven floating-point transformation layer that preserves x87 context with fnsave/frstor, but the recovered core logic remaps selected values through thresholded piecewise functions. The strongest evidence that this is a remapper, not exact emulation: sub_14968 builds coefficients from embedded tables.


threshold table   @ 0x14b64:   60.0, 60.0, 40.0, 47.0, 40.0, ...
value/gain table  @ 0x14ba4:   0.1, 0.42, 0.1, 0.1, 0.1, ...   (approx)

threshold table   @ 0x14b64:   60.0, 60.0, 40.0, 47.0, 40.0, ...
value/gain table  @ 0x14ba4:   0.1, 0.42, 0.1, 0.1, 0.1, ...   (approx)

That is a classic piecewise linear transfer function:

below lower bound: no remap / early return path

between lower and upper bounds: linear transform

above upper bound: clamp to preset output

So the answer to the precision question is:

it does not preserve floating-point results exactly in the general case

it implements selective, table-driven approximation/remapping

visible effects would be changed numerical outputs in the patched code paths, especially around configured threshold regions and saturation points

The agent independently determined that this driver deliberately corrupts numerical results. Not through pattern matching against known malware, but by reconstructing the injected code’s mathematics.

The Carrier

What is the purpose of this binary?

The agent’s initial assessment of svcmgmt.exe was cautious:

This binary looks like a Windows service-style administration utility, not clearly malware from the evidence currently visible. The string win32implant is suspicious, but by itself it is not enough to classify the binary as malware.

The agent doesn’t jump to conclusions; it reports what it can prove.

Is it doing anything unconventional?

The agent identified six unusual behaviors, including registry-mediated self-relaunch, hidden process spawning, named-pipe IPC, generic DLL loading, native API process enumeration, and XOR-obfuscated strings.

Can it run Lua scripts?

Yes. This binary contains an embedded Lua interpreter and can run Lua code.

sub_4147e0 creates an interpreter state through sub_411390

sub_4148f0 registers host-provided globals including "install", "is_service", "rp", and "progname"

sub_403ad0 implements Lua package loading behavior around _LOADED and _REQUIREDNAME

Can we find any Lua code in it?

The first attempt found encrypted data. When asked to try again, the agent cracked it:

sub_418660 is a simple in-place XOR decoder:

it starts with seed 0x02d63a86

XORs each byte with the low byte of the evolving seed

updates the seed as (seed * 0x17) % 0x05f5e101

After applying that decoding to the blob at 0x42d82c, the first decoded bytes become 1b 4c 75 61 50 01 ... which is \x1bLuaP..., i.e. a Lua precompiled chunk header.

The decoded bytecode revealed the framework’s true nature:


build_wormlet_table
scm_wormlet_propagate_system
worm_install_failure_action
implant_install_failure_action
%windir%\system32\drivers\fast16.sys
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\fast16

build_wormlet_table
scm_wormlet_propagate_system
worm_install_failure_action
implant_install_failure_action
%windir%\system32\drivers\fast16.sys
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\fast16

The binary looked like a Windows service administration utility until the agent cracked the XOR encryption and found a complete worm propagation chain written in Lua.

How does the whole propagation chain work end to end?

The agent reconstructed the complete kill chain:

sub_4148f0 initializes Lua and runs the decoded bytecode.

Lua builds candidate targets via build_wormlet_table, valid_ips, ip_ranges, same_subnet, target_ok.

Lua evaluates gating via ok_to_install, ok_to_propagate, acquire_privilege.

Lua enters the SCM propagation path: scm_init_prop_status → scm_wormlet_propagate_system.

Native helpers enumerate/connect to Windows network resources.

Payload files are staged with CopyFileW.

Service persistence is established with CreateServiceW, adjusted with ChangeServiceConfigW, and launched with StartServiceW.

Registry state is maintained for implant tracking.

Success/failure is tracked through propagation status routines.

And the agent identified embedded components:

fast16.sys kernel driver (with PDB path C:\buildy\driver\fd\i386\fast16.pdb)

Connect.dll plugin (with AddConnectNotify / CancelConnectNotify exports)

A service executable mode

Encrypted Lua bytecode implementing worm logic

What can an AI agent actually recover from a stripped nation-state binary?

Starting from two stripped binaries and no prior context, the Delphos agent reconstructed the full architecture of a nation-state sabotage framework:

Identified a filesystem filter driver mapping a 101-rule pattern engine that rewrites instruction sequences on the fly

Traced far-call hooks into injected shellcode

Recovered, disassembled, and reconstructed position-independent FPU manipulation code as a piecewise linear transfer function

Concluded the code deliberately alters numerical results, the sabotage finding

Decrypted embedded Lua bytecode by identifying the XOR algorithm

Reconstructed a complete worm propagation chain from Lua symbols and native API mapping

Identified all major embedded components including the driver, DLL, and service

Where does agent-assisted analysis stop and human judgment begin?

The agent did not:

Identify the specific target software (LS-DYNA, PKPM, MOHID). That requires matching patterns against a large software corpus, which is an intelligence problem, not a reverse engineering one.

Connect the framework to the Shadow Brokers leak. That is external threat intelligence context, not something derivable from the binary.

Correctly interpret the “Intel” string check on the first attempt. It characterized it as a tolerance filter rather than a targeting selector for Intel-compiled executables.

The first two gaps are not reverse engineering problems; they are intelligence problems, and no binary analysis tool can solve them from the binary alone.

These gaps are real but expected. The third is an interpretation error that a human analyst reviewing the output would catch and correct. None of them diminish the core technical achievement: going from opaque binary to “this corrupts floating-point math” in minutes.

What changes when binary analysis takes minutes instead of days?

SentinelLABS’ research on fast16 is exceptional work that required deep expertise and significant time investment. We’re not claiming equivalence. What we are saying is that the gap between “days of expert analysis” and “minutes of agent-assisted analysis” is closing fast.

The question shifts from “can we afford to analyze this?” to “what should we ask it?”

For security teams drowning in binaries they can’t inspect, that changes the calculus. It can get you 80% of the way there in 1% of the time, and that first 80% is often what determines whether a threat gets triaged or sits in a queue.

The fast16 samples analyzed in this post were originally documented by SentinelLABS. We recommend reading their full analysis for the complete threat intelligence context.