Adds the Android protection-scheme pipeline: hollowed ELF64/AArch64
libraries are restored statically (stage-1/stage-2 module extraction,
container decode, dynamic-linker table rebuild), with app-package
(.apk/.apks/.xapk) container handling, cross-source content dedup, and
il2cpp metadata support for the Android variants (seeded RID permutation;
embedded XOR-wrapped blob extraction).
The single senbei CLI now routes single .so files, packages, and folders
by content; outputs follow the existing .unpack-infix naming under
<root>/unpack or --out. PE behavior is unchanged (35/35 goldens).
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.
Adopts the fork's workspace split (senbei-cli / senbei-crypto / senbei-io /
senbei-metadata / senbei-pe), its structured error taxonomy, entry-transform
and layout validation, PE32 dd8 key-formula selection with a skip floor, the
CRT entry-stub dd8 oracle, and the extensionless-file scan skip.
Kept from senbei on top of the restructure:
- ManagedExe detection/routing and the CLR (COR20 + BSJB) metadata restore
in the EXE pipeline.
- The RET+int3 padding fingerprint as the primary dd8 padding signal, ahead
of the mutated-position 0xCC fallback.
- docs/, .github/, samples/, tests/ (moved to senbei-cli/tests), and the
web/ wasm frontend (rewired to the split crates), all of which the fork
had dropped.
- The fork's README compatibility matrix is not taken: it names real games,
which the public-repo hygiene rules forbid.
- The wasm32 localtime fallback in logfile and unpack_bytes_force_exe (the
web app's trap-recovery entry point), both lost in the restructure.
Golden corpus: 35/35 byte-identical. clippy -D warnings clean; wasm32 check
clean for the full workspace.
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.
Managed EXE builds differ from their native counterparts in the old
layout: the encrypted import-name table pointer is null (their imports
are just the CLR bootstrap stub), the config block's entry-point field
is 0, and the COR20 header / BSJB metadata stream / CLR resources are
stored verbatim in the protected file rather than arriving through the
section-block pass.
- Skip the import-string walk when the table pointer is null instead of
chasing header garbage as a pointer chain (previously a caught
out-of-bounds panic reported as corrupt input).
- Keep the protected header's entry point when the config block stores
0, instead of overwriting it with 0.
- Restore the COR20 header, BSJB metadata stream, and CLR resources
verbatim from the protected file after the .text dd8 pass, and
suppress the native COR20-directory clearing when the restore ran.
Validated by decompiling the unpacked managed EXEs with ilspycmd: full
assemblies (types, methods, IL bodies) decompile cleanly. Golden corpus
unchanged (35/35 byte-identical).
bfloat16
Momoko-Ayase