Author Archives: adam

RunDll32 — API calling

Posted on by

This is a quickie.

Using rundll32 to run stuff is well-known. You can load DLLs, and call APIs.

Sometimes tho, we may get confused about data format we need to provide to APIs. If your API accepts an ANSI, or a Unicode string, different rules apply.

The best way to test _any_ API executed via rundll32.exe is to call it by a ‘native’ name w/o a suffix (A or W). This way, it will go through a sequence of:

  • Loading our DLL
  • Retrieving an address of the API with a ‘W’ suffix (Wide/Unicode)
  • Retrieving an address of the API with a ‘A’ suffix (ANSI),
  • Retrieving an address of the API with no suffix at all (ANSI, assumed)

What it means (practically) is that if you supply an API name with a ‘A’ or ‘W’ suffix, the sequence of API name resolving is going to look like this:

  • FunctionNameAW
  • FunctionNameAA
  • FunctionNameA

or

  • FunctionNameWW
  • FunctionNameWA
  • FunctionNameW

Knowing the way rundll32.exe accepts and processes the API function names is actually very helpful – especially when you are calling functions that require Unicode strings as an argument…

ALPC Ports

Posted on by

In my post about SilentProcessExit I mentioned an ALPC interface. Programs (clients) using this mechanism usually connect to a specific port (addressed via a unique name), and then exchange messages with a server.

I was curious what other native ALPC ports exist out there apart from WindowsErrorReportingServicePort, and this post is an attempt to list as many of them as possible…

After looking at executables and libraries that reference ZwAlpcConnectPort and NtAlpcConnectPort functions, I came up with this list (port + list of files that references it):

  • \WindowsErrorReportingServicePort
    • Faultrep.dll
    • PsmServiceExtHost.dll
    • WerFault.exe
    • audiodg.exe
    • audiosrv.dll
    • daxexec.dll
    • dwmghost.dll
    • modernexecserver.dll
    • ntdll.dll
    • psmsrv.dll
    • wermgr.exe
    • werui.dll
    • win32kfull.sys
    • winsrvext.dll
  • \PdcPort
    • AzureSettingSyncProvider.dll
    • DeviceDirectoryClient.dll
    • DeviceEnroller.exe
    • InstallService.dll
    • LocationFramework.dll
    • LockController.dll
    • LockHostingFramework.dll
    • MusNotification.exe
    • NcaSvc.dll
    • NetEvtFwdr.exe
    • OneDriveSettingSyncProvider.dll
    • PsmServiceExtHost.dll
    • SensorService.dll
    • SettingSyncCore.dll
    • SettingSyncHost.exe
    • TpmCoreProvisioning.dll
    • WPTaskScheduler.dll
    • Windows.Cortana.OneCore.dll
    • Windows.Devices.Haptics.dll
    • Windows.System.SystemManagement.dll
    • audiosrv.dll
    • bisrv.dll
    • cdp.dll
    • dhcpcore.dll
    • dhcpcore6.dll
    • diagtrack.dll
    • dmcertinst.exe
    • gpsvc.dll
    • modernexecserver.dll
    • moshostcore.dll
    • ncsi.dll
    • networkhelper.dll
    • ngcrecovery.dll
    • omadmclient.exe
    • powrprof.dll
    • qmgr.dll
    • rdbui.dll
    • sysmain.dll
    • termsrv.dll
    • tetheringservice.dll
    • twinui.pcshell.dll
    • ubpm.dll
    • umpo.dll
    • updatehandlers.dll
    • usocore.dll
    • wbiosrvc.dll
    • wcmsvc.dll
    • wer.dll
    • wifinetworkmanager.dll
    • wifitask.exe
    • wpncore.dll
    • wpnprv.dll
    • wuaueng.dll
    • wwansvc.dll
  • \BaseNamedObjects\FontCachePort
    • DWrite.dll
  • \RPC Control\AutoRotationApiPort
    • RotMgr.dll
  • \ConsoleInputServerPort
    • conhost.exe
  • \BaseNamedObjects\msctf.server
    • msctf.dll
  • \SmApiPort
    • ntdll.dll
  • \PowerPort
    • umpo.dll
  • \SmSsWinStationApiPort
    • winsrvext.dll

I know there are a possibly a few more, but static analysis were not worth it to chase after names passed via complex set of arguments/structures and nested functions. We will eventually figure it out anyway.

There is an interesting bit I came across with regards to WER Port (\WindowsErrorReportingServicePort). It would seem that its name is configurable and specified by this Registry Entry:

HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ErrorPort=<Port name>

The thing tho is that some of the Windows components retrieve that name dynamically, and some rely on a hard-coded name…

Another ALPC server that is configured via Registry is WDI ALPC Server:

HKLM\SYSTEM\CurrentControlSet\Control\WDI\Config
ServerName =<Port name>

And that’s it… If anything, at least you can use these names in your further research. There is a possibility some of them don’t check the message data integrity and this could lead to some new vulnerabilities being discovered. And if not, it’s always a good thing to know which strings we come across are actually OS-native. I think ALPC needs a lot more research and we will hear about more of its issues in the future.

Adding some bits here after posting the main post:

The \PdcPort is very interesting as many components ‘talk to it’; quick check confirms that the Port is created by a kernel driver pdc.sys.