Seems like we need to perform a buffer overflow. Let's first find where the buffer ends! Input several strings of increasing length, and eventually you'll find that the buffer ends at byte 20.

Therefore, we need to start modifying our input at byte 21. Test out each bye starting from byte 21, inputting a simple 1. The output doesn't seem to be very patterned. However, notice what happens when we increase each bye by 1 -- with byte 21, the output increases by 1; with byte 22, the output increases by 256; with byte 23, the output increases by 65536.

Well, if we think about how buffer overflow works, we're usually looking at the hex value of the ASCII string, not the number itself. And 1 is 0x31 in hex. Does this make sense? Let's take a look.

Input | Output | Input in hex | Input in decimal
000000000000000000001 | 49 | 0x31 | 49
0000000000000000000001 | 12592 | 0x3031 | 12337
00000000000000000000001 | 3223600 | 0x303031 | 3158065

However, there's one thing we forgot when converting from hex to decimal! Remember that memory is generally stored in little endian form. In short, for this problem, we need to reverse the order of the bytes. Watch what happens when we do this:

Input | Output | Adjusted input in hex | Input in decimal
000000000000000000001 | 49 | 0x31 | 49
0000000000000000000001 | 12592 | 0x3130 | 12592
00000000000000000000001 | 3223600 | 0x313030 | 3223600

Oh! So, all this buffer overflow is doing is converting our input into hex, and reading it in little endian. Therefore, we just need to convert our target number, 5134160, into hex, and reverse the order of the bytes!

5134160 is 0x4E5750 in hex, so our payload should be 0x50574E, i.e. PWN in ASCII.

Input 00000000000000000000PWN to get the flag!

TCP1P{ez_buff3r_0verflow_l0c4l_v4r1abl3_38763f0c86da16fe14e062cd054d71ca}