Incompatible system python vs gdb python

[armax00]

While working on solving level 7.0 and 7.1 I noticed the following issue that worked earlier.

What I want to do is to get a value of a register out of a first run to then use it in a second run. That way, I should be able to fully automate at exploit independently of container restarts. However gdb is complaining.

Error: [ERROR] Failed to connect to GDB: rpyc is not installed

Code example: g = gdb.debug(CHALLENGE, ''' break main continue ''') value = (g.execute("print ($rbp))")) g.close()

Looking at the pwntools docs this seems to be an issue with the different python interpreters used: hacker@program-exploitation~level7-0:~/yellow/prog-exploitation/level07$ gdb -batch -ex 'python import sys; print(sys.version)' 3.11.9 (main, Apr 2 2024, 08:25:04) [GCC 13.2.0] hacker@program-exploitation~level7-0:~/yellow/prog-exploitation/level07$ python3 --version Python 3.8.10

Would it be possible to upgrade python to 3.11.9?

[ConnorNelson]

Interesting, this definitely sounds like a new nix-related bug. Thanks for reporting.

[ConnorNelson]

Ok so it looks like the gdb.debug starts up gdb correctly with your initial gdb script.

I am not seeing how g.execute works; it doesn't seem to be a method on the pwnlib.tubes.process.process which I get back from gdb.debug.

That being said, import rpyc definitely works inside /usr/bin/gdb, but does not work inside /run/current-system/sw/bin/gdb, which means I can reproduce the underlying issue.

[armax00]

Yeah, the command execute() should be available on the Gdb object exposed by the naitve gdb Python object. That is what .debug() should return but it is possible I missed how to call it properly. (I did that earlier, I believe I still have the script in my home dir).

Said that, because of the error, I was not able to get that far :)

On Fri, 26 Jul 2024, 22:10 Connor Nelson, @.***> wrote:

Ok so it looks like the gdb.debug starts up gdb correctly with your initial gdb script.

I am not seeing how g.execute works; it doesn't seem to be a method on the pwnlib.tubes.process.process which I get back from gdb.debug.

That being said, import rpyc definitely works inside /usr/bin/gdb, but does not work inside /run/current-system/sw/bin/gdb, which means I can reproduce the underlying issue.

— Reply to this email directly, view it on GitHub https://github.com/pwncollege/dojo/issues/483#issuecomment-2253321313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH43RPCONHBRU6FXXIU5FTZOKNI5AVCNFSM6AAAAABLRAN7USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJTGMZDCMZRGM . You are receiving this because you authored the thread.Message ID: @.***>

[ConnorNelson]

It looks like gef and pwndbg in their nixpkgs implementations setup a pythonPath.

In gef they use makeWrapper to make a gef program that calls gdb with a custom NIX_PYTHONPATH and PATH and -x gef.py.

In pwndbg they also use makeWrapper, with -x pwndbg/gdbinit.py, and patch that gdbinit to setup PYTHONPATH/PATH.

It looks like we'll need to also take an approach of wrapping gdb (probably we'll also make it be called gdb so everything works by default) and getting any dependencies we want gdb to have access to. I think I favor the gef approach a bit more.

Probably these dependencies will include:

• Everything pwntools wants
• Everything pwndbg wants
• Everything gef wants

But maybe we should be even broader with this and make sure the full python environment that we setup's dependencies appear.

Any thoughts on this @Scoder12 @supercoolspy?

[supercoolspy]

Sounds good