Hack the Planet - TeamSpeak server

[fyfywka]

Ever heard of an event loop?

ok, how do you imagine the sound transmission through the php?

 

[MazeMcRoy]

get packet > process packet > send packet

 

[fyfywka]

that is, someone able to decipher traffic teamspeak?

 

[why-am-i-even-here]

Did you even read this thread?

The whole time we've been talking about how they in fact did manage to crack the encryption.

 

[MazeMcRoy]

well, I am.
Look at my other post's I shared an lib so you guys can actually look at the decrypted packets. Ofc voice is binary stuff and can't be read. But you could in theory grab that packet remove some userid stuff and replay it. But hell who am I talking too?

 

[why-am-i-even-here]

Also, just for the fun of it, this.

 

[MazeMcRoy]

it depends on the used codec. celt is also wide spreaded. Or opus ..

 

[self.add()]

Anyway. You're talking about patching the code, which I mentioned in my reply. This isn't basic memory manipulation with which you can only change simple data values.

Your PoV implies that memory editing != patching the code.
Which is rather interesting since that's exactly what you do.

Okay, then tell me: how would you go about setting the channel commander flag for every client? Keep in mind that the flag doesn't switch. It's set to channel commander right away.
Or even harder: how would you add the "Seclevel xx" client description. It displays the actual security level of the client identity.

I don't know if you have ever heard of jmp OP codes. But the server does a check if you have the Channel Commander. You jmp this check to always grant you Channel Commander. Not a big deal.

As for security level. I found it pretty interesting at first until I found the description part. You can literally make the description jmp to the sec level of the specific client. This will make your security level appear as description instead of the actual description (which won't be shown if it's "not set").
You could also make this appear only in case no description is set.
This requires finding a general ptr for the client but that's not too bad.

Either way. They may be working on writing their own server. But I won't believe that until I see actual proof.
All I know is that everything the HTP Server has CAN be done my memory editing.

 

[MazeMcRoy]

pft
Okay .. You got me. At first i thought you were serious. But now I can smell the troll.
Throwing in words like jmp op code etc might impress some people but every who actually know how reverse engineering works will you start laughing. Or crying. In first case perhaps both. You cant jump straight across the memory. You need to save register etc. All that would be such an incredible amount of work. Just for a commander stat? Come on. You can do better trolling than that.
But good news for you. You can proof now that I am wrong and you are awesome.
Just do some very basic noobish shit. That nooby commander stuff. You said its easy, For god sake please do it!

 

[why-am-i-even-here]

Your PoV implies that memory editing != patching the code.
Which is rather interesting since that's exactly what you do.

Yes, that's exactly my standing. There is a clear difference between changing values in the heap memory and actually patching the code while the process is running. Don't pretend there's not.

As for security level. I found it pretty interesting at first until I found the description part. You can literally make the description jmp to the sec level of the specific client. This will make your security level appear as description instead of the actual description (which won't be shown if it's "not set").
You could also make this appear only in case no description is set.

lol nope. First off, the security level is stored as an integer. You can't just append an integer to a string without casting / transforming it first. You won't find "Seclevel xx" as a string anywhere in memory, so you can't possibly "jump" there.
Furthermore, you cannot edit your or other client's descriptions, although you have the required permissions to do so.

This requires finding a general ptr for the client but that's not too bad.

You forget, that the memory would have to be manipulated before the packets in question are assembled and transmitted, as subsequent changes will have no effect in the client view.

Are you absolutely sure, that you really know what you're talking about? Because right now it seems like you're just throwing around buzzwords.

 

[self.add()]

pft
Okay .. You got me. At first i thought you were serious. But now I can smell the troll.
Throwing in words like jmp op code etc might impress some people but every who actually know how reverse engineering works will you start laughing. Or crying. In first case perhaps both. You cant jump straight across the memory. You need to save register etc. All that would be such an incredible amount of work. Just for a commander stat? Come on. You can do better trolling than that.
But good news for you. You can proof now that I am wrong and you are awesome.
Just do some very basic noobish shit. That nooby commander stuff. You said its easy, For god sake please do it!

