No matter how good the intentions or how strong your hack-fu may be, sometimes you just can’t cross the finish line with every project. Here’s one that we hate to see go unfinished, but it’s obvious that a ton of work already went into reclaiming these smart white-board projectors and it’s time to cut the losses.

The hardware is a Smartboard Unifi 35″ computer with a projector mounted on a telescoping rod. It was manufactured for use with a touch-sensitive white board which the guys at the Milwaukee Makerspace don’t have. The projector works, but all it will display is a message instructing the user to connect the computer to the white board. Since they’ve got a couple of these projectors, it would be nice to salvage the functionality.

The first attempt was to replace the video signal to the projector. A few test boards were etched to experiment with DVI input. This included several logic sniffing runs to see what the computer is pushing to get the warning message to display. Alas, the group was not able to get the device to respond. But this opens up a great opportunity for you to play Monday morning hacker. Take a look at the data they’ve posted in the link above and let us know how you would’ve done it in the comments.

[Todd Harrison] took a slew of pictures in his quest to loose all the secrets of the G-35 Christmas Lights. These are a string of 50 plastic bulbs which house individually addressable RGB LEDs. We’ve seen a ton of projects that use them, starting about a year ago with the original reverse engineering and most recently used to make a 7×7 LED matrix. But most of the time the original control board is immediately ditched for a replacement. It’s become so common that you can now buy a drop-in board, no hacking needed. We enjoy the hard look that [Todd] took at the electronics.

