Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error "Unable to find the text segment base addr" if space present in binary path #69

Closed
Angelo942 opened this issue Jun 5, 2023 · 5 comments · Fixed by #80
Closed
Labels
bug Something isn't working

Comments

@Angelo942
Copy link

Hi,
I played with this error for the past two days and pinpointed it to when the local binary passed to gdb contains a space in it's absolute path.

This happens in native gdb and with pwndbg too, but not GEF. Unfortunately GEF as a similar problem when connecting to a gdbserver (hugsy/gef#901 (comment)) so I have to work around it anyway.

I know that gdb has always had troubles with paths containing spaces, but it's the first time after a year working with this setup that I notice one so I don't know if the problems lies in gdb or this library.

@mahaloz mahaloz added the bug Something isn't working label Jun 5, 2023
@mahaloz
Copy link
Owner

mahaloz commented Jun 5, 2023

Hi @Angelo942, to clarify, you are running a local binary (not remote), and you are getting this error if a space is in the binary path?

@mahaloz
Copy link
Owner

mahaloz commented Jun 5, 2023

My immediate hunch is that this line is the cause of this issue. If you wanted to debug it before I can get to it (which will likely be this weekend), you can set a breakpoint here and see what's going on:

return path_name == get_filepath()

This is if you are running locally.

@Angelo942
Copy link
Author

I tested it both debugging a local process and a remote one. The bug is present every time we pass a copy of the binary to gdb.

so gdb ./challenge will never work even if we connect to a gdbserver, but for remote processes just gdb will work fine.

I took a look at the code and we have a problem here, where the path_name used is truncated:

path = mapping.split(" ")[-1]

I tried changing the parse to:

def vmmap_base_addrs():
    addr_maps = {}
    mappings = gdb.execute("info proc mappings", to_string=True).split("\n")
    for mapping in mappings:    
        try:
            addr = int(re.findall(r"0x[0-9a-fA-F]+", mapping)[0], 16)
            path = "/" + "/".join(mapping.split("/")[1:])
        except IndexError:
            continue

        # always use the lowest addr
        if path in addr_maps or path == "/":
            continue

        if addr and path:
            addr_maps[path] = addr

    return addr_maps

This solves the problem for local processes, but not for remote ones. (I focus on that part because gdb ./challenge is how pwntools' gdb.debug launches gdb before connecting to the gdbserver)

if other_file_hash == binary_hash:

Now I'm trying to figure out why the hash is right with gdb, but not with gdb ./challenge.
The only think I noticed so far is that is that in the first case the hash changes every time, while in the second both hashes [other_file_hash and binary_hash] are constant but different. I tried with a path that doesn't contains any spaces and in that case the hashes are all constant.

@mahaloz
Copy link
Owner

mahaloz commented Aug 30, 2023

Linking this GEF issue which may fix some stuff for us: hugsy/gef#999

@Grazfather
Copy link

This one too hugsy/gef#998

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants