Before I start, I’d like to note that this is my first reverse engineering project.
So the story here starts with me taking a class that required me to purchase one of these iClicker’s ( http://www.iclicker.com/Products/iclicker/ ), otherwise I wouldn’t get “participation” points in class :/ So I purchased one and booted it up during lecture to “participate”. It was neat to see some tech in the classroom, but the material wasn’t any more interesting, so I decided to tear this thing apart… I busted out my utilikey and tore it apart mid-lecture.
At this point the professor noticed all the students were “participating” except me. She then walked up to my desk and noticed the iClicker completely torn apart and asked “What are you doing?” to which I responded “Opening this thing up..” and she responded with “This is not apart of the lecture, you shouldn’t be doing this in class. This is very important you should be paying attention.” I figured it’s time to protect my grades so I said I would clean it up right away, and did so.. (unhappily)
I snapped a few shots of the tear down before doing so..
Here we see the Buttons “A” “B” “C” “D” “E” and “ON/OFF”.
Noticed the RF hardware consisted of an XE1203F ( http://www.semtech.com/images/datasheet/xe1203f.pdf ) which does ISM band (iClicker is configured for 900Mhz)
Discovered the microcontroller is an ATMega8A ( http://www.atmel.com/dyn/resources/prod_documents/doc8159.pdf ) and best of all.. the ICSP pads are broken out for you already!! At this point I was hoping that the security bit wasn’t set so I could dump the firmware and EEPROM.
I later got to my setup at Nullspace Labs ( http://032.la/ ) and soldered on a 6pin header for the ICSP line. Then connected my AVR Dragon and attempted to dump the firmware and EEPROM from the ATMega8A with an external power supply connected to the power leads for the battery. As soon as I attempted the read, the iClicker reset itself. So I figured the power management must be doing some funky things, so lets by pass all that and go directly to the ATMega8A’s VCC and GND line. I soldered on some kynar wire to pin 4 (vcc) and pin 5 (gnd) and attempted the read again..
Success!! The security bit was never set! So now that I could communicate with the chip, I decided dumped the firmware and EEPROM. (Reversing in IDA to come in Part 2)
At this point I realized the hardware ID must be in the EEPROM, so I went exploring looking for “3300B586” which is the hardware ID written on the back of the device:
I noticed at line 0 column A the sequence “3300B5”, huzah! At this point I could just modify this and change the hardware ID of the iClicker!
Next I decided to listen to the communication between the ATMega8A and XE1203F by sniffing the SPI bus, following the datasheets I soldered up some wire to the SPI lines. Once the wiring was done I used my handy AnnaLogic to sniff the SPI bus.
AnnaLogic (16-channel logic analyzer) from Nullspace Labs (available for purchase here for $40: http://www.nullspacelabs.com/catalog/products.php?5&sid=mkkhjkoj10qo012972ufdfhka3 ) Totally easy to use and it fits in an egg!!
Once I powered up the iClicker (note: it’s not connected to an instructor machine) I began the sniffing and pressed the following sequence of buttons: A B C D E . I noticed that there was only data on the Slave Input lines, which makes sense since there is no instructor machine to send data back. Between each button I pressed only one byte was changed, and it doesn’t seem to be as intuitive as ‘A’, ‘B’, ‘C’,’D’,’E’. Instead A = 177 (0xB1) , B = 181 (0xB5), C = 189 (0xBD), D = 190 (0xBE), E = 186 (0xBA).
Next I need to capture some traffic between my iClicker and the instructor machine to see a full cycle of registering the iClicker to the instructor machine, voting and receiving confirmation that the vote went through.. I’ll leave that for Part 2.
Please note that I will NOT be doing this packet capture in the classroom (it’s no place for learning anyway), I’ve decided to purchase an instructor base station to prevent any issues with my school. Plus it gives me control to test and try out things I normally wouldn’t be able to do.
For the mean time I need the clicker for lectures so I’ve poked a hole into it.. totally looks normal 🙂
Next up.. reverse engineering the firmware in IDA, stay tuned for Part 2:
So far the only defeat has been spoofing other iClicker hardware ID’s by reprogramming the EEPROM (thankfully iClicker never set any security bits 🙂 ) It’s not much yet, but next up is to reverse the firmware and figuring out how the packets are sent, handled and then to create a new firmware with some extra features. A few new features I’ve thought of are listening in to other iClickers, submitting and spoofing as other iClickers, and making a general purpose ISM band radio.
Interested in hardware hacking? Layerone 2012 http://www.layerone.org/ 🙂
21 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. […]
I would get in soooo much trouble for having these in the classroom… Oh so, so much trouble…
[…] [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. […]
usrp plugin for 900mhz iclicker
http://gr-clicker.sourceforge.net/
Found this when I started the project! Can’t wait to take a crack at it.
I looked into modding the iclicker, but I didn’t have a logic analyzer laying around. I love how there is an atmega8 which isn’t locked down. The radio circuit and controller are very separate.
I’m guessing whoever designed this doesn’t like the idea of the product, and leaving the firmware open.
It was just calling out to be hacked. Btw, if you want a good logic analyzer for cheap I’d recommend the Annalogic: http://www.nullspacelabs.com/catalog/
I actually did most of this, except the snooping of RF, and even wrote a naive ARM-asm to C compiler to make reading the firmware easier (ish).
I have a git repo for it at git@fahhem.com:avr_to_c.git. I can give you access, but I need your public key first.
If you have a buspirate you could just link onto the SPI lines during class and dump the whole session transparently while “participating” normally. If you have an n900 you can even do it without anything but a random cable going from pocket (containing n900+buspirate) to clicker. I’m sure it can be done with other phones/tablets as well.
Thought about it, but the risk of getting caught and people over reacting (especially the professor) is just not worth it.
Also, I noticed there is encryption on the iClicker so that without the key entered into the base station, the base can’t understand the clicker. But there is a mode that, when sent from the base station, puts the iClicker into non-encryption mode and sends its ID over the wire (for iClickers whose label has been worn away). You can send that command from any iClicker (since they put a transceiver, not a transmitter only) and get IDs for every iClicker in the room. Then spoof everyone in the class whenever you want. Since only the last-entered value is stored so you can overwrite everyone if you attach a faster processor with the new firmware to the transceiver (or multiple) and send all the results at the last second.
Diabolical! I will look into this, thanks for the tip! I figured that is the only way to spoof everyone else. I however will NOT be doing this in my class, but just for demo at home. I need to get a hold of one of these base stations.
Nice post – look forward to part 2.
Thought this might interest you if you’ve not come across it before – its Travis Goodspeeds reversal work on the iClicker including Snooping http://travisgoodspeed.blogspot.com/2010/07/reversing-rf-clicker.html
Goodspeeds work is great! I’ve been looking at his work for ideas on where to snoop around and techniques of reverse engineering. Good stuff.
This has me interested in IDA, which version are you using and how did you make it load the hex file? The latest free version doesn’t support hex.
I’m running 5.5, it was simple as just opening the file with IDA and selecting the chip.
Can’t wait for Part 2.
Never knew that IDA supports AVR awesome! Tried it on my one with one of my one hex files, but the structure of the diassembled code is new for me 🙂
Think your next Part will help 😉
Greetings from Germany
Yeah, I’m excited to get started on it tonight, It’s my first reversing project with IDA so I’ll try to document it well enough for anyone to do it on their own! 🙂
Grüße aus Amerika
How’s it going?
Yep, those button codes agree with mine:
/* codes transmitted by iclicker */
#define BUTTON_A 0x1
#define BUTTON_B 0x5
#define BUTTON_C 0xD
#define BUTTON_D 0xE
#define BUTTON_E 0xA
#define JOIN_CHAN 0x2
I wrote a simple iclicker sniffer for the Girltech IM-Me a while back. It was based entirely on over the air observations (as was gr-clicker). Email me if you want the source. The one big thing I never did was figure out how the ID is encoded, though you don’t need to know that to spoof another device once you have recorded a transmission from that device. Still, you should be able to figure out the encoding from reversing the firmware.
Awesome! I’m glad the button codes agree. I can’t wait to reverse the firmware to figure out that ID encoding. I think I’ll take you up on the offer for code and shoot you an email. Also, I think we met at Toorcon this year.. 🙂