unix4fun

Aller au contenu | Aller au menu | Aller à la recherche

Tag - python

Fil des billets - Fil des commentaires

mercredi 9 juin 2010

Le crochetage SSL avec ton serpent

Par frl le mercredi 9 juin 2010, 11:43 - geeking

Pour un premier post, désolé, c'est sur du win32 :). Je lisais dernièrement "GrayHat Python" et je découvre Pydbg (un debugger écrit en python) que je ne connaissais pas (bon je ne connais pas grand chose non plus, du coup c'est plus facile d'être émerveillé) et dans le chapitre sur le hooking je tombe sur un exemple de "soft-hooking" (le hooking avec un breakpoint soft (INT3) sur la fonction qui t'intéresse) pour "sniffer" les connections SSL dans firefox (hook sur une fontion specifique de firefox).

Ca me rappelle des discussions avec eau qui avait déjà commence a bosser dessus, en voyant comment le truc est tout con ca m'a donne envie de voir si hooker les "CryptoAPI"s de MS que IE utilise est tout aussi simple.

Donc une fois recup Pydbg, un petit "import pydbg" et on peut instancier un object debugger mydbg=pybdg.pydbg().
Et voila! maintenant qu'on a notre debugger instancié, on peut s'attacher a des process, mettre des breakpoints, lire l'etats des registres etc.. Un peu comme scripter a l'interieur d'IDA ou ImmunityDebugger.

Du coup c'est vrai que le soft hooking comme ca c'est tout bidon. Un petit breakpoint dans la fonction qui nous intéresse, une callback fonction pour effectuer des opérations sur cette fonction et on release le breakpoint pour que le process continue normalement.

Bon, c'est pas efficace du tout côté perf, c'est clair...
Mais pour un ptit hooking rapido histoire de tester/fuzzer un truc ca peut etre sympa et utile.

Alors voila j'ai matte les CryptoAPI de MS et j'ai pense d'abord hooker "CryptEncrypt()" et "CryptDecrypt()" exportées par "Advapi32.dll".

Ok finalement en cherchant un peu, il y a eut pleins de présentations sur le hooking de ces 2 fonctions (par exemple celle-ci) et en effet c'est tout bon mais pour sniffer uniquement.

Si on veut modifier les requêtes envoyées par exemple, alors la on voit qu'on tombe sur un os, en tracant les appels un certain "CryptHashData()" est appelé avant "CryptEncrypt()" et donc dommage.. Difficile de modifier un truc hashe préalablement sans que ca se voit! Et la ce cher eau me dit qu'il avait regarde "EncryptMessage()" et "DecryptMessage()" et il avait raison le bougre!

En effet "EncryptMessage()" prend la requête, appele "CryptHashData()" puis "CryptEncrypt()" et balance tout ca hashé/chiffré ensuite au fonctions résal(réseaux). Du coup hooker "EncryptMessage()" est bien plus intéressant puisqu'avant le hash donc possible de modifier la requête.

Je n'ai pas encore réussi a faire tout ce que je voulais sur "EncryptMessage()", modifier la requête...ok, mais uniquement si sa nouvelle taille est <= a l'originale. Pour en générer une de taille > a la requête originale, je coince.

J'ai essaye de mettre a jour la taille a plusieurs endroits, re-ecrire la requête en allouant assez de place ailleurs et updater les pointeurs/références sur ma nouvelle requête mais niet... je dois merder, quelque chose m'échappe.

Voyant que des fonctions appelées avant "EncryptMessage()" manipulaient aussi la requête HTTP et utilisaient la taille pour différents trucs que je n'ai pas exploré je me suis résigné a hooker la dedans et c'est passé. Enfin, j'ai finalement hooke une fonction qui se trouve dans "Wininet.dll" mais elle semble tres specifique a IE donc pas super fonctionnel pour autre chose qu'IE... (i.e. Thick Client)...

