# 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 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)<br>

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

  ```powershell
  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.

Here is the addition for the RedLotus Mod Analyzer as a "BONUS METHOD", formatted in the same style as the existing content:


---

# Agent Instructions: 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:

```
GET https://itzicehere.gitbook.io/redlotusguide/screensharing-minecraft-knowledge/fifth-section-specific-context-minecraft/specific-analysis-for-minecraft/forge-mod-analysis.md?ask=<question>
```

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.