We like [Tim’s] drive for improvement. He wrote a WS2812 driver library that works with AVR and ARM Cortex-M0 microcontrollers, but he wasn’t satisfied with how much of the controller’s resources the library used to simply output the required timing signal for these LED modules. When he set out to build version 2.0, he dug much deeper than just optimizing his own code.
We remember [Tim] from his project reverse engineering a candle flicker LED. This time, he’s done more reverse engineering by comparing the actual timing performance of the WS2812(B) module with its published specs. He learned that although several timing aspects require precision, others can be fudged a little bit. To figure out which ones, [Tim] used an ATtiny85 as a signal-generator and monitored performance results with a Saleae logic analyzer. Of course, to even talk about these advances you need to know something about the timing scheme, so [Tim] provides a quick run-through of the protocol as part of his write-up.
Click the top link to read his findings and how he used them to write the new library, which is stored in his GitHub repository.
[Afonso] picked up a cheap energy use monitor a few years back. He really like the data it displays about his home’s electricity, using a sensor to gather this info and a display that communicates with it wirelessly. But there is no option to log or dump the data. He set out to reverse engineer the wireless protocol in order to extend the use of the system. As the name of this column implies, he failed to get this working.
The hardware above is a 433Mhz transceiver that he rigged up as test hardware. It sounds like he’s assuming the monitor works on this band, which could have been his first misstep (we really don’t know). The speaker is there to give audible confirmation that he’s receiving something from the transmitter. This is where things start to get pretty weird. White noise was coming from the speaker, but when he stepped away from the bench it stopped. He was able to measure a regular pattern to the noise, and proceeded to place the speaker next to his computer MIC so that he could record a sample for further analysis.
Fail of the Week always aims to be a positive experience. In this case we’d like to have a conversation about the process itself. We agree that connecting a speaker (or headphones) should help get your foot in the door because your ear will recognize a rhythmic pattern when it is received. But with this noise, measuring the timing and recording a sample we’re not so sure about. Given the situation, how would you have soldiered on for the best chance at successfully sniffing out the communication scheme used by this hardware? Leave a comment below!
Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.
Looking at this huge Uninterruptible Power Supply we are a little envious. It’s meant to hang on the wall of a utility room and power your critical devices. [Radek Hvizdos] has had it in service for quite some time, and when he started thinking of replacing the internal battery he decided to see if he could also extend the functionality. To do so he needed to get at the firmware of the chip controlling the device. And so began his adventure of dumping the firmware from the read-protected PIC 18F452.
The challenge of dumping code from a write-protected chip is in itself a fun project. But [Radek] was actually interested in fixing bugs and adding features. The wishlist feature we’d be most interested in is a kind of triage for shutting down devices as the internal battery starts to run low. Nice! But starting from scratch with the firmware is a no-go. You can see the two places where he connected to the PCB. The upper is for using a PIC programmer. The lower is an I2C connection used to dump the EEPROM with an improvised Bus Pirate.
In the end it was improper lock bit settings that opened the door to grabbing the firmware. The bootloader section of the PIC is not locked, and neither is the ability to read from FLASH at run-time. These two combined allowed him to write his own code which, when flashed to the bootloader section, dumps the rest of the firmware so that it may be combined into a complete file afterward. Since posting this fascinating article he has made a follow-up about disassembling the code.
When [Eloi] was home for Christmas, he faced one of the most difficult problems man has ever faced: his entire family, equipped with smartphones and laptops, siphoning all the Internet through a 1Mb/s connection. For any technically minded person, the fix for this problem is to limit the bandwith for all those Facebook and Twitter-heads, while leaving [Eloi]’s battlestation unaffected. [Eloi] had originally set up the Linksys WAG200G router in the family home a few years ago but had since forgotten the overly complex admin password. No worries, then, because apparently the WAG200G is open as wide as a barn door with a completely undocumented backdoor.
Without the password to the admin panel of the router, [Eloi] needed a way in. After pointing nmap at the router, he found an undocumented service running on port 32764. Googling this observation resulted in a lot of speculation, so the only option was to download the router’s firmware, look for the service, and figure out a way in.
[Eloi] eventually got a shell on the router and wrote a very short Python script to automate the process for all WAG200G routers. As for where this backdoor came from, it appears a SerComm device on the router is responsible. This means a whole bunch of routers with this specific SerComm module also have this backdoor, and we’d assume anything with a service running on port 32764 is suspect.
If you’re looking for a fix for this backdoor, your best bet is probably installing OpenWRT or Tomato. The OpenWAG200 project, an open firmware specifically designed for [Eloi]’s router, still has this vulnerability, though.
After a quick review of the Hackaday viewer demographics, we need to say the late 90s were weird. Even portable audio players were downright bizarre: MP3 players existed, but you loaded up your songs (all eight of them) over your PC’s parallel port. While helping a cousin move some furniture, [Ch00f] found a huge collection of one of the oddest music formats ever: HitClips, a tiny plastic encapsulated bit of circuitry that stores 60 seconds of terrible-sounding mono audio. Yes, this was a thing, but so was the pet rock. With no HitClips player, [Ch00f] decided he would take a swing at reverse engineering these tiny, tinny songs.
After taking apart the plastic enclosure, [Ch00f] found a very simple circuit: a few resistors, a cap, and an epoxy blob that enclosed an die with the musical data. On the back of the clip, there are eight pads for connecting to the player. With nothing to go on, [Ch00f] started poking around and found connecting one of these pins to ground caused circuit to draw 300uA of current for about 60 seconds – the same length of time as the recorded sample.
[Ch00f] originally thought the HitClip would provide audio data over an SPI or other digital protocol. What he found was much more interesting: two of the pins on the HitClip correspond to the push and pull FETs of a class D amplifier. The audio on the HitClip is digital audio, but it’s encoded so it can directly drive an analog circuit. Pretty clever engineering for a happy meal toy, if you ask us.
After dumping this data with a logic analyzer, [Ch00f] turned all the values in to .WAV file. It was, amazingly, music. A little refinement to the process to nail down the timing resulted in a 60-second clip seen (heard?) after the break.
Since [Ch00f] doesn’t want to spend $40 on eBay for a vintage HitClips player, he’s right about at the limit of what he can reverse engineer out of these cheap, crappy music chips. He has put up all his documentation, though, so if you’re up for improving on [Ch00f]’s methods, have a go.
Continue reading “Reverse Engineering HitClips”
Cyber Monday may be behind us, but there are always some hackable, inexpensive electronics to be had. [Stephen’s] wireless Android/Arduino outlet hack may be the perfect holiday project on the cheap, especially considering you can once again snag the right remote controlled outlets from Home Depot. This project is similar to other remote control outlet builds we’ve seen here, but for around $6 per outlet: a tough price to beat.
[Stephen] Frankenstein’d an inexpensive RF device from Amazon into his build, hooking the Arduino up to the 4 pins on the transmitter. The first step was to reverse engineer the communication for the outlet, which was accomplished through some down and dirty Arduino logic analyzing. The final circuit included a standard Arduino Ethernet shield, which [Stephen] hooked up to his router and configured to run as a web server. Most of the code was borrowed from the RC-Switch outlet project, but the protocols from that build are based on US standards and did not quite fit [Stephen’s] needs, so he turned to a similar Instructables project to work out the finer details.
Stick around after the break for a quick video demonstration, then check out another wireless outlet hack for inspiration.
Continue reading “Android and Arduino RF Outlet Selector”
When his 6 years old induction cooker recently broke, [Johannes] decided to open it in an attempt to give it another life. Not only did he succeed, but he also added Bluetooth connectivity to the cooker. The repair part was actually pretty straight forward, as in most cases the IGBTs and rectifiers are the first components to break due to stress imposed on them. Following advice from a Swedish forum, [Johannes] just had to measure the resistance of these components to discover that the broken ones were behaving like open circuits.
He then started to reverse engineer the boards present in the cooker, more particularly the link between the ‘keyboards’ and the main microcontroller (an ATMEGA32L) in charge of commanding the power boards. With a Bus Pirate, [Johannes] had a look at the UART protocol that was used but it seems it was a bit too complex. He then opted for an IOIO and a few transistors to emulate key presses, allowing him to use his phone to control the cooker (via USB or BT). While he was at it, he even added a temperature sensor.