The fact that the channel commander is literally just a check if you have it and is ONE point in the memory - which can be inverted or just straight put to be always true. Which can in fact be done by a jump. This will end up showing everyone as a channel commander. Seems like your knowledge on that isn't so great.
It's harder for security level which - as I said would require you to have the specific ptr.

Yes, that's exactly my standing. There is a clear difference between changing values in the heap memory and actually patching the code while the process is running. Don't pretend there's not.


lol nope. First off, the security level is stored as an integer. You can't just append an integer to a string without casting / transforming it first. You won't find "Seclevel xx" as a string anywhere in memory, so can't possibly "jump" there.
Furthermore, you cannot edit your or other client's descriptions, although you have the required permissions to do so.


You forget, that the memory would have to be manipulated before the packets in question are assembled and transmitted, as subsequent changes will have no effect in the client view.

Are you absolutely sure, that you really know what you're talking about? Because right now it seems like you're just throwing around with buzzwords.

Well I want to see you patching the code without changing anything in the memory.
That sounds rather interesting - but I guess we are just not really having the same definition on that.

I didn't say you could change the description. I said you could make it to only appear like that in case no description is said - not talking anything specific about HTP.
Which doesn't really apply since you say they make their own server, while I say this is no proof to me since it's possible by memory editing.

Also bringing in manipulating packets at this point makes literally no sense. Since everything send FROM the manipulated server would apply to the packets as well. Therefore not having a reason to manipulate them AFTERWARDS anyway because they are created with already manipulated information.

And with your last question we are at the same point as we have been before.
HTP doesn't have ANY proper proof they are really creating their own server - It may be possible but it's not for certain, like @Asphyxia said.
Which is like this since everything they "have" can be done without the need of a "new" Server.
Memory editing or patching the code (however you want to call it) can do this.

And yeah I've got several years of experience in game-hacking and recreating game servers.
Where I needed to RE and manipulate game memory. So yeah.

I'll just stop discussing this here - it doesn't lead anywhere anyway.

 

[why-am-i-even-here]

It's harder for security level which - as I said would require you to have the specific ptr.

You can literally make the description jmp to the sec level of the specific client.

What now? You still need to create the "Seclevel xx" string. Even if you got hold of some "magic" pointer.

 

[MazeMcRoy]

Yeah i dont know my shit. Where is your decryption? Where is you fully decrypted packet dump?
Btw that stuff was a lot easier than everything you are trying to do xD
Well maybe its possible to gain channel commander with some memory editing. I havn't looked at the packet yet neither the disasm (disassembled "for you").
Now lets get serious. You want to JMP to a ptr? Or to an offset? What do you think the code will do after? Magically return to your old position? So you might want to use a CALL... But that wont help you. The only serious way to do so would probably be using a straight MOV EAX, 1 or something like that. I guess channel commander will be just a boolean type.
Next question, as I am dumb and don't know what to do, you have an JMP XYZ which will produce channelcommander = 0. How will you patch the code so that it will produce channelcommander = 1? Using JNZ? Well yeah :-/ How do you know that your opcode will fit the given size? I mean jmp can take from 2 to 6? bytes.
And remember. JMP is relative. What do you do if the size is bigger? Yeah okay that was easy. NOP ..
But yeah.. You know that ofc. Anyway i like to see a method with a JMP Seriously.

 

[why-am-i-even-here]

@self.add() it would be great if you could not edit your posts, but write new posts, when you've forgotten something or changed your mind on something. Especially after we have replied to you.

I'll just stop discussing this here - it doesn't lead anywhere anyway.

Yeah, right...

 

[why-am-i-even-here]

I didn't say you could change the description. I said you could make it to only appear like that in case no description is said - not talking anything specific about HTP.
Which doesn't really apply since you say they make their own server, while I say this is no proof to me since it's possible by memory editing.

