App - Système
App - Système - ELF x86 - Stack buffer overflow - C++ vtables
Bonjour,
J’arrive à obtenir un shell sur gdb, mais sur la console ca me met quand même une erreur de segmentation.
En utilisant ltrace ou strace, je n’ai pas d’erreur de segmentation.
Quelqu’un aurait une explication sur ce problème ?
Merci
App - Système - ELF x86 - Stack buffer overflow - C++ vtables
Salut,
Oui tu as un decalage sur la stack entre gdb et hors-gdb, et pareil avec Strace/ltrace. Tu peux essayer de copier le binaire dans /tmp et d’analyser des coredumps pour eviter les decalages de stack du aux debuggers.
Tie21
App - Système - ELF x86 - Stack buffer overflow - C++ vtables
Salut Tie21,
J’ai copié le binaire dans le dossier tmp et effectué la commande "ulimit -c unlimited", cependant lorsque je fais crash le binaire dans le fichier /tmp ou depuis le fichier /challenge/app-systeme/ch20, je reçoit pas l’erreur segmentation fault (core dumped). J’ai vu que la machine pour le challenge était un ubuntu, et les personnes sur internet disent qu’il faut effectuer la commande "sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t" pour définir le nom du core file. Sinon pour voir le nom par défaut, on peut run la commande "sysctl kernel.core_pattern", et ça me donne comme résultat core. Certains disent que le core dump se trouve dans le dossier où le fichier a été exécuté, d’autres disent que ça se trouve dans /var/crash.
Conclusion, je vois pas comment avoir le core file. Je n’ai pas accès à /var/crash ou les permissions pour exécuter la commande sysctl. Au final même après avoir run "ulimit -c unlimited", lorsque je fais crash le binaire, il me revoit segmentation fault et non segmentation fault (core dumped).
Skallz
App - Système - ELF x86 - Stack buffer overflow - C++ vtables
Quelque fois, on va chercher trop compliqué 🙂, avec ulimit -c 100000
On obtient bien Segmentation fault (core dumped) avec un joli fichier core