Add port, gdb_args, and gdbserver_args to gdb.debug()

[gfelber]

added two arguments to gdb.debug()

• port: specifies the port that should be used by the gdbserver, this is useful for alpine, because alpine doesn't support the default openssh port forwarding feature, due to a minimalistic version of openssh
• gdb_args: allows forwarding arguments to the gdb binary spawned by gdb.attach() (just a passthrough)

also downgraded "GDB Python API is supported only for local processes" to a warning, because it seems to work.

These changes are made for compatibility with my pwntools "plugin" vagd which currently uses a workaround on Pwngd.debug() (basically the same behaviour as the patch)

[gfelber]

additionally added the optional argument gdbserver_args, which could be useful for some setups or troubleshooting

[peace-maker]

Cool, thank you! Allowing more control over the way debugging is initiated seems useful for one-off problems.

Your "plugin" looks nice, do you have plans to upstream features? I'd rather have nice docker and qemu integration than patchwork changes to make the external tool work. :D

[peace-maker]

I don't like changing this without tests that proove full support. Then we could just remove the warning altogether. Which runner did work for you other than a process?

[gfelber]

ssh.process works for me.
This makes sense IMO, because gdb is still run on the host session therefore attaching the gdb api through a unix socket still works. Changing it into a warning for ssh.process and an error for everything else

[gfelber]

7305502: GDB Python API is now a warning for ssh.process and an error for everything else

[peace-maker]

I think we should still parse the output even though the port is specified explicitly. There were problems with shells forking when gdbserver uses them causing stalls which were detected by a timeout on the message in _gdbserver_port recently. And this way we're sure gdbserver is up and running before trying to attach.

[gfelber]

7305502: now using gdbserver_port to check if the correct port was set

[gfelber]

Addressed change requests in 7305502.

regarding:

Your "plugin" looks nice, do you have plans to upstream features? I'd rather have nice docker and qemu integration than patchwork changes to make the external tool work. :D

The initial reason this has turned into a "plugin" i maintain myself is so i can basically make changes whenever i encounter a problem or run into an issue (or want to add a new feature).

Generally speaking I don't mind adding the functionality to upstream, but this might require some time because

• i will have to rewrite a lot of stuff to work with python2.7
• i will have to read into the pwntools project to understand exactly how your docs, code structure and testing setups work
  I would probably also keep my repo around, so it's easier for me to add and test new stuff

Maybe we can move this discussion somewhere else? My discord tag is @gfelber (I'm also on the official discord server).

[peace-maker]

It would be better to add the tests instead of this vague warning. I think we can copy the API tests and slap a ssh=shell argument to the .debug call.

See here for instructions on how to test locally. make -C travis/docker ANDROID=no TARGET=gdb.rst should do the job.

[peace-maker]

Ah, lol. gdb tests are disabled in the docker testing setup apparently. CI will do the work then.

pwntools/travis/docker/doctest3

Lines 27 to 29 in 51e8eb0

	# GDB tests currently don't work inside Docker for unknown reasons.
	# Disable these tests until we can get them working.
	echo > ~/pwntools/docs/source/gdb.rst

[peace-maker]

I just tried running the gdb tests in docker and they all passed, so I guess we can just remove that line from doctest3 and include them.

[gfelber]

0ee8d36 so i added some test cases (the same as non ssh) and i was wondering how this test case is supposed to work (IMO it doesn't make sense for gdb.attach to work on remote targets and the test case doesn't work for me).

        Attach to the remote process from a :class:`.remote` or :class:`.listen` tube,
        as long as it is running on the same machine.

        >>> server = process(['socat', 'tcp-listen:12345,reuseaddr,fork', 'exec:/bin/bash,nofork'])
        >>> sleep(1) # Wait for socat to start
        >>> io = remote('127.0.0.1', 12345)
        >>> sleep(1) # Wait for process to fork
        >>> pid = gdb.attach(io, gdbscript='''
        ... call puts("Hello from remote debugger!")
        ... detach
        ... quit
        ... ''')
        >>> io.recvline()
        b'Hello from remote debugger!\n'
        >>> io.sendline(b'echo Hello from bash && exit')
        >>> io.recvall()
        b'Hello from bash\n'

this is the error i get

Document: gdb
-------------
**********************************************************************
File "../../pwnlib/gdb.py", line ?, in default
Failed example:
    io.recvline()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python3.10/doctest.py", line 1350, in __run
        exec(compile(example.source, filename, "single",
      File "<doctest default[5]>", line 1, in <module>
        io.recvline()
      File "/home/pwntools/pwntools/pwnlib/tubes/tube.py", line 527, in recvline
        return self.recvuntil(self.newline, drop = not keepends, timeout = timeout)
      File "/home/pwntools/pwntools/pwnlib/tubes/tube.py", line 341, in recvuntil
        res = self.recv(timeout=self.timeout)
      File "/home/pwntools/pwntools/pwnlib/tubes/tube.py", line 106, in recv
        return self._recv(numb, timeout) or b''
      File "/home/pwntools/pwntools/pwnlib/tubes/tube.py", line 176, in _recv
        if not self.buffer and not self._fillbuffer(timeout):
      File "/home/pwntools/pwntools/pwnlib/tubes/tube.py", line 155, in _fillbuffer
        data = self.recv_raw(self.buffer.get_fill_size())
      File "/home/pwntools/pwntools/pwnlib/tubes/sock.py", line 39, in recv_raw
        data = self.sock.recv(numb, *a)
      File "/home/pwntools/pwntools/docs/source/conf.py", line 446, in alrm_handler
        raise EndlessLoop()
    EndlessLoop

i also added some timeouts to the other recvline commands for the tests

[gfelber]

hey are there any outstanding issues?
Without this patch I can't start with up streaming vagd

[peace-maker]

No, sorry. I wanted to check why you had to add the timeout everywhere instead of having a timeout set on the context but didn't get to it.
I can clean up later if there is something to cleanup.

Thank you!

[gfelber]

No, sorry. I wanted to check why you had to add the timeout everywhere instead of having a timeout set on the context but didn't get to it.

Zeah i guess context would have been better for the docs, but i realized that there are different acceptable timeout margins (e.g. some use 1s others 30s), so decided to set it to 1s for most use cases and in special cases increased it