But I asked this exact question and this whole thread is about HTP. If everything is so easy and possible by only editing some values here and there, then how did they generate this dynamic description? Don't give answers to questions I didn't ask - we can't have a conversation like that.

Also bringing in manipulating packets at this point makes literally no sense. Since everything send FROM the manipulated server would apply to the packets as well. Therefore not having a reason to manipulate them AFTERWARDS anyway because they are created with already manipulated information.

You brought packet manipulation to the table, not I. And in the post you've quoted I wasn't in fact talking about manipulating packets. I was talking about editing the memory before a packet is assembled by the server.

And with your last question we are at the same point as we have been before.
HTP doesn't have ANY proper proof they are really creating their own server - It may be possible but it's not for certain, like @Asphyxia said.
Which is like this since everything they "have" can be done without the need of a "new" Server.
Memory editing or patching the code (however you want to call it) can do this.

The whole time you're claiming that everything they do on that server is possible with trivial memory hacks and code patching, yet you still did not explain how to dynamically set the description using these techniques.

You need detailed knowledge of many intricacies of the code to be able to do such things via code patching, which again brings me back to my original point. If you have that much knowledge, you might as well just implement the server.

There are only two big problems in reversing the protocol. One is the encryption, the other one I won't discuss. Once you've cracked these problems, you basically only have to re-implement the ServerQuery protocol with a few additions here and there, which really is no hassle.

 

[self.add()]

Yeah i dont know my shit. Where is your decryption? Where is you fully decrypted packet dump?
Btw that stuff was a lot easier than everything you are trying to do xD
Well maybe its possible to gain channel commander with some memory editing. I havn't looked at the packet yet neither the disasm (disassembled "for you").
Now lets get serious. You want to JMP to a ptr? Or to an offset? What do you think the code will do after? Magically return to your old position? So you might want to use a CALL... But that wont help you. The only serious way to do so would probably be using a straight MOV EAX, 1 or something like that. I guess channel commander will be just a boolean type.
Next question, as I am dumb and don't know what to do, you have an JMP XYZ which will produce channelcommander = 0. How will you patch the code so that it will produce channelcommander = 1? Using JNZ? Well yeah :-/ How do you know that your opcode will fit the given size? I mean jmp can take from 2 to 6? bytes.
And remember. JMP is relative. What do you do if the size is bigger? Yeah okay that was easy. NOP ..
But yeah.. You know that ofc. Anyway i like to see a method with a JMP Seriously.

We are talking about a different part here. I said jmp the check. Alternativly you could invert the check.
You are talking about what happens if you are already in the check - Sure you can have it check and turn the condition to wanted output.
But why would you want to overcomplicate it?
And you don't really need to bother to much about size - you can allocate memory somewhere else - jump there and execute your script - which can also include reading values from ptrs and similar. afterwards jump back to the original code.

Granted - this includes writing code for it. But it's not rewriting the whole server and you have a running base. No need to break any encryption or similar.
This can also make you able to do the sec level description.
From the desc part jump to your script part which "returns a description" with reading the sec level from the ptr for the called client (this requires work - I agree) and after that jmp back to the part where it would send the desc info.

There is really no need to go into detail on that again since it will end up being exactly like it was before.

@self.add() it would be great if you could not edit your posts, but write new posts, when you've forgotten something or changed your mind on something. Especially after we have replied to you.

I am not editing my posts because I am changing my mind. I change them to include replies that have been made while I was writing my post to include those - rather than double posting like you do.

Yeah, right...

See this doesn't lead anywhere. We have different standpoints on this.
I am saying that you can do all of it via memory editing. Something may be more complex but it's possible.
It still seems more likely than rewriting a server and having to break the encryption.
I am not saying they aren't doing that. They may be. I am just not believing it until I've seen actual proof.

The whole time you're claiming that everything they do on that server is possible with trivial memory hacks and code patching, yet you still did not explain how to dynamically set the description using these techniques.

See above.

You need detailed knowledge of many intricacies of the code to be able to do such things via code patching, which again brings me back to my original point. If you have that much knowledge, you might as well just implement the server.

