Introduction

Because I was rather pissed at these stupid things and for a few months I didn't notice any differences I decided to fix it myself. In order to do that I had to understand how this chat communicates via proprietary protocol. I also thought it could be a good exercise for my skills and chance to improve them that little bit.
 

Legal stuff

Both approaches involve running tools on my own computer on publicly available files (Java .class files) that are being downloaded by browser, thus no attempts were made to gain any unauthorized access to the main server. It simply not required, and this is a bit scary how easy people can do things they were not supposed to due to lousy programming practices.
 

1st approach: Decompiling Java applet.

First task is to get hold of actual Java .class files. Unfortunately authors of the chat didn't use packed JAR format (ZIP file) and as the result it's not only loads longer, but also takes one to get all files manually, which was a bit irritating. I guess this was their "security" measure. Anyway, here is the list of files:

AreaServer.class Avatar.class AvatarUserPanel.class Bubble.class ChatClient.class ChatLog.class ChatRoom.class COMI.class Communicator.class DoBeDoBanner.class DoBeDoChat.class DoBeDoList.class DropMenu.class Emoticon.class IAreaServerClient.class IChatClient.class IChatLog.class IChatObject.class IChatRoom.class IClickAreaClient.class IClickAreaServer.class ICOM.class IHotAreaClient.class IHotAreaServer.class IIntro.class IListener.class ILoader.class IMapObject.class IMovableChatObject.class Intro.class IPaint.class IPaintServer.class ISelectableChatObject.class Loader.class Login.class Map.class MapCircle.class MapObject.class MapPolygon.class MapText.class NewCircle.class NewPolygon.class NewRectangle.class NewShape.class PaintServer.class RecordSet.class Sender.class Tab.class TabView.class

The OO design is rather good, one point to the authors, but it's hell lot of files.

Jad worked out just fine and produced about 357k of source code. You will be surprised how readable is it! Here is a little code snippet from decompiled Communicator.class:

    public void onLeave(String s, String s1)
    {
        IChatRoom ichatroom = (IChatRoom)chatClient.getChatObject(s);
        IChatObject ichatobject = chatClient.getChatObject(s1);
        if(ichatroom == null || ichatobject == null)
        {
            System.out.println("\nOne of the objects could not be found in onLeave call!");
            return;
        }
        else
        {
            moveObjectFromRoom(ichatobject, ichatroom);
            chatClient.objectViewChanged(ichatroom);
            isWaitingFor.remove("onLeave");
            return;
        }
    }

The lack of comments will stop only inexperienced programmers.

A quick look reveals that they use a chat server located at  195.7.67.136, port 443. The chat loader loads a list of specified
classes in booting HTML file.  Funny thing is that this chat specifically doesn't want to run locally due to "security" problems. It is also interesting that guys who programmed it meant to make a proper login procedure, but it never appears on the screen.
Actually now it is time to name these guys: Andreas Arrg and Henrik Wall. They appear in internal list of credits. Nice work guys, but you should have paid a LOT more attention to security issues instead of hard coding bi-lingual features (Swedish/English).

The communication is done using two main channels. First is the main server at 443 port where a chat client sends commands and receives updated. Every sent/received command is a one line ending with "\r\n" (0x0D 0x0A). The second is when a client requests an image (GIF/JPG) via HTTP protocol.
 

Examples of commands send from client to server:

1. sendToAll'emote,6,gagging for it.'157'868687'
2. updateProperty'20581'20581'position'150,110'N'

Examples of commands received by client from server:

1. onReceive'whisper,miaow?'76557' '93842'
2. onEnter'171'13'icon'avatar/gal1.gif'my_room'109481'owns'5650,1,5696,1'OBJECTCLASS'
   CHATOBJECT'position'287,151'OBJECTID'109480'current_room'176'avatar_mood'01'avatar_style'01'
   avatar_sex'02'clan_id'20'OBJECTTYPE'AVATAR'label'Alicia5'
3. onUpdateProperty'13709'position'535,251'

It seems to me that guys were a bit influenced by IRC, but didn't take into account many security features found in the protocol. Ever read RFC?
 

