Dropping an .apk/.apks/.xapk package or a .so library reported
"not recognized — will be skipped", which reads as "not protected"
when the real gap is that the Android pipeline (filesystem
orchestration in senbei-io) has no wasm build. These files now get an
explicit android pseudo-kind at staging time: the row explains that
the CLI handles them, and they neither enable the Unpack button nor
error out mid-run.
The Rust bindings move from web/src to a top-level senbei-wasm crate (still
outside the workspace, own Cargo.lock), matching the other senbei-* crates.
web/ keeps only the static frontend; wasm-pack emits the JS/wasm package into
web/pkg/ via --out-dir. JS glue renamed senbei_web -> senbei_wasm with the
crate.
The detector already used the CLR data-directory RVA to split DLLs into
NativeDll / ManagedDll; EXEs were a single undifferentiated Exe kind.
Apply the same CLR check to EXEs so callers can tell a protected .NET
executable from a native one without unpacking. Routing is unchanged:
both EXE kinds go to the EXE pipeline.
- CLI per-file lines and the run log now print NativeExe / ManagedExe
(the kind comes from the same Debug formatting as the DLL variants).
- The web API's detect()/unpack_file() kind strings become
'native-exe' / 'managed-exe'; the web UI gains matching labels, and
the trap-retry guard (DLL-probe recovery) keys off both EXE kinds.
Golden corpus unchanged (35/35 byte-identical); kind is classification
only and never affects output bytes.
Momoko-Ayase