Ghidra decompiler has been used to get the source code of the program.
Checking the decompiled code, user_info take up to 56 characters, whereas fgets(user_info) can write until 120 characters. Therefore, we can write more characters than the computer has allocated for the variable user_info. This seems to be the vulnerability in this program.
It seems that we need to indicate "scientifique" at the first question so that the program continue
Let's fuzz the program with in GDB to see how the stack looks like before exiting the program.
At the beginning of the stackframe (0x7fffffffe1d0), it stores the variable user_id (AAAABBBBCCCCDDD scientifique) and the buffer size of the variable is 64 characters.
At the address 0x7fffffffe210, the value of user_info is stored. The buffer size of the variable is 56 characters, but fgets(user_info, 120, stdin) allows us to write until 120 characters.
Setting the breakpoint at the instruction RET, to see the return address.
At the instruction ret, it destroys the stackframe and the return address is 0x7fffffffe258. It's in the middle of the 'A' so we can redirect to an address and takes control of the execution of the program.
We can control the execution of the program. The goal is to open a shell, so we need to find a way to execute system("/bin/sh"). This seems to be a ret2libc exploit.
puts@got = 0x601018
Address of pop rdi; rdi : 0x0000000000400763
We've just leaked the address of puts() in the global offset table.