Attach and ptrace

[io-no]

There seem to be issues when we attach to a process run with pwntools. Sometimes the SIGTRAP signal of a breakpoint is not intercepted by our ptrace but is sent to the process, causing it to stop unexpectedly. I was not able to reproduce the issue using d.run or subprocess followed by d.attach.

For example, the following script causes an error after a few sendline cycles (often during the first interaction).

io = process('./pkm')
d = debugger()
input("press enter to continue")
d.attach(io.pid)
  
bp = d.breakpoint(position = 0x401C8b, callback = lambda x, y: print('hit'), hardware=True)

d.cont()
io.recv(90)

for i in range(100):
    io.sendline(b'0')
    io.recv(100)
    print('add_pkm')

io.sendline(b'5')
d.wait()
assert bp.hit_count == 100
print('Done!!!!')
d.kill()

Meanwhile, the following script seems to work properly.

io = subprocess.Popen(['./pkm'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
d = debugger()
input("press enter to continue")
pid = io.pid
d.attach(pid)

bp = d.breakpoint(position = 0x401C8b, callback = lambda x, y: print('hit'), hardware=True)

d.cont()
io.stdout.read(90)

for i in range(100):
    io.stdin.write(b'0\n')
    io.stdin.flush()
    io.stdout.flush()
    io.stdout.read(100)
    print('add_pkm')

io.stdin.write(b'5\n')
io.stdin.flush()
d.wait()
assert bp.hit_count == 100
print('Done!!!!')
d.kill()

Without breakpoints, everything works properly.
From my tests, the ptrace wait does not return, and it SEEMS as if the SIGTRAP is sent directly to the process (I hope and believe this is not really the case). I am working on understanding what pwntools does that can interfere with our bps.

Thanks to @danmaam (and his passion for cursed implementations) for highlighting the original strange behavior.

[MrIndeciso]

Can replicate, cannot really explain, but I have a guess:
pwntools is calling waitpid on the process too, and sometimes it is able to win against our internal waitpid and receive the status, which contains SIGTRAP, and so everything breaks.

If not, how would pwntools be able to print "process exited with SIGTRAP"?

If this is the case, well not our problem

[MrIndeciso]

I was able to test this theory.

for i in range(100):
    io.sendline(b'0')
    time.sleep(0.001)
    io.recv(100)
    print('add_pkm')

With a 1ms sleep in-between calls to the tube, the script works correctly.

[io-no]

I was investigating the same thing last night. I spent some time further confirming the theory.

The pwntools recv_raw function calls self.poll(), that is the Popen.poll().

# Implementation of the methods required for tube
def recv_raw(self, numb):
    # This is a slight hack. We try to notice if the process is
    # dead, so we can write a message.
    self.poll()

    if not self.connected_raw('recv'):
        raise EOFError

Same for the send_raw function.

def send_raw(self, data):
    # This is a slight hack. We try to notice if the process is
    # dead, so we can write a message.
    self.poll()

Popen.poll() internally calls waitPid.

if self.returncode is not None:
        return self.returncode  # Another thread waited.
    pid, sts = _del_safe.waitpid(self.pid, _del_safe.WNOHANG)
    if pid == self.pid:
        self._handle_exitstatus(sts)

The polling mechanism seems to be deeply integrated in the pwntools process interaction logic. Therefore, I currently see no solutions that do not require significant changes to the pwntools library.

Not really a bug of libdebug.

[MrIndeciso]

Let's add a disclaimer about this behavior somewhere in the documentation

[MrIndeciso]

In the meantime I'll open an issue with pwntools and see if we get somewhere

[Frank01001]

This behavior has been documented in https://docs.libdebug.org/latest/#conflicts-with-other-python-packages

In the meanwhile, the issue is being investigated.