`memo` is a `x86_64` pwn challenge with provided `libc`. `FULL RELRO` and `PIE` is disabled. At start we should provide an username (and password). We can do the following operations:  1. Insert new memo of size 0x20 up to 4  2. Edit last memo  3. View memo by index  4. Delete memo by index  5. Change Username and Password you entered before   There is also a two table (array) at `.bss` which keeps memo address and its size (<= 0x20). # VulnerabilitiesAfter analysing each function it can be seen as `memo` has multiple issues:  1. At `new_message` `0x400C52` if we enter size more than 0x20 we can overflow an heap allocation by `malloc(0x20)` with our size. **and the allocated space won't be placed in memos table**  2. At `edit_last_message` `0x400DA8` we can leak heap address after editing.  3. At `view_memo` `0x400E56` index is not checked against negative values although due to casting we can't use this infoleak.  4. At `change_password` `0x400FF6` there is an off-by-one on entering password which overwrite LSB (Least significant byte) of first (index == 0) memo size.  
As you may noticed we have heap overflow (via using `4` or `1`) but based on size limitation we should trick `fastbins` to own the challenge.   # ExploitationFirst of all we need a fastbin free chain. So allocating two chunk both of size 0x20 and then freeing the chunks in **inverse order** gives us a fastbin free chain of size `48` (**0x30**). We can then use `1` vulnerability to overflow the heap and corrupt heap so that free chain last pointer points to our arbitrary address. **But remember we should provide our pointer in such a way that it bypasses the fastbin malloc corruption checks**. To do so we should use an address with having a metadata (address-4) of size `48`. For this case i choose memo table so if i can overwrite pointers in the table i have `infoleak + write-what-where` primitive. As i described earlier we can use password since it is located just behind the table. after overwriting the second pointer in the table and using `view_memo` i have libc leak and stack leak. Due to binary compiled with `FULL RELRO` protection, we can overwrite stack or creating a fake tls_dtors struct (but due to new protection against tls_dtors and issues in some cases i choose option 1). After leaking we can overwrite the second pointer in the table again with stack address and pwn the challenge.  
You can see my [exploit](sol.py) 