Exploiting Tools
Metasploit
Coquilles###
GDB
Installation
Paramètres
Instructions
Astuces
Adresses identiques dans GDB
Pendant le débogage, GDB aura des adresses légèrement différentes de celles utilisées par le binaire lors de son exécution. Vous pouvez faire en sorte que GDB ait les mêmes adresses en faisant :
unset env LINES
unset env COLUMNS
set env _=<chemin>
Mettez le chemin absolu vers le binaireExploitez le binaire en utilisant le même chemin absolu
PWD
etOLDPWD
doivent être les mêmes lors de l'utilisation de GDB et lors de l'exploitation du binaire
Retrouver les fonctions appelées avec la trace de pile
Lorsque vous avez un binaire lié statiquement, toutes les fonctions appartiendront au binaire (et non aux bibliothèques externes). Dans ce cas, il sera difficile de identifier le flux que suit le binaire pour par exemple demander une entrée utilisateur.
Vous pouvez facilement identifier ce flux en exécutant le binaire avec gdb jusqu'à ce qu'une entrée vous soit demandée. Ensuite, arrêtez-le avec CTRL+C et utilisez la commande bt
(backtrace) pour voir les fonctions appelées :
Serveur GDB
gdbserver --multi 0.0.0.0:23947
(dans IDA, vous devez remplir le chemin absolu de l'exécutable dans la machine Linux et dans la machine Windows)
Ghidra
Trouver le décalage de la pile
Ghidra est très utile pour trouver le décalage pour un débordement de tampon grâce aux informations sur la position des variables locales.
Par exemple, dans l'exemple ci-dessous, un débordement de tampon dans local_bc
indique que vous avez besoin d'un décalage de 0xbc
. De plus, si local_10
est un cookie canary, cela indique qu'il y a un décalage de 0xac
pour l'écraser depuis local_bc
.
Rappelez-vous que les premiers 0x08 où le RIP est sauvegardé appartiennent au RBP.
GCC
gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compiler sans protections -o --> Sortie -g --> Sauvegarder le code (GDB pourra le voir) echo 0 > /proc/sys/kernel/randomize_va_space --> Pour désactiver l'ASLR dans Linux
Pour compiler un shellcode : nasm -f elf assembly.asm --> retourne un ".o" ld assembly.o -o shellcodeout --> Exécutable
Objdump
-d --> Désassembler les sections exécutables (voir les opcodes d'un shellcode compilé, trouver des gadgets ROP, trouver l'adresse d'une fonction...) -Mintel --> Syntaxe Intel -t --> Table des symboles -D --> Désassembler tout (adresse d'une variable statique) -s -j .dtors --> section dtors -s -j .got --> section got -D -s -j .plt --> section plt désassemblée -TR --> Relocations ojdump -t --dynamic-relo ./exec | grep puts --> Adresse de "puts" à modifier dans la GOT objdump -D ./exec | grep "VAR_NAME" --> Adresse d'une variable statique (celles-ci sont stockées dans la section DATA).
Dumps de core
Exécuter
ulimit -c unlimited
avant de démarrer mon programmeExécuter
sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
sudo gdb --core=\<path/core> --quiet
Plus
ldd executable | grep libc.so.6 --> Adresse (si ASLR, alors cela change à chaque fois) for i in `seq 0 20`; do ldd <Ejecutable> | grep libc; done --> Boucle pour voir si l'adresse change beaucoup readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system --> Décalage de "system" strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh --> Décalage de "/bin/sh"
strace executable --> Fonctions appelées par l'exécutable rabin2 -i ejecutable --> Adresse de toutes les fonctions
Débogueur Inmunity
IDA
Débogage à distance sur Linux
À l'intérieur du dossier IDA, vous pouvez trouver des binaires qui peuvent être utilisés pour déboguer un binaire sur un système Linux. Pour ce faire, déplacez le binaire linux_server ou linux_server64 sur le serveur Linux et exécutez-le à l'intérieur du dossier contenant le binaire :
Ensuite, configurez le débogueur : Débogueur (remote linux) --> Options du processus... :
Last updated