Defense Digital Rover

| | | :--: | :---: |

The Defense Digital Rover (DDR) is a simple web controlled rover designed to teach the basics of attacking a space based radio frequency data link. This is an update on the DDSat-1 project from last year, using the feedback from everyone who played. This year players will try and take control of a rover driving around the Paris ballroom. Similar to last year, the twitch chat will be used to represent the RF data link. This year the message will allow you to control the motors on a rover, letting you drive around the defcon floor.

If you want to make your own, follow the instructions in this DIY guide

Table of Contents

• How-to-Play
  • Command-Overview
  • Without-Programming
  • With-Programming
• Technical-Background
  • Designer-Challenges
  • Hacker-Challenges
• Hints-and-Walkthrough
  • Hints
  • Walkthrough

<!-- toc -->

How-to-Play

To interact with the rover, simply head over to the twitch channel: here. Players will interact and take command of the rover by using the stream chat to talk to both the rover and ground control chatbots. Twitch was chosen because it has both a robust API and requires players to download no additional software.

Players can complete the game without any programing, however writing scripts and chatbots can make the game easier for those who take the time to do so. The rover chatbot is ddsat1, while the ground station chatbot is OtterBot.

This is meant to be an easier and less stressful version of ddsat, with an expected play time of around an hour to figure everything out. It was also an excuse to drive a rover around the Aerospace village, because why not?

Command-Overview

All chat commands begin with the identifier: !

• !help : This command will link you to this page explaining the different commands and how to play.
• !vote or !v : This is the first and easiest command to use to control the rover. Every 15 seconds a voting round will end, and the winning command will be carried out by the rover. A live update of the vote count is in the upper left of the stream.
• !send : This is the most common way to interact with the rover. This represents the player transmitting a command over RF to the rover.
• !theme : This lets you change the rover display between a normal display and several color shifts. This has no actual impact on game play.
• !music : This lets you change the background audio playing during the stream.
• !status : This is the message from the rover updating the players on the rovers status and new command number
• !cheat : For those who want to play a slightly different game and want to hack into the ground station instead of the rover.
• !auth : How you log into the ground station. Please do not use your real password. This is a game, the game credentials are hidden in the support material from this year and last year. DO NOT USE YOUR REAL PASSWORD!

Examples

The following are examples of how to use the commands

!help : sends a link to this page

!vote forward : votes to have the rover move forward for one second. Other valid forms would be to use !vote left, !vote right, or !vote backward. You can also use W,A,S,D and !v for shorthand. Thus !vote forward and !v w mean the same thing.

!send AgABf39k+WOI2A== : command to move the rover forward for one second. Note that the actual command is encoded with base64.

!theme mars : command to change the filter on the video display. In this case, we are setting it to a red shift. One can also show the normal view with !theme earth, a black and white view with !theme moon, or a joke DDR theme with !theme ddr

!music next : plays the next background music theme in the list, can also use !music prev to play a previous track, or !music X to play a specific track, where X can be 0 through 6. Note each background track is on a loop, so this command is the only way to jump to other songs.

!status : this command comes from the rover, and can be used as a trigger by your own chat bots to update their settings. It does nothing if sent by a player.

!cheat 127-127-255 255-255-255 : orders the ground station to send a message to the rover with two commands, the first sends the rover forward at full speed for 2.5 seconds, and the second sends it in reverse at full speed for 2.5 seconds. Note to use this command your twitch user name must be on the authorized user list. So unless your name is Otter MiSpace, good luck having that happen.

!auth password : adds a user to the authorized user list, allowing them to use the !cheat command. Note, the password is neither password nor your own password. It is however the same password used in previous SpaceDotCom products for those of you who remember it from last year.

Without-Programming

The message structure is simple enough this year that you do not need to write any code to play with the rover. All three methods: !vote, !send, and !cheat can be used without any scripting. Note, this is not recommended, but it is possible.

For !send, you will need a way to generate a CRC value, and a way to encode and decode base64 data. This can all be done online, and we recommend using sites like:

• https://crccalc.com/
• https://cryptii.com/pipes/base64-to-hex

With-Programming

As mentioned above, the only functions you need are a way to generate a CRC checksum and encode a byte array into a base64 encoded string. Thus any language will work. For this project, both the rover and ground station were written in python, and the example provided are all written in python.

Technical-Background

Designing and hacking space-based systems have a lot of unique rules and challenges that aren't present in terrestrial based system. In this section we'll go over some of the challenges from both a designer and hacker standpoint.

Designer-Challenges

Designing an RF data link that works from one room to another is a pain, designing one that works from one planet to another is a nightmare. Many of these challenges are outside the scope of this demo, because they involve things like deciding the frequency to transmit on, or the modulation to use for clear reception. We're trying to stay away from hardware problems, so we'll instead focus on three software challenges: Encryption, Bandwidth, and Time Delay.

Encryption

For ground based systems, encrypting a data link is an obvious solution to privacy concerns. After all, even if the encryption gets misconfigured, you just have to walk over to the physical device to correct things. This isn't quite as straight forward for space-based systems.

When your system is in orbit around your own planet, or driving around on another, the worst that can happen is to lose the ability to communicate with it. There is nothing worse than losing contact with your platform and having no idea why, and no way to reconnect. This means that while adding encryption to something is the cheap and obvious answer on earth, its a very risky answer in space. If a key gets corrupted, there is no way to fix things once they go bad.

This means that a lot of designing of the data link has to be focused on making it safe for the system no matter who the device is talking to. CubeSats are a great example of this, where the data links are kept very simple with limited capability both to keep the cost of the sat down, and reduce the risk of something bad happening when someone from earth tries to talk to them.

We are used to thinking of space as a solitary, isolating place, where no one can hear or see anything you do. The reality is the exact opposite, with space being one of the few areas with absolutely zero privacy, at least from an RF stand point. Figuring out how to protect these data links in a space where anyone can pretend to be anyone else will be the major security hurdle of the 21st century.

Bandwidth

One of the basic rules of the physics of data transmission is that the longer a message becomes, the more overhead is needed to process the message and the more likely it is that the message becomes corrupted during transmission. This is why the concept of a maximum transmission unit (MTU) exists. Space doesn’t like to play nice with anyone, thus leading to a very high likelihood of transmission errors and forcing the individual message length of a transmission to be fairly small compared to terrestrial transmissions.

In order to maximize bandwidth in such a challenging space, most space-based data links are bit-oriented instead of the more common byte-oriented nature of terrestrial data links. Between this and the use of custom modulation schemes, its not uncommon to see some designers advertise this as a form of encryption. Its not. While its true the raw data can look obscured to anyone who doesn't know what is happening, none of the underlying patterns or relations between the fields are actually obscured or hidden.

Time Delay

Send a command and something happens is a pretty obvious design philosophy, but even this is harder in space. On earth, its common for most round trip communications to only have delays in the milliseconds. However jumps outside the atmosphere, the sheer distance quickly causes communications to have delays measured in seconds and minutes.

This means that designers of these systems cannot rely on seeing the immediate results of any command or request to the space-based system. This is one of the reasons why even a sim