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.
Making a programming jig becomes exponentially more difficult after two pins and who would even consider building one if they were not setting up more than twenty boards? If it were easy for novices to construct jigs, we might all have a quiver of them on the shelf next to our microprocessors. Honestly, a tackle box full of homemade programming fixtures sounds pretty chic. The next advantage to ditching the demo boards is that bare processors take up less room and don’t draw power for unnecessary components like unused voltage regulators and LEDs. [Albert David] improves the return-on-time-investment factor by showing us how to repurpose a WeMos board to program a bare ESP8266 module.
[Albert]’s concept can apply to many other surface-mount chips and modules. The first step is to buy a demo board which hosts a programmable part and remove that part. Since you’ve exposed some solder pads in the process, put pogo pins in their place. Pogo pins are small spring-loaded probes that can be surface mounted or through-hole. We’ve used them for programming gorgeous badges and places where the ESP8266 has already been installed. When you are ready to install your software, clamp your Franken-porcupine to the controller and upload like normal. Rinse, wash, repeat. We even get a view of the clamp [Albert] uses.
eBay is a wondrous land, full of Star Wars memorabilia in poor condition, old game consoles at insane markups, and a surprising amount of DIY electronics. [TheHWCave] found himself tinkering with a common frequency counter kit, and decided to make a few choice improvements along the way (Youtube link, embedded below).
The frequency counter in question is a common clone version of [Wolfgang “Wolf” Büscher]’s minimalist PIC design. Using little more than a PIC16F628 and some seven-segment displays, it’s a competent frequency counter for general use. Clone versions often add a crystal oscillator tester and are available on eBay for a fairly low price.
[TheHWCave] found that the modifications were less than useful, and developed a way to turn the tester components into a more useful signal preamp instead. Not content to stop there, custom firmware was developed to both improve the resolution and also add a tachometer feature. This allows the device to display its output in revolutions per minute as opposed to simply displaying in hertz. By combining this with an optical pickup or other RPM signal, it makes a handy display for rotational speed. If you’re unfamiliar with the theory, read up on our phototachometer primer. If you’re looking to modify your own kit, modified firmware is available on Github.
We’ve seen other eBay kit specials modified before. Being cheap and using commodity microcontrollers makes them a ripe platform for hacking, whether you just want to make a few tweaks or completely repurpose the device.
[Thanks to Acesoft for the tip!]
Continue reading “Hacking A Cheap eBay Frequency Counter”
It might be difficult for modern audiences to believe, but at one point Microsoft Windows fit on floppy disks. This was a simpler time, with smaller hard drives, lower resolution displays, and no hacker blogs for you to leave pessimistic comments on. A nearly unrecognizable era, to be sure. But if you’re one of the people who looks back on these days fondly, you might wonder why we don’t see this tiny graphical operating system smashed into modern hardware. After all, SkiFree sure ain’t gonna play itself.
Well, wonder no more. A hacker by the name of [redsPL] thought that Microsoft’s latest and greatest circa 1992 might do well crammed into the free space remaining on a ThinkPad X200’s firmware EEPROM. It would take a little fiddling, plus the small matter of convincing the BIOS to see the EEPROM as a virtual floppy drive, but clearly those are all minor inconveniences for anyone mad enough to boot their hardware into a nearly 30 year old copy of Visual Basic for a laugh.
The adventure starts when [redsPL] helped a friend install libreboot and coreboot on a stack of old ThinkPads by using the Raspberry Pi as an SPI flasher, a pastime we’re no strangers to ourselves. Once the somewhat finicky software and hardware environment was up and running, it seemed a waste not to utilize it further. Especially given the fact most firmware replacements only fill a fraction of the X200’s 8 MB chip.
Of course, Windows 3.1 was not designed for modern hardware and no proper drivers exist for much of it. Just getting the display resolution up to 1024×768 (and still with only 256 colors) required patching the original video drivers with ones designed for VMWare. [redsPL] wasn’t able to get the sound hardware working, but at least the PC speaker makes the occasional buzz. The last piece of the puzzle was messing around the
xz commands until the disk image was small enough to sneak onto the chip.
Believe it or not, this isn’t the first time we’ve seen Windows from this era running on a (relatively) modern ThinkPad. For whatever reason, these two legends of the computing world seem destined to keep running into each other.
[Thanks to Renard for the tip.]
If you missed it, the Hackaday Supercon 2018 badge was a complete retro-minicomputer with a screen, keyboard, memory, speaker, and expansion ports that would make a TRS-80 blush. Only instead of taking up half of your desk, everyone at the conference had one around their neck, when they weren’t soldering to it, that is.
The killer feature of the badge was its accessibility and hackability — and a large part of that was due to the onboard BASIC interpreter. And that’s where Jaromir comes in. Once Voja Antonic had finalized the design of the badge hardware for our conference in Belgrade in the spring of 2018, as Jaromir puts it, “all we needed was a little bit of programming”. That would of course take three months. The badge was battle-tested in Belgrade, and various feature requests, speed ups, and bugfixes were implemented (during the con!) by Jaromir and others.
Firmware work proceeded over the summer. Ziggurat29 helped out greatly by finding ways to speed up the badge’s BASIC interpreter (that story is told on his UBASIC and the Need for Speed project page) and rolled into the code base by Jaromir. More bugs were fixed, keywords were added, and the three-month project grew to more like nine. The result: the badge was in great shape for the Supercon in the fall.
Jaromir’s talk about the badge is supremely short, so if you’re interested in hacking a retrocomputer into a PIC, or if you’ve got a badge and you still want to dig deeper into it, you should really give it a look. We don’t think that anyone fully exploited the CP/M machine emulator that lies inside — there’s tons of software written for that machine that is just begging to be run after all these years — but we’re pretty sure nearly everyone got at least into the basement in Zork. Dive in!
Continue reading “Jaromir Sukuba: The Supercon 2018 Badge Firmware”
We can’t think of where you’d buy a new, cheap, MIDI keytar that’s just a keyboard and a handle with some pitch and mod wheels or ribbon controllers. This is a format that died in the 90s or thereabouts. Yes, the Rock Band controller exists, but my point stands. In fact, the closest you can get to a cheap, simple MIDI keytar is the Alesis Vortex Wireless 2 Keytar, but the buttons on the handle don’t make any sense. [marcan] of Wii and Kinect hacking fame took note. (YouTube, embedded below.)
Reverse engineering is a research project, and all research projects begin with looking at the docs. When it comes to consumer electronics, the best resource is the documents a company is required to submit to the FCC (shout out to FCC.io), which gave [marcan] the user manual, and photos of the guts of the keytar. The ‘system update download’ files are living on the Alesis servers, and that’s really all you need to reverse engineer a keytar.
The first step is extracting the actual device firmware from whatever software package appears on the desktop when you download the software update. This is a simple job for 7zip, and after looking at a binary dump of the firmware, [marcan] discovered this was for an STM chip. With the datasheet of the chip, [marcan] got the entry point for the firmware, some values, and the real hardware hacking began. All of this was done with IDA.
This is a five-hour hacking session of cross-referencing the MIDI spec and a microcontroller built thirty years after this spec was developed. It’s an amazing bit of work just to find the bit of code than handled the buttons on the keytar grip, and it gets even better when the patched firmware is uploaded. If you want to ‘learn hacking’, as so many submitters on our tip line want to do, this is what you need to watch. Thanks [hmn] for the tip.
Continue reading “Live Hacking And A MIDI Keytar”
Firmware and software are both just code, right? How different could the code that runs Internet-scale distributed web stuff be from the code that runs a tiny microcontroller brain inside a personal hydroponics device? Night and day!
Ruth Grace Wong works in the former world, but moonlights as a manufacturing engineer with some friends. Their product had pre-existing firmware that contained (at least) one bug, and Ruth’s job was to find it. The code in question was written by the Chinese PCB engineer, who knew the electronics intimately but who had no software background, providing Ruth an opportunity to jump head-first into the rawest of raw embedded programming. Spoiler alert: she found the bug and learned a lot about firmware along the way. This talk follows her along the adventure.
“The code is very well documented, in Chinese” but the variable names are insanely non-descriptive. Similarly, while the PCB engineer knows full well what a
24C02 is, if you’re a software geek that might as well be Chinese. As you’d expect, web searches came to the rescue on both fronts.
The bug ended up hiding in a logical flaw in the PWM-setting code inside an interrupt service routine, and it kept the fan from ever coming full on. Once found, it was easily fixed. But getting to the point where you understand the codebase deeply enough to know where to look is four-fifths of the battle. Heck, setting up the toolchain alone can take a day or two.
If you’re a fellow software type, Ruth’s talk (embedded below) will give you a quick glimpse into the outer few layers of the onion that is embedded firmware development, from a familiar viewpoint. Give her quick and value-packed talk a watch! Grizzled hardware veterans will nod along, and maybe even gain a little insight into how our code looks to “them”.
Continue reading “Supercon: Ruth Grace Wong and Firmware From the Firehose”