Request: dumping code options

[carlossless]

Hey, thanks for all the effort in building this!

Have you looked into dumping the existing code option values? Any idea which address they are available on? Perhaps it would be a worthwhile addition to this tool.

[gashtaan]

They should be located in custom block, shouldn't be problem to read them. I'll add it to the tool.

[gashtaan]

Done.

[carlossless]

Seems like it doesn't cover CHIP_TYPE 7. Are you looking up these addresses from a sinowealth programmer?

[gashtaan]

Ups, you're right. I looked it up in firmwares that doesn't support chip type 7. However, I tested it on chip type 7 with chip type 2 set in config. You can do the same. There are no relevant differences between types 2 and 7 if there is no more than 64kB of flash memory on the chip.

[carlossless]

Alright, running it (on a SH68F90A) produced:

Dumping code options:
00000000EF13A4E063C0300330033003
30000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

Any hints about the layout of these options? For example, where do the 8 programable bytes referenced in SH68f90A.gpt begin?

[gashtaan]

That's weird, doesn't seem that 8 bytes fit anywhere. Maybe all of it is set to default, i.e. set to zeroes? Honestly, I don't have a clue yet, just know that this block is programmed when drivers are writing "Code Option".

BTW, are you sure you have dumped entire firmware? It seems that some sectors are protected by having security bit set (those 3 digits from offset 0x0A).

[carlossless]

Maybe all of it is set to default, i.e. set to zeroes?

I can't tell for sure, though I doubt it since the default values suggested in the gpt files are completely different. This device interfaces with another 3v3 wireless IC, so I would expect that at least OP_IOVx would be set to 1, although I haven't confirmed how the two are exactly connected yet.

BTW, are you sure you have dumped the entire firmware? It seems that some sectors are protected by having a security bit set (those 3 digits from offset 0x0A).

No, I'm not.

Before looking into this I had assumed that protection would be applied to the whole of flash, but if it can be specific to certain sectors then I can't be sure.

Still, if that option is set only for the first sector, the disassembly for it didn't look mangled and there was a jump instruction to some init code in a different region.

What does reading protected regions output for you?

[gashtaan]

In my case of protected SH68F90 chip, the region is filled with this:

ED130000FA59A4C063C0333333333333
33330000000000000000030000000000
00000000000000000000000000000000
000000000000000000000000ED130000

I'm not sure how large is the sector that every nibble of these security data represents. It is definitely not a SectorSize (defined in GPT file) granularity, it wouldn't fit into 64 bytes along with other data. BTW, there is also feature that they call "Ultra Security for Program Memory" and describe as "The real code write to the program memory is disordered", but I'm not sure if it applies to SH68F90 chips.

To be clear, for now, most of this is just my assumptions, maybe those security features (or options in general) works in a completely different way.

[gashtaan]

Sorry to misinform you, I just looked to more recent SinoLink programmer driver and it turns out that for chip type 7 code options block is 512 bytes long, not only 64. I already updated the dumper accordingly.

[gashtaan]

It seems that my assumptions about how security bits works are correct. If you read that nibbles from 0x0A offset, it perfectly matches the data you have dumped - where bits are set (3 = 0b0011), there are gaps in dump - every nibble specifies protection per 4kB sector. Unfortunately, it means that your dump is not complete.

00000FE9  mov     A, R5
00000FEA  xrl     A, #1
00000FEC  jnz     code_102D           ; <--- jump to the missing code
00000FEE  mov     DPTR, #0xC02
00000FF1  mov     A, #0x5B ; '['
00000FF3  movx    @DPTR, A
00000FF4  inc     DPTR
00000FF5  mov     A, #0xA8
00000FF7  movx    @DPTR, A
00000FF8  mov     DPTR, #0xBF7
00000FFB  clr     A
00000FFC  movx    @DPTR, A
00000FFD  inc     DPTR
00000FFE  mov     A, #0xE3
00001000  nop                         ; <--- here start the protected sector
00001001  nop
00001002  nop
00001003  nop
00001004  nop