The stock controller uses a single layer, single sided board. There’s a resin-blob chip, but also an SOP-20 microcontroller. Since [Todd's] using several strings of lights on his house, he wondered if it would be possible to improve on the controller in order to synchronize the strands. His investigation showed that the board was designed to host a crystal oscillator but it is unpopulated. Unfortunately you can’t just add those parts to improve the timing of the chip (firmware changes would also be requires). He found that there’s a spot for a push-button. Quickly shorting the pads cycles through the effects, shorting them for a longer time turns off the string of lights. There is wireless control, but it seems that the only functionality it provides is the same as the unpopulated switch.

We enjoyed the close-up circuit board photos, and we like the spacing jig he used to attach the lights to his fascia boards. We’ve embedded a lengthy video about his exploits after the break.

The difference between Fluke’s 54 II and 51 II thermometers is the addition of a second channel for dual temperature sensing, and buttons which control data logging. Oh, and an additional $150 in price for the higher model. [TiN] was poking around inside and with the help of some forum members he figured out how to unlock additional features on his low-end Fluke temperature meter. You can do the same if you don’t mind cracking open the meter, sourcing and soldering most of the components seen above, cutting holes in the case for the buttons, and hoping it still works when you put everything back together.

It seems that Fluke designed one full-featured unit and watered it down to fill a hole in the lower-priced market just like some other testing-hardware manufacturers (Rigol’s digital storage oscilloscopes come to mind). But the MSP430 P337I in this meter cannot be reflashed, so this would most likely be unhackable hardware if the firmware for the two models is different. After some intensive study of the PCB layout [TiN] found a set of resistors which seemed to serve no external hardware purpose. They do connect to the microcontroller and together they create a two-bit code. He was able to get pictures of the four different hardware models and work out which resistor combinations identify the different meters. Now he can get the firmware to believe it is operating a Fluke 54 II, the rest is just putting the correct passive components onto the unpopulated locations.

We think the quest is what is of interest with this hack. [TiN] did an amazing job of photographing and writing about each step in the process. We’re unlikely to try this ourselves but loved reading about it.

Almost a month ago I started trying to reverse engineer an inexpensive LED color changing light bulb. With your help I’ve mapped out the circuit, and taken control of the bulb. But there’s still a few mysteries in this little blinker. Join me after the break to see what I’ve done so far, peruse the schematic and source code, and to help solve the two remaining mysteries.

What I’ve Accomplished

First off, thank you to all the commenters on the original post. I figured a lot out about this circuit because of that help. Notably, that the code I had dumped wasn’t any use because the lock bits had been set. There was also a lot of constructive input and conjecture about this when I shared it at the Sector67 meeting on Tuesday (a hackerspace here in Madison).

I’m happy to say that I was able to program the ATtiny13 chip while in place. I damaged the first bulb I cracked open by drilling through an inductor. The second time I was more careful, and soldered ribbon cable onto each of the microcontroller pins.

I can program this chip without removing it from the board. This is accomplished by using High Voltage Serial Programming (HVSP) while AC power is not connected. I reset the fuses to factory settings to enable the reset pin but I have been unable to program this using ISP. But that’s not really a problem. The diffuser was taped in place and I added an IDC connector for easy interface with the bulb.

The firmware I’ve written is up on GitHub. It has a few features; the default operation is to fade between red and green every 20 minutes as a porch light during this Christmas season. I’ll discuss the circuit below, but there are two unused pins on the device and I’ve added two test modes that are entered by jumping the pin to ground on the IDC connector. One of the test modes makes the red/green fader happen every 2 seconds. The other scrolls through primary and secondary colors with a 1/2 second delay.

So what we have is a microcontroller that drives two RGB LED modules in series. This chip has two available pins and 1K of programming space. So it should be relatively simple to make this into an I2C addressable module. Ideally this would be done without using AC power, sparking one of the questions I ask at the bottom of the post.

The Circuitry

I traced out the circuit board and recreated the schematic using an Ohmmeter and continuity Tester. There are two separate schematics, one for the LED control circuitry and another for the power supply.

As expected, the power supply uses the example circuit from the LNK304 datasheet. The 12V output connects to the two VCC points on the controller schematic but the ground or return path is a bit peculiar. Look at the upper leg on the PSU schematic which includes R2, R3, R10, and C7. I’ve labeled this as ‘GND (5V rail)’ because this connects to the ground side of the ATtiny13. The ‘GND (12V rail)’ connects to the low side of the LEDs but that is separated from the microcontroller ground path. Obviously the Zener diode is clamping power input for the microcontroller (which needs 5V), but I have no idea how the filter circuit leading back to the AC hot is working.

Take a look at the component list and then see if you can help solve two questions.

• R1 – inline with center conductor of light socket; ~0.5 Ohm. Might be a fuse
• R2 – 1004
• R3 – 1004
• R4 – 3001
• R5 – 1302
• R6 – 1201
• R7 – 1Bx
• R8 – 270
• R9 – 270
• R10 – 1003
• D1 – 1N4007
• D2 – 1N4007
• D3 – R106 TF
• D4 – Looks like a zener
• D5 – RGB LED
• D6 – RGB LED
• D7 – JF S1J
• IC1 – PNP Transistor
• IC2 – PNP Transistor
• IC3 – PNP Transistor
• IC4 – LNK304GN AC/DC switching converter
• IC5 – ATtiny13
• C1 – smd without label
• C2 – 50V 22 uF electrolytic
• C3 – 400V 4.7 uF electrolytic
• C4 – 400V 4.7 uF electrolytic
• C5 – 25V 100 uF electrolytic
• C6 – smd without label
• C7- smd without label
• L1 – 102J CEC
• L2 – 102J CEC

Help solve these two questions:

1. How does the GND connection for the ATtiny13 work? A complete answer will explain what the path that includes R2, R3, R10, and C7 actually does, and how it works in conjunction with the switching converter.

2. What is the easiest way to power the control circuit using DC?

Feel free to leave a comment with your thoughts. But if you’re so inclined, I’d love to read a more verbose description so post your thoughts on your own host and leave a link in the comments.

Follow Me

szczys

I went to the last monthly meeting of Sector 67, a hackerspace in Madison, WI. One of the things shown off was a color changing LED light bulb that Menards was clearing out for $1.99. Inside there’s two RGB LEDs controlled by an ATtiny13 and powered by an AC/DC buck converter. An ATtiny13 will run you around $1.25 by itself so this price is quite amazing. I grabbed a couple of these bulbs and set to work on them. Join me after the break to see what I’ve got so far.

These bulbs use a candelabra base so I grabbed an adapter and tried it out in a lamp. Here’s the result, you can see it stepping through color levels a few times a second:

We’ve seen this in a lot of mood light hacks, I want to get at the hardware and make it do my bidding. First thing’s first, time to crack it open. For some reason I thought that carefully drilling some holes around the base would help me figure out where best to use the Dremel cutting wheel. Unfortunately I immediately drilled through one of the inductor coils. Drat.

Well, no stopping now. I’m not too worried as I also bought a solid red version of this bulb. I want to see what’s inside, whether it’s the same design with unpopulated components, or the full shebang with different hardware. I assume there’s no microcontroller inside so I’ll steal the inductor from that one later.

I cut off the diffuser and got to the circuit board. Here’s some images (click for hi-res) as well as a cursory list of hardware.

Top:

• R2 – 1004
• R3 – 1004
• R4 – 3001
• R5 – 1302
• R10 – 1003
• D4 – Looks like a zener… perhaps to set down votage for the tiny13
• D5 – RGB LED
• D6 – RGB LED
• D7 – JF S1J
• IC5 – ATtiny13
• C1 – smd without label
• C7- smd without label

Bottom:

• R1 – inline with center conductor of light socket
• P1 & P2 – Labels for incoming AC power?
• L1 – 102J CEC
• L2 – 102J CEC
• C2 – 50V 22 uF electrolytic
• C3 – 400V 4.7 uF electrolytic
• C4 – 400V 4.7 uF electrolytic
• C5 – 25V 100 uF electrolytic
• C6 – smd without label
• D3 – R106 TF
• R6 – 1201
• R7 – 1Bx
• R8 – 270
• R9 – 270
• IC1 – NGS (transistor for driving LEDs?)
• IC2 – NGS (transistor for driving LEDs?)
• IC3 – NGS (transistor for driving LEDs?)
• IC4 – LNK304GN AC/DC switching converter

I wanted to see if I could talk to the ATtiny13 so I soldered wires onto the pins and hooked it up to my AVR Dragon programmer. ISP was a no go so I soldered more wire to the remaining connection and gave high voltage programming a shot. That was also a failure. But since I already hosed that inductor I have no issue popping the microprocessor off of the board. Here it is soldered onto some perfboard and inserted in a breadboard:

I tried ISP again and that was a no-go. But this time around High Voltage Serial Programming worked. I talked to the chip with AVRdude using this command:

avrdude -P usb -p t13 -c dragon_hvsp -v

That polls the chip and reads back the fuse settings. Currently the lfuse is 0x6A which is the factory default but the hfuse is 0xFA. After checking the datasheet I see that they’ve disabled the reset function (that’s why ISP doesn’t work) and enabled brownout detection. I dumped the firmware and the eeprom and that’s where I’m at. Now I need your help.

I haven’t done much reverse engineering before this so I’m not sure what to do next. I disassembled the firmware using ‘ndisasm’ but I have no idea what I can learn from it, or even how to read it. I’d love some help answering two questions:

1) Why couldn’t I talk to the chip when it was on the circuit board?

