32-bit x86 LINUX BUFFER OVERFLOW (PicoCTF 2022 #31 'buffer-overflow1') 

There are videos that discuss stack over follow / buffer overflow and more variables. Just gotta know what to look for, this information has been out for many many years! Has a lot to do with network administration and active directories. Heck I'm surprised there hasn't been any CTF for buffer under run. I reported the security threat the second I figured I could gain full privilege to a server and reroute traffic. Sad part is I had no idea about bug bounty programs and since big shot did or else I'd be rich lol

@@elijah2863 are you a poorly written bot?

A slightly more efficient method of finding the offset is to generate a fairly large string of characters that never repeat the same 2 bytes, pass it into the app that you started with a debugger, then check the EIP register and read out the little endian format of the string. Search for that as a substring of the original string you generated, et voila.... count the bytes prior and you have your offset without trial and error.

dont give space after ./ vuln rather write it ./vuln

I think im a stupid. it will be the same because its the virtual memory address, and it will be mapped on the appropriate physical memory by the os.

Well, you're not stupid, because you answered your own question correctly ;)

because there were protection called PIE/ASLR, which is will randomization the address but in this binary the protection are disabled so the address will be the same

The return value has been compromised :)

It just tells you if the "little end" or "big end" comes first. For anyone wondering why on earth little-endian became a thing, it's because it simplifies mathematical operations for the processor. You always start with the least significant byte then carry to the more significant ones, so starting with the LSB in memory avoids having to count over from the beginning of it's storage to find the LSB, esp for inc or dec or other small operations that only occasionally will carry

Loooooo forgotten but remembered in our hearts.

only thing that the source code help with was the use of gets/buffer size

You can still view the source code with decompile the binary but its not 100% similiar with original source code

And also, why is the address of win() in local the same as the one on the server? shouldnt the win() has a different address to be called in the server?

Say your function gets called, so return address gets pushed to the stack and execution transfers to the beginning of your function. ESP is say 0x2000 now, which points to the first byte of the return address in memory It's a completely bare-bones function that doesn't save the frame pointer or set up any other variables, all it does is subtract 0x100 from ESP, to create a 100-byte local buffer starting at address 0x1900. If you start copying a string to your buffer, the first byte gets copied to 0x1900, the 2nd byte to 0x1901, etc. If you don't do any bounds checking, the 101st through 104th bytes you copy in will go in 0x2000 through 0x2003 and you've overwritten your return address Discreet numbers the processor saves are stored in little-endian on Intel systems. Buffers are generally copied in byte by byte in an incrementing loop

They gave out a pre-compiled executable with the challenge to ensure it was configured to be based at the same virtual address to make the challenge easier. Since it actually tells you the original return address during operation, you could actually still calculate the right address on the server if it were based differently but not changing from run to run.

holy shit, you need to go outside dude, touch some grass fr.

I'm pretty sure mixing up some terminology doesn't kill people 🤣