00-offensive-low-level-security-researcher-path.md

Offensive Low-Level Security Researcher Path

Value Score: 97/100 Role: Offensive low-level study path Proof Level: Lab-routed

Date: 2026-05-18

Purpose: make the large notes tree navigable for offensive low-level security research. The priority is not "learn every OS subsystem." The priority is: after code execution, what state gives authority, memory access, execution redirection, persistence, telemetry control, or a route across a security boundary?

This file is an entrypoint. It does not replace the detailed notes; it tells you which ones deserve attention first.

Priority Rule

Read in this order:

1. Chain and objective: where the attacker or authorized agent is in the lifecycle.
2. Authority state: token, credential, privilege, handle/fd, capability, integrity, sandbox, session, namespace.
3. Memory and translation state: VAD/VMA, PTE, section/mapping, page cache, image/private mismatch, executable memory.
4. Execution and dispatch state: loader, imports/exports, callbacks, APCs, thread pools, driver dispatch, hooks, JIT/code caches.
5. IPC and broker state: named pipes, RPC, ALPC, COM, Unix sockets, inherited handles/fds, impersonation, endpoint ACLs.
6. Runtime allocation and object lifetime: heap behavior, reference counts, stale pointers, use-after-free, RAII/destructors, C++ object layout.
7. Evidence and experiments: code, debugger views, traces, logs, memory maps, handles/fds, tokens/creds, and source paths that prove the mechanism.
8. Persistence and telemetry: services, tasks, WMI/COM, registry, systemd/cron, ETW/AMSI/audit/logging, forensic evidence.
9. Vulnerability mechanics: bug classes, primitives, mitigations, reliability, exploitability constraints.
10. Hardware/firmware: DMA/IOMMU, virtualization, secure/measured boot, code integrity, hypervisor boundaries.

If a document does not help answer one of those questions, treat it as support material, not first-pass reading.

Read First

These are the highest-signal files for the offensive low-level mindset:

1. Security internals research: 0/1-click RCE+PE to agent

   Start here. It frames every mechanism by scenario stage: initial exposure, RCE, sandbox escape or PE, agent runtime, persistence, kernel/driver primitive, and evidence.

2. Low-level security component map

   Use this to separate policy checkers from real enforcers. This prevents shallow answers such as "the API blocks it" when the actual enforcer is a token, PTE, IOMMU, code-integrity policy, object ACL, or kernel-mode dispatch path.

3. Low-level security critical terms

   Keep this beside the component map when dense terms show up: PPL, SRM, handles versus object pointers, driver dispatch, IRPs, MDLs, ACPI tables, MSRs, gates, PTE states, DMA pinning, and kernel-thread/process terminology.

4. Practical concept anchors

   Use this when an abbreviation appears before you can teach it: IOMMU, page cache, VMA/VAD, PTE/PFN, IRP/MDL, LSM, RCU, eBPF, io_uring, ETW, AMSI, PPL, VBS/HVCI, CFG, and CET. It gives the expansion, owner layer, practical use, evidence path, and deeper doc/lab.

5. Attacker-relevant structures and components

   Use this as the ranked map of high-power targets: authority state, translation state, dispatch state, integrity state, telemetry state, and device/DMA state.

6. Hands-on internals labs

   Use this to prove claims with local code and tools before treating cross-platform analogies as knowledge.

7. Linux vs Windows internals

   Use this only for translation and comparison. Do not try to memorize it all before touching the security path.

8. Pick the platform spine.

   • Windows: Source-enriched Windows mechanisms, then Windows deep-understanding Q&A.
   • Linux: Linux project README, Linux source map, then Linux deep-understanding Q&A.

Windows Priority Track

Use this order for Windows offensive low-level research:

1. Source-enriched Windows mechanisms

   Baseline Executive/Object Manager/process/thread/memory/scheduler/driver/telemetry vocabulary.

2. Windows deep-understanding Q&A

   Active recall for the Windows concepts most likely to appear in interviews or research conversations.

3. Windows object handles, references, and tokens

   Highest priority for authority: handle tables, granted access, object identity, pointer references, tokens, impersonation, inherited handles, and kernel object residency.

4. Windows kernel memory, sections, privileges, and ASLR

   Highest priority for translation and memory security: sections, mapped views, file cache, pagefile-backed memory, pool choices, PEB/TEB discovery, DLL sharing, KASLR, and privilege semantics.

5. Paging, residency, page lists, and shared memory

   Read with the Windows kernel-memory note so "resident," "pageable," "swappable," "standby," "free," and "zeroed" do not blur together.

