Saturday, January 28, 2017

[Random Teardowns] YU4802 48V/2A power supply

Device: Cheap 48V 2A power supply (YU4802)
Origin: Aliexpress
Reason for teardown: Preemptive checkup
Impressions: Not bad for the price ($14 shipped)

Blue Power LED on top

⚡ RISK OF ELECTRIC
DO NOT OPEN !
Yeah, but if I don't it's still a risk due to being a 96W  $14 power supply from china so.... bring on the risk of electric.


Noname primary-side cap, mismatched screws on the TO-220s but the design doesn't seem to be too terrible at least
Based on UC3842 (datasheet)










3 noname secondary side caps, par for the course

I've seen way worse for the same amount of money.
UPDATE:
So after actually using this with a significant load (charging a 50cell 10S5P LiIon battery) I can say that it's really not a very efficient power supply and that it should probably never have been designed into this enclosure. A hundred vent holes and a fan later I'm now reasonably sure it won't burn down.

This is a very similar circuit to what they sell as SLA battery chargers for electric bicycles in cases 4 times this size with vent slots all around. Even so they get stupidly hot and just cook the transformer if the vents are covered up as a friend of mine found out. Primary side shorts straight through leaving nothing intact.
So if you buy this and want to use it anywhere near it's rating then break it apart, get your drill out and turn the case into swiss cheese at the very least but I'd recommend active cooling as well in addition.


Monday, September 5, 2016

The weird fuses in laptop batteries

I called them "externally triggerable fuse" in my first post. The datasheets call them "Combined Thermal Fuse/Resistor" or "Fuse-Resistance protector".
Chances are your first time seeing one of these will be in a smart battery, it sure was for me.

As an over-current protection device (ie. regular fuse) they're probably only going to trigger during catastrophic short-circuit scenarios. Their main purpose is to provide a way for the microcontroller to physically break the circuit if it detects a potentially dangerous condition like the overheating of the cells and can't stop it by shutting the FETs off. The problem is some firmwares will count the sudden disappearance/reappearance of cell voltages amongst the list of conditions that warrant doing this so if you want to re-cell a pack you might end up with a blown fuse.
Replacing or jumping them is a pain so it's a good idea to connect the Reset pin of the controller to ground before doing anything of the sort to keep it from overreacting.


The rectangular one




The Cyntec 12AH3 / 12AG3 (datasheet) or similar devices will seem like large capacitors on first sight, though the fact that they have 4 terminals might make you think "current sense resistor". Nope!

The black plastic cap attaches to the ceramic body with glue and you can tease it off with a pair or side-cutters, pliers or tweezers. Here's what you see under it:





Left: intact, Right: blown

What you have is a rectangle of "solder" (probably some special alloy) with a resistor/heating element under it in this configuration:


As you can see on the images above, when the device is triggered the thin layer of solder heats up, flows onto the center pad and breaks the connection. The heater is about a 10 ohm resistance so with a 12.6v battery voltage that's 14 watts dissipated on that tiny surface area (or more if the charger voltage is used)

To check this fuse you'd look for continuity on longer sides and for the heater resistance between either contact and Pin 4.
To jump it carefully dab older onto the broken connections. Use low temperature and thin solder. You can probably shave away at it afterwards and the fuse MAY be able to blow again.. unreliably.. and completely of spec.
The best course of action is of course to replace it with a new one once the repair is confirmed.

If the controller is blowing the fuse repeatedly you have an issue in your data or a hardware fault in the controller board or your cell connections.

The 3-legged one






The SEFUSE D6X / D6T (datasheet) is a weird looking thing that doesn't really resemble any other component.

It's the same deal with a different physical construction.





To jump it you break off the cap (if there is one) to find a resin coated square. Then you carefully scrape away at the coating roughly in the middle until you find a tiny via. This is the center point you see in the diagram above. Now you just need to reconnect it to the two leads where the fusible material broke the connection so tin the via and connect it to both leads (ignore the lead for the heater).

Here's a pretty terrible example:




As with the previous one, it's best to get a new one once the repair is confirmed.

Tuesday, August 30, 2016

Adding the M37512 with Panasonic/IBM firmware

Just "adding" because this battery controller is already public. You have the datasheet(pdf) which tells you the pin combination to enter the Boot ROM and most of the command set (how was the actual read command missed? weird). Then there are open-source flasher tools like this one. You can also use Google to find the passwords because you WILL need passwords (at least with this firmware) and that is after you set the correct pins to the correct states to enter the boot rom. Overkill? Yeah, overkill.

