Windows APT Warfare E-Book

Sheng-Hao Ma

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 273

Veröffentlichungsjahr: 2023

Beschreibung

An Advanced Persistent Threat (APT) is a severe form of cyberattack that lies low in the system for a prolonged time and locates and then exploits sensitive information. Preventing APTs requires a strong foundation of basic security techniques combined with effective security monitoring. This book will help you gain a red team perspective on exploiting system design and master techniques to prevent APT attacks. Once you’ve understood the internal design of operating systems, you’ll be ready to get hands-on with red team attacks and, further, learn how to create and compile C source code into an EXE program file. Throughout this book, you’ll explore the inner workings of how Windows systems run and how attackers abuse this knowledge to bypass antivirus products and protection.
As you advance, you’ll cover practical examples of malware and online game hacking, such as EXE infection, shellcode development, software packers, UAC bypass, path parser vulnerabilities, and digital signature forgery, gaining expertise in keeping your system safe from this kind of malware.
By the end of this book, you’ll be well equipped to implement the red team techniques that you've learned on a victim's computer environment, attempting to bypass security and antivirus products, to test its defense against Windows APT attacks.

Leseprobe

Windows APT Warfare

Identify and prevent Windows APT attacks effectively

Sheng-Hao Ma

BIRMINGHAM—MUMBAI

Windows APT Warfare

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Mohd Riyan Khan

Publishing Product Manager: Neha Sharma

Senior Editor: Runcil Rebello

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Alishon Mendonca

Marketing Coordinator: Marylou De Mello

First published: March 2023

Production reference: 1100223

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-811-0

www.packtpub.com

I would like to thank all the anonymous researchers in the Cheat Engine forum; all of you taught me the reverse engineering skills of analyzing online games since my childhood. Now it is time for me to share this wonderful knowledge with others.

– Sheng-Hao Ma

Forewords

I was both happy and touched when I heard that Sheng-Hao is going to write a new book, Windows APT Warfare. He has shared his unique insights on x86, vulnerability techniques, compiler practices, and operating system principles at Black Hat USA, DEFCON, CODE BLUE, HITB, HITCON, and other conferences for many years. It’s great to see he’s willing to share his years of learning and experience in this book.

Lots of beginners might find themselves in the world of reverse engineering or cyber-attack and defense due to the research on online game cheats in the early days. Even though there are a lot of learning resources on the internet, there are more reasons to get stuck. Therefore, through this book, Sheng-Hao shares the results of his research and experiments for years so that you can enjoy learning the secrets of Windows PE design, which I think is a significant contribution to the community.

When I got the first draft of this book, I couldn’t wait to read it, but I also followed all the practical examples in the book following the chapter schedule, so that you can effectively gain Windows knowledge. But it is also a book that is difficult enough to demand repetitive practice. I would suggest to beginners that you should try to do the examples in the book, not only to deepen your impression but also to discover the author’s thoughts on the design of the examples.

This book will not only help you to build a strong foundation but also to learn how real-world cyber warriors use this knowledge to break through the defenses of the security vendors. You can use this book as a basis for malware-related analysis, software protection, or for finding exploits in applications. With the basic knowledge of this book, it can serve as a guide for your future learning path. Don’t forget to come back to the book when you’re stuck for ideas. Maybe you’ll be surprised with new inspiration when you do IDA-Pro F7, F8, or F5 numerous times late at night.

In the world of offense and defense, there is no secure system, and there is no absolute winner; both the offense and defense rely on the knowledge and practice of the basics. This book provides you with basic knowledge, the research methods of new techniques, and the way people use this basic knowledge to attack and defend. This is a good book to lay the groundwork. I recommend it to everyone.

Ziv Chang

Vice President of Automotive CyberThreat Research Lab, VicOne Inc. and Senior Director of CoreTech, TrendMicro Inc.

I had the pleasure of meeting Sheng-Hao in the summer of 2022, right after he delivered a talk at Black Hat US, which is one of the most selective industry conferences in the field of cybersecurity. As a member of the European Black Hat Review Board, I can say that only very few submissions are accepted among the many that we receive every year. I was impressed by how Sheng-Hao and his colleagues went beyond pure reverse-engineering tasks, and created tools based on symbolic execution to extract evasive behaviors from malware. Sheng-Hao and his colleagues made concrete steps toward making symbolic execution practical for the specific reversing task, which is quite challenging because symbolic execution can quickly become resource-demanding.

