TS3 Protocol

[Asphyxia]

So, let's get this back onto the TeamSpeak 3 protocol subject. TeamSpeak 3 should be able to withstand digital terrorism --- so then if the protocol is public for all, we may all sleep safer at night skid-tested, blackhat tested, gray and white too. I say bring all ye digital warlords, bring the war to TeamSpeak 3. We can watch them "blow your fucking brains out" in response to all the security issues found.

 

[RSX]

So, let's get this back onto the TeamSpeak 3 protocol subject. TeamSpeak 3 should be able to withstand digital terrorism --- so then if the protocol is public for all, we may all sleep safer at night skid-tested, blackhat tested, gray and white too. I say bring all ye digital warlords, bring the war to TeamSpeak 3. We can watch them "blow your fucking brains out" in response to all the security issues found.

And even I think that is over exaggerated. Jesus.

 

[Asphyxia]

That would be voluntary community security checking. I think there needs to be stronger support for such a security model.
This is basically what bug bounties do, they incentivize such behavior.

 

[RSX]

Going back to the classes idea, could we at least have some spam filter to prevent those who do have bad intentions. I'm sure legitimate people with an interest in this wouldn't mind having a low - medium amount of time on this forum alongside a quiz that can be taken once a month asking silly RE questions. And, by bad intentions, I mean retarded 12 year olds that require their "team" to compile it for them, so they can make spam bots & sell them on hf for $5.

 

[Asphyxia]

Going back to the classes idea, could we at least have some spam filter to prevent those who do have bad intentions. I'm sure legitimate people with an interest in this wouldn't mind having a low - medium amount of time on this forum alongside a quiz that can be taken once a month asking silly RE questions. And, by bad intentions, I mean retarded 12 year olds that require their "team" to compile it for them, so they can make spam bots & sell them on hf for $5.

Absolutely, when I said TeamSpeak 3 protocol classes I was not joking. I have thought about the idea for a couple months.

It would not have to be too isolated to the TS3 protocol, but would be a community-developed class highlighting any present and past security risks of TeamSpeak 3 along with solutions. It could focus on for example properly sandboxing TeamSpeak 3 to mitigate the risk of full system compromise in the event of a 0day (remote code execution). It could cover the server-side of things and demonstrate packet filtration, etc. There are so many ways you could teach security by using TeamSpeak 3. It is really a perfect application to teach security classes in my opinion.

 

[RSX]

Absolutely, when I said TeamSpeak 3 protocol classes I was not joking. I have thought about the idea for a couple months.

It would not have to be too isolated to the TS3 protocol, but would be a community-developed class highlighting any present and past security risks of TeamSpeak 3 along with solutions. It could focus on for example properly sandboxing TeamSpeak 3 to mitigate the risk of full system compromise in the event of a 0day (remote code execution). It could cover the server-side of things and demonstrate packet filtration, etc. There are so many ways you could teach security by using TeamSpeak 3. It is really a perfect application to teach security classes in my opinion.

If anybody can contribute, that isn't profitable, although, those who can """teach""", should be able to share their resources.

 

[Asphyxia]

The classes would be free and a chance to earn VIP (by contributing to teaching the community). A free academic library of sorts, I think this sounds nice for all of us.

 

[tagKnife]

With a small amount of code.

 

[Derp]

With a small amount of code.

Funny enough, now you can try out this

 

[Splamy]

Funny enough, now you can try out this

huh, how? notifycliententerview is a serversided command... or do I miss something?

 

[Derp]

huh, how? notifycliententerview is a serversided command... or do I miss something?

Actually, I was talking about

client_badges=overwolf=0:badges=50bbdbc8-0f2a-46eb-9808-6022

notifycliententerview is indeed a serversided command, but you can still use

clientupdate client_badges=overwolf=0:badges=50bbdbc8-0f2a-46eb-9808-6022

 

[tagKnife]

Funny enough, now you can try out this

Still learning how to use this SDK Atm trying to make the bots join random channels. But cant find the command to get channel list and join channel.

@Splamy maybe a pointer? Also, after about 150~ bots a decompression exeption gets thrown where packet is too large to decompress, may want to look into that

currently

https://imgur.com/l9uWNm5.png

Also, once i get to learn how to using this SDK, I would like to make a TS BNC. to allow users to have a t persistent connection to a TS server and connect through the BNC, like and IRC bnc Though u dont think this is capable of server side messages yet*?

 

[Splamy]

Still learning how to use this SDK Atm trying to make the bots join random channels. But cant find the command to get channel list and join channel.

