You are browsing the archive for Code Injection. SHAllocShared

December 25, 2020 in Code Injection

There couldn’t be a less misleading post title than the one I chose for this entry. The function SHAllocShared is documented, may not be very well known, but we may see it more in the future. It is exported by shlwapi.dll and its description has a nice vibe to it:

Allocates a handle in a specified process to a copy of a specified memory block in the calling process.

Hmm… I remember that 15+ years ago or so I was looking at the AppBar functionality. At that time many applications were taking advantage of this desktop feature, so I was really curious how it works. Eventually I created a simple POC that relied on SHAppBarMessage function to add my own app bar, but then got bored and forgot about it.

A few months back I suddenly remembered that POC. I realized that I have never looked at the internals of the SHAppBarMessage function, and with my experiments around code injection via GUI primitives this of course triggered my interest.

Under the hood, the SHAppBarMessage relies on SHAllocShared/SHLockShared and SHUnlockShared/SHFreeShared APIs to create&lock/unlock&free block of memory allocated within program’s address space, and then WM_COPYDATA message is used to send info about the appbar message to ‘Shell_TrayWnd’ window (tray window). Internally, SHAllocShared relies on CreateFileMapping/MapViewOfFile/DuplicateHandle API set to duplicate a handle to existing memory block inside a target process.

This is it. It’s not a lot, but having a set of atomic functions residing inside the shlwapi.dll is probably not a bad thing. This is not as robust as accessibility functions that do a lot of reading and writing of memory blocks between different processes, but it’s always good to have some extra feature at hand.

Propagate, Ribbonate

December 22, 2020 in Anti-Forensics, Code Injection, Forensic Analysis, Malware Analysis

I thought Propagate technique is a dead horse. Described, implemented, used in malware.


There is perhaps one more possibility, or four.

When you open Windows Explorer and Ribbons are enabled:

the UIRibbon.dll DLL gets loaded into this process address space:

One of the things the DLL does is setting properties of its internal windows using the following methods:

  • HWndContainer::Build(HWND hWnd, char a2, struct HWndContainer **a3)
    • Property:0xA91C
  • OfficeSpace::Root::SetEventLogger(OfficeSpace::Root *this, struct IUIEventLogger *a2)
    • Property: 0xBCDE
  • NetUI::SetCommandManager(HWND hWnd, HWND hData, struct NetUI::ICommandManager *a3)
    • Property:0xBCDF
  • UXHwndEffectsManager::FInitialize@(HANDLE hData@, HWND hWnd@, bool a3, bool a4, bool a5)


So, what do we do with this?

These are all possible targets for a Propagate code injection as all these properties appear to be holding virtual table pointers…