When we explored API hooking and EDR evasion in earlier chapters, we focused on the moment of execution—how code gets from point A to point B without triggering security controls. But execution represents only a fraction of an implant's lifecycle. Most of the time, malware sits idle, waiting for its next beacon or command. This dormant period creates a significant vulnerability: memory scanners have ample opportunity to examine process memory at their leisure, searching for signatures, suspicious patterns, or anomalous memory regions. Sleep evasion techniques address this fundamental challenge by transforming how implants behave during idle periods.
Modern endpoint security solutions don't rely solely on monitoring API calls and system events. They actively scan process memory, looking for indicators of compromise that might slip past behavioral detection. Understanding these scanning mechanisms reveals why sleep evasion has become essential for advanced threats.
EDR memory scanners employ multiple detection strategies, each targeting different aspects of in-memory threats:
MEMORY SCANNING DETECTION MODEL
┌─────────────────────────────────────────────────────────────────────┐
│ EDR Memory Scanner │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Periodic Scanning: │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Every N seconds, scan process heaps and executable regions │ │
│ │ Compare .text sections against known-good baselines │ │
│ │ Flag memory with RWX permissions (read-write-execute) │ │
│ │ Identify unbacked executable memory (not mapped to files) │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ Pattern Recognition: │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Shellcode signatures (common prologs, syscall patterns) │ │
│ │ Stack anomalies (unusual return addresses, frame structures) │ │
│ │ Entropy analysis (encrypted regions stand out) │ │
│ │ String references (C2 URLs, suspicious commands) │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ Event-Triggered Scans: │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Process creation/injection detected │ │
│ │ Suspicious API sequence observed │ │
│ │ Network connection established │ │
│ │ Manual investigation initiated │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘The key insight is that memory scanners operate asynchronously from the malware itself. While an implant sleeps between beacons, perhaps waiting 60 seconds or several minutes, the EDR has repeated opportunities to examine its memory. A scanner running every 10 seconds would have six chances to detect the implant during a single 60-second sleep cycle. This asymmetry heavily favors the defender.
Consider a typical command-and-control implant. It executes for perhaps a few hundred milliseconds—establishing connections, executing commands, exfiltrating data—then sleeps for seconds or minutes before its next callback. During that brief execution window, the code must be present and readable in memory. But during the much longer sleep period, the same code remains exactly where it was, fully readable, just waiting to be discovered.
THE IDLE TIME VULNERABILITY
Timeline:
├──────┤ ├──────┤
Execute Sleep (60 seconds) Execute
(200ms) (200ms)
Memory during execution: Memory during sleep:
[Shellcode - Readable] [Shellcode - STILL Readable]
[Strings - Visible] [Strings - STILL Visible]
[Config - Accessible] [Config - STILL Accessible]
Scanner opportunity: Scanner opportunity:
1 scan possible 6+ scans possible
▲ Minimal exposure ▲ Maximum exposureThis disparity explains why sleep evasion has become a focus of offensive security research. If an implant spends 99% of its time sleeping, making that sleep period opaque to scanners eliminates 99% of the detection surface.
The core concept of sleep encryption is straightforward: before sleeping, encrypt the implant's memory; after waking, decrypt it before resuming execution. The challenge lies in implementation—the decryption code must somehow execute even though the rest of the implant is encrypted.
Sleep encryption faces an interesting bootstrap challenge. If you encrypt all your code before sleeping, how does the decryption routine run when you wake up? The decryption code can't be encrypted, but leaving it in the clear creates a detection surface. Several approaches address this paradox:
Approach 1: Small Stub - Leave only a minimal decryption stub unencrypted. This reduces but doesn't eliminate the detection surface.
Approach 2: ROP Chains - Use return-oriented programming to construct the decryption sequence from gadgets in legitimate system DLLs. The implant contains no decryption code at all.
Approach 3: Timer Callbacks - Schedule decryption as a timer callback that fires when sleep ends. The callback mechanism is part of the operating system, not the implant.
Approach 4: APC Injection - Queue an Asynchronous Procedure Call to the sleeping thread that handles decryption upon wake.
Each approach has tradeoffs between complexity, reliability, and detectability.
SLEEP ENCRYPTION LIFECYCLE
┌─────────────────────────────────────────────────────────────────┐
│ ACTIVE PHASE │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Memory: RX (executable) │ │
│ │ Content: Plaintext shellcode, strings, configuration │ │
│ │ Status: Executing tasks, communicating with C2 │ │
│ └────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ PRE-SLEEP SEQUENCE │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 1. VirtualProtect(RW) - Make memory writable │ │
│ │ 2. Generate encryption key (random per cycle) │ │
│ │ 3. Encrypt memory regions (code, data, heap) │ │
│ │ 4. Optionally spoof stack frames │ │
│ │ 5. Schedule wake-up mechanism │ │
│ └────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ SLEEP PHASE │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Memory: RW (non-executable) │ │
│ │ Content: Encrypted blob - appears as random data │ │
│ │ Status: Thread waiting on kernel object │ │
│ │ │ │
│ │ Scanner sees: │ │
│ │ - High entropy data (looks like compressed/encrypted) │ │
│ │ - No recognizable signatures │ │
│ │ - No suspicious strings │ │
│ │ - Thread in normal wait state │ │
│ └────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ POST-SLEEP SEQUENCE │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 1. Decrypt memory regions using stored key │ │
│ │ 2. VirtualProtect(RX) - Restore execute permissions │ │
│ │ 3. Zero key material from memory │ │
│ │ 4. Restore original stack if spoofed │ │
│ │ 5. Resume normal execution │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘Ekko, developed by C5pทider (Cracked5pider), pioneered a clever approach using Windows timer callbacks to execute an encryption/decryption ROP chain. Instead of keeping decryption code in the implant, Ekko constructs the entire encrypt-sleep-decrypt sequence using legitimate Windows API functions called through timer queue callbacks.
The technique relies on CreateTimerQueueTimer, which schedules callback functions to execute at specified intervals. By queuing multiple callbacks with precise timing, Ekko orchestrates a sequence of operations that encrypt the implant, wait for the sleep duration, then decrypt before signaling completion.
EKKO MECHANISM
1. Create synchronization objects:
├── Waitable Timer (for sleep duration)
└── Event (for completion signaling)
2. Queue timer callbacks (in sequence):
┌─────────────────────────────────────────────────────────────┐
│ Callback 1: VirtualProtect(implant_region, RW) │
│ Make memory writable for encryption │
├─────────────────────────────────────────────────────────────┤
│ Callback 2: SystemFunction032(implant, key) │
│ RC4 encrypt the implant memory │
├─────────────────────────────────────────────────────────────┤
│ Callback 3: WaitForSingleObject(timer, sleep_duration) │
│ Actual sleep - encrypted during this time │
├─────────────────────────────────────────────────────────────┤
│ Callback 4: SystemFunction032(implant, key) │
│ RC4 decrypt (same key, RC4 is symmetric) │
├─────────────────────────────────────────────────────────────┤
│ Callback 5: VirtualProtect(implant_region, RX) │
│ Restore execute permissions │
├─────────────────────────────────────────────────────────────┤
│ Callback 6: SetEvent(completion_event) │
│ Signal main thread that sleep is complete │
└─────────────────────────────────────────────────────────────┘
3. Main thread waits on completion event
(Implant encrypted during entire wait)
4. Upon completion, resume normal executionA key component of Ekko is SystemFunction032, an undocumented function exported by advapi32.dll that performs RC4 encryption. Since RC4 is symmetric (the same operation encrypts and decrypts), the same function call works for both phases. Using a system-provided encryption function means the implant doesn't need to contain any cryptographic code.
// SystemFunction032 function signature
typedef NTSTATUS (WINAPI *SystemFunction032_t)(
PUNICODE_STRING Data, // Buffer to encrypt/decrypt
PUNICODE_STRING Key // RC4 key
);
// UNICODE_STRING is repurposed to hold arbitrary data
typedef struct _UNICODE_STRING {
USHORT Length; // Used as data length
USHORT MaximumLength; // Used as buffer size
PWSTR Buffer; // Used as data pointer
} UNICODE_STRING;The function treats the UNICODE_STRING structures as simple buffer descriptors, ignoring their typical semantics. This allows encrypting arbitrary binary data, not just Unicode strings.
Each sleep cycle should use a unique encryption key. If the same key were reused, an attacker who captured one key could decrypt all historical memory dumps. Key rotation uses readily available entropy sources:
void GenerateEphemerKey(PBYTE pKey, SIZE_T cbKey) {
LARGE_INTEGER perfCounter;
QueryPerformanceCounter(&perfCounter);
DWORD threadId = GetCurrentThreadId();
DWORD tickCount = GetTickCount();
FILETIME fileTime;
GetSystemTimeAsFileTime(&fileTime);
// Mix multiple entropy sources
for (SIZE_T i = 0; i < cbKey; i++) {
pKey[i] = (BYTE)(
(perfCounter.QuadPart >> ((i % 8) * 8)) ^
(threadId >> ((i % 4) * 8)) ^
(tickCount >> ((i % 4) * 8)) ^
(fileTime.dwLowDateTime >> ((i % 4) * 8))
);
}
}This approach provides sufficient randomness for each sleep cycle without requiring cryptographic random number generators, which might draw attention from behavioral monitors.
While Ekko effectively hides implant memory during sleep, the thread's call stack remains a potential indicator. Security tools examining sleeping threads can walk the stack, looking for return addresses that don't point to legitimate code. Foliage extends sleep encryption by also fabricating legitimate-looking stack frames.
When a thread sleeps, its stack contains return addresses showing how it got there. A normal thread waiting on I/O might have a stack like:
NtWaitForSingleObject+0x14 ← In ntdll.dll
WaitForSingleObjectEx+0x9E ← In kernel32.dll
SomeApplicationFunction+0x42 ← In app.exe
BaseThreadInitThunk+0x14 ← In kernel32.dll
RtlUserThreadStart+0x21 ← In ntdll.dllBut an implant's stack reveals its true nature:
NtWaitForSingleObject+0x14 ← In ntdll.dll
EncryptedSleep+0x187 ← In UNBACKED MEMORY ← Suspicious!
MainLoop+0x95 ← In UNBACKED MEMORY ← Suspicious!
ShellcodeEntry+0x12 ← In UNBACKED MEMORY ← Suspicious!Return addresses pointing to unbacked memory (memory not associated with any file on disk) immediately flag the thread as suspicious.
Foliage addresses this by constructing a fake stack that appears to originate from legitimate system code. Before sleeping, it replaces the actual stack contents with carefully crafted frames:
STACK SPOOFING FOR SLEEP
Before Spoofing (Actual Stack): After Spoofing (Fake Stack):
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ Return to shellcode+0x100 │ │ NtWaitForSingleObject+0x14 │
│ (Unbacked executable) │ │ (Legitimate ntdll.dll) │
├─────────────────────────────┤ ├─────────────────────────────┤
│ Return to shellcode+0x50 │ │ WaitForSingleObjectEx+0x9E │
│ (Unbacked executable) │ │ (Legitimate kernel32.dll) │
├─────────────────────────────┤ ├─────────────────────────────┤
│ Saved RBP │ │ Saved RBP → Next frame │
├─────────────────────────────┤ ├─────────────────────────────┤
│ Local variables │ │ BaseThreadInitThunk+0x14 │
└─────────────────────────────┘ ├─────────────────────────────┤
│ RtlUserThreadStart+0x21 │
└─────────────────────────────┘
EDR Stack Walker: EDR Stack Walker:
"Suspicious - unbacked code" "Normal thread waiting"Constructing convincing stack frames requires knowing the exact frame size for each spoofed function. Windows x64 uses structured exception handling (SEH) with UNWIND_INFO records that describe each function's prologue and epilogue. These records specify exactly how much stack space each function reserves.
UNWIND_INFO STRUCTURE
┌────────────────────────────────────────────────────────────────┐
│ PE Optional Header │
│ └── DataDirectory[EXCEPTION] │
│ └── RUNTIME_FUNCTION array │
│ ├── BeginAddress: RVA of function start │
│ ├── EndAddress: RVA of function end │
│ └── UnwindData: RVA of UNWIND_INFO │
│ │
│ UNWIND_INFO: │
│ ├── Version: 1 │
│ ├── Flags: Handler flags │
│ ├── SizeOfProlog: Bytes in prologue │
│ ├── CountOfCodes: Number of unwind codes │
│ └── UnwindCode[]: Array describing stack operations │
│ │
│ UnwindCode operations: │
│ ├── UWOP_PUSH_NONVOL: Pushed register (8 bytes) │
│ ├── UWOP_ALLOC_SMALL: Small stack allocation │
│ ├── UWOP_ALLOC_LARGE: Large stack allocation │
│ └── UWOP_SET_FPREG: Frame pointer setup │
└────────────────────────────────────────────────────────────────┘By parsing UNWIND_INFO for each function in the spoofed call chain, Foliage can calculate exact frame sizes and construct frames that will pass validation by stack walkers.
Beyond code sections, implants often allocate heap memory for configuration data, downloaded payloads, and command results. This heap data persists across sleep cycles and may contain recognizable strings or patterns. Heap encryption extends the protection to dynamically allocated memory.
To encrypt heap regions during sleep, the implant must track what memory it has allocated. This requires wrapper functions around allocation routines:
HEAP REGION TRACKING
Allocation Flow:
┌─────────────────────────────────────────────────────────────────┐
│ TrackedAlloc(size) called │
│ ├── VirtualAlloc(size) → Returns pMem │
│ ├── Create HEAP_REGION record: │
│ │ ├── Address: pMem │
│ │ ├── Size: size │
│ │ └── Next: pointer to previous record │
│ └── Add record to linked list │
└─────────────────────────────────────────────────────────────────┘
Pre-Sleep Encryption:
┌─────────────────────────────────────────────────────────────────┐
│ Walk linked list of HEAP_REGIONs │
│ For each region: │
│ ├── XOR or RC4 encrypt contents │
│ └── Region now contains encrypted data │
└─────────────────────────────────────────────────────────────────┘
Post-Sleep Decryption:
┌─────────────────────────────────────────────────────────────────┐
│ Walk linked list of HEAP_REGIONs │
│ For each region: │
│ └── Decrypt contents (same key, XOR/RC4 symmetric) │
└─────────────────────────────────────────────────────────────────┘XOR Encryption: Simple and fast, but produces predictable patterns if the key is short or reused. Best for temporary protection where performance matters.
RC4 (via SystemFunction032): Already available in the system, produces output indistinguishable from random. Good balance of security and availability.
AES: Stronger encryption but requires either importing crypto libraries (increases size and detection surface) or implementing AES directly (complexity and potential side channels).
For sleep encryption, RC4 via SystemFunction032 represents a practical choice—it's already present on the system, requires no additional code, and produces sufficient entropy to defeat signature matching.
Mature implants combine multiple evasion techniques into a cohesive sleep routine. The orchestration matters—operations must occur in the correct order, and failures must be handled gracefully to avoid crashing or leaving the implant in an inconsistent state.
COMPREHENSIVE SLEEP EVASION FLOW
┌──────────────────────────────────────────────────────────────────────┐
│ STAGE 1: PRE-SLEEP PREPARATION │
├──────────────────────────────────────────────────────────────────────┤
│ 1. Generate ephemeral encryption key │
│ 2. Save current thread context (RtlCaptureContext) │
│ 3. Record current stack pointer and frame chain │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ STAGE 2: MEMORY ENCRYPTION │
├──────────────────────────────────────────────────────────────────────┤
│ 4. Change implant region to RW (VirtualProtect) │
│ 5. Encrypt implant code and data sections │
│ 6. Encrypt tracked heap regions │
│ 7. Store key in obfuscated location (or in encrypted form) │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ STAGE 3: STACK SPOOFING (Optional) │
├──────────────────────────────────────────────────────────────────────┤
│ 8. Build synthetic stack frames │
│ 9. Copy spoofed frames over actual stack │
│ 10. Update context to reflect spoofed stack │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ STAGE 4: SLEEP │
├──────────────────────────────────────────────────────────────────────┤
│ 11. Enter wait state (WaitForSingleObject, timer, etc.) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ During this period: │ │
│ │ - Code is encrypted (unreadable) │ │
│ │ - Heap is encrypted (no recognizable patterns) │ │
│ │ - Stack appears legitimate │ │
│ │ - Thread in normal waiting state │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────┐
│ STAGE 5: WAKE-UP SEQUENCE │
├──────────────────────────────────────────────────────────────────────┤
│ 12. Restore original stack (if spoofed) │
│ 13. Decrypt implant memory regions │
│ 14. Decrypt heap regions │
│ 15. Change implant region back to RX (VirtualProtect) │
│ 16. Securely erase key material (SecureZeroMemory) │
│ 17. Resume normal execution │
└──────────────────────────────────────────────────────────────────────┘The encrypt and decrypt phases introduce latency around each sleep cycle. For short sleep times, this overhead can become significant. Implementations often skip encryption for very short sleeps or use faster (less secure) encryption for frequent wake cycles.
Sleep Duration vs. Encryption Overhead:
Sleep Time Encrypt/Decrypt Overhead % Recommendation
─────────────────────────────────────────────────────────────────
100ms ~5ms ~5% Skip encryption
1 second ~5ms ~0.5% Light encryption
10 seconds ~5ms ~0.05% Full encryption
1 minute ~5ms ~0.008% Full encryption
─────────────────────────────────────────────────────────────────For beacon intervals of several seconds or more, the encryption overhead is negligible and full protection makes sense.
Beyond Ekko's approach, various timer mechanisms can orchestrate sleep encryption. Each has distinct characteristics that may suit different scenarios.
Windows waitable timers provide precise scheduling for deferred execution. They can be set for specific times or intervals and support both synchronous waiting and APC-based callbacks.
Waitable Timer Options:
┌─────────────────────────────────────────────────────────────────┐
│ CreateWaitableTimer / SetWaitableTimer │
├─────────────────────────────────────────────────────────────────┤
│ Mode 1: Manual Reset │
│ - Timer signals once at specified time │
│ - Must be manually reset for next cycle │
│ - Good for one-shot operations │
├─────────────────────────────────────────────────────────────────┤
│ Mode 2: Periodic Timer │
│ - Timer signals repeatedly at specified interval │
│ - Automatically resets after each signal │
│ - Good for regular beacon intervals │
├─────────────────────────────────────────────────────────────────┤
│ Callback Option: │
│ - SetWaitableTimer with completion routine │
│ - Callback runs in thread's context when timer fires │
│ - Thread must be in alertable wait state │
└─────────────────────────────────────────────────────────────────┘Timer queues, used by Ekko, offer a simpler interface for scheduling multiple callbacks. The system manages a pool of timer objects and dispatches callbacks efficiently.
Timer Queue Advantages:
1. Multiple timers share queue overhead
2. System manages callback thread pooling
3. Simpler API than raw waitable timers
4. Built-in cleanup mechanisms
Disadvantages:
1. Callbacks run in worker threads (not main thread)
2. Must synchronize with main thread for completion
3. Less precise timing than waitable timers
4. Timer queue activity may be monitored by EDRsThe Windows thread pool provides another timer mechanism through CreateThreadpoolTimer. These integrate with the broader thread pool API and may blend better with legitimate application behavior.
Understanding how security tools detect sleep evasion helps both attackers (to improve techniques) and defenders (to tune detection).
| Indicator | Description | Detection Difficulty |
|---|---|---|
| Memory entropy changes | Sudden entropy spikes when encryption occurs | Medium - requires baseline |
| RW/RX transitions | Frequent VirtualProtect calls on code regions | Easy - well documented |
| Timer queue activity | Multiple timer callbacks with suspicious patterns | Medium - noisy baseline |
| SystemFunction032 calls | Unusual use of this encryption function | Easy - uncommon in most apps |
| Stack anomalies | Frames that don't match UNWIND_INFO | Hard - requires sophisticated analysis |
| Unbacked executable memory | RX regions not mapped to files | Easy - standard detection |
Security vendors have developed responses to sleep encryption:
Entropy Monitoring: Track memory region entropy over time. Sudden increases suggest encryption. However, legitimate compression or data processing also causes entropy changes.
VirtualProtect Hooks: Monitor protection changes on executable regions. Multiple RW→RX transitions on the same region are suspicious. But this generates false positives from JIT compilers.
Timer Callback Analysis: Examine timer callbacks for chains that resemble encryption patterns. Difficult due to the prevalence of legitimate timer use.
Point-in-Time Scanning: Instead of periodic scans, scan immediately upon suspicious events. If the implant is executing, it must be decrypted.
Sleep Function Hooks: Intercept sleep calls to scan memory just before the thread sleeps. The implant hasn't encrypted yet at this point.
Effective sleep evasion considers these detection methods:
Different scenarios call for different levels of sleep evasion complexity:
Complexity Spectrum:
┌─────────────────────────────────────────────────────────────────────┐
│ LOW COMPLEXITY │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Technique: Simple XOR encryption │ │
│ │ Code size: Minimal (~100 lines) │ │
│ │ Evasion: Basic signature avoidance │ │
│ │ Use case: Quick tests, low-security environments │ │
│ └────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ MEDIUM COMPLEXITY │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Technique: Ekko-style timer encryption │ │
│ │ Code size: Moderate (~500 lines) │ │
│ │ Evasion: Memory scanning, basic behavioral │ │
│ │ Use case: Standard engagements, most EDRs │ │
│ └────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ HIGH COMPLEXITY │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Technique: Foliage (encryption + stack spoofing) │ │
│ │ Code size: Substantial (~1500+ lines) │ │
│ │ Evasion: Memory, behavioral, stack analysis │ │
│ │ Use case: Advanced EDRs, high-security environments │ │
│ └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘Sleep evasion represents a critical evolution in the offensive-defensive arms race. By recognizing that idle time creates detection opportunities, these techniques transform the vulnerability of dormancy into an asset. When an implant sleeps encrypted with a spoofed stack, it presents minimal attack surface to memory scanners.
The key concepts to remember:
| Technique | What It Protects | How It Works |
|---|---|---|
| Sleep Encryption | Code and data sections | Encrypt before sleep, decrypt on wake |
| Heap Encryption | Dynamic allocations | Track and encrypt heap regions |
| Stack Spoofing | Thread call stack | Replace with legitimate-looking frames |
| Timer Callbacks | Execution flow | Use system mechanisms to trigger decrypt |
| Key Rotation | Historical safety | Generate new key each sleep cycle |
These techniques work together synergistically. Sleep encryption alone might evade memory scanners but leave stack traces. Stack spoofing alone hides thread origin but leaves code exposed. Combined, they create comprehensive protection during the most vulnerable period of implant operation.
The next chapter explores persistence mechanisms—how implants survive system restarts and maintain access over extended periods.