Manuel Reithuber edited this page Jul 5, 2013 · 8 revisions

This page tries to gather information about btsync's (and therefore picosync's) transmission protocol. The official protocol hasn't (yet?) been published, so all the info you see here is based on tcpdump analysis.

Note: Currently, I'm doing protocol analysis with only one share to keep things simple. Therefore I don't yet have a clue how the official app announces and syncs multiple shares.
Note2: The protocol seems to have changed in recent versions of the official client. I did most of the analysis using the rather old 1.0.116 client. This page will be updated soon


This section describes how peers find each other. There are several different discovery methods, as seen on the official Technology Page.

Note: Currently, I've only covered tracker and local discovery. But the other methods will follow...

Discovery packets

The app sends discovery packets to potential peers. A discovery packet might look like that (hexdump, share and Peer ID have been removed):

00000000  42 53 59 4e 43 00 64 32  3a 6c 61 36 3a c0 a8 01  |BSYNC.d2:la6:...|
00000010  18 a1 b5 31 3a 6d 69 34  65 34 3a 70 65 65 72 32  |...1:mi4e4:peer2| <- note that the message type parameter 'm' has changed. In early versions it was an integer (4 in this case), now it's a string as seen below
00000020  30 3a __ __ __ __ __ __  __ __ __ __ __ __ __ __  |0:..............|
00000030  __ __ __ __ __ __ 35 3a  73 68 61 72 65 33 32 3a  |......5:share32:|
00000040  __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __  |................|
00000050  __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __  |................|
00000060  65                                                |e|

The packet starts with the text "BSYNC\0" followed by bencoded request data. If decoded, the request data looks like that:

    "peer": /* 20 bytes of binary randomness identifying this app instance" */, 
    "share": /* 32 bytes (=256bits) SHA256 hash, see the Secret wiki page linked below for more info */, 
    "m": "get_peers" /* message type, 'get_peers' is sent to the tracker, the peers use 'ping' when pinging each other */, 
    "la": /* local IP + port in binary form (4 bytes IP + 2 bytes for the port) */

For more info on how share secrets are calculated, see the Secret wiki page.


The tracker IPs are fetched by querying DNS for (The resulting IPs are hosted at Amazon AWS at the time of this writing). The app sends a discovery packet (see above) to the tracker (UDP port 3000) and in return gets a response packet back (which contains a list of other peers for the same share and the external IP+port of this instance). Details follow.


The peer to peer protocol is currently being analyzed. Therefore, consider this section a work in progress.

But some information has already been found out (Note: This mostly reflects packet analysis done based on v1.0.116. The protocol has been changed since):

  • BitTorrent Sync uses libutp for data transport. µTP was developed for BitTorrent as a replacement for TCP that only takes available bandwidth without slowing down other connections
  • The p2p traffic is said to be AES encrypted (according to the official Technology Page). But it is still unknown which cipher mode is used or how the encryption key is derived from the Secret
  • The traffic seems to be split in frames that start with a 4byte frame length header
  • The communication sessions seem to be rather short-lived (tested with a simple share that only contains a single text file that wasn't changed during the test). After the aforementioned handshake, each peer sends about two data packets (each containing several frames) after which the session gets closed.
  • Also noteworthy is the fact that some frames have similar byte sequences (most common: the first ~9 bytes are the same) which is a little odd since encrypted data shouldn't look like that.


The official btsync app supports relaying traffic via external servers. This hasn't yet been tried out and analyzed, but as soon as there's progress, you'll find it here.

According to the debug log (and some packet capturing), the official relay servers are determined by querying the DNS server for

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.