[C++]Visual Studio - Geen/corrupte DLLMain export

[sh4d0wman]

Probleem: Ik probeer een simpele DLL te maken maar krijg DLLMain niet exported e.g. niet terug te vinden met "Dll Export Viewer" en de foutmelding met rundll32.exe dat DllMain niet gevonden kan worden.

Code:
Ik ben begonnen met de standaard code van Visual Studio 2017:
(nieuw project -> Visual C++, Win Desktop, DLL)

Met deze code wordt DllMain niet geexporteerd in zowel de x86 als x64 builds wanneer ik naar release compile.

C++:

dllmain.cpp

BOOL WINAPI DllMain(  
         HINSTANCEhinstDLL,  // handle to DLL module
         DWORD fdwReason,     // reason for calling function
         LPVOID lpReserved )  // reserved
{
    // Perform actions based on the reason for calling.
    switch( fdwReason )
    {
    case DLL_PROCESS_ATTACH:
        // Initialize once for each new process.
        // Return FALSE to fail DLL load.
        WinExec("calc", 1);            
        break;

    case DLL_THREAD_ATTACH:        
        // Do thread-specific initialization.
        break;        
   
    case DLL_THREAD_DETACH:
        // Do thread-specific cleanup.            
        break;
   
    case DLL_PROCESS_DETACH:        
        // Perform any necessary cleanup.
        break;    
    }
        return TRUE;
}

Verander ik het naar:
A.

C++:

BOOL APIENTRY DllMain of BOOL  __stdcall DllMain

dan is er nog steeds geen DllMain export terug te vinden in zowel de x86 als x64 DLL.

Neem ik de volgende code op:
B.

C++:

#define EXTERN_DLL_EXPORT extern "C" __declspec(dllexport)
EXTERN_DLL_EXPORT BOOL WINAPI DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)

Dan is in een x64 build DllMain terug te vinden en werkt de DLL (start calc.exe of MsgBox).
Getest door de DLL in een applicatie te injecteren en te laden met "rundll32.exe test.dll DllMain"

Echter in een x86 build is DllMain mangled en geeft _DLLMain@12 als export in "Dll Export Viewer".
De applicatie wil de DLL niet laden en rundll32 geeft de foutmelding "Missing entry: DLLMain" maar start wel calc.exe of de MsgBox.

Waarom werkt DllMain niet "by default" en hoe los ik dit op?
Het zal wel iets simpels zijn maar ik zit er al een week op vast.

[Radiant]

DllMain is normaliter geen export. Je maakt aparte functies die je export en die roep je aan (ofwel met rundll32 of vanuit een ander programma). DllMain wordt aangeroepen zodra de DLL wordt geladen of geunload; hierin kan je globale initialisatie doen, resources vrijgeven, etc. mocht je dat nodig hebben.

https://docs.microsoft.co...dows/desktop/dlls/dllmain
MSDN: Exporting from a DLL Using __declspec(dllexport)

[sh4d0wman]

@Radiant: dat snap ik als we een volwaardige dll willen bouwen. Echter is het in dit geval genoeg dat DllMain een stukje code draait, ik wil geen export beschikbaar maken.

Inmiddels heb ik onderstaande code:

Op x86 kan een process deze laden en uitvoeren. Echter rundll32 kan nog steeds geen DllMain vinden.
Op x64 kan een process deze laden en uitvoeren. Ook kan rundll32 DllMain vinden.
Dus opzich kan ik nu verder maar lijkt er met VisualStudio by design iets niet lekker te gaan met een x86 build.

C++:

// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"
#include <windows.h>

int dll_hijack();

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        dll_hijack();
        return 0;
    case DLL_THREAD_ATTACH:
        break;
    case DLL_THREAD_DETACH:
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

int dll_hijack()
{
    MessageBox(0, L"DLL Hijacking!", L"DLL Message", MB_OK);
    return 0;
}

[.oisyn]

Je haalt wat dingen door elkaar. Wat rundll specificeert als "entry point" is niet je DLL entry point. Het enige dat rundll doet is je dll laden met LoadLibrary(), en hij gaat dan op zoek naar de opgegeven "entry point" met GetProcAddress(). Daarvoor moet de opgegeven functie natuurlijk wel ook geexport worden. Bovendien moet hij voldoen aan de volgende signature:

C++:

void CALLBACK EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);

Je DLL entry point is een stuk code dat wordt aangeroepen zodra je DLL wordt geladen in een proces. Die hoef je niet te exporteren.

[Radiant]

Misschien is het handig om even te beschrijven wat je uiteindelijk wil bereiken. Als je een DLL wil die alleen iets uitvoert als LoadLibrary() wordt aangeroepen, dan kan je af met een DllMain. Dan heb je echter een vrij nutteloze DLL.

[.oisyn]

Radiant schreef op vrijdag 12 oktober 2018 @ 11:50:
Misschien is het handig om even te beschrijven wat je uiteindelijk wil bereiken. Als je een DLL wil die alleen iets uitvoert als LoadLibrary() wordt aangeroepen, dan kan je af met een DllMain. Dan heb je echter een vrij nutteloze DLL.

