dece / duratoremu

Server for WoW 1.1.2.4125

DuratorEmu

This is a World of Warcraft 1.1.2.4125 tiny server emulator, written in Python, which tries to remain small, clean and understandable. The goal is to handle several player and basic stuff like chat and groups to have some fun with old school exploration techniques.

I'll repeat that again: it is a TINY emulator, which means that it is not meant for serious use (you shouldn't run a serious private server anyway). There are very few sanity checks beside basic auth, and almost nothing that a client wouldn't do is checked for. It is also not meant to be an efficient implementation. It is in Python, and nothing is done to circumvent the GIL. The threaded connections use locks pretty much anywhere because I didn't want to do a full-fledged concurrency system, and I'm not even implying that I could do that correctly. It would mean that I have to look in my reading notes about the readers-writers problems and stuff, and these notes are almost unreadable.

Use it to have fun exploring with a few friends, that's all.

Demo: https://youtu.be/uucpgeK3ILk

Installation

Dependencies:

• Python 3.4+
• MySQL
• Peewee, the Python ORM used
• A Python MySQL driver
• PyShgck

Python 3.4+

Get that from their website.

MySQL

Get a community package from their website, anything slightly recent should be fine. Once the MySQL server is running, you need to setup a database and an account to access this database.

Quick MySQL database setup:

• CREATE DATABASE durator;
• CREATE USER 'durator'@'%' IDENTIFIED BY 'durator'
• GRANT ALL PRIVILEGES ON durator.* TO 'durator'@'%' IDENTIFIED BY 'durator';

Feel free to use other credentials (but update the database code configuration), and to narrow the hostname to something more private than a full wildcard.

Peewee

Available in PyPI:

pip install peewee

Python MySQL driver

You only need one of them, preferably PyMySQL because that's the one I use, but both are available in PyPI:

pip install pymysql
# OR
pip install mysqldb

PyShgck

Grab this tag and install it with the setup batch file.

Configuration

Configure the database and create an account with the database client

cd DuratorEmu
python3 -m durator.main db
# use the commands 'install' and 'account'

Then just use start.bat, or manually start the login and world servers in different consoles:

python3 -m durator.main login
python3 -m durator.main world

Documentation

Some related projects and documentation that I used, first for Vanilla (mostly 1.12):

• WoWCore
• MangosClassic
• Ember
• Miceiken's server

More recent but still interesting sources:

• Mangos wiki
• ArcEmu wiki

Also, thanks to #modcraft for being nice folks :]

duratoremu's Issues

Code Improvements

File: durator/common/account/account.py

Analysis details:
There are no obvious security vulnerabilities in this code, but there are a few coding errors and areas for improvement:

1. The ACCOUNT_NAME_RE regular expression is not used anywhere in the code, so it can be removed.

2. The AccountStatus enum should have a more descriptive name for the NOT_READY value, as it is not clear what that means. Additionally, it would be better to use string values instead of integers, as they are more human-readable and less error-prone.

3. The srp_salt and srp_verifier fields are stored as base64-encoded strings, which is a common practice. However, the srp_verifier_as_int property converts the base64-encoded string to an integer, which may not be necessary and could cause issues if the value is too large. It would be better to keep the value as a base64-encoded string and only convert it to an integer when necessary.

4. The srp_salt_as_bytes and srp_verifier_as_int properties are not used anywhere in the code, so they can be removed.

5. The srp_salt_as_bytes and srp_verifier_as_int setters do not perform any validation on the input values, which could lead to errors or security vulnerabilities. It would be better to validate the input values before setting them.

6. The srp_salt and srp_verifier fields have a maximum length of 64, which may not be sufficient for all use cases. It would be better to use a larger maximum length or to use a binary field instead.

7. The Meta class should have a more descriptive name, such as AccountMeta.

8. The Meta class should also include an indexes attribute to define any indexes on the model, if necessary.

9. The DB object should be imported explicitly, rather than using a relative import.

dump_data in auth/ and world with pysghck

Had to fix.. from pysghck dump_data to get_data_dump

Python3.6

Security vulnerabilities and coding errors in SRP login process implementation

File: durator/auth/srp.py

This implementation of the SRP login process has several security vulnerabilities and coding errors that need to be addressed. The use of fixed modulus and generator values, os.urandom() for generating the private ephemeral, static multiplier for generating the server ephemeral, assert statements for error handling, sha1 for hashing, int.to_bytes() with a fixed length of 32 bytes, and upper() for converting strings to uppercase are all problematic. These issues need to be fixed to ensure the security of the SRP login process. This is an improvement issue.