Pour ceux que ca intéresse, voila un petit bout de code tout bidon (et pas beau je sais :)..) mais c'est juste pour tester et voir comment jouer avec pydbg et le soft-hooking:

hook_ssl_pydbg.py

J'ai teste ca sur XP SP2 en anglais avec IE7.

Un petit print screen aussi pour voir ce que ca donne:

hook_ssl_pydbg.png

Pydbg fait parti du framework Paimei (du coup ca m'a donne envi de revoir kill bill2..):
Paimei

svn checkout http://paimei.googlecode.com/svn/trunk/pydbg paimei-read-only

CryptEncrypt(), CryptDecrypt(), EncryptMessage(), DecryptMessage()

Ca passe ok avec python 2.6 sur ma VM XP mais quelques posts disent que pydasm ne passe bien qu'avec python 2.5.

2 commentaires aucun rétrolien

jeudi 8 octobre 2009

*Real* High level languages are Un!X

Par sbz le jeudi 8 octobre 2009, 01:22 - geeking

Nous aimons tous le C, l'asm, Unix et Linux, c'est un fait. Mais voilà pourquoi on aime aussi le Python et le Perl qui sont aussi des *vrais* langages.

Vous en doutez encore ? Allez jeter un oeil ici et là.

aucun commentaire aucun rétrolien

vendredi 21 décembre 2007

oye oye oye de retour!

Par eau le vendredi 21 décembre 2007, 02:25 - geeking

Hola,

apres une grosse absence, il me semble qu'il est bon de revenir un peu, les fetes approchent, du coup, alors comme c'est noel j'offre que dalle...

par contre apres mes galeres avec pylibpcap et le threading, je suis passe a ca ca marche sans sourciller..

je posterai un ptit exemple rapidement j'espere...

aussi le week end food du retour arrive!!! one-two checking the microphone - check this out incoming week end food soon... (1 jour)

aucun commentaire aucun rétrolien

lundi 5 novembre 2007

IMDbis.

Par poz le lundi 5 novembre 2007, 16:54 - geeking

En tant que lecteurs assidus de ce formidable site, vous vous rappelez évidemment de la news traitant d'IMDb. Bah voilà, je profite un peu de mon préavis en lurkant sur le interwebz comme disent nos amis d'outre Atlantique, et on me signale deux-trois trucs qui facilitent la discussion avec IMDb.com. Deux petites libs pour récupérer des informations concernant les acteurs/réalisateurs/films, écrites en Python et Ruby, qui plus est :

- libimdb-ruby
- imdbpy

PS : non je ne fais pas une fixation.

PPS : IMDbPy semble plus abouti (j'ai juste jeté un oeil)

aucun commentaire 2 rétroliens

DHCP et python

Par ppr le lundi 5 novembre 2007, 15:26 - geeking

Pour développer un daemon DHCP en python, rien de plus simple, il existe la Pydhcplib développée à l'origine pour le projet Anemon. En l'occurence cette bibliothèque m'a sauvé la vie pour le développement d'un serveur DHCP se basant sur Xenstore. Définitivement pratique.

un commentaire un rétrolien

lundi 17 septembre 2007

python, le GIL, pourquoi et tout ça ?

Par ppr le lundi 17 septembre 2007, 18:15 - geeking

Avec eau (aka. Le Frelon Dardé du Gabon) on discutait d'une appli en développement basée sur python et la pylibpcap. Le modèle de l'application était composé de deux threads : une thread pour l'envoi de paquets et une thread utilisant pcap pour la réception. Le problème de ce modèle appliqué à python est que cette application ne pouvait pas marcher "as is" : la thread d'envoi ne pouvait pas démarrer car la pylibpcap acquiert le GIL (Global Interpreter Lock) et ne le libère jamais. En d'autres termes : la thread d'envoi n'était jamais démarré et python se consacrait à la thread de réception qui, du coup, ne recevait rien.

Petite explication nécessaire : les développeurs de Python ont décidé de développer un interpréteur qui n'est pas thread-safe, pour la simplicité. Cependant, pour tout de même proposer des threads, il leur a été nécessaire de créer un lock, global, entre elles. Chaque thread acquiert donc ce lock (le GIL) exécute un nombre donné (et configurable) d'instructions python, puis libère le GIL. De l'extérieur tout se passe comme si les threads étaient exécutées séquentiellement pendant un certain nombre d'instructions plutôt que parallèlement. C'est la raison d'un des plus gros trolls sur python, après l'indentation : le GIL.

La réponse de Guido van Rossum, le BDFL de python est toujours la même : n'utilisez pas de threads, développez plusieurs processus et faites les communiquer par IPC. C'est un des éléments de la philosophie python et les arguments de Guido sont nombreux.

Donc, en ce qui concerne l'application en développement, plutôt que de patcher la pylibpcap, il est peut-être plus intéressant de développer l'application dans un modèle "à la python" avec un processus d'écoute qui transmet à un processus de traitement les paquets lus, par IPC.

L'intérêt n'est pas de décider si le GIL est une bonne ou une mauvaise idée mais de comprendre pourquoi il est là et la philosophie du langage quand on a à l'utiliser. Donc, voici les quelques ressources citées dans l'article, pour ceux qui veulent en savoir plus :

  1. Python/C API Reference Manual, Thread State and the Global Interpreter Lock, http://docs.python.org/api/threads.html
  2. python-list, pylibpcap and multiple threads : http://mail.python.org/pipermail/python-list/2005-January/303798.html
  3. Needled by Threads : http://cleverdevil.org/computing/30/needled-by-threads
  4. python-3000, the future of the GIL : http://mail.python.org/pipermail/python-3000/2007-May/007414.html

4 commentaires aucun rétrolien

lundi 10 septembre 2007

Grapher le wifi

Par eau le lundi 10 septembre 2007, 09:16 - geeking

Comme je disais la dernière fois, même si c'est des p'tits trucs, bah c'est utile ou ça apporte quelquechose de nouveau. Enfin voilà ils n'arrêtent pas.

Un p'tit tool pour grapher genre tous les BSSID d'un même réseau wireless avec où sont connectés les clients, c'est pas nouveau, mais juste le fait de passer un coup de graphviz ça devient déjà plus lisible.

C'est ici : http://community.corest.com/~hochoa/wifizoo/index.html

aucun commentaire aucun rétrolien

jeudi 23 août 2007

dnspython

Par ppr le jeudi 23 août 2007, 18:42 - geeking

La bibliothèque dnspython est bien pratique pour manipuler des requêtes et des réponses DNS en python.

Pour exemple, un serveur DNS sur UDP, threadé à la demande, et qui répond IN A 1.2.3.4 à toutes les requêtes :

from SocketServer import ThreadingUDPServer
from SocketServer import DatagramRequestHandler
from dns import message, rdataclass, rdatatype, rrset

class DNSRequestHandler(DatagramRequestHandler):
    def handle(self):
        msg = message.from_wire(self.rfile.read(1500))
        reply = message.make_response(msg)
        name = reply.question[0].name.to_text()
        rdset = rrset.from_text(name, 0, rdataclass.IN,
            rdatatype.A, '1.2.3.4')
        reply.answer = [ rdset ]
        self.wfile.write(reply.to_wire())

if __name__ == '__main__':
    server = ThreadingUDPServer(('127.0.0.1', 5353),
        DNSRequestHandler)
    server.serve_forever()

aucun commentaire aucun rétrolien

lundi 20 août 2007

Python Decorators

Par ppr le lundi 20 août 2007, 14:00 - geeking

Les Decorators (Design Pattern) en Python sont bien documentés : il y a tout d'abord le PEP318 et ensuite, pour le compléter, cette documentation The decorator Module qui présente plusieurs utilisations classiques de ce design pattern.

aucun commentaire aucun rétrolien