Book Image

Mastering Malware Analysis

By : Alexey Kleymenov, Amr Thabet
Book Image

Mastering Malware Analysis

By: Alexey Kleymenov, Amr Thabet

Overview of this book

With the ever-growing proliferation of technology, the risk of encountering malicious code or malware has also increased. Malware analysis has become one of the most trending topics in businesses in recent years due to multiple prominent ransomware attacks. Mastering Malware Analysis explains the universal patterns behind different malicious software types and how to analyze them using a variety of approaches. You will learn how to examine malware code and determine the damage it can possibly cause to your systems to ensure that it won't propagate any further. Moving forward, you will cover all aspects of malware analysis for the Windows platform in detail. Next, you will get to grips with obfuscation and anti-disassembly, anti-debugging, as well as anti-virtual machine techniques. This book will help you deal with modern cross-platform malware. Throughout the course of this book, you will explore real-world examples of static and dynamic malware analysis, unpacking and decrypting, and rootkit detection. Finally, this book will help you strengthen your defenses and prevent malware breaches for IoT devices and mobile platforms. By the end of this book, you will have learned to effectively analyze, investigate, and build innovative solutions to handle any malware incidents.
Table of Contents (18 chapters)
Free Chapter
1
Section 1: Fundamental Theory
3
Section 2: Diving Deep into Windows Malware
5
Unpacking, Decryption, and Deobfuscation
9
Section 3: Examining Cross-Platform Malware
13
Section 4: Looking into IoT and Other Platforms

Stopping at the driver's entry point

Now, we should set up a debugger to intercept the moment the driver code gets executed so that we can get control over it immediately once it starts. In most cases, we don't have symbol information for the analyzed sample, so we can't use common WinDbg commands such as bp <driver_name>!DriverEntry to stop at the driver's entry point. There are several other ways this can be done, as follows:

  1. By setting unresolved breakpoints: The following command can be used to set a breakpoint that will trigger once the module is loaded:

bu <driver_name>!<any_string>
  1. Even though the debugger doesn't stop at the entry point in this case, it is possible to reach it manually. In order to do this, take the base of the driver from the console output window, add the entry point's offset to it, and then set a breakpoint. Then, remove or disable the previous breakpoint and continue execution.
  1. By breaking on the module...