But to make this short, gdbserver version 11.1 solves the problem! Thanks also to Peace-Maker from the pwntools discord server who finally pointed me to the correct issue: So i decided to update the gdb version on the Debian VM, found out that on debian it was working at some time, tried different python versions, building gdb on the ubuntu vm with a different python version and so on…this was not a fast process, because you need to build python and gdb every time from the source and that takes time. Ubuntu 20.04.3 comes with gdb and gdbserver version 9.2, debian 11.2.0 comes with version 10.1-1-7 and also the python version is different (3.8 vs 3.9 etc.). I thought maybe something in my environment is broken so i installed a fresh new Ubuntu and a fresh new Debian, same problem on both VMs. gdb attach works but i was not able to debug further (it just hangs).the problem is not binary related, so it comes up with any other 32 binary.pwndbg depends on gdb and the inbuild python of the gdb build, pwntools depends on gdb, the gdbserver and python and all of these exists in different versions I googled a lot about the missing cache file (cacheinfo.c) gdb is claiming about but cant found any one else having this problem. So i thought it must have been related to pwntools. split32 everything is fine and you can debug through the hole binary without any crash. The interesting thing is, if you start the binary with in gdb standalone gdb. I stepped further to find the exactly instruction that causes this crash and found the _dl_init Setting a breakpoint at main and continuing to it crashes the binary Here is my script that i used for troubleshooting from pwn import *Į = ELF(binary, checksec=False) # setting pwntools context os/archĬontext.os = 'linux' # so that we won't have to specify it explicitlyĬontext.arch = e.arch # when using pwntools functions like asm etc. This was working fine for me with 64bit binares, but with the 32bit version of the binary it always crashes just before the main function was reached. I already learned, to avoid memory address differences between the (i will call it standalone) debugging when you run gdb and the „normal“ execution, i try to start as soon as possible with a pwntools script and start the debugger from there with gdb.debug(). My main toolset is basically (next to some standalone tools): Long story short, this was the point where my struggle begin.ĭoing reverse engineering and binary exploitation can involve a lots of different tools, frameworks and libraries which partial depends on each other. So i short decided to do the 32bit challenges as well to get a better understanding and practice about that. ![]() series that there is a difference between how 32bit and 64bit binaries handle function arguments (stack vs. ![]() The second challenge (split) is about providing a correct parameter to your Gadget. Completed the first challenge without any problem. After some reverse engineering lessons and understanding the basics i decided to do the ropemporium series, also because CryptoCat has a good youtube series about it, so you can watch them if you get stuck or want to proof if there are other solutions.įirst i decided to concentrate on the 64bit binaries (ropemporium always provide each challenge in different architectures). There are many good tutorials, challanges and ctfs out there, where you can start learning the topic. One of these problems i will describe today. A few weeks ago i just started with binary exploitation and as learning and understanding this topic is not enough challenging, i encountered different problems with the tools and some basics.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |