We recently released a book “Practical IoT Hacking” (No Starch Press), a simple yet effective guide on how to attack (and as a result defend) the Internet of Things. The journey of writing a technical book was a long and arduous one, yet filled with valuable lessons.

Writing a (technical) book is hard

Working on the book consumed most of my free time for the past two years, as this was on top of a full-time job as a principal security engineer at Mayo Clinic. I would point out that a technical book in particular requires an inordinate amount of time so as to conduct all the prior research before even starting writing the chapters. We had to decide:

  • Hardware tools: which of them to showcase ensuring that they are readily available, relatively cheap and have a high chance of not going out of stock in the near future. For example, we wouldn’t want to force the reader to have to purchase an expensive (~$400) Saleae logic analyzer when there are other cheaper options, especially for beginners.

  • Target devices: which target devices to demonstrate the hacking techniques against. Again we had to ensure that they would be easily purchasable, cheap and would continue to be available in stock long-term

  • IoT Protocols: which ones to leave out and which ones to focus on. Those decisions were made based on the protocol’s popularity, ease of testing and also on what existing literature is out there. For example, no IoT book had ever focused on LoRa/LoRaWAN so we thought this would make for a good addition.

All of these were in constant iteration and reconsiderations were made as we were continuously testing more hardware and software tools.

Of course, apart from research, a great amount of time was spent writing the chapters themselves, creating the exercises for the readers, writing and testing the accompanying code and setting up the VM for one of the chapters.

Timeline is at least x2 what you think it is

We originally thought that the book would take about a year to write. This is almost technically true as the bulk of the research and writing of the chapters had been completed in that amount of time. However, writing the draft chapters is only half the work. The other half is collaborating with the editors to improve on the chapters through many (see point 3) cycles of:

  • Feedback on writing style: Frances Saux did a tremendous job at correcting and improving our wording (keep in mind that out of the 5 authors, only Beau is a native English speaker)
  • Comments about structure: ensuring that all concepts are introduced in a logical, coherent manner by rearranging paragraphs where it makes sense
  • Layouts: making sure Figures are referenced before they show up and that they are the proper size.
  • Technical reviews: Aaron Guzman, with whom we’ve also collaborated in the OWASP IoT project, was our technical reviewer and did a great job at pointing out errors and technical ambiguities that needed clarification
  • Pictures: making sure we take higher-quality pictures whenever they are blurry
  • Copyrights: making sure that all material, such as photos of devices, included are copyright-free
  • Self-reliance: omitting lots of hyperlinks and references and making sure the reader can understand follow-up concepts by properly introducing any dependencies early on
  • Legality: making sure that every technique we demonstrate and the way we do it is perfectly legal. We are are particularly grateful for EFF’s pro-bono consulting on these issues.

Chapters will go through many iterations

And by many we mean more than 6 each and more in some cases.

The amount of passes we did for each chapter was mercilessly high. No Starch Press are perfectionists and we are grateful for that as this increases the quality of all their books exponentially. We weren’t expecting to have to go through so many passes but the result was well-worth it. We are confident (and hopeful) that even the early access chapters will not be riddled with mistakes. Frances Saux, Dapinder Dosanjh from No Starch Press and Aaron Guzman, our technical reviewer, were there to guarantee that the outcome would be as great as it could be.

Book proposals need lots of refining

This book wasn’t to be about IoT initially - in fact, the original proposal had nothing to do with IoT hacking. The first idea proposal we sent to Bill Pollock at No Starch Press was about analyzing and attacking the authentication of network protocols. This came naturally as I had created Ncrack, the network authentication cracking tool of the Nmap project, Evangelos had contributed to it during Google Summer of Code 2017 and Paulino has been a long-time core member of the Nmap-dev community. After Bill’s feedback about expanding the breadth of the target audience, we pivoted to medical device hacking. We then pivoted again to extend our topic coverage to IoT in general (IoT being a superset of medical devices). I’ll be dedicating a separate blog post about the details of the book’s history and timeline - I believe there are valuable lessons to be demonstrated there as well.

After deciding on the overall direction of the book, we still had to revise the actual content of the chapters multiple times. As we progressed on our research of which protocols, target devices and tools to demonstrate, we had to iterate and refine each individual chapter. Being on the same page with everyone was essential - which brings me to the next point.

Coordination with co-authors is highly important

The book was a team-job. To organize we did:

  • monthly voice-call team meetings to keep track of progress
  • frequent real-time WhatsApp discussions for more urgent matters
  • use airtable to keep track of individual tasks that needed more attention
  • keep a large number of google docs for research ideas and documentation around each chapter
  • commit code on github - initially private and now public repo
  • use onedrive for live collaboration on Word documents (No Starch Press uses either docx or odt for the initial chapter drafts)

Some chapters were allocated to separate authors based on their expertise on the field but many of them were a collaborative effort. For chapters written entirely or almost entirely by one author, at least one other one would go over them to make sure we had more eyes on them and to bounce off new ideas and improvements.

A book is not a series of blog posts or papers

  • Knowledge Organization

The book should have all the information on the subject in an organized and well-structured manner. Industry whitepapers tend to omit some technical details and rarely have step by step instructions on how to perform the techniques, while research papers (academia) are very formal and tend to have a lot of fluff, boring details and theory as well as having to enumerate all relevant past research. Blog posts on the other hand tend to be quite informal and will usually touch on a subject more superficially than books. There are some exceptions though where a well-written blog-post could fit in as part of a book.

  • Accompanying Material

Projects like the OWASP IoTGoat or other exercises, challenges and demonstratios on real-world devices that can be downloaded or purchased by the user is of paramount importance for the book. A technical book where you cannot follow the examples and perform them yourself is very much pointless. The examples should be reproducible and well-tested.

  • Entertainment

We want to keep things entertaining and engage the reader, something that papers will never be able to do because of their formal character.

  • Point of Reference

Especially with ebooks, users know they’re able to open the PDF and quickly search for how to do a “upnp firewall punching attack” in a consistently reproducible manner. It is very often that when performing a web application pentest, I find myself referring to the Web Application Hacker’s Handbook for its methodologies. The same ideally will happen with our book when people want to test IoT devices.

Teaching is learning

Perhaps the most important lesson was the experience we all gained by trying to teach all the concepts in the book. Analyzing a technical subject to the point that a broad audience can easily understand it, requires a deeper understanding of its underlying mechanisms, breaking it down to its simpler constituents and explaining complex concepts in as simple a manner as possible. This made us discover our own knowledge gaps and greatly helped improve our understanding of several IoT hacking techniques.

For instance, when I was creating and testing the exercise for Chapter 7 (UART, JTAG and SWD Exploitation), I remember being surprised by some of the behaviour of the STM32F103 microcontroller family so I had to refer to the datasheet multiple times. I also had to refresh my memory on the ARM instruction set.

I realized that writing a book can be an educational experience at least (and probably even more) on par with writing research papers and presenting at conferences, which usually cover a less broad but more specialized subject. Another time I had to go through a similar process, albeit to a much lesser extent, was when I authored the video course on mastering Nmap.

Perhaps the most important lesson was the experience we all gained by trying to teach all the concepts in the book.

Conclusion

Writing “Practical IoT Hacking” has been an immensely educating and humbling experience, filled with both hardships and joy. Working on a technical book as a side-project isn’t for everyone, but if you decide to undertake that journey I can assure you it’s well worth the struggle and effort.

We hope you enjoy reading it as much as we did writing it and are eager to get your feedback so that we can improve it even more in the near future!