Back in the summer of 2022, I could already foresee that something more based on that research would come up, so I was not too surprised when I saw that he open-sourced a tool based on the research. I was pleased when I was contacted to review this book. Sheng-Hao was able to explain his findings to the audience using clear technical language, so he certainly has the required skills needed to produce educational material. I’ve been an instructor for graduate-level cybersecurity courses at Politecnico di Milano, teaching cybersecurity to thousands of students, so I know exactly what it takes not only to produce teaching material but also to convey messages in a clear way. This is what I see when reading this book: a curated selection of deep technical topics, explained at the right level, with spot-on examples, practical snippets, and references to extra resources for the avid reverser.

Reverse engineering is a blend of technical knowledge, dedication, and art. The Web is riddled with an immense amount of free learning resources and little orientation, which creates the risk that newcomers may feel overwhelmed and just walk away. Books like this one are much needed, because they select, consolidate, and create new content, infused with practical experience and real-world examples, giving a new life to fundamental techniques and resources that would otherwise remain only in the brain of the seasoned reverser.

Sheng-Hao works with TX One, a spin-off of Trend Micro, where I worked between 2016 and 2022 as a senior threat researcher. I’ve had the opportunity to collaborate with Sheng-Hao’s colleagues at TX One on various projects, some of them involving a good deal of reverse engineering of proprietary, closed-source binaries. Whoever joins TX One is either an experienced, hands-on cybersecurity researcher or will become one very quickly, because such research activities require being able to dig deep.

I can see this book in the bags of new hires, to quickly build skills, as well as on the bookshelf of experienced researchers, to review fundamentals as needed by the most challenging projects.

Federico Maggi, Ph.D., Cybersecurity Researcher, Review Board Member of Black Hat Europe

Contributors

About the author

Sheng-Hao Ma (@aaaddress1) is currently working as a threat researcher at TXOne Networks, specializing in Windows reverse engineering analysis for over 10 years. In addition, he is currently a member of CHROOT, an information security community in Taiwan. He has served as a speaker and instructor for various international conferences and organizations such as Black Hat USA, DEFCON, CODE BLUE, HITB, VXCON, HITCON, ROOTCON, Ministry of National Defense, and Ministry of Education.

I would like to thank those who supported my research, my professor Shin-Ming Cheng, and research partners, Canaan Kao and Mars Cheng. In particular, my father, Shun-Rong Ma (late), who inspired me to learn reverse engineering when we played online games during my childhood. To all the enthusiasts who motivated me to write this content and the team at Packt for their help and support throughout the process.

About the translator

Pei-Te Chen received his Ph.D. in electrical engineering from National Cheng Kung University (NCKU) in Taiwan and has been a lecturer at organizations such as the National Taiwan University of Science and Technology (NTUST) and the Hacker College Institute. His expertise lies in cryptanalysis, intrusion detection, red team exercises, and penetration testing, and he has obtained several cybersecurity licenses such as OSSTMM OPST and GIAC GXPN. He has participated in many of Taiwan’s major cybersecurity projects, such as the Local Government Information Security Operations project and the Digital National Information Security Technology Services project. He is currently working as a senior engineer at the Cybersecurity Technology Institute (CSTI) department of the Institute for Information Industry (III), where he is responsible for cybersecurity talent training.

I would like to extend my sincerest gratitude to all those who have helped me in the field of cybersecurity, particularly to Professor Chi-Sung Laih for his guidance in introducing me to the field, to Ms. Lan-Ying Jiang for her spiritual encouragement, and to Sheng-Hao Ma for the cooperation and technical discussion. Your support and advice have been invaluable in my growth as a cybersecurity professional. I am deeply grateful for your contributions and support.

About the reviewers

Ta-Lun Yen is a security researcher with interests in reverse engineering, protocol analysis, wireless security, and embedded and IoT/ICS device security. He has been a member of a Taiwanese InfoSec community, “UCCU Hacker,” and has presented various research at well-known conferences and events. Ta-Lun is currently working for TXOne Networks (Trend Micro) with a focus on offensive research.

