Mastering PE (Portable Executable) Files

The Portable Executable (PE) format is the file format for executables, object code, DLLs and others, used in 32-bit and 64-bit versions of Windows operating systems. Understanding the PE file format is crucial for reverse engineers, malware analysts, security researchers, and anyone interested in the inner workings of Windows programs. This article provides a detailed and comprehensive guide to mastering PE files, covering its structure, sections, and manipulation techniques.

Understanding the PE File Format

The PE file format is a complex structure designed to provide a standardized way for the operating system to load and execute programs. It’s based on the Common Object File Format (COFF), but with extensions and modifications specific to Windows. Before diving into the details, let’s establish a basic understanding of what a PE file contains.

At its core, a PE file contains the code and data necessary for a program to run. This includes the executable code itself, as well as any resources, libraries, and other dependencies that the program requires. The PE format defines how these different components are organized and accessed.

The PE file format allows the operating system to load and execute programs in a consistent and efficient manner. By adhering to the PE format, developers can ensure that their programs will run correctly on any Windows system that supports the format.

Key Components of a PE File

A PE file is composed of several key components, each serving a specific purpose. These components include:

• DOS Header: This is the first part of the PE file and contains a small DOS program. If the PE file is run on an older DOS system, this program will display a message indicating that the program requires Windows.
• PE Header: Located after the DOS Header, this header contains essential information about the PE file, such as the machine type, number of sections, timestamp, and the address of the entry point.
• Section Headers: These headers describe each section in the PE file, including its name, virtual address, size, and characteristics.
• Sections: These are the actual code and data segments of the PE file. Common sections include .text (executable code), .data (initialized data), .rdata (read-only data), .idata (import data), and .rsrc (resources).
• Import Address Table (IAT): This table contains the addresses of imported functions that the program uses from other DLLs.
• Export Address Table (EAT): This table contains the addresses of functions that the DLL exports for other programs to use.
• Resource Directory: This directory contains information about the resources embedded in the PE file, such as icons, bitmaps, and strings.

Detailed Structure of the PE File

To truly master PE files, it’s essential to understand the detailed structure of each component. Let’s examine each of these components in more detail.

The DOS Header

The DOS Header, also known as the MZ Header, is a small structure located at the very beginning of the PE file. It’s a remnant from the days of DOS and serves a dual purpose.

First, it contains a small DOS program that can be executed if the PE file is run on an older DOS system. This program typically displays a message indicating that the program requires Windows.

Second, the DOS Header contains a pointer to the PE Header. This pointer allows the operating system to locate the PE Header and begin parsing the PE file format.

The DOS Header is defined by the `IMAGE_DOS_HEADER` structure:

