It was present on the stack before and esp, 0xfffffff0 instruction that aligns the stack to 16 bytes. This instruction doesn't erase the data that was previously at esp (so ecx-4 still points to the return address), but stack pointer points now to possibly different value than at the begining of the function. So there is a need to push the return value ([ecx-...
To examine in radare2 you can think as 'print values' and you can use:
px show hexdump
pxl display N lines (rows) of hexdump
pxr[j] show words with references to flags and code (q=quiet)
> px [nBytes] @[address][offset]
"Print hex 10 bytes at rbp plus 10"
[0x5618eccbf77a]> px 10 @rbp+10
There seems to be a local array on the stack frame that takes up 78h =
120d bytes on the stack, indicated by this line :
no the local var is of type int and it takes 4 bytes on 32 bit machine
it is located at the address ebp - 0x78
the other one is again a int and is located at esp+4
the circus is probably some home grown obfuscation may be
all it does ...
The esp value at the end of the function is computed based on the ecx value stored on the stack. This value is stored immediately "above" (has higher address) the buffer which in your case has 260 bytes instead of 256 (notice sub esp, 0x104 - the reason behind this is to keep the stack aligned to 16 bytes before each function call). So why does providing 260 ...
You are sort of comparing oranges and apples.
In the first example, you are looking at the arguments passed to the main function by the C library, and they match the C standard requirements (array of char pointers).
In the second example, you are looking at the low level entry point to the binary and the parameters from the kernel, before they have been ...
Check out the memory map in the virtual file /proc/[pid]/maps (replace [pid] by the process ID of your target).
Usually it mentions memory ranges belonging to heap and stack. E.g.:
address perms offset dev inode pathname
00400000-00452000 r-xp 00000000 08:02 173521 /usr/bin/dbus-daemon
00651000-00652000 r--p 00051000 08:02 173521 ...