2) What can I learn from the disassembled code. Update: after running the code through an AVR disassembler it looks like this is just an ascending list of numbers. [Tiago] pointed out in the comments that this is the behavior when the lock bits have been set. It should be possible to reuse the chip by erasing it but I won’t be able to dump the firmware first. Now I’ll focus on figuring out how the board is routed.

Let me know in the comments.

We love hacks that take quality products and make them better. This enhanced firmware for the VCI-100 is a great example of that. In a similar fashion as the Behringer hack, [DaveX] reverse engineer the firmware for the device and figured out a few ways to make it better. It improves the scratch controller and slider accuracy to use 9-bit accuracy from the ADC readings, which in the stock version were being shifted down to 7-bits. There’s also a few LED tricks they call Disco Mode. They’re selling a “chip” that you need to flash the firmware but from what we can see it’s simply an RS232 converter so you might be able to figure out how to work without that part. We’ve embedded a demo of firmware version 1.4 after the break.

[Thanks Steve]

[James] is interested in reverse engineering some integrated circuits. One of the biggest hurdles in this process has always been just getting to the guts of the chip. He used acetone to dissolve the plastic case but had trouble getting through the epoxy blob. Commonly, the epoxy is soaked in nitric acid for a few minutes but [James] didn’t have access to that chemical. Instead he popped into the local music store and picked up some rosin (used to make violin bows sticky enough to grab the strings of the instrument). After boiling down the rock-hard rosin and the chip for 20 minutes, he got a clean and relatively undamaged semiconductor that he can easily peer into.

When [Jespersaur] purchased a Luxeed LED keyboard, he was disappointed to find that the drivers were not open source and didn’t support all the features he wanted. His solution? Hack the drivers that come with it, and implement his own. In his article, he gives a basic rundown of beginning reverse engineering by multiple methods and a brief introduction to libusb. For the Linux drivers, check out [Kurt Stephens]‘s site, where he supplies a link to the source code, instructions on building it, and a tutorial on sending commands to the keyboard.

Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.

[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.