Fyodor Yarochkin is a researcher with Trend Micro Taiwan and holds a Ph.D. from EE, National Taiwan University. An open source evangelist as well as a “happy” programmer, Fyodor has a strong interest in both offensive and defensive security. Prior to his position at Trend Micro, Fyodor spent several years as a threat analyst and over 8 years as an information security analyst responding to network security breaches and conducting remote network security assessments and network intrusion tests for the majority of regional banking, finance, semiconductor, and telecommunication organizations. Fyodor is an active member of the local security community and has spoken at a number of conferences regionally and globally.

Disclaimer

The information within this book is intended to be used only in an ethical manner. Do not use any information from the book if you do not have written permission from the owner of the equipment. If you perform illegal actions, you are likely to be arrested and prosecuted to the full extent of the law. Packt Publishing does not take any responsibility if you misuse any of the information contained within the book. The information herein must only be used while testing environments with properly written authorizations from the appropriate persons responsible.

Table of Contents

Preface

Part 1 – Modern Windows Compiler

1

From Source to Binaries – The Journey of a C Program

The simplest Windows program in C

C compiler – assembly code generation

Assembler – transforming assembly code into machine code

Compiling code

Windows linker – packing binary data into PE format

Running static PE files as dynamic processes

Summary

2

Process Memory – File Mapping, PE Parser, tinyLinker, and Hollowing

Sample programs

The memory of the static contents of PE files

NT Headers

Section Headers

PE Parser example

Dynamic file mapping

PE infection (PE Patcher) example

tinyLinker example

Examples of process hollowing

PE files to HTML

Summary

3

Dynamic API Calling – Thread, Process, and Environment Information

Sample programs

Function calling convention

Calling convention

Thread Environment Block (TEB)

Process Environment Block

Examples of process parameter forgery

Examples of enumerating loaded modules without an API

Examples of disguising and hiding loaded DLLs

Summary

Part 2 – Windows Process Internals

4

Shellcode Technique – Exported Function Parsing

Sample programs

EATs in PE

Examples of a DLL file analyzer

Dynamic crawling function in PE

Examples of writing shellcode in x86

A shellcode generator in Python

Summary

5

Application Loader Design

Import Address Table in PE

Import API analyzer example

Calling programs directly in memory

Examples of IAT hijack

DLL side-loading example

Summary

6

PE Module Relocation

Relocation table of PE

tinyLoader example

Summary

Part 3 – Abuse System Design and Red Team Tips

7

PE to Shellcode – Transforming PE Files into Shellcode

The open source project pe_to_shellcode analysis

Parsing Kernel32’s export table in x86 assembly

Getting API addresses in x86 assembly

File mapping and repairing an import table in x86

Handling relocation in x86

An example of PE to shellcode

Summary

8

Software Packer Design

What is a software packer?

Packer builder

Stub – the main program of an unpacker

Examples of software packers

Summary

9

Digital Signature – Authenticode Verification

Authenticode digital signatures

Signature verification

WinVerifyTrust under the hood

Signature data in PE files

PKCS#7 information

Examples of mock signatures

Examples of bypassing hash verification

Examples of signature steganography

Getting signed by abusing path normalization

Summary

10

Reversing User Account Control and Bypassing Tricks

UAC overview

RAiLaunchAdminProcess callback

Two-level authentication mechanism

Authentication A

Authentication B

UAC interface program, ConsentUI

Elevated privilege conditions

Improper registry configuration triggered by privilege hijacking privileges

Examples of bypassing UAC

Elevated COM Object (IFileOperation)

CMSTP arbitrary privilege elevation execution

Achieving elevated privileges through trusted path collisions

Summary

Appendix – NTFS, Paths, and Symbols

Win32 and NT path specification

DOS Path 1.0

DOS Path 2.0

Example 1

Example 2

Example 3

Example 4

Example 5

Example 6

Example 7

Example 8

Index

Other Books You May Enjoy

Preface

This is a basic book that enables you to read a single line of C code and then be able to calculate the distribution of dynamic and static memory in your head and write the executable hexadecimal content by hand on a whiteboard.

