a TCP tunnel with packet length obfuscation

Latest on Hackage:

This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow to host generated Haddocks.

Apache-2.0 licensed by Jinjing Wang
Maintained by




n | padding | m | payload
  • n (word32be): the number of bytes of padding
  • padding: n bytes of noise
  • m (word32be): the number of bytes of the original payload
  • payload: the original packet


  • n is deduced from a randomly generated i = n + m for each packet.
  • When a random i is less then m, payload is split to p1 and p2 to satisfy the constrain, where the length of p1 is equal to i and p1 + p2 = payload. p2 will be sent in the next iteration by the same algorithm.
  • i is bounded by a maximum r, configurable by the --randomnessInBytes argument.
  • To reduce overhead, n is set to 0 whenever m is greater then r.


  • local:

      neko-obfs --localHost TEXT --localPort INTEGER --remoteHost TEXT --remotePort INTEGER
  • remote:

      neko-obfs --role remote --remoteHost TEXT --remotePort INTEGER --forwardHost TEXT --forwardPort INTEGER
  • This tunnel should be used inside an encrypted tunnel.

  • For example:

      ss-local (rc4)
        -> neko-obfs -> ss-tunnel (aes-256-cfb)
          -> gfw -> internet
        -> ss-tunnel (aes-256-cfb) -> neko-obfs 
      -> ss-server (rc4)
  • Note it’s the ss-tunnel layer that protects the obfuscation, otherwise data and noise length are clearly visible.


  • No noticeable slow down yet (Jul 24, 2017)


Revision history for neko-obfs – YYYY-mm-dd

  • First version. Released on an unsuspecting world.
comments powered byDisqus