Full Report
The author of this post is the developer of GameFinder: a .NET library for finding games installed via different stores. Recently, EA deprecated Origins and moved to EA Desktop. While trying to add support, the author learned that EA had added some level of encryption. This post is about breaking that encryption. The author found a IS file and through it into hexdump. The beginning of it appears to be a hash and the rest of it looks like junk. They through the rest of the file into CyberChef with Shannon Entropy turned on in order to determine if the file was encrypted. Since the randomness is high, the file is likely encrypted. How is this encrypted? The author noticed that the files changed during the stopping and starting of downloads. So, they prepared a HUGE download of Apex legends and slowed down the speed to 512kb/s. At this point, they started using Process Monitor with a file on the file of interest to see what was accessing it. The only executable that turned up was EABackgroundService.exe. Even cooler, Process Monitor will show the stack at the time of execution. This allows for decrypted data to be seen and for us to identify the region of code that executes these steps. Pretty neat! From following paths in x64dbg and Ghidra, they were able to identify the functions that processed the data - hurray for debug strings! In particular, the error message "AES256 CBC encryption failed" failed was helpful. There is a function call to EVP_aes_256_cbc(), which is from the OpenSSL library. Nice! Now we know how these operations are being performed. By stepping in x64dbg around here, they could find the aes key and IV that was being used. The key appears to be hardcoded while the IV is not. They include a CyberChef setup with the encrypted data, key, IV and everything in here as well. Pretty neat reproduction steps that people can follow along with! How are is the key and IV generated? Right before the encryption function, which takes in the key and IV, the author found another function that handles this. The IV is ALWAYS constant - why even use CBC the!? SHA3_256("allUsersGenericId" + "IS") was the code used to generate the IV. The key generation is much more involved. The code "allUsersGenericId" + "IS" + "a2a0ad25aa3556c035b34ea63863794e54ad5b53" was the string used for hashing. The first two are constants but the final string looks weird. Since this is 160, it must be a SHA-1 hash. Looking into the code for the function evp_SHA1 turns up a single function. While in this function, it appears to be taking a SHA1 hash of the hardware information. Quite a bit of data was used to generate the hash: baseboard manufactuerer, serial number, bios serial number, processor ID and several more bits of information. To access this information, the author used the WMI API. With this, they could decrypt the file on any machine. The author makes a bunch of complaints about this being useless encryption. If you have control of the machine and the data has to be decrypted for use, then EVERY encryption is made; it's more about obfuscation then anything else. It took this man 4 days to figure out, which most people would just stop at.
Analysis Summary
# Research: Reverse Engineering the EA Desktop IS File Encryption
## Metadata
- **Authors:** The Master (Developer of GameFinder)
- **Institution:** Independent / GameFinder Project
- **Publication:** Personal Technical Blog / GitHub Project Analysis
- **Date:** Circa 2023 (Post-EA Origin Deprecation)
## Abstract
This research documents the reverse engineering of the "IS" configuration files used by the EA Desktop client. After EA transitioned from the Origin platform to EA Desktop, game metadata and installation paths were protected by local encryption. The author successfully identified the cryptographic algorithms, extracted the hardcoded Initialization Vector (IV), and reverse-engineered the hardware-bound key generation mechanism using dynamic analysis and static reverse engineering.
## Research Objective
The primary goal was to bypass the encryption on EA Desktop's internal files to allow the .NET library *GameFinder* to programmatically locate installed games. The research sought to answer:
1. What encryption algorithm is protecting the local game data?
2. How are the keys and IVs generated and stored?
3. Can this encryption be decrypted reliably across different hardware environments?
## Methodology
### Approach
The researcher utilized a "dynamic-to-static" pipeline:
1. **Entropy Analysis:** Used to confirm the presence of encryption.
2. **Behavioral Monitoring:** Slowed down network traffic to extend the window for observing file access in real-time.
3. **Stack Tracing:** Used to bridge the gap between file I/O and the responsible code segments.
4. **Static Analysis & Debugging:** Identifying cryptographic primitives via debug strings and stepping through execution to observe memory states.
### Dataset/Environment
- **Software:** EA Desktop Client, `EABackgroundService.exe`.
- **Target File:** The `.is` file (identified as an encrypted configuration/metadata file).
- **Environment:** Windows 10/11 with *Apex Legends* installation as the test case.
### Tools & Technologies
- **CyberChef:** For Shannon Entropy analysis and cryptographic verification.
- **Process Monitor (Sysinternals):** For file access monitoring and call stack inspection.
- **x64dbg:** For dynamic debugging and memory inspection.
- **Ghidra:** For static disassembly and decompilation.
- **WMI (Windows Management Instrumentation) API:** For recreating hardware-bound hashes.
## Key Findings
### Primary Results
1. **Encryption Standard:** The files are encrypted using **AES-256-CBC** via the OpenSSL `EVP` API.
2. **Deterministic IV:** Despite using Cipher Block Chaining (CBC) mode, the Initialization Vector is effectively constant, derived from a static string hash: `SHA3_256("allUsersGenericId" + "IS")`.
3. **Hardware-Bound Key:** The encryption key is derived from a SHA-1 hash of unique system identifiers, including the Baseboard Serial Number, BIOS Serial Number, and Processor ID.
### Supporting Evidence
- **Debug Strings:** The presence of the string `"AES256 CBC encryption failed"` within the binary pointed directly to the logic.
- **Stack Analysis:** Process Monitor revealed `EABackgroundService.exe` accessing the file, allowing the researcher to pinpoint the exact memory address of the decryption routine.
### Novel Contributions
- Identification of the specific WMI queries used by EA to fingerprint hardware for local file obfuscation.
- Demonstration that slowing down background processes (throttling download speed) is a viable technique for increasing the observability of transient file operations.
## Technical Details
The key generation process follows a specific concatenation pattern:
- **Input String:** `"allUsersGenericId" + "IS" + [Hardware_Hash]`
- **Hardware Hash:** A SHA-1 hash (160-bit) of a concatenated string containing WMI-retrieved hardware metadata.
- **Transformation:** This final concatenated string is processed to form the 256-bit AES key.
- **Implementation Flaw:** The use of a constant IV for CBC mode mitigates the primary benefit of CBC (randomness), making the encryption behave more like a deterministic obfuscation layer.
## Practical Implications
### For Security Practitioners
- This case study highlights the difference between **encryption** (protecting data from unauthorized parties) and **obfuscation** (hiding data from the owner of the machine). If the decryption key is generated on the local machine using local traits, it is fundamentally recoverable.
### For Defenders
- Software developers should be aware that debug strings (e.g., error messages) are "roadmaps" for reverse engineers.
- Using static seeds for IVs in CBC mode is a cryptographic weakness that allows for easier pattern recognition and replay attacks.
### For Researchers
- This provides a framework for analyzing other "launcher" applications (Ubisoft Connect, Battle.net) that may use similar local hardware-binding for configuration files.
## Limitations
- The research is specific to the EA Desktop client’s implementation and may break if EA updates their key derivation function (KDF) or rotates the static strings.
- The decryption requires administrative or WMI access to the target machine to replicate the hardware hash.
## Comparison to Prior Work
Unlike standard "crackme" challenges, this research dealt with a live production service. It moves beyond simple XOR obfuscation commonly found in older games to a more modern, albeit flawed, implementation of OpenSSL-based encryption.
## Real-world Applications
- **Interoperability:** Allows third-party tools (like GameFinder, Playnite, or Lutris) to detect EA games without official API access.
- **Forensics:** Provides a method for forensic analysts to read EA Desktop metadata during a digital investigation.
## Future Work
- Automating the extraction of the hardware hash via a standalone script.
- Investigating if the `allUsersGenericId` remains constant across different OS installations on the same hardware.
## References
- OpenSSL EVP Documentation: `https://www.openssl.org/docs/manmaster/man3/EVP_EncryptInit.html`
- Microsoft WMI Documentation: `https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page`