1
⚙ AES-256-GCM HTML OBFUSCATOR
PBKDF2-250K · AES-256-GCM · Bidirectional Tool
<waiting for result...>
🔒 PROTECTION LAYERS
1. PBKDF2 — 250,000 Iterations (Brute Force Killer)
Unlike SHA-256 (which runs billions of times per second), PBKDF2 with 250,000 iterations forces every password guess to run 250,000 SHA-256 rounds. A GPU that tests 10 billion SHA-256 hashes/second is reduced to ~40,000 password attempts/second — making dictionary attacks practically infeasible.
2. AES-256-GCM (Authenticated Encryption)
AES-GCM provides both encryption and authentication via a built-in GHASH tag. A wrong password doesn't produce garbled output — it throws a cryptographic exception immediately. This prevents partial decryption attacks and ciphertext manipulation.
3. Random Salt + IV Per Encryption
A 256-bit salt (for PBKDF2) and a 96-bit IV (for AES-GCM) are generated fresh via crypto.getRandomValues() each time. Two encryptions of the same HTML with the same password produce completely different output.
4. XOR-Masked Key Segments
The password is split into 3 segments, each XOR'd with a runtime-generated mask before Base64 encoding. The XOR mask is computed from browser properties at runtime — not stored — making static analysis of the key segments useless without executing the code.
5. State Machine Control Flow
The decryption logic runs inside a while(true)+switch state machine with randomized state numbers. Linear reverse engineering (reading top to bottom) fails — execution jumps between non-sequential states that only make sense when traced dynamically.
6. Six Anti-Debug Layers
- Timing trap:
performance.now()+debugger— pauses >150ms wipe the page - DevTools size detection:
outerWidth - innerWidththreshold detects open panels - Console lock:
Object.definePropertymakesconsole.*non-writable and non-configurable - toString freeze:
Function.prototype.toStringlocked to prevent hook detection bypass - Prototype integrity check: Verifies native function signatures aren't patched
- Hidden debugger traps inside dead code branches that look like real logic
7. Deep Code Obfuscation
- All variable/function names: random hex strings regenerated each run
- All string literals: converted to charCode arrays accessed via
String.fromCharCode.apply() - Dead code blocks with fake crypto-looking variable names injected throughout
- The entire output differs completely between two obfuscations of the same input
Comments
Post a Comment