[c++] key logger

[fero86]

ciao, scusa se mi intrometto...

Originariamente inviato da -fidel-

Non ho capito una cosa: potenzialmente tutti gli hook possono risiedere in un eseguibile invece che in una DLL, ma non potrebbe poi essere un hook globale, bensì solo un hook "thread specific".

ciò che dici vale per tutti gli hook tranne che per quelli Low Level (c'è una dicitura apposta su MSDN, guarda ad esempio la pagina di LowLevelKeyboardProc ).

Quindi stai dicendo che un qualunque hook di tastiera non globale funziona lo stesso? Oppure che un Low Level hook funziona lo stesso anche se non è globale?

la seconda

EDIT: non avevo visto la spiegazione di cionci

[-fidel-]

Originariamente inviato da cionci

http://www.codeproject.com/samples/F...select=1362970
L'ho modificato un po' e funziona alla perfezione per loggare tutti i tasti

Ottimo! Non è che posteresti i sorgenti? Ho dimenticato il login a Code Project e non mi va di reiscrivermi
Comunque non capisco una cosa: nella descrizione del programma, si vede la seguente riga di codice:

TheKeyHook = SetWindowsHookEx(WH_KEYBOARD_LL, LowLevelKeyboardProc, ppI,0);

che sembra cozzare con MSDN:
(dalla documentazione per
HHOOK SetWindowsHookEx(
int idHook,
HOOKPROC lpfn,
HINSTANCE hMod,
DWORD dwThreadId
);

lpfn
[in] Pointer to the hook procedure. If the dwThreadId parameter is zero or specifies the identifier of a thread created by a different process, the lpfn parameter must point to a hook procedure in a DLL. Otherwise, lpfn can point to a hook procedure in the code associated with the current process.
hMod
[in] Handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.
dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

[-fidel-]

@ mamo:

Io ho disponibile, come dicevo qualche post fa, un programma che feci hai tempi dell'università, che installa un hook per tastiera globale non low level (usando quindi una DLL), totalmente commentato (era un esercizio settimanale )
Se vuoi posto il progetto per Visual Studio. Da quel progetto penso che in pochi minuti implementi un keylogger.

[mamo139]

Originariamente inviato da -fidel-

@ mamo:

Io ho disponibile, come dicevo qualche post fa, un programma che feci hai tempi dell'università, che installa un hook per tastiera globale non low level (usando quindi una DLL), totalmente commentato (era un esercizio settimanale )
Se vuoi posto il progetto per Visual Studio. Da quel progetto penso che in pochi minuti implementi un keylogger.

si mi farebbe molto piacere... grazie!

[cionci]

Ecco qui, ho modificato l'esempio sopra molto in fretta...

[-fidel-]

Ecco il programma di cui parlavo prima: è soprattutto un buon esempio su come caricare una DLL in un processo senza usare lo stub .lib per compilare, oltre a mostrare l'uso di un hook globale in una DLL.

NOTA: il progetto è per Visual Studio 6: se hai Visual Studio 2003, ti basta rispondere "Sì" alla domanda di conversione progetto, una volta caricato vai nel Solution Explorer (il pannello sulla destra di VS 2003), click col tasto destro sulla cartella KbdHook e selezionare "Set as StartUp Project" (il nome della cartella diventa in grassetto).

EDIT: Nessuna risposta al mio post #22 ?

EDIT 2: Ah, questo programma NON fa uso delle librerie MFC, bensì è scritto in modo classico (Win32 API programming), quindi in C plain ed implementando la coda dei messaggi, mentre il programma postato da cionci usa le MFC.
Tra l'altro, quel programma non compila, mancano i files "ImageLoader.cpp" e "ImageLoader.h"! L'ho lanciando togliendo i riferimenti a quei files, ma poi il programma non funziona correttamente... Cionci, non è che puoi ripostarlo?

[71104]

Originariamente inviato da -fidel-

EDIT: Nessuna risposta al mio post #22 ?

si tratta di un'incoerenza dovuta a motivi di natura probabilmente cronologica; non è l'unica che abbia incontrato nella mia esperienza.

ciò che hai riportato di MSDN vale per tutti gli hook tranne quelli Low Level, che sono stati aggiunti successivamente e sono implementati in maniera leggermente diversa.

[-fidel-]

Originariamente inviato da 71104

si tratta di un'incoerenza dovuta a motivi di natura probabilmente cronologica; non è l'unica che abbia incontrato nella mia esperienza.

ciò che hai riportato di MSDN vale per tutti gli hook tranne quelli Low Level, che sono stati aggiunti successivamente e sono implementati in maniera leggermente diversa.

Sì, la documentazione è incoerente come dici: oltre ai low level hooks, anche con gli hook "normali" la documentazione è discorde. Infatti, nel programma che ho postato (fatto circa 3 anni fa), chiamavo la SetWindowsHookEx (all'interno della DLL) in questo modo:

hKeyboardHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)KeyboardHookProc, NULL, 0);

Il programma, compilato con VS 6, funzionava benissimo. Prima di postarlo, l'ho compilato e provato con VS .NET e, sorpresa, l'hook non veniva creato (la funzione restituiva NULL...). Ho dovuto modificare la chiamata in questo modo:

hKeyboardHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)KeyboardHookProc, hDllInstance, 0);
/* hDllInstance è l'handle alla DLL stessa (simile a "this" in Java) */

