Inofficial Protocol Specification

[mreithub]

I've been spending some time recently trying to figure out some of the details of BitTorrent Sync's network protocol. I really liked the idea of a p2p alternative to other cloud storage providers like dropbox etc.

So I tried to find out the technical details behind the project. The official Technology page was a little sparse in that regard so I figured I'd have to dig in myself.

I managed to start this as a university project (at the Vienna University of Technoligy in Austria). The goals are:

• Analyze the network protocol (and documenting it as far as possible)
  
• Discuss possible security issues (The official page claims it's very secure and throws around with words like AES and SHA2, but )
  Don't get me wrong, I don't expect to find anything serious here as the basic idea seems pretty solid, but I think this claim has to be proven
  
• Write an open source library that allows other apps to communicate with btsync (not a full-blown sync app, just the basics)
  

So, now to the fun stuff, I'll explain what I've found out so far:

Secrets:

The read only secret is basically just a hashed version of the normal secret (all code is valid python code (after importing hashlib.* and base64.*)):

roSecret='R'+(b32encode(sha256(b32decode(secret)).digest())[:32])

The roSecret is hashed again. That hash is transmitted in LAN announces as well as to the tracker at t.usyncapp.com:

shareHash=sha256(b32decode(roSecret[1:])).digest()

That's about all the magic that's in the share secrets.

Tracker:

The Tracker protocol uses bencoded data.

The request format is (I've conveted it to JSON for readability):

{
"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",
"la": /* local IP + port in binary form (4 bytes IP + 2 bytes for the port) */
}

The tracker's answer looks like that:

{
   "m": "peers",
   "peers": [
      {
         "a": /* 6bytes external ip+port of peer*/,
         "p": /* 20bytes peer id (random) */,
         "la": /* 6 bytes local IP+port of the peer */
      },
      /* all the other peers */
      ],
      "ea": /* 6 bytes, external IP+port of the local peer *,
      "share": /* 32bytes shareHash */,
      "time": /* integer, unix timestamp */
}

P2P:

The peers use µTP for communication.

On top of that, they seem to do a key handshake and submit the actual data.

The details about that are still a little unclear (and have changed since the early 1.0.* releases), but I'll keep you updated as soon as I know more.

I'm currently working on some Qt code (Qt's just the framework I'm used to, this might change if there's a good reason to) that reflects these protocol details. It's mostly based on what I've found out analyzing v1.0.116's protocol. I'll update it soon to support the new protocol used by 1.1.27.

It can be found on GitHub. All the above details also are in the repo's wiki (feel free to contribute).

Also let me give huge thanks to the BitTorrent Sync Team. They're doing great work (both in writing the app and in working with the community here on the forums).

[GreatMarko]

The goals are:

• Discuss possible security issues (The official page claims it's very secure and throws around with words like AES and SHA2, but )
  Don't get me wrong, I don't expect to find anything serious here as the basic idea seems pretty solid, but I think this claim has to be proven
  

Issues/Questions surrounding security have previously been pretty much discussed to death - please search the forum to find the information/answers you require - the following threads will help you get started: 1 | 2 | 3 | 4 | 5

The goals are:

• Write an open source library that allows other apps to communicate with btsync (not a full-blown sync app, just the basics)
  

Given that BTSync & the protocol are, at present, closed source, writing your own app that reverse-engineers the protocol and/or attempts to communicate with Sync will likely be frowned upon, as it is in direct breach of the Terms or Use... it would also certainly be unwise to go down that route at the present time, given the very fluid nature of the "alpha" builds & the protocol (which has changed several times since the build you base your "findings" on). That said, there is an official API in development, which may be something of significant interest to you if you do wish to develop your own app/interface, etc, although please be aware that there is no timescale at present for the API's general availability (There's a dedicated "Wishlist" thread for the API here)

[hhz]

I, for one, welcome an open source implementation and don't consider it "unwise". Congrats!

[Harold Feit]

Considering the current state of the protocol AND program, it is unwise to start an open source implementation at this time.

[cdata]

Even if it is too early for the protocol to be considered stable enough for reverse engineering, I think it's important that open source developers start considering decentralized sync a challenge worth tackling. Kudos, mreithub.

[th1nk]

I totally agree with cdata! It's never to early to start analyzing and documenting protocols and their closed source implementations. This should be in the interest of everybody...

So, keep up your work, mreithub!

[GreatMarko]

It's never to early to start analyzing and documenting protocols...

...it is, given that the protocol's currently changing all the time!! The OP's "research" is pretty outdated and isn't applicable to the latest builds!

[cdata]

The OP's research may lead him (or others) to develop an alternative solution to the problem. If you are old enough, you might recall a time when this methodology was applied to develop free communication tools, operating systems and peer-to-peer file sharing protocols.

[mreithub]

Hi all of you,

first of all thank you for all the responses so far (especially for the ones )

Given that BTSync & the protocol are, at present, closed source, writing your own app that reverse-engineers

the protocol and/or attempts to communicate with Sync will likely be frowned upon... and it would certainly

be unwise to go down that route at the present time, given the very fluid nature of the "alpha" builds & the

protocol (which has changed several times since the build you base your "findings" on).

When I posted that message I already suspected that some of you might not be all that happy about what I am doing...

I've been thinking a lot about it, but I think I've done the right thing.

And what I've done so far was basically a mix of thinking how I'd do it myself, running tcpdump+writing a script that

makes it easier to see patterns in the transmitted packets and a little research in "[uses] bittorrent technology",

so it hasn't been that difficult (and would've been done anyway sooner or later).