Funny how I have to go into detail about how it's done while I don't see any detail on the HTP Side of that being done. As in decrypted protocols and packets. etc.

Anyway - I wanted to stop discussing this non sense - There is no reason in arguing.
I have my standpoint and you have yours. Until any proof is released on it being a php written server I won't believe in it.

 

[why-am-i-even-here]

Granted - this includes writing code for it. But it's not rewriting the whole server and you have a running base. No need to break any encryption or similar.
This can also make you able to do the sec level description.
From the desc part jump to your script part which "returns a description" with reading the sec level from the ptr for the called client (this requires work - I agree) and after that jmp back to the part where it would send the desc info.

Take a step back. Then look at this whole process.

They did not add one or two little hacks that already require a lot of work. They implemented a whole load of new stuff. The amount of work needed to go through the asm code and analyze all stack frames is insane. The fact that the server is multi-threaded makes it even worse. You'll see what I mean, when you try to go through it step by step.

That "running base" really is nothing. Think about what few tasks the server actually has to do.

It is infinitely more efficient to only crack the encryption and the one other problem I mentioned, and then just re-implement the server as a whole (or the parts you actually use). There is no way they did this whole bulk by memory hacking and code patching.

Also, take into account that it's very likely that many, if not all, code pointers change with every update. If they used the original server, this would mean they had to redo a significant part of their work for every update. Otherwise, they'd be vulnerable to old exploits.

 

[self.add()]

Take a step back. Then look at this whole process.

They did not add one or two little hacks that already require a lot of work. They implemented a whole load of new stuff. The amount of work needed to go through the asm code and analyze all stack frames is insane. The fact that the server is multi-threaded makes it even worse. You'll see what I mean, when you try to go through it step by step.

That "running base" really is nothing. Think about what few tasks the server actually has to do.

It is infinitely more efficient to only crack the encryption and the one other problem I mentioned. There is no way they did this whole bulk by memory hacking and code patching.

So you agree it's possible doing this via memory editing and code patching?
I agree it's possible to rewrite the server. And it may be more efficient once breaking the encryption is done. I have done this in game servers before.
But breaking the encryption usually includes trying to reverse parts of the the code by looking into the memory. Also sniffing the packets. Analyze structures. Order headers and similar things. Having the server being able to decrypt and work with received packets and creating proper answers and encrypting them again.
Doing this by editing the memory saves the work of breaking the encryption but still makes you able to add certain features.

Also, take into account that it's very likely that many, if not all, code pointers change with every update. If they used the original server, this would mean they had to redo a significant part of their work for every update. Otherwise, they'd be vulnerable to old exploits.

Talking about editing posts...

Sure you would have to redo a significant part rather than finding and fixing the exploit.
But if you have done that before (and you probably have done it multiple times by then) you will find an efficient way of doing that. And you may actually be able to fix certain exploits on the "old version".

 

[MazeMcRoy]

Okay one thing thats kinda proof The original teamspeak server splits and compresses the packets if they get too big.
HTP just splits the packets. You can look at your own if you dont believe me. And dont tell me they memory edited it that way. That wouldn't make any sense.

 

[why-am-i-even-here]

So you agree it's possible doing this via memory editing and code patching?

In theory yes, just like I could turn notepad.exe into GTA V. Practically no; the amount of work required is to big.

But breaking the encryption usually includes trying to reverse parts of the the code by looking into the memory. Also sniffing the packets. Analyze structures. Order headers and similar things. Having the server being able to decrypt and work with received packets and creating proper answers and encrypting them again.
Doing this by editing the memory saves the work of breaking the encryption but still makes you able to add certain features.

I never claimed that this wasn't their actual workflow. It most likely was. However, I'm talking about the finished end product: a self-written re-implementation of the TS server, and parts of the client fyi.

The original teamspeak server splits and compresses the packets if they get too big.

btw, that's the "one other problem" I was talking about.

This and the encryption. Everything else is trivial stuff. Just like writing a telnet server.