This book distills three aspects of reverse engineering, compilers, and system practice principles into a practical study of Windows cyberattacks, and explains the attack techniques from a red team perspective, which have been used by national cyber armies in recent years on the solid foundation of PE attack techniques.

This book covers practical examples of malware and online game hacking, such as EXE infection, shellcode development, software packer, UAC bypass, path parser vulnerabilities, and digital signature forgery.

Who this book is for

This book is targeted at Windows engineers, malware researchers, network administrators, and ethical hackers who want to apply their skills to Windows Exploit, kernel practice, and reversing engineering. You need to have hands-on experience with reversing engineering and basic C/C++ knowledge. The book will have self-contained bite-size recipes for you to pick and choose the right one to solve your business problems.

What this book covers

Chapter 1, From Source to Binaries – The Journey of a C Program, includes the basics of how compilers package EXE binaries from C code and techniques for system processes to run dynamically as processes.

Chapter 2, Process Memory – File Mapping, PE Parser, tinyLinker, and Hollowing, explains the file mapping process, builds a compact compiler, attaches malware into system services, and infects game programs.

Chapter 3, Dynamic API Calling – Thread, Process, and Environment Information, elaborates on the basics of Windows API calls in x86 assembly.

Chapter 4, Shellcode Technique – Exported Function Parsing, explains how to get the desired API address from loaded DLL modules.

Chapter 5, Application Loader Design, explains how a simple application loader can execute EXE files in memory without creating any child process.

Chapter 6, PE Module Relocation, discusses the relocation design of PE modules. We will learn to manually analyze PE binary and implement dynamic PE module relocation, allowing any program to be loaded into memory.

Chapter 7, PE to Shellcode – Transforming PE Files into Shellcode, explains how to write a lightweight loader in x86 assembly that can be used to convert any EXE file to shellcode.

Chapter 8, Software Packer Design, develops a minimalist software packer.

Chapter 9, Digital Signature – Authenticode Verification, explores Windows Authenticode specification, reverse-engineering the signature verification function, WinVerifyTrust, and how to hijack well-known digital signatures.

Chapter 10, Reversing User Account Control and Bypassing Tricks, reverse-engineers UAC design to understand the internal workflow of UAC protection and learn the techniques used by threat actors to bypass UAC design for privilege elevation.

The Appendix – NTFS, Paths, and Symbols, explores the file path resolve principle of Windows and the use of special paths to attack in the wild.

To get the most out of this book

You will need a Windows environment to analyze the PE structure and practice the book’s multiple labs and install TDM-GCC and Visual Studio C++ to test the book’s examples. For simplicity in explanation, most of the examples in this book are shown in 32bit, but the approaches are generic and can be modified to run in 64bit.

Software/hardware covered in the book

Operating system requirements

TDM-GCC

Windows

Visual Studio Community (C++)

PE-bear

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Windows-APT-Warfare. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/LG0j1

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “We can get the first IMAGE_BASE_RELOCATION structure at the address of the relocation table.”

A block of code is set as follows:

#include <Windows.h> Int main(void) { MessageBoxA(0, "hi there.", "info", 0); return 0; }

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

#include <Windows.h> Int main(void) { MessageBoxA(0, "hi there.", "info", 0); return 0; }

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Its function is to pop up a window with the info title and the hi there content.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Windows APT Warfare, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-80461-811-0

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1 – Modern Windows Compiler

In this section, you will learn the principles of C++ program execution on Windows systems from a binary perspective and gain the necessary knowledge to analyze Windows programs by hand. This section will cover topics such as how Windows analyzes program files and mounts program files to memory, tampering the mounted program of the benign process, and the basics of API function calling.

This section has the following chapters:

Chapter 1, From Source to Binaries – The Journey of a C ProgramChapter 2, Process Memory – File Mapping, PE Parser, tinyLinker, and HollowingChapter 3, Dynamic API Calling – Thread, Process, and Environment Information

1

From Source to Binaries – The Journey of a C Program

