Forge Mod Analysis

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: 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):

  Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass; Invoke-Expression (Invoke-RestMethod https://raw.githubusercontent.com/HadronCollision/PowershellScripts/refs/heads/main/HabibiModAnalyzer.ps1)

  The script will typically prompt for the path to the mods folder to analyze.