Cyberoam/24Online Protocol
by Rahul Mittal (admin@rasteroid.com)
Created on
July 17, 2002.
Last updated on May 13, 2003.
Copyright (c) 2002, 2003 Rahul Mittal.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at "GNU Free Documentation License".
Disclaimer: This document comes with no warranty or promise whatsoever. Use the document entirely at your own risk. Be aware that interfering with private and public networks can potentially make you liable for any damages or breaches of security. The author is in no way responsible for any action taken by anybody as a result of the information contained within this document. The author affirms that no legal rules were broken in deciphering this protocol, and no Cyberoam servers suffered any attack or damage of any form as a result of my investigation.
Contents
- Credits
- Introduction
- Protocol Versions
- Packet Structure
- Packet Types
- Packet Mangling
- Password Encryption
- Sample Packets
Credits
Independent work on decoding the protocol has been carried out by Amish Mehta, Mayur Naik, Sandip Bhattacharya and Ashish Kulkarni. There are potentially others that I am unaware of. Navin Kadambi also helped me take a look at the disassembled code. Although the work carried out by the above people was well before mine, most of the information in this document was determined independently by me.
Introduction
Cyberoam clients use the User Datagram Protocol (UDP) to communicate with a central server. The central server is usually configured to run on port 6060, but I am unaware of networks configured with a different port number. There are several brand names involved in the marketing and distribution of the Cyberoam client, including "24Online" and "Elitecore". Often the client is distributed with a brand belonging to the ISP or company that purchased the product. I am not aware of the relationship between these names, so if anybody has information about this, please inform me so I may update this document accordingly.
When sniffing a UDP packet sent via the Internet Protocol (IP) on an Ethernet II backbone, the first 42 bytes of each raw packet end up containing the headers for each of the three protocol layers. Specifically, the first 14 bytes are used for the Ethernet II packet header, the next 20 bytes for the IP header, and the subsequent 8 bytes for the UDP descriptor. For all the packet structures described in this document, except the packet dumps at the very end, I have ignored these first 42 bytes for the sake of simplicity.
A note on the terminology used within this document. Unless otherwise indicated, the term "protocol" in the context of this document implies the Cyberoam/24Online protocol. The term "server" implies the Cyberoam/24Online server hosted by the ISP. The term "client" implies a Cyberoam/24Online client which needs to log on to the Cyberoam/24Online server in order to gain access to the internet. The term "packet" implies a UDP packet that is transmitted between a server and a client and conforms to the protocol specifications outlined in this document. The term "network" implies a UDP based ethernet network operated by the ISP.
Protocol Versions
Through recent efforts by Ashish Kulkarni, different protocol versions have been identified. In general, these different protocols mark the evolution of the protocol. So far, we have identified three different client versions - 1.3.1, 1.3.1.1, and 2.1.3.0. Each of these different clients support different network protocols, which I have named V5, V7 and V8. I based this naming convention on the "Preferences\ServerPrefID" registry value set by the client installation software. V5 clients have a ServerPrefID of 5, V7 have 7, and V8 have 8. These values are also sent by the server in the StartupResponse message.
The V5 and V8 protocols are are largely the same with the exception of the Startup and StartupResponse messages. V7 and V8 have identical Startup and StartupResponse messages, but some of the other V7 messages are significantly different from V5 and V8. I have highlighted these differences in the discussion of the protocol below.
Additionally, 1.3.1 is the only TOS-filtering protocol that we are presently aware of.
Packet Structure
The basic layout of each packet is quite simple. A packet of length n bytes consists of a 1-byte function identifier followed by a 4-byte message length indicator, and finally a (n-5) byte long data section.
| Byte(s) | Information | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Function Identifier -- indicates the packet type. Known values are described in the next section. | ||||||||||
| 1-4 |
Message Length -- stores
the full length of the packet as an ASCII string. By full length,
I mean the Function Identifier (1 byte), Message Length (4 bytes)
and the Packet Data. Hence the minimum value that this field can
contain is 5. The ASCII string is left aligned, with 0x00 ('\0'
to those familiar with C/C++) bytes filling any trailing blanks.
For example, if the length of the message is 24 bytes, this field
will contain the following values in each byte:
The actual length of each packet depends on the packet type (i.e. the Function Identifier) specified in Byte 0 above. Some packets have a fixed length, while others have a variable length. |
||||||||||
| Remainder | Packet Data -- The length of this section is given by the Message Length minus 5. The data in this section is described further below in this document. |
It was surprising to discover that the message length was stored as an ASCII string. As a result, the Message Length field takes up four bytes instead of two bytes, had it instead been stored in binary format. Additionally, the UDP packet header stores the length of the data section of the packet, so in fact the Message Length field is just a waste of four bytes. Two to four bytes don't affect the performance of a small Local Area Network at all, but this, and other inefficiencies in the Packet Data will become a consideration when scaling to large LANs with thousands of connections. UDP packets are broadcast, not routed, so packet size should always be strongly scrutinized when designing a UDP based protocol.
Packet Types
There are several types of packets, each with a unique Function Identifier. Not all the packet types have been discovered yet, and not all the discovered packet types are fully understood yet. Basically the client seems to initiate all communication, and the server merely responds with the corresponding message, indicating among other things, success or failure. So for each message X broadcast by the client, there is a message XResponse that is sent back by the server in reply. I list all the known packet types below with a brief description of each:
| No. | Packet Type | Function Identifier |
Length (in bytes) |
Sample | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
Startup
This packet is sent as soon as the client is started up, without even waiting for the user to issue a connect command. I believe this packet is used by the client to confirm that any settings it remembers from a previous session are correct. Specifically, a successful response to this message implies that the server supports a mutually compatible protocol. This packet contains no information, hence it has a message length of 5. If the server is not reachable, the client is configured to re-broadcast the Startup packet a fixed number of times (two more times on my client), with a gap of 40 seconds between each subsequent rebroadcast. |
0x29 (V5) 0x24 (V7) 0x24 (V8) |
5 | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 2 |
StartupResponse
This packet is sent immediately by the server in response to a Startup packet from the client. The 6th byte of this packet indicates the version of the protocol used by the server. This is the same value that is stored in the registry key "Preferences\ServerPrefID". The following table summarizes what values the 6th byte may contain:
As you can see from the table, different versions of the client use different versions of the protocol. I like to call these versions V5, V7 and V8 respectively. It appears that the servers dictate the protocol version; the client cannot negotiate to determine a suitable protocol version. However, the server does respond with an Error message if it doesn't support a particular protocol. This can be exploited to create a simple protocol auto-detection algorithm. First check with a V5 Startup packet (0x29 Function Identifier). If the server responds with an error, try V7 (0x24). If it doesn't respond with an error, then your server supports either V7 or V8, since both use identical Startup/StartupResponse packets. To distinguish between V7 and V8, you will have to use a Connect packet and resolve the response from the server. V8 packets are identical to V5 packets except for the Startup/StartupResponse handshake, whereas V7 packets have more concrete differences. The meaning of the 6th byte was deciphered by Ashish Kulkarni. |
0x2A (V5) 0x25 (V7) 0x25 (V8) |
6 | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 3 |
Connect
This packet is sent when the client makes a request to log into the server. The packet structure is similar across all protocol versions. The only exceptions are V8 clients which use a different function identifier and also append the client version number as a fourth field after the encrypted password but before the MAC address. Here is the detailed packet structure:
|
0x21 (V5) 0x21 (V7) 0x38 (V8) |
112 (V5) 112 (V7) 124 (V8) |
Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 4 |
ConnectResponse
Sent by the server immediately, in response to a Connect message. The contents of this packet vary according to the protocol version used by the server. V7 servers respond with packets containing only four fields, whereas V5 and V8 servers respond with an additional 4 fields (i.e. a total of 8 fields). These fields are stored within each packet as a single ASCII string, with each field delimited by ':' (colon) characters. For example, the following is a response from a V5 (or V8) server: inc:0:You have successfully logged on.:yes:1966:1:Message from Administrator:1119 The following is known about the meaning of each field (thanks to Ashish Kulkarni for decoding some of the fields):
|
0x02 | * | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 5 |
ConnectRefused
This packet is sent by the server immediately in response to a Connect packet from the client. It indicates that the server has refused the connection request. This is most likely due to an authentication failure (i.e. bad username/password) but may possibly also be sent if your account has been disabled for any reason. Contains an ASCII string which contains the message explaining the reason a connection was refused. You should verify your login credentials and then try connecting again (by sending another Connect message). If you still cannot log in, call your ISP to see if your account has been disabled. |
0x03 | * | No | |||||||||||||||||||||||||||||||||||||||||||||
| 6 |
Ping
This message is sent periodically from the client to the server and serves as a keep-alive message. It is the period between two successive Ping messages sent by the client. The client stores this value in the registry under the key "Preferences\LiveRequestTime". The default period is 180 seconds. The first part of the packet is the 30-character username that was used in the Connect message. This part is present in all versions of the protocol. In the V7 protocol, 20-bytes after the username are blank, filled with NULL (0x00) bytes. This gives V7 packets a fixed length of 55. In V5 and V8, the username field is followed by the ConnectionID number which was supplied by the server in field 5 of the ConnectResponse message. This number is stored as an ASCII string, giving the packet a variable length. |
0x04 | 39* (V5) 55 (V7) 39* (V8) |
Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 7 |
Pong (PingResponse)
This message is sent by the server immediately in response to a Ping message. The message length is 5, so it contains no additional information. |
0x05 | 5# | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 8 |
PingRefused
Sent by the server if it receives a Ping message after an abnormally long period of time. This usually occurs because the client has been inactive for an extended period of time (e.g. due to a power outage) and basically means that the client should try logging in again using a Connect message. It just contains the string "You are disconnected from the machine..., Press Yes to Login again or Press No to Logout." To respond to this message, simply try to reconnect to the server by sending a Connect packet once again and then resume the Ping (keep-alive) packets to maintain the connection. This packet is quite interesting since it indicates how the servers dictate how the clients' behavior, even for error handling. This has significant implications on the versatility of the protocol. |
0x0E | 93* | No | |||||||||||||||||||||||||||||||||||||||||||||
| 9 |
Check
This message is used by the client if the user wishes to manually verify that the client settings (specifically the server's IP address) are correct. It contains no additional information. |
0x17 | 5 | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 10 |
CheckResponse
This message is sent by the server immediately in response to a Check message, confirming that the server can be reached via the client's new settings. This packet contains no additional information. |
0x18 | 5# | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 11 |
Logoff
A Logoff message has identical contents compared to a Ping packet. It is sent at the end of the session to notify the server of the client's intention to terminate. See the Ping packet for details on packet contents, and how the contents differ according to the protocol version. |
0x07 | 39* (V5) 55 (V7) 39* (V8) |
Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 12 |
LogoffResponse
This message is sent by the server immediately in response to a Logoff message, acknowledging to the client that the server received the Logoff message. It contains a string indicating the success or failure of the logoff process. In case of successful logoff, it contains the string "You have successfully logged off." |
0x08 | 38* | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 13 |
Version
Received by my server emulator right after the client's Startup handshake. Contains the ASCII digit '1' (one) in the 6th byte, and at first I was puzzled by what the '1' meant. A little later I noticed that the client displays the message "Checking for Version" when it sends this message, and so I am pretty sure it is a version inquiry message. The '1' possibly stands for protocol version 1 (or 0.1?). The 6th field of the ConnectResponse message also contained a '1', so an investigation on the relation between these two is needed. The registry key "Version\VersionID" also contains the value 1, so perhaps my above guesses are correct. On further testing, with variable values for the 6th byte, I kept receiving the same VersionResponse packet described below. So perhaps the contents of this packet are simply being ignored by the server. Removing the sixth byte caused the server to return an Error packet with the message "Error in protocol". |
0x2B | 6 | Yes | |||||||||||||||||||||||||||||||||||||||||||||
| 14 |
VersionResponse
Received in response to a Version packet (see above). It contains no additional information. |
0x10 | 5 | No | |||||||||||||||||||||||||||||||||||||||||||||
| 15 |
Contact
Used to transmit custom messages to the network administrator. It contains just one ASCII string, which is the transmitted message. |
0x15 | 5* | No | |||||||||||||||||||||||||||||||||||||||||||||
| 16 |
Error
Received when the server detects an error in the packets it receives. It contains just one ASCII string which is the error message. In almost all cases, this string is "Error in protocol". |
0x65 | 5* | No |
| * | The length of these packets is probably variable, depending on the values of the strings contained within. |
| # | Although the Message Length indicated in the packets for these server responses is 5, the messages typically contained 18 bytes, with 5-17 containing 0x00 values. I am not sure if this is a server bug, or if there was a bug with my packet sniffing program, or if this is how it is supposed to be. |
Packet Mangling
Credit goes to Ashish Kulkarni for his work on decoding this aspect of the Cyberoam/24Online protocol.
For certain versions of the clients - specifically 1.3.1 (protocol V5) and perhaps others - outgoing IP datagrams are mangled by a packet-level driver installed by the client installation program. This driver goes by the name of "eno2000.sys" and "enonotify.dll". The driver actually alters the "Type of Service" (TOS) octet of each datagram by setting bit 6 (assuming bits are numbered 0 to 7) to 1. Additionally, while the client is not logged in, the packet-level driver resets this bit to 0 for all outgoing IP datagrams. Correspondingly the server hosted by the ISP actively filters all packets and only allows the altered ("flagged") packets to pass.
For more information about the TOS octet, please refer to the Internet Protocol specification (RFC 791) and the Type of Service in the Internet Protocol Suite specification (RFC 1349).
Visit the Slyberoam Software page to learn how you can configure your PC to set the TOS byte to 0x02, without having the eno2000.sys driver installed.
Password Encryption
News (13.Aug.2002) I have successfully reverse engineered the password encryption algorithm after decompiling the client binary. I present below an implementation in ANSI C++. The code is made available under the GNU General Public License. Also, there is a reasonable amount of guesswork that I went through before arriving at the final algorithm. You will need to add the appropriate include files and implement main() or another calling function.
Password Encryption Algorithm (in ANSI C++)
I list below several sample plaintext passwords and their corresponding ciphertext bytes. This is so that anybody implementing the protocol may check that their implementation is in fact accurate:
Timestamp Plaintext Ciphertext
0004240304 aaaaaaaa 136082143026182017124235
aaaaaaab 136082143026182017124232
aaaaaaac 136082143026182017124233
aaaaaaad 136082143026182017124238
aaaaaaba 136082143026182017127070
aaaaaabb 136082143026182017127069
aaaaaabc 136082143026182017127068
aaaaaabd 136082143026182017127067
aaaaaabe 136082143026182017127066
aaaaabbb 136082143026182018093220
baaaaaaa 139130177020202028103003
caaaaaaa 138086203201018084228026
daaaaaaa 141181119195210074024216
eaaaaaaa 140174045004226214021037
faaaaaaa 143009219194058152205108
gaaaaaaa 142080223038148195144093
haaaaaaa 129226154044225190030241
iaaaaaaa 128042024158161223195167
babaaaaa 139130178077044014035230
bbbbbbbb 139129116250115037000253
cccccccc 138084225008127207058098
AAAAAAAA 168243168082213211103141
AAAAAAAB 168243168082213211103142
AAAAAAAC 168243168082213211103143
BBBBBBBB 171242152219074144082185
CCCCCCCC 170169211179138149152047
1029045616 aaaaaaaa 073225217104163023147200
I spent a considerable amount of time trying to decode the password encryption algorithm, and eventually had to figure it out from the disassembled code. For this reason, I include a link to my initial guesses so that anybody interested may follow my thought process.
Sample Packets
Listed below are samples of packets caught by my packet sniffing program. This means that the packets contain Ethernet II, IP and UDP headers in addition to packet data. In each case I have highlighted the Cyberoam/24Online packet data. Also, since I have decoded and published password encryption algorithm, I have altered the packet data for my username and password wherever they appear in the packets below. Please do not use the sample Connect packet below to attempt to decode the encryption algorithm!
Startup
0x0000 00 20 78 D7 E1 96 00 03-47 88 4C 6F 08 00 45 00 . x×á–..GˆLo..E.0x0010 00 21 00 DE 00 00 80 11-E0 0F C0 A8 01 64 CB C0 .!.Þ..€.à.À¨.dËÀ
0x0020 CC 11 04 22 17 AC 00 0D-60 F2 29 35 00 00 00 Ì..".¬..`ò)5...
StartupResponse
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 00 ..GˆLo. x×á–..E.0x0010 00 22 00 00 40 00 3F 11-E1 EC CB C0 CC 11 C0 A8 .";..@.?.áìËÀÌ.À¨
0x0020 01 64 17 AC 04 1F 00 0E-5F BD 2A 36 00 00 00 35 .d....._½*6...5
0x0030 00 00 00 00 00 00 00 00-00 00 00 00 ............
Connect
0x0000 00 20 78 D7 E1 96 00 03-47 88 4C 6F 08 00 45 00 . x×á–..GˆLo..E.0x0010 00 8C 01 84 00 00 80 11-DE FE C0 A8 01 64 CB C0 .Œ.„..€.ÞþÀ¨.dËÀ
0x0020 CC 11 04 22 17 AC 00 78-D6 9C 21 31 31 32 00 75 Ì.."..xÖœ!112.u
0x0030 73 65 72 6E 61 6D 65 00-00 00 00 00 00 00 00 00 sername.........
0x0040 00 00 00 00 00 00 00 00-00 00 00 00 00 32 30 31 .............201
0x0050 34 32 35 36 38 36 34 32-31 39 31 37 36 32 35 31 4256864219176251
0x0060 31 38 36 32 32 35 30 39-37 32 33 38 31 35 32 00 186225097238152.
0x0070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0x0080 00 00 00 00 00 00 00 00-00 46 30 3A 30 44 3A 46 .........F0:0D:F
0x0090 30 3A 30 44 3A 46 30 3A-30 44 0:0D:F0:0D
ConnectResponse
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 00 ..GˆLo. x×á–..E.0x0010 00 58 00 00 40 00 3F 11-E1 B6 CB C0 CC 11 C0 A8 .X..@.?.áËÀÌ.À¨
0x0020 01 64 17 AC 04 22 00 44-68 39 02 37 36 00 00 69 .d..".Dh9.76..i
0x0030 6E 63 3A 30 3A 59 6F 75-20 68 61 76 65 20 73 75 nc:0:You have su
0x0040 63 63 65 73 73 66 75 6C-6C 79 20 6C 6F 67 67 65 ccessfully logge
0x0050 64 20 6F 6E 2E 3A 79 65-73 3A 31 39 36 36 3A 31 d on.:yes:1966:1
0x0060 3A 6E 65 74 77 6F 72 6B-20 67 72 65 65 74 69 6E :network greetin
0x0070 67 3A 31 31 31 39 g:1119
ConnectRefused
Packet capture data unavailable.Ping
0x0000 00 20 78 D7 E1 96 00 03-47 88 4C 6F 08 00 45 00 . x×á–..GˆLo..E.0x0010 00 43 01 26 00 00 80 11-DF A5 C0 A8 01 64 CB C0 .C.&..€.ߥÀ¨.dËÀ
0x0020 CC 11 04 22 17 AC 00 2F-BE 58 04 33 39 00 00 75 Ì.."../¾X.39..u
0x0030 73 65 72 6E 61 6D 65 00-00 00 00 00 00 00 00 00 sername.........
0x0040 00 00 00 00 00 00 00 00-00 00 00 00 00 31 39 36 .............196
0x0050 36 6
Pong (PingResponse)
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 00 ..GˆLo. x×á–..E.0x0010 00 21 00 00 40 00 3F 11-E1 ED CB C0 CC 11 C0 A8 .!..@.?.áíËÀÌ.À¨
0x0020 01 64 17 AC 04 22 00 0D-84 F2 05 35 00 00 00 00 .d.."..„ò.5....
0x0030 00 00 00 00 00 00 00 00-00 00 00 00 ............
PingRefused
Packet capture data unavailable.Check
0x0000 00 20 78 D7 E1 96 00 03-47 88 4C 6F 08 00 45 00 . x×á–..GˆLo..E.0x0010 00 21 01 25 00 00 80 11-DF C8 C0 A8 01 64 CB C0 .!.%..€.ßÈÀ¨.dËÀ
0x0020 CC 11 04 32 17 AC 00 0D-72 E2 17 35 00 00 00 Ì..2...râ.5...
CheckResponse
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 00 ..GˆLo. x×á–..E.0x0010 00 21 00 00 40 00 3F 11-E1 ED CB C0 CC 11 C0 A8 .!..@.?.áíËÀÌ.À¨
0x0020 01 64 17 AC 04 2F 00 0D-71 E5 18 35 00 00 00 00 .d../..qå.5....
0x0030 00 00 00 00 00 00 00 00-00 00 00 00 ............
Logoff
0x0000 00 20 78 D7 E1 96 00 03-47 88 4C 6F 08 00 45 00 . x×á–..GˆLo..E.0x0010 00 43 01 83 00 00 80 11-DF 48 C0 A8 01 64 CB C0 .C.ƒ..€.ßHÀ¨.dËÀ
0x0020 CC 11 04 22 17 AC 00 2F-BB 58 07 33 39 00 00 75 Ì.."../»X.39..u
0x0030 73 65 72 6E 61 6D 65 00-00 00 00 00 00 00 00 00 sername.........
0x0040 00 00 00 00 00 00 00 00-00 00 00 00 00 31 39 36 .............196
0x0050 36 6
LogoffResponse
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 00 ..GˆLo. x×á–..E.0x0010 00 42 00 00 40 00 3F 11-E1 CC CB C0 CC 11 C0 A8 .B..@.?.áÌËÀÌ.À¨
0x0020 01 64 17 AC 04 22 00 2E-30 5E 08 33 38 00 00 59 .d.."..0^.38..Y
0x0030 6F 75 20 68 61 76 65 20-73 75 63 63 65 73 73 66 ou have successf
0x0040 75 6C 6C 79 20 6C 6F 67-67 65 64 20 6F 66 66 2E ully logged off.
Version
0x0000 00 03 47 88 4C 6F 00 20-78 D7 E1 96 08 00 45 03 ..GˆLo. x×á–..E.0x0010 00 22 4A AB 00 00 80 11-6C 67 C0 A8 01 01 C0 A8 ."J«..€.lgÀ¨..À¨
0x0020 01 64 08 42 17 AC 00 0E-30 C7 2B 36 00 00 00 31 .d.B...0Ç+6...1
0x0030 00 00 00 00 00 00 00 00-00 00 00 00 ............