[c] consiglio dll

[KrYeD]

ho una dll che serve per implementare un hook che teoricamente nn si dovrebbe vedere

per eseguirla mi conviene utilizzare un normale programma che nn crei nessuna finestra ma facilmente killabile da un utente + "attento"
oppure usare qualche tecnica in particolare?

ho letto di queste dll injection ma gli antivirus fanno delle storie, ho letto anche di questi SHATTER ATTACK ma sn un'attimino complessi...

[KrYeD]

[71104]

un modo semplice di "lanciare" una DLL è usare regsvr32.exe

[ilsensine]

Originariamente inviato da 71104

un modo semplice di "lanciare" una DLL è usare regsvr32.exe

Forse intendi...rundll32

[71104]

Originariamente inviato da ilsensine

Forse intendi...rundll32

veramente no, parlavo proprio di regsvr32: è un programma che serve tra l'altro a registrare le shell extensions, cioè quelle DLL che sono dei plugins per la shell grafica di Windows (per esempio possono aggiungere voci nei menu di contesto che appaiono quando si fa clic destro sull'icona di un file; WinRAR lo fa). i motivi percui suggerisco regsvr32 anziché rundll32 sono i seguenti:
1) non conosco molto bene rundll32 ma mi pare (anche dalla descrizione che leggo nel link) che la DLL caricata debba rispettare un'interfaccia ben definita e che non possa chiamare le API
2) non è necessario realizzare una vera e propria shell extension: regsvr32 carica la DLL e ne chiama l'entry point, qualunque cosa contenga. a quel punto è fatta: del tuo codice viene eseguito, e quel codice può anche chiamare delle funzioni API. eseguito quel codice, della shell extension può anche fregarsene e far ritornare FALSE alla DllMain, simulando un errore di caricamento. però intanto il tuo codice è stato eseguito e tramite di esso la tua DLL può essersi iniettata chissà dove.

[KrYeD]

uhm quindi bastare fare un semplice
Regsvr32.exe c:\prova\nomefle.dll

per eseguire una dll senza prg strani che girano?

[71104]

Originariamente inviato da KrYeD

uhm quindi bastare fare un semplice
Regsvr32.exe c:\prova\nomefle.dll

per eseguire una dll senza prg strani che girano?

si però devi avere l'accortezza di ritornare FALSE dalla DllMain, altrimenti regsvr32 continuerà a caricare la tua ipotetica shell extension aspettandosi di trovare nella tua DLL tutta l'interfaccia necessaria. in pratica devi simulare un errore di caricamento.

inoltre io ci metterei per sicurezza anche l'opzione /s:

regsvr32 /s c:\blah\doh.dll

[KrYeD]

uhm si cn quello me lo carica però se metto return false mi si blocca subito... invece se lascio true sembra funzionare ma viene quasi subito rilasciata

[71104]

Originariamente inviato da KrYeD

uhm si cn quello me lo carica però se metto return false mi si blocca subito... invece se lascio true sembra funzionare ma viene quasi subito rilasciata

la tua DLL non possiede l'interfaccia necessaria per essere realmente registrata, quindi devi mettere un return FALSE. il motivo percui smette subito di funzionare dipende dal codice che viene eseguito dalla DllMain prima di ritornare con FALSE. puoi postarlo? casomai prova anche ad incrementare il reference count della tua DLL facendo una LoadLibrary passandogli il nome della tua DLL (in questo modo una sola FreeLibrary non basterà a scaricarla, ne serviranno due e suppongo che regsvr32 ne faccia una sola), ma non credo che servirà a molto perché comunque regsvr32 non è un programma fatto per restare in esecuzione: registra ed esce, sia che abbia avuto successo sia che non ne abbia avuto. hai detto di aver utilizzato un Windows Hook: ora controllo se i Windows Hooks vengono eliminati automaticamente quando la DLL viene scaricata dal processo originario.

[KrYeD]

per ora stavo giochicchiando con la dll postata da fidel nel 3d del keylogger... nn essendo capace di rifarla provo a cambiarci qualcosina per migliorarlo e capire esattamente cosa fa... ho provato anche a cercare un po' su internet ma nn trovo niente di interessante...
per ora sto usando un semplice LoadLibrary e se metto la visualizzazione di un messaggio prima del rilascio della dll questa funziona correttamente, appena premo ok avviene il rilascio e smette di funzionare.. molto probabilmente è + complessa di quello che pensavo e nn riesco a farla partire...

