Hey guys!
Nice website. I think you have the best collection of Paltalk related information on the net
Awesome job! My name is Aran -- I used to be really big into Paltalk when it came out back in 1998 -- I built a few clients for Linux and Windows Mobile (formerly Windows CE). Back at that time Paltalk was just text and VOIP -- no video so it was pretty simple. Anyways, while a lot of the Paltalk developers were cool, I got sick of the "i'm in charge and I don't care what you think" attitude that most of the co-admins had...so I quit Paltalk for a while. The other day one of my buddies (who uses Paltalk regularly) mentioned that Paltalk still had NOT released a client for Linux. *smacks forehead* Do they not realize its almost 2008 and Linux is quite common place these days??So...I thought since Paltalk wasn't doing anything to bring a client to Linux, I might help them out. Creating a client that supports text is the simplest task. Adding the audio codec will be the next notch. Finally, video codec will be the final component.
My first question is: Does anyone already have the Paltalk Protocol? If so, please send it to me! (It will save me time by not having to decode theirs/re-invent the wheel).
Sometimes I'm asked what a protocol is -- more than likely if you're asking this question then you're not a programmer and wouldn't care about protocols anyways :] But in short, a protocol is simply just a pre-defined way to communicate information [in the case of Paltalk, between the client and the server]. In general, protocols are widely published by those that develop them -- Hyper Text Transport Protocol (HTTP), Secure Sockets Layer (SSL), File Transfer Protocol (FTP), etc. are just a couple examples of some Internet protocols that you might have heard of. Paltalk does not publish their protocol because they would prefer to control the clients that their users connect with. I mean, if someone has the protocol, they can build a replacement client for Windows (without the spyware/adware) and all of the sudden black nicks are also getting ad-free access :] Also, if the protocol is kept secret then the company can be more lax in their security measures -- security through obscurity is always a bad idea, but many companies still practice it.
If you think you might be interested in deciphering Paltalk's protocol, I encourage you give it a shot. It's very easy to get started and also very enlightening. The first tool you need is a good packet sniffer. These days you can get really nice open source [free] tools to do the job. I recommend downloading and installing Wireshark (formerly Ethereal) (http://www.wireshark.org). Once you have Wireshark installed, look under the "Capture" menu and select "Interfaces". Then click "Start" for the adapter that you wish to spy on :] You will now see packets appearing in the list -- you can read ALL the information that is sent between your computer and those on your network/internet.
When you're using Wireshark, its best to either 1) close down any internet programs you don't want to view while monitoring (ie. close everything...instant messengers, irc, peer to peer, etc, etc.) except Paltalk or 2) set a filter in Wireshark that ignores all the data except that coming from the IP address or port(s) that you're interested in. At first you might feel a little intimidated by all the information that Wireshark provides -- don't worry. MOST of it is not needed for what we are trying to do.
Here is an example:
1) start Wireshark
2) start Paltalk and click Login
Instantly a barrage of data comes flying into Wireshark. A second later I notice that Paltalk is connected. Ok, well lets go under the "Capture" menu of Wireshark and select "Stop" so we can look through what happens when we started Paltalk. I just did this and in about 1 second I picked up 57 packets -- thankfully only about 8 of them are important.
Starting at the top of the list, I'm looking at the port numbers. These are shown under the Info heading as xxx > yyyy (that means xxx is the port for source and yyyy is the port for the destination)
Okay, so the first thing I see is my computer trying to connect to 199.106.211.53 to port 5001. If you've ever looked at the Windows Registry you have probably seen both this IP address and port before. If you change these values in the registry you can make the Paltalk client attempt to connect to a different server or port. This is handy if you make your own Paltalk server or want to spoof your login through a proxy server -- more on this later.
I need to point out that for application level protocols (like Paltalk) the only thing we care about are: Source IP, Destination IP, Ports and Data! Everything else you can IGNORE!
So the first packet I found that shows my computer 192.168.1.2 connecting to 199.106.211.53, I see a bunch of garbage in the middle (Frame 3, Ethernet II, Internet Protocol, Transmission Control Protocol -- all of that is garbage! It is information for the lower level protocols that we don't need to concern ourselves with.)
The next packet shows paltalks server 192.106.211.53 on port 5001 talking back to my computer. Since there is no "Data" section in the packet, no information that we are concerned about is being transmitted.
The third packet -- again my computer talking to the server, but no data is sent.
Finally on the fourth packet, Paltalks' server talking to my computer you will see a section labeled "Data" under Transmission Control Protocol in the center part of the screen. Click on Data (12 bytes). You'll notice that in the bottom part of the screen part of the packet will be highlighted. This IS the data that Paltalk is sending to the client. The left part of the window is a hexadecimal representation of the ASCII values shown on the right part of the screen. Basically the important part is only the hex stuff -- the ascii isn't so important.
This first part of data Paltalk's server is sending is:
ff 89 00 00 00 06 c7 6a ea 7c 45 52
If you've never done this before you're probably thinking "WTF is this crap?" It's always a good idea to save what you get and repeat the Wiresharking several times. After a couple tries you'll notice that the ff 89 00 00 00 06 part is ALWAYS the same but the c7 6a ea 7c 45 52 part changes slightly. So think about it -- we haven't sent Paltalk anything, but it wants us to know this right away. What is it for? Well, if we look at the next packet we collected we will see that it is a FIN packet (ie. the client is telling the Paltalk server we are disconnecting). But, wait! The next packet shows us connecting to Paltalk on a different IP and port! Instead of 199.106.211.53, we are connecting to 199.106.234.124 and instead of the port 5001 in the registry we are connecting to port 17746. This is a good time to start up the Windows Calculator. Start->Run calc OK. It appers, click "View" menu and choose Scientific. Okay, now at the top, make sure Dec is selected. Type in 199..now select Hex
We get an answer of C7. This means that 199 in decimal is C7 in hex. Repeat this for the rest of the IP address and we get: IP-->199= c7, 106= 6a, 234= ea, 124= 7c Port--> 17746= 4552.
Ah-ha! So the first data packet from the Paltalk server is telling the client where to connect to and on what port! This is the first part of the Paltalk protocol.
As we keep looking through the "Data" section in the packets we see our next packet from Paltalk server says ff 8b 00 0e 00 12 48 65 6c 6c 6f 2d 46 72 6f 6d 3a 50 61 4c 54 41 4c 4b
And if you look on the right hand side of the packet you'll see that a portion of that hex corresponds to ASCII characters that spell out "Hello-From:PaLTALK"
Alright, so I'm getting tired of typing, but as you progress through the login sequence you see small data exchanged between the client and the Paltalk server. What other data is exchanged? Well, obviously the client needs to tell the server the username trying to connect (you'll see it in plain text later in the packets) and of course the user's password. It's just my guess that they also send the MAC address for the computer you are using so they can block you, etc. Anyways, once you connect to the server you can see that everything is done in plain text -- no encryption at all. It's quite fun to play with.
Anyways, hopefully something up there was of interest to someone. I love decoding protocols and building clients. Yahoo uses a similar scheme but their system is more documented than Paltalks -- you can find protocol descriptions for Yahoo, AIM, MSN, IRC, etc easily online.
Other things you can do to help in decoding the protocol is to analyze the Paltalk client -- I recommend using IDA Pro or SoftICE. These tools will allow you to follow what happens during the login sequence so see what data is used and how it is transformed (ie. the algorithms) used to produce the data which is sent to Paltalk for logging in.
Some things I tried a while back -- changing the registry values for the paltalk server and port -- pointing them at a simple server that I made which basically "tunneled" the connection allowing me change data before the Paltalk client received or after it sent it. This was interesting so I also tried to shift my tunnel through a SOCKS proxy server. I didn't get this working at the time -- I was probably using an IP that Paltalk prohibits from using their service) Very interesting though.
You can use any programming language that supports sockets to make your servers and clients. I tend to use C/C++ and C#. If you use IDA Pro or SoftICE you have to use assembly.
Anyways, let me know if you have the protocol/make any discoveries
I'll do the same.Peace, Aran
by 
SitemapIndex
RSS Feed
