CANiBUS
Overview
The CANiBUS Server connects one or more CAN devices to one or more researchers. The CANiBUS Server has drivers for each CAN device that abstracts the communication with the client. It provides a method for multiple researchers to connect to a Vehicle and work together to analyze the CANbus system. This allows for an unlimited number of research to work without additional strain on the electrical system of the vehicle. This works well for instructional environment or remote research on a vehicle.
!!!NOTE!!! This is VERY ALPHA. It may cause unexpected results to your vehicle, which may include but are not limited to: stalling, bricking the system, locking the brakes, or becoming a Decepticon. We can not be held responsible for the use of this product.
Server Features
- Currently supported CAN Devices:
- CANSIM - CAN bus simulator (built-in)
- ( more devices will be added as the server matures )
- Lobby
- Lists available connected CAN devices
- Group chat for discussion prior to starting
- Ability to start a 'hack session' on a device
- Hack Sessions
- Read-only mode (instructor mode)
- Chat private to that hack session
Client
The protocol is documented on the wiki so any client can connect (or bot for that matter). The network protocol is XML an fairly self documenting but you will want to refer to the server source or the wiki if you want to write your own. There is a built-in ncurses client in the client/ folder. This code can be used as an example on how to implement some of the APIs. Ncurses was chosen because:
- Simple interface
- Works via SSH
- Could be used as a server admin tool for CANiBUS server maintenance
Commands
Lobby
- Type anything to chat
- /nick <name> to change username
- /quit to exit
- /refresh to request to server to rescan for newly attached CAN devices
Source Code
Get the source here: https://github.com/Hive13/CANiBUS
Client Development
Server Version
The protocol to the network socket is XML based. When you connect you will get a server version response:
<canibusd><server version="0.0.1"/></canibusd>
All packets are wrapped in <canibusd> tags and all have a \n at the end of them.
The first thing you *must* do is register your username. All commands to the server a simple ascii commands that begin with a '.'
Register a Name
.n<Name> = Example: .nBob The response: Your clientId, updateHackSesisonList, and a finishedInit (see below)
You can also use .n<Name> later to change the username
Once you have registered a name you will be in the "Lobby" state. Here you can start a hack session on one of the returned canbus IDs listed in the updateHackSessionList or chat with other users.
Chatting
Just send a packet. Do *NOT* start with a '.' a straight string will be treated as a chat message and will send to the appropriate scope. If in a lobby it goes to the lobby, if in a hack session then it will only go to the other members of that hack session.
Response example for "hi":
<canibusd><msg type="chat" clientid="1" author="Bob" value="hi"/></canibusd>
Exiting To gracefully quit out and disconnect from the CANIBUSd server you simply execute:
.X
You will be disconnected and all other attached users will see:
<canibusd><deleteclient clientid="1"/></canibusd>
Which simply states which client has recently left so that you can clean up any memory they were using.
Responses
Responses can come at any time. Along with the above XML responses here are some other standard update responses.
client
<canibusd><client clientid="1" cookie=""/></canibusd>
This message only gets sent when you register your name for the first time. This is just to inform you of what your client ID number is and has a place for a cookie. A cookie will be used for reconnecting a disconnected session but is not currently implemented.
UpdateHackSessionList
<canibusd>
<updatehacksessionlist type="full">
<canbus id="1" type="CANSIM" description="CAN Simulation Module"/>
</updatehacksessionlist>
</canibusd>
Additional linefeeds added for clarity but are not present in the actual packet. This provides a list of CAN devices the server knows about. You can get a new list at any time by sending: .sl This is fairly self explanatory but note that you can have any number of canbuses present. You wll use the canbus ID to connect and start hack sessions.
ClinetUpdate
When you first connect you will get a client update for everyone attached to the server:
<canibusd> <clientupdate clientid="1" host="localhost.localdomain" name="Bob" session="-1"/></canibusd>
Keep a local copy of this information in your application so you will know what has changed. The first time you see these messages just record them as is. After you see the FinishedInit message (below) then all following ClientUpdates are for changes or new people joining. Information is fairly self-explanatory and session means what active HackSession they belong to.
For instance if Bob in this example changed their name (via .n<name>) you would get a message like this:
<canibusd> <clientupdate clientid="1" name="Steve"/></canibusd>
As you can see it only has the updated information as attributes. Newly joined users will have all attributes shown.
FinishedInit
After the initial barrage of XML packets comes in you will get the following packet:
<canibusd><finishedinit /></canibusd>
This just signals to the client that all data after this point is update data and not initialization data.