Have been working on Windows internals security stuff and trying to figure out a couple things:
When consent.exe is launched, what is the structure of the memory block passed as the third parameter on the command line? Besides the path to the EXE itself, there is a PID for the parent process (AppInfo service running as AppInfo.dll within a svchost), there is block size, and there is a memory address into the parent process.
Process: C:\Windows\system32\consent.exe, ARGS: consent.exe 1072 468 000002050F426B301072 = the PID (for AppInfo service) 468 = size of the memory block 000002050F426B30 = the memory block address inside AppInfo service
We've been looking at the block and can parse some things, but it is undocumented. It's not in MSDN or the Windows Internals book... can't find anything where it is documented. At certain offesets into the block are visible strings to file paths and such...like the path to an MSI if elevation is needed for installation, or the path to an EXE if it needs elevation.
- Looked at some products who replace UAC consent.exe with their own version. How is that done? I see that consent.exe is launched by the AppInfo service. I attached ProcMon to see if the system looks for any special registry keys that would allow hooking the creation of consent.exe to use a different program, and I failed to see where it was possible to hook it. Now, the only thing I saw that maybe was hookable/interceptable was to replace the AppInfo service. The AppInfo service is a DLL started within svchost with the name of the DLL. If the service entry in the registry was changed to a different DLL, it would be possible to replace AppInfo and therefore that replacement AppInfo service could call a different version/replacement of consent.exe.
To summarize, I've scoured Google, searched Windows Internals, and run ProcMon and at a dead end to find:
- What is the structure of the memory address passed to consent.exe ?
- How could consent.exe be hooked/intercepted to replace it?