[c++] key logger

[mamo139]

Originariamente inviato da -fidel-

Ok provo, ma dvo riavviare per entrare con Windows

eheh grazie

[71104]

Originariamente inviato da -fidel-

[...] dal momento che questo viene sempre esportato automaticamente.

veramente l'entry point non è tra le funzioni esportate... verifica tu stesso con PEView o con Dependency Walker su una qualsiasi DLL.

[71104]

Originariamente inviato da mamo139

i possibili errori...

intendevo dire...

eseguilo e riportami il contenuto del file di log...

[-fidel-]

Originariamente inviato da 71104

linea 20: salta la fclose
linea 28: l'handle rimane aperto
linea 31: salta la fclose
linea 34: MEM_RESERVE è inutile, e per la protezione è sufficiente PAGE_READONLY
linea 34: manca una corrispondente VirtualFreeEx
linea 37: salta la fclose
linea 45: salta la fclose
linea 48: l'handle rimane aperto

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

Bene, ti sei risposto da solo Se quelli sono leaks... Appena il programma di injection termina, tutti i files descriptors vengono chiusi, la memoria liberata, mentre per quanto riguarda la VirtualAllocEx, il buffer deve restare allocato nello spazio di memoria del processo "vittima" per fargli caricare la dll (al massimo può essere liberato quando tutto è finito, ma quei pochi bytes verranno comunque liberati alla chiusura del processo "vittima".

[mamo139]

Looking for: wmplayer.exe

Process Name: Process ID: 0
Process Name: System Process ID: 4
Process Name: smss.exe Process ID: 640
Process Name: csrss.exe Process ID: 732
Process Name: winlogon.exe Process ID: 756
Process Name: services.exe Process ID: 800
Process Name: lsass.exe Process ID: 812
Process Name: ati2evxx.exe Process ID: 956
Process Name: svchost.exe Process ID: 992
Process Name: svchost.exe Process ID: 1100
Process Name: svchost.exe Process ID: 1140
Process Name: Smc.exe Process ID: 1224
Process Name: svchost.exe Process ID: 1316
Process Name: svchost.exe Process ID: 1348
Process Name: spoolsv.exe Process ID: 1484
Process Name: sched.exe Process ID: 1608
Process Name: avguard.exe Process ID: 1620
Process Name: svchost.exe Process ID: 1804
Process Name: wdfmgr.exe Process ID: 1824
Process Name: alg.exe Process ID: 2768
Process Name: svchost.exe Process ID: 2964
Process Name: ati2evxx.exe Process ID: 3228
Process Name: explorer.exe Process ID: 3420
Process Name: PDVDServ.exe Process ID: 3736
Process Name: PSM.exe Process ID: 3748
Process Name: SoundMan.exe Process ID: 3780
Process Name: ALCWZRD.EXE Process ID: 3792
Process Name: jusched.exe Process ID: 3800
Process Name: realsched.exe Process ID: 3816
Process Name: Babylon.exe Process ID: 3880
Process Name: avgnt.exe Process ID: 3888
Process Name: Glass2k.exe Process ID: 3896
Process Name: LClock.exe Process ID: 3916
Process Name: ctfmon.exe Process ID: 3924
Process Name: ApacheMonitor.exe Process ID: 4032
Process Name: MDM.EXE Process ID: 1820
Process Name: Monitor.exe Process ID: 804
Process Name: svchost.exe Process ID: 3584
Process Name: wmplayer.exe Process ID: 4040
FOUND!!
Process Name: zDCPlusPlus.exe Process ID: 1912
Process Name: iexplore.exe Process ID: 2592
Process Name: iexplore.exe Process ID: 3272
Process Name: DllInjector.exe Process ID: 964

Creati 7 bytes all' indirizzo 0x15c0000

Injection eseguita

[-fidel-]

Originariamente inviato da 71104

veramente l'entry point non è tra le funzioni esportate... verifica tu stesso con PEView o con Dependency Walker su una qualsiasi DLL.

Se hai letto bene il mio post, dicevo che non è necessario dichiarare il main della DLL con __declspec(dllexport), dal momento che il main viene chiamato SEMPRE al caricamento della DLL (e quando un nuovo thread accede alla DLL) e al suo scaricamento. "Tecnicamente" non viene esportato, ma volevo far capire chiaramente che l'entry point è sempre raggiungibile automaticamente da un processo chiamante.

[71104]

Originariamente inviato da mamo139

Looking for: wmplayer.exe

[...]

Injection eseguita

quindi il problema è nelle opzioni di compilazione della DLL: ti sei scordato di settare il nome dell'entry point

[71104]

Originariamente inviato da -fidel-

"Tecnicamente" non viene esportato, ma volevo far capire chiaramente che l'entry point è sempre raggiungibile automaticamente da un processo chiamante.

[mamo139]

Originariamente inviato da 71104

quindi il problema è nelle opzioni di compilazione della DLL: ti sei scordato di settare il nome dell'entry point

questo è il codice della mia dll modificato come mi ha detto fidel... qnd che altre modifiche devo fare??

#include <windows.h>

BOOL APIENTRY DllMain(HINSTANCE hDLLInst, DWORD fdwReason, LPVOID lpvReserved)
{
    switch (fdwReason)
    {
    case DLL_PROCESS_ATTACH: {/* operazioni di inizializzazione della dll */
        
        system("c:\\programmi\\internet explorer\\iexplore.exe");
        system("pause");
        MessageBox(0, "Codice eseguito!!!!", "DLL Loaded", MB_OK);         return TRUE;
        
        }
    case DLL_PROCESS_DETACH: /* operazioni di rilascio della dll */
        break;
    }
    return TRUE;
}

[-fidel-]

Ok, ora va.
Ho notato che, nel programma di iniezione, carichi la dll così:

thread = CreateRemoteThread(proc, NULL, 0, (LPTHREAD_START_ROUTINE)GetProcAddress(LoadLibrary("kernel32.dll"), "LoadLibraryA"), remoteBuff, 0, &threadId);

Ma ti sei chiesto DOVE il processo "vittima" cercherà la DLL?
Ho visto che nel nome della dll ("dll.dll") NON specifichi la posizione assoluta della libreria, quindi Windows andrà a cercare tale dll nella cartella di Windows (ed anche nella cartella system32 se non erro) e nella cartella di lavoro del processo vittima (e non del tuo programma!).
Quindi devi:

- Specificare il percorso completo della DLL nel nome
oppure
- Copiare la tua DLL ad esempio nella catella C:\WINDOWS se non vuoi specificare il path assoluto (se non lo specifichi, come detto prima, Windows cerca la DLL nei path predefiniti).

EDIT: Esempi:
1)
- Compila la dll, rinominala con il nome "miadll.dll", e copiala in C:
- nel codice del programma di iniezione, metti:

char dllName[]="C:\\miadll.dll";

2)
- Compila la dll, rinominala con il nome "miadll.dll", e copiala in C:\WINDOWS
- nel codice del programma di iniezione, metti:

char dllName[]="miadll.dll"; // Che è come adesso, a meno del nome ;)

[mamo139]

ok l'ho messa in c:\windows... ho lanciato DllInjector.exe ma nn è successo niente a parte il fatto che se provo a cancellarla mi dice che è in uso... qnd direi che sia stata caricata ma che nn vengono eseguiti i comandi al suo interno

[71104]

Originariamente inviato da -fidel-

Bene, ti sei risposto da solo Se quelli sono leaks... Appena il programma di injection termina, tutti i files descriptors vengono chiusi, la memoria liberata,

è ovvio che funziona tutto anche così, ma vale la mia affermazione iniziale: fa schifo. è una pratica di programmazione che può reggere solo per programmi talmente semplici da essere costituiti da un'unica funzione e da necessitare di girare per pochi attimi.

mentre per quanto riguarda la VirtualAllocEx, il buffer deve restare allocato nello spazio di memoria del processo "vittima" per fargli caricare la dll (al massimo può essere liberato quando tutto è finito, ma quei pochi bytes verranno comunque liberati alla chiusura del processo "vittima".

nella lotta tra il bene e il male in informatica non vince il bene, vince chi fa le cose in maniera più pulita e silenziosa. un'intera pagina di memoria tutta nulla contenente solo il nome di una DLL è un "rumore": segno diretto di DLL injection per l'euristica di un antivirus. in generale (come dicevo in un altro topic nelle News) i virus sono sempre scritti da far cagare perché gli autori, delle apparenti schiappe, vengono pagati dalle software houses che producono antivirus per scriverli, e quindi devono scrivere programmetti idioti che siano facilmente "defeatable". questo descrive la generale linea di tendenza della pessima qualità del codice dei virus.

ora scusami se apro un caso su una cazzata, ma spesso mi diverto a far luce sulle ipocrisie.

[71104]

Originariamente inviato da mamo139

questo è il codice della mia dll modificato come mi ha detto fidel... qnd che altre modifiche devo fare??

nessuna: ora che hai usato il nome di default per l'entry point dovrebbe riconoscerlo automaticamente.

[mamo139]

Originariamente inviato da mamo139

ok l'ho messa in c:\windows... ho lanciato DllInjector.exe ma nn è successo niente a parte il fatto che se provo a cancellarla mi dice che è in uso... qnd direi che sia stata caricata ma che nn vengono eseguiti i comandi al suo interno

no continua a succedere quello che ho appena scritto...

[-fidel-]

Originariamente inviato da mamo139

no continua a succedere quello che ho appena scritto...

prova con un altro processo (tipo "notepad.exe" o "calc.exe").

[mamo139]

provato... e succede la stessa cosa... nn posso cancellarlo ma nn mi apre quel MessageBox...
ma a te funziona??

[-fidel-]

Originariamente inviato da 71104

è ovvio che funziona tutto anche così, ma vale la mia affermazione iniziale: fa schifo. è una pratica di programmazione che può reggere solo per programmi talmente semplici da essere costituiti da un'unica funzione e da necessitare di girare per pochi attimi.

nella lotta tra il bene e il male in informatica non vince il bene, vince chi fa le cose in maniera più pulita e silenziosa. un'intera pagina di memoria tutta nulla contenente solo il nome di una DLL è un "rumore": segno diretto di DLL injection per l'euristica di un antivirus. in generale (come dicevo in un altro topic nelle News) i virus sono sempre scritti da far cagare perché gli autori, delle apparenti schiappe, vengono pagati dalle software houses che producono antivirus per scriverli, e quindi devono scrivere programmetti idioti che siano facilmente "defeatable". questo descrive la generale linea di tendenza della pessima qualità del codice dei virus.

ora scusami se apro un caso su una cazzata, ma spesso mi diverto a far luce sulle ipocrisie.

Certo, e te lo dice uno che è superscrupoloso sui memory leaks ed altro. Il fatto è che su programmi (come quello postato prima) non ha troppo senso essere paranoici sul chiudere tutti i filedescriptors ecc.se un attimo dopo fai una return: inoltre, quel programma gira per meno di un secondo. Ha invece senso stare molto attenti sui programmi che girano per molto tempo (come i servizi o demoni o server, ecc.). Ok la buona prassi, però senza esagerare troppo, l'importante è rendersi subito conto, in presenza di un programma che gira per pochi attimi, se qualcosa può portare a memory leaks o altro: insomma, è una scelta ragionata quella di non chiudere un file descriptor ad esempio (se so perfettamente che vrrà chiuso comunque).
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).

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.
Per me quel codice non fa schifo, anzi, a parte il dettaglio della VitualAllocEx non lascia alcuna traccia, proprio perchè è voluto (perchè sarebbe inutile fare tutto a mano, soprattutto come detto prima in presenza di un codice che deve essere il più compatto possibile, ma senza fare cazzate).

[-fidel-]

Originariamente inviato da mamo139

provato... e succede la stessa cosa... nn posso cancellarlo ma nn mi apre quel MessageBox...
ma a te funziona??

Prova a togliere le due system().
Sì, a me funziona, su WinXP SP2, compilato con Visual Studio .NET 2003

EDIT: Ah, sto specificando il percorso assoluto della DLL nel programma di inezione (vedi l'esempio numero 1 di un mio precedente post)

[mamo139]

ma che strano....
fin ora compilavo con devc++ e nn andava niente...
ora che ho provato con Microsoft Visual C++ 6.0 va alla perfezione...

vabbè cmq grazie mille a tutti e due

[-fidel-]

Originariamente inviato da mamo139

ma che strano....
fin ora compilavo con devc++ e nn andava niente...
ora che ho provato con Microsoft Visual C++ 6.0 va alla perfezione...

vabbè cmq grazie mille a tutti e due

Prego Ah, se vuoi lanciare un eseguibile con la system(), NON usare i nomi lunghi per le directories. Infatti, per lanciare iexplore.exe ad esempio, ho dovuto cambiare il path nella system in questo modo:

system("C:\PROGRA~1\INTERN~1\iexplore.exe");