In this chapter, we will learn the basics of how compilers package EXE binaries from C code and techniques for system processes to execute. These basic concepts will build your understanding of how Windows compiles C into programs and links them across system components. You will also understand the program structure and workflow that malware analysis and evasion detection should follow.

In this chapter, we’re going to cover the following main topics:

The simplest Windows program in CC compiler – assembly code generationAssembler – transforming assembly code into machine codeCompiling codeWindows linker – packing binary data into Portable Executable (PE) formatRunning compiled PE executable files as dynamic processes

The simplest Windows program in C

Any software is designed with some functionality in mind. This functionality could include tasks such as reading external inputs, processing them in the way the engineer expects them to be processed, or accomplishing a specific function or task. All of these actions require interaction with the underlying operating system (OS). A program, in order to interact with the underlying OS, must call system functions. It might be nearly impossible to design a meaningful program that does not use any system calls.

In addition to that, in Windows, the programmer, when compiling a C program, needs to specify a subsystem (you can read more about it at https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem); windows and console are probably the two of the most common ones.

Let’s look at a simple example of a C program for Windows:

#include <Windows.h> Int main(void) { MessageBoxA(0, "hi there.", "info", 0); return 0; }

Presented here is the most simplified C program for Windows. Its purpose is to call the USER32!MessageBox() function at the entry point of the main() function to pop up a window with the info title and the hi there content.

C compiler – assembly code generation

What is intriguing to understand in the previous section is the reason the compiler understands this C code. First, the main task for the compiler is to convert the C code into assembly code according to the C/C++ calling convention, as shown in Figure 1.1:

Figure 1.1 – x86 calling convention

Important note

For convenience and practicability, the following examples will be presented with x86 instructions. However, the methods and principles described in this book are common to all Windows systems, and the compiler examples are based on GNU Compiler Collection (GCC) for Windows (MinGW).

As different system functions (and even third-party modules) have the expected in-memory access to the memory level of the assembly code, there are several mainstream application binary interface (ABI) calling conventions for ease of management. Interested readers can refer to Argument Passing and Naming Conventions by Microsoft (https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions).

These calling conventions mainly deal with several issues:

The position where the parameters are placed in order (e.g., on a stack, in a register such as ECX, or mixed to speed up performance)The memory space occupied by parameters if parameters are need to be storedThe occupied memory to be released by the caller or callee

When the compiler generates the assembly code, it will recognize the calling conventions of the system, arrange the parameters in memory according to its preference, and then call the memory address of the function with the call command. Therefore, when the thread jumps into the system instruction, it can correctly obtain the function parameter at its expected memory address.

Take Figure 1.1 as an example: we know that the USER32!MessageBoxA function prefers WINAPI calling conventions. In this calling convention, the parameter content is pushed into the stack from right to left, and the memory released for this calling convention is chosen by the callee. So after pushing 4 parameters into the stack to occupy 16 bytes in the stack (sizeof(uint32_t) x 4), it will be executed in USER32!MessageBoxA. After executing the function request, return to the next line of the Call MessageBoxA instruction with ret 0x10 and release 16 bytes of memory space from the stack (i.e., xor eax, eax).

Important note

The book here only focuses on the process of how the compiler generates single-chip instructions and encapsulates the program into an executable file. It does not include the important parts of advanced compiler theory, such as semantic tree generation and compiler optimization. These parts are reserved for readers to explore for further learning.

In this section, we learned about the C/C++ calling convention, how parameters are placed in memory in order, and how memory space is released when the program is finished.

Assembler – transforming assembly code into machine code

At this moment, you may notice that something is not quite right. The processor chips we use every day are not capable of executing text-based assembly code but are instead parsed into the machine code of the corresponding instruction set to perform the corresponding memory operations. Thus, during the compiling process, the previously mentioned assembly code is converted by the assembler into the machine code that can be understood by the chip.

Figure 1.2 shows the dynamic memory distribution of the 32-bit PE:

Figure 1.2 – 32-bit PE memory layout

Since the chip cannot directly parse strings such as hi there or info, data (such as global variables, static strings, global arrays, etc.) is first stored in a separate structure called a section. Each section is created with an offset address where it is expected to be placed. If the code later needs to extract resources identified during these compilation periods, the corresponding data can be obtained from the corresponding offset addresses. Here is an example:

