first of all hello everyone. I'm trying to make a private server for (wolfteam).
I am using this project on server side. I tried various clients (2007(I couldn't run xtrap files are missing),2008,2010,2012(the version I'm working now),2014,2016), I unpack the wolf.xfs file (quickbms by aligui) and put it in the client directory and replace the original (wolf.xfs) I put the folder named (wolf.xfs).
I make the server ip settings, it connects to the server without any problems, but the incoming packets were completely random, so I examined cshell.dll and saw that it mixed the cs_br_chainlist_req package with srand(Gettickcount) before sending it, then I edited it, as a result I can get fixed packets, but they are still encrypted or the server cannot read the packets properly. If anyone knows how to fix this problem, I would be very grateful.
some packet data :
Nice work, I suggest looking at CS_CH_LOGIN_REQ packet, and follow the entered data until you see it gets encrypted, then patch that function.
Request: client -> server
Acknowledge: server -> client
A list of packets with ordering based on sequence:
Login packets:
--------------------------
1. Chain list request (CS_BR_CHAINLIST_REQ).
2. Chain list Acknowledge ( CS_BR_CHAINLIST_ACK )
3. World list request (CS_BR_WORLDLIST_REQ)
4. World list acknowledge (CS_BR_WORLDLIST_ACK)
5. World info request (CS_BR_WORLDINFO_REQ)
6. World info acknowledge (CS_BR_WORLDINFO_ACK)
7. Relay list request (CS_BR_RELAYLIST_REQ)
8. Request the credentials (CS_CH_LOGIN_REQ)
9. Credentials acknowledge (CS_CH_LOGIN_ACK)
Anti hack packets:
--------------------
1. Antihack client info request (CS_CK_SEND_ANTI_HACK_CLIENTINFO_REQ)
2. Antihack server info ack (CS_CK_SEND_ANTI_HACK_SERVERINFO_ACK)
If the same input (username/password) produces the same encrypted packet, it suggests a static XOR key.
You can XOR two packets of the same login attempt to check for a static key.
Check If It's RC4 or Another Stream Cipher
If the encryption key is seeded using srand(), then it might be RC4-like.
If each packet differs even with the same input, a stream cipher is likely.
Decryption Function (XOR Based)
If encryption is a simple XOR cipher, we can attempt to brute-force the key by analyzing known plaintext (username: apolet, password: 123123, country code: 200).
for i, byte in enumerate(packet):
decrypted.append(byte ^ key[i % key_len]) # XOR with repeating key
return decrypted
# Example usage
cipher_packet = bytes.fromhex("067653d8002482820019f6a4e77f66477b0 02e2907e548db") # Example hex packet
possible_key = b"\x01\x02\x03\x04" # Try to find this through analysis
decrypted = xor_decrypt(cipher_packet, possible_key)
print(decrypted)
If RC4 is Used
If srand(GetTickCount()) influences packet data, the encryption might be RC4. You can try RC4 decryption:
Set a breakpoint at srand and rand to inspect key generation.
Use IDA Pro/OllyDbg to trace how sub_3419B310 processes the data.
Check If It's XOR or RC4
XOR encryption is easy to spot: the same key is used cyclically.
If the same login attempt produces different packets, it’s likely RC4.
Brute-force the Key If Needed
Use known plaintext (apolet123123200) to derive an XOR key.
If the same input (username/password) produces the same encrypted packet, it suggests a static XOR key.
You can XOR two packets of the same login attempt to check for a static key.
Check If It's RC4 or Another Stream Cipher
If the encryption key is seeded using srand(), then it might be RC4-like.
If each packet differs even with the same input, a stream cipher is likely.
Decryption Function (XOR Based)
If encryption is a simple XOR cipher, we can attempt to brute-force the key by analyzing known plaintext (username: apolet, password: 123123, country code: 200).
for i, byte in enumerate(packet):
decrypted.append(byte ^ key[i % key_len]) # XOR with repeating key
return decrypted
# Example usage
cipher_packet = bytes.fromhex("067653d8002482820019f6a4e77f66477b0 02e2907e548db") # Example hex packet
possible_key = b"\x01\x02\x03\x04" # Try to find this through analysis
decrypted = xor_decrypt(cipher_packet, possible_key)
print(decrypted)
If RC4 is Used
If srand(GetTickCount()) influences packet data, the encryption might be RC4. You can try RC4 decryption:
Set a breakpoint at srand and rand to inspect key generation.
Use IDA Pro/OllyDbg to trace how sub_3419B310 processes the data.
Check If It's XOR or RC4
XOR encryption is easy to spot: the same key is used cyclically.
If the same login attempt produces different packets, it’s likely RC4.
Brute-force the Key If Needed
Use known plaintext (apolet123123200) to derive an XOR key.
it was a question from 2 years ago, this has nothing to do with encryption, what I'm talking about in this regard is just used to randomize the first byte of the packet Srand().wolfteam uses an edited blowfish algorithm for encryption. thank you for your comment.
it was a question from 2 years ago, this has nothing to do with encryption, what I'm talking about in this regard is just used to randomize the first byte of the packet Srand().wolfteam uses an edited blowfish algorithm for encryption. thank you for your comment.
Sounds like the first byte of the packet is randomized using srand(GetTickCount()). You might need to reverse that first to get a consistent value.
WolfTeam uses a modified Blowfish for encryption, so you’ll have to figure out what they changed. The encryption function is probabaly near the network functions in cshell.dll. You can look for Blowfish patterns like s-boxes and p-arrays.
The key is important too—try setting a breakpoint when the game encrypts data and see what key it uses. Since it’s a modified version, they might have changed the block size, padding, or chaining mode. If you can find those changes, you should be able to decrypt the packets properly.
If you have an encrypted packet and know what it should look like decrypted, that would help a lot. Let me know what you find
Sounds like the first byte of the packet is randomized using srand(GetTickCount()). You might need to reverse that first to get a consistent value.
WolfTeam uses a modified Blowfish for encryption, so you’ll have to figure out what they changed. The encryption function is probabaly near the network functions in cshell.dll. You can look for Blowfish patterns like s-boxes and p-arrays.
The key is important too—try setting a breakpoint when the game encrypts data and see what key it uses. Since it’s a modified version, they might have changed the block size, padding, or chaining mode. If you can find those changes, you should be able to decrypt the packets properly.
If you have an encrypted packet and know what it should look like decrypted, that would help a lot. Let me know what you find
I have already prepared a blowfish algorithm, there is also one in aeonlucid's github project, see https://github.com/AeonLucid/WolfteamRE
pack dateien im client encrypted/encrypted head 10/21/2012 - Metin2 Private Server - 2 Replies hi, ich hab ein problem, seit 2 wochen sind meine pc.eix und epk dateien in dem format encrypted und encrypted head die heißen nichtmehr .epk, .eix.
diese kann ich nicht entpacken..
ich hab mir gestern modified client 4.5 von neonblue gezogen und da sind die dinger auch encrypted, encrypted head... das kann nicht, ich hab das früher immer mit epk und eix gemacht
hab ich da irgendwas bei meinem computer umgestellt, oder was is anders? kann jemand helfen?
danke sehr <3
Memory Address of Post Encrypted Send Packet 10/20/2010 - CO2 Programming - 9 Replies Currently I am working on memory based proxy but I have a problem in finding the address of the pre-encrypted send packet data. I think i found out the address of the receive packet(from server), as per attached, but I'm not sure it that was really the address.
Anyone please help me how to locate the address of pre-encrypted send packet.
The title is misleading but I mean Post-decryption of receive packet buffer and pre-encryption of send packet buffer.