TOOLS / PE Analysis

SideFinder

A Windows application that identifies and validates DLL sideloading opportunities in PE files and generates test, sideload or proxy DLLs.

SideFinder brings PE file analysis, candidate prioritisation and DLL load validation together in a single interface. It automates import inspection, path resolution, export reconstruction and load testing.

The article DLL Sideloading made simple with SideFinder explains the technique through a practical example. This page documents SideFinder's features and options.

Main capabilities

  • Analyses x86 and x64 executables and DLLs, including regular, delay and bound imports.
  • Classifies potential candidates using contextual scoring.
  • Checks architecture, Authenticode signatures, CFG, CET, subsystem and LoadLibrary usage.
  • Resolves search paths, KnownDLLs, missing dependencies and DLLs located alongside the application.
  • Correlates static analysis with modules observed during execution.
  • Scans complete directories and lets you return to the results to continue the analysis.
  • Enriches findings with the community-maintained HijackLibs database.
  • Generates test, sideload or proxy DLLs and can compile them automatically.

Requirements

PE analysis works directly from the application. Compiling generated DLLs and running one-click tests requires a compatible C++ toolchain:

  • Visual Studio Build Tools with the Desktop development with C++ workload.
  • MinGW-w64 with g++.exe available in PATH.

SideFinder looks for cl.exe, vswhere.exe, vcvarsall.bat, g++.exe and x86_64-w64-mingw32-g++.exe. If no compiler is found, it can still generate the source code and build files, but it will not automatically produce the final DLL.

Analysing a binary

Drag the executable or its shortcut into the window, or use Load Binary to select it. SideFinder processes the PE and presents three main sections.

Target Info

Displays the effective path, architecture, signature and protections of the target. Check this information before generating a DLL: the architectures of both artefacts must match.

Import Table

  • Imports: dependencies normally resolved during loading.
  • Delay Imports: dependencies resolved when the program uses them.
  • Bound Imports: information about previously bound imports, when available.

Sideload Candidates

The table brings the candidates together and sorts them by score. Its columns help explain why a DLL appears in a particular position:

IndicatorHow to interpret it
HijackablePath resolution may allow a copy placed alongside the executable to be loaded.
App DLLA dependency belonging to the application's directory or package.
DelayIt may be loaded later during the application's execution flow.
MissingIt is referenced but was not found in the evaluated paths.
DocumentedA match exists in the local HijackLibs database.
ExportsNumber of exposed functions; a high value usually increases proxy complexity.

The score orders the candidates so you can decide which ones to test first. Confirmation comes from running the load test.

Validating a candidate

Select a row and click Test Sideload. SideFinder generates a test DLL with a MessageBox routine, attempts to compile it, prepares the required files and runs the target.

The message confirms code execution, but you should also verify that:

  • The process corresponds to the binary you intended to analyse.
  • The DLL was loaded from the expected path.
  • The application continues to start and retains its main functions.
  • No plugin, initialisation or dependency errors appear.

If the test executes code but breaks the application, repeat it using a proxy DLL that preserves the original library.

Running dynamic analysis

Click Run Dynamic Analysis to observe the modules loaded during execution. SideFinder keeps the process active during the analysis window, collects the observed DLLs and updates the candidate table.

The analysis only covers execution paths reached during that period. If a dependency is loaded after opening a menu or performing a specific action, interact with the application during capture or repeat the test using the appropriate flow.

Scanning a directory

Use Scan Directory and select the folder you want to inspect. By default, SideFinder traverses up to three levels of subdirectories.

Once complete, a summary appears for each binary with the number of confirmed and potential candidates. Double-click a row to load that executable in the main window.

The Scan Results button lets you return to the summary without repeating the scan.

For large directories, narrow the path first to reduce analysis time and duplicate results.

Enabling HijackLibs

Open Tools, enable Enable HijackLibs, and select Update HijackLibs Database to download the latest version of the database.

When a row displays Documented, double-click the indicator to review known matches, associated binaries and their paths.

