It's just about poking at it and being persistent, until you figure everything necessary out. I've done similar reverse engineering efforts with a PoS terminal and an e-book reader/eInk display protocols. You don't know much at the beginning. Reverse engineering is mostly about persistence.

It may not always get you to the finish line, but without any documentation, persistence and some tools is all you have anyway. Knowledge is acquired during the process.

Same here! Then I remember that problem to solution only takes a sentence or two in the article, but might be few days of dead ends irl.

Absolutely.

I found myself wondering while reading the article what the guys notes look like. Does he screenshot everything and bullet point as he goes along? Or does he hit a logical stopping point and write up what worked from A-B, B-C etc.?

It's massively inspiring though.

The screenshots were definitely taken near the end of the project, while I still had it all in my head but before I started writing.

In general, the process looked like:

- Brainstorm and reverse engineer first. Have in the back of my mind that I'm writing this up, and releasing a tool, at the end. This guides my search: no your reader won't want to desolder something to use their camera, so yes you need to speak the stock Baichuan protocol.

- As I hit interesting things (like the Charlie Scrambler) start filling out a Google Keep note with keywords that will remind me of them when I'm writing.

- Take screenshots and produce other media, giving me a rough layout of waypoints that the article has to hit.

- Write the article, editorializing optional but recommended.

For me, my "writing mindset" is very different from my "engineering mindset." Some days, I can pound out a new piece of code and sometimes it will even be a decent design. Other days, I can write clear documentation. Very seldom can I do both on the same day.

These blogs kinda downplay the problem being broken down little by little.

Forensics work is the same... you don't naturally get a report that says the person did something, it's basically a list of things you try that lead to other things that lead to dead ends or an answer.

I'd like to know this too. Lately when I've been getting into something new or trying to solve a non-trivial bug/problem I've tried to keep notes as I go along in the hope of finally creating some blog content. I keep finding this extra step really slows me down and I forget to keep doing it at some points so what I end up with isn't even very good. I think this is just another skill I have not mastered (or even fundamentally grasped).

My other wonder was how long it took to go from "i've got this camera" to "i've written this software". I imagine it's on the order of weeks.

Which means you could probably do a daily journalling exercise. What you tried, what worked etc.

It's interesting to wonder about, but i imagine the dead ends, looking up docs, writing debugging tools is too boring to put in a blog

Oh for sure, it would have to be heavily edited from that complete set of notes. Although, even if my blog is so boring that I'm the only reader, I'd still be happy to have written it as that writing process will massively increase my chance of remembering what I learned.

Yeah, and the only way to get better at writing stuff up, is to write stuff up.

Just like the Wireshark dissector takes only a few sentences in the article, the author himself says it's more like a few hours to write one