Help me reverse engineer an LED light bulb

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.

1. Was the programmer soldered directly to the pins? Maybe there’s a regulator of some sort dropping the HV signal. O’Scope it.

2. Looks like a lot of “add” in the code and not much control logic. I suppose it’s just running a simple loop cycling through colors though. Maybe the adds are an obfuscated way to go about setting up all the I/O registers, etc. Not sure. Wish the disassembler would’ve filled in register names like some others do…

The converter’s trying to draw too much current, more than your ISP can provide, which is why you couldn’t talk to it in circuit. We see the same problem in the adafruit Ice Tube Clock kit when you attempt to program the ATMega ISP with the tube plugged it. Cut the leads (Vin0 to the buck converter and you might be able to program it in circuit. But since you’ve pulled it it hardly matters at this point.

Oh, and there’s not much toxic substances in an LED, Angelo. It’s not a CFL.

The disassembled code doesn’t look correct. It’s just 0x00-0xFF twice, interpreted as assembly. I know some AVR devices can protect their code space from being read for security, is the Tiny13 one of those devices?

I would say you could not talk to the AVR in circuit because the pins are obviously connected to other components on the PCB. That introduces loads to the pins of the AVR and the programmer, so the signal gets altered, distorted, weakened..

I’d have to question the value in reverse engineering the code – you’ve got a set of clearly defined inputs and outputs, and it’s easy to infer what is going on in the uP. It’s normally only really necessary to reverse engineer more complex system.

Perhaps later I’ll take a look at the code. But right off I’m thinking “danger, 110V!”. Then it strikes me. These things are $2 each! Buy two. Make one into the power supply then the other into the development / hacking platform.

If I had to guess w/o looking I would say the software is probably an exercise in pulse width modulation. Such that you can slowly change the colors of the LEDs.

You pictures are very good. I can see each LED has 6 legs. And there appears to be 3 LEDs (dark spots) in each LED case. If you can trace these back to the micro (probably through a transistor like device) that should help others backwards engineer the code.

I can think of some great fun with these. I remember internet connected devices which changed color based on scraping the weather or stock market reports.

What would help is a quick check and sketch of the LEDs leads, how they are powered and from which pin of the micro. That way we could look at the code with an eye of understanding. If the

Yup, definitely unsafe. I hear they also contain roentgenium and Darmstadtium, which is probably why they don’t last very long. Oh, and the case is made from asbestos. Better look out for the velociraptors hiding in the box, as well!

You can’t talk to the chip while it was on the board because HV programming isn’t designed to work in-circuit. ISP doesn’t automatically work in circuit either unless the board is properly designed for it. They probably had the attinys pre-programmed before they assembled the boards as is usual in production at this scale.

Can you tell if the reset pin is connected to anything on the board? They may have disabled reset as a rudimentary protection measure or more likely they may have needed to repurpose the pin for another purpose.

The AC->DC converter on the lower part of the board outputs 12V. Undoubtedly the LEDs are driven at 12V by the transistors/FETs on the underside. There is some possibility that the ATtiny is both controlling the LEDs and playing a part in the power supply. Before having a look at the code it would be useful to know something about where the IO pins of the ATTiny are routed.

It probably wouldn’t even be worth trying to wade though the disassembly if the mcu is simply controlling the LEDs. Theres plenty of code out there for that — it would be easier to simply write your own implementation. If it’s playing a part in the power supply though, things are going to be far more complicated.

I have 2 questions.
1. Why do you try to disassemble ATTiny assemble code with x86 disassembler?
2. Why do you try to disassemble 00 01 02 03 which does not look like processor instructions? Processor instructions are likely to be more “irregular”.

I would find where they start, find proper disassembler, and try again.

I don’t have an answer to your first question and an partial answer to the second one.

You can learn a lot form the code in the microcontroller. It can teach you how the device works. Unfortunately, the disassembled code you posted is useless. You used nsisasm, which is a 80×86 disassembler and therefore incapable of understanding avr binary files. Try using an avr disassembler like vAVRdisasm. You’ll see that
the produced code will make more sense.

Once you understand how the code works, you can modify it to suit your needs. You can for example make it to display different color sequences or blinking patters. Those are just some ideas.

If the protectio bits are enable everything that you will read is the flash address and not the flash contents, as said, learn how to use avr-objdump, because its pretty obvious that your disassembly is from a x86 core, those have AX,BX,CX,DX,SI,and others registers, AVR’s have r0,r1,r2, up to r31 and then they have the X,Y and Z for the pointers.

If you disable the reset, you cannot use ISP. The device looks like it is protected against reading the code(which is how most micros are in commercial aplications in order to protect duplication). Still, it should be easy to reproduce. Also, get a new bulb and hook up a scope on each of the pins.
Hv programming is not suited for in board and it might even damage other parts of the circuit.
I wish i could find such cheap bulbs… now attiny13 costs more than $2 for one piece.

Only $1.99? And I got my IR controlled one for like $30. Feel like a sap now. Ah well. Looking forward to the development of this project, maybe then I can add IR to a bunch of these and have a whole bunch running off of one remote.

i rember back in the dishnet hackign days on some 301 irds having to cut a trace that was holdign the reset pin of the tsop low to be able to gain read/write access.. i would be intrested to see what the pins on the atiny are tied to.

Tiago mentioned that the lock bits might be just feeding the register addresses when read. I think he’s right because I tried disassembly with vAVRdisasm and I get sequential numbers. The debugWire is not enabled so it looks like there’s no way to dump the code.

I’ll need to try and figure out how the board is wired up. I’ve done some continuity testing but no success if tracing from uC pins to transistors, or figuring out how the LEDs are connected. Bit of strangeness going on that I’ll have to look into more this weekend.

If you want I can give you working code for the arduino IDE that uses an HSL colour wheel and then translates the Hue value to RGB and output that as pwm for an RGB led, but its very very easy to do, and there are many examples out there.
Fell free to ask.

Hey Angelo, no worries – I glanced at original post and thought exactly the same as you till I saw the pix of the *plastic* bulb – yep, DUH :)

—

Just looking at looking at CFL circuits for first time- interesting, but a bit Hairy-Scary / incomprehensible for me – (soon as it gets into Coils/Inductors am a bit lost…)

—

Any interesting hacks with CFLs/’CFL bases’ (i.e. sans bulb) out there? I keep getting packs of them sent to me for free from my electricity supplier, but I don’t like the light they give out so they just sit in my cupboard.

when i originally read the cfl+flyback thing, i thought it said you could make like really long ‘lightning bolts” like a few feet long.. i love it when a cfl burns out. burnt out incandescents are practically useless, but a dead cfl brings something to the table

Looks like a fairly strait forward circuit to me. The LinkSwitch LNK304 universal off-line switch mode controller is a class of devices found a lot in the smaller wall adapters for cell phones and the like. That particular chip can only output about 170mA of total current due to the limitations of the internal switching FET. It probably just provides the board with regulated 5V, based on the requirements of the ATtiny and the fact that I don’t see another voltage regulator. Although it might be possible that D4 is a zener and is being used as a rudimentary regulator for the AVR.

Throw in a few FETs as low side switches to PWM dim the RGB channels of LEDs and you have yourself a mood light!