[carlossless]

@gashtaan alright I see! Thanks for looking into and explaining this. I will dump the full code options of my chip later this week, but I believe this issue could be closed now.

[gashtaan]

@carlossless meanwhile, I figured out the method to dump flash even from protected sectors, but now I'm deciding if I want to release it to the public here.

[swiftgeek]

If fixing it would require changing protocol, then it's probably a better idea to not force vendor to change the protocol, since they don't want describe it publicly to full extent - which would require yet another reversing effort in the future to get R/W/E even on unprotected parts.

Though if JTAG/ICP protocol ever changes dramatically in the future, maybe that would be a good time to release it

[gashtaan]

That and it's also an ethical matter for me.

I bet if they were forced to change the protocol then there would be nothing free to download and reverse anymore.

[swiftgeek]

From ethics angle, I guess it might be important to consider application of those MCUs: they are usually used in home appliances and simple peripherals, nothing that would appear to be used in security applications or medical devices.

[gashtaan]

How do you know? For most MCUs they manufacture there is absolutely no info even on their own web site.

[swiftgeek]

Marketing/datasheet materials looked better 10 years ago I guess :D

And people report missing programming tools for reading/writing/erasing those chips from time to time, and what kind device they found it in, like a massage chair here

[gashtaan]

I don't have luck for these MCUs in home appliances, this is the first time I have encountered them. But maybe some of those with part ID missing, misleading or scratched off are one of SinoWealth MCUs, I've seen a lot of such.

[carlossless]

@gashtaan here's the dump of the info area with your updated code:

Dumping part number:
68F90A0000

Dumping code options:
00000000EF13A4E063C0300330033003
30000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
772E2305220520151614054002300100
0F000088000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

The code option line seems to be broken up between 8 bytes at 0x006 and 0x100. Concatenated together it becomes:

A4E063C00F000088 // 0x8800000FC063E0A4

I've broke out the individual options using info from the .gpt file:

A4
OP_OSCDRIVE 2 - 4MHz crystal or 8~12MHz crystal with external capacitance(C1=C2)<20pF
OP_RST 1 - P0.2 used as IO pin
OP_WMT 0 - longest warm up time
OP_SCMEN 1 - Disable SCM
OP_OSCRFB 0 - 150K

E0
OP_LVREN 1 - Enable LVR function
OP_LVRLEVEL 3 - 2.1V LVR level4
OP_SCM 0 - SCM is invalid in warm up period
OP_OSC2SEL 0 - OSC2 select 12M RC
OP_IOV1 0 - P7.1/P7.2/P7.3/P7.4 input/output level is VUSB(5V)
OP_IOV0 0 - P5.5/P5.6 input/output level is VUSB(5V)

63
OP_SCMSEL 3 - 8MHz
OP_OSC 3 - Oscillator1 is internal 128KHz RC, oscillator2 is internal 24MHz RC

C0
OP_ISP 1 - Disable ISP function
OP_ISPPIN 1 - Enter ISP mode only when P6.3 and P6.4 are connected to GND, simultaneously
OP_WDT 0 - Enable WDT function
OP_WDTPD 0 - Disable WDT function in Power-Down mode

0F
OP_SINK1 3 - Port6[5:0] sink ability largest mode(380mA)
OP_SINK0 3 - P4.7/Port7[7:5] sink ability largest mode(50mA)

00
OP_BOPTP 0 - (1+21%)tr min
OP_BOPTN 0 - (1+21%)tf min

00
Unused

88
OP_ISPSIZE 8 - 0Bytes
OP_EEPROMSIZE 8 - 0Bytes

EDIT: I made a wrong guess about where the code options were located in the original comment. Things seem correct now.

[gashtaan]

I just have reversed it and going to let you know, but it was complete waste of the time as you already know :)