[71104]

non so se l'hook viene cancellato automaticamente alla terminazione del processo originario ma in teoria è una cosa possibile, quindi tanto vale premunirsi contro tale eventualità. l'idea che mi è venuta in mente è questa: ogni volta che nella DllMain ricevi una notifica DLL_PROCESS_ATTACH chiami LoadLibrary col nome della tua DLL, incrementandone così il reference count. tieni però presente che l'hook verrebbe disinstallato... potresti installarne uno nuovo, ma cercherei una soluzione più semplice. domanda: l'hook ti serve per davvero o è solo un modo per far sì che User32 ti caricasse dappertutto?

[71104]

Originariamente inviato da KrYeD

per ora stavo giochicchiando con la dll postata da fidel nel 3d del keylogger... nn essendo capace di rifarla provo a cambiarci qualcosina per migliorarlo e capire esattamente cosa fa... ho provato anche a cercare un po' su internet ma nn trovo niente di interessante...
per ora sto usando un semplice LoadLibrary e se metto la visualizzazione di un messaggio prima del rilascio della dll questa funziona correttamente, appena premo ok avviene il rilascio e smette di funzionare.. molto probabilmente è + complessa di quello che pensavo e nn riesco a farla partire...

il problema è che se usi rundll32 come proponeva ilsensine poi il processo rundll32.exe resta visibile nel Task Manager e può essere terminato. per un utonto è un processo "fidato", ma un utente un po' più accorto potrebbe semplicemente informarsi su cosa faccia realmente (esegue gli applet del pannello di controllo) e vedendo che resta in esecuzione pure col pannello di controllo chiuso si insospettirebbe e lo terminerebbe, quindi sarebbe meglio se la DLL installasse l'hook solo quando è stata caricata in qualche processo di "lungo termine", come explorer.exe. ho partecipato anche io al thread del keylogger che dici (se ho capito qual è), e ricordo che la DLL di fidel non prevedeva l'eventualità che l'hook dovesse essere installato da un processo diverso da quello che effettua il primo caricamento.

[KrYeD]

esatto è lo stesso 3d dove avevi postato anche te... avevo pensato a fare un injection dll ma ormai gli antivirus fanno storie
così avevo inizialmente provato a vedere se funzionava caricandola normalmente ma appena si scarica puff scompare anche l'hook

[tomminno]

Originariamente inviato da KrYeD

esatto è lo stesso 3d dove avevi postato anche te... avevo pensato a fare un injection dll ma ormai gli antivirus fanno storie
così avevo inizialmente provato a vedere se funzionava caricandola normalmente ma appena si scarica puff scompare anche l'hook

Io darei un'occhiata a questa:
http://www.codeproject.com/system/Paladin.asp
AVG 7.5 e Symantec Corporate non battono ciglio, riesci ad agganciare un hook a qualunque API Win32. L'unico problema che ho riscontrato è che su alcuni computer recenti provando a nascondersi al task manger questo viene terminato, sicuramente non è a causa dell'antivirus forse è il no execute (NX) che fa killare il processo, non ho ancora capito però se è questa la causa.

[71104]

Originariamente inviato da tomminno

Io darei un'occhiata a questa:
http://www.codeproject.com/system/Paladin.asp
AVG 7.5 e Symantec Corporate non battono ciglio, riesci ad agganciare un hook a qualunque API Win32. L'unico problema che ho riscontrato è che su alcuni computer recenti provando a nascondersi al task manger questo viene terminato, sicuramente non è a causa dell'antivirus forse è il no execute (NX) che fa killare il processo, non ho ancora capito però se è questa la causa.

non se ne fa molto: da quanto ho capito vuole fare un keylogger, usando l'API Hooking dovrebbe hookare GetMessage; in linea di principio è una pessima strategia.

@KrYeD: la DLL injection presuppone che tu abbia già del tuo codice in esecuzione; se puoi fare questa assunzione allora possiamo procedere con una tecnica di DLL injection alternativa di mia invenzione () che forse non darà nell'occhio agli antivirus, o in alternativa si può provare qualche magheggio per far sì che gli antivirus non si accorgano di nulla. nella seconda ipotesi bisogna capire qual è di preciso il punto del codice che fa insospettire l'antivirus, ma dovrai procurarti qualche antivirus tra i più diffusi o tra quelli di cui più probabilmente dispone la tua vittima.

