Protocol obfuscation

From EMule Wiki
(Difference between revisions)
Jump to: navigation, search
(Undo revision 3007 by Izegiwera (Talk))
 
Line 1: Line 1:
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
=[http://itygeligub.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
 
----
 
=[http://itygeligub.co.cc CLICK HERE]=
 
----
 
</div>
 
 
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.
 
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.
  
Line 19: Line 11:
 
== Limitations ==
 
== Limitations ==
  
* Obfuscation only works if both sides of the transfer support it. If one side doesn't support it, the communication is done the &quot;old&quot; way, unless this is disabled (see ''Settings'' section).
+
* 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 is not perfect, it is still possible to detect the eMule protocol.
 
* Obfuscation does not increase anonymity or hide which files are shared.
 
* Obfuscation does not increase anonymity or hide which files are shared.
Line 35: Line 27:
 
     see EncryptedStreamSocket.h
 
     see EncryptedStreamSocket.h
 
   :
 
   :
     -Keycreation Client &lt;-&gt; Client:
+
     -Keycreation Client <-> Client:
 
     - Client A (Outgoing connection):
 
     - Client A (Outgoing connection):
                 Sendkey:    Md5(&lt;UserHashClientB 16&gt;&lt;IPClientA 4&gt;&lt;MagicValue91 1&gt;&lt;RandomKeyPartClientA 2&gt;)  23
+
                 Sendkey:    Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>)  23
 
     - Client B (Incoming connection):
 
     - Client B (Incoming connection):
                 Receivekey: Md5(&lt;UserHashClientB 16&gt;&lt;IPClientA 4&gt;&lt;MagicValue91 1&gt;&lt;RandomKeyPartClientA 2&gt;)  23
+
                 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
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
   :
 
   :
     -Keycreation Client &lt;-&gt; Server:
+
     -Keycreation Client <-> Server:
     - Client A (Outgoing connection client -&gt; server):
+
     - Client A (Outgoing connection client -> server):
                 Sendkey:    Md5(&lt;BaseKey 4&gt;&lt;MagicValueClientServer 1&gt;&lt;RandomKeyPartClientA 2&gt;)  7
+
                 Sendkey:    Md5(<BaseKey 4><MagicValueClientServer 1><RandomKeyPartClientA 2>)  7
 
     - Client B (Incoming connection):
 
     - Client B (Incoming connection):
                 Receivekey: Md5(&lt;BaseKey 4&gt;&lt;MagicValueServerClient 1&gt;&lt;RandomKeyPartClientA 2&gt;)  7
+
                 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
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
  :
 
  :
 
     - Handshake
 
     - Handshake
             -&gt; The handshake is encrypted - except otherwise noted - by the Keys created above
+
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
             -&gt; Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
+
             -> Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
         Client A: &lt;SemiRandomNotProtocolMarker 1[Unencrypted]&gt;&lt;RandomKeyPart 2[Unencrypted]&gt;&lt;MagicValue 4&gt;&lt;PaddingLen 1&gt;&lt;RandomBytes PaddingLen%16&gt;    
+
         Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 2[Unencrypted]><MagicValue 4><PaddingLen 1><RandomBytes PaddingLen%16>    
 
  :
 
  :
 
     - Overhead: 8 Bytes per UDP Packet
 
     - Overhead: 8 Bytes per UDP Packet
Line 66: Line 58:
 
=== Encrypted TCP ===
 
=== Encrypted TCP ===
  
  Basic Obfuscated Handshake Protocol Client &lt;-&gt; Client:
+
  Basic Obfuscated Handshake Protocol Client <-> Client:
 
     -Keycreation:
 
     -Keycreation:
 
     - Client A (Outgoing connection):
 
     - Client A (Outgoing connection):
                 Sendkey:    Md5(&lt;UserHashClientB 16&gt;&lt;MagicValue34 1&gt;&lt;RandomKeyPartClientA 4&gt;)  21
+
                 Sendkey:    Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
                 Receivekey: Md5(&lt;UserHashClientB 16&gt;&lt;MagicValue203 1&gt;&lt;RandomKeyPartClientA 4&gt;) 21
+
                 Receivekey: Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
 
     - Client B (Incomming connection):
 
     - Client B (Incomming connection):
                 Sendkey:    Md5(&lt;UserHashClientB 16&gt;&lt;MagicValue203 1&gt;&lt;RandomKeyPartClientA 4&gt;) 21
+
                 Sendkey:    Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
                 Receivekey: Md5(&lt;UserHashClientB 16&gt;&lt;MagicValue34 1&gt;&lt;RandomKeyPartClientA 4&gt;)  21
+
                 Receivekey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
 
         NOTE: First 1024 Bytes are discarded
 
         NOTE: First 1024 Bytes are discarded
 
   :
 
   :
 
     - Handshake
 
     - Handshake
             -&gt; The handshake is encrypted - except otherwise noted - by the Keys created above
+
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
             -&gt; Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
+
             -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
             -&gt; EncryptionMethod = 0 is Obfusication and the only supported right now
+
             -> EncryptionMethod = 0 is Obfusication and the only supported right now
         Client A: &lt;SemiRandomNotProtocolMarker 1[Unencrypted]&gt;&lt;RandomKeyPart 4[Unencrypted]&gt;&lt;MagicValue 4&gt;&lt;EncryptionMethodsSupported 1&gt;&lt;EncryptionMethodPreferred 1&gt;&lt;PaddingLen 1&gt;&lt;RandomBytes PaddingLen%16&gt;    
+
         Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 4[Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen%16>    
         Client B: &lt;MagicValue 4&gt;&lt;EncryptionMethodsSelected 1&gt;&lt;PaddingLen 1&gt;&lt;RandomBytes PaddingLen%16&gt;
+
         Client B: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen%16>
             -&gt; The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
+
             -> 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
 
     - Overhead: 18-48 (~33) Bytes + 2 * IP/TCP Headers per Connection
 
     - Security for Basic Obfusication:
 
     - Security for Basic Obfusication:
Line 94: Line 86:
 
               it doesn't offers substantial protection against eavesdropping without added authentification
 
               it doesn't offers substantial protection against eavesdropping without added authentification
  
Basic Obfuscated Handshake Protocol Client &lt;-&gt; Server:
+
Basic Obfuscated Handshake Protocol Client <-> Server:
 
     - RC4 Keycreation:
 
     - RC4 Keycreation:
 
     - Client (Outgoing connection):
 
     - Client (Outgoing connection):
                 &lt;nowiki&gt;Sendkey:    Md5(&lt;S 96&gt;&lt;MagicValue34 1&gt;)  97&lt;/nowiki&gt;
+
                 <nowiki>Sendkey:    Md5(<S 96><MagicValue34 1>)  97</nowiki>
                 &lt;nowiki&gt;Receivekey: Md5(&lt;S 96&gt;&lt;MagicValue203 1&gt;) 97&lt;/nowiki&gt;
+
                 <nowiki>Receivekey: Md5(<S 96><MagicValue203 1>) 97</nowiki>
 
     - Server (Incomming connection):
 
     - Server (Incomming connection):
                 &lt;nowiki&gt;Sendkey:    Md5(&lt;S 96&gt;&lt;MagicValue203 1&gt;)  97&lt;/nowiki&gt;
+
                 <nowiki>Sendkey:    Md5(<S 96><MagicValue203 1>)  97</nowiki>
                 &lt;nowiki&gt;Receivekey: Md5(&lt;S 96&gt;&lt;MagicValue34 1&gt;) 97&lt;/nowiki&gt;
+
                 <nowiki>Receivekey: Md5(<S 96><MagicValue34 1>) 97</nowiki>
 
   :     
 
   :     
 
     NOTE: First 1024 Bytes are discarded
 
     NOTE: First 1024 Bytes are discarded
 
   :
 
   :
 
     - Handshake
 
     - Handshake
             -&gt; The handshake is encrypted - except otherwise noted - by the Keys created above
+
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
             -&gt; Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
+
             -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
             -&gt; EncryptionMethod = 0 is Obfusication and the only supported right now
+
             -> EncryptionMethod = 0 is Obfusication and the only supported right now
 
   :     
 
   :     
         Client: &lt;SemiRandomNotProtocolMarker 1[Unencrypted]&gt;&lt;G^A 96 [Unencrypted]&gt;&lt;RandomBytes 0-15 [Unencrypted]&gt;    
+
         Client: <SemiRandomNotProtocolMarker 1[Unencrypted]><G^A 96 [Unencrypted]><RandomBytes 0-15 [Unencrypted]>    
         Server: \&lt;G^B 96 [Unencrypted]&gt;&lt;MagicValue 4&gt;&lt;EncryptionMethodsSupported 1&gt;&lt;EncryptionMethodPreferred 1&gt;&lt;PaddingLen 1&gt;&lt;RandomBytes PaddingLen&gt;
+
         Server: \<G^B 96 [Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen>
         Client: &lt;MagicValue 4&gt;&lt;EncryptionMethodsSelected 1&gt;&lt;PaddingLen 1&gt;&lt;RandomBytes PaddingLen&gt; (Answer delayed till first payload to save a frame)
+
         Client: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen> (Answer delayed till first payload to save a frame)
 
     :       
 
     :       
             -&gt; The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
+
             -> 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
 
     - Overhead: 206-251 (~229) Bytes + 2 * IP/TCP Headers Headers per Connectionon
Line 122: Line 114:
 
== See also ==
 
== See also ==
 
*[http://www.azureuswiki.com/index.php/Bad_ISPs List of providers which are throttling '''Bittorrent''']
 
*[http://www.azureuswiki.com/index.php/Bad_ISPs List of providers which are throttling '''Bittorrent''']
*[http://www.emule-project.net/home/perl/help.cgi?l=1&amp;rm=show_topic&amp;topic_id=848 Obfuscation at the eMule docs]
+
*[http://www.emule-project.net/home/perl/help.cgi?l=1&rm=show_topic&topic_id=848 Obfuscation at the eMule docs]
  
  
 
[[category:features]]
 
[[category:features]]

Latest revision as of 10: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.

Contents

[edit] Settings

howtoenableobfuscation.png

  • 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

Personal tools