current BTSync protocol

[almereyda]

• Is the interface simply beautiful?

and

• Does sync.io support newer iterations of the BTSync protocol? By the way how clients are able to connect to each other, I can see there must have been some changes.

[ppmathis]

Thanks for your comment, @almereyda. I'm going to fix the README soon (currently fetching some server backups, seems like I've forgotten to upload these images to the new server). sync.io does not support newer iterations of BTSync, they've changed a lot and I would have to reverse engineer the whole protocol again.

If there's still interest in this project though, I can do so.

[ppmathis]

Short update: Reverse engineering should be doable, can't name any release date though, working on another project right now. But the screens are now back online!

[almereyda]

I found it interesting that you received the right to reverse engineer the protocol. In my view that is a kind of asking for it. If you are capable of doing so, I am sure the community would be very thankful for that. Once that works well, I could even think of an added (undocumented) expert configuration option that allows to manually set tracker and relay servers.

Thank you for the screens. I have accordingly updated the headline.

[ppmathis]

Unfortunately BitTorrent Inc. is probably never going to do so - they do not support me in any way and they are strictly against that setting, it was requested already a few times but always declined.

I'll take a look at BTSync's new protocol as soon as I've got time for that.

[rainkinz]

Do you know what the last known good version of BTSync that worked with sync.io was?

[ppmathis]

@rainkinz Thanks for your comment. It seems that there's still a lot of interest in an opensource tracker and BitTorrent Inc. doesnt seem to do something similar in the near future.

I'm currently on vacations, but when I'm back at home, I will continue on working at keepass.io and also recode sync.io so it is compatible to the new protocol. Im also going to add a few new features, stay tuned!

Now to your real question: The last time I've worked on sync.io was in January, but I can not tell the exact version number anymore, sorry.

[mubix]

Just a head up, BTSync now does a HTTP request to config.usyncapp.com for sync.conf which looks like this:

{
  "trackers" :
  [
    {"addr" : "54.225.100.8:3000"},
    {"addr" : "54.225.196.38:3000"},
    {"addr" : "54.225.92.50:3000"}
  ],
  "relays" :
  [
    {"addr" : "67.215.231.242:3000"},
    {"addr" : "67.215.229.106:3000"}
  ]
}

[mubix]

I tried to modify the trackers list to just my Sync.io one but btsync binary (linux) would just crash after talking to Sync.io over port 3000. The nice thing looks like that ports are configurable now. Just need updates to the protocol I think and we'll be set.

[ppmathis]

@mubix Thanks for your comment and your efforts to help me. I'll be back on Sunday and will continue coding on sync.io and keepass.io next week. I'm going to recode it completely, as some things have changed drastically.

Also, I've come up with a few new features - stay tuned!

[rainkinz]

:thumbsup: Thanks looking forward to trying it out.

[almereyda]

Heads up!

On 24 July 2014 16:07, rainkinz notifications@github.com wrote:

[image: :thumbsup:] Thanks looking forward to trying it out.

— Reply to this email directly or view it on GitHub https://github.com/NeoXiD/sync.io/issues/2#issuecomment-50022419.

[ppmathis]

Just a short notice: I've started working on sync.io about a week ago, but there aren't many commits so far, even though I'm investing quite a lot of time into it. BitTorrent, Inc. changed almost all parts of the protocol and the tracker server now listens on TCP and UDP (separate protocols..), but there's good progress so far.

[almereyda]

Good to know. Thanks for the update.

[ppmathis]

Another short update: I've reversed the TCP protocol now completely and written down all the protocol parts on a piece of paper. A few hours ago; I started with implementing the first few methods. No idea yet about the UDP protocol, but so far, it seems like it isn't needed. Going to keep you all updated.

[mubix]

@NeoXiD as always, thanks for the update and continued work. Really appreciated

[icy]

Awesome, @NeoXiD :)

[almereyda]

Go go go ! :dancer:

[ppmathis]

And there's another update, guys! The core functionality is now implemented and exchanging files between various peers works like a charm. I've just set up a bunch of different VMs and couldn't spot any problems. Here's a little screenshot:

Please do not use it in production yet. There are still many things missing, like cleaning up old shares/peers/announcements, the new webinterface, security-related stuff and others. As said though, the core functionality seems to work, so the rest shouldn't be that much of a challenge.

I've still got no idea though for what the UDP connection is being used, but so far, I didn't have any problems with simply ignoring it...

[rtreffer]

I'd guess that UDP is used for NAT piercing. This is a common thing to i connect 2 peers that are both nated.

On 25. August 2014 22:24:59 MESZ, Pascal Mathis notifications@github.com wrote:

And there's another update, guys! The core functionality is now implemented and exchanging files between various peers works like a charm. I've just set up a bunch of different VMs and couldn't spot any problems. Here's a little screenshot:

Please do not use it in production yet. There are still many things missing, like cleaning up old shares/peers/announcements, the new webinterface, security-related stuff and others. As said though, the core functionality seems to work, so the rest shouldn't be that much of a challenge.

I've still got no idea though for what the UDP connection is being used, but so far, I didn't have any problems with simply ignoring it...

---

