Signed Nullsoft Plug-ins – potential Lolbins

A couple of years ago I exported ~12K Nullsoft plugins from a large corpora of installers. It was a part of my research on hooking Nullsoft plug-in APIs that I described here.

Today I revisited this old repo, because it crossed my mind that perhaps some of these DLLs were actually signed. And if they are, I thought, then perhaps some of them will tick the box of re-usigned libraries.

To my surprise, I found over 2K signed plug-ins.

Encouraged by these stats, I ran a script to list all the functions exported by these DLLs. Apart from default exports that can be found in the most popular Nullsoft plug-ins, I was able to find tones of other functions.

There are functions for pretty much every occasion:

  • Internet downloads
  • Resource handling
  • Message Boxes
  • Mathematical functions
  • FTP
  • File operations
  • Audio / Video
  • Unicode
  • Network enumeration
  • Process operations
  • Sqlite3
  • Encryption
  • HTML
  • SSH
  • Hooking
  • String operations
  • GDI / UI primitives
  • XML
  • ZIP
  • Zlib
  • and lots more

There are also ‘more refined’ self-descriptive functions e.g. CreateProcessInjected, InjectDll, _DownloadCompleteFile, SilentOpenURLA, KillAllXBrowserProcesses and a variation of KillProcess functions.

Given the variety of exported functions many of these DLLs must be based of source code of popular foss libraries. Why? It’s really hard to believe someone accidentally included all OpenSSL exports in a working Plug-in.

Being so feature-rich one could use these to build unusual code paths that would rely on code callbacks provided by these signed DLLs. In a way similar to ROP, except re-using functional code blocks instead of a single instructions, their small clusters, or trampolines.

Here’s the whole list if you want to have a look.

PE files and the DemoScene

One of the most creative ways of constructing PE files come not from malware authors, but from so-called DemoScene. Squeezing in everything possible in the smallest possible file is a form of an art. It has roots in competitions that forced the participants to use very restrictive environment to produce the best demo effect possible. From a file format perspective, this resulted in many cool productions where the PE file structure looks completely non-sensical, almost like non-PE, yet when executed, still produces some sort of demo effect.

See for yourself. Is this a valid PE file?

There is no visible DOS Stub, no strings, no library names, no API names, it looks like an old DOS MZ file. At least at a first glance.

It actually is a PE file though.

Many PE Editors, Viewers, and Dumpers have a serious problem analyzing this sort of files, because they can’t handle exceptions that happen during processing. They are typically triggered by some of the PE header structure fields being re-used by demos to store actual code/data for the presentation (no byte is wasted). These values tend to be random, and definitely outside of the boundaries of a file, or image in memory. Operating system loader ignores many of such out-of-bound indexes, while PE tools tend to ‘trust’ the content, and interpret them as valid values, and… eventually fail.

I won’t be naming names, but can confirm that among a couple of tools that I tested, some failed to load this file, some didn’t show proper code from the entry point, because they miscalculated the offset where the code is located.

Overall, it’s good to test your parsers by including such PE curiosities in your test bed (Scene.org is a great source for these, but don’t forget Corkami repo – Ange took the art of hand crafted PEs to a completely new level).