Quindi ho dovuto comunque specificare l'handle del modulo contenente il codice, a differenza d quanto specificato in MSDN. Ora e tutto chiaro

EDIT: Più che il compilatore usato, dal momento che il programma compila sia con VS 6 che con VS .NET, è proprio Windows che è cambiato: il programma, con la prima chiamata SetWindowsHookEx, settava tranquillamente l'hook con Win XP SP1, mentre da quando ho installato il SP2, l'hook viene installato solo se viene specificato anche l'handle alla DLL (come nel secondo stralcio di codice postato).

[cionci]

Originariamente inviato da -fidel-

L'ho lanciando togliendo i riferimenti a quei files, ma poi il programma non funziona correttamente... Cionci, non è che puoi ripostarlo?

A me funziona...ho tolto l'include mancante e mi va alla perfezione (l'ho aperto dal file .vcproj

[mamo139]

Originariamente inviato da -fidel-

Ecco il programma di cui parlavo prima: è soprattutto un buon esempio su come caricare una DLL in un processo senza usare lo stub .lib per compilare, oltre a mostrare l'uso di un hook globale in una DLL.

ok si è compilato alla perfezione... io clicco su KbdHook.exe e mi dice:
esecuzione in corso ecc...
ma detta in soldoni... dove le vedo le lettere che premo ??

[-fidel-]

Originariamente inviato da mamo139

ok si è compilato alla perfezione... io clicco su KbdHook.exe e mi dice:
esecuzione in corso ecc...
ma detta in soldoni... dove le vedo le lettere che premo ??

Avvia il programma (non è importante che sia in primo piamo), poi prova a premere il tasto F10, e dimmi cosa succede.
Come fa il programma ad "accorgersi" che è stato premuto proprio quel tasto?
Semplice: tutti gli eventi della tastiera passano per la funzione KeyboardHookProc all'interno della DLL (il file KbdHookDll.cpp). Quella funzione è la funzione associata all'hook: ogni volta che l'hook "cattura" la pressione di un qualunque tasto della tastiera, chiama quella funzione.
All'interno della funzione, puoi sapere quale tasto è stato premuto tramite i parametri "wParam" e "lParam": nel mio programma controllo che il tasto premuto corrisponde ad F10, ed in caso affermativo visualizza una finestra di dialogo, tu puoi farci ciò che vuoi (ad esempio "codificare" il carattere, cioè sapere tramite i due parametri il tasto premuto, e scriverlo su un file di testo).
Ti rimando alla documentazione su MSDN della funzione KeyboardHookProc (la trovi facilmente seguendo la documentazione della funzione SetWindowsHookEx) per conoscere COME interpretare i parametri "wParam" e "lParam" per sapere il tasto premuto.
Ah, il mio programma visualizza una finestrella mentre è in esecuzione, essendo un esempio, così da poterlo chiudere facilmente: tu ovviamente, volendo fare un keylogger, elimini qualunque output a video, e il processo lo chiudi con il Task Manager. O ancora meglio lo rendi un servizio...

Buon divertimento

