I found A way to implement Just in time decryption into my stager project for redteaming. All just in time decryptors I found either decrypted the payload instruction after instruction (which is incredibly slow) or completely in total at start of payload execution (which gives basically no benefit).
Lucky-Spark decrypts a sliding windows of memory pages to keep performance high and still provide protection against memory detection and reverse engineering.
I want to share my code here to maybe help you with your pentest or readteaming project or to show you how to encrypt your "legitimate" project to secure your intellectual property.
The project is not vibe coded and can be found here:
Schich
/
Lucky-Spark
A stealthy stager designed for shellcode payloads staged with http/https like Sliver, or on github raw.
LUCKY-SPARK
⟪ LUCKY-SPARK ⟫ is a stager designed for shellcode payloads staged with http/https like sliver or on github raw. It uses modern obfuscation and evaion methods like sliding window just-in-time decryption of the payload and cpu instruction patching By default it creates an executable masquarading as the filezilla ftp client.
Features
- Staged Sliver Payload Loader Downloads and executes a Sliver payload from a specified server.
- JIT Shellcode Decryption Decrypts only a sliding windows of the payload to minimise exposure.
- Fiber-based Execution Runs shellcode within fibers for improved stealth and complicating analysis.
- Dynamic API Resolution Suspicious or detection-prone Windows API functions are dynamically loaded at runtime.
- String Obfuscation Sensitive strings (e.g., URLs, user agents) are encrypted using an affine cipher and stored obfuscated in the compiled binary.
- Cpu instruction patching The aes cpu instructions re hidden behind unsuspicious cpu instructions like pmulqd and patched after execution.
- Automatic Disguise EXE is…
Top comments (1)
I'm intrigued by the approach of decrypting a sliding window of memory pages, as it seems to strike a balance between performance and security. The traditional methods of decrypting instruction by instruction or all at once do have significant drawbacks, and I can see how Lucky-Spark's approach would be more efficient and effective. By only decrypting the necessary pages, you're minimizing the attack surface while maintaining a decent level of performance. Have you considered implementing any additional features, such as anti-debugging or anti-emulation techniques, to further enhance the security of Lucky-Spark?