The aforementioned info string can be expressed as \x69\x6E\x66\x6F\x00 in ASCII code (5 bytes in total with null at the end of the string). The binary data of this string can be stored at the beginning of the .rdata section. Similarly, the hi there string can be stored closely after the previous string at the address of the .rdata section at offset +5.In fact, the aforementioned call MessageBoxA API is not understood by the chip. Therefore, the compiler will generate an Import Address Table struct, which is the .idata section, to hold the address of the system function that the current program wants to call. When needed by the program, the corresponding function address can be extracted from this table, enabling the thread to jump to the function address and continue executing the system function.Generally speaking, it is the compiler’s practice to store the code content in the .text section.Each individual running process does not have just one PE module. Either *.EXE or *.DLL mounted in the process memory is packaged in PE format.In practice, each module loaded into the memory must be assigned an image base address to hold all contents of the module. In the case of a 32-bit *.EXE, the image base address would normally be 0x400000.The absolute address of each piece of data in the dynamic memory will be the image base address of this module + the section offset + the offset of the data on the section. Take the 0x400000 image base address as an example. If we want to get the info string, the expected content will be placed at 0x402000 (0x400000 + 0x2000 + 0x00). Similarly, hi there would be at 0x402005, and the MessageBoxA pointer would be stored at 0x403018.

Important note

There is no guarantee that the compiler will generate .text, .rdata, and .idata sections in practice, or that their respective uses will be for these functions. Most compilers follow the previously mentioned principles to allocate memory. Visual Studio compilers, for example, do not produce executable programs with .idata sections to hold function pointer tables, but rather, in readable and writable .rdata sections.

What is here is only a rough understanding of the properties of block and absolute addressing in the dynamic memory; it is not necessary to be obsessed with understanding the content, attributes, and how to fill them correctly in practice. The following chapters will explain the meaning of each structure in detail and how to design it by yourself.

In this section, we learned about the transformation to machine code operations during program execution, as well as the various sections and offsets of data stored in memory that can be accessed later in the compiling process.

Compiling code

As mentioned earlier, if the code contains chip-incomprehensible strings or text-based functions, the compiler must first convert them to absolute addresses that the chip can understand and then store them in separate sections. It is also necessary to translate the textual script into native code or machine code that the chip can recognize. How does this work in practice?

In the case of Windows x86, the instructions executed on the assembly code are translated according to the x86 instruction set. The textual instructions are translated and encoded into machine code that the chip understands. Interested readers can search for x86 Instruction Set on Google to find the full instruction table or even encode it manually without relying on a compiler.

Once the compiler has completed the aforementioned block packaging, the next stage is to extract and encode the textual instructions from the script, one by one, according to the x86 instruction set, and write them into the .text section that is used to store the machine code.

As shown in Figure 1.3, the dashed box is the assembly code in the text type obtained from compiling the C/C++ code:

Figure 1.3 – Native code generation

You can see the first instruction is push 0, which pushes 1 byte of data onto the stack (saved as 4 bytes), and 6A 00 is used to represent this instruction. The push 0x402005 instruction pushes 4 bytes onto the stack at once, so push 68 50 20 40 00 is used to achieve a longer push. call ds:[0x403018] is the address of the 4 bytes, and the long call of machine code, FF 15 18 30 40 00, is used to represent this instruction.

Although Figure 1.3 shows the memory distribution of the dynamic msgbox.exe file, the file produced by the compiler is not yet an executable PE file. Rather, it is a file called a Common Object File Format (COFF) or an object file, as some people call it, which is a wrapper file specifically designed to record the various sections produced by the compiler. The following figure shows the COFF file obtained by compiling and assembling the source code with the gcc -c command, and viewing its structure with a well-known tool, PEview.

As shown in Figure 1.4, there is an IMAGE_FILE_HEADER structure at the beginning of the COFF file to record how many sections are included:

Figure 1.4 – COFF

At the end of this structure is a whole array of IMAGE_SECTION_HEADER to record the current location and size of the content of each section in the file. Closely attached at the end of this array is the substantive content of each section. In practice, the first section will usually be the content of the .text section.

In the next stage, the Linker