Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.
Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.
In the Digital Forensics ecosystem, the field of memory forensics can help uncover artifacts that can’t be found anywhere else. That can include deleted files, network connections, running processes, rootkits, code injection, fileless malware and many more.
Microsoft introduced the hibernation feature in Windows 2000, allowing systems to be powered down while preserving their volatile state. This is achieved by saving RAM contents and processor context to a file called hiberfil.sys before shutting down inside the root folder of the filesystem drive. When the computer is turned on again, the system restores the volatile state from the saved file. Hibernation files are valuable for digital forensic professionals as they store temporary data from RAM to non-volatile storage, eliminating the requirement for specialized tools on the target device.
The Hibernation file structure has evolved in time. In this blog post, we will dive into the structure of the modern Windows hibernation file and propose a new translation layer for the volatility3 framework to create a raw memory image from a hibernation file.
Memory forensics is a huge help when performing an investigation and during incident response. Collecting memory images and analyzing them at scale is a challenge.
It is crucial to have the capability of examining memory images on storage platforms other than traditional file systems. With the emergence of cloud technologies, new forms of storage known as object storage have emerged. Enabling memory analysis on object storage provides exciting opportunities for innovation and advancement.
In this article, we will go through the journey of making the volatility3 framework compatible with s3 object-storage to perform memory analysis over the network. Also, the reader will discover how this new capability can and will be applied to the VolWeb 2.0 project which is still in developpement.
Disclaimer : All of the information about the volatility3 framework given in this blogpost are from my own understanding of the framework and of the project documentation1. Feel free to contact me at felix.guyard@forensicxlab.com to correct any mistake made in the explanations.
Being interested in memory forensic for a while now, I have learned a lot about the volatility3 framework. In this article, we will go through how you can use the framework's libraries to automate your memory analysis tasks and directly exploit the results. I will assume in this article that the reader has a basic understanding of how volatility3 is exploiting memory to extract evidence. If you want to learn more about volatility3, you can check the links in the "References" section.