In the evolving landscape of cybersecurity, obfuscation plays a critical role in protecting against intrusive memory scans.

‘FLOWER’ emerges as a groundbreaking technique, offering a fresh approach to sleep obfuscation. Developed by bakki at, FLOWER leverages unique methods to queue the ropchain, enhancing compatibility and evading detection.

This article delves into the intricacies of FLOWER, exploring its implementation, versatility, and the strategic advantages it offers in the digital defense arsenal.

 * flowing sleep obfuscation 
 * bakki -

This is a primitive implementation of the technique I discuss in my blogpost

for any technical explanation, caveats or IOCs, do give it a read.

A version of this that does not rely on any external technique to queue the ropchain will be made available.


To showcase the compatibility of this technique, several flags are made available for the user


Self explanatory, specifies which technique you wish to use to queue the ropchain



Freeing the old region means a copy of our shellcode is still there for as long as the old region does not get used.

Considering changing the protection back to RW has, at this time, no perceivable caveats stealth wise; I added the option to zero out the old region before freeing it.



Using jump gadgets is nowadays the preferred way to evade the PATRIOT memory scanner which targets the research of both @C5pider and ilove2pwn_.

In simple terms, PATRIOT will check if the Rip field of a CONTEXT struct points to a *Protect function.

Since it doesn’t inspect non-volatile registers we can simply store the address of our function in a non-volatile register and point the Rip of the CONTEXT to an arbitrary gadget that jumps to said register.

// use the given register to store our function address
// we then execute it through a JMP gadget


Will conceal the instruction pointer (RtlUserThreadStart + 0x21) and stack of the beacon thread (Rsp pointing to an empty buffer)