Protocol obfuscation

Latest revision as of 09:06, 24 November 2010

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. Obfuscation makes it harder to identify the eMule protocol.

[edit] Settings

• Enable Protocol Obfuscation: Ask other clients to use obfuscated communications.
• Allow obfuscated connections only: If the other client doesn't understand obfuscation, any communication with it gets canceled. Use this setting only in extreme situations!
• Disable support for obfuscated connections: The client behaves like it would be an older version which doesn't understand obfuscation.

[edit] Limitations

• Obfuscation only works if both sides of the transfer support it. If one side doesn't support it, the communication is done the "old" way, unless this is disabled (see Settings section).
• Obfuscation is not perfect, it is still possible to detect the eMule protocol.
• Obfuscation does not increase anonymity or hide which files are shared.
• If the provider doesn't try to detect the eMule protocol but rather blocks/limits every user which uses lots of bandwidth, obfuscation can't help at all.

[edit] Earlier version

Neomule supported a different kind of obfuscation before official supported obfuscation. This has become mostly obsolete since the official client supports it.

[edit] Technical implementation

[edit] 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

[edit] 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

[edit] See also

• List of providers which are throttling Bittorrent
• Obfuscation at the eMule docs