Reading firmware out of a mask ROM microcontroller

[cilione]

I'm trying to dump the flash of a M16C/65.
I've successfully read out everything except block A + B, these are being read as FFs.
I guess that block A + B has to be enabled?

m16c-flasher returns "VER.1.00"

I guess that the code provided for enabling A + B has to be adapted for this MCU?


M16C/65 Group
User’s Manual: Hardware
https://www.renesas.com/en/document/mah/m16c65-group-users-manual-hardware?r=1053261

[das]

I'm also stuck trying to dump a M16C/65 R5F365. I'm trying to dump it in-place which might be the problem. There's a 18-pin header on a side of the board which looks like it could be used to program the device in the factory. For complicated reasons the device cannot be powered normally and I have to rely on this header which seemingly has everything needed:
VCC: tried +3.3V and +5V
VSS: GND
RESET: toggled manually
RX, TX: to computer UART
CE (P5_0): high
CNVSS: high
CLK (P6_5): low
RTS (P6_4): to oscilloscope
HOLD (P5_5): low
P5_1: unused
P2_0: unused

I'm powering the MCU using a C.V. external PSU.

When powering, if RESET is held low nothing happens, no current draw. If RESET is held high 0.036A are drawn. When sending byte 0xB0 (baudrate negociation) I get no reply and the RTS line stays low. If powered is maintained and RESET is manually toggled the current drawn is now 0.008A which seems to indicate that the MCU might have entered bootloader mode? At this point sending 0xB0 yields no answer either BUT the RTS line goes high and stays high for a few millisecs. So it looks like something's happening on the MCU side? Has someone encountered this behaviour?

I could pull the MCU from the board and build a rudimentary circuit from a socket but I wanted to avoid that for now.

[das]

Well I pulled the MCU from its board and built a makeshift rats' nest using cables according to the datasheet. Same behaviour: still get no activity on RX with RTS/BUSY high when data is sent, indicating the MCU is doing something but not answering. So either I'm doing something really wrong, or this MCU is protected in some way nobody has seen before or it's fried 

Never mind it was an autobaud problem. Using tru's software fixed it!

[tru]

Perhaps the serial I/O mode is disabled.
In the M16C/65 user hardware manual, page 749, "30.9.3 Standard Serial I/O Mode Disable Function", I see that if the ID passcode is set to the string "Protect" then serial communication s ignored by the boot ROM. 

[tru]

Well I pulled the MCU from its board and built a makeshift rats' nest using cables according to the datasheet. Same behaviour: still get no activity on RX with RTS/BUSY high when data is sent, indicating the MCU is doing something but not answering. So either I'm doing something really wrong, or this MCU is protected in some way nobody has seen before or it's fried 

Never mind it was an autobaud problem. Using tru's software fixed it!

Ops, looks like I posted just after you, but good to know ID is not set to "Protect".

[das]

Yeah lucky for me that would have been a nightmare to diagnose on a first chip!

Sadly the ID code is not '00'*7 nor 'ff'*7. I tried measuring the time delta between the last bit of ID code and the BUSY release (as demonstrated during REcon 2018) and it's all over the place, not exploitable. Maybe it'd be more consistent with an externally provided clock. Otherwise I'll have to find another vuln to get in, probably with a voltage glitch.

[tru]

Sadly the ID code is not '00'*7 nor 'ff'*7. I tried measuring the time delta between the last bit of ID code and the BUSY release (as demonstrated during REcon 2018) and it's all over the place, not exploitable. Maybe it'd be more consistent with an externally provided clock. Otherwise I'll have to find another vuln to get in, probably with a voltage glitch.

I tried that also and got inconsistent results with serial mode 2 (Async UART mode).  But then I realised they are actually using serial mode 1 which should work the same as SPI (without the NSS signal).  I tried with STM32H753ZI dev board, man their SPI functions (HAL) just doesn't work with it.  Got a logic analyzer and saw that STM32 HAL is sending 7 bits of data when I have 8-bits selected!!  Perhaps I need to select 9-bits data, anyway, I got tired and given up for now.  Another thing is they've done that with a slow clock on their M16C so they cheated a bit.

[tru]

Forgot to add, you can only brute force 3 times then you need to power off/on to get another three tries.  I guess they most likely also added in at mosfet or BJT controlled power switch circuit which they didn't mention.

[das]

Forgot to add, you can only brute force 3 times then you need to power off/on to get another three tries.  I guess they most likely also added in at mosfet or BJT controlled power switch circuit which they didn't mention.

Hum interesting, I didn't see a behavioural change after 3 tries yet.

Sadly the ID code is not '00'*7 nor 'ff'*7. I tried measuring the time delta between the last bit of ID code and the BUSY release (as demonstrated during REcon 2018) and it's all over the place, not exploitable. Maybe it'd be more consistent with an externally provided clock. Otherwise I'll have to find another vuln to get in, probably with a voltage glitch.

I tried that also and got inconsistent results with serial mode 2 (Async UART mode).  But then I realised they are actually using serial mode 1 which should work the same as SPI (without the NSS signal).  I tried with STM32H753ZI dev board, man their SPI functions (HAL) just doesn't work with it.  Got a logic analyzer and saw that STM32 HAL is sending 7 bits of data when I have 8-bits selected!!  Perhaps I need to select 9-bits data, anyway, I got tired and given up for now.  Another thing is they've done that with a slow clock on their M16C so they cheated a bit.

Good to know I'm not the only one that cannot reproduce! I could try mode 1 then.

[gashtaan]

I tried measuring the time delta between the last bit of ID code and the BUSY release (as demonstrated during REcon 2018)

They already fixed this vulnerability in later bootloader versions, now it always take the same time, no matter if entered key is wrong or correct.

[das]

I tried measuring the time delta between the last bit of ID code and the BUSY release (as demonstrated during REcon 2018)

They already fixed this vulnerability in later bootloader versions, now it always take the same time, no matter if entered key is wrong or correct.

I've read that for bootloader V4 I think? Mine is 1.01.

[gashtaan]

I've read that for bootloader V4 I think? Mine is 1.01.

I wrote it. I've seen it in bootloader V4, but I never got my hands on prior versions to check. It'd make sense that they fixed it in V1.01 as soon as this vulnerability in V1.00 leaked.