Authenticator
Solved by me.
Challenge Info
Solution
First I did a test exec of the program. It asked for an Alien ID, then exited on fail:
Once again, ltrace appeared to show the str being compared:
I ran the program again, this time using 11337 as the Alien ID. The program asked for a PIN next, I hit enter assuming I would need to run ltrace again, but the program spat out the flag without me using any PIN.
Wait, no that wasn't it. Ok, I explored the disassembly code in radare2 and found something else I think might be the PIN:
To find this string in radare2 I opened the binary with r2 authenticator. Next, I analyzed the program by entering aaaa.
I then took a look at the flow graph mode at main by entering VV @ main. I then pressed p once to cycle to the view that only displays the calls and actions, without any of the memory pops and stuff:
This made it a lot easier to parse what was going on. As can be seen in the following screenshot, after the main function compares the Alien ID string with call sym.imp.strcmp, a result of True jumps to 0xa80. Here I could see the sym.printstr call for the PIN entry prompt, and I could see that the entry was passed into a call to sym.checkpin.
Since I knew that sym.checkpin wasn't a built in C function, I quit out of the visual mode and relaunched it at the checkpin function with VV @ sym.checkpin. I pressed p once again to drop down to that function.
Highlight selection wasn't playing nice with radare2, so I dumped out the interesting string with strings:
strings authenticator| grep 'a:Vh'
}a:Vh|}a:g}8j=}89gV<p<}:dV8<Vg9}V<9V<:j|{:
monique
After talking with my teammate, I realized I really should try using Ghidra instead of radare2. I loaded up the binary, and immediately realized the benefit of this program, as it displayed the raw decompiled C code in a window of the CodeBrowser…
Examining the function graph in Ghidra also showed the jump instruction to PIN input if Alien ID returned true to a strcmp, followed by a prompt for PIN entry, then a call to checkpin.
Double-clicking on the call checkpin instruction brought me to that function in the flow graph and the CodeBrowser window. Checking out the code in the Decompile section showed the exact operation that was occurring. Basically, for each byte in the weird string, XOR with 9. The 'U' in '9U' just means it's an unsigned int in C.
Since XOR encryption returns to the original string when it is applied twice, I can now just dump the string into CyberChef, XOR it with a key of 9, and I should get back the decrypted string. Testing this was successful.
Flag
CHTB{th3_auth3nt1c4t10n_5y5t3m_15_n0t_50_53cur3}
0x5555554009a4 = UUT
