A defensible screenshare workflow
Plan a focused player examination, preserve the evidence, and document the limits of a live view.
Question & scope
A screenshare is a live observation session, not a complete disk acquisition. Start with a concrete question tied to the disputed game session: a particular client, modification, executable, or installation. Agree on the material the player will show and the collection steps before asking for files. Record the game, launcher, operating-system build, account context, and session time. A narrow plan makes the examination easier to reproduce and reduces unrelated browsing.
Screenshots, exported artifacts, and collected files serve different purposes. A screenshot shows what was displayed at that moment; it does not preserve every byte or authenticate the application rendering it. An exported record can be re-examined, but only if its source and extraction method are recorded. Identify which type of evidence supports each observation rather than treating the screenshare itself as proof.
What to collect
| Source | Retain and examine |
|---|---|
| Session notes | Start/end time, timezone, stated question, participant consent and scope. |
| Environment | Game build, launcher profile, instance directory, active user context. |
| Relevant artifacts | Selected logs, mods, metadata, or execution records associated with the question. |
| Collection log | Tool names, versions, commands, files copied, and any live changes. |
Examination workflow
- Ask the player to identify the actual game instance and the disputed session before inspecting a default folder.
- Record original paths and available timestamps. Preserve selected files before opening them in tools that may modify data.
- Check identity with hashes and exact release versions; then inspect execution or behavior records appropriate to the question.
- Connect findings across independently collected sources. Keep uncertain matches separate from confirmed identities.
- End with a short observation summary, unresolved gaps, and the evidence needed for further review.
Interpretation & false positives
Launching a parser, opening a folder, restarting a game, or changing a logging option can alter the live system. Document these actions, because they may create new execution artifacts or rotate logs. A player controlling the displayed view can omit a profile, use a different instance, or show incomplete data without that fact being immediately visible. Record the boundary of what was examined.
An empty folder, a stopped process, or a single clean log is not a clean bill of health for every session. Conversely, an unfamiliar filename is not sufficient grounds for a cheating claim. State the scope of the result: for example, the selected instance contained these files at the time of collection.
Worked scenario
A player shows an empty default mods folder, but the launcher profile points to another instance. Ask for the configured instance path and inspect the corresponding logs and mod files. The first observation described the wrong directory; it did not establish the state of the active game. Preserve the profile information that connects the launcher to the examined path.
Report checklist
- The disputed session and actual instance are identified.
- Live changes and collection tools are logged.
- Each conclusion names its supporting artifact and scope.
- Private account details are redacted from shared findings.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.