I am in no way trying to pose a threat to btsync. It's in my best interest that it'll be as successful as it can be,

because I am (as most of you I suppose) part of the minority of cloud storage users that really are concerned about

having their private data stored unencrypted in some data center (we've all heard the PRISM discussions lately, so I'll

skip that here).

But as I said, I think we (the security-concerned users) only make a small percentage of cloud storage users. So for

btsync to gain real momentum, it has to be rock solid. They say they use secure AES-based encryption (which I believe

is correct but I (and I'm sure many others) would prefer to have actual proof.

The other killer feature of btsync - the (virtually) unlimited storage - comes with a downside though: It's only

interesting for people having their own server or at least NAS with 24/7 uptime.

There already were proposals in the forum for an additional secret that'll only gain you encrypted access to the share.

That was also one of my first thoughts after learning about btsync as it will allow us to get rid of the one downside

and allow btsync-providers that can't access our data. Those could also implement daily off-site backups of your

encrypted data - which will be a very interesting feature for small and middle-sized businesses (which in turn will increase

btsync's market share).

I do want btsync to get as successful as possible (as I don't want to fall back to dropbox and the like when it comes

to sharing data with people that simply don't have it) so market share is important (and the market's already close to

being saturated if you ask me)

As to your statements that it doesn't make sense to analyze a protocol that's not yet stable I can say that I think (like @cdata, ...)

you can't start too early for several reasons. The first one is that one of my aims is simply to prove (or disprove)

make sure the used encryption really is secure (All the threads @GreatMarko linked to are either about implementation bugs

or "how-secure-is-the-secret". That's one part of the question, but I'm more interested in things like: which AES-Mode is

used, does it encrypt everything or just the files, etc.).

The other reason is that I look at BitTorrent itself and the huge ecosystem of apps and services that grew around it.

I'd like something like that for btsync too. I also see other services built based on the same technology (e.g. think of

having a remote desktop app that uses btsync technology (not the file sharing, but the discovery and transport layers)).

To sum it up, I'd love to see other developers using that technology for whatever reason in their apps (there's just so

much potential in the technology).

To the API:

Yes, I've read the announcements of an API, but as @rippelhans answered to the post @GreatMarko linked above, it kind of

pokes a hole into the whole noone-else-has-access-to-your-data argument. Yeah, they could write an API-Software that's

self-hosted or runs on the client but then you're back at needing a server.

Ok, that about sums up what I wanted to say. Sorry that it's quite a lot to read (and sorry if some parts may be hard to read, I'm not

a native speaker).

Anyway, please ask if anything's unclear or I left questions unanswered. (And help is very much welcome )

[handle]

Hi all of you,

first of all thank you for all the responses so far (especially for the ones )

When I posted that message I already suspected that some of you might not be all that happy about what I am doing...

I've been thinking a lot about it, but I think I've done the right thing.

And what I've done so far was basically a mix of thinking how I'd do it myself, running tcpdump+writing a script that

makes it easier to see patterns in the transmitted packets and a little research in "[uses] bittorrent technology",

so it hasn't been that difficult (and would've been done anyway sooner or later).

I am in no way trying to pose a threat to btsync. It's in my best interest that it'll be as successful as it can be,

because I am (as most of you I suppose) part of the minority of cloud storage users that really are concerned about

having their private data stored unencrypted in some data center (we've all heard the PRISM discussions lately, so I'll

skip that here).

But as I said, I think we (the security-concerned users) only make a small percentage of cloud storage users. So for