intanto chiariamo la situazione: tu puoi assumere di eseguire codice prima di aver iniettato la tua DLL ed avviato il keylogger?

[KrYeD]

Originariamente inviato da 71104

non se ne fa molto: da quanto ho capito vuole fare un keylogger, usando l'API Hooking dovrebbe hookare GetMessage; in linea di principio è una pessima strategia.

@KrYeD: la DLL injection presuppone che tu abbia già del tuo codice in esecuzione; se puoi fare questa assunzione allora possiamo procedere con una tecnica di DLL injection alternativa di mia invenzione () che forse non darà nell'occhio agli antivirus, o in alternativa si può provare qualche magheggio per far sì che gli antivirus non si accorgano di nulla. nella seconda ipotesi bisogna capire qual è di preciso il punto del codice che fa insospettire l'antivirus, ma dovrai procurarti qualche antivirus tra i più diffusi o tra quelli di cui più probabilmente dispone la tua vittima.

intanto chiariamo la situazione: tu puoi assumere di eseguire codice prima di aver iniettato la tua DLL ed avviato il keylogger?

uhm nel mio uso kav6, nell'altro pc uso norton quindi ne ho un paio da testare


beh si prima di iniettarlo posso eseguire qualcosa... (sempre se ho capito la domanda visto che mi sn appena svegliato )

cmq dici che la dll injection è la miglior soluzione per essere il + stealth possibili (senza complicarci troppo la vita) ?

[71104]

Originariamente inviato da KrYeD

cmq dici che la dll injection è la miglior soluzione per essere il + stealth possibili (senza complicarci troppo la vita) ?

in realtà esistono programmi per enumerare le DLL caricate in un processo, di conseguenza sei comunque visibile, ma non credo che ti interessi nasconderti anche per queste evenienze.

per quanto riguarda la DLL injection, una delle innumerevoli tecniche consiste nel chiamare CreateRemoteThread passandogli come indirizzo dell'entry point l'indirizzo della funzione API LoadLibrary, cosicché il nuovo thread carichi la tua DLL. la prima cosa da fare è enumerare i processi con EnumProcesses e trovare quello che ti interessa. se per esempio quello che ti interessa è explorer.exe allora per ciascun processo enumerato devi ottenerne il base name con GetModuleBaseName e confrontarlo in maniera case insensitive con la stringa "explorer.exe". in questo modo trovi il PID di explorer.exe. trovato quello apri un HANDLE con OpenProcess, che alla fine di tutto chiuderai con CloseHandle.

ora viene l'injection vera e propria. la tecnica che ti spiegherò consiste nel chiamare CreateRemoteThread (che ti servirà a creare un thread nello spazio di indirizzamento del processo di explorer.exe) passandole come entry point la funzione API LoadLibrary, in maniera tale che il thread non farà altro che caricare la tua DLL.

la prima cosa da fare è scrivere nella memoria di explorer.exe il path completo della tua DLL: lo dovrai passare come argomento al nuovo thread (cioè alla LoadLibrary). quindi ricavati il path (questo sai tu come farlo, a seconda di dove prevedi che sarà la DLL), poi alloca un'area di memoria in explorer.exe grossa abbastanza utilizzando la VirtualAllocEx, ed infine scrivici il path con WriteProcessMemory.

fatto questo chiama CreateRemoteThread passandole al quarto parametro esattamente questa cosa:

(LPTHREAD_START_ROUTINE)LoadLibraryA

ma attenzione a Unicode: io ho scritto LoadLibraryA perché ho dato per scontato che tu ti ricavassi il path in formato ANSI, ma se invece usi Unicode allora devi passargli LoadLibraryW.

se il thread viene creato attendi che esso termini passandone l'HANDLE alla WaitForSingleObject (l'HANDLE è quello ritornato dalla CreateRemoteThread), ed in caso analizzane il codice di uscita con la GetExitCodeThread per sapere se la DLL è stata caricata con successo (chiaramente il valore ritornato da GetExitCodeThread sarà esattamente lo stesso ritornato da LoadLibrary). in ogni caso ricordati ti deallocare con VirtualFreeEx la memoria che hai allocato con VirtualAllocEx per scrivere il path della DLL. infine chiudi con CloseHandle l'HANDLE del thread remoto.