@Splamy maybe a pointer? Also, after about 150~ bots a decompression exeption gets thrown where packet is too large to decompress, may want to look into that

currently

https://imgur.com/l9uWNm5.png

Haha, yeah those werent my concerns yet, I will make many stability tests when it's more finished.

Regarding finding channel: There is no command to find the channels since the entire channel structure is sent when connecting and kept up in sync by bookkeeping.
You'd have to modify the TS3Client/Ts3BaseClient.cs InvokeEvent method and add an event for the channellist event just like the others are declared.
I'm still thinking if I should add the bookkeeping to my library or leave this to the end user, but it seems like a common pattern, so I will probably add it at some time... (I also have some code for that already, but as said not added here)

 

[tagKnife]

Haha, yeah those werent my concerns yet, I will make many stability tests when it's more finished.

Regarding finding channel: There is no command to find the channels since the entire channel structure is sent when connecting and kept up in sync by bookkeeping.
You'd have to modify the TS3Client/Ts3BaseClient.cs InvokeEvent method and add an event for the channellist event just like the others are declared.
I'm still thinking if I should add the bookkeeping to my library or leave this to the end user, but it seems like a common pattern, so I will probably add it at some time... (I also have some code for that already, but as said not added here)

alight, I just make a small php script to random move the bots when they connect. Much easyer that way

Ill open an issue on github for the decompression expeption as i assume its because of the amount of users on the TS, not because of the amount of bots I am making Maybe an issue for larger teamspeaks 300+ users
https://github.com/Splamy/TS3AudioBot/issues/51

 

[Splamy]

Also, once i get to learn how to using this SDK, I would like to make a TS BNC. to allow users to have a t persistent connection to a TS server and connect through the BNC, like and IRC bnc Though u dont think this is capable of server side messages yet*?

Sure you can, you just would have to implement your own server, and that is A LOT of work. But the crypto part should be no problem with a bit of turning around the information you have from the open src client

 

[RSX]

Also, once i get to learn how to using this SDK, I would like to make a TS BNC. to allow users to have a t persistent connection to a TS server and connect through the BNC, like and IRC bnc Though u dont think this is capable of server side messages yet*?

This is exactly the type of shit I'm talking about.
Amount of critical teamspeak issues found on this thread: 0
Amount of retarded kids copying another project and calling someone elses client/api a software development kit: 1
Amount of retarded kids thinking creating spam bots on a service that utilities hash cash is a good idea: 1
Amount of kids thinking it's a good idea to link an application that's only used for its VOIP service to a text based client: 1

alight, I just make a small php script to random move the bots when they connect. Much easyer that way

Ill open an issue on github for the decompression expeption as i assume its because of the amount of users on the TS, not because of the amount of bots I am making Maybe an issue for larger teamspeaks 300+ users
https://github.com/Splamy/TS3AudioBot/issues/51

absolutely incorrect. a bad implementation of the ts packet fragments =/= 'xdd wont work with more than 300 people in the same ts server'

Edit: The amount of users and channels doesn't mean compression will be used. Something you would know if you actually read the god damn source and dbgprinted a few things.

@Splamy if you want to fix your compression stuff, you should have implemented it like:
First packet: pid | 0x10 | 0x40 | 0x50
X packet: pid | []
X packet: pid | []
X packet: pid | []
End packet: pid | 0x10
Combine payloads then set the flags to the first one.
EG: https://txt.itsghost.me/zIpkFHaXFAwUxTy.hastebin.css(Server -> client)
Also, pid 0 is usually VOICE not 'readable'

Terminology translation:
My research || Yours
SeqId          || PacketId   
Pid/Type       || PacketType
Flags          || PacketFlags
N/A            || Header
Header         || AES EAX Tag
Payload        || Data

 

[Splamy]

This is exactly the type of shit I'm talking about.
Amount of critical teamspeak issues found on this thread: 0
Amount of retarded kids copying another project and calling someone elses client/api a software development kit: 1
Amount of retarded kids thinking creating spam bots on a service that utilities hash cash is a good idea: 1

Like I dont see your problem here, whats the deal when someone wants to use my API for that what it intented for: Being an API. It's not like I developed this thing not to be one. If you look around the forum, you see my first reason to write this was to get rid of the ts3client as an additional resource. If ts sys wouldnt make such a retarded sdk kit which is incompatiple with the rest i'd never have a reason to rewrite it in the first place.

absolutely incorrect. a bad implementation of the ts packet fragments =/= 'xdd wont work with more than 300 people in the same ts server'

