Choosing a DLL for Read-only Inspection

Table of Contents

• Windows DLL structure (on disk)
• How DLLs relate to the kernel
• Where system DLLs live
• Verified lab inventory
• Choosing a practice target

Windows DLL structure (on disk)

0. Purpose

Before you pick amsi.dll vs version.dll, you need a mental model of what any DLL file actually is — a Portable Executable (PE) on disk that the loader maps into process memory.

1. High level (explain like I'm five)

A DLL is a shared instruction book stored as a file. Programs do not copy the whole book into themselves — they borrow pages from it when needed.

On disk, that book has:

• A cover label (headers — file type, CPU architecture, where sections start)
• Chapters (sections — code, read-only data, writable data)
• A table of contents for lending out (exports — functions other programs may call)
• A shopping list of other books (imports — other DLLs and APIs this file needs)

.exe and .dll use the same PE format. The difference is mainly how the loader uses them: an EXE is the program entry point; a DLL is a library module loaded into an already-running process.

2. Deep breakdown — PE layout

Every inbox DLL under %windir%\System32\ follows the same skeleton. When you open a copy in PE-bear or Ghidra, read in this order:

flowchart TD
  DOS[DOS / MZ header
e_magic = MZ] -->|e_lfanew| NT[NT headers
PE signature]
  NT --> FH[File header
machine, characteristics]
  NT --> OH[Optional header
image base, subsystem, entry]
  OH --> DD[Data directories]
  DD --> EXP[Export table]
  DD --> IMP[Import table]
  DD --> RES[Resources]
  DD --> SEC[Security / Authenticode]
  NT --> ST[Section table]
  ST --> TEXT[.text — executable code]
  ST --> RDATA[.rdata — read-only constants]
  ST --> DATA[.data — writable globals]
  ST --> REL[.reloc / .pdata — loader fixups]

Key terms:

Full header walkthrough: Portable Executable Structure.

How DLLs relate to the kernel

0. Purpose

Understand which DLLs talk to the kernel, which stay in user mode, and why that matters when you pick an inspection target.

1. High level (explain like I'm five)

Windows splits work into two floors:

• User mode (Ring 3) — your apps, PowerShell, browsers, and most DLLs in System32
• Kernel mode (Ring 0) — the real boss: ntoskrnl.exe (the Windows kernel), drivers, hardware access

User programs cannot walk upstairs directly. They must ask through a reception desk — a chain of DLLs that ends in a syscall (a controlled door into the kernel).

Most DLLs you will inspect (amsi.dll, version.dll, crypt32.dll) live on the user-mode floor. They may request kernel services, but they are not the kernel.

2. Deep breakdown — the call chain

flowchart TB
  subgraph ring3 [User mode — Ring 3]
    APP[Application
powershell.exe, your.exe]
    SPEC[Specialty DLLs
amsi.dll, crypt32.dll, sspicli.dll]
    WIN32[Win32 surface
kernel32.dll, advapi32.dll, user32.dll]
    NTDLL[Native API gateway
ntdll.dll]
  end

  subgraph ring0 [Kernel mode — Ring 0]
    KERN[ntoskrnl.exe
Windows kernel]
    DRV[Drivers .sys]
  end

  APP --> SPEC
  APP --> WIN32
  SPEC --> WIN32
  SPEC --> NTDLL
  WIN32 --> NTDLL
  NTDLL -->|syscall instruction| KERN
  KERN --> DRV

Typical path for a privileged operation (allocate memory, open a process, read a file):

1. App calls VirtualAlloc in kernel32.dll (Win32)
2. kernel32 calls NtAllocateVirtualMemory in ntdll.dll (NT API)
3. ntdll executes syscall → CPU enters kernel mode
4. ntoskrnl.exe performs the work and returns an NTSTATUS
5. Result unwinds back to the application

See: Syscalls Flow and Syscalls Deep dive.

How the loader wires DLLs together

When a process starts (or calls LoadLibrary):

1. NT loader (ntdll + kernel) maps the EXE and required DLLs into the process address space
2. The PEB (Process Environment Block) records which modules loaded and at which base addresses — see PEB / TEB
3. The loader resolves imports — fills in pointers to exported functions from dependency DLLs
4. For DLLs with DllMain, the loader runs attach logic (user-mode code — another reason to inspect read-only first)

Why this matters for target selection:

64-bit vs 32-bit on one machine:

Where system DLLs live

Choosing a practice target

Now that you know what a DLL is and where the kernel sits, use the sections below to pick a file that matches your learning goal.

Why not start with kernel32.dll?

Almost every Windows program loads kernel32.dll and ntdll.dll. They are foundational — and enormous. For your first passes you want:

• A small enough export surface to finish in one sitting
• Clear Microsoft documentation for at least some exports
• A DLL you can see load in Process Explorer without exotic setup
• A file that teaches the workflow, not drowning you in unrelated APIs

amsi.dll was chosen for the walkthrough because it hits that sweet spot and connects to script-scanning / defensive-component literacy. It is not automatically the best first DLL for everyone.

Verified lab inventory (192.168.50.252)

amsi.dll on this host (extra checks):

MpClient.dll (Defender) — not in System32:

Reproduce on any lab host:

# Quick inventory (same script shape used on .252)
'version.dll','amsi.dll','wldp.dll','crypt32.dll','bcrypt.dll','dbghelp.dll','wer.dll','mpclient.dll' |
  ForEach-Object {
    $p = Join-Path $env:windir "System32\$_"
    [PSCustomObject]@{
      DLL = $_
      Present = Test-Path $p
      SizeKB = if (Test-Path $p) { [math]::Round((Get-Item $p).Length/1KB,1) } else { $null }
      Signature = if (Test-Path $p) { (Get-AuthenticodeSignature $p).Status } else { $null }
    }
  } | Format-Table -AutoSize

Fact-check notes (Microsoft docs + lab)

GitHub and official references (read-only learning)

Curated via agentctl research + manual verification. Use for parsing literacy, not bypass tradecraft.

Prioritization rubric

Score each candidate 0–2 per row (0 = poor fit, 2 = great fit). Prefer DLLs with higher totals for your current goal.

Gate rule: If you are studying a DLL primarily to bypass or weaken it, you are past read-only inspection — use a different lab design and explicit authorization.

Tiered candidates (inbox System32)

All paths below are %windir%\System32\ on 64-bit Windows. On 64-bit, also check the SysWOW64 copy when the architecture matters.

Tier 1 — Best first targets

Suggested path: version.dll for pure PE practice → amsi.dll or wldp.dll for defensive components.

Tier 2 — After one full pass

Tier 3 — Specialty / blue-team depth

Tier 4 — Foundational but advanced

Quick comparison in PowerShell

Run on your lab VM to compare size and signature before you commit a Saturday to Ghidra:

$candidates = @(
  'version.dll',
  'amsi.dll',
  'wldp.dll',
  'crypt32.dll',
  'bcrypt.dll',
  'dbghelp.dll',
  'wer.dll'
  # MpClient.dll is NOT in System32 — search separately:
  # Get-ChildItem 'C:\Program Files\Windows Defender','C:\ProgramData\Microsoft\Windows Defender' -Recurse -Filter MpClient.dll -EA SilentlyContinue
)

$candidates | ForEach-Object {
  $path = Join-Path $env:windir "System32\$_"
  if (-not (Test-Path $path)) {
    [PSCustomObject]@{ DLL = $_; Present = $false }
    return
  }
  $item = Get-Item $path
  $sig = Get-AuthenticodeSignature $path
  [PSCustomObject]@{
    DLL           = $_
    SizeKB        = [math]::Round($item.Length / 1KB, 1)
    FileVersion   = $item.VersionInfo.FileVersion
    Signature     = $sig.Status
    LastWriteTime = $item.LastWriteTime.ToString('yyyy-MM-dd')
  }
} | Format-Table -AutoSize

Optional — export count when dumpbin is available (Visual Studio Build Tools):

function Get-ExportCount {
  param([string]$DllPath)
  $dumpbin = Get-Command dumpbin -ErrorAction SilentlyContinue
  if (-not $dumpbin) { return $null }
  $section = & dumpbin /exports $DllPath 2>$null |
    Select-String -Pattern '^\s+\d+\s+[0-9A-F]+\s+[0-9A-F]+\s+\w' 
  if ($section) { return @($section).Count }
  return $null
}

'version.dll','amsi.dll','wldp.dll' | ForEach-Object {
  $path = Join-Path $env:windir "System32\$_"
  [PSCustomObject]@{
    DLL = $_
    ExportCount = Get-ExportCount $path
  }
} | Format-Table -AutoSize

Prefer DLLs with fewer exports when you are still learning the workflow.

Decision tree

flowchart TD
  A[Pick a learning goal] --> B{First time opening PE/Ghidra?}
  B -->|Yes| C[version.dll]
  B -->|No| D{Defensive / script-scan focus?}
  D -->|Yes| E[amsi.dll]
  D -->|No| F{Policy / code integrity?}
  F -->|Yes| G[wldp.dll]
  F -->|No| H{Certificates / trust?}
  H -->|Yes| I[crypt32.dll]
  H -->|No| J[Re-score candidates with rubric]
  C --> K[Run Part 1 workflow on a copy]
  E --> K
  G --> K
  I --> K
  J --> K

Mapping goals → starting DLL

Using a non-amsi.dll target in Part 1

The Part 1 steps are DLL-agnostic. Substitute your chosen name everywhere amsi.dll appears:

Navigation

← Windows Playbook · Part 1 walkthrough →