SmokeLoader Malware Analysis

Initial examination reveals that all memory regions are configured with Read/Write/Execute permissions, enabling the malware to perform extensive self-modification during runtime.

Dynamic debugging requires a hardware breakpoint at 0x401ae0. Software breakpoints must be avoided as they modify the malware's code by inserting CC bytes, which interferes with the unpacking process and can cause analysis failures.

I dumped the process memory to Ghidra for combined static analysis. However, initial static analysis revealed that portions of the executable remain encoded even after the initial unpacking phase.

Further investigation revealed SmokeLoader's sophisticated anti-analysis technique: polymorphic code execution. The malware follows this pattern:

1. Decode → Execute → Re-encode

This continuous cycle makes traditional static analysis extremely challenging, as the code constantly changes its appearance in memory.

To overcome this limitation, I developed a technique to capture decoded instructions during execution. The process involves:

1. Execute the malware until reaching the target function (e.g., 0x40410a)
2. Capture the decoded bytes while they're in plaintext
3. Patch the dumped executable with the decoded instructions
4. Repeat for each polymorphic section

The first major function at 0x40410a implements dynamic API resolution, loading function addresses from system DLLs into uninitialized data sections:

This function is significantly longer than shown and systematically resolves all required Windows APIs for the malware's operation.

After renaming the data variables to their corresponding function names in Ghidra, static analysis became considerably more manageable. However, many functions still utilize internal decoder() routines, requiring continued dynamic extraction of their true implementations.

One significant discovery involves the malware's filename detection capability:

The function checks the current executable's filename and returns different values based on the name. In my analysis with a randomized filename, it returned 0x10, but other predetermined names trigger different behavioral modes.

The filename comparison mechanism is straightforward:

This suggests the malware can operate in multiple modes depending on how it's deployed or executed.

The malware implements a persistence mechanism involving a process named WinSrv32. The core functionality includes:

Process Termination: Locates and terminates any existing WinSrv32 processes File Replacement: Deletes the existing WinSrv32 executable Self-Replication: Writes a copy of itself (or a modified version) to the WinSrv32 location Execution Transfer: Launches the new WinSrv32 process to continue execution

Due to university final examinations, I had to suspend the analysis before completing a full behavioral breakdown. While I successfully decoded critical components and understood the core unpacking mechanisms, several areas remain unexplored:

Complete payload analysis Network communication protocols Full persistence mechanism details Command and control functionality

I'm providing the following analysis artifacts for future research:

Ghidra Project File: Complete project with renamed functions and decoded sections x32dbg Database: Contains breakpoint configurations and analysis notes Memory Dumps: Process dumps at various execution stages

These resources are available in the same directory as this analysis report.