Yo, thats probably a problem on my side, since I know there's somewhere a bug in the packet splitting/merging routines.

EDIT:
> Also, pid 0 is usually VOICE not 'readable'
Yeah, I know that, I left it since the ts3 devs called the constant like that, dont ask me why.

 

[RSX]

Like I dont see your problem here, whats the deal when someone wants to use my API for that what it intented for: Being an API. It's not like I developed this thing not to be one. If you look around the forum, you see my first reason to write this was to get rid of the ts3client as an additional resource. If ts sys wouldnt make such a retarded sdk kit which is incompatiple with the rest i'd never have a reason to rewrite it in the first place.

My issue isn't bots, it's retarded kids that can't even hook the client to give themselves badges are using incorrect terms, whilst attempting to ruin the experience by creating spam bots, despite hashcash is in place (which he would know that, if he wasn't such a leeching twat). Another 'SDK' or whatever type of tool kit would be nice, but when you provide code samples to kids, that is the type of shit you get. I don't see him trying to fuck with security; he couldn't even get badges to work. For fuck sake, he couldn't even get sending messages to work, and that's documented by teamspeak themselves. I mean, common, he is [one of] the first person(s) from here to use this and he is already abusing it. If that doesn't prove my original point I don't know what will.

 

[Splamy]

@Splamy if you want to fix your compression stuff, you should have implemented it like:
First packet: pid | 0x10 | 0x40 | 0x50
X packet: pid | []
X packet: pid | []
X packet: pid | []
End packet: pid | 0x10
Combine payloads then set the flags to the first one.
EG: https://txt.itsghost.me/zIpkFHaXFAwUxTy.hastebin.css(Server -> client)
Also, pid 0 is usually VOICE not 'readable'

Terminology translation:
My research || Yours
SeqId          || PacketId
Pid/Type       || PacketType
Flags          || PacketFlags
N/A            || Header
Header         || AES EAX Tag
Payload        || Data

Uh, unless I oversee something, that is exactly what I'm already doing?.

My issue isn't bots, it's retarded kids that can't even hook the client to give themselves badges are using incorrect terms, whilst attempting to ruin the experience by creating spam bots, despite hashcash is in place (which he would know that, if he wasn't such a leeching twat). Another 'SDK' or whatever type of tool kit would be nice, but when you provide code samples to kids, that is the type of shit you get. I don't see him trying to fuck with security; he couldn't even get badges to work. For fuck sake, he couldn't even get sending messages to work, and that's documented by teamspeak themselves. I mean, common, he is [one of] the first person(s) from here to use this and he is already abusing it. If that doesn't prove my original point I don't know what will.

If you always take the loudest people (since those are mostly the ones with the least experience) as example you sure will get these results.
I don't mind helping here or there a bit but there is no reasonable chance that anyone would release something like that in foreseeable future, especially when there are mostly people with your attitude. The whole project took me about two months including getting used to ida and asm again. This is some work the majority would not be able to do. And I think there are people which have good ideas and would benefit from this reseach, so why should I deny this to them to prevent the risk of some noise.

 

[RSX]

If you always take the loudest people (since those are mostly the ones with the least experience) as example you sure will get these results.

I didn't take the vocal minority, I took the first person on this thread that's actually using it. I mean, common, I have done absolutely nothing and my second post on this thread got proven right: https://reece.sx/WbkwBKZLtXY0s4l (point 1 & 2)

I don't mind helping here or there a bit but there is no reasonable chance that anyone would release something like that in foreseeable future, especially when there are mostly people with your attitude.

Yes, because I and many others have seen what happens first hand when you release such assets. You, someone who self-admittedly claimed to have little to no experience REing protocols and binaries that implement some kind of encryption, hasn't seen what can happen.

The whole project took me about two months including getting used to ida and asm again.

If you've got ida, you might as well be using hexrays. Two months to relearn ASM and arguably the most used, most popular, disassembler that has the most resources. ollydbg is pretty much a complex dead mess, the xdbgs have dead resource links, and ida is sitting there with everything you need. ASM is something you can learn in a few weeks with prior programming experience and isn't something you forget overnight. I'm struggling to believe it takes someone with prior experience 2 months to reverse a binary with zero obfuscation.

This is some work the majority would not be able to do. And I think there are people which have good ideas and would benefit from this reseach, so why should I deny this to them to prevent the risk of some noise.

A fair few amount of people on here can. Hate to burst your special snowflake but what you did doesn't exactly require a special skill you was gifted with.