Solving The Final Part Of The IClicker Puzzle

May 21, 2019 by Tom Nardi 9 Comments

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.

Emulating A Student Clicker With An Arduino

November 16, 2012 by Brian Benchoff 20 Comments

When schools and universities have hundreds of students in a lecture course, they need a way to tell alumni and other potential benefactors that faculty/student relations are just as good as they were in the 1960s, when enrollment was just a fraction of current levels. Technology solves all problems, apparently, so administrators of these universities turn to ‘clickers’ – radio frequency remotes used to take attendance and administer quizzes.These clickers have absolutely no security, so it’s no surprise [Taylor Killian] was able to emulate one of these clickers with an Arduino allowing anyone with a laptop to cheat on a quiz, or have an entire class show up with only one student in the room.

Previously [Travis Goodspeed] (thanks for sending this in, [Travis]) tore apart one of these clickers – a TurningPoint ResponseCard RF – and discovered it uses a Nordic nRF24L01 wireless transceiver, commonly available on eBay for about two dollars.

[Taylor] connected this wireless module to an Arduino and whipped up a bit of code that allows him to listen to the audience responses, respond to a question as either a single clicker or all clickers, automatically respond with the most popular answer, and even block all audience responses to each question.

Perhaps technology doesn’t solve every problem, but at least [Taylor] learned something from a glorified remote control sold at the bookstore at an insane markup.

Snooping Around In The Iclicker Hardware And Firmware

October 23, 2011 by Mike Szczys 26 Comments

[Arko] was compelled to purchase an iclicker to use in some of his college courses. It’s similar in size to a television remote control except it only has six buttons and it communicates via radio frequency instead of infrared light. The idea is that classrooms have a base station that the instructor uses, and he or she can ask questions of the class and have instant feedback. Results are often projected on a screen for all to see but only the instructor can get at the breakdown of who answered in what way. In [Arko’s] case, the class awards participation points that you can only get by using this device. He decided to actually learn something from the expenditure by reverse engineering the device.

Preliminary hardware inspection told him that it uses an ATmega8 microcontroller and there’s a standard 6-pin ISP footprint just waiting to be populated with a surface mount pin header. Once he soldered on that header, he tried to read out the firmware but the iClicker reset itself. He guessed that there was something going on with the power and ground lines so he soldered directly to them and was able to dump the data–the security fuses are not set. He goes on to snoop in the EEPROM to find where the device ID is stored, and then to watch some of the SPI communications to see what the microcontroller is sending to the radio chip. But there’s a lot left to discover and he’s planning at least two follow-up post to share what he finds.

Just looking to repair your dead device? Check out this tip on battery problems with the iclicker.

A Simple Fix To Resurrect Your Broken Iclicker

September 12, 2011 by Mike Nathan 34 Comments

simple_iclicker_battery_fix

If you are currently attending college, the odds are that you are familiar with iclicker classroom remotes. If you have one of these, you might also be aware that they tend to be flaky at times, particularly when it comes to powering on. [Todd] received a few “broken” iclickers lately and has found an easy to fix design issue that might possibly save yours (and others) from the trash heap.

When he started pulling the units apart to diagnose them, he noticed that something with the battery contacts was not quite right. They are held in place by the device’s plastic shell which is pretty common, however in the iclicker, the portion of the plastic case that holds the positive battery contact is too big, preventing some batteries from making a complete circuit.

Now you might be thinking to yourself that AA batteries are all the same, but they are not necessarily created equal. Through a small bit of testing, [Todd] found that many different batteries experienced intermittent connectivity issues depending on the height of the positive terminal, and that due to their design, Duracell batteries flat out didn’t work. With the careful removal of a portion of the plastic surrounding the positive contact, [Todd] was able to fix each of his “broken” remotes.

He hopes that this information helps some people resurrect their non-functioning units, because a few minutes work sure beats buying another $30 iclicker.

Wireless Sniffing And Jamming Of Chronos And Iclicker

January 25, 2011 by Joseph Thibodeau 1 Comment

The ubiquitous presence of wireless devices combined with easy access to powerful RF development platforms makes the everyday world around us a wireless hacker’s playground. Yesterday [Travis Goodspeed] posted an article showing how goodfet.cc can be used to sniff wireless traffic and also to jam a given frequency. We’ve previously covered the work of [Travis] in pulling raw data from the IM-ME spectrum analyzer, which also uses goodfet.cc.

The Texas Instruments Chronos watch dev platform contains a C1110 chip, which among other things can provide accelerometer data from the watch to an interested sniffer. The i>clicker classroom response device (which houses a XE1203F chip) is also wide open to this, yielding juicy info about your classmates’ voting behaviour. There is still some work to be done to improve goodfet.cc, and [Travis] pays in beer–not in advance, mind you.

With products like the Chronos representing a move towards personal-area wireless networks, this sort of security hole might eventually have implications to individual privacy of, for example, biometric data–although how that might be exploited is another topic. Related to this idea is that of sniffable RFID card data. How does the increasing adoption of short-range wireless technologies affects us, both for good and bad? We invite you to share your ideas in the comments.