A Roboheist Challenge

Teaching the Next Generation of Embedded Engineers

Embedded security should be part of every engineer’s toolkit. While teaching a design course to undergraduate students, Colin introduced a few aspects of embedded security and wanted to give you an overview of this, as it might spark some ideas readers could reuse.

I’ve released everything I was able to for this course under open-source licenses, with the goal of providing material for others who might find this sort of reference useful.

Peter Gregson’s Legacy

For many years, Dr. Peter Gregson taught a special course in third-year electrical and computer engineering at Dalhousie University. In that course, students were challenged to build autonomous robots to solve a specific objective, which changed almost every year. After Dr. Gregson passed, the course continued his legacy, and each year students under the supervision of another professor compete in the Dr. Peter Gregson Robotics Challenge.

In recent years, Dr. Vincent Sieben has taught this course and designed his own robotics platform called the DALibot (Currently there is not a website for Dr. Vincent Sieben’s DALibot and it is unreleated to other DALibots out there). This platform includes a mini-PC, motors, LIDAR, and IMU. It uses the Robotics Operating System 2 (ROS2) language, which allows complex pathfinding and other designs.

The students are expected to build additional mechanical and electrical peripherals to expand the capabilities of this base platform, however. Figure 1 shows examples of student teams’ robots used in the final course. The platform itself is similar to the well-known TurtleBot, but with a variety of in-house, specific optimizations and repair options, such as using 3D printer parts that can be replaced as needed. At least 20 such robots are reused each year, and because there is bound to be some damage, having quick repairs is critical for keeping the course moving.

This year Dr. Vincent Sieben was on sabbatical, meaning I temporarily taught the course. Let’s see what the challenge was this year.

Staging a Course Heist

I couldn’t resist the opportunity to bring some of my embedded security work into the course, so I decided to go with the theme of a “Roboheist.” My goal was not just to teach them about a few skills on the technical side of embedded security analysis work, but to also teach them about thinking how systems can be bypassed and when they should test what they are told about a system design. These skills are important when they go on to look at the security of embedded design later in their careers.

Of course, the original (and true) goal of the class is to teach general design skills. I won’t discuss that as much here, but I will summarize some good lessons learned that all engineers would like to see taught in these classes.

The Roboheist

The general idea of the Roboheist is to modify their robot platform (Figure 1) to collect several pieces of loot. You can see a robot picking up a piece of loot in Figure 2. These loot pieces were 3D printed and 60mm (2.4”) in diameter and 25mm (1”) high.

The robot must run entirely autonomously, and as part of the canon of the course, their robot is delivered by a cardboard box with fixed maximum dimensions. Their robotic run begins when the cardboard box is removed from the robot; the robot detects the removal of the cardboard box to start the run.

The heist part comes into play because while some of the loot pieces are simply sitting on the course, several are protected by various types of alarms and sensors. These alarms can be disabled by known and unknown methods (enter the embedded security lessons).

The course diagram is shown in Figure 3, with the loot marked with certain values. I won’t go over all the rules, but the idea is there are additional point multipliers for simply touching the loot, getting the loot onto their robot, or returning the loot to the starting zone.

Of special interest are the three loot containers on the left-hand side (the safe, the I.N.D.I.A.N.A. sensor, and the cage), the RFID reader on the top left, and the break-beam sensor in the top right. Some of these were designed to be interesting robot applications that required careful design principles to be followed, but some of them hid cybersecurity lessons that you can reuse if you are working with high school or undergraduate students.

As part of the course, I created some simple datasheets for various sensors and systems. Often these datasheets included information about how a system worked, but students would need to perform their own experiments to fully understand how to interact with the course challenges. One of the first challenges was a break-beam sensor.

Bypassing a Beam Sensor

The break-beam sensor used common infrared (IR) demodulators that are designed to be used by remote controls in TVs, heat pumps, and similar items. These output a constant logic level when a specific frequency IR signal is detected. In this case I used a combination of 38kHz and 59kHz sensors. The 38kHz is used for the break-beam detector, described next.

A simplified diagram of the break-beam sensor is shown in Figure 4. This design uses the Arduino to output a 38kHz signal on pin 9, while also writing UART data out on pin 5. The SoftwareSerial port is used to leave the main serial port open for debugging. By connecting the IR LED in between these two pins, it makes it easy to modulate UART data onto the IR beam. The advantage of this system is that the demodulation is performed by the off-the-shelf IR receiver modules (Vishay TSSP4038), and they spit out logic-level UART data, which can be read by an Arduino or Raspberry Pi Pico (two of the platforms I used for embedded work in this class). The IR carrier ensures that changes in daylight don’t affect the system.

A simplified version of the code implemented on the Arduino for transmitting the signal is shown in Listing 1. The break-beam sensor includes a series of changing numbers that is received by the other side, which means an attacker cannot just send a simple constant if they want to break the beam without tripping the detector. They need to either repeat the signal from one end to the other (think of an invisibility cloak) or understand the protocol and send suitable fake data. If you want the receiving sensor, see the GitHub repository linked in Resources.

Listing 1
Simplified break-beam code, shown using an Arduino to generate the 38kHz signal, which then modulates a slow 300 baud serial message over it.

