Glossary/Terminology

• Exports, APIs, Functions ⇒ They’re mostly synonymous. DLLs have exported functions and the ones in ntdll, kernel32, etc. are often referred to as APIs. So talking about a DLL’s exports is probably just referring to the functions or APIs that are accessible from it.
• Windows API ⇒ The APIs available from the System32 dlls like Kernel32, ntdll, etc.
• PE ⇒ Portable executable; an EXE or DLL typically written in c/c++
• JIT Compilation ⇒ Just in time compilation; used by .NET assemblies.
• .NET Assembly ⇒ A PE written in C#. These assemblies contain MSIL instead of actual machine code (I believe in the .text section of the PE). The MSIL is compiled to machine code during runtime via JIT compilation (hence the name). Due to this, there are multiple RWX sections in memory of the assembly. Additionally, to perform the JIT compilation, the CLR must be available to the process (can be loaded in via APIs)
• CLR ⇒ Command Language Runtime. It is like a virtual machine; the thing that will do the JIT compilation for a .NET assembly.
• Marshalling ⇒ I don’t know the definition, but it usually equates to “translating” or converting, usually in the context of unmanaged to managed
• Delegates ⇒ A data structure in C#, they’re cool cause they can execute a function in memory given the location of it.

Managed vs Unmanaged

In C#, accessing memory directly is considered “unmanaged memory”, while memory that is handled by the garbage collector and CLR is considered “managed”. As an example, allocating memory via Marshal.AllocHGlobal will allocate unmanaged memory that can be written to via Marshal.Copy. Creating a byte array like byte[] bruh = new byte[] { 0x00}; will create a managed byte array that the garbage compiler will handle. Working with the Windows API involves working with unmanaged memory. To provide interoperability between these things, stuff like Pinvoke is used and the System.Runtime.InteropServices namespace.

Interop Situations ****

PE Structure

Please read 0xrick’s post for a comprehensive, detailed explanation. This is very summarized

The PE Structure contains multiple parts

• DOS HEADER ⇒ Basically says “i’m a PE”
  • 0x3c bytes in is the e_lfanew property which contain a Int32 of the distance between the base of the exe and the Nt Headers
• DOS STUB ⇒ Not relevant
• NT Headers ⇒ Contains a signature, a File Header, and the Optional Headers
  • The Optional Headers are 0x18 bytes into the NT headers. Within the Optional Headers are a lot of properties about the PE, such as the size of its code, the base of its code, and other information (helpful for loading it into memory).
    • At the end of the Optional Headers (0x70 bytes in x64) are the IMAGE_DATA_DIRECTORY structures.
      • There are up to 16 data directories, but we only care about the first one. The first one details the exports of the PE. If the PE we are walking is a DLL, it should have this.
      • An IMAGE_DATA_DIRECTORY structure has only 2 DWORD (integer) values: The first is a Virtual Address (VA) to the location of the actual data directory, and the 2nd is the size of the Data directory
• From here there are multiple sections here are some common ones
  • .text ⇒ Contains the executable code of the program.
  • .data ⇒  Contains the initialized data, like global variables.
  • .bss ⇒ Contains uninitialized data.
  • .rdata ⇒ Contains read-only initialized data.
  • .edata ⇒ Contains the export tables.
  • .idata ⇒ Contains the import tables.
  • .reloc ⇒ Contains image relocation information. Executables often don’t have memory address range that they want allocated to them, so theres information on how to relocate them (useful for inline PE)
  • .rsrc ⇒ Contains resources used by the program, these include images, icons or even embedded binaries.
  • .tls ⇒  (Thread Local Storage), provides storage for every executing thread of the program.