TS3 Protocol

[Splamy]

Hey R4P3 Community,

I am currently working on an open source, completely free, plugin-extensible, TS3 music bot (<link for those interested>, but the setup is really annoying so i can't recommend it for now)
Recently I wanted to eliminate the ts3client and write my own one with udp sockets.
For that I spent the last ~2weeks reverse engineering the client, but I'm only making slowly progress.
Calls to libtomcrypt are constantly shuffled and optimized
"c:\\windows\\system\\firewall32.cpl" made me ragequit for a few days...
etc..

So I found your existing Bot https://r4p3.net/threads/teamspeak-bot-v0-3-2.707/ and since it works(/worked) it seems you are probably farther than me right now.
I'd like to ask if you are willing to share informations on the connection/data protocol since this would boost our development hugely.
If you say VIP only I'm fine with donating a bit too ^^.

Just to be clear, I will continue reversing anyway. I just wanted to ask here before to maybe spare me some time if someone already knows something.

Greets Splamy

 

[Kaptan647]

Yes we do have the teamspeak protocol but problem with sharing it is because it would be dangerous. We found a lot of exploits because of we can manupliate the protocol. If we share it to public then more people can find more bugs and crashes and uses them maliciously maybe even sell them. This protocol can hurt a lot of people if a black hat gets his hands on it. We report all the exploits we found to teamspeak before we share them. These are my thougts but i cant make this decision alone. It must be made by all of the team members.

 

[Splamy]

Yes we do have the teamspeak protocol but problem with sharing it is because it would be dangerous. We fond a lot of exploits because of we can manipulate the protocol. If we share it to public then more people can find more bugs and crashes and uses them maliciously maybe even sell them. This protocol can hurt a lot of people if a black hat gets his hands on it. We report all the exploits we found to teamspeak before we share them. These are my thoughts but i cant make this decision alone. It must be made by all of the team members.

First of all, thanks for your reply.
I do understand that this might be a security problem, but the more I research on TS3 the more I realize how they only practice security by obscurity, and I really disapprove on that.
Generally speaking open source Projects are equal or even safer than closed source ones since more people can verify the correctness.
But from what we see in the past collaboration with ts gmbh usually doesn't go pretty well and fixes are coming slowly. So yeah, it is a two sided coin
EDIT:
As to a recent Explanation from derp, I have to add that I'm definitely not far enough with the reversing to make thoroughly correct answers. This means my answers are based on what I can confirm plus assumptions from that vantage point.

 

[Splamy]

A quick update: My own client works now too. And I will make the protocol public in some time... so yeah.
A little side note: the encryption is actually pretty solid, mark me surprised, i actually didn't expect that...

 

[theshark556]

good Job.

 

[RSX]

A quick update: My own client works now too. And I will make the protocol public in some time... so yeah.
A little side note: the encryption is actually pretty solid, mark me surprised, i actually didn't expect that...

Even though this is kind of an old thread, for fuck sake, don't. Taking into consideration stupid shit like sending bad opus packets can crash the entire win server, you will release hell.

> I do understand that this might be a security problem, but the more I research on TS3 the more I realize how they only practice security by obscurity, and I really disapprove on that.

Yes, because inappropriate disclosure and releasing hell can be justified with 'xd ur stupid for relying on sob'

 

[Splamy]

Guess what, the implementation is actually public for 'bout 4 months now, and what happend? Nothing. Guess not everybody is an asshat on the internet just out to destroy everything. With my publication I want to improve ts and make it more accessible. I even report all bugs I can find instead of making them public. Ever realized that open source project are so secure because everybody can contribute finding problems? How can you know that not someone else has reversed ts and is now using it maliciously but nobody knows it because we dont even know there is a security issue. Just crashing a server can be fixed with a patch, remote code execution can inject stuff for a long time before someone finds it.
Also if you've read my second sentence you quoted, you would realize that your last sentence doesnt make any sense.

 

[Asphyxia]

Security research requires risk. Open source projects are awesome, they allow for more opportunities. Proprietary software stunts innovation and oftentimes once reversed, we see stupid security obscured. I support taking things apart for digital biopsy/autopsy.

 

[RSX]

Guess what, the implementation is actually public for 'bout 4 months now, and what happend? Nothing. Guess not everybody is an asshat on the internet just out to destroy everything. With my publication I want to improve ts and make it more accessible. I even report all bugs I can find instead of making them public. Ever realized that open source project are so secure because everybody can contribute finding problems? How can you know that not someone else has reversed ts and is now using it maliciously but nobody knows it because we dont even know there is a security issue. Just crashing a server can be fixed with a patch, remote code execution can inject stuff for a long time before someone finds it.
Also if you've read my second sentence you quoted, you would realize that your last sentence doesnt make any sense.

> Guess what, the implementation is actually public for 'bout 4 months now, and what happend? Nothing
Arguably, it's due to the lack of attention your project has got. Take into consideration out of all the spammers and/or potential attackers on teamspeak, 34 out of all of them is hardly anything.

> Guess not everybody is an asshat on the internet just out to destroy everything
A good portion of people are. Especially, if you start looking on here.

> With my publication I want to improve ts and make it more accessible
As for this so-called publication, I've not seen any resources posted from you explaining the ts protocol.

> Ever realized that open source project are so secure because everybody can contribute finding problems?
Don't start this bullshit iOS vs Android war. Taking into consideration most people will admit that closed source does make it harder to research, it should also be a fair assumption that if it's harder to research, it's harder for people to abuse problems. Research groups are a thing. Open sourcing something that could easily be used to screw with hundreds if not thousands of servers is another thing.

> How can you know that not someone else has reversed ts and is now using it maliciously
That is the most retarded thing ever. Nobody ever said otherwise nor is that my point. We shouldn't know the abuse stats nor is there any reason to collect information on what client has issued what malicious request. My point is that you're just aiding incompetent skids and not the people who can RE it themselves.

> nobody knows it because we dont even know there is a security issue
I'm sorry, what? Are you the person patching it? Oh, wait, no you're not. There's no reason for a non-teamspeak dev to know how to reproduce an issue unless you want to go out of your way to abuse it.

> Just crashing a server can be fixed with a patch
....So?

> remote code execution can inject stuff for a long time before someone finds it.
And your project helps detects malicious binaries dumped on someone's box how?

 

[Splamy]

I shoudnt even have bothered.. At this point you only show ignorance with your post...

 

[RSX]

Security research requires risk. Open source projects are awesome, they allow for more opportunities. Proprietary software stunts innovation and oftentimes once reversed, we see stupid security obscured. I support taking things apart for digital biopsy/autopsy.

Whilst that is a fair argument, you've also got to consider how unstable it is and how you're helping abuse. Maybe later down the line when ts3 is more stable, open source stuff will be great, but at this moment in time, there's simply too much that can be abused.

I shoudnt even have bothered.. At this point you only show ignorance with your post...

Ignorance can easily be detected by someone who's going 'Blah blah blah. i'm not listening nor am I going to respond nor am I going to learn.' I'm providing the argument and you're the one acting ignorant by refusing to debunk or otherwise hurt my claims by a correction or otherwise.

 

[Splamy]

ALSO EDIT: Maby i wasn't quite clear enough explaining why I think your post shows ignorance. You deconstruct my post into single sentence meanings, but fail to address my intention with the project.

> Arguably, it's due to the lack of attention your project has got.
So doesnt this actually prove my point, that noone cares about destroying everything?

> As for this so-called publication, I've not seen any resources posted from you explaining the ts protocol.
I meant publication in the sense of making at least something public. Also I'd say my code is ok enought to be read and espesially the crypto part is pretty well documented.

> Don't start this bullshit iOS vs Android war
??

> That is the most retarded thing ever.
No, I wanna fucking know that the software I use on my severs is secure, and when ts systems wont do anything, someone has to push it. Also regarding "Especially, if you start looking on here." no, the r4p3 team does not release any crashing source before reporting to ts sys and giving them disclosure time.

> I'm sorry, what? Are you the person patching it?
No but I have contact with teamspeak devs and I will report everything that I can reproduce, and I hope so will others too.

> And your project helps detects malicious binaries dumped on someone's box how?
You know what I meant...

Appednum:
>screw with hundreds if not thousands of servers
oh yeah sure i can see the infrastructure apocalyse is comming... /s Script kiddies will always stay script kiddies, and releasing the source wont change anything. It's not like the server is complete trash, they had tons of patches already fixing stuff before.

Also I'm not making the ts3 server public but the protocol. Lets try to make that secure what has to be secure. If RE specialists want to find bugs and exploits like buffer overflows and segfaults in the sever they still can, I haven't made a single line of the ts3 server code public.

 

[Kepler]

Hey Splamy,
You did a very good job on TS3AudioBot. I've been trying to understand how everything works and maybe contribute to it, but coming from Python and JS I feel a bit lost and stupid. Can you point me a good place to start in your code?
I was able to understand some basics of the functions in Ts3Crypt.cs, but it's pretty hard to find information for BouncyCastle in C#. I was wondering if you could/would help me : P.
Cheers!

 

[Splamy]

...

Sure. So you mentioned the TS3AudioBot as well as the crypto part and the whole project is actually not that small anymore. So what would you like to dig into?
Regarding the crypto: Yes BC is not very well documented, thats why I tried to document a lot in my crypt code. But I know that doesnt help that much if you want to understand the whole structure. Basially the full client works with the query protocol under the hood. That was the reason for me to create a uniform structure and offer both types (full/query) with the same library.
There are two aspects about the full client, the extended query plaintext protocol and the udp packet handling.
To get a basic understanding of the extended protocol the full client is using there are two interesting locations. One at Ts3FullClient.NetworkLoop() the message field and Ts3FullClient.SendCommand com.ToString(), when you print both to the console you should get a nice log of whats going on.
The udp packet handlig is a bit more complex since it covers (fake-)encryption, counting/order, splitting, de-/compressing, packet loss, keep alive pings, acknowlegements and other stuff. As mentioned in my first post, I intended to write a little (not so formal) rfc-like document, but I didn't get to it yet. If you want to get a more in depth explanation, pm me and ill get in touch with you on my server, since writing a full explanation would probably take as long as writing the rfc paper itself.

 

[NoXx]

...
> With my publication I want to improve ts and make it more accessible
As for this so-called publication, I've not seen any resources posted from you explaining the ts protocol.

I've actually gone through all of his code for a Java port and it shows exactly how the TS3-Protocol gets build and with which obfuscation they work (pretty poorly from TS3 :I). Just open your eyes, no one will serve you everything on the gold plate.
And I agree to Splamy with open-source projects. It greatly increases all the security fixes which wouldn't be found if no one would release it online. From what I've seen so far, TeamSpeak always talks about high Security in their projects but all that I see are poorly implemented security patterns or obfuscation...
Projects like the one from Splamy really help making those things as they should have been done initially.


Best regards

 

[RSX]

I've actually gone through all of his code for a Java port and it shows exactly how the TS3-Protocol gets build and with which obfuscation they work (pretty poorly from TS3 :I).

And I'm supposed to take you seriously after that shit? There is no obfuscation in neither the protocol nor binaries (excl some build strings). I'll just assume your message is buillshit considering your first sentence about it is completely wrong.

> Just open your eyes, no one will serve you everything on the gold plate.

Piss off, kid. You're the one whos self admittedly leaching off his stuff. Unlike you, I can actually point out the holes in his research.

> And I agree to Splamy with open-source projects

Ye, of course you agree with him. You're clearly besties considering you share private repos.

> I see are poorly implemented security patterns or obfuscation...
Um, odd, interesting. Please, go a head, tell us how ECC + HashCash + AES - EAX was implemented incorrectly. Ohh, wait, you can't because you're just basing your shit off his private repo.

 

[Splamy]

(...)

And thats the other thing I'm annoyed about, your sensless agressiveness in a rather formal thread. What is your problem?

Also there is some kind of obfuscation in the protocol. Encrypting half of the init stuff with a dummy key serves no cryptographical purpose, especially since the pub/priv key exchange is secure enough.

 

[RSX]

And thats the other thing I'm annoyed about, your sensless agressiveness in a rather formal thread. What is your problem?

Also there is some kind of obfuscation in the protocol. Encrypting half of the init stuff with a dummy key serves no cryptographical purpose, especially since the pub/priv key exchange is secure enough.

Encryption is highly common in most (if not all modern) protocols. When you say security by obscurity, I think random xoring and making odd encryption requests to some master server. In this case, it's just a standard AES EAX implementation. And, no, hashing a shared secret before using it as a key/nonce is recommended, not SOB. Whilst the dummy keys are a bit odd, that is also common practice. Although, I respect that common practice doesn't mean it's not SOB, however, when it's not intended to protect user information and intellectual property and it takes two seconds to hook, I wouldn't call that security by obscurity.

PS: Great obscurity considering everything TS implements is over ~15 years old and not homebrewed.
https://en.wikipedia.org/wiki/EAX_mode - 2003
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard - 1998
https://en.wikipedia.org/wiki/MD5 - 1992
https://en.wikipedia.org/wiki/SHA-1 - 1995
https://en.wikipedia.org/wiki/SHA-2 - 2001
https://en.wikipedia.org/wiki/Hashcash (hardly modified - still using the same concept) - 1997

 

[Splamy]

Encryption is highly common in most (if not all modern) protocols. When you say security by obscurity, I think random xoring and making odd encryption requests to some master server. In this case, it's just a standard AES EAX implementation. And, no, hashing a shared secret before using it as a key/nonce is recommended, not SOB. Whilst the dummy keys are a bit odd, that is also common practice. Although, I respect that common practice doesn't mean it's not SOB, however, when it's not intended to protect user information and intellectual property and it takes two seconds to hook, I wouldn't call that security by obscurity.

Please keep in mind that I haven't used the term SOB, even once from the time on I was done with the reversing, this was a bad assumption from my side (see post dates respectively).
What I do say is that they do use some kind of obfuscation. Also I'm no crypto specialist, if that what you said is common practice, then I'm fine with that, it was a simple observation.

>it's just a standard AES EAX implementation. And, no, hashing a shared secret before using it as a key/nonce is recommended
I have never criticised the value hashing techniques or encrption type they have chosen.

 

[RSX]

Please keep in mind that I haven't used the term SOB, even once from the time on I was done with the reversing, this was a bad assumption from my side (see post dates respectively).
What I do say is that they do use some kind of obfuscation. Also I'm no crypto specialist, if that what you said is common practice, then I'm fine with that, it was a simple observation.

Fair enough.

>it's just a standard AES EAX implementation. And, no, hashing a shared secret before using it as a key/nonce is recommended
I have never criticised the value hashing techniques or encrption type they have chosen.

I was trying to think of anything teamspeak does that you could call potentially obscure (ie odd hashing and basing the auth flow on that. the usual stuff) . Sure, they aren't winning a best practices award, but they also aren't obtaining the worst cryptography utilization award either.