Recently, after looking at the difference between 0vercl0ck’s proof of concept and the real deal, a friend asked me “Why does PowerLoader go to all the trouble of using ROP chains instead of just executing the shellcode like 0vercl0ck does. PowerLoader gets the malicious code into the process by opening an existing, shared section already mapped into explorer, removing the need to allocate heap space or overwrite process memory. By opening “Shell_TrayWnd” and calling SetWindowLong, PowerLoader is able to set a variable used by the window procedure to point to a specific address in its shellcode. The read part won’t trigger DEP (Data Execution Prevention), if the section is not executable (in later versions of windows it is execute-protected), however if EAX points to an address inside the section, DEP will be triggered. Well how does one get from KiUserApcDispatcher to code execution, without executing the non-executable shellcode, I hear you ask. Next it pops the return address into the EAX and then calls it, this results in execution being transferred back to the Window Procedure. The sequences are instruction within the executable regions of explorer’s memory, their purpose is to perform certain operations as PowerLoader can’t execute any of its own code yet, due to the section being execute-protected. 00100E28 points to some code in explorer that executes the instruction “STD” followed by “RET”, As a result the instruction underlined in red will result in the direction flag being set and execution being returned to the Window Procedure. Well these bytes were found, in this case inside some random shell32 function (it doesn’t matter). Now the pointer doesn’t point to the start of the function, it points somewhere in the middle, as a result, only the bytes in the red box are executed. Remember: because all addresses points to executable code within explorer address space, and they are called using a pointer, no code in the shellcode is actually executed, thus resulting in no nasty DEP errors