Subject: Modular Vault — path-dependent opcode encryption (not obscurity); debugger welcome
Hi,
Looking for technical feedback from IDA users.
Purpose: This is not an obscurity/obfuscator. I want to know whether path-dependent / rolling encryption for machine code is genuinely hard to reverse — recovery tied to execution history, not “find the hidden branch.”
Modular Vault — small MFC dialog payload embedded in a Win32 host. The protected payload runs under a 6-floor matrix with VEH stepping: valid bytes at a given RIP depend on which instructions ran before, not on a fixed static mapping at that address alone.
Goal: recover the integer constants and formula, compute the 7-digit access code.
Methods: IDA, Ghidra, debugger, trace, plugins — all welcome. Anti-debug and extra SEH paths were removed in this build to simplify debugging.
Run / investigate: mfcDlgPayload.exe — this is the host. It loads the protected payload from the PE tail overlay, builds the in-memory matrix, and drives VEH stepping. Debug the host load path (overlay extraction, mapping, floor setup), not only the standalone floor files in isolation.
Decryption model: There is no bulk decrypt before execution. Opcodes are handled instruction-by-instruction at runtime under VEH: decrypt at the current RIP, then possibly re-encrypt as execution moves on. A full cleartext .text does not exist upfront for static analysis — at any moment, only the currently executed instruction may be valid literal machine code; the rest of .text can remain encrypted, trapped, or decoy bytes on ghost floors. RIP can move between floors on valid instructions (not a single flat contiguous image), so following execution in a debugger is part of the test.
Also in ZIP: Floors/mfcDlgPayload.exe.matrix.f00.exe … f05.exe — per-floor .text snapshots so you can skip tail decompression and compare floor correlation directly.
PDB is not included. Symbol names below are author labels for those RVAs.
Direction (open guide):
I am not hiding where the logic lives. The test is whether you can recover meaning from bytes under rolling, path-dependent encryption.
0x138C — VaultComputeAccessCode — constants and formula (start here)
0x1510 — VaultVerifyUserCode — parse input, call compute, compare
0x1690 — OnBnClickedVerify — Verify button; xref from UI strings
In IDA/Ghidra: load Floors/mfcDlgPayload.exe.matrix.f00.exe, base 0x140000000, go to .text + RVA.
Across floors: for each RVA above, open the same offset in f00 … f05. Floor 0 = execution plane (unstable literal x86 at rest when encrypted). Floors 1–5 = ghost-plane representation. Diff one RVA in all six files — that is the mechanism under test.
Suggested order: 0x138C → 0x1510 → 0x1690
Win: correct 7-digit code + short write-up — especially what worked (host load, single floor, six floors, trace under host) and where recovery stopped.
ZIP: https://drive.google.com/file/d/19WT375RxZEGsu11Hz1mekcPVJloXGy5S/view?usp=sharing
SHA256: 6C655C20EB26B61D6C15983E8B89D473470329E84FAEAF3D41EF96D37310CE6A
Provisional patent 64/108,338 — high-level discussion in-thread welcome.
Thanks,
Igor Tebelev