Solving The Final Part Of The iClicker Puzzle

Solving The Final Part Of The iClicker Puzzle

The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.

[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.

He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.

This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.

At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.

Solving The Final Part Of The iClicker Puzzle
Source: HackADay

0Shares