Author: Jon Backman 🕵️ — May 31, 2022
The iClicker is the most popular in-class polling system in the nation, used in university classrooms all around the country. The iClicker system involves using a simple USB base station that connects to the lecturers computer and audience members respond using a simple radio remote device. Using iClicker software, the lecturer can choose a special radio frequency and pose a poll towards the viewers. The viewers then have the option to respond with one of five answers. Answers include the letters A-E.
Using software defined radios (SDRs) we were able to replicate the behaviors of the remotes towards the base station. We continued to use this knowledge to later change and copy data coming from other remotes transmitting on the same radio frequency. The purpose for this demonstration was to teach principles of GNU radio and teach principles of software defined radios. No malicious or hostile objectives were intended. We hope that the readers of this post will use this knowledge for educational pursuits and not for ill-natured purposes.
The iClicker has three models for the remotes; iClicker, iClicker+, and the the iClicker2. For this experiment we used the iClicker+ remotes, but this implementation should work for all different kinds of remotes. We also used the iClicker Classic software, because this software enables the user to pick different frequencies for the base channel. A big inspiration for how to hack the iClickers came from a paper published titled “Reverse Engineering Classroom Polling: A Case Study”. From this article we learned how the hardware works and more importantly how the software protocol to send and receive answers using the iClicker remotes works.
The remote operates on two different frequencies. One frequency for transmitting answers to the base station and another frequency for receiving an acknowledgement from the base station. The remote will change these two frequencies based on the channel chosen by the base station. With this knowledge we knew what frequencies we would need to set our SDRs to in order to replicate the behavior of the iClicker remotes. We are mostly interested in the transmitting frequencies as we only want to replicate a iClicker remote and not a base station.
Source: Reverse Engineering Classroom Polling: A Case Study
The next step in understanding the iClicker is comprehending the contents of the payload of an answer transmitted by a remote. The first step in replicating the payload is to create a 3 byte and 1 nibble stream that contains the remote ID. The remote ID can be found on the back of the iClicker remote above the barcode. We are only interested in the first 3 bytes of that ID as that is the only bytes the iClicker remote encodes in the payload. The remote will encode this data using the following algorithm.
[Source: Reverse Engineering Classroom Polling: A Case Study](<https://github.com/wizard97/iSkipper>)
The last nibble of the 4th byte will contain the answer that is being transmitted by the remote. These nibbles are constant across all frequencies given by the base station and across all remotes. The following shows which nibble corresponds to which answer.
Source: Reverse Engineering Classroom Polling: A Case Study
The last byte of the payload is the sum of the last 4 bytes of the packet mod 256 plus a constant based on the answer being transmitted.
Source: Reverse Engineering Classroom Polling: A Case Study
These 5 bytes make up the majority of the payload being sent to the iClicker base station from the iClicker remote. Before transmitting the 5 bytes the iClicker remote will first send 3 bytes of either 0x55 or 0xAA, then transmit a 3 byte sync address( 0x85, 0x85, 0x85). Afterwards, the iClicker will then send the 5 byte payload of encoded data with the remote ID and the answer included. If everything was done correctly than the base station will respond back at a lower frequency. An example of this transmission is shown below. This transmission was collected using a HackerRF software defined radio.
Channel AB, Answer C
Now that we understand how the iClicker remotes worked, we wanted to create our own remote using SDRs. We used two Universal Software Radio Peripherals (USRP) to act as the remotes. These two USRPs have the capability to transmit and receive any signals on a pre-programmed frequency. With the USRPs we could assign the data being received to a socket on the device and the data to be transmitted to a different socket on a different device. This allows us to use Python to gain easy access to the data being received by the software defined radios. We did all of this implementation with the USRPs in GNU radio.
We now had access to packets being transmitted over the air, we just needed to be able to read the packets according to how the iClicker software worked. We did this by first creating a station class in Python. This class contained many functions that would read encoded bytes and decode them. Within the class contains a receiving function and a transmitting function. The receiving function will print out the remote IDs and answers to any transmission it can hear. The transmission function requires a text file with remote IDs and answers. It will then transmit all the contents of the given text file. Next we created a running Python program that would include the station class and use command line controls to make it easier for the user to choose what functions they wanted to use.