TeamSpeak 3 Protocol

[Asphyxia]

It has come to my attention that not enough research has been put into decryption of the TeamSpeak 3 protocol. The TeamSpeak 3 protocol is proprietary, you may already know this.

TeamSpeak 3 runs via UDP (9987 by default), while UDP is the low-level protocol being used for connections to a TeamSpeak 3 server, the high-level protocol is the TeamSpeak 3 proprietary one. So when you connect to a server, it works like this:

1. You click on Connect.
2. Your client knows the TeamSpeak 3 proprietary protocol and sends the information encrypted for the TeamSpeak 3 protocol.
3. The information is exchanged via the low-level protocol UDP.

This makes it harder than if TeamSpeak 3 just used UDP to exchange the information. They likely did this for many reasons, mainly security. The good thing is that although they have added this security, it is POSSIBLE to work around it.

There are a few examples of why someone would want the TeamSpeak 3 proprietary protocol encryption/decryption method, here are some.

• Make fake connections to a server, filling up user slots. This would disallow other users from joining if full.
• Make a complaint/report bot, 5 bots join a server and report a specific client resulting in a 20 minute ban by default.
• Allow opensource programs to connect to TeamSpeak 3 servers (Mumble) or even make your own TeamSpeak 3 protocol if you really wanted.
• Send false information to the server just for fun --- have a 1337 ping or never be idle.

So, why this announcement? I am calling for anyone and everyone to get involved, only if desired. Go grab Wireshark, WireEdit, mmBBQ --- analyze the TeamSpeak 3 protocol and see if you can figure out how the protocol encryption works. If you find anything, please message me the information. For any correct information, VIP will be rewarded.

This is an interesting post about TS3 encryption: https://archive.is/rUTmb
This will definitely be useful also: http://www.blizzhackers.cc/viewtopic.php?p=4597974
This demonstrates listening to a VoIP conversation with Wireshark: https://cyberarms.wordpress.com/201...g-to-voip-conversations-from-packet-captures/

 

[Asphyxia]

Here is the easiest attainable goal right now: Using mmBBQ and the linked tutorial, attempt to extract the raw commands for sending a report (complaint) to a client in a server. Once successful, attempt using LUA script to automate 5 different connections to the server (different product id/different user id), automatically report the user --- 5 total times of course, to simulate how the standalone version will work.
I hope this makes sense to everyone interested in this.

I'm coining this methodology for a TeamSpeak 3 auto-ban a R4P3 Ban and rightfully so, we'll be at the frontier of development for this automatic ban execution via script. The fifth bot making the complaint could optionally poke the victim or send them a private message prior to sending the report.

 

[ehthe]

I'm interested in this, but couldn't reproduce the tutorial linked. The one shot breakpoint fails for me on windows7 (access violation). I'll have to try on XP.

 

[Asphyxia]

I ran into the same issue ehthe, a while back I finally managed to get it working somehow and I'm trying to figure out what I did. As soon as I figure it out again, I will post up a tutorial on the forum on how to set it up. Hopefully it works on Win XP for you.

If I remember correctly I was using an old client and old server --- which is probably of no help. I wonder if they have implemented some protection against mmBBQ of some sort, if so we will have to figure a way to bypass that in the new TeamSpeak 3 client binary.

 

[Supervisor]

mhm, the tut is for 3.0.8.. I guess TeamSpeak managed to fixx this breakpoint, I'll try it, too

 

[Asphyxia]

I am making some slight progress with Supervisor, we're pretty much to the last step in decrypting the latest TeamSpeak 3 client/server connection. Upon completing this task, I will quickly get to work on writing some LUA Script which will allow for someone to enter an IP and Client ID to be automatically reported 5 times with 5 fake users (upon connection, 5 separate false user IDs and Product IDs will be provided). Eventually the goal that me and Supervisor came up with is to have this automated on a web-server, so you can do this through a web control panel or TeamSpeak 3 plugin (right click user, click R4P3 ban). The plugin should send the information including the server address, victim's Client ID and the server will initiate the request.

 

[Supervisor]

I was able to reproduce it with the Client_3.0.8.1
Having some troubles to get the 3.0.16 working

 

[Asphyxia]