typedef struct _IMAGE_DOS_HEADER {      // DOS .EXE header
    WORD e_magic;                     // Magic number
    WORD e_cblp;                      // Bytes on last page of file
    WORD e_cp;                        // Pages in file
    WORD e_crlc;                      // Relocations
    WORD e_cparhdr;                   // Size of header in paragraphs
    WORD e_minalloc;                  // Minimum extra paragraphs needed
    WORD e_maxalloc;                  // Maximum extra paragraphs needed
    WORD e_ss;                        // Initial (relative) SS value
    WORD e_sp;                        // Initial SP value
    WORD e_csum;                      // Checksum
    WORD e_ip;                        // Initial IP value
    WORD e_cs;                        // Initial (relative) CS value
    WORD e_lfarlc;                    // File address of relocation table
    WORD e_ovno;                      // Overlay number
    WORD e_res[4];                    // Reserved words
    WORD e_oemid;                     // OEM identifier (for e_oeminfo)
    WORD e_oeminfo;                   // OEM information; e_oemid specific
    WORD e_res2[10];                  // Reserved words
    DWORD e_lfanew;                   // File address of new exe header
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

The most important fields in the DOS Header are `e_magic` and `e_lfanew`. `e_magic` should be equal to `0x5A4D` (‘MZ’ in ASCII), which identifies the file as a DOS executable. `e_lfanew` contains the offset to the PE Header.

The PE Header

The PE Header contains essential information about the PE file and is crucial for the operating system to load and execute the program. It consists of three parts:

1. Signature: A 4-byte value that identifies the file as a PE file. It should be equal to `0x00004550` (‘PE\0\0’ in ASCII).
2. IMAGE_FILE_HEADER: Contains general information about the PE file, such as the machine type, number of sections, timestamp, and size of the optional header.
3. IMAGE_OPTIONAL_HEADER: Contains additional information about the PE file, such as the address of the entry point, size of code and data sections, and the addresses and sizes of various data directories.

IMAGE_FILE_HEADER

The `IMAGE_FILE_HEADER` structure is defined as follows:

typedef struct _IMAGE_FILE_HEADER {
    WORD  Machine;
    WORD  NumberOfSections;
    DWORD TimeDateStamp;
    DWORD PointerToSymbolTable;
    DWORD NumberOfSymbols;
    WORD  SizeOfOptionalHeader;
    WORD  Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

Key fields in the `IMAGE_FILE_HEADER` include:

• Machine: Specifies the target machine architecture. Common values include `0x014C` (x86), `0x8664` (x64), and `0x0200` (IA64).
• NumberOfSections: Indicates the number of sections in the PE file.
• TimeDateStamp: Represents the time and date when the PE file was created.
• SizeOfOptionalHeader: Specifies the size of the `IMAGE_OPTIONAL_HEADER` structure.
• Characteristics: Contains flags that describe the characteristics of the PE file, such as whether it’s an executable or a DLL.

IMAGE_OPTIONAL_HEADER

The `IMAGE_OPTIONAL_HEADER` structure contains a wealth of information about the PE file. There are two versions of this header: `IMAGE_OPTIONAL_HEADER32` for 32-bit PE files and `IMAGE_OPTIONAL_HEADER64` for 64-bit PE files. While they share many of the same fields, there are some differences in size and layout.

Here’s a simplified representation of the `IMAGE_OPTIONAL_HEADER32` structure:

typedef struct _IMAGE_OPTIONAL_HEADER32 {
    WORD  Magic;
    BYTE  MajorLinkerVersion;
    BYTE  MinorLinkerVersion;
    DWORD SizeOfCode;
    DWORD SizeOfInitializedData;
    DWORD SizeOfUninitializedData;
    DWORD AddressOfEntryPoint;
    DWORD BaseOfCode;
    DWORD BaseOfData;
    DWORD ImageBase;
    DWORD SectionAlignment;
    DWORD FileAlignment;
    WORD  MajorOperatingSystemVersion;
    WORD  MinorOperatingSystemVersion;
    WORD  MajorImageVersion;
    WORD  MinorImageVersion;
    WORD  MajorSubsystemVersion;
    WORD  MinorSubsystemVersion;
    DWORD Win32VersionValue;
    DWORD SizeOfImage;
    DWORD SizeOfHeaders;
    DWORD CheckSum;
    WORD  Subsystem;
    WORD  DllCharacteristics;
    DWORD SizeOfStackReserve;
    DWORD SizeOfStackCommit;
    DWORD SizeOfHeapReserve;
    DWORD SizeOfHeapCommit;
    DWORD LoaderFlags;
    DWORD NumberOfRvaAndSizes;
    IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

Key fields in the `IMAGE_OPTIONAL_HEADER32` include:

• Magic: Identifies the type of optional header. `0x10B` for PE32 (32-bit) and `0x20B` for PE32+ (64-bit).
• AddressOfEntryPoint: The RVA (Relative Virtual Address) of the entry point of the program. This is the address where the operating system will begin executing the program’s code.
• ImageBase: The preferred base address where the PE file will be loaded into memory.
• SectionAlignment: The alignment of sections in memory.
• FileAlignment: The alignment of sections in the PE file on disk.
• SizeOfImage: The total size of the image in memory.
• SizeOfHeaders: The combined size of the DOS Header, PE Header, and Section Headers.
• Subsystem: Specifies the subsystem required to run the PE file, such as Windows GUI, Windows CUI, or native.
• DataDirectory: An array of `IMAGE_DATA_DIRECTORY` structures that describe the location and size of various data directories, such as the import table, export table, and resource directory.

The `IMAGE_OPTIONAL_HEADER64` structure is similar to the `IMAGE_OPTIONAL_HEADER32` structure, but it uses 64-bit addresses and sizes where appropriate. For example, the `ImageBase`, `SizeOfStackReserve`, `SizeOfStackCommit`, `SizeOfHeapReserve`, and `SizeOfHeapCommit` fields are all 64-bit values in the `IMAGE_OPTIONAL_HEADER64` structure.

Section Headers

Following the PE Header are the Section Headers. Each section header describes a section in the PE file, providing information about its name, virtual address, size, and characteristics.

The `IMAGE_SECTION_HEADER` structure is defined as follows:

typedef struct _IMAGE_SECTION_HEADER {
    BYTE  Name[IMAGE_SIZEOF_SHORT_NAME];
    union {
            DWORD PhysicalAddress;
            DWORD VirtualSize;
    } Misc;
    DWORD VirtualAddress;
    DWORD SizeOfRawData;
    DWORD PointerToRawData;
    DWORD PointerToRelocations;
    DWORD PointerToLinenumbers;
    WORD  NumberOfRelocations;
    WORD  NumberOfLinenumbers;
    DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

Key fields in the `IMAGE_SECTION_HEADER` include:

• Name: The name of the section, such as “.text”, “.data”, or “.rsrc”.
• VirtualSize: The size of the section in memory.
• VirtualAddress: The RVA of the section in memory.
• SizeOfRawData: The size of the section in the PE file on disk.
• PointerToRawData: The file offset of the section in the PE file on disk.
• Characteristics: Flags that describe the characteristics of the section, such as whether it contains code, data, or resources, and whether it’s readable, writable, or executable.

The number of section headers is specified in the `NumberOfSections` field of the `IMAGE_FILE_HEADER`. By iterating through the section headers, you can access information about each section in the PE file.

Sections

The sections are the actual code and data segments of the PE file. They are located after the Section Headers and contain the executable code, initialized data, read-only data, import data, resources, and other information required by the program.

Common sections include:

• .text: Contains the executable code of the program. This section is typically marked as read-only and executable.
• .data: Contains initialized data, such as global variables and static data. This section is typically marked as read-write.
• .rdata: Contains read-only data, such as string literals and constant values. This section is typically marked as read-only.
• .idata: Contains the import data, which describes the DLLs and functions that the program imports.
• .edata: Contains the export data, which describes the functions that the DLL exports.
• .rsrc: Contains the resources embedded in the PE file, such as icons, bitmaps, and strings.

The characteristics of each section are determined by the `Characteristics` field in the corresponding `IMAGE_SECTION_HEADER`. These characteristics control how the section is loaded into memory and how it can be accessed.

Import Address Table (IAT)

The Import Address Table (IAT) is a crucial part of the PE file format. It’s a table that contains the addresses of imported functions that the program uses from other DLLs. When the program is loaded into memory, the operating system fills in the IAT with the actual addresses of these functions.

The IAT is located in the .idata section of the PE file. The location and size of the IAT are specified in the `DataDirectory` array of the `IMAGE_OPTIONAL_HEADER`. Specifically, the `IMAGE_DIRECTORY_ENTRY_IMPORT` entry in the `DataDirectory` array points to the import directory table.

The import directory table is an array of `IMAGE_IMPORT_DESCRIPTOR` structures. Each `IMAGE_IMPORT_DESCRIPTOR` structure describes a single DLL that the program imports.

typedef struct _IMAGE_IMPORT_DESCRIPTOR {
    union {
        DWORD Characteristics;            // 0 for terminating null import descriptor
        DWORD OriginalFirstThunk;         // RVA to original unbound IAT (PIMAGE_THUNK_DATA)
    } DUMMYUNIONNAME;
    DWORD TimeDateStamp;                  // 0 if not bound,
                                          // -1 if bound, and real date/time stamp
                                          //   in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND)
                                          // O.W. date/time stamp of DLL bound to (old BIND)
    DWORD ForwarderChain;                 // -1 if no forwarders
    DWORD Name;                           // RVA to DLL name
    DWORD FirstThunk;                     // RVA to IAT (if bound this IAT contains actual addresses)
} IMAGE_IMPORT_DESCRIPTOR, *PIMAGE_IMPORT_DESCRIPTOR;

Key fields in the `IMAGE_IMPORT_DESCRIPTOR` include:

• OriginalFirstThunk: The RVA to the original Import Lookup Table (ILT). The ILT contains the names of the imported functions.
• Name: The RVA to the name of the DLL that the program imports.
• FirstThunk: The RVA to the IAT. This is the table that will be filled in with the actual addresses of the imported functions when the program is loaded into memory.

The ILT and IAT are arrays of `IMAGE_THUNK_DATA` structures. Each `IMAGE_THUNK_DATA` structure represents a single imported function.

typedef union _IMAGE_THUNK_DATA {
    DWORD  ForwarderString;      // PBYTE
    DWORD  Function;             // PBYTE
    DWORD  Ordinal;
    DWORD  AddressOfData;        // PIMAGE_IMPORT_BY_NAME
} IMAGE_THUNK_DATA, *PIMAGE_THUNK_DATA;

The `IMAGE_THUNK_DATA` structure can represent an imported function by name or by ordinal. If the most significant bit of the `Ordinal` field is set, then the function is imported by ordinal. Otherwise, the `AddressOfData` field points to an `IMAGE_IMPORT_BY_NAME` structure, which contains the name of the imported function.

typedef struct _IMAGE_IMPORT_BY_NAME {
    WORD    Hint;
    BYTE    Name[1];
} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

The `Name` field in the `IMAGE_IMPORT_BY_NAME` structure contains the name of the imported function, followed by a null terminator.

Export Address Table (EAT)

The Export Address Table (EAT) is used by DLLs to export functions for other programs to use. It contains a list of the functions that the DLL exports, along with their addresses.

The EAT is located in the .edata section of the PE file. The location and size of the EAT are specified in the `DataDirectory` array of the `IMAGE_OPTIONAL_HEADER`. Specifically, the `IMAGE_DIRECTORY_ENTRY_EXPORT` entry in the `DataDirectory` array points to the export directory table.

The export directory table is an `IMAGE_EXPORT_DIRECTORY` structure.

typedef struct _IMAGE_EXPORT_DIRECTORY {
    DWORD Characteristics;
    DWORD TimeDateStamp;
    WORD  MajorVersion;
    WORD  MinorVersion;
    DWORD Name;                           // RVA to DLL name
    DWORD Base;                           // Starting ordinal number
    DWORD NumberOfFunctions;              // Number of functions in the export table
    DWORD NumberOfNames;                // Number of functions exported by name
    DWORD AddressOfFunctions;           // RVA to the array of export addresses
    DWORD AddressOfNames;               // RVA to the array of name pointers
    DWORD AddressOfNameOrdinals;        // RVA to the array of ordinals
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

Key fields in the `IMAGE_EXPORT_DIRECTORY` include:

• Name: The RVA to the name of the DLL.
• Base: The starting ordinal number for the exported functions.
• NumberOfFunctions: The total number of functions in the export table.
• NumberOfNames: The number of functions exported by name.
• AddressOfFunctions: The RVA to the array of export addresses.
• AddressOfNames: The RVA to the array of name pointers.
• AddressOfNameOrdinals: The RVA to the array of ordinals.

The `AddressOfFunctions` field points to an array of RVAs, each of which represents the address of an exported function. The `AddressOfNames` field points to an array of RVAs, each of which represents the name of an exported function. The `AddressOfNameOrdinals` field points to an array of WORDs, each of which represents the ordinal number of an exported function.

Resource Directory

The Resource Directory contains information about the resources embedded in the PE file, such as icons, bitmaps, strings, and dialog boxes. These resources are used by the program to provide its user interface and other functionality.

The Resource Directory is located in the .rsrc section of the PE file. The location and size of the Resource Directory are specified in the `DataDirectory` array of the `IMAGE_OPTIONAL_HEADER`. Specifically, the `IMAGE_DIRECTORY_ENTRY_RESOURCE` entry in the `DataDirectory` array points to the root resource directory table.

The Resource Directory is organized as a hierarchical tree structure. Each node in the tree is represented by an `IMAGE_RESOURCE_DIRECTORY` structure.

typedef struct _IMAGE_RESOURCE_DIRECTORY {
    DWORD Characteristics;
    DWORD TimeDateStamp;
    WORD  MajorVersion;
    WORD  MinorVersion;
    WORD  NumberOfNamedEntries;
    WORD  NumberOfIdEntries;
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

Key fields in the `IMAGE_RESOURCE_DIRECTORY` include:

• NumberOfNamedEntries: The number of named entries in the directory.
• NumberOfIdEntries: The number of ID-based entries in the directory.

The entries in the resource directory can be either named or ID-based. Named entries are identified by a string, while ID-based entries are identified by an integer ID.

Each entry in the resource directory is represented by an `IMAGE_RESOURCE_DIRECTORY_ENTRY` structure.

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
    union {
        struct {
            DWORD NameOffset : 31;
            DWORD NameIsString : 1;
        } DUMMYSTRUCTNAME;
        DWORD Name;
        WORD  Id;
    } DUMMYUNIONNAME;
    union {
        DWORD   OffsetToData;
        struct {
            DWORD OffsetToDirectory : 31;
            DWORD DataIsDirectory : 1;
        } DUMMYSTRUCTNAME2;
    } DUMMYUNIONNAME2;
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

Key fields in the `IMAGE_RESOURCE_DIRECTORY_ENTRY` include:

• Name: If `NameIsString` is 0, this is the ID of the resource. If `NameIsString` is 1, this is an offset to a string containing the name of the resource.
• OffsetToData: If `DataIsDirectory` is 0, this is an offset to an `IMAGE_RESOURCE_DATA_ENTRY` structure that describes the resource data. If `DataIsDirectory` is 1, this is an offset to another `IMAGE_RESOURCE_DIRECTORY` structure.

The `IMAGE_RESOURCE_DATA_ENTRY` structure describes the resource data.

typedef struct _IMAGE_RESOURCE_DATA_ENTRY {
    DWORD   OffsetToData;
    DWORD   Size;
    DWORD   CodePage;
    DWORD   Reserved;
} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

Key fields in the `IMAGE_RESOURCE_DATA_ENTRY` include:

• OffsetToData: The offset to the resource data.
• Size: The size of the resource data.
• CodePage: The code page used to encode the resource data.

Analyzing PE Files with Tools

While understanding the PE file format is essential, it’s also important to be familiar with the tools that can help you analyze PE files. Several tools are available for this purpose, each with its own strengths and weaknesses.

PEView

PEView is a popular and free tool that allows you to view the structure of a PE file. It displays the DOS Header, PE Header, Section Headers, and other components of the PE file in a user-friendly interface. PEView also allows you to view the contents of the sections, import table, export table, and resource directory.

CFF Explorer

CFF Explorer is another powerful and free tool for analyzing PE files. It provides a more advanced interface than PEView and includes features such as a disassembler, a debugger, and a PE editor. CFF Explorer can also be used to modify PE files.

Dependency Walker

Dependency Walker is a tool that analyzes the dependencies of a PE file. It shows the DLLs that the PE file depends on, as well as the functions that the PE file imports and exports. Dependency Walker is useful for troubleshooting dependency issues and for understanding the architecture of a program.

IDA Pro

IDA Pro is a commercial disassembler and debugger that is widely used by reverse engineers and malware analysts. It is a very powerful tool that can be used to analyze even the most complex PE files. IDA Pro includes features such as a decompiler, a debugger, and a scripting language.

Radare2

Radare2 is a free and open-source reverse engineering framework. It provides a comprehensive set of tools for analyzing and manipulating PE files, including a disassembler, a debugger, and a hex editor. Radare2 is a powerful and flexible tool that can be used for a wide range of reverse engineering tasks.

Manipulating PE Files

Once you understand the structure of PE files, you can begin to manipulate them. This can be useful for a variety of purposes, such as adding or removing features, patching vulnerabilities, or customizing the behavior of a program.

However, it’s important to note that manipulating PE files can be risky. If you’re not careful, you can easily corrupt the PE file and make it unusable. It’s also important to be aware of the legal and ethical implications of modifying PE files.

Adding a Section

Adding a new section to a PE file involves several steps:

1. Locate the last section header: Find the last `IMAGE_SECTION_HEADER` in the PE file.
2. Create a new section header: Create a new `IMAGE_SECTION_HEADER` structure for the new section. Set the `Name`, `VirtualSize`, `VirtualAddress`, `SizeOfRawData`, `PointerToRawData`, and `Characteristics` fields appropriately.
3. Adjust the `SizeOfImage` in the Optional Header: Increase the `SizeOfImage` field in the `IMAGE_OPTIONAL_HEADER` to accommodate the new section.
4. Adjust `NumberOfSections` in File Header: Increase the `NumberOfSections` field in the `IMAGE_FILE_HEADER` by 1.
5. Write the new section header to the PE file: Write the new `IMAGE_SECTION_HEADER` after the last existing section header.
6. Allocate space for the section data: Allocate space in the PE file for the new section data. This should be done after the last existing section data. The `PointerToRawData` field in the new section header should point to this location.
7. Fill the section with data (optional): Fill the new section with data, such as code or resources.

Modifying the Import Address Table (IAT)

Modifying the IAT can be used to redirect function calls to different functions. This is a common technique used in malware to hook API calls and intercept program behavior.

1. Locate the IAT: Find the `IMAGE_DIRECTORY_ENTRY_IMPORT` entry in the `DataDirectory` array of the `IMAGE_OPTIONAL_HEADER`. This entry points to the import directory table.
2. Find the target DLL: Iterate through the import directory table to find the DLL that contains the function you want to modify.
3. Find the target function: Iterate through the IAT for the target DLL to find the function you want to modify.
4. Modify the IAT entry: Change the value of the IAT entry to point to the new function. This requires careful consideration of the target architecture (32-bit vs. 64-bit) and the calling conventions.

Patching Code

Patching code involves modifying the executable code of a program. This can be used to fix bugs, add features, or bypass security checks.

1. Locate the code to patch: Use a disassembler to find the code you want to modify.
2. Modify the code: Change the code to achieve the desired effect. This may involve changing opcodes, adding new instructions, or removing existing instructions.
3. Update the checksum (optional): If the PE file has a checksum, you may need to update it after modifying the code.

Security Considerations

Understanding the PE file format is crucial for security professionals. Malware often uses techniques such as packing, obfuscation, and anti-debugging to hide its code and make it difficult to analyze. By understanding the PE file format, you can better detect and analyze malware.

PE Packing

PE packing is a technique used to compress and encrypt the executable code of a program. This makes it more difficult for reverse engineers and malware analysts to analyze the program. A packed PE file typically has a small entry point that unpacks the rest of the program into memory before executing it.

Obfuscation

Obfuscation is a technique used to make code more difficult to understand. This can involve renaming variables and functions, inserting junk code, and using control flow obfuscation techniques.

Anti-Debugging

Anti-debugging techniques are used to prevent debuggers from analyzing a program. This can involve detecting the presence of a debugger, crashing the debugger, or using techniques to make it difficult to step through the code.

Conclusion

Mastering the PE (Portable Executable) file format is a challenging but rewarding endeavor. It provides a deep understanding of how Windows programs are structured and executed, which is essential for reverse engineers, malware analysts, and security researchers. By understanding the PE file format, you can better analyze and manipulate PE files, detect and analyze malware, and develop more secure software.

This article has provided a comprehensive overview of the PE file format, covering its structure, sections, and manipulation techniques. While it’s not possible to cover every aspect of the PE file format in a single article, this should provide a solid foundation for further learning and exploration. Remember to practice with various tools and techniques to solidify your understanding.

As you continue your journey to mastering PE files, always be mindful of the legal and ethical implications of your actions. Use your knowledge responsibly and for the betterment of cybersecurity.