Category Archives: Archaeology

Not installing the installers, part 4

Posted on by

This old series is not very exciting. Decompiling goodware installation scripts will never lead us to newsworthy discoveries – feel free to stop reading now.

Many installers copy files, add/change registry keys and values, install services, drivers, and do all that while their GUIs sometimes tell us what is happening, and occasionally ask us to guide them. Superboring stuff.

If you are still reading…

Recently, I noticed that some of the aforementioned ‘add/change registry keys and values’ activities affect the Process Environment block. The most popular modification is (obviously) focused on the PATH environment variable – installers just love adding new directories to it!

BUT

There is more.

The below is a list (not exhaustive) of other environment variables that are being added by installers:

  • ACE_STUDIO_PATH
  • BRAINGINES_PATH
  • CC_PIXEL_RATIO
  • DELIGHT
  • FLOW_PATH
  • FMXLINUX
  • GIT_LFS_PATH
  • GPU_AUDIO_PLUGIN_INSTALLATION_PATH
  • IDF_TOOLS_PATH
  • IFCEXPORTER
  • INTELBRAS_AMTRD_JAVA_HOME
  • JAVA_HOME
  • JETTY_WEB_HOME
  • JIOCLOUD_INSTALL_TYPE
  • LANDO_INSTALL_PATH
  • LANG
  • LANG_PSERVER
  • P3DEXPORTER
  • QT_DEVICE_PIXEL_RATIO
  • RTOOLS43_HOME
  • RTOOLS44_AARCH64_HOME
  • RTOOLS44_HOME
  • XR_RUNTIME_JSON

While some of them seem to be quite unimportant, a lot of them seem to be asking for some … abuse (aka research) ?

I mean… anything that includes ‘PATH’ or ‘HOME’ in their name needs an appropriate research-driven follow-up.

Why?

All of them are under HKCU, so anyone can modify them. Secondly, these environment variables may open new ways to abuse legitimate, often signed binaries to do something they never intended to do – and as such, create new lolbin opportunities. It could be loading plug-ins from a malicious location, it could be executing framework binaries from a controlled location, there is definitely a scope for research here.

Mapping the API mapping/code redundancy

Posted on by

In my last post I have shown that some of the shell32.dll functions are now mapped to windows.storage.dll.

This sort of API mapping, as well as blatant code redundancy present in many Windows binaries is not new, and we have seen many instances of it over the years:

  • Windows API sets
  • gdi32.dll and gdi32full.dll
  • gdi32full.dll and win32u.dll
  • combase.dll and ole32.dll
  • kernel32.dll and KernelBase.dll
  • IEAdvpack.dll and advpack.dll
  • crtdll.dll, msvcirt.dll, ucrtbase.dll and their many, many versions over the years
  • ntdll.dll and ntoskrnl.exe (user mode vs. kernel mode mapping)

and so on, and so forth.

It is probably not surprising that after that latest discovery it was only natural for me to build a list of APIs (API names) that are shared between many libraries to see if I can discover more interesting bits.

Looking at the list of API names that appear to be shared between at least 2 DLL libraries on the Windows 11 24 H2 build – win11_24H2_list_64_shared.txt – one can immediately see a lot of interesting findings:

  • sqlite functions are exported by SearchIndexerCore.dll, StateRepository.Core.dll, winsqlite3.dll
  • apart from kernel32.dll and KernelBase.dll there is now also kernel.appcore.dll
  • code base of tcblaunch.exe and winload.exe seems to be overlapping a lot
  • edgehtml.dll replaces mshtml.dll

Unfortunately, I have not seen anything similar to ShellExec_RunDLL – a discovery that kicked off this research 🙁