If you're not using str anywhere after then it's just that the garbage collector has not run so the memory that should be released hasn't been collected yet. This is probably because Java doesn't need it (since it has some reserve pages left) yet as Java has to use a certain amount of memory before it starts reclaiming memory since running the garbage collector is an expensive task.

@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)

You're allocating perms[8] with a size of 8. So valid indexes for this tab are going to be [0-7].

After you assign perms[8] = mode & S_IXOTH? 'x' : '-'; and perms[9] = '\0'; which are out of boundaries of your perms array.

Your time array must be right after perms in memory. so perms[8] and perms[9] act like you were affecting time[0] = '-' then time[1] = '\0'.

time is now equal to - and printf displays it correctly.

Just correct your perms[8] declaration to perms[10] and you will affect value to the good variable memory part.

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.

First one is correct. There is no memory leak, by the way.

--

I think sprintf is C. Is there a better way?

Yes. C++ way:

std::stringstream ss;  //#include <sstream>
ss << fCount;
std::string frameNum = ss.str();