NOTA: Il codice è ampiamente commentato, quindi non credo avrai problemi, per la descrizione completa delle funzioni (e per comprenderle pienamente) rifatti alla documentazione ufficiale MSDN.

[71104]

Originariamente inviato da -fidel-

O ancora meglio lo rendi un servizio...

il Task Manager di NT comunque visualizza anche i servizi (su XP sono praticamente quasi tutti quelli che girano sotto l'account SYSTEM).

[-fidel-]

Originariamente inviato da 71104

il Task Manager di NT comunque visualizza anche i servizi (su XP sono praticamente quasi tutti quelli che girano sotto l'account SYSTEM).

Sì, ma lo vedi nella lista dei processi, e non in quello delle applicazioni in esecuzione. Già questo può essere sufficiente in molti casi (come tu stesso facevi notare qualche post fa)

[mamo139]

grazie mille fidel... spiegazione perfetta!!!

e come si fa a renderlo un servizo??
sarebbe utile anche perche se non dico male i programmi eseguiti come SYSTEM hanno "poteri" da admin giusto??

[-fidel-]

Originariamente inviato da mamo139

grazie mille fidel... spiegazione perfetta!!!

e come si fa a renderlo un servizo??
sarebbe utile anche perche se non dico male i programmi eseguiti come SYSTEM hanno "poteri" da admin giusto??

Prego
Per installare un nuovo servizio in modo semplice, ti consiglio questa utility:

http://p-nand-q.com/e/pserv.html

è un file .cpl: doppio click ed aggiunge una voce nel Pannello di Controllo di Windows: usala per aggiungere e rimuovere i servizi, occhio però a non fare danni (tipo rimuovere servizi vitali per Windows ).
Per aggiungere un nuovo servizio, ti basta andare nel menu "Object" e scegliere "Install", inserisci i dettagli richiesti ed è fatta.
Se lo vuoi fare via codice, con un programma ad hoc che, eseguito con privilegi di amministratore (ossia l'account di default di Win XP.......), ti permette di aggiungere un servizio alla lista dei servizi la cosa è un po' più complessa.

NB: Sì, i servizi girano in account SYSTEM se non erro.

[mamo139]

installato...

così per curiosità: non c'è un modo per inserirli ad esempio attraverso il registro o cmq in un modo manuale o sarebbe troppo complicato??

[71104]

Originariamente inviato da -fidel-

Sì, ma lo vedi nella lista dei processi, e non in quello delle applicazioni in esecuzione.

capirai, allora è sufficiente non creare nessuna finestra...

[71104]

Originariamente inviato da mamo139

installato...

così per curiosità: non c'è un modo per inserirli ad esempio attraverso il registro o cmq in un modo manuale o sarebbe troppo complicato??

su Windows esistono una svaria di modi per ottenere che un modulo sia caricato automaticamente all'avvio; poi naturalmente dipende anche da che tipo di caricamento si vuole ottenere (ad ogni creazione di explorer.exe, ad ogni logon, all'avvio del sistema, eccetera eccetera).

il miglior* sistema che io conosca è quello di creare una shell extension, ma nota bene che se il target dei tuoi misfatti ( ) è un autentico esemplare di utonto, e come tale lavora normalmente con Administrator, allora è di gran lunga preferibile l'idea del driver che ho descritto qualche post fa...

* migliore nel senso che più si adatta a questo genere di malefatte
ma naturalmente se volessimo semplicemente creare un programma che si avvia automaticamente senza doversi nascondere allora sarebbe chiaramente meglio installare la voce in Esecuzione Automatica o il valore nella chiave di registro Run.

[-fidel-]

Originariamente inviato da 71104

capirai, allora è sufficiente non creare nessuna finestra...

Certo, ma se non erro (sono su linux nel 99,9% del tempo e non posso verificare ora) i processi avviati come servizi vengono etichettati diversamente dal Task Manager, rendendoli meno evidenti ad un utente non molto esperto.

[71104]

Originariamente inviato da -fidel-

Certo, ma se non erro (sono su linux nel 99,9% del tempo e non posso verificare ora) i processi avviati come servizi vengono etichettati diversamente dal Task Manager, rendendoli meno evidenti ad un utente non molto esperto.

stanno là e basta; hanno solo la particolare caratteristica di girare sotto l'account SYSTEM...