Live process & module inspection
Inspect process identity, parents, modules, and open resources without equating overlays or unusual names with cheats.
Question & scope
A live process view can establish what is running during an observed session. Record collection time and tool version before discussing a PID, path, command line, parent, user, module, or handle. Process IDs can be reused after termination; a PID without time and identity context is not permanent.
Process Explorer can expose relationships, loaded DLLs, and handles depending on access. Use those views to form a specific question. An overlay library, recorder, accessibility application, or security component may legitimately interact with a game process.
What to collect
| Source | Retain and examine |
|---|---|
| Process identity | PID, collection time, image path, user, and available start information. |
| Invocation context | Command line, parent identity, and relevant environment. |
| Modules and handles | Available module paths and resource references with access limits. |
| File identity | Collected hashes and signature information for relevant binaries. |
Examination workflow
- Capture observed state before stopping processes or relaunching the game.
- Resolve the executable path and parent context rather than trusting a display name.
- Inspect relevant modules and resources, retaining path and identity information.
- Compare suspicious modules with exact releases and legitimate software in the environment.
- Correlate runtime observations with logs and files, documenting views denied by access restrictions.
Interpretation & false positives
A live tool displays a moment in time. A module can load or unload between observations; a terminated process may be absent. A failure to inspect a process can reflect privilege or protection rather than concealment. Do not turn a blank panel into proof that no relevant state existed.
A DLL inside a game process is not automatically maliciously injected code. Names, signatures, and paths are identity signals, but capability and use require further examination. Parents may have exited, and current PID mappings can differ from earlier records.
Worked scenario
An unfamiliar DLL appears in the game process. Its hash and publisher information match an installed capture product, and notes confirm recording was active. Record the supported explanation. If the bytes differ from the expected release, investigate that discrepancy instead of treating every similarly named module alike.
Report checklist
- Each PID is paired with time and identity.
- Access restrictions are documented.
- Module presence is separate from a behavior claim.
- Legitimate overlays and capture products are considered.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.