Challenge Writeup

When unpacking and executing the binary both via the command line and as an GUI application, nothing happens. So let's load the binary into IDA. Whilst analyzing the main function we see that we are expected to supply an argument when executing the binary. If we supply one argument, that argument will be used as a parameter for the function sub_401000. If we try executing the binary via the command line again, and supply an argument, we receive two strings and the application exits. Time to dive in deeper.

Jumping into the function, the rather long sequential mov instructions are rather curious and deserve closer analysis. In total, 36 bytes get loaded into ebp+var_28 up and until ebp+var_5. This is also exactly the length of the loop which occurs a little later. In this loop, for each iteration a memory page is allocated using VirtualAlloc with a size of 1000 bytes. The page is set to PAGE_EXECUTE_READWRITE. The return value of the call to VirtualAlloc is stored in [ebp+var_34], which will be called later. In between the page creation and subsequent call, the allocated memory page is filled as follows: for the nth round of iteration, the nth byte from the user's input is taken and added to the nth byte of the previously allocated 'string'. The resulting byte is then written to the memory page. As this page is then executed, and becomes inherently part of the program, any invalid instructions will cause the program to crash. So we have to come up with an ingenious way of ensuring this page does not crash. However, we are only limited to one specific byte for each iteration.
Therefore, we have to identify a byte that serves as a thrustworthy opcode that is unlikely to crash if it is executed. One opcode that immediately comes to mind is the opcode 0xC3, which is the RET instruction which will return execution to the calling program, as such being quite harmless. Based on the input constraints and length check, we determine that the maximum length of the input string is 30. So we can sort of brute force our way to ensure the output byte is always C3. Eventually, you will end up with the following bytes, which all appear within ASCII range. Based on that we can conclude that the input string needs to be: see three, C3 C3 C3 C3 C3 C3 C3! XD. Eventually we end up with the flag for this challenge i_w0uld_l1k3_to_RETurn_this_joke@flare-on.com. And with that, we have completed the fourth Flare-On challenge!