Authorization boundary (applies jointly to this gateway and the downstream skills [[re-license]] / [[re-keygen]] / [[re-patching]] / [[re-drm]])
- Allowed scenarios: License verification analysis is limited to — analysis of own/self-developed software, authorized testing and auditing, CTF and research environments (challenge/sandbox samples), vendor-authorized assessment targets
- Prohibited: Unauthorized software unlocking, commercial software bypass, distribution after bypassing authorization (including dissemination of patched and keygen artifacts)
- Dynamic route permission threshold: Dynamic steps such as observing return values at breakpoints, modifying the environment, and verifying behavior are normal reverse engineering methods, but before the Agent executes them automatically, it must confirm that the user has stated the target's ownership (one of software ownership / testing authorization / CTF·research environment) — if not stated, only perform static license logic analysis, and do not execute dynamic verification or patch application
Complete workflow
Execute in order; for each step's artifacts (checkpoint addresses / algorithm pseudocode / patch files / keygen scripts) record evidence path + sha256 (see [[re-triage]] (capability:triage)), for citation in the report.
- Packer determination and unpacking: [[re-anti-analysis]] (capability:
unpack、deobfuscation、evasion-analysis） — determine the packer before acting: [[re-packer-id]] (capability:unpack) identification (abnormal section names / entropy >7 / extremely small import table / EP pointing to a non-first section). If packed, unpack first (simple packer [[re-unpack-simple]] (capability:unpack), strong packer [[re-unpack-advanced]] (capability:unpack), archive the sha256 of the unpacked artifact); if after unpacking there are still junk instructions / flattening / string encryption → [[re-deobfuscate]] (capability:deobfuscation）。Only after confirming there is no packer enter license locating(searching for the license function in packer code is wasted effort, see pitfall 1) - License locating: [[re-license]] (capability:
license-analysis） — use strings / API cross-references to find the verification function (registration dialog / MessageBox / registry read) → call graph and success/failure branches → algorithm recovery (comparison / decryption / signature verification) → distinguish online activation from offline verification → identify machine code binding.Artifacts: all checkpoint addresses + verification algorithm(not just the first one, see pitfall 2) - Dispatch: choose the path according to the nature of the verification algorithm and the target —
- Algorithm is reversible (comparison / transformation / table lookup can be reversed) → [[re-keygen]] (capability:
license-analysis） write a keygen (generate any valid serial number, without modifying the target file, suitable for distribution) - Algorithm is irreversible (hash; asymmetric signature verification — the private key cannot be derived from the public verification process, RSA/ECC verification itself is a public algorithm, what is unavailable is the signature generation key) → [[re-patching]] (capability:
binary-patching）(skip signature verification / change the decision branch); if the serial number must be hard-derived from the comparison chain / mathematical relationship → [[re-z3]] (capability:constraint-solving) modeling is optional (see pitfall 4) - Only want to bypass quickly (do not care about the algorithm) → [[re-patching]] (capability:
binary-patching）(Minimal change: change failed jump to successful jump) - Both can be done simultaneously: patch is immediately usable, keygen is valid long-term
- Algorithm is reversible (comparison / transformation / table lookup can be reversed) → [[re-keygen]] (capability:
- Patch: [[re-patching]] (capability:
binary-patching） — locate patch points (failed jump jz/jnz) → byte modification (nop / jump rewrite) → checksum / self-check handling → patch export (binary diff / patch file) → multi-architecture adaptation (ARM change B instruction, etc.) - Keygen: [[re-keygen]] (capability:
license-analysis） — from the verification algorithm obtained via [[re-license]] (capability:license-analysis) → reverse-derive generation algorithm (forward derivation / constraint solving) → python implementation → checksum / check digit boundary handling → multi-platform CLI output - Verification: rerun in sandbox ([[re-sandbox]] (capability:
sandbox-setup), highest principle of [[re-analyze/platform-tips]]) — the patched version and the serial number generated by keygen must passallverification points (startup + function points, see pitfall 2); behavior is consistent compared with the unmodified sample; artifacts and evidence paths are archived
Record the result of each step according to [[re-triage]] (capability:triage); registration algorithm fingerprint / patch bytes are the [[re-ioc]] (capability:threat-intel) YARA feature source.
When to use which atomic skill (selection tree)
By input characteristics / target branch:
- Sample is packed(abnormal section names / high entropy / extremely small import table) → first [[re-anti-analysis]] (capability:
unpack、deobfuscation、evasion-analysis; packer-id → unpack-* → deobfuscate when needed), after unpacking return to step 2 of this gateway - "What is the serial number algorithm / help me generate a registration code" → [[re-license]] (capability:
license-analysis) restore algorithm → [[re-keygen]] (capability:license-analysis) generate - "Bypass registration verification / unlock features" → [[re-license]] (capability:
license-analysis) locate verification points → [[re-patching]] (capability:binary-patching) minimal change - Verification algorithm is irreversible (hash; asymmetric signature — private key cannot be derived from the public verification process) → [[re-patching]] (capability:
binary-patching; skip signature verification); if you want to hard-derive from the comparison chain → [[re-z3]] (capability:constraint-solving) model - Online activation(verification includes network requests) → [[re-license]] (capability:
license-analysis) distinguish online / offline, then switch to [[re-protocol]] (capability:network-capture、protocol-recovery、crypto-identification、crypto-decryption、key-extraction、tls-analysis) packet capture to analyze the activation process, handle the local side according to the offline process (see pitfall 3) - Only confirm whether a registration mechanism exists("Does this program have authorization?") → [[re-license]] (capability:
license-analysis) step 1 is enough, do not proceed further - Confirm there is no authorization mechanism → this gateway is not needed, switch to [[re-binary-core]] (capability:
decompilation、debugging、memory-dump、elf-parser、pe-parser、macho-parser) normal analysis - Target is DRM content protection(PlayReady / Widevine licenses, content decryption) → not traditional authorization verification, switch to [[re-drm]] (capability:
drm-analysis; authorization research only, compliance boundaries see that skill)
Cross-domain combination
- Entry dispatch: This gateway is invoked by the triage "cracking / authorization bypass / registration code" path of [[re-analyze]] (re-cracking → if packed, re-anti-analysis → authorization locating re-license → patching / keygen re-patching / re-keygen)
- Unpacking before cracking: Packed samples first go through [[re-anti-analysis]] (packer-id → unpack-* → deobfuscate), and the unpacked artifact returns to this gateway for authorization locating; step 6 of the [[re-anti-analysis]] workflow likewise routes cracking targets back to this gateway
- Decompilation workbench: Decompiling authorization functions goes through [[re-binary-core]] ([[re-ghidra]] / [[re-ida]] / [[re-radare2]])
- Dynamic locating: [[re-gdb]] / [[re-x64dbg]] (breakpoints to inspect validation branches and return values), [[re-lldb]] (macOS), [[re-tracing]] (strace / ltrace to observe registry / file / API calls), [[re-memdump]] (registration flags / validation results in memory)
- Online activation: Validation involves network interaction → [[re-protocol]] ([[re-netcap]] packet capture + [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]] to handle activation protocol encryption)
- DRM content protection: PlayReady / Widevine license and content decryption belong to the DRM domain → [[re-drm]] (distinct from authorization validation cracking; authorization research only)
- Obfuscation countermeasures: Validation functions are protected by junk instructions / flattening / string encryption → restore with [[re-deobfuscate]] before locating
- Verification sandbox: Re-running patched versions / keygen serial numbers for verification must use [[re-sandbox]] (the highest principle of [[re-analyze/platform-tips]])
- IOC output: Registration algorithm fingerprints, patch bytes, and typical keygen characteristics go into the [[re-ioc]] list
Common pitfalls and traps
- Skipping unpacking and locating authorization directly: Symptom—the "validation function" located via xref is all the packer's decompression code, and string searches are all garbled / packer information; Cause—the sample is packed, and the authorization logic is only decrypted after the OEP; Countermeasure—in step 1, first use [[re-anti-analysis]] to confirm it is fully unpacked (sha256 + import table parseable + sandbox re-run) before proceeding to authorization locating
- Patching only one validation point: Symptom—the startup validation passes, but using a core feature pops up the registration dialog again / the feature is locked; Cause—validation occurs multiple times (startup + feature points + timers); Countermeasure—in step 2 of [[re-license]], traverse all xrefs / call graphs of the validation function, and makeallvalidation points into a checklist, cover them one by one with patch / keygen, and verify each one
- Treating online activation as offline cracking: Symptom—after modifying all local decision branches, the program still refuses to work; Cause—serial number verification is server-side, and locally there is only request / response and pseudo-validation; Countermeasure—in step 4 of [[re-license]], first distinguish online / offline; for online activation, switch to [[re-protocol]] to analyze the activation protocol, and the local side can only handle response validation and offline fallback logic
- Blindly pursuing a keygen: Symptom—the validation algorithm contains SHA / MD5 or RSA signature verification, a keygen cannot be written, and the plan is stuck; Cause—the irreversible part is one-way (hashes cannot be reversed; in asymmetric signature verification, the private key cannot be derived from the public verification process), so forward generation of serial numbers is impossible; Countermeasure—dispatch according to step 3: for irreversible parts, switch to [[re-patching]] to skip signature verification; when constraint solving is required, use z3-solver to model only the reversible parts
- Cloud configuration lost → find files of the same series and guess the format: Symptom — the cracking target depends on a cloud configuration file (such as
SSSSSPRO.json), the file has been emptied by the author and the program throws errors, and reverse-engineering the parsing is slow; Cause — the cloud file is unavailable; Countermeasure — guess other files from the same series (such as the version without PRO, whose format is usually identical) → start a local server to simulate the data + URL replacement (hosts/proxy/frida hook redirection), which is much faster than reverse-engineering the configuration format - If the network verification platform allows self-registration → build your own backend instead of reverse-engineering: Symptom — the card key verification server protocol is complex (sign/encryption and decryption/data format), and writing your own server keeps reporting data anomalies; Cause — fully implementing the verification platform protocol is a large amount of work; Countermeasure — first investigate the verification platform itself: locate the API URL → subdomain scanning → find the platform's API documentation/admin login page; if the platformallows anyone to register → register and build your own software, generate a configuration (default encryption algorithm such as RC4) → replace the configuration values in the target, which is less trouble than writing a server; this is a general shortcut for cracking network verification: prefer "reusing the platform" over "rewriting the platform"
- frida gadget injection without hijack injection: Symptom — the target main program is packed/self-checking, making hijack injection troublesome; Countermeasure — write loader.exe:
CreateProcessimmediately inject after starting the targetfrida-gadget.dll(together with gadget.config), which is simpler and more controllable than the hook injection path