Aan zijn code te zien probeert hij gewoon custom code te injecteren in een andere executable (dmv "dll hijacking"). Dan heb je genoeg aan het gewoon het inladen van je DLL in het andere proces. Zijn code testen met rundll is dan niet zo handig, tenzij hij gewoon voor de vorm een dummy functie opneemt en die exporteert.

[Voor 11% gewijzigd door .oisyn op 12-10-2018 12:22]

[sh4d0wman]

@.oisyn
Ja, ik snap inmiddels dat DllMain niet geexporteerd hoeft te worden echter verklaart dit niet het afwijkende gedrag wat ik nu zie.

Waarom kan rundll32 DllMain wel vinden als ik voor x64 compileer maar niet voor x86? (dus zonder een export functie van DllMain te maken)

Beiden injecteren nu wel zonder probleem in het process.

@Radiant

Ik wil inderdaad simpelweg code injecteren in een bepaald process. Tot op heden was het genoeg om een simple calc.exe of messagebox via Metasploit DLL te gebruiken om DLL hijacking aan te tonen.

Echter nu wil ik DLL hijacking gebruiken om op een bepaalde locatie iets aan te passen door misbruik te maken van het vertrouwde process waar ik in injecteer. Hiervoor moet ik dus wat custom commando's laten uitvoeren hence the need om zelf te compilen vanaf scratch.

Het enige wat de DLL moet doen is wat code uitvoeren in DllMain. Dus vanuit programmeer gebied gezien een nutteloze DLL ja.

[Radiant]

De tweede stap die rundll32 doet is niet zo interessant voor je (het opzoeken van de function/ordinal van de export die je wil uitvoeren) dus je kan beter gewoon een C-programmatje maken dat alleen LoadLibrary() aanroept om te testen.

De reden waarom rundll32 de x86 versie niet pakt zal wellicht zijn omdat je een 64-bit-OS hebt en de 32-bit-versie (WOW) van rundll32 moet hebben (naam is verwarrend ja, ze heten allemaal rundll32). Die staat in C:\Windows\SysWOW64.

[sh4d0wman]

@Radiant bedankt ik zal er vanavond nog eens naar kijken. Ik compileer op 64-bit en zet dan de x86 DLL over naar een 32-bit virtual machine. Volgens mij heb ik rundll32 op beide omgevingen getest maar heb inmiddels begrepen dat het weinig zinvol is om als test te gebruiken tenzij ik een export in de DLL heb zitten.

[.oisyn]

Maar dat komt dus omdat je een functie probeert aan te roepen die niet bedoelt is voor rundll. Het probleem zit 'm in de __stdcall name mangling. In 32 bits geeft dat een leading underscore en een @ postfix met het aantal bytes van de parameters: _DllMain@12. In 64 bits wordt de name helemaal niet gemangled: DllMain

En daar zit dus het probleem. Want rundll zoekt een __stdcall functie die voldoet aan zijn signature: 3 pointers en een int, in totaal 16 bytes, dus _DllMain@16. Jouw DllMain's signature klopt niet met wat rundll verwacht, en daarom is ie verkeerd gemangled.

(De technische reden voor het verschil is dat __stdcall in 64 bits eigenljik niet meer bestaat en gewoon wordt geignored. Bij __stdcall is de callee verantwoordelijk voor het opruimen van de parameters die door de caller op de stack zijn gepushed, dmv een RET n instructie. In 64 bits zijn er geen verschillende calling conventions; de enige convention is dat de eerste parameters via registers gaan, de rest op de stack wordt gepushed, en caller is verantwoordelijk voor opruiming.

Het probleem bij __stdcall is dat als de caller een andere hoeveelheid parameters passt dan de callee verwacht, je stack corruption krijgt. Vandaar dat het aantal bytes van de parameters in de name mangling staan.)

[Voor 46% gewijzigd door .oisyn op 12-10-2018 12:46]

[sh4d0wman]

@.oisyn
Aha, dus als ik het nu goed begrijp kun je met rundll wel een export aanroepen (waarbij je als je niet oppast ook name mangling kan krijgen) maar niet DllMain.

Ik was er al wel achter dat er name mangling optrad en had er voor exports ook over gelezen. (toen ik DllMain exporteerde zag ik al dat deze in x64 normaal is en in x86 __DLLMain@12 ofzo werd)

Echter het verschil in loaden via een process vs rundll was het grote onbekende voor mij.
Dus daar kan ik het beste een simpele loader voor schrijven of domweg de DLL bij het target proces droppen.

edit: je edit verduidelijkt het maar toen had ik al gepost

[Voor 5% gewijzigd door sh4d0wman op 12-10-2018 12:54]

[.oisyn]

sh4d0wman schreef op vrijdag 12 oktober 2018 @ 12:53:
@.oisyn
Aha, dus als ik het nu goed begrijp kun je met rundll wel een export aanroepen (waarbij je als je niet oppast ook name mangling kan krijgen) maar niet DllMain.

Hij mag best DllMain heten, als hij maar 16 bytes aan parameters heeft. En dat conflicteert natuurlijk met het standaard entrypoint dat de crt verwacht voor je dll