The Documented flag confirms that HijackLibs contains a related entry. Test the combination again because the result may vary between versions, paths and system configurations.

Finding matches on the system

From Tools > Scan System for Sideloading, SideFinder compares documented paths with applications present on the machine.

Validate each result from the main window before considering it functional.

Generating a DLL

Select the candidate and click Generate Proxy DLL. The generator lets you control the library type, export source, execution point and validation payload.

Proxy DLL and Sideload DLL

  • Proxy DLL: generates the required exports and forwards calls to a renamed copy of the legitimate library. This is the appropriate option when the program needs the original functionality.
  • Sideload DLL: exposes the expected symbols through minimal implementations. It is useful for quickly validating a load, but may degrade functionality or cause the application to terminate.

In proxy mode, you must keep the original DLL alongside the generated one under the configured alternative name.

Export source

The original DLL's EAT is generally the recommended source because it describes what the library actually exports. Information derived from the IAT is limited to the functions imported by the analysed binary and may omit exports used by plugins or other modules.

Execution point

  • DllMain: runs the routine when the loader attaches the DLL to the process. It is direct, but work performed inside DllMain should be kept to a minimum.
  • Selected export: delays the routine until the application invokes a specific function. You must verify that this execution path is reached reliably.

Validation payload

  • MessageBox: displays a message when the DLL loads, making the execution flow easy to verify.
  • Custom: provides a template for adding custom logic to the proxy.
  • Shellcode Runner: reads a binary payload from an external file and executes it using the selected method.

The external file can use extensions such as .dat, .ini or .txt. It can also be appended to a carrier file such as an image. This mechanism does not make the payload undetectable; it simply separates its data from the DLL and must be evaluated against the controls in the environment.

Execution method

The available options run the routine inside the process that loaded the DLL:

  • Callbacks: reuse an API that invokes a function supplied by the program. Their behaviour and constraints depend on the selected API.
  • Thread Pool: schedules the work on the process's thread pool infrastructure, avoiding the explicit creation of a dedicated thread.
  • Fibers: converts or uses a thread as a fiber and transfers execution to another cooperative context. The generated code must return control to the original fiber to avoid interrupting the thread.

The choice depends on when the DLL is loaded and how the process must continue after the routine runs.

Generated files

After clicking Generate, SideFinder opens the project directory. It contains the source code, build files and an output folder with the generated binaries.

In a typical proxy setup, the final directory contains:

  • The generated DLL using the name expected by the application, for example VERSION.dll.
  • The renamed legitimate DLL, for example notVERSION.dll.
  • The external data file, when required by the configuration.

After copying them alongside the executable, run the test and confirm that the program retains its functionality.

Common problems

The DLL is not generated

Check that a compatible compiler is installed, that its architecture matches the target, and that SideFinder can locate it. If no compiler is available, use the generated project and compile it manually from a configured console.

The MessageBox does not appear

Check the DLL path, exact name and architecture, and make sure you are starting the analysed executable. If it is a delay import, reproduce the action that triggers its loading.

The application closes or loses functionality

Generate a Proxy DLL, use the original library's EAT, and check that the renamed legitimate DLL is present. Also review transitive dependencies and ordinals.

Dynamic analysis does not add candidates

Interact with the relevant functions during the capture window. Some DLLs only appear after opening a dialogue, loading a plugin or accessing a specific feature.

HijackLibs does not show documentation

Confirm that the integration is enabled and update the database. If no matches appear, the local database does not contain an entry for that candidate.

Building SideFinder from source

The project uses Dear ImGui and DirectX 11. Its Makefile can generate a static Windows executable from Linux using MinGW-w64:

sudo apt install make mingw-w64
git clone https://github.com/mxngel/SideFinder.git
cd SideFinder
make

The result is saved as SideFinder.exe. You can also use make debug to create a build with console output, and make clean to remove generated artefacts.

Licence and components

SideFinder is released under the MIT licence. The repository includes Dear ImGui under its own MIT licence and can optionally integrate data from HijackLibs.

RELATED / 01

Keep exploring

Back
No more published entries yet.