Automatic finding one-gadget

[Isaac0616]

There is a tool for finding one-gadget written in ruby. Is it a good idea to have one in pwntools?

[zachriggle]

Perhaps? It'd be better / easier to use if there were a single endpoint which had all of the offsets in a neutral format like JSON.

I think that the other tool is useful in its own right, I'm not sure that it necessarily fits into the Pwntools workflow currently.

[ZetaTwo]

For anyone searching for "one_gadget pwntools" and ending up on this issue: I made the following utility function which calls the one_gadget tool with a path or build id and returns a list of offsets. It requires one_gadget to be installed and in the PATH:

def get_one_gadgets(libc):
	args = ["one_gadget", "-r"]
	if len(libc) == 40 and all(x in string.hexdigits for x in libc.hex()):
		args += ["-b", libc.hex()]
	else:
		args += [libc]
	return [int(offset) for offset in subprocess.check_output(args).decode('ascii').strip().split()]

which can then be called for example with:

print(get_one_gadgets(ELF('libc.so.6').buildid))

or

print(get_one_gadgets(ELF('challenge').libc.path))

[Hellsender01]

Maybe this fits you -

from one_gadget import generate_one_gadget

path_to_libc = './libc-2.23.so'

for offset in generate_one_gadget(path_to_libc):
    print(offset)

Spoiler!

This does not work everytime

[ir0nstone]

How acceptable would it be for pwntools to have a one_gadget function in the ELF class that simply uses subprocess to call the Ruby one_gadget? An error would have to be thrown in case it's not installed and on the PATH, but I think it could be incredibly helpful.

Not quite sure on the licensing issues this would invoke, though.

[Arusekk]

Nobody (except the transitional NMap license) ever argued spawning a subprocess constitutes a derivative work, so it falls just under 'use for any purpose' under both FSF-approved and OSI-approved licenses, so licensing-wise this is 100% safe. I would love to call a direct API though in case anyone ever implemented one. In case of an error we can just display a message analogous to missing binutils. Email z wtorku 26 marca 2024 od Andreja L:

…

How acceptable would it be for pwntools to have a `one_gadget` function in the `ELF` class that simply uses `subprocess` to call the Ruby [`one_gadget`](https://github.com/david942j/one_gadget)? An error would have to be thrown in case it's not installed and on the `PATH`, but I think it could be incredibly helpful. Not quite sure on the [licensing](https://github.com/david942j/one_gadget/blob/master/LICENSE) issues this would invoke, though. -- Reply to this email directly or view it on GitHub: #932 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***

-- Wysłane z mojego urządzenia Sailfish

[ir0nstone]

It does not appear as if there is an API. The repository itself describes a way to grab the one-gadgets through a subprocess. That ok?

[david942j]

Author of one_gadget here 👋

Feel free to let me know if any support is required from the one_gadget gem. A simple Python wrapper to call subprocess to one_gadget shall be a preferred (at least I prefer it) way to enable it on Pwntools.

Or if there is a common practice for bridging Python-Ruby method exists then I am also fine to add such support on the Ruby side if needed.

[peace-maker]

Hey!👋 I'd like to see a json output instead of having to parse the text for --near X --raw output, which would make it more robust against cosmetic changes you might want to do. But the basic use case of just grabbing all magic gadgets for a file with a plain one_gadget --raw libc.so.6 execution is good as is. I think shelling out to the one_gadget tool is perfectly fine.

@ir0nstone How do you envision this function to be used in pwntools scripts? Get all one gadgets and just try them in a loop?
I'm thinking of whether adding some interactive selection while showing the gadget constraints be useful. Similar to libcdb.search_by_symbol_offsets:

That would allow you to try a few gadgets without touching your script's code.

pwndbg has a onegadget command which parses the tool's output and filters the available gadgets based on whether the constraints can be satisfied in the current execution context which simplifies the process of selecting the right gadget if there is one that doesn't require additional memory/register manipulation.

[david942j]

@peace-maker thanks for the suggestion! I have filed david942j/one_gadget#224 for tracking this support on one_gadget.