DLL Injection

[GordonFreeman]

i tried to inject a dll into another process,but CreateRemoteThread() fails :(




const char szDLL[] = "somedll.dll";

void RemoteLoadDll(HANDLE,const char *);


int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,INT){
RemoteLoadDll(GetCurrentProcess(),szDLL); // i also tried with handles to different processes
return 0;
}


void RemoteLoadDll(HANDLE hProcess,const char *szDll){

char szLibPath[_MAX_PATH];

void* pLibRemote; // The address (in the remote process) where
// szLibPath will be copied to;
DWORD hLibModule; // Base address of loaded module (==HMODULE);
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");

// initialize szLibPath
strcpy(szLibPath,szDll);

// 1. Allocate memory in the remote process for szLibPath
// 2. Write szLibPath to the allocated memory
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),
MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,
sizeof(szLibPath), NULL );

MessageBox(NULL,"before createremotethread()","remoteloaddll()",MB_OK);

// Load DLL into the remote process
// (via CreateRemoteThread & LoadLibrary)

// THIS WILL RAISE A MEMORY ACCESS EXCEPTION...WHY??

hThread = ::CreateRemoteThread( hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
"LoadLibraryA" ),
pLibRemote, 0, NULL );

MessageBox(NULL,"after createremotethread()","remoteloaddll()",MB_OK);

::WaitForSingleObject( hThread, INFINITE );

// Get handle of the loaded module
::GetExitCodeThread( hThread, &hLibModule );

// Clean up
::CloseHandle( hThread );
::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );

}




help


p.s. rispondete in italiano please :D

[71104]

CreateRemoteThread fallisce perché non hai passato il puntatore al DWORD per ricevere l'id del nuovo thread; in questo modo fallirebbe pure la CreateThread :)

comunque se ti può interessare sto sviluppando una DLL molto più sofisticata; il vecchio trucchetto della CreateRemoteThread con la LoadLibrary come entry point è banale perché la DLL caricata è visibile; la mia invece è invisibile perché anziché caricarla con LoadLibrary l'ho mappata manualmente con un File Mapping Object ;) di conseguenza non viene registrata dal sistema operativo.

inoltre ho applicato numerose altre tecniche per proteggerla dai crackers: anti disassemblaggio, anti monitoraggio delle API, e un po' di altre cose.

se ti interessa dimmelo che posto il codice (che attualmente però ha dei problemi che sto cercando di risolvere).

ciao

[GordonFreeman]

CreateRemoteThread fallisce perché non hai passato il puntatore al DWORD per ricevere l'id del nuovo thread; in questo modo fallirebbe pure la CreateThread :)

comunque se ti può interessare sto sviluppando una DLL molto più sofisticata; il vecchio trucchetto della CreateRemoteThread con la LoadLibrary come entry point è banale perché la DLL caricata è visibile; la mia invece è invisibile perché anziché caricarla con LoadLibrary l'ho mappata manualmente con un File Mapping Object ;) di conseguenza non viene registrata dal sistema operativo.

inoltre ho applicato numerose altre tecniche per proteggerla dai crackers: anti disassemblaggio, anti monitoraggio delle API, e un po' di altre cose.

se ti interessa dimmelo che posto il codice (che attualmente però ha dei problemi che sto cercando di risolvere).

ciao


grazie della proposta,anch'io sto facendo una cosa del genere,ma devo farlo per la tesi di laurea,non posso farmelo fare da altri,sei molto gentile cmq ;)

beh per il fatto del LPDWORD,l'ho aggiunto,ma nisba,non era quella la causa,anche perchè quel codice l'ho preso tale e quale ad una guida trovata su codeguru.com,scritta da Robert Kuster e intitolata "three ways for injecting your code to other processes"...sarebbe quindi stato sbagliato il codice scritto nella guida,e ne dubito...

comunque vorrei che qualcuno provasse ad eseguirlo,magari è il mio kernel32.dll che ha casini,infatti avevo già un psapi.dll buggato,ed era quello incluso nell'installazione di windows xp,poi infatti l'ho cambiato con uno aggiornato e funzionava

anche il kernel32.dll che ho è quello "originale",magari è buggato e mi tocca cambiarlo,chi lo sa...provate a compilare ed eseguire il codice e ditemi l'esito

ciauz

[71104]

altri errori non ne vedo, quindi probabilmente il problema si trova nella DllMain nel codice che hai messo in risposta a DLL_PROCESS_ATTACH. Comunque ora provo ad eseguirlo da me.

[71104]

da me funziona (provato con ws2_32.dll caricata in notepad.exe). l'errore è sicuramente nella tua dll (impossibile che kernel32.dll contenga errori così evidenti: un conto è psapi.dll, un conto è kernel32.dll...).

[GordonFreeman]

da me funziona (provato con ws2_32.dll caricata in notepad.exe). l'errore è sicuramente nella tua dll (impossibile che kernel32.dll contenga errori così evidenti: un conto è psapi.dll, un conto è kernel32.dll...).


ho risolto,è tutto ok,non era kernel32 buggato

ciao e grazie!

[71104]

ho risolto,è tutto ok,non era kernel32 buggato

ciao e grazie! per curiosità, da cosa dipendeva?

[GordonFreeman]

per curiosità, da cosa dipendeva?

allora,io avevo hookato NtCreateThread() in ntdll.dll sovrascrivendo i primi suoi byte con un salto in una mia funzione di hook,per fare API hooking

l'errore era appunto in questa funzione di hooking,e invece il codice che ho postato qui è corretto

in realtà l'API hooking lo dovrei fare solo sui processi remoti,ma invece me lo sono fatto anche "da solo",cioè al mio processo,e quindi quando chiamavo CreateRemoteThread() mi hookavo da solo eseguendo la funzione di hooking di NtCreateThread() [chiamata da CreateRemoteThread()],però poi riconoscendo che il processo corrente è quello che deve monitorare,non uno di quelli monitorati

[71104]

ma il codice a cui salta NtCreateThread a che Privilege Level viene eseguito? questo non c'entra nulla col tuo problema, era per interesse mio: volevo sapere a che Privilege Level viene chiamata NtCreateThread dal subsystem Win32.

[GordonFreeman]

ma il codice a cui salta NtCreateThread a che Privilege Level viene eseguito? questo non c'entra nulla col tuo problema, era per interesse mio: volevo sapere a che Privilege Level viene chiamata NtCreateThread dal subsystem Win32.

il privilege level della mia funzione di hook è 3,cioè user mode

poi sono sicuro che kernel32.dll,user32.dll e tutte le dll forchè ntdll siano in user mode,perchè infatti non tutte la applicazioni le hanno mappate nel loro spazio di indirizzamento,vedi ad esempio lsaas.exe,smss.exe e altre applicazioni "native",esse hanno solo ntdll caricato...se kernel32 fosse in ring0 lo avrebbero tutti i processi,non credi?

poi mi sembra che anche tutte le funzioni di ntdll girino in user mode,e poi facciano un interrupt per entrare in ring0 e chiamare servizi del kernel,perchè altrimenti il mio programma sarebbe andato in crash e con esso tutti i processi monitorati,se vuoi te lo spiego perchè

[71104]

il privilege level della mia funzione di hook è 3,cioè user mode ok, grazie.

poi sono sicuro che kernel32.dll,user32.dll e tutte le dll forchè ntdll siano in user mode,perchè infatti non tutte la applicazioni le hanno mappate nel loro spazio di indirizzamento,vedi ad esempio lsaas.exe,smss.exe e altre applicazioni "native",esse hanno solo ntdll caricato...se kernel32 fosse in ring0 lo avrebbero tutti i processi,non credi? perché mai? Windows è implementato così, ma non era mica obbligatorio... e comunque guarda che kernel32.dll *sta* in tutti i processi, controlla bene... e ntdll.dll pure.

poi mi sembra che anche tutte le funzioni di ntdll girino in user mode,e poi facciano un interrupt per entrare in ring0 e chiamare servizi del kernel, non è detto gli entry point ZwXxx (o NtXxx, che sono la stessa cosa) li puoi chiamare in entrambi i ring: non fanno controlli sul CPL; non lo so di preciso ma ipotizzo che l'int 2Eh punti a un task gate (Windows NT è parzialmente microkernel).

perchè altrimenti il mio programma sarebbe andato in crash e con esso tutti i processi monitorati non è detto: che tipo di JMP hai usato? se il JMP è near non hai problemi perché non può essere interprivilege.