6. Process memory access and memory API flags

   Needed for cross-process access, injection/reversing permissions, VirtualAlloc*, mmap, mprotect, and related access flags.

7. Windows IPC named pipes, RPC, ALPC, and security

   Highest priority for broker/service boundaries: endpoint ACLs, SQOS/QoS, named-pipe races, RPC binding/auth, ALPC attributes, handle/view transfer, and failed impersonation.

8. Related system calls and API semantics

   Read when Win32, Native API, POSIX, and Linux syscall analogies start to blur.

9. ELF, PE, loaders, and linkers Q&A

   Required for loader abuse, DLL side-loading, manual mapping, API hashing, export walking, TLS, relocations, and process startup/destruction.

10. User-mode heaps, runtime APIs, and toolchains

    Required for heap/API layering, malloc/UCRT/HeapAlloc/VirtualAlloc, LFH, segment heap, SEH/C++ constraints, and compiler/runtime fingerprints.

11. C++ and modern C++ internals for security researchers

    Required for real-world user-mode products and drivers: vtables, destructors, RAII, smart pointers, COM-style refcounts, atomics, intrinsics, and optimizer artifacts.

12. Vulnerability research and exploitation primitives

    Read after the OS mechanism model. Primitives are only useful when you can say which authority, mapping, dispatch, or telemetry invariant they violate.

13. Flare-On Windows internals notes

    Case-study reinforcement for reversing and Windows mechanism recognition.

14. Windows low-level security resources

    Source list and external reading queue.

Lower-priority Windows support files:

• Windows long-term mastery roadmap
• Windows roadmap know-cold explanations
• Windows case-study resource map
• Local Hebrew and Digital Whisper paper reading map

Use those when you need checklist coverage, not as the main path.

Linux Priority Track

Use this order for Linux offensive low-level research:

1. Linux deep-understanding Q&A
2. Linux project README
3. Linux source map
4. Address space, mm_struct, VMAs, page tables, TLBs, and faults
5. Page cache, reclaim, pinned pages, and allocators
6. Syscall entry, exceptions, interrupts, and ELF loading
7. Bug-to-primitive reasoning and mitigations
8. Linux and Android memory internals for vulnerability research
9. Modern Linux memory manager reading map
10. Android internals
11. Architecture special cases
12. Veteran interview FAQ

Read Linux through the same offensive lens: cred, capabilities, namespaces, seccomp, fd tables, VMAs, page tables, page cache, ELF/linker behavior, eBPF/io_uring, LSM, netfilter, module/driver state, audit/logging, systemd/cron/PAM/NSS/loader persistence.

Cross-Platform Subsystem Track

Use these when a mechanism crosses platform boundaries:

1. Hands-on internals labs
2. Memory, filesystems, and network Q&A
3. Paging, residency, page lists, and shared memory
4. Process memory access and memory API flags
5. Related system calls and API semantics
6. ELF, PE, loaders, and linkers Q&A
7. C++ and modern C++ internals for security researchers
8. Mobile OS and coding interview traps Q&A
9. User-mode heaps, runtime APIs, and toolchains

Hardware, Firmware, And Architecture

Read these when the chain reaches kernel, driver, hypervisor, DMA, boot, or hardware-backed security:

1. Low-level security critical terms
2. Hardware and OS security Q&A
3. x86 privilege rings, descriptors, and syscall entry
4. ARM architecture differences

Treat these as high priority only when your research path touches PPL, SRM, privileged control state, CPL/DPL/RPL, syscall MSRs, CR registers, GDT/LDT/IDT/TSS, page tables/PTEs, DMA/IOMMU, virtualization, EL levels, x86-64 versus arm64, Secure Boot, measured boot, VBS/HVCI, PatchGuard, firmware, or device trust.

Source And Case-Study Maps

These are support maps, not first-pass reading:

• Digital Whisper issues 134-185 internals map
• Journey PDF source map
• Windows low-level security resources
• Flare-On Windows internals notes

Use them when you need a paper, case study, or source bridge for a mechanism already identified as relevant.

What To Deprioritize On First Pass

Do not start by trying to complete every roadmap or source map. Deprioritize:

• broad resource lists before mechanism notes;
• paper maps before the primary OS mechanism model;
• exploitability details before authority/memory/dispatch invariants;
• hardware/firmware unless the chain reaches those layers;
• full cross-platform comparison tables unless you are translating between Linux and Windows.

The first pass should leave you able to explain this sentence for any mechanism:

Given this execution context, this object/state controls this authority or boundary; if corrupted, confused, or reused, it yields this capability; these mitigations and evidence sources decide whether it matters on the target build.