Unfortunately DoBeDo chat is a nice chat where I like to hang out myself, and I can't reveal too many details on how to exploit the system as no doubt it will be abused.

One might be tempted to make a change and recompile it, however I didn't bother. It is easier to write a Perl script doing all I wanted.

2nd approach: Traffic analysis.

The output of this program will looks like this (my IP was changed to xxx.yyy.zz.z): It may look weird and cryptic to a non-professional, but for those who see it says everything.

Source IP: xxx.yyy.zz.z  Target IP: 195.7.67.136 TCP  Length: 0  Source Port: 1221 
Target Port: 443  Seq: 00542AF9  Ack: 032190BF Flags: A  Window: 8225  TCP ChkSum: 11415 UrgPtr: 0

Source IP: 195.7.67.136  Target IP: xxx.yyy.zz.z TCP  Length: 43  Source Port: 443 
Target Port: 1221  Seq: 032190BF  Ack: 00542AF9 Flags: PA  Window: 8107  TCP ChkSum: 32272 UrgPtr: 0
 00000000: 6F 6E 55 70 64 61 74 65 50 72 6F 70 65 72 74 79   onUpdateProperty
 00000010: 27 31 36 38 37 37 32 27 70 6F 73 69 74 69 6F 6E   '168772'position
 00000020: 27 32 34 39 2C 32 30 32 27 0D 0A                  '249,202'..

Source IP: xxx.yyy.zz.z  Target IP: 195.7.67.136 TCP  Length: 0  Source Port: 1221 
Target Port: 443  Seq: 00542AF9  Ack: 032190EA Flags: A  Window: 8182  TCP ChkSum: 11415 UrgPtr: 0

Source IP: 195.7.67.136  Target IP: xxx.yyy.zz.z TCP  Length: 1  Source Port: 443 
Target Port: 1221  Seq: 032190EA  Ack: 00542AF9 Flags: PA  Window: 8107  TCP ChkSum: 48600 UrgPtr: 0
 00000000: 6F                                                 o

Source IP: xxx.yyy.zz.z  Target IP: 195.7.67.136 TCP  Length: 0  Source Port: 1221 
Target Port: 443  Seq: 00542AF9  Ack: 032190EB Flags: A  Window: 8181  TCP ChkSum: 11415  UrgPtr: 0

Source IP: 195.7.67.136  Target IP: xxx.yyy.zz.z TCP  Length: 20  Source Port: 443 
Target Port: 1221  Seq: 032190EB  Ack: 00542AF9 Flags: PA  Window: 8107  TCP ChkSum: 44153 UrgPtr: 0
 00000000: 6E 4C 65 61 76 65 27 31 36 38 27 31 35 39 37 33   nLeave'168'15973
 00000010: 38 27 0D 0A                                       8'..

After an hour of traffic capturing all became clear. Another approach but the same result. This couldn't be attributed to any flaws of Java. While for some this dump will not mean a thing, those who can will see it all.

I found that this approach gives faster results than with decompilation. The latter however is useful to see what features are in that are not available for you, and hence get them (ie zapping people), something that traffic analysis won't reveal because unless you use this feature, you can't see the command strings in TCP dump.

Conclusions

I tried to limit details to minimum to avoid potentially devastating effect on the fellow chatters. However, being silent and turning a blind eye on obvious security holes is like being a straus who hides his head in sand.

Solutions

1. Obfuscate your Java code to prevent easy decompiling.
2. Encrypt all traffic at the application level (not XOR though, please).

1. Use fake logic structures and yummy looking strings that will just mislead the attacker.
2. Scramble all important commands in the code, avoid using plain text at all.
3. Self verify your own code, it might be byte patched.

Last words

Some would cry out loud accusing me of being evil, but they are wrong. Evil doesn't come forward with a good advice, as evil exploits weaknesses for it's own evil purposes without telling them. Blame not the messenger, but blame the cause, the root of the evil, which in this case is a poor design of the Java application.
 

To the authors: for Christ sake guys, could not you cache all these images in memory to make moving from one room to another faster? This is so obvious.