This blog is far overdue and unfortunately isn’t really a “Part 1”. The truth is, I’ve poked around with Wi-Fi Direct for several months now with mild success and many dead-ends that resulted in learning a lot. The purpose of this blog is to retrace my steps and document some resources before diving into some fun stuff for Part 2.
For this years Binary Golf Grand Prix I started off by learning to fuzz properly, use a debugger properly, and various tooling. The objective was originally to hit all of the bonus points: +1024 pts, if you submit a writeup about your process and details about the crash +1024 pts, if the program counter is all 3’s when the program crashes +2048 pts, if you hijack execution and print or return “3” +4096 pts, if you author a patch for your bug which is merged before the end of the competition Well, life happens, and I ended up using the majority of my 2 week break from work doing more important things like taking care of my sick infant son (He’s doing much better now).
Have you ever had an idea you couldn’t quite shake? Something that worms it’s way into your brain for one reason or another and just wont leave. Always on the backburner, thinking about it in the shower every day, in the bed as you go to sleep at night, zoning out in the living room, for as long as you can remember?
So far I’ve managed to have just enough reverse engineering skills as is useful to me at the time, but recently I’ve taken an interest in getting a bit more in depth. My son was ill last week and home from daycare, so I took it upon myself to take the time to watch HackadayU: Reverse Engineering with Ghidra (~4 hours).
This aims to explain and perform an example of how the Client-Puzzle-Protocol (CPP) may be implemented (almost) entirely in HTTP. Side Note: I’m _mattata on Twitter, you should give me a follow. I do stuff like this often. The Client Puzzle Protocol at a high level is a way to slow down automated bots crawling a site so that they approach the speed that humans would normally browse your site.