prova a buttare del codice e a farlo andare, e se gli antivirus rompono le scatole vedremo di preciso quale chiamata API li fa insospettire e a seconda vedremo la soluzione migliore.

[KrYeD]

uhm ti ringrazio per la bellissima guida, ora sto tentando di metterla in pratica, con un po' (tanti) errori a quanto pare :P

[KrYeD]

per ora ho creato questa cosa sbagliatissima usando solo msdn
ovviamente nn funziona, ma almeno dimmi se mi sto avvicinando a qualcosa oppure sono partito per la tangente

int _tmain(int argc, _TCHAR* argv[])
{
	DWORD proclist[1024], nbit, cProcesses, nsize[50];
int i;
HANDLE handleproc, p;
LPWSTR nomeproc;
LPVOID ind;
EnumProcesses(proclist,sizeof(proclist),&nbit);

    cProcesses = nbit / sizeof(DWORD);

    for ( i = 0; i < cProcesses; i++ )
        if( proclist[i] != 0 )
		{
			handleproc = OpenProcess(PROCESS_VM_WRITE,FALSE,proclist[i]);
            GetModuleBaseName(handleproc,NULL,&nomeproc,nsize);
			if(nomeproc=="calc.exe") //uhm
			{
				p=LoadLibrary("C:\\key.dll");
				ind=VirtualAllocEx(handleproc,NULL,1024,MEM_RESERVE,PAGE_EXECUTE_WRITECOPY);
				WriteProcessMemory(handleproc,ind,...,&p)
			}
		}
	return 0;
}

[71104]

Originariamente inviato da KrYeD

per ora ho creato questa cosa sbagliatissima usando solo msdn
ovviamente nn funziona, ma almeno dimmi se mi sto avvicinando a qualcosa oppure sono partito per la tangente

mannò, continua così che stavi andando benino
qualche correzione:

linea 13: quell'if non serve, puoi anche toglierlo (tanto se becchi il PID 0 ti fallisce la OpenProcess).

linea 15: PROCESS_VM_WRITE non basta, non devi solo scrivere memoria: devi anche allocare il thread, e tra l'altro penso che PROCESS_VM_WRITE da solo non basti neanche ad allocare con VirtualAllocEx la memoria che vuoi scrivere. per ora mettici un brutale PROCESS_ALL_ACCESS, poi casomai si vedrà.

linea 16: nomeproc non è allocato, e tra l'altro l'hai esplicitamente dichiarato come Unicode mentre invece hai usato la versione portabile della funzione GetModuleBaseName (non ha ne' il suffisso A ne' W). scegli se vuoi usare ANSI, Unicode, o se vuoi fare un sorgente portabile tra i due standard: nel primo caso devi dichiarare il buffer come LPSTR e usare esplicitamente GetModuleBaseNameA; nel secondo buffer LPWSTR e funzione GetModuleBaseNameW; nel terzo buffer LPTSTR e funzione GetModuleBaseName. se non hai preferenze è consigliabile fare una versione portabile compilandola però in Unicode definendo la macro UNICODE, macro che Visual C++ 2005 definisce già automaticamente di default (infatti scommetto che stai usando quello, si vede dal tipo di errore che hai fatto ).

sempre linea 16: ma nsize non era un array?

linea 17: fa bene a farti riflettere quella cosa, infatti è sbagliata
devi usare la funzione lstrcmpi, che sarebbe la versione API Win32 della strcasecmp. conviene usare lstrcmpi piuttosto che strcasecmp perché lstrcmpi è portabile ANSI/Unicode (infatti esiste lstrcmpiA e lstrcmpiW).

linea 19: piccolo appunto, stai usando implicitamente LoadLibraryW (versione Unicode) però gli hai passato una stringa ANSI. per scrivere una stringa costante Unicode in C devi usare il prefisso L:

LoadLibraryW(L"C:\\key.dll");

ma piuttosto che fare così ti conviene usare la macro TEXT che ti da la portabilità:

LoadLibrary(TEXT("C:\\key.dll"));

linea 20: MEM_RESERVE non va bene, usa MEM_COMMIT. PAGE_EXECUTE_WRITECOPY neanche va bene: usa PAGE_READWRITE.