Here, i highlight the information security books i have read. This segment is new on my blog so, expect update delays.
This book is hands-down the reference for anyone interested in the field of malware analysis. Going through all the labs is mandatory in my opinion. If you are not familiar with x86/x64 assembly, don’t worry, just read. My assembly background was poor and i managed to read the whole book and do the labs with no major delays. The book overviews aspects such as:
- Types of analysis (e.g. static, dynamic) and tools (e.g. IDA, WinDbg, OllyDbg)
- User-mode/kernel-mode debugging
- Mapping of C/C++ constructions to assembly
- Windows internals: APIs, Processes/Threads, Registry, mutexes
- Malware tricks: process injection, process hollowing, system call hooking
- Encoding: Base64, XOR, Encryption
- Network protocols and indicators
- Anti-analysis: anti-VM, anti-disassembly, anti-debugging
- Shellcode (very light): PDF documents with exploits
- 64-bit malware (very light)
Personally, i have found the last two points to be a bummer. While 64-bit malware is still not that common at the time of writing of this review, i feel that a few more pages about Shellcode analysis and exploit code would be most welcome. If this is the first book you have read about malware analysis, my advice is:
- Read the theory and then do the labs. It is of most importance to create solid foundations in order to progress in this field. If you get stuck, it may be worth checking the solutions. Sometimes you go down a rabbit hole when the solution is so much simpler that you expected.
- Be proactive. Search, search, search! At the beginning you will be overwhelmed with information so it is important to understand it properly. Don’t get caught up in details though. You don’t need to know opcodes or the arguments for assembly instructions or even the arguments for API calls. Malware analysis is lighter than reverse engineering so you just need to master the art of translating an IDA graph/ chain of API calls into the answer for: what is the purpose of this function?
- Be very patient! Solid understanding and skill to analyse malware take time to obtain. Don’t be discouraged if you get stuck on one of the labs. Read the solutions and understand the line of thought.
This book is more oriented to reverse engineering in general as opposed to PMA (Practical Malware Analysis). There is only a chapter dedicated to malware analysis which i found to be very light (e.g. packing, polymorphism and metamorphism are barely scratched). A big chunk of the chapter is spent analysing a simple malware that leverages IRC for communication. Don’t be discouraged however because chapter 10 discusses anti-reversing mechanisms which are also employed by malware.
I have found the basics review (e.g. assembly 101, Windows internals, applications) to have good technical depth and to be definitely worth reading. The Windows internals parts encompass topics like memory management, synchronisation objects, high and low level APIs. Essential topics of high-level (e.g. C#/Java) and low level (e.g. C/C++) languages are also covered:
- Data structures: lists, trees and their relation with memory organisation and addressing
- Language constructs: classes and objects, inheritance, loops, variables, functions, pointers
- Low-level process/thread execution: stacks, heaps, registers, flags, API/system calls
- Compilation, decompilation and low-level instructions: bytecode, JIT compilers, branching, pipelines. Chapter 13 is a good source of information if you are into code generation and decompilation internals.
I started reading this book on Chapter 12 since i had previously spent some time looking at decompiled Android. I was expecting something similar. However, .NET employs an evaluation stack and all method calls, even for low-level stuff (e.g. add) require arguments to be pushed onto the stack. I won’t spoil the reason. Go read it 🙂 I have found this chapter to be a great starting point for MSIL analysis.
Now, regarding the practical and more in-depth reversing stuff, the book overviews three cases:
- Reversing for interoperability (Chapter 5): say you have a Windows dll with no documentation but you want to understand its internals and even leverage it on your application. You need to understand what functions are provided and what they do. This is a good chapter for you. However (and i have found the same problem on Chapter 6 and 11), i felt that the author should not have dumped large chunks of assembly code on a book. He should have focused on smaller chunks or put graphs like the ones on IDA. It becomes impossible to follow pages and pages of assembly.
- Reversing proprietary file formats (Chapter 6): this chapter is useful if you want to create a program that is able to parse files created by a proprietary algorithm and application. While this chapter suffers slightly from the same problem as Chapter 5 (non-graphed assembly), i have found it to be more readable.
- Patching and Keygenning (Chapter 11): wan’t to create cracks and keygens? this chapter is for you. The first example is followable. It is a simple crackme and the author both patches it and creates a keygen. The second example is huge both in pages and complexity. I think this example is far too complex to be put on a book since there is only one chapter dedicated to cracking. Jumping from a simple crackme to a self-defending binary worth almost twenty-pages of analysis is a bit of an overkill.
As an overall opinion for the previously referred chapters, i was expecting more guidelines instead of a few use cases. While reverse engineering is a case-by-case science, there are some approaches that work as a starting point. It would be much better to have guidelines, a use case and then practical exercises. The solutions could have been put online or at the end of the book. In my opinion, reverse engineering is about understanding the basics and then scale effort (i.e. add time and patience).
In case you like exploitation and breaking stuff, Eldad got you covered on Chapter 7. The chapter is small but packed with valuable information regarding potential means to exploit applications (e.g. overflows, type conversion errors). I would have loved some practical exercises for this one with solutions.
The book ends with three appendix chapters. I advise you to read the appendices. Appendix A is good if you want to reconstruct source code from assembly (e.g. convert a chain of jumps and condition checks into a complex if statement). Appendix C is gold in my opinion. Compiled C++ tends to be hard to read because of the virtual methods and classes. This chapter overviews the C++ constructions and their translation into assembly.
I really liked this book in general but i was expecting more practical exercises. PMA was able to nail this perfectly by striking a balance between theory and practice in a relatively small book. However, i have found this book to be more interesting in technical terms since it exposes the guts of Windows and binaries (e.g. compilation, execution, decompilation).
Hands down one of the best books i have read due to the technical depth. In my opinion, this book can be used by:
- Incident responders and malware analysts
- Reverse engineers dealing with OS internals
- Volatility developers
Depending on what you do you may consider not spending too much time with some pages or chapters. On the one hand, if you are an incident responder and/or malware analyst, you are mostly interested on Volatility’s features and commands so you will not miss much if you skip the parts where internal OS structures are described. On the other hand, if your focus is understanding OS internals to implement tools or even contribute to Volatility, you may wanna pay attention to OS structures.
Volatility is a huge beast and the amount of commands and features (specially if we dive into Volshell) are overwhelming. As a security analyst i have had the opportunity to leverage this framework many times and so my biggest advice is “Be aware of Volatility’s features and don’t worry too much about the commands”. If you have a terrible memory like mine you know that the core concepts stay there while the others can be Googled. In any case, you can put this cheat sheet on your desk (the link may change in the future).
Is the book perfect though? Not quite. As with everything else (e.g. programming, reversing, playing piano) the way to mastery is by practicing. If you work with Volatility on a daily basis, you will eventually be proficient. If on the other hand you expect good labs to practice, you will be a bit disappointed. I would expect the labs to be a set of memory samples, either real or built to test specific commands and knowledge conveyed by some chapters. I realise this is tricky and time-consuming, specially when you are dealing with rootkits and malware that erases traces of infection. In my case, i have Googled for CTF’s and Forensics’s challenges where memory samples with questions were provided. As an example you can check the samples on Volatility’s GitHub repo.