btsync to gain real momentum, it has to be rock solid. They say they use secure AES-based encryption (which I believe

is correct but I (and I'm sure many others) would prefer to have actual proof.

The other killer feature of btsync - the (virtually) unlimited storage - comes with a downside though: It's only

interesting for people having their own server or at least NAS with 24/7 uptime.

There already were proposals in the forum for an additional secret that'll only gain you encrypted access to the share.

That was also one of my first thoughts after learning about btsync as it will allow us to get rid of the one downside

and allow btsync-providers that can't access our data. Those could also implement daily off-site backups of your

encrypted data - which will be a very interesting feature for small and middle-sized businesses (which in turn will increase

btsync's market share).

I do want btsync to get as successful as possible (as I don't want to fall back to dropbox and the like when it comes

to sharing data with people that simply don't have it) so market share is important (and the market's already close to

being saturated if you ask me)

As to your statements that it doesn't make sense to analyze a protocol that's not yet stable I can say that I think (like @cdata, ...)

you can't start too early for several reasons. The first one is that one of my aims is simply to prove (or disprove)

make sure the used encryption really is secure (All the threads @GreatMarko linked to are either about implementation bugs

or "how-secure-is-the-secret". That's one part of the question, but I'm more interested in things like: which AES-Mode is

used, does it encrypt everything or just the files, etc.).

The other reason is that I look at BitTorrent itself and the huge ecosystem of apps and services that grew around it.

I'd like something like that for btsync too. I also see other services built based on the same technology (e.g. think of

having a remote desktop app that uses btsync technology (not the file sharing, but the discovery and transport layers)).

To sum it up, I'd love to see other developers using that technology for whatever reason in their apps (there's just so

much potential in the technology).

To the API:

Yes, I've read the announcements of an API, but as @rippelhans answered to the post @GreatMarko linked above, it kind of

pokes a hole into the whole noone-else-has-access-to-your-data argument. Yeah, they could write an API-Software that's

self-hosted or runs on the client but then you're back at needing a server.

Ok, that about sums up what I wanted to say. Sorry that it's quite a lot to read (and sorry if some parts may be hard to read, I'm not

a native speaker).

Anyway, please ask if anything's unclear or I left questions unanswered. (And help is very much welcome )

Thank you for reverse engineering the protocol some. Would you be able to divulge and/or explain some more information?

If you are still persuing this, keep up the good work!

[GreatMarko]

Thank you for reverse engineering the protocol some. Would you be able to divulge and/or explain some more information?

If you are still persuing this, keep up the good work!

Please note, that attempting to "reverse engineer" BitTorrent Sync violates the current Terms of Use

[handle]

Please note, that attempting to "reverse engineer" BitTorrent Sync violates the current Terms of Use

This is true, however when people do this to expose good security being used, it helps the product because more security-conscious people are likely to use it, and to spread it around as a good thing. Because of this, I do not believe this portion of the Terms of Use is being actively enforced, and for good reason.

I'm waiting for answers from a developer in a different thread, however I really do want to use Bittorrent Sync, as do many other people. Due to the lack of protocol information or source code, security-conscious people have to either wait for developers (who are most likely very busy) to answer questions about how the system works, or it can be partially reverse engineered to explain better how the internals work.

As one of the developers have stated that they do not abide by Security through Obscurity, I see no problem with this when done reasonably. Using it to explain the security of a program is perfectly reasonable.

[hhz]

Please note, that attempting to "reverse engineer" BitTorrent Sync violates the current Terms of Use

It is not. Read those ToU again.

It is a violation to reverse engineer the binary code of btsync, but not a violation to reverse engineer the protocol used by the program. There is a difference.

It should also be noted that reverse engineering clause of the ToU is most likely legally invalid in mreithub's country and thus very difficult to enforce against him. (Welcome to the Internet.)

Allow the question: Why are you (greatmarko) so upset about this? Obviously, you're not with BitTorrent or a developer of btsync. Why the zealotry that the btsync developers didn't even ask for?

[handle]

It is not. Read those ToU again. It is a violation to reverse engineer the binary code of btsync, but not a violation to reverse engineer the protocol used by the program. There is a difference.

Allow the question: Why are you (greatmarko) so upset about this? Obviously, you're not with BitTorrent or a developer of btsync. Why the zealotry that the btsync developers didn't even ask for?

In order to learn the protocol, either the binary has to be reverse engineered, or one must be very lucky at guesses. I think he meant Bittorrent Sync as in the binary program. Though I might be wrong.

As for the second paragraph, he doesn't seem upset - it sounds like more of a friendly warning than a "Silence, naysayers" sort of deal. Though I might be wrong on this as well.

[grabhive]

GreatMarko,

Disputation about terms barring research and free inquiry is preposterous. There are important matters at stake. With the recent mass-spying revelations, it's clear that the age of closed-source must swiftly come to an end. We need to know what our software is doing and must have the power to create alternative implementations if we do not agree with what we see.

mreithub,

Please carry on. If you post a Bitcoin address I will be happy to donate to your efforts, and I am almost certainly not the only one. You are doing the right thing, and I implore you to avoid persuasion by zealots such as GreatMarko. Given the sheer lack of sense on display, one can assume that his bread and butter derives directly from the coffers of BitTorrent, Inc., a company capitalizing in extraordinarily uncertain terms upon that which it knows should be open in the first place.

[winr0ar]

Please note, that attempting to "reverse engineer" BitTorrent Sync violates the current Terms of Use

No it is not. Please see grabhive's answer

He did not say he reverse engineered the application binary. He might have started by experimenting and discovering how it works.

mreithub,

Please carry on. If you post a Bitcoin address I will be happy to donate to your efforts, and I am almost certainly not the only one. You are doing the right thing, and I implore you to avoid persuasion by zealots such as GreatMarko. Given the sheer lack of sense on display, one can assume that his bread and butter derives directly from the coffers of BitTorrent, Inc., a company capitalizing in extraordinarily uncertain terms upon that which it knows should be open in the first place.

Agreed. I am very impressed with your work and please carry on.

[grabhive]

Hey how is this project coming along?