http://www.tomsguide.com/faq/id-2119014/fix-access-violation-address-error.html

We're getting access violation errors, in the new version of TS3 --- really fucking annoying. Anyone have any ideas? I think they locked down the addresses to try to prevent decryption of the protocol in the newer clients. This won't make it impossible, just more work I think haha.

 

[Supervisor]

I did get the errors in 3.0.8.1, too. I think we should try to get the mmBBQ 3.0.1

 

[Asphyxia]

I hope mmBBQ 3.0.1 helps us out, I will do my best to get it.

 

[Asphyxia]

This right here demonstrates the 5 complaint ban:

All that is needed is:
"C:\Program Files (x86)\TeamSpeak 3 Client\ts3client_win32.exe -nosingleinstance" launch TeamSpeak like this with
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion --- "ProductId" blank.

It's kind of tricky to figure it out, if anyone wants to make a better tutorial on how to do it, feel free to do so. You need 5 separate Unique IDs also, because can't report from same Product ID and can't report from same User ID. Good luck to anyone testing it out, lol.

An alternative to doing this all through the TeamSpeak 3 protocol is to inject/hook TeamSpeak 3 with our own DLL. Which that DLL could provide access to send commands to the TeamSpeak 3 binary such as "Connect to server address, 127.0.0.1 with User ID 1, report client ID 156161651561" --- then move on to the next client. If we got that working, I would be impressed. But it would give us the same functionality as what we are aiming for.
Could even inject in the automatic spoofing of the Product ID, to not worry about that. It really would be amazing to get this working. Then we could run a Windows server with everything configured/setup properly... where the 5 bots all connect to an IP address, send a complaint against a user by client id, like client id 123 or whatever. Then we could connect from R4P3.NET to that Windows machine setup to automate banning complaints. That would be...... WILD as fuck.

 

[Hexboy]

Alternatively to above you could run different instances in sandboxie.
I'm a professional developer, what you are attempting to accomplish shouldn't be too hard, I'm going to start looking into it now, I'll keep you posted.

 

[Asphyxia]

Alternatively to above you could run different instances in sandboxie.
I'm a professional developer, what you are attempting to accomplish shouldn't be too hard, I'm going to start looking into it now, I'll keep you posted.

Your help would be greatly appreciated, I look forward to hearing of anything you may figure out.

 

[Hexboy]

Your help would be greatly appreciated, I look forward to hearing of anything you may figure out.

So, from what I have gathered..

You can send one ban from the query on port 10011, regardless of IP, then send the others via proxied bots.
I have written an interface to extrapolate the id's to usernames and hooked that to the GUI, fired up a bunch of AWS instances (as I have corporate account with an undisclosed provider) to kick via the current interface using something like your method.

I think it's possible to go one step further as I can mask the UID that the query server uses and do it completely from there, thus avoiding detection.

In my one day of probing there seems to be a lot of underlining issues with there protocol, for this reason I am more than happy to write something to exploit this..

FYI - Slightly drunk!

 

[Supervisor]

You don't even need multiple IP's as all they connect to your complaint is the UID and the Windows UID/Linux stuff

 

[Hexboy]

To connect to the query port it seems you do need a different IP.
Are you the dude I spoke to on Teamspeak?

 

[Asphyxia]

To connect to the query port it seems you do need a different IP.
Are you the dude I spoke to on Teamspeak?

I'm the dude you spoke with.
All you must do in order to make multiple reports (complaints) from the same IP is: Have a different User ID (5 different identities for the 5 different reports), you also need 5 different Windows Product IDs. You change this Windows Product ID in your registry.

 

[Supervisor]

Mhm, thats strange.. and no, I think that was not me you spoke with on TS.

 

[Hexboy]

I'm the dude you spoke with.
All you must do in order to make multiple reports (complaints) from the same IP is: Have a different User ID (5 different identities for the 5 different reports), you also need 5 different Windows Product IDs. You change this Windows Product ID in your registry.

Ok, I was unable to replicate that using the method you suggested so I simply ran a bunch of instances with different ips.

 

[Asphyxia]

I can make a video tutorial later on today showcasing exactly what needs to be done to recreate what I showcased in the video when I was banning people.