Reply to this email directly or view it on GitHub: https://github.com/NeoXiD/sync.io/issues/2#issuecomment-53324137

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[ppmathis]

Thanks for your message, @rtreffer. The tracker is only thought for distribution of shares and their peers, so it has the same usage as a normal BitTorrent Tracker.

In earlier versions, that tracker connection was working via UDP, but now they've switched to TCP. There's still a UDP connection though, for whatever reason. Why should they use NAT piercing/traversal then? The tracker servers have to be available with a public IP anyways. (If you want to have external clients, otherwise a private IP will do for sure)

Since the first few BTSync Versions, there is also a Relay-Server, which gets used for NAT piercing/traversal between peers.

But I'm definitely going to further investigate this with Wireshark.

[rtreffer]

Imagine one PC at home and one at work, syncing data.

You usually don't want to use a "real" relay. (That would kill any server quite fast). So your home PC sends a UDP packet out. This opens port 37768 on the firewall, which you don't know. You usually need a way to determine your external IP and port to make file transfer work. (UDP is stateless, so any host may contact you on that port!)

A tracker would simply add you with the right udp ip/port. And tell you what it found. Which means the traffic might be totally innocent unless 2 machines sync from behind different nat gateways.

Normal BT has embedded this in the DHT implementation. I'm not very familiar with the BTSync stuff, but I would expect them to alway do direct connections if possible, thus using a UDP fallback.

Anyway, just a wild guess based on what bittorrent is doing.

[ppmathis]

I understood what you've meant, @rtreffer. In the older versions though, all these NAT traversal or full-relay things were the job of the relay server. Maybe they've changed that too, although it doesn't make that much sense when thinking about the BTSync infrastructure. We'll see, Wireshark might expose the truth :)

[rtreffer]

If both are NATed, how would you initialize a transfer?

Both would either have to keep a relay connection opened or keep state on the tracker and poll that....

On 26. August 2014 08:46:51 MESZ, Pascal Mathis notifications@github.com wrote:

I understood what you've meant, @rtreffer. In the older versions though, all these NAT traversal or full-relay things were the job of the relay server. Maybe they've changed that too, although it doesn't make that much sense when thinking about the BTSync infrastructure. We'll see, Wireshark might expose the truth :)

---

Reply to this email directly or view it on GitHub: https://github.com/NeoXiD/sync.io/issues/2#issuecomment-53381640

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[ppmathis]

In the older protocol versions, both NATed peers would have first connected to the tracker via UDP. This had always worked (except when outgoing traffic was blocked), as there was only a communication between each peer and the tracker, without anything inbetween. Each time a peer announces itself to the tracker, the tracker distributed a list of all peers to each peer. That list contains the local address (LAN) and the remote address (WAN) of each peer.

Now the BTSync peers tried to communicate to each other with the IP addresses they've received. If they were not able to build up a connection to each other, they've both contacted the Relay server, which tried to do NAT piercing / traversal and other things to bypass firewalls.

That old protocol had two server types, both served by UDP: The tracker server and the relay server. However, the current state of the protocol is:

• Relay Server: TCP & UDP connection
• Tracker Server: TCP & UDP connection
• Mobile Push Proxy: TCP, maybe UDP too - unsure.

So far, I've reversed the new TCP tracker protocol, but I still have to take a look at all the others. As I currently focus on the tracker server though, I'm trying to find out for what this UDP connection is used.

[almereyda]

This is starting to read like a crime story :) Big ups for all your (allowed!) reverse engineering. I hope you learn a lot for yourself.

[almereyda]

It's interesting to think about how sync.io could help mitigating the drawbacks of the new Bittorrent Sync clients as found by http://2014.hackitoergosum.org/bittorrentsync-security-privacy-analysis-hackito-session-results/:

5. TL;DR & Conclusions

• Probable leak of all hashes to getsync.com and access for BitTorrent Inc to all shared data.
• Change of sharing paradigm that introduced this vulnerability happened after the first releases. This may be the result of NSL (National Security Letters, from US Government to businesses to pressure them in giving out the keys or introducing vulnerabilities to compromise previously secure systems) that could have been received by BitTorrent Inc and/or developers.
• Leak about the private network addresses of clients that gives indication about where and what to attack.
• Probable multiple vulnerabilities of the clients.
• Bottom line: Do not use for sensitive data.

[ppmathis]

@almereyda I'm still alive, although the project isn't really active anymore. I was able to reverse the TCP tracker protocol some time ago, but I still don't have any idea what the other protocols are doing. There is also the problem that I'm using a nasty DNS hack, if the client should ever start grabbing the configuration from HTTPS and then checking against the certificate fingerprint, no one is going to be able to use a private tracker.

To cut a long story short, I'm no longer sure if that project is reasonable. BitTorrent Inc. never gave me the permission to do so, they just said sth like "it is fine for now". Also, the client is kinda similar to a blackbox -> All the sourcecode is encrypted, no one knows which ciphers are being used, no one exactly knows which hash goes to what place and so on.

Also, I'll never be able to support private trackers on Android/iOS for example. I was able to modify the binary, but that's already against the ToS. I think the best solution would be a opensource solution which does not rely on any closed source products.