$ smbusb_comm -a 16 -c 71 -w 0x0214 $ smbusb_scan -w 0x16 -b 0x70 ------------------------------------ smbusb_scan ------------------------------------ SMBusb Firmware Version: 1.0.0 Scanning for command writability. Scan range: 70 - ff Skipping: None ------------------------------------ [71] ACK, Byte writable, Word writable [72] ACK [73] ACK So this actually unlocks an extra command which disappears again when an SBS command is issued (or when doing a full command scan starting from 0.) The command however is not writable. Reading it returns. Ok, nothing straightforward. No obvious BOOT pin as one would expect with a device that's not meant to be tampered with. Biznes plan xls. But maybe pulling some pin high or low during reset will get me somewhere.

After the first pass no, not really. So maybe we have to set multiple pins into multiple states for it to work. Or maybe there's no such combination at all. How about I try to abuse N/C pins instead.

Currency conversions are estimated. Lithium Battery Catalog Datasheet MFG & Type PDF Document Tags ML614SAbstract: BR1632A Co., Ltd., Panasonic Sales Companies and Panasonic Agencies. Lithium Battery Tab Configuration, used for different destinations. Inquire separately for details. Bq8030dbt bq8030 reset bq8030 interface bq8030 datasheet.

20 20 design dongle crack for for profit. I have no logical explanation as to why I came to this decision. Maybe I saw a presentation somewhere about blackbox chips and N/C pins years and years and years ago but I could just be imagining things. Either way, about 5 minutes of poking at PIN #28 with a resistor connected to 3.3v in hand and triggering RESET at random intervals while running a continuous command scan. $ 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 [1] ACK [2] ACK [3] ACK [4] ACK, Byte writable, Word writable, Block writable [5] ACK, Byte writable, Word writable, Block writable [6] ACK, Byte writable, Word writable [7] ACK, Byte writable, Word writable [8] ACK [9] ACK, Byte writable, Word writable [a] ACK, Byte writable, Word writable Wow, that worked? Let's just reset for now. $ smbusb_sbsreport SMBusb Firmware Version: 1.0.1 ------------------------------------------------- Manufacturer Name: ERROR Device Name: ERROR Device Chemistry: ERROR Serial Number: Manufacture Date: 1980.00.00 Uh-oh. Well that's not good! It seems we're stuck in the Boot ROM.

Is the chip fried? It's at this point that I coded up the flash tool to try and read the flash contents. (I wasn't really bothered by the chip dying as this was one of 2 sacrificial controller boards I kept just for messing around with.) And the results? Apparently we can corrupt (ideally just) the first couple of blocks of flash if we bully PIN #28 while the chip is trying to start up. The good news though?

(If we're lucky) We get 99% of the firmware, and thanks to we have a (zip) for it. Did messing with Pin #28 even have an effect? Could it just have been the erratic resetting of the chip that triggered the malfunction? Did I short VCELL+ to Pin28 while messing about? Was there high voltage on VCELL+? Was it just ESD?

But I did manage to reproduce the result on another chip using the same procedure. So when in doubt and you have nothing to lose, act like a caveman, I guess? The only good thing about this method is that even if you have 0 knowledge about whether there even IS a method for entering the Boot ROM in the firmware let alone what it is there's still a high chance that you'll get in. How much of the firmware survives is another question. Disassembly A couple of hours of staring at unfamiliar assembly code later, here are the relevant parts for entering the Boot ROM with annotations. Cmd_handle_70: *snip* move r3, access_level and r3, # 0x40 cmp r3, # 0; don't even bother if access jeq cmd_handle_71; flag 0x40 is missing *snip* calls smbSlaveRecvWord move r2, (i3, 0x19); smb_word_LSB move r3, (i3, 0x18); smb_word_MSB cmp r3, # 5 jne wrong_pass cmp r2, # 0x17; is 70 0517? Jne wrong_pass *snip* (prepare leaving the firmware safely) calls bootrom_execute So now we know pretty much what we need to do.