• Reset terminal (RES) set to low level. • Set to assigned level to INT0/1 terminals. • Set to assigned level to Port 0/3. (17) Factory shipment - Chip QIC160 package shipping available for sample evaluation. (18) Development support tools - Evaluation (EVA) chip: LC868099 - Emulator: EVA86000 + ECB868000 (Evaluation chip board).

$ 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. 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. I have no logical explanation as to why I came to this decision. Dracula 2000 free. 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. Send 0x0214 to 0x71 2.??? Send 0x0517 to 0x70 4.

Profit And we've made the educated guess that Step 2 is really 'Send 0x???? To 0x71' so we're pretty much done with the disassembly as 16 bits is way within the realm of bruteforceability and since I had another sacrificial board as well as a battery pack running SANYO firmware I had everything I needed to attempt it. As it turns out there's another mandatory step between 1 and 2 and it was sheer luck that I left it in my brute force loop. 0x73, the command unlocked by sending the first password needs to be read before entering the second password. Which is.*drumroll* 0xFDC3 After realizing that the first unlocked command is important (why else would they have made it mandatory otherwise) it's not that surprising that when adding the number returned by it (0x023d) to the bruteforced value we get a nice round result: 0x10000 which is probably what the adding in the assembly and the mystery numbers are all about.