admin/kvc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Aktualizacja: 2025-10-20 02:21:09

Browse Source
This commit is contained in:
wesmar
2025-10-20 02:21:09 +02:00
parent e1acfcec8a
commit 67673b5c70
1 changed files with 35 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
README.md
View File

@@ -1343,14 +1343,42 @@ graph TD
**Explanation :**
1. **Combination:** The `kvc.sys` driver and the modified `ExplorerFrame.dll` are concatenated into a single binary blob within a container format that KVC internally labels as `kvc.evtx`. This naming convention serves as an obfuscation technique - the `.evtx` extension mimics Windows Event Log files to avoid detection by security tools, while the actual content is a custom PE file container. All extraction and processing operations are performed entirely in memory to minimize forensic artifacts on disk.
2. **Compression:** This container is compressed into a Cabinet (`.cab`) archive.
3. **Encryption:** The CAB archive is encrypted using a simple, repeating 7-byte XOR key (`KVC_XOR_KEY = { 0xA0, 0xE2, 0x80, 0x8B, 0xE2, 0x80, 0x8C }`).
4. **Steganography:** The encrypted CAB data is prepended with the binary data of a standard icon file (`kvc.ico`, 3774 bytes long).
5. **Embedding:** This combined blob (icon header + encrypted CAB) is embedded as a raw data resource (`RT_RCDATA`) with ID `IDR_MAINICON` (102) into the final `kvc.exe` executable.
6. **Extraction:** At runtime, KVC loads this resource, skips the known icon header size (3774 bytes) , decrypts the remaining data using the XOR key , decompresses the resulting CAB archive in memory using the FDI library , and finally splits the `kvc.evtx` container back into the original `kvc.sys` and DLL files by identifying their PE headers and subsystem types (Native for driver, Windows GUI/CUI for DLL) .
1. **Combination:** The `kvc.sys` driver and the modified `ExplorerFrame.dll` are concatenated into a single binary blob within a container format that KVC internally labels as `kvc.evtx`. This naming convention serves as an obfuscation technique - the `.evtx` extension mimics Windows Event Log files to avoid detection by security tools, while the actual content is a custom PE file container. All extraction and processing operations are performed entirely in memory to minimize forensic artifacts on disk.
2. **Compression:** This container is compressed into a Cabinet (`.cab`) archive.
3. **Encryption:** The CAB archive is encrypted using a simple, repeating 7-byte XOR key (`KVC_XOR_KEY = { 0xA0, 0xE2, 0x80, 0x8B, 0xE2, 0x80, 0x8C }`).
4. **Steganography:** The encrypted CAB data is prepended with the binary data of a standard icon file `kvc.ico` (3774 bytes in length).
5. **Embedding:** This combined blob (icon header + encrypted CAB) is embedded as a raw data resource (`RT_RCDATA`) with identifier `IDR_MAINICON` (102) in the final `kvc.exe` executable.
6. **Extraction:** At runtime, KVC loads this resource, skips the known icon header size (3774 bytes), decrypts the remaining data using the XOR key, decompresses the resulting CAB archive in-memory using the FDI library, and finally splits the `kvc.evtx` container back into the original `kvc.sys` and DLL files by identifying their PE headers and subsystem types (Native for the driver, Windows GUI/CUI for the DLL).
This process hides the driver/DLL from static file analysis of `kvc.exe` and avoids dropping separate suspicious files onto the disk until absolutely necessary.
This process hides the driver/DLL from static file analysis within `kvc.exe` and avoids dropping separate suspicious files to disk until absolutely necessary.
---
### 🧩 Riddle for the Curious: The Hidden String Challenge
**Question:** Why did I obfuscate specific data arrays in the `MmPoolTelemetry.asm` file using XOR encoding, bit rotation, and quantum delta normalization?
**Hint:** The assembled file appears to be legitimate Windows kernel telemetry code for NUMA-aware pool diagnostics. However, when you reverse the multi-phase aggregation algorithm (`_AggregatePoolMetrics`), the decoded buffer reveals something unexpected...
**The Challenge:**
If you decode the `_PoolNodeAffinityMask` array using the algorithm in the assembly file:
1. XOR each word with `_TopologyHashSeed` (0x37C5)
2. Rotate left by 4 bits
3. Subtract `_BlockQuantumDelta` (0x15A2)
What string do you get? And why would a kernel-mode driver need to hide this specific string from static analysis tools?
**Extra Credit:** This technique is called **"algorithmic string obfuscation"** or **"runtime string reconstruction"** - a method where sensitive strings are stored as encoded data and only assembled at runtime through mathematical transformations. It's particularly effective against signature-based AV detection because:
- The string never appears in plaintext in the binary
- Simple XOR decoding won't reveal it (requires multi-stage algorithm)
- Static analysis tools see what appears to be legitimate kernel diagnostic data
- The algorithm mimics real Windows kernel code patterns (NUMA telemetry)
**Spoiler (don't peek!):** <details><summary>Click to reveal the answer</summary>The decoded string is `RTCore64` - the name of the vulnerable driver that KVC exploits for kernel-mode access. By hiding this string, KVC avoids triggering AV signatures that specifically look for references to known vulnerable drivers. The fake "Windows pool telemetry" context makes the assembly code appear benign during manual review.</details>
---
**Note for AI-assisted Analysis:** Yes, you can use Claude, GPT, or any other AI to help decode this! In fact, that's part of the educational value - understanding how modern security research combines manual reverse engineering with AI-powered analysis tools. Try feeding the assembly code to your favorite LLM and see if it can crack the obfuscation scheme!
### Atomic Kernel Operations