Analysis details:
There are several security vulnerabilities and coding errors in this implementation of the SRP login process:

1. The use of a fixed modulus and generator values makes the implementation vulnerable to attacks. A better approach would be to use a random modulus and generator values for each session.

2. The use of os.urandom() for generating the private ephemeral is not a secure way to generate random numbers. A better approach would be to use a cryptographically secure random number generator.

3. The use of a static multiplier for generating the server ephemeral is not secure. A better approach would be to use a random multiplier for each session.

4. The use of assert statements for checking the presence of required attributes is not a secure way to handle errors. A better approach would be to raise specific exceptions with informative error messages.

5. The use of sha1 for hashing is not recommended as it is vulnerable to collision attacks. A better approach would be to use a stronger hash function such as sha256 or sha3.

6. The use of int.to_bytes() with a fixed length of 32 bytes for converting integers to bytes is not secure as it can lead to truncation or padding issues. A better approach would be to use a variable length encoding such as DER or ASN.1.

7. The use of upper() for converting strings to uppercase is not secure as it can lead to encoding issues. A better approach would be to use a proper encoding function such as UTF-8.

Overall, this implementation of the SRP login process needs significant improvements to be considered secure.

Insecure Encryption and Decryption Methods

File: durator/common/crypto/session_cipher.py

The encryption and decryption methods used in this code are not secure. The XOR operation used is not a strong enough encryption method and can be easily broken by an attacker. Additionally, the use of a fixed session key is a security vulnerability. A new session key should be generated for each session to ensure that even if one session is compromised, the rest of the sessions remain secure. The code does not handle errors or exceptions properly and does not follow the best practices for naming conventions in Python. The class name should be in CamelCase, and the method names should be in snake_case. The code could benefit from additional comments to explain the purpose of the different variables and methods. This issue is an improvement.

Analysis details:
There are several issues with this code that should be addressed:

1. The encryption and decryption methods are not secure. The XOR operation used in the encryption and decryption process is not a strong enough encryption method and can be easily broken by an attacker.

2. The use of a fixed session key is also a security vulnerability. Ideally, a new session key should be generated for each session to ensure that even if one session is compromised, the rest of the sessions remain secure.

3. The code does not handle errors or exceptions properly. The assert statements used to check the length of the data are not sufficient to ensure that the code will not break if the input data is not of the expected length.

4. The code does not follow the best practices for naming conventions in Python. The class name should be in CamelCase, and the method names should be in snake_case.

5. The code could benefit from additional comments to explain the purpose of the different variables and methods.

Overall, this code needs significant improvements to ensure the security and reliability of the encryption and decryption process.

works with BC or WoLK ?

is this source works with BC or WoLK ? or even posible ?

Hello, do you have a WoW 1.1.2.4125 version of the client?

I want to study how the game server is written. My World of Warcraft version is 1.12.1. There seems to be no way to connect. I have been in the authentication process, so I want to download a 1.1.2 client for testing.

Security vulnerabilities and coding errors in code

File: durator/auth/login_server.py

Analysis details:
There are a few security vulnerabilities and coding errors in this code:

1. The use of threading without proper synchronization can lead to race conditions and other concurrency issues. The code uses locks to protect shared resources, but it's important to ensure that all accesses to those resources are properly synchronized.

2. The use of simple_thread from pyshgck.conc is not a secure way to handle threading. It's better to use the threading module from the standard library, which provides more robust and secure threading functionality.

3. The use of a single configuration file for multiple realms is a security risk. Each realm should have its own configuration file to ensure that sensitive information is not shared between realms.

4. The code does not perform proper input validation on client connections. It's important to validate all input to prevent attacks such as buffer overflows and injection attacks.

5. The code does not perform proper error handling. It's important to handle errors gracefully and provide appropriate error messages to users.

6. The use of simple logging statements is not sufficient for a production environment. It's important to use a proper logging library, such as the logging module from the standard library, to ensure that log messages are properly formatted and stored.

7. The code does not perform proper authentication and authorization checks on client connections. It's important to authenticate and authorize all clients to prevent unauthorized access to sensitive resources.

8. The use of a global shutdown_flag variable is not secure. It's better to use a more secure mechanism, such as a signal handler or a dedicated shutdown thread, to handle shutdown requests.

9. The use of a single event loop for both client and realm connections can lead to performance issues and scalability problems. It's better to use a dedicated event loop for each type of connection to ensure optimal performance and scalability.

Overall, the code needs significant improvements to ensure that it is secure and reliable in a production environment.