dimanche 25 novembre 2007

SetWindowsHookEx() ou le hook 'facile' :).

Bonsoir à tous ,
je profite de ce petit week-end pour vous faire partager ma 'release' de la semaine .
Après mon post sur les hooks , je voulais continuer dans cette voie-ci
et donc m'intérésser à la fonction SetWindowsHookEx().D'après ce que l'on a put me raconter la fonction va hooker elle-même certaines apis au niveau du kernel ,cela permettant donc d'analyser les messages envoyés par les différentes applications.
Le but est donc de pouvoir 'capter' toutes les informations liées à la souris et au clavier dans mon petit post .Comme précédemment , nous allons choisis la technique par dll ,on appelle ça un hook système.Notre technique sera donc la suivante :

-Nous allons coder un programme se chargeant d'appeler les fonctions de notre dll.
-Notre programme va donc appeller ces fonctions , les fonctions de filtres vont donc rentrer en actions.

Pour le code ,j'ai opté pour l'utilisation de variable globale ,permettant de retrouver le handle du hook ou celui du fichier de log ,dans tous le programme par exemple.
Je tiens à préciser aussi que les adresses des fonctions contenus dans les dlls auraient put être retrouvées en chainant plusieurs apis ,seulement j'ai choisis de linker le .a de ma dll pour compiler le programme 'principale'.
La source présente donc une utilisation de la fonction SetWindowsHookEx pour deux types de messages ,à savoir les messages liés à la souris et aux claviers.
Lorsque le pointeur de la souris sera dans le coin inférieur droit ,où dans le coin supérieur gauche le programme enverra un OutputDebugString().
De plus le programme se chargera de logger toutes les touches du clavier ,biensûre .
Et puis je vois déjà tous me pointer du doigt : -"Henn , il ouvre et ferme le fichier à chaque écriture!" et bien oui j'ai choisis d'opérer ainsi car cela me permettait de pouvoir ouvrir le fichier log pendant que le prog tourner par exemple.
Je voulais aussi préciser que ce projet est un petit échec ,je me rend compte que lorsque qu'on 'bourrine' le clavier on aperçoit des inversions de lettres..un problème auquel je n'ai trouvé aucune solution donc si des personnes ont reussis merci de prendre contact avec moi merci.
Donc je vous expose cette petit saloperie de code :
-FuckingKeylogger.
-La dll contenant les hooks.

Un petit screenshot :) :




cya.
PS : si quelqu'un aurait une façon valable pour gérer le problèmes des deads keys aussi...

Quelques liens sympa :
- http://vbman.free.fr/articles/hacking/KEYLOG.htm
- http://tcharles.developpez.com/simul/

samedi 17 novembre 2007

API Hooking - IAT patching

Bonjour à tous ,
Aujourd'hui je vais essayer de vous présenter l'api hooking via l'iat patching.
En effet notre but lors de ce petit billet sera de détourner l'appel d'apis.
J'illustrerais avec un petit exemple de hooking sur le notepad.exe , cependant vous pourriez , après avoir compris le principe , laisser cours à votre imagination afin de creer de multiples attaques.
Cette démonstration de hook sera réalisé dans l'userland (ring3).

Tout d'abord je vais vous exposer ma façon d'opérer :
- Nous allons coder un programme chargé d'injecter notre dll dans le processus cible ( voir billet sur l'injection ).
- Ensuite nous allons coder une dll qui ira modifier directement l'iat du processus cible ( voir billet sur le dump de l'iat ).

Voilà donc les grandes étapes :
- On retrouve le pid de notre processus.
- Nous ouvrons notre processus afin d'avoir un handle sur celui-ci , avec l'api OpenProcess.
- On alloue de la mémoire dans le processus cible , on y écrira le full path de notre dll.
- Nous créons un thread dans le processus sur l'adresse de LoadLibraryA ( exporté par kernel32.dll ) avec comme arguement le path de la dll donc .
- A présent notre dll est loadé par l'application cible.
- Notre dll dès son chargement va aller modifier l'adresse de la fonction à hooker par l'adresse de notre fonction dans l'iat.

L'application à chaque appel de l'api hooké appelera enfaite notre fonction , c'est pour cela qu'elle doit posséder le même prototype que la fonction hooké.
Je tiens aussi à préciser , que la modification de l'iat ne peut se faire qu'après un appel à l'api VirtualProtect.Et ce pour changer l'acces à la zone mémoire , après la modification
nous rétablissons l'accès originel de la zone mémoire.

Voici donc les illustrations :
Tout d'abord l'injecteur : InjecteurDll.
La dll pour hooker le ShellAbout de notepad.exe : HookShellAboutW.dll.
Un petit screenshot pour les plus fainéants :




