This is just a blurb for an idea that I posted on Twitter today. I have not figured it out yet per se, but just jotting down notes.

Programs reading command line by design as well as software offering assistive technology offer an interesting opportunity to inject stuff into their process via reverse data injection. That is, the sole nature of them reading data from other processes will copy for us buffer we feed to them. Then just need to find out what is the address of that buffer & execute it (the latter is harder part).

As I was testing how popular methods of listing processes and command line retrieval work I noticed some inconsistencies in the way various programs report the results. The following list the preliminary findings:

Process list tools show command line buffer program started with

• Tasklist /v
• WMIC path win32_process
• Get-Process – doesn’t show command line line! need to use Get-WmiObject
• Taskmgr.exe

Process list tools show command line buffer program modified after start:

• Process Hacker
• Process Explorer (truncated to first Unicode null character)

This is not a huge difference, but in the instance of Process Hacker and Process Explorer you could use the fact they read the most up to date buffer content to e.g. transmit data in chunks, plus you don’t need to feed the logs with shellcode passed as a command line (i.e. can change command line buffer in memory, and only after child program is launched).

With regards to assistive technology, I covered it in the past. Their under the hood secrets rely heavily on ReadProcessMemory function that is reading data from other controls, hence you could feed a shellcode this way to a UI automation software.

All righty… this is a cool one, because it’s so… vague.

How do you describe a generic code execution technique without showing examples?

You show le video…

Then you explain that… any windows message above WM_USER is a potential code execution massacre. Yes. The GIF you looked at is just a simple example of enumerating all windows and their children, and then running a simple loop on all the windows handles. Each iteration of that loop sends a Window Message WM_USER (up to WM_USER+1000) to these windows owned by various processes.

It sounds stupid but it’s not. It counter-marshals (pun intended) the whole system of windows message marshaling…

Common controls use WM_USER+ messages. Custom controls use WM_USER+ messages. Every app is most likely using _some_ controls that are relying on WM_USER+ message. So yeah.. you just narrow this one down that allows you to swap content of a pointer of your choice and you have your code running inside another process user space.

This is the most vague code injection post you will probably come across, but let me tell you this: it describes a whole class of shatter attacks that are either happening, or are going to happen.

Hint: a good message to start playing with is EM_SETTEXTEX (WM_USER+97).

People pointing out Brett Moore’s work are absolutely right. The above idea is identical in principle, just generalized to cover the whole WM_USER spectrum (that includes custom messages that are application-specific & may require per-app research which opens up a lot of pathways to custom code injections e.g. Nvidia, AMD, Intel, Dell etc. GUI applications that are always on).