Momoko-Ayase/Senbei
1
1
Fork 0
mirror of https://github.com/Momoko-Ayase/Senbei.git synced 2026-09-19 03:57:59 -04:00
Code Issues Activity

refactor: consolidate platform engines into senbei-engine

Browse Source
This commit is contained in:
bfloat16
2026-09-06 19:31:19 +08:00
parent cbfacbc31f
commit d436a200ba
66 changed files with 1148 additions and 1012 deletions
Download Patch File Download Diff File Expand all files Collapse all files
samples/README.md
+15 -97
View File
@@ -1,105 +1,23 @@
# senbei/samples
# Samples
Drop-in corpus for the `samples` integration test (`tests/samples.rs`).
This ignored directory is the optional local corpus used by the samples integration test. Protected binaries and restored outputs must never be committed.
This folder is **git-ignored** (only this `README.md` is tracked), so it holds
whatever Crackproof binaries happen to be on your machine. Nothing here is
committed.
Place protected `.exe` and `.dll` files, exact `global-metadata.dat` files, and matching `.exe._` or `.dll._` companion payloads here. A golden output may sit beside an input as `<base>.golden.<ext>`.
## What to put here
Place protected inputs directly in this folder:
- `*.exe` — Crackproof-protected executables (PE32 or PE32+)
- `*.dll` — Crackproof-protected DLLs (native or managed)
- `*.dat` — il2cpp `global-metadata.dat` blobs (method-token de-obfuscation)
For an **external-companion** module, copy the `<name>._` payload in as well,
keeping the exact `._` suffix on the full file name. The test splices it the
same way the CLI does; without it the loader stub alone is meaningless and the
splice / export-overlay / TLS-restore code is never exercised.
Optionally, place a **golden** next to each input — the known-good unpacked
output, named `<base>.golden.<ext>`:
```
```text
samples/
app.exe <- input
app.golden.exe <- golden (optional)
managed.dll <- input
managed.golden.dll <- golden (optional)
stub.dll <- input (external-companion layout)
stub.dll._ <- its encrypted payload (NOT an input itself)
stub.golden.dll <- golden
global-metadata.dat <- input
global-metadata.golden.dat<- golden
mystery.exe <- input, no golden
app.exe
app.golden.exe
managed.dll
stub.dll
stub.dll._
stub.golden.dll
global-metadata.dat
global-metadata.golden.dat
```
The type (EXE vs native/managed DLL vs metadata) is auto-detected from the file
contents, not the extension, so you don't need to classify anything by hand.
Run `cargo test --release --test samples -- --nocapture`. A missing golden prints a warning; a mismatched golden or failed restore fails the test. An empty corpus is a no-op pass.
Since the corpus is the only regression gate on byte-identical output, keep it
broad: each build family, each layout (marker-based and marker-less), and at
least one external-companion pair. A family with no sample here is a family no
test protects.
## Android Corpus
## How the test treats each input
Run with:
```
cargo test --release --test samples
```
For every input file, the test runs the same routing the CLI uses
(`job::unpack_bytes`, so companions splice and the stub overlays run) — or
`metadata::deobfuscate` for an il2cpp blob — and then:
| Situation | Result |
| ------------------------------------------- | ------------------------------- |
| Golden present, bytes **identical** | **pass** |
| Golden present, bytes **differ** | **fail** (test fails) |
| **No golden** found | **warning** (needs manual check)|
| Unpack errored / file unreadable | **fail** |
Warnings are printed but do not fail the test — they flag outputs you should
eyeball or promote to a golden once verified. Failures fail the test. An empty
or absent folder is a no-op pass.
To see the per-file warning/pass/fail summary, run with output shown:
```
cargo test --release --test samples -- --nocapture
```
## Naming rules
- An **input** is any `*.exe` / `*.dll` / `*.dat` whose name does **not**
contain the `.golden.` segment.
- A **golden** is `<base>.golden.<ext>` sitting next to its input. Files with
`.golden.` in the name are never treated as inputs.
- A **companion** is `<input file name>._` (e.g. `stub.dll._` for `stub.dll`).
Its extension is `_`, so it is never picked up as an input of its own; it is
read only when its base module is processed.
## Android corpus (`samples/android/`)
The `android/` subfolder holds Android samples, one **extracted app tree** per
subdirectory (the layout an APK unpacks to: `lib/<abi>/*.so`,
`assets/.../global-metadata.dat`, ...). The test
(`tests/android_samples.rs`) finds protected AArch64 libraries by content and
restores them through the real pipeline. `SENBEI_ANDROID_SAMPLES` overrides
the corpus location.
Sidecar conventions (all next to the protected `.so` input):
| File | Meaning |
| ---- | ------- |
| `<base>.golden.so.sha256` | Expected SHA-256 of the restored library |
| `<base>.golden.metadata.sha256` | Expected SHA-256 of the unwrapped embedded metadata blob (when the library carries one) |
| `<base>.restore-fails` | Empty marker: this input's restore is a known gap and *must* fail (a future fix fails the test, prompting marker removal) |
A missing sidecar is a warning (with the computed digest printed, ready to
promote), never a failure. App packages (`.apk`/`.apks`/`.xapk`) dropped into
a tree are exercised by folder mode as containers.
`samples/android/` may contain one extracted app tree per subdirectory. Protected libraries are restored through the real pipeline and can carry SHA-256 sidecars named `<base>.golden.so.sha256` and `<base>.golden.metadata.sha256`. An empty `<base>.restore-fails` marker documents a known restore gap.