attaching libdebug to a 32 bit process sometimes thinks it's 64 bit

[jtyliu]

If you have a 32 bit binary, run it with pwntools' process with shell=True and set a breakpoint, sometimes libdebug will attempt to set a breakpoint at a 64 bit address.

Note I could not get this error to trigger if shell=False (which is the default behaviour of process)

test.c

#include <stdio.h>
int main(){
	getc(stdin);
	printf("REE\n");
}

test.py

from libdebug import debugger
from pwn import *

context.log_level = 'critical'

def guess():
    con = process('./test', shell=True)
    d = debugger()
    d.attach(con.pid)

    d.breakpoint(0x804a92a)
    d.kill()
    con.close()
    return


for _ in range(100):
    print("AH")
    guess()

error

Traceback (most recent call last):
  File "/home/joshual/test.py", line 26, in <module>
    guess("AAA", 'REEEEEEE')
  File "/home/joshual/test.py", line 18, in guess
    d.breakpoint(0x804a92a)
  File "/home/joshual/.local/lib/python3.12/site-packages/libdebug/libdebug.py", line 327, in breakpoint
    address = self.context.resolve_address(position)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/joshual/.local/lib/python3.12/site-packages/libdebug/state/debugging_context.py", line 247, in resolve_address
    normalized_address = normalize_and_validate_address(address, maps)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/joshual/.local/lib/python3.12/site-packages/libdebug/utils/debugging_utils.py", line 29, in normalize_and_validate_address
    raise ValueError(f"Address {hex(address)} does not belong to any memory map.")
ValueError: Address 0x55555d59e92a does not belong to any memory map.

[io-no]

I discussed the problem with @MrIndeciso and we tested the code you proposed. It really seems to be a race condition.

The point is that the attachment of libdebug is fast enough to attach to the PID when the memory layout is still the one of the shell and not the new memory space of the binary you want to execute (probably it is attaching before the exec syscall called by the shell). This is indeed a problem even in 64-bit binaries but it is less evident since the breakpoint is more likely to exist. When you use it with 32-bit binaries, the shell memory layout and the binary memory layout are much more different, leading to an exception.

Indeed, the problem is solved by adding a sleep before the attach. However, it can generate another race condition, the one at #48 (yes, maybe we are way too fast for pwntools in general).

I will add the tests I performed for completeness:

• Without the sleep, as you can see, the memory map is the one of /bin/bash (please see the memory regions).
  

from libdebug import debugger
from pwn import *
from time import sleep

context.log_level = 'critical'

def guess():
    con = process('./test', shell=True)
    d = debugger()
    d.attach(con.pid)
    print(d._internal_debugger.debugging_interface.maps())
    d.breakpoint(0x80491ae, callback=lambda _, __: print("puts reached"))

    d.cont()

    con.send(b'A')
    print(con.recvuntil(b"REE"))

    d.kill()
    con.close()
    return


for _ in range(100):
    print("AH")
    guess()

• With sleep, no errors on the breakpoint are returned and the memory map is the correct one.
  

from libdebug import debugger
from pwn import *
from time import sleep

context.log_level = 'critical'

def guess():
    con = process('./test', shell=True)
    d = debugger()
    sleep(0.5)
    d.attach(con.pid)
    print(d._internal_debugger.debugging_interface.maps())
    d.breakpoint(0x80491ae, callback=lambda _, __: print("puts reached"))

    d.cont()

    con.send(b'A')
    print(con.recvuntil(b"REE"))

    d.kill()
    con.close()
    return


for _ in range(100):
    print("AH")
    guess()

Note: the test has been performed on the branch aliases (the behavior is the same but the way to access the memory map is different, we are working on exposing the map with a proper public API. Sorry for that).

Thank you for highlighting the problem. We will definitely add some advice to the documentation (at least).

[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.

[io-no]

I will close this issue since it is not something we can control. As @Frank01001 mentioned, we have included a warning in the documentation about this behavior, which is the most we can do at this point.

Feel free to open new issues if further problems arise, and thank you again for your collaboration. It is greatly appreciated.