The Collective

Hey y’all. Last week we pulled a couple of all nighters investigating this, and this is what we’ve obtained so far in order to eventually prevent ourselves from getting PWNed. The program was a little janky when compiled as 32-bit, so we’ve made a safe bet to remake it as a 64-bit executable (upgrades people, upgrades!) We’ve analyzed it thoroughly… and surprise! Contrary to our expectations, there seems to be 8 bytes of padding between the buffer and correct_or_not. Also, we’ve tested the com server with netcat, telnet, as well as our own programs using sockets, and all of them seem to communicate successfully!

Oh, and one last thing: the JSON decoder in the program seems to be nitpicky beyond our expectations. If you test it yourself, make sure to send the message in this format exactly: double quotes around values, no outermost quotes around the braces. {“code”: “<your message here!>”}

Note that if you use the echo command to print this message, you must escape the double quotes with a backslash (\”).

Hey y’all. We seem to be having a buffer overflow problem with our secret com server happening at the IP address 3.13.39.253 on port 53666. It looks like certain inputs are giving people information that they should NOT be getting. We are getting PWNed. Luckily we have made it so we ban any IP that causes our server to crash. Anyone want to give me some help below is the code to where the vulnerability seems to exist?


Remember for testing that the program accepts a dictionary where the secret password is kept in an element to a JSON dictionary called “code”. Remember we don’t have to be too sure because our attackers only have 1 shot, 1 opportunity, to get into our system. They're probably going to miss their chance to blow.

It looks like you *slaps knee* really bungled this one.

Fact of the day: remember Jason? His legal name is actually .json. He is the father of all .json.

Dude I never knew his name was actually JSON. I always thought it was his call sign.