But since it's all out there it's just a matter of coding up a tool for SMBusb.




Quote:
 "Normal microcomputer mode is entered when the microcomputer is reset with pulling CNVSS pin low. In this case, the CPU starts operating using the control program in the User ROM area. When the microcomputer is reset by pulling the P24/SDA2/RXD pin high, the CNVss pin high, the CPU starts operating using the control program in the Boot ROM area"

After setting the pins to desired state and resetting the chip you get:

$ smbusb_scan -w 0x16
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - ff
Skipping: None
------------------------------------
[0] ACK, Byte writable, Word writable, Block writable, >Block writable
[1] ACK, Byte writable, Word writable, Block writable, >Block writable
[2] ACK, Byte writable, Word writable, Block writable, >Block writable
[3] ACK, Byte writable, Word writable, Block writable, >Block writable
[4] ACK, Byte writable, Word writable, Block writable, >Block writable
[5] ACK, Byte writable, Word writable, Block writable, >Block writable
[6] ACK, Byte writable, Word writable, Block writable, >Block writable
*repeat for all commands*


Going at this blind would've been pretty terrible. This chip is waiting for the correct passwords and ACKing literally everything until it gets them.
Entering the correct passwords scoured from the internet:


$ smbusb_comm -a 0x16 -c 0xFF -w CDAB -b
$ smbusb_comm -a 0x16 -c 0xCF -w 3412 -b
$ smbusb_scan -w 0x16 -e 10
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - 10
Skipping: None
------------------------------------
[0] ACK, Byte writable, Word writable, Block writable, >Block writable
[1] ACK
[2] ACK
[3] ACK
[4] ACK
[5] ACK
*snip*


It still ACKs every command but it's exposing the documented Boot ROM inteface now. Just don't scan it too much because writing the wrong thing to the wrong command will hang the controller and/or the entire bus which the SMBusb won't like too much either. (The Boot ROM in this chip has zero error handling.)

Some coding later:


$ smbusb_m37512flasher -w b0 -p b0
------------------------------------
        smbusb_m37512flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Erasing flash block starting at 0xe000 ...
Done!
Writing memory 0xe000-0xffff ...
Done!
Verifying 0xe000-0xffff ...
Verified OK!

The tool is now a part of SMBusb.

I haven't done research into modification or resetting for this controller yet. Maybe in the future!

Monday, August 29, 2016

Hacking the R2J240 with LGC firmware


The second battery controller I looked at was the Renesas R2J240-10F020. It's a complete black box with very little information available except for some outtakes from the datasheet on Chinese developer forums. There is very little resemblance to the M37512, an older Mitsubishi/Renesas microcontroller used in earlier battery packs that's fairly well documented.


The first thing you notice is that this chip has the analog frontend integrated (unlike the M37512 or the bq8030) because there's no separate chip for measuring voltages and such. Cells are connected directly to this chip so it's a one-chip solution for building smart batteries.

SBS Report

$ smbusb_sbsreport
SMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name:          LGC
Device Name:                LNV-42T4911
Device Chemistry:           LION
Serial Number:              41291
Manufacture Date:           2010.01.25

Manufacturer Access:        6001
Battery Mode:               e000
*snip*


Probing around



I started out by measuring voltages on all the pins. Just going by logic I was expecting some sort of differentiation on the various sides of the chip.

To summarize my findings after the first pass:
  • 1-12 is the "main microcontroller side" has the SMBus pins, VCC (and probably RESET and others)
  • 25-36  is connected to current sensing and exposes various built-in voltage regulators
  • 37-48  appears to be mainly unused with a couple of pins at 3.3v, GPIO side?
  • 13-24  has many pins connected directly to "high voltage" from the cells.
I took a 1k resistor connected to ground and started poking the pins with it to find reset. It should be possible to pull reset low through 1k resistor but unlikely on VCC and it shouldn't lead to a complete reset on an unrelated pin. It's also possible to rule out most pins through visual inspection and measurement. So long story short: Pin #12 is Reset.

Next I wanted to see if there's something like a Boot pin that's going to get me a different mode when pulled either low or high during reset so I started up a continuous command scan and started poking at the pins again.

Pulling Pin #4 (also connected to Test Point 1 on the other side of the PCB) low during reset gave me this:

$ smbusb_scan -w 0x16
------------------------------------
             smbusb_scan
