[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EBJTPBCZXSZ8CSV0QGZ1WG":3,"skill-same:01M7EBJTPBCZXSZ8CSV0QGZ1WG":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M7EBJTPBCZXSZ8CSV0QGZ1WG","analyzing-ransomware-encryption-mechanisms",null,"Analyzes encryption algorithms, key management, and file encryption routines used by ransomware families to assess decryption feasibility, identify implementation weaknesses, and support recovery efforts. Covers AES, RSA, ChaCha20, and hybrid encryption schemes. Activates for requests involving ransomware cryptanalysis, encryption analysis, key recovery assessment, or ransomware decryption feasibility.","lza6\u002FArmor-piercing-system-prompts","lza6","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128880206?v=4","01M7EB3K7WPX5T28EJ2NVHE6EG","Chinese-tingfeng","01M7EB3K97E1KQ16QWKJMFNGX8",11,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F03-逆向工程\u002Fanalyzing-ransomware-encryption-mechanisms\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: analyzing-ransomware-encryption-mechanisms\ndescription: 'Analyzes encryption algorithms, key management, and file encryption\n  routines used by ransomware families to assess decryption feasibility, identify\n  implementation weaknesses, and support recovery efforts. Covers AES, RSA, ChaCha20,\n  and hybrid encryption schemes. Activates for requests involving ransomware cryptanalysis,\n  encryption analysis, key recovery assessment, or ransomware decryption feasibility.\n\n  '\ndomain: cybersecurity\nsubdomain: malware-analysis\ntags:\n- malware\n- ransomware\n- encryption\n- cryptanalysis\n- reverse-engineering\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.AE-02\n- RS.AN-03\n- ID.RA-01\n- DE.CM-01\nmitre_attack:\n- T1486\n- T1573.001\n- T1573.002\n- T1027\nmitre_f3:\n  version: '1.1'\n  tactics:\n  - monetization\n  - positioning\n  techniques:\n  - id: F1018\n    name: Convert to Cryptocurrency\n    tactic: monetization\n    source: f3\n  - id: F1047\n    name: Transfer of funds\n    tactic: monetization\n    source: f3\n  - id: T1219\n    name: Remote Access Tools\n    tactic: positioning\n    source: attack\n---\n\n# Analyzing Ransomware Encryption Mechanisms\n\n## When to Use\n\n- A ransomware infection has occurred and recovery requires understanding the encryption scheme used\n- Assessing whether decryption is possible without paying the ransom (implementation flaws, known decryptors)\n- Reverse engineering ransomware to identify the encryption algorithm, key derivation, and key storage mechanism\n- Developing a decryptor tool when a weakness in the ransomware's cryptographic implementation is identified\n- Classifying a ransomware sample by its encryption approach to attribute it to a known family\n\n**Do not use** for production data recovery operations without first verifying the decryption method on test copies of encrypted files.\n\n## Prerequisites\n\n- Ghidra or IDA Pro for reverse engineering the ransomware binary\n- Python 3.8+ with `pycryptodome` library for testing encryption\u002Fdecryption routines\n- Sample encrypted files and their corresponding plaintext originals (known-plaintext pairs)\n- Access to the ransomware binary (unpacked if applicable)\n- Familiarity with symmetric (AES, ChaCha20) and asymmetric (RSA) cryptographic algorithms\n- NoMoreRansom.org database for checking existing free decryptors\n\n## Workflow\n\n### Step 1: Identify the Encryption Algorithm\n\nDetermine which cryptographic algorithm the ransomware uses:\n\n```python\n# Check for Windows Crypto API usage in imports\nimport pefile\n\npe = pefile.PE(\"ransomware.exe\")\n\ncrypto_apis = {\n    \"CryptAcquireContextA\": \"Windows CryptoAPI\",\n    \"CryptAcquireContextW\": \"Windows CryptoAPI\",\n    \"CryptGenKey\": \"Windows CryptoAPI key generation\",\n    \"CryptEncrypt\": \"Windows CryptoAPI encryption\",\n    \"CryptImportKey\": \"Windows CryptoAPI key import\",\n    \"BCryptOpenAlgorithmProvider\": \"Windows CNG (modern crypto)\",\n    \"BCryptEncrypt\": \"Windows CNG encryption\",\n    \"BCryptGenerateKeyPair\": \"Windows CNG asymmetric key gen\",\n}\n\nprint(\"Crypto API Imports:\")\nfor entry in pe.DIRECTORY_ENTRY_IMPORT:\n    for imp in entry.imports:\n        if imp.name and imp.name.decode() in crypto_apis:\n            print(f\"  {entry.dll.decode()} -> {imp.name.decode()}: {crypto_apis[imp.name.decode()]}\")\n```\n\n```\nCommon Ransomware Encryption Schemes:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nAES-256-CBC + RSA-2048:    Most common hybrid scheme (LockBit, REvil, Conti)\nAES-256-CTR + RSA-4096:    Stream cipher mode variant (BlackCat\u002FALPHV)\nChaCha20 + RSA-4096:       Modern stream cipher (Hive, Royal)\nSalsa20 + ECDH:            Curve25519 key exchange (Babuk)\nAES-128-ECB:               Weak mode - potential decryption via known-plaintext\nXOR-only:                  Trivial encryption - always recoverable\nCustom algorithm:          Often contains implementation flaws\n```\n\n### Step 2: Analyze Key Generation and Management\n\nReverse engineer how encryption keys are generated and stored:\n\n```\nKey Management Patterns in Ransomware:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. STRONG (no recovery possible without key):\n   - Per-file AES key generated with CryptGenRandom\n   - AES key encrypted with embedded RSA public key\n   - Encrypted key appended to each file or stored separately\n   - RSA private key held only by attacker's C2 server\n\n2. WEAK (potential recovery):\n   - AES key derived from predictable seed (timestamp, PID)\n   - Same AES key used for all files (single key compromise = full recovery)\n   - Key transmitted to C2 before encryption starts (PCAP may contain key)\n   - XOR with short repeating key (brute-forceable)\n   - PRNG seeded with GetTickCount or time() (limited keyspace)\n\n3. FLAWED IMPLEMENTATION:\n   - ECB mode (preserves plaintext patterns)\n   - Initialization vector (IV) reuse across files\n   - Key stored in plaintext in memory (recoverable from memory dump)\n   - Partial encryption (only first N bytes encrypted)\n```\n\n### Step 3: Examine File Encryption Routine\n\nReverse engineer the file processing logic:\n\n```c\n\u002F\u002F Typical ransomware file encryption flow (decompiled pseudo-code from Ghidra):\n\nvoid encrypt_file(char *filepath) {\n    \u002F\u002F 1. Check file extension against target list\n    if (!is_target_extension(filepath)) return;\n\n    \u002F\u002F 2. Generate per-file AES key (32 bytes for AES-256)\n    BYTE aes_key[32];\n    CryptGenRandom(hProv, 32, aes_key);\n\n    \u002F\u002F 3. Generate random IV (16 bytes)\n    BYTE iv[16];\n    CryptGenRandom(hProv, 16, iv);\n\n    \u002F\u002F 4. Read file contents\n    HANDLE hFile = CreateFile(filepath, GENERIC_READ, ...);\n    BYTE *plaintext = read_entire_file(hFile);\n\n    \u002F\u002F 5. Encrypt with AES-256-CBC\n    aes_cbc_encrypt(plaintext, file_size, aes_key, iv);\n\n    \u002F\u002F 6. Encrypt AES key with RSA public key\n    BYTE encrypted_key[256];  \u002F\u002F RSA-2048 output\n    rsa_encrypt(aes_key, 32, rsa_pubkey, encrypted_key);\n\n    \u002F\u002F 7. Write: encrypted_data + encrypted_key + IV to file\n    write_file(filepath, encrypted_data, encrypted_key, iv);\n\n    \u002F\u002F 8. Rename file with ransomware extension\n    rename_file(filepath, strcat(filepath, \".locked\"));\n}\n```\n\n### Step 4: Check for Cryptographic Weaknesses\n\nTest the implementation for exploitable flaws:\n\n```python\nfrom Crypto.Cipher import AES\nimport os\nimport struct\n\n# Test 1: Check if same key is used for multiple files\n# Compare encrypted versions of known files\ndef check_key_reuse(file1_enc, file2_enc):\n    with open(file1_enc, \"rb\") as f:\n        data1 = f.read()\n    with open(file2_enc, \"rb\") as f:\n        data2 = f.read()\n\n    # Extract IVs (location depends on ransomware family)\n    # If IVs are same and files share encrypted blocks -> same key\n    iv1 = data1[-16:]  # Example: IV at end\n    iv2 = data2[-16:]\n    if iv1 == iv2:\n        print(\"[!] Same IV detected - key reuse likely\")\n\n# Test 2: Check for predictable key derivation\n# If key is derived from timestamp, iterate possible values\ndef brute_force_timestamp_key(encrypted_file, known_header, timestamp_range):\n    with open(encrypted_file, \"rb\") as f:\n        encrypted_data = f.read()\n\n    for ts in timestamp_range:\n        # Derive key the same way ransomware does\n        import hashlib\n        key = hashlib.sha256(str(ts).encode()).digest()\n        iv = encrypted_data[-16:]\n        cipher = AES.new(key, AES.MODE_CBC, iv)\n        decrypted = cipher.decrypt(encrypted_data[:16])\n\n        if decrypted[:len(known_header)] == known_header:\n            print(f\"[!] Key found! Timestamp: {ts}\")\n            return key\n\n    return None\n\n# Test 3: Check for ECB mode (pattern preservation)\ndef check_ecb_mode(encrypted_file):\n    with open(encrypted_file, \"rb\") as f:\n        data = f.read()\n    # ECB produces identical ciphertext for identical plaintext blocks\n    blocks = [data[i:i+16] for i in range(0, len(data), 16)]\n    unique = len(set(blocks))\n    total = len(blocks)\n    if unique \u003C total * 0.95:\n        print(f\"[!] ECB mode likely: {total-unique} duplicate blocks out of {total}\")\n```\n\n### Step 5: Attempt Key Recovery\n\nUse identified weaknesses for key recovery:\n\n```python\n# Recovery Method 1: Extract key from memory dump\n# Volatility plugin to scan for AES key schedules\n# vol3 -f memory.dmp windows.yarascan --yara-rule \"aes_key_schedule\"\n\n# Recovery Method 2: Known-plaintext attack (weak algorithms)\ndef xor_key_recovery(encrypted_file, known_plaintext):\n    \"\"\"Recover XOR key from known plaintext-ciphertext pair\"\"\"\n    with open(encrypted_file, \"rb\") as f:\n        ciphertext = f.read()\n\n    key = bytes(c ^ p for c, p in zip(ciphertext, known_plaintext))\n    # Find repeating key length\n    for key_len in range(1, 256):\n        candidate = key[:key_len]\n        if all(key[i] == candidate[i % key_len] for i in range(min(len(key), key_len * 4))):\n            print(f\"XOR key (length {key_len}): {candidate.hex()}\")\n            return candidate\n    return None\n\n# Recovery Method 3: Check NoMoreRansom for existing decryptors\n# https:\u002F\u002Fwww.nomoreransom.org\u002Fen\u002Fdecryption-tools.html\n```\n\n### Step 6: Document Encryption Analysis\n\nCompile findings into a structured report:\n\n```\nAnalysis should document:\n- Algorithm identified (AES, RSA, ChaCha20, custom)\n- Key size and mode of operation (CBC, CTR, ECB, GCM)\n- Key generation method (CSPRNG, predictable seed, static key)\n- Key storage location (appended to file, registry, C2 transmission)\n- File modification pattern (full encryption, partial, header-only)\n- Targeted file extensions\n- Ransom note format and payment infrastructure\n- Decryption feasibility assessment (possible\u002Fimpossible\u002Fpartial)\n- Recommended recovery approach\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Hybrid Encryption** | Combining symmetric (AES) for fast file encryption with asymmetric (RSA) for secure key wrapping; the standard ransomware approach |\n| **Key Wrapping** | Encrypting the per-file symmetric key with the attacker's RSA public key so only the attacker's private key can decrypt it |\n| **ECB Mode** | Electronic Codebook mode encrypts each block independently; preserves patterns in plaintext, a critical weakness enabling partial recovery |\n| **Known-Plaintext Attack** | Using a known original file and its encrypted version to derive the encryption key; effective against XOR and weak stream ciphers |\n| **Key Schedule** | The expanded form of an AES key in memory; scannable in memory dumps to recover encryption keys before they are erased |\n| **CSPRNG** | Cryptographically Secure Pseudo-Random Number Generator; ransomware using CryptGenRandom produces unpredictable keys |\n| **Partial Encryption** | Some ransomware only encrypts the first N bytes or every Nth block for speed; unencrypted portions may aid recovery |\n\n## Tools & Systems\n\n- **Ghidra**: Reverse engineering suite for analyzing ransomware encryption routines at the assembly level\n- **PyCryptodome**: Python cryptographic library for implementing and testing decryption routines\n- **NoMoreRansom.org**: Free decryption tool repository maintained by Europol and security vendors for known ransomware families\n- **Volatility**: Memory forensics framework for extracting encryption keys from RAM dumps of infected systems\n- **CryptoTester**: Tool for identifying cryptographic algorithms based on constants and code patterns\n\n## Common Scenarios\n\n### Scenario: Assessing Decryption Feasibility for a Ransomware Incident\n\n**Context**: An organization is hit with ransomware encrypting file servers. Management needs to know if decryption is possible without paying the ransom before making a recovery decision.\n\n**Approach**:\n1. Identify the ransomware family from ransom note, file extension, and sample hash (check ID Ransomware)\n2. Check NoMoreRansom.org for existing free decryptors for this family\n3. Reverse engineer the encryption routine in Ghidra to identify the algorithm and key management\n4. Test for implementation weaknesses (key reuse, predictable seeds, ECB mode)\n5. Check if PCAP from the incident captured the key transmission to C2 (if key was sent before encryption)\n6. Scan memory dumps from affected machines for AES key schedules in RAM\n7. Report findings: decryption possible\u002Fimpossible with specific technical justification\n\n**Pitfalls**:\n- Testing decryption methods on the only copy of encrypted files (always work on copies)\n- Assuming all files use the same key without verifying (some ransomware uses per-file keys)\n- Not checking for volume shadow copies (vssadmin) which ransomware may have failed to delete\n- Confusing the file encryption algorithm with the key wrapping algorithm in reports\n\n## Output Format\n\n```\nRANSOMWARE ENCRYPTION ANALYSIS\n================================\nSample:           lockbit3.exe\nFamily:           LockBit 3.0 \u002F LockBit Black\nSHA-256:          abc123def456...\n\nENCRYPTION SCHEME\nFile Cipher:      AES-256-CTR (per-file unique key)\nKey Wrapping:     RSA-2048 (public key embedded in binary)\nKey Generation:   CryptGenRandom (CSPRNG - unpredictable)\nIV Generation:    Random 16 bytes per file\nFile Structure:   [encrypted_data][rsa_encrypted_key(256B)][iv(16B)][magic(8B)]\n\nTARGETED EXTENSIONS\nTotal:            412 extensions targeted\nCategories:       Documents (.doc, .xls, .pdf), Databases (.sql, .mdb),\n                  Archives (.zip, .7z), Source code (.py, .java, .cs)\nExcluded:         .exe, .dll, .sys, .lnk (system files preserved)\n\nIMPLEMENTATION ANALYSIS\nKey Strength:     STRONG - per-file random keys, no reuse\nMode Security:    STRONG - CTR mode with unique nonces\nKey Storage:      RSA-encrypted key appended to each file\nShadow Copies:    Deleted via vssadmin and WMI\n\nDECRYPTION FEASIBILITY\nWithout Key:      NOT POSSIBLE\n  - No implementation flaws identified\n  - RSA-2048 key wrapping prevents brute force\n  - CSPRNG prevents key prediction\n  - No existing free decryptor available\n\nRECOVERY OPTIONS\n1. Restore from offline backups (recommended)\n2. Check for volume shadow copies (low probability - ransomware deletes them)\n3. Memory forensics if machine was not rebooted (key may persist in RAM)\n4. Negotiate with attacker (last resort - no guarantee of decryption)\n```\n","# Analyzing Ransomware Encryption Mechanisms\n\n## When to Use\n\n- A ransomware infection has occurred and recovery requires understanding the encryption scheme used\n- Assessing whether decryption is possible without paying the ransom (implementation flaws, known decryptors)\n- Reverse engineering ransomware to identify the encryption algorithm, key derivation, and key storage mechanism\n- Developing a decryptor tool when a weakness in the ransomware's cryptographic implementation is identified\n- Classifying a ransomware sample by its encryption approach to attribute it to a known family\n\n**Do not use** for production data recovery operations without first verifying the decryption method on test copies of encrypted files.\n\n## Prerequisites\n\n- Ghidra or IDA Pro for reverse engineering the ransomware binary\n- Python 3.8+ with `pycryptodome` library for testing encryption\u002Fdecryption routines\n- Sample encrypted files and their corresponding plaintext originals (known-plaintext pairs)\n- Access to the ransomware binary (unpacked if applicable)\n- Familiarity with symmetric (AES, ChaCha20) and asymmetric (RSA) cryptographic algorithms\n- NoMoreRansom.org database for checking existing free decryptors\n\n## Workflow\n\n### Step 1: Identify the Encryption Algorithm\n\nDetermine which cryptographic algorithm the ransomware uses:\n\n```python\n# Check for Windows Crypto API usage in imports\nimport pefile\n\npe = pefile.PE(\"ransomware.exe\")\n\ncrypto_apis = {\n    \"CryptAcquireContextA\": \"Windows CryptoAPI\",\n    \"CryptAcquireContextW\": \"Windows CryptoAPI\",\n    \"CryptGenKey\": \"Windows CryptoAPI key generation\",\n    \"CryptEncrypt\": \"Windows CryptoAPI encryption\",\n    \"CryptImportKey\": \"Windows CryptoAPI key import\",\n    \"BCryptOpenAlgorithmProvider\": \"Windows CNG (modern crypto)\",\n    \"BCryptEncrypt\": \"Windows CNG encryption\",\n    \"BCryptGenerateKeyPair\": \"Windows CNG asymmetric key gen\",\n}\n\nprint(\"Crypto API Imports:\")\nfor entry in pe.DIRECTORY_ENTRY_IMPORT:\n    for imp in entry.imports:\n        if imp.name and imp.name.decode() in crypto_apis:\n            print(f\"  {entry.dll.decode()} -> {imp.name.decode()}: {crypto_apis[imp.name.decode()]}\")\n```\n\n```\nCommon Ransomware Encryption Schemes:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nAES-256-CBC + RSA-2048:    Most common hybrid scheme (LockBit, REvil, Conti)\nAES-256-CTR + RSA-4096:    Stream cipher mode variant (BlackCat\u002FALPHV)\nChaCha20 + RSA-4096:       Modern stream cipher (Hive, Royal)\nSalsa20 + ECDH:            Curve25519 key exchange (Babuk)\nAES-128-ECB:               Weak mode - potential decryption via known-plaintext\nXOR-only:                  Trivial encryption - always recoverable\nCustom algorithm:          Often contains implementation flaws\n```\n\n### Step 2: Analyze Key Generation and Management\n\nReverse engineer how encryption keys are generated and stored:\n\n```\nKey Management Patterns in Ransomware:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. STRONG (no recovery possible without key):\n   - Per-file AES key generated with CryptGenRandom\n   - AES key encrypted with embedded RSA public key\n   - Encrypted key appended to each file or stored separately\n   - RSA private key held only by attacker's C2 server\n\n2. WEAK (potential recovery):\n   - AES key derived from predictable seed (timestamp, PID)\n   - Same AES key used for all files (single key compromise = full recovery)\n   - Key transmitted to C2 before encryption starts (PCAP may contain key)\n   - XOR with short repeating key (brute-forceable)\n   - PRNG seeded with GetTickCount or time() (limited keyspace)\n\n3. FLAWED IMPLEMENTATION:\n   - ECB mode (preserves plaintext patterns)\n   - Initialization vector (IV) reuse across files\n   - Key stored in plaintext in memory (recoverable from memory dump)\n   - Partial encryption (only first N bytes encrypted)\n```\n\n### Step 3: Examine File Encryption Routine\n\nReverse engineer the file processing logic:\n\n```c\n\u002F\u002F Typical ransomware file encryption flow (decompiled pseudo-code from Ghidra):\n\nvoid encrypt_file(char *filepath) {\n    \u002F\u002F 1. Check file extension against target list\n    if (!is_target_extension(filepath)) return;\n\n    \u002F\u002F 2. Generate per-file AES key (32 bytes for AES-256)\n    BYTE aes_key[32];\n    CryptGenRandom(hProv, 32, aes_key);\n\n    \u002F\u002F 3. Generate random IV (16 bytes)\n    BYTE iv[16];\n    CryptGenRandom(hProv, 16, iv);\n\n    \u002F\u002F 4. Read file contents\n    HANDLE hFile = CreateFile(filepath, GENERIC_READ, ...);\n    BYTE *plaintext = read_entire_file(hFile);\n\n    \u002F\u002F 5. Encrypt with AES-256-CBC\n    aes_cbc_encrypt(plaintext, file_size, aes_key, iv);\n\n    \u002F\u002F 6. Encrypt AES key with RSA public key\n    BYTE encrypted_key[256];  \u002F\u002F RSA-2048 output\n    rsa_encrypt(aes_key, 32, rsa_pubkey, encrypted_key);\n\n    \u002F\u002F 7. Write: encrypted_data + encrypted_key + IV to file\n    write_file(filepath, encrypted_data, encrypted_key, iv);\n\n    \u002F\u002F 8. Rename file with ransomware extension\n    rename_file(filepath, strcat(filepath, \".locked\"));\n}\n```\n\n### Step 4: Check for Cryptographic Weaknesses\n\nTest the implementation for exploitable flaws:\n\n```python\nfrom Crypto.Cipher import AES\nimport os\nimport struct\n\n# Test 1: Check if same key is used for multiple files\n# Compare encrypted versions of known files\ndef check_key_reuse(file1_enc, file2_enc):\n    with open(file1_enc, \"rb\") as f:\n        data1 = f.read()\n    with open(file2_enc, \"rb\") as f:\n        data2 = f.read()\n\n    # Extract IVs (location depends on ransomware family)\n    # If IVs are same and files share encrypted blocks -> same key\n    iv1 = data1[-16:]  # Example: IV at end\n    iv2 = data2[-16:]\n    if iv1 == iv2:\n        print(\"[!] Same IV detected - key reuse likely\")\n\n# Test 2: Check for predictable key derivation\n# If key is derived from timestamp, iterate possible values\ndef brute_force_timestamp_key(encrypted_file, known_header, timestamp_range):\n    with open(encrypted_file, \"rb\") as f:\n        encrypted_data = f.read()\n\n    for ts in timestamp_range:\n        # Derive key the same way ransomware does\n        import hashlib\n        key = hashlib.sha256(str(ts).encode()).digest()\n        iv = encrypted_data[-16:]\n        cipher = AES.new(key, AES.MODE_CBC, iv)\n        decrypted = cipher.decrypt(encrypted_data[:16])\n\n        if decrypted[:len(known_header)] == known_header:\n            print(f\"[!] Key found! Timestamp: {ts}\")\n            return key\n\n    return None\n\n# Test 3: Check for ECB mode (pattern preservation)\ndef check_ecb_mode(encrypted_file):\n    with open(encrypted_file, \"rb\") as f:\n        data = f.read()\n    # ECB produces identical ciphertext for identical plaintext blocks\n    blocks = [data[i:i+16] for i in range(0, len(data), 16)]\n    unique = len(set(blocks))\n    total = len(blocks)\n    if unique \u003C total * 0.95:\n        print(f\"[!] ECB mode likely: {total-unique} duplicate blocks out of {total}\")\n```\n\n### Step 5: Attempt Key Recovery\n\nUse identified weaknesses for key recovery:\n\n```python\n# Recovery Method 1: Extract key from memory dump\n# Volatility plugin to scan for AES key schedules\n# vol3 -f memory.dmp windows.yarascan --yara-rule \"aes_key_schedule\"\n\n# Recovery Method 2: Known-plaintext attack (weak algorithms)\ndef xor_key_recovery(encrypted_file, known_plaintext):\n    \"\"\"Recover XOR key from known plaintext-ciphertext pair\"\"\"\n    with open(encrypted_file, \"rb\") as f:\n        ciphertext = f.read()\n\n    key = bytes(c ^ p for c, p in zip(ciphertext, known_plaintext))\n    # Find repeating key length\n    for key_len in range(1, 256):\n        candidate = key[:key_len]\n        if all(key[i] == candidate[i % key_len] for i in range(min(len(key), key_len * 4))):\n            print(f\"XOR key (length {key_len}): {candidate.hex()}\")\n            return candidate\n    return None\n\n# Recovery Method 3: Check NoMoreRansom for existing decryptors\n# https:\u002F\u002Fwww.nomoreransom.org\u002Fen\u002Fdecryption-tools.html\n```\n\n### Step 6: Document Encryption Analysis\n\nCompile findings into a structured report:\n\n```\nAnalysis should document:\n- Algorithm identified (AES, RSA, ChaCha20, custom)\n- Key size and mode of operation (CBC, CTR, ECB, GCM)\n- Key generation method (CSPRNG, predictable seed, static key)\n- Key storage location (appended to file, registry, C2 transmission)\n- File modification pattern (full encryption, partial, header-only)\n- Targeted file extensions\n- Ransom note format and payment infrastructure\n- Decryption feasibility assessment (possible\u002Fimpossible\u002Fpartial)\n- Recommended recovery approach\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Hybrid Encryption** | Combining symmetric (AES) for fast file encryption with asymmetric (RSA) for secure key wrapping; the standard ransomware approach |\n| **Key Wrapping** | Encrypting the per-file symmetric key with the attacker's RSA public key so only the attacker's private key can decrypt it |\n| **ECB Mode** | Electronic Codebook mode encrypts each block independently; preserves patterns in plaintext, a critical weakness enabling partial recovery |\n| **Known-Plaintext Attack** | Using a known original file and its encrypted version to derive the encryption key; effective against XOR and weak stream ciphers |\n| **Key Schedule** | The expanded form of an AES key in memory; scannable in memory dumps to recover encryption keys before they are erased |\n| **CSPRNG** | Cryptographically Secure Pseudo-Random Number Generator; ransomware using CryptGenRandom produces unpredictable keys |\n| **Partial Encryption** | Some ransomware only encrypts the first N bytes or every Nth block for speed; unencrypted portions may aid recovery |\n\n## Tools & Systems\n\n- **Ghidra**: Reverse engineering suite for analyzing ransomware encryption routines at the assembly level\n- **PyCryptodome**: Python cryptographic library for implementing and testing decryption routines\n- **NoMoreRansom.org**: Free decryption tool repository maintained by Europol and security vendors for known ransomware families\n- **Volatility**: Memory forensics framework for extracting encryption keys from RAM dumps of infected systems\n- **CryptoTester**: Tool for identifying cryptographic algorithms based on constants and code patterns\n\n## Common Scenarios\n\n### Scenario: Assessing Decryption Feasibility for a Ransomware Incident\n\n**Context**: An organization is hit with ransomware encrypting file servers. Management needs to know if decryption is possible without paying the ransom before making a recovery decision.\n\n**Approach**:\n1. Identify the ransomware family from ransom note, file extension, and sample hash (check ID Ransomware)\n2. Check NoMoreRansom.org for existing free decryptors for this family\n3. Reverse engineer the encryption routine in Ghidra to identify the algorithm and key management\n4. Test for implementation weaknesses (key reuse, predictable seeds, ECB mode)\n5. Check if PCAP from the incident captured the key transmission to C2 (if key was sent before encryption)\n6. Scan memory dumps from affected machines for AES key schedules in RAM\n7. Report findings: decryption possible\u002Fimpossible with specific technical justification\n\n**Pitfalls**:\n- Testing decryption methods on the only copy of encrypted files (always work on copies)\n- Assuming all files use the same key without verifying (some ransomware uses per-file keys)\n- Not checking for volume shadow copies (vssadmin) which ransomware may have failed to delete\n- Confusing the file encryption algorithm with the key wrapping algorithm in reports\n\n## Output Format\n\n```\nRANSOMWARE ENCRYPTION ANALYSIS\n================================\nSample:           lockbit3.exe\nFamily:           LockBit 3.0 \u002F LockBit Black\nSHA-256:          abc123def456...\n\nENCRYPTION SCHEME\nFile Cipher:      AES-256-CTR (per-file unique key)\nKey Wrapping:     RSA-2048 (public key embedded in binary)\nKey Generation:   CryptGenRandom (CSPRNG - unpredictable)\nIV Generation:    Random 16 bytes per file\nFile Structure:   [encrypted_data][rsa_encrypted_key(256B)][iv(16B)][magic(8B)]\n\nTARGETED EXTENSIONS\nTotal:            412 extensions targeted\nCategories:       Documents (.doc, .xls, .pdf), Databases (.sql, .mdb),\n                  Archives (.zip, .7z), Source code (.py, .java, .cs)\nExcluded:         .exe, .dll, .sys, .lnk (system files preserved)\n\nIMPLEMENTATION ANALYSIS\nKey Strength:     STRONG - per-file random keys, no reuse\nMode Security:    STRONG - CTR mode with unique nonces\nKey Storage:      RSA-encrypted key appended to each file\nShadow Copies:    Deleted via vssadmin and WMI\n\nDECRYPTION FEASIBILITY\nWithout Key:      NOT POSSIBLE\n  - No implementation flaws identified\n  - RSA-2048 key wrapping prevents brute force\n  - CSPRNG prevents key prediction\n  - No existing free decryptor available\n\nRECOVERY OPTIONS\n1. Restore from offline backups (recommended)\n2. Check for volume shadow copies (low probability - ransomware deletes them)\n3. Memory forensics if machine was not rebooted (key may persist in RAM)\n4. Negotiate with attacker (last resort - no guarantee of decryption)\n```\n",{"name":5,"tags":24,"author":30,"domain":31,"license":15,"version":32,"mitre_f3":33,"nist_csf":50,"subdomain":55,"description":56,"mitre_attack":57},[25,26,27,28,29],"malware","ransomware","encryption","cryptanalysis","reverse-engineering","mahipal","cybersecurity","1.0.0",{"tactics":34,"version":37,"techniques":38},[35,36],"monetization","positioning","1.1",[39,43,46],{"id":40,"name":41,"source":42,"tactic":35},"F1018","Convert to Cryptocurrency","f3",{"id":44,"name":45,"source":42,"tactic":35},"F1047","Transfer of funds",{"id":47,"name":48,"source":49,"tactic":36},"T1219","Remote Access Tools","attack",[51,52,53,54],"DE.AE-02","RS.AN-03","ID.RA-01","DE.CM-01","malware-analysis","Analyzes encryption algorithms, key management, and file encryption routines used by ransomware families to assess decryption feasibility, identify implementation weaknesses, and support recovery efforts. Covers AES, RSA, ChaCha20, and hybrid encryption schemes. Activates for requests involving ransomware cryptanalysis, encryption analysis, key recovery assessment, or ransomware decryption feasibility.\n",[58,59,60,61],"T1486","T1573.001","T1573.002","T1027","main","d69096e239f2a89aabc2cd078c47664a9d3b1e11","03-逆向工程\u002Fanalyzing-ransomware-encryption-mechanisms",3,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts","https:\u002F\u002Fgithub.com\u002Flza6","个人vx：Tf00798\r\n个人✈：@TFGY999","2026-10-08 14:29:22",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add lza6\u002FArmor-piercing-system-prompts --skill analyzing-ransomware-encryption-mechanisms",{"tool":76,"command":77},"bunx","bunx skills add lza6\u002FArmor-piercing-system-prompts --skill analyzing-ransomware-encryption-mechanisms",{"tool":79,"command":80},"pnpm","pnpm dlx skills add lza6\u002FArmor-piercing-system-prompts --skill analyzing-ransomware-encryption-mechanisms","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F03-逆向工程\u002Fanalyzing-ransomware-encryption-mechanisms\u002FSKILL.md",true,[84],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fapi-reference.md","REFERENCE","参考文档",4076,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F03-逆向工程\u002Fanalyzing-ransomware-encryption-mechanisms\u002Freferences\u002Fapi-reference.md",[91,99,106,113,120,127],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M7EXRM12046G0GM1WGMMFXCN","ci-cd-and-automation","Automates CI\u002FCD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.","MIT","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fci-cd-and-automation\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":19},"01M7EXRFYYSJ3Y15AGPDDEWWQD","chrome-devtools","Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to `--slim` mode (MCP configuration).","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-devtools\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":19},"01M7EXR6EYPE4X5X1BTAE6QJRV","chrome-cdp","Drive a real Chrome via the Chrome DevTools Protocol (CDP). Ensures a\ndebuggable Chrome is running (launching it if needed) so the agent can\nnavigate, read page content, inspect the DOM, run JavaScript, and take\nscreenshots — without the user typing any launch command. Includes a\nfirst-class \"review a live running app\" flow: point Chrome at the app under\ndevelopment and inspect\u002Fscreenshot the REAL page (what a static-artifact tool\ncannot do). Backed by Glimpse and the chrome-devtools MCP server. Use when\nasked to \"use chrome\", \"open chrome\", \"drive my browser\", \"read the page in\nchrome\", \"review the running app\", \"screenshot the app\", or \"\u002Fchrome-cdp\".","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-cdp\u002FSKILL.md",[],[],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":19},"01M7EXR1Y7E79KQKG4J798XGH6","check-identity-pack","Run an AFP 100-point or AUSTRAC safe-harbour identity check over a set of documents, and report exactly what's missing. Use when the user asks to check identity documents, verify someone's ID for onboarding, or assess whether a document pack satisfies Australian identity requirements.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcheck-identity-pack\u002FSKILL.md",[],[],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":19},"01M7EXQXW7C7PGREJW9ZZTZ16H","changelog","Auto-generates a changelog from git commits, sprint data, and design documents. Produces both internal and player-facing versions.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchangelog\u002FSKILL.md",[],[],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":19},"01M7EXQMH2ZME3ANN8Q8MEWPFB","cellxgene-census","Query the CZ CELLxGENE Census programmatically for versioned public single-cell and spatial transcriptomics data. Use when you need population-scale cell metadata, gene expression slices, Census summary counts, source H5AD URIs\u002Fdownloads, embeddings, spatial Census data, or reference atlas comparisons across organisms, tissues, diseases, assays, and cell types. For analyzing your own local single-cell data use scanpy, anndata, or scvi-tools.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcellxgene-census\u002FSKILL.md",[],[]]