Why does the for loop run only 25 times on a 200 byte input?

or maybe i is getting overwritten. Print the value of i after the loop?

Also since you're writing code that relies on UB you can't really expect us to help without providing your compiler version and args.

give code.
Won't bother typing all this myself.

i isn't on the stack, it's in the bss section. OP, it looks like you're overwriting blah and, by some miracle, not segfaulting. Does it terminate successfully with all inputs, or just the one you're trying?

> it's in the bss section
yeah i know. figured there could be some optmization coming into play or something and since I don't really have any other suggestions it's something that's at least quick to inspect.

That's possible, but I haven't seen gcc (nor any other compiler) make these kind of optimizations. Usually it just overflows as much as you'd expect it. This does overflow a bit, but not enough to overflow the return address. When compiled with stack protectors, it does overwrite the stack cookie, though.

i is stored on the heap and doesn't get overwritten.
gcc 8.2.1, but I think it will behave the same on 6.0+, maybe even lower.

ptpb.pw/bz07

I haven't tried every single combination, but with a bunch of 'A's it doesnt segfault.

Bump, any ideas?

its mostly what after going out of bounds on that bok array its all undefined, somehow after a couple more attempts at writing out of those bounds the blah array gets messed up. you'd have to look at a more in depth level to fish out what exactly is going on. if I had to guess it'd be that somehow writing out of those bounds of bok you mess up the address of blah, or something else that segfaults it. see attached image, its the for loop with watchpoints on bok and blah

Attached: bs.png (612x813, 19K)

Try getting the assembly? Or post the build command.
Maybe the loop is unrolled, or something.

Are you sure it's running exactly 25 times? And not 20?

Bok will hit out of bound after the 21st character, then gcc does some weird shit

>char bok[20];
Good fucking lord.

Ask RMS. He might help you.

I'll definitely take a deeper look inside gdb, try to figure out why it doesn't segfault and eventually try to exploit it, thanks.

I did take a look at the disassembly. Only briefly though. I though I had missed something on the source code level.
The build command is: gcc loop.c -fno-stack-protector -o loop

Yes, it runs 25 times

Nice identifiers you shit programmer.

Not my code, retard

>muh identity

Attached: a-trap-can-use-girls-weapons.jpg (350x489, 57K)

>Yes, it runs 25 times
Going by on the 26th loop it attempts to access memory the application is not allowed to access and so it segfaults.
In your memory stack there's probably a variable after the bok array that you're overflowing into until you finally hit your memory bounds.

What exactly are you trying to achieve with this code?

Again, the problem is that it _doesn't_ segfault for some reason

To understand it and to exploit it, for excersise.

Does the program segfault outside of gdb?

Well clearly your "bok" array is 20 char long, so of course it can take only 20 characters. Make it dynamic and the size of the position of '\0' of the input if you want more characters ^^.

>it _doesn't_ segfault
it might not literally say that, but looking at my gdb output and the way it throws nonsense to console before somehow 'gracefully' ending execution could be counted as such

Attached: bs2.png (1522x380, 8K)

I think it starts overwriting blah so it starts pointing outside the string, and it just so happens that the out-of-bounds address is both accessible and contains a zero.

What's the font?

you should dl the shellcoders handbook pdf.
there is a whole chapter about buffer overflow and how to get the adresses and other things.

Looks like DejaVu Sans Mono

I don't think it necessarily returns nonsense, that might be an address of some sort (I think tit might be the end address of the bok buffer), try piping it through xxd

I can't read ebooks on my laptop, it's quite frustrating, I should really get a Kindle or a Kobo. I have basic understanding of buffer overflows and other basic binary exploitation techniques, but I'm trying to learn more and get better

I figured it out. You are stack smashing, but the first thing to get overwritten is not the return address, but blah - the local variable. Then, since blah gets overwritten, the loop starts reading from wrong addresses, until it eventually reads a zero value and stops. That it does not segfault immediately is a miracle of memory layouts.

You can pull out blah into a global too, so you have
int i;
char *blah;

void func(char *b) {
blah=b;

If you do that, the loop will execute completely, then the function will segfault on return.

This makes perfect sense, good job