#include <SoftwareSerial.h>#include <stdlib.h>const byte rxPin = 2;const byte txPin = 5;// Set up a new SoftwareSerial objectSoftwareSerial mySerial (rxPin, txPin);void setup() {    // Set pin 9 (OC1A) as output    pinMode(9, OUTPUT);    // Configure Timer1    TCCR1A = 0; // Clear Timer1 Control Register A    TCCR1B = 0; // Clear Timer1 Control Register B    // Set CTC mode (Clear Timer on Compare Match)    TCCR1B |= (1 << WGM12);    // Set prescaler to 1 (no division)    TCCR1B |= (1 << CS10);    // Set compare match value for 38.0 kHz    OCR1A = 211;    // Enable toggle mode on pin 9    TCCR1A |= (1 << COM1A0);    pinMode(rxPin, INPUT_PULLUP);    pinMode(txPin, OUTPUT);    mySerial.begin(300);}uint8_t chksum(char * data, unsigned char len){  uint8_t sum = 0;  while(len){    sum ^= *data++;    len--;  }    return sum; }char temp[20];int rint = 0;void loop() {  // put your main code here, to run repeatedly:  rint = random() & 0x1FFF;  sprintf(temp, “ACHY %04d “, rint);  mySerial.write(temp);  sprintf(temp, “%02x\n”, chksum(temp, 9));  mySerial.write(temp);    _delay_ms(150);}

Because the students may not have seen these types of sensors before, they also had various imitation packing lists containing part numbers purchased by the company that manufactured the alarm system sensors. While this wouldn’t give away the answer, it suggested part numbers of sensors they might want to use in their attempt to bypass the beam break.

One team did exactly that; a photo of their robot sneaking through the beam break is given in Figure 5. The keen-eyed reader might notice a speaker on their robot, too. They decided to have it play a little tune while accomplishing the goal—not needed but it was there for a bit of extra style!

Naturally, there was more than one way to bypass most of the challenges. The other option I introduced was exploiting a vulnerable junction box, which could be manipulated using a strong enough magnet. In real life, attacks using strong magnets to trip relays were demonstrated.

In my course, this was done by a magnetic switch (reed switch) behind a thick piece of steel bar. This required precise alignment of the magnet, a particular challenge to do autonomously. If the reed switch was manipulated by the magnet, it effectively disabled the break-beam detector.

Advanced Challenges

Once students bypassed the bream break, by either sneaking through or disabling it with the magnet, there were three main challenges the teams faced. First, there was a safe that required them to manipulate the rotary locking mechanism. Second, there was a special laser sensor that used six laser beams to sense that the loot was present. To steal the loot, they had to block one of the laser beams (making it look like the loot was still present), while not tripping the rest of them. This was inspired by an Indiana Jones movie, and called the I.N.D.I.A.N.A. sensor. Finally, there was a cage that lifted when the students swiped an access card from an off-the-shelf RFID reader.

The RFID reader was a way of introducing students to classic hardware hacking. I chose an older RFID reader that used 125kHz tags, which are effectively just a serial number that is encoded onto them. In this case it used the XSF format, which is supported by the popular Proxmark 3 RFID reader. The students received a photo of the card from their hired private eye and needed to understand the protocol format to clone the card based on the numbers printed on the card.

A small Arduino decoded the data from the RFID reader and looked for the tag number, and if that number was seen, it would unlock the cage securing one of the loot pieces. This functioned just like a basic access control system.

Getting the card to align with the RFID reader was one of the engineering challenges; one team took the approach of holding an array of identically programmed cards. This made it easy to swipe the card without needing perfect alignment. This was a great example of solving problems using fundamentals—no need for complex alignment.

A more advanced robot, capable of accomplishing several goals, is shown in Figure 6. This photo shows several annotations. At (1) is the RFID card, held up in the air as they used an arm to bring it down to the reader for swiping, then out of the way when the robot was moving around. The cage (2) is shown up in the air, as they already successfully swiped the access card. They are picking up a piece of loot with a magnet at (3). They already successfully bypassed the I.N.D.I.A.N.A. sensor at (4) by leaving an object in the path of the laser while retrieving the loot. This was just one of several impressive robots to navigate the course.

Lessons Taught and Learned

The course was designed to teach a variety of topics explicitly, including design principles and hands-on tools such as Git usage and PCB design.

But the main lesson learned during the course is that making the most reliable and simple solution is often the best, even if we engineers like to make complex solutions. For example, picking up the pieces of loot could be done in several different ways. Many teams (including the winning teams) used simple magnets—no special logic needed. The robot could drag around the pieces due to the magnets attaching to steel built into the loot.

Of course, several teams wanted to make systems that didn’t just drag the pieces around but actually picked them up. For example, the robot from Figure 2 included an arm that could retrieve each piece of loot. Their arm could also interact with the safe and other course aspects. But a last-second bit of damage to the arm limited their capabilities. Despite it being a more capable design, it was less robust, which was the ultimate challenge.

As engineers, we need to make reliable systems, which often means not reaching for the most interesting and complex solutions. The course provided a harsh lesson by forcing students to confront these realities using strict time limits.

If you’re interested in reusing bits of the course, see the Resources for a link to my main GitHub account for the course. The design of many aspects of it have been posted, as well as slides on topics such as PCB design, which I introduced in the course. Feel free to reach out as well if anything isn’t available. I hope you find these bits helpful if you need to teach engineering students how to think like a hardware hacker and have a little fun while doing it. 

SOURCES
Main GitHub repository: https://www.github.com/colinoflynn/roboheist-challenge
Public website:  https://roboheist.com/

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2025 #420 – Get a PDF of the issue

Sponsor this Article