3 ms·
So, I have a meta question: how does one go doing writeups like this? I mean, I kinda tried once post-factum, but I feel details are already starting to get blu
by akavel 5y ago
So, I have a meta question: how does one go doing writeups like this? I mean, I kinda tried once post-factum, but I feel details are already starting to get blurry at that point in my memory (esp. of all the failed paths, but also byte offsets, checked fields, Google searches, etc.), as well as the order of events. OTOH, I can hardly imagine doing even such detailed screenshots on every step while actually hacking, as I assume it would slow me down like crazy and most probably break my flow. So, what's the trick??
- swarnie 5y agoFor work i use a tool called Snagit to queue up screen captures then a pen and paper to scribble notes. The two together along with my memory and the order of open tabs is enough to put together "good enough" documentation showing the discovery and fixing process.
- akavel 5y agoThanks!! I need to check the tool then!
- thrdbndndn 5y agoI wrote this style of blog all the time. When doing any kind of "discovery", I always just open notepad.exe and write some keywords, short notes, and reference URLs (most important) along the way, not specifically for blogging, but just need them for my own process. Once done, and feel like I can write a blog about it, I would redo the whole thing (and take the screenshots) for the blog article.
- akavel 5y agoThanks for the reply!! So basically working notes, makes sense, and I vaguely thought about that too; although it would appear they somehow don't seem to work that well in my case for this purpose; I need to think about it. As to the "redo" step, that is something I didn't think of, but sounds like a really good idea, thank you!
- Slortibort 5y agoHi, I'm the author. I write a lot of technical software docs for a living so I'm no stranger to writing, but this was my first attempt at such an informal writeup. I started trying to fix it on a Friday evening and gave up after I couldn't get the "abort -> No Operation" thing. When I came back a couple of days later, I realised how I was going to proceed, but wanted to write it up. I made sure the thread I was pulling made sense (and thus I was confident I'd get to the end of this), stopped, and wrote the writeup to that point retrospectively. I also went back and recreated some of the screenshots. From then on I played with the software for a bit until I "hit a breakthrough", stopped, and wrote the story and took some screenshots, then worked on the software until the next "breakthrough". I wanted this doc to record offsets and methodology so I made sure to include that wherever I could. I also used the document as a "rubber-duck debugging" aide, writing it for someone unfamiliar to the project. I then polished/edited it (rushedly, without too much care) the day after and put it up. You can see my shift in methodology a few times where I mess up the past and present tense and with how some bits have considerably more detail than others. As this is my first, I don't know if I'd do it the same way again. I've got a HW hacking project on the go and while I've taken loads of pictures, I think I'll probably be writing that up fully retrospectively.
- akavel 5y agoThanks a lot for the reply!! FWIW, I didn't notice the change of tenses or other stuff at all, found the whole piece very engaging and interesting! (Though admittedly skimmed some details that I didn't care enough about :P) As for rubber-duck debugging, that's a benefit I didn't think of, thanks!