Puis pour terminé j'ai voulu faire un exemple un peu plus concret mais qui reste très simple.
Imaginons le code d'une petite application permettant de lister les fichiers et dossiers dans le current directory.
Notre but serait de cacher un fichier .
Voici les codes : - HookFindNextFirstFile.dll.
- cible.exe.

Et un petit screnshot :



J'essairais plus tard de coder un petit rootkit userland prenant le contrôle de l'userland par le biais de hook justement.
Sur ce bonne fin de journée , cya.

lundi 12 novembre 2007

Dump Own iat.

Après avoir coder le viewer de pe , je me trouvais plutôt frustré de ne pas avoir bien saisis l'iat , chose résolu je vous file le code permettant de dumper les adresses et noms des fonctions exportées par les dlls.
DumpFuckingIat.

Par contre j'ai pas compris desuite le fonctionnement j'avoue avoir fais pas mal de test et lu plusieurs tutoriaux :) .
Doc pour éclaircir :
Voilà cya.

Process env block.

Cette fois-ci c'est le peb qui attire mon attention , j'ai donc coder un petit programme qui se ballade dans les structs liées au peb afin d'aller dumper le nom des dlls loadées par le programme.
Je signale que je n'ai pas reussi à compilé ce code avec Code::Blocks , je l'ai compilé directement avec gcc ( 3.4.2 ).Je me suis aussi permis de 'troncater' les structs vu que le membre qui m'interessait ce trouver au début de celle-ci .
Processenvblock.


Pour la compréhension du code :
voilà cya.

Unload de dll.

Après avoir coder l'injecteur de dll , je me suis intérogé sur le "Comment décharger une dll d'un processus ?". Pour la technique , rien de compliqué , nous allons creer un remote thread sur FreeLibrary cette fois .La seule petite difficulté (oupa) c'est de trouver le handle de la dll dans le processus cible biensûre , nous y allons donc à grand coup de CreateToolhelp32Snapshot et on voilà.
Unload fucking dll.

Cya.

Injection de code / dll.

Pour ce billet je vais vous présenté la fameuse injection de code et de dll.
Le principe est plutôt simple , en effet nous allons alouer de la mémoire dans le processus cible ou nous allons écrire par exemple notre full path vers notre dll , nous créons ensuite un remote thread sur directement sur le shellcode ou encore sur LoadLibraryA exporté par kernel32.dll. Résultat nous avons notre dll qui va se charger en mémoire , ou l'éxécution direct de notre shellcode.
Je vous présente le code de l'injecteur ainsi que d'une dll d'exemple :
Inject Dll into fucking process.
Dll de démonstration.


Pour ce code vous pourrez trouver de multiples articles expliquant 'pas à pas' la technique.
Je vous recommande comme toujours la msdn pour l'utilisation des apis.
Cya.

Process.

C'est maintenant les processus et leurs 'gestions' qui m'interesse .Je vous fais alors pars d'un petit code que j'ai réalisé dans le but de me familiariser avec ceux-ci , il permet de killer les processus et d'en faire la liste .
Le code est assez simple , je me passerais donc d'explications.

ProcessViewer.

Pour la compréhension du code , je vous conseil vivement la msdn qui est vraiment excellente pour l'utilisation des apis .
Cya.

View fucking pe.

Comme vous le savez peut-être , le portable executable ou PE est un format de fichier utilisé pour les éxécutables windows ou encore les dlls.
Je me suis donc intéréssé à celui-ci , voici un code plutôt simple permettant la lecture de quelques informations le concernant ( ce viewer de pe est loin d'être complet , je pense à l'import table qui n'a pas été exploré dans ce code ).
Je tiens aussi à précisé que dans ce genre de code l'utilisation des casts est très importantes , étant donné que l'on a affaire à "des adresses virtuelles relatives" (RVA) et que nous devons additionner celles-ci à des membres des structures utilisées pour le PE.
ViewFuckingPe.

Je vous file un peu de doc qui m'a pas mal servis :
cya.

dimanche 11 novembre 2007

Ouverture.

Bonsoir ,
Voilà le premier billet de ce modeste blog , j'ai enfin décidé d'en ouvrir un afin de faire partager mes quelques recherches et codes sur le thème de la sécurité informatique.
Je voudrais remercier tout particulièrement les personnes avec lesquelles j'évolue au quotidien que ce soit sur le net ( #carib0u@irc.worldnet.net && #nibbles@irc.worldnet.net ) ou dans ma petite vie.
En espérant que vous passerez une agréable visite.