Protocol obfuscation
From EMule Wiki
Some providers are throttling eMule traffic (decreasing the allowed bandwidth). They do this by detecting the eMule protocol and allowing a very limited amount of the total bandwidth to be used by eMule. The best reaction against this is to change ISP.
- Before you are changing your ISP, please verify on the eMule under Options-> Security-> Protocol Obfuscation, that Enable Protocol Obfusaction is checked, otherwise you are unable to work with the Protocol Obfusaction on eMule.
However, by encrypting the eMule protocol, the provider cannot detect eMule easy and might allow more bandwidth to be used by encrypted traffic.
- Encryption (obfuscation) is only possible if both sides use encryption.
- It only protects (limited) against man-in-the-middle attacks.
- It does not increase your privacy since your data is still visible to other eMule clients that use the same encryption.
neomule
Neomule supported a different kind of obfuscation before official supported obfuscation. THis has become mostly obsolete since official emule supportes it.
Technical implementation
<verse> encrypted UDP
Basic Obfusicated Handshake Protocol UDP:
see EncryptedStreamSocket.h
-Keycreation Client <-> Client:
- Client A (Outgoing connection):
Sendkey: Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>) 23
- Client B (Incoming connection):
Receivekey: Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>) 23
- Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
-Keycreation Client <-> Server:
- Client A (Outgoing connection client -> server):
Sendkey: Md5(<BaseKey 4><MagicValueClientServer 1><RandomKeyPartClientA 2>) 7
- Client B (Incoming connection):
Receivekey: Md5(<BaseKey 4><MagicValueServerClient 1><RandomKeyPartClientA 2>) 7
- Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
- Handshake
-> The handshake is encrypted - except otherwise noted - by the Keys created above
-> Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 2[Unencrypted]><MagicValue 4><PaddingLen 1><RandomBytes PaddingLen%16>
- Overhead: 8 Bytes per UDP Packet
- Security for Basic Obfuscation:
- Random looking packets, very limited protection against passive eavesdropping single packets
- Additional Comments:
- For obvious reasons the UDP handshake is actually no handshake. If a different Encryption method (or better a different Key) is to be used this has to be negotiated in a TCP connection
- SemiRandomNotProtocolMarker is a Byte which has a value unequal any Protocol header byte. This is a compromiss, turning in complete randomness (and nice design) but gaining
a lower CPU usage
Encrypted tcp
Basic Obfuscated Handshake Protocol Client <-> Client:
-Keycreation:
- Client A (Outgoing connection):
Sendkey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>) 21
Receivekey: Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
- Client B (Incomming connection):
Sendkey: Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
Receivekey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>) 21
NOTE: First 1024 Bytes are discarded
- Handshake
-> The handshake is encrypted - except otherwise noted - by the Keys created above
-> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
-> EncryptionMethod = 0 is Obfusication and the only supported right now
Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 4[Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen%16>
Client B: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen%16>
-> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
- Overhead: 18-48 (~33) Bytes + 2 * IP/TCP Headers per Connection
- Security for Basic Obfusication:
- Random looking stream, very limited protection against passive eavesdropping single connections
- Additional Comments:
- RandomKeyPart is needed to make multiple connections between two clients look different (but still random), since otherwise the same key
would be used and RC4 would create the same output. Since the key is a MD5 hash it doesnt weakens the key if that part is known
- Why DH-KeyAgreement isn't used as basic obfusication key: It doesn't offers substantial more protection against passive connection based protocol identification, it has about 200 bytes more overhead,
needs more CPU time, we cannot say if the received data is junk, unencrypted or part of the keyagreement before the handshake is finished without loosing the complete randomness,
it doesn't offers substantial protection against eavesdropping without added authentification
Basic Obfuscated Handshake Protocol Client <-> Server:
- RC4 Keycreation:
- Client (Outgoing connection):
Sendkey: Md5(<S 96><MagicValue34 1>) 97
Receivekey: Md5(<S 96><MagicValue203 1>) 97
- Server (Incomming connection):
Sendkey: Md5(<S 96><MagicValue203 1>) 97
Receivekey: Md5(<S 96><MagicValue34 1>) 97
NOTE: First 1024 Bytes are discarded
- Handshake
-> The handshake is encrypted - except otherwise noted - by the Keys created above
-> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
-> EncryptionMethod = 0 is Obfusication and the only supported right now
Client: <SemiRandomNotProtocolMarker 1[Unencrypted]><G^A 96 [Unencrypted]><RandomBytes 0-15 [Unencrypted]>
Server: \<G^B 96 [Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen>
Client: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen> (Answer delayed till first payload to save a frame)
-> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
- Overhead: 206-251 (~229) Bytes + 2 * IP/TCP Headers Headers per Connectionon
- DH Agreement Specifics: sizeof(a) and sizeof(b) = 128 Bits, g = 2, p = dh768_p (see below), sizeof p, s, etc. = 768 bits
</verse>
