ImageFileName is truncated by Windows (14+NUL): surface the full image path instead

[h4x0r]

A 15-character process name loses its last byte in every view. ps and
netstat both report coreupdater.ex where the real name is coreupdater.exe.

Evidence

Independent oracle — the DFIR Madness Case-001 memory writeup, Volatility on
this same dump:

The other interesting, but now suspect process, 3644 coreupdater.exe had an
active network connection to 203.78.103.109

The answer-key writeups say coreupdater.exe 66 times and never the 14-character
form.

issen (current main, release build) on
tests/data/dfirmadness-szechuan-sauce/DC01-memory.zip:

$ issen memory DC01-memory.zip --command ps
3644  2244  coreupdater.ex  Exited

$ issen memory DC01-memory.zip --command netstat --format json
{"Proto":"TCPv4","Local":"10.42.85.10:62613","Remote":"203.78.103.109:443",
 "State":"ESTABLISHED","PID":"3644","Process":"coreupdater.ex", ...}

coreupdater.exe is 15 bytes; coreupdater.ex is 14.

Why 15 characters is the sharp edge

_EPROCESS.ImageFileName is UCHAR[15]. A 15-character name fills the array
exactly, leaving no room for a NUL terminator. Anything treating the field as
NUL-terminated, or reserving a byte for one, silently drops the final character —
but only for names of exactly 15 characters. Shorter names are unaffected, which
is why this has gone unnoticed.

memf-windows/src/network.rs::owner_info reads the correct length:

let name_bytes = reader.read_bytes(owner + name_off, 15)?;
let process_name = String::from_utf8_lossy(&name_bytes)
    .trim_end_matches('\0')
    .to_string();

Since ps and netstat are both affected, the loss is in shared decode rather
than in either command.

Why it matters more than a display nit

It corrupts an IDENTIFIER, silently, with nothing to signal it happened — no
ellipsis, no lossy flag. An examiner grepping for coreupdater.exe gets no
hit; a report cites a filename that does not exist on the volume.

It is also present in the JSON view, which the fleet rule reserves for exact
values: machine views carry the exact serialization token, never humanized or
truncated.

Why the existing test does not catch it

tests/szechuan_netstat.rs:

.find(|r| name_of(r).starts_with("coreupdater"))

A prefix match passes identically for coreupdater.exe and coreupdater.ex. The
assertion is weaker than the property it protects, so the test sits directly
beside the defect and cannot see it.

Suggested fix

1. Trace the shared _EPROCESS.ImageFileName decode and stop reserving/assuming
   a terminator; take all 15 bytes and trim only actual NULs.
2. Change the test to assert EQUALITY against coreupdater.exe, not a prefix.
   Confirm it FAILS against current main first, or it proves nothing.
3. Sweep for the same shape elsewhere — any fixed-width, non-NUL-terminated
   field decoded as a C string has this bug for maximum-length values.

[h4x0r]

Empirical confirmation: the ceiling is 14, fleet-wide in the dump

Ran issen memory DC01-memory.zip --command ps (issen built from main today) and
took the length distribution of every process name, rather than reasoning from
one sample:

     7 chars: 3
     8 chars: 2
     9 chars: 4
    10 chars: 1
    11 chars: 6
    12 chars: 5
    14 chars: 3

42 rows captured, so this is measured against a non-empty baseline.

No name in the entire dump reaches 15 characters. The three at 14 are
coreupdater.ex, vm3dservice.ex and taskhostex.exe — the first two are
15-character names clipped, the third is genuinely 14.

A live Windows DC has many 15-character process names. A distribution that stops
dead at 14 is the signature of a decoder that cannot emit 15, not of a machine
that happens to have none.

Where it is NOT

Ruled out by reading, so the search can start below these:

• Every call site passes the right length:
  read_field_string(eproc_addr, "_EPROCESS", "ImageFileName", 15) in both
  process.rs (the ps path) and, via a direct read_bytes(.., 15),
  network.rs::owner_info (the netstat path). A crate-wide grep found no site
  passing 14.

• ObjectReader::read_string is correct:

  let mut buf = vec![0u8; max_len];
  self.vas.read_virt(vaddr, &mut buf)?;
  let end = buf.iter().position(|&b| b == 0).unwrap_or(buf.len());
  Ok(String::from_utf8_lossy(&buf[..end]).into_owned())

  With max_len = 15 and no NUL, end == 15. No off-by-one here.

Both ps and netstat are affected, and they reach the bytes by different
routes, so the loss is below both — in field_offset resolution or in
read_virt itself. Two candidates worth checking first:

1. field_offset("_EPROCESS", "ImageFileName") returning an offset one byte
   high. Reading 15 from base+off+1 yields the last 14 characters plus one
   trailing byte; if that byte is NUL the NUL-scan trims to 14 and the result
   looks exactly like a clean truncation.
2. read_virt short-reading by one at a boundary, leaving buf[14] as its
   initialised zero — which the NUL-scan then treats as the terminator.

(1) is distinguishable from (2) by whether the FIRST character survives: under
(1) a 15-char name would lose its leading character, not its trailing one. The
observed coreupdater.ex keeps the leading c, which points at (2) — a
short read — rather than a shifted offset.

[h4x0r]

Correction: the reader is faithful; the truncation is in the artifact

I filed this assuming we dropped a byte. Checking the raw dump shows we do not —
Windows itself stores the truncated name, and the reader reports what is there.

Evidence, from the bytes

Scanning citadeldc01.mem for coreupdater and testing which hit is inside the
_EPROCESS for PID 3644 (PID 3644 present as a u64 within ±0x400):

offset	bytes	PID 3644 nearby
0x02082cb38	coreupdater.ex\0	yes, at rel 0x2a8
0x0195086ea	coreupdater.exe\0	no

The field the process listing reads — _EPROCESS.ImageFileName, UCHAR[15] —
contains

c o r e u p d a t e r . e x \0      14 characters + NUL, filling all 15 bytes

The kernel reserved the final byte for the terminator and truncated the name to
14 characters when it populated the field. The complete coreupdater.exe\0
exists elsewhere in memory, in a structure that is not adjacent to this PID.

So coreupdater.ex is not a decode defect. It is what the evidence says, and
read_string (read 15, stop at first NUL) returns it correctly.

What the original report got wrong

The premise was "a 15-character name fills the array leaving no room for a NUL,
so anything treating the field as NUL-terminated drops the final character."
The array is indeed full — but it is full of 14 characters and a NUL, not 15
characters. Nothing of ours dropped anything.

The independent-oracle argument was also weaker than it looked. The writeups say
coreupdater.exe because that is the malware's real filename, known from the
disk image and from other artifacts. That is not evidence about what
ImageFileName contains, and I treated prose in a writeup as though it were tool
output.

What is still worth fixing

Reporting coreupdater.ex is faithful but can mislead an examiner into thinking
that is the filename on disk. The honest improvement is enrichment, not a decode
change:

1. Source the full name from a structure that carries it — the NT path in
   _EPROCESS.SeAuditProcessCreationInfo.ImageFileName, or ImagePathName in
   _RTL_USER_PROCESS_PARAMETERS — and show that when available.
2. When only ImageFileName is available, make the 15-byte limit visible rather
   than silently presenting a possibly-truncated name as the process name.

Both are additive. Neither changes what ImageFileName decodes to, which must
keep reporting the field verbatim: it is the observed value, and a reader that
"corrects" evidence to match an expected filename is worse than one that shows a
truncated name.

Retitling accordingly — this is an enrichment gap, not a byte-loss bug.