Preamble
During a work trip to Washington I pulled the next read from a stack of books I checked out from my local library (I am so grateful that the libraries in my area have re-opened). Robert M. Slade’s Software Forensics: Collecting Evidence from the Scene of a Digital Crime is an easy read on a very complex topic.
Slade starts by distinguishing software forensics apart from digital forensics and network forensics; while predominantly affiliated with assessing malicious (or potentially malicious) software, it also has carved out space for identifying intellectual property theft.
From there, Slade pivots to talking about what the objectives of software forensics are. These include intent (what is the program meant to do?) and origin (who wrote this program?).
In the case of malware, those in software forensics are primarily concerned with finding out what the program does, and who wrote it.
-Robert M. Slade
With regard to origin, Slade notes that there are a variety of methodologies, including content and non-content analyses, with which can help determine attribution. To this end, Slade notes that (absent some clear explicit clues, such as comment strings in source code), there is always room for error and it can be important not to read to deeply into any one particular method. Having said that, there were some interesting parallels he draws to linguistic analysis (see cusum) and habits, such as variable naming conventions, spellings, presence/absence of recursion, etc.
The book briefly touches on some particular tools that Slade believes are promising ventures in supporting software forensics (at the time of publication, Ghidra was not yet published), but doesn’t intend to serve as a how-to. Rather, I think the author was content with providing some starting places for the reader to get hands-on, including commercial and open-source solutions.
Before closing, Slade also touches on digital forensics and the law, since there is often some overlap between the two; when assessing malware, the results of software forensics is likely to be cited as evidence in prosecuting the malware authors. Slade points out that there are complications here, especially since some considerable effort has to be made to translate the highly technical process into lay-speak for a jury.
Finally, Slade provides an exhaustive list of follow-up readings (including some of his own books) for folks interested in exploring any of the above topics in greater detail. What I found most enjoyable about this chapter was that he provided some brief synopses on each reading, along with why someone may (or may not) want to read it.
Closing Thoughts
I liked this book. At 203 pages (or 153, if you don’t include the follow-up readings Slade recommends), “Software Forensics” makes for a quick read. It isn’t a heady academic text, but it doesn’t beat around the bush in citing tangential anecdotes either. I’m unlikely to recall (or even look into using) most of the forensic tools the author lists, but I think there was value in considering the art and read-between-the-lines techniques an analyzer might employ to identify a software’s author.
Perhaps I’m romanticizing malware analysis (I do love the idea of being someone who averts the next technical disaster), but I think I need to engage with a resource that actually works through a piece of software (I guess I need to learn to love assembly?).