------------------------------------
SMBusb Firmware Version: 1.0.1
Scanning for command writability..
Scan range: 00 - ff
Skipping: None
------------------------------------
*snip*
[f0] ACK, Byte writable
[f1] ACK
[f2] ACK
[f3] ACK
[f4] ACK
[f5] ACK
[f6] ACK
[f7] ACK
[f8] ACK
[f9] ACK
[fa] ACK, Byte writable, Word writable, Block writable
[fb] ACK, Byte writable, Word writable, Block writable
[fc] ACK, Byte writable, Word writable, Block writable, >Block writable
[fd] ACK, Byte writable, Word writable, Block writable, >Block writable
[fe] ACK
[ff] ACK

The chip was ACKing on every command. A deliberate attempt at confusing any would-be attacker perhaps? The write scan however reveals that the chip is actually exposing some real functionality on some of the commands and that a couple of them violate SMBus protocol.

Pin #4 appears to be BOOT (active-low).



Mapping

Mapping out the protocol took a while especially because it doesn't correspond to standard SMBus protocol but I was eventually able to figure out how to read and write to RAM and erase blocks of memory-mapped flash.
Just writing to the appropriate address in ram (after the flash blocks have been erased) writes the flash memory which is convenient.

There are several partitions of flash mapped into RAM and I'm sure I haven't found all of them. The ones I did are included as address&length presets in the flasher tool.



$ smbusb_r2j240flasher -d eep2.bin -p df2
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Dumping memory 0x3400-0x37ff ...
Done!
$ xxd eep2.bin
0000000: 0000 0000 0000 0000 0000 ffff ffff ffff  ................
0000010: 4c4e 562d 3432 5434 3739 3700 0000 0000  LNV-42T4797.....
*snip*

$ smbusb_r2j240flasher -d eep3.bin -p df3
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Dumping memory 0xc000-0xdfff ...
Done!
$ xxd eep3.bin
0000000: 0100 0700 b801 b801 1100 0203 0201 01e3  ................
0000010: e6fe e3ae 7000 e0e4 0cc8 0038 3150 14f0  ....p......81P..
0000020: 1530 2a4c 4743 0031 3100 0000 0000 0000  .0*LGC.11.......
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 004c 4e56 2d34 3254 3439 3131 0000  ...LNV-42T4911..
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 004c 494f 4e01 2d01 2d30 07fa 1031  ...LION
*snip*


In this particular battery pack the static information was stored in df3 and the dynamic in df2, df1 was empty.
Another battery stored dynamic info in df1 so this is going to differ between firmwares/packs.

Just like the bq8030 the static area is protected by a checksum on this controller/firmware as well. I took a shot at it just for kicks and it was pretty simple so I included it in the flasher tool.


$ smbusb_r2j240flasher -w eep3_f.bin -p df3 --fix-lgc-static-checksum --execute
------------------------------------
        smbusb_r2j240flasher
------------------------------------
SMBusb Firmware Version: 1.0.1
------------------------------------
Erasing flash block starting at 0xc000 ...
Done!
Fixing LGC static checksum..
Done!
Writing memory 0xc000-0xdfff ...
Done!
Verifying 0xc000-0xdfff ...
Verified OK!
Exiting Boot ROM and starting firmware.

$ smbusb_sbsreport
SMBusb Firmware Version: 1.0.1
-------------------------------------------------
Manufacturer Name:          LGC
Device Name:                Karosium000
Device Chemistry:           LION
Serial Number:              41291
Manufacture Date:           2010.01.25
*snip*


Reset

Pretty much the same procedure as with the bq8030. Map and modify the dynamic area. Eventually you'll find the error flag. As with the bq8030 the dynamic area isn't checksummed in this controller/firmware either.

Helpful tips:
  • Again, multiple log entries. The number of 0x00 bytes at the beginning of the section determine the number. Patch the duplicated data in all of them.
  • You can decrease the number of log entries to 1 for the time of mapping which will make the job a lot easier.
  • The real cycle count is stored encoded. No idea how. With this particular firmware it was at 0x78-79. Zeroing out the bytes still decreases the cycle count to 5 but the precise algorithm/obfuscation? No clue.
  • Please don't ask me to fix flash dumps :-)
  • Good luck!
Notes

No disassembly/ler for this chip. I don't really know what architecture it's based on. If I had to guess I'd say an extended version of the MELPS 7700, an old Mitsubishi architecture that Renesas inherited because trying to load it up in IDA with that core seems to produce something that starts to make sense but fails on invalid instructions. I could be completely wrong though.

If anyone wants to tackle this they could probably find a nice, easy way of getting into the Boot ROM using just SMBus commands.