-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: dumping code options #4
Comments
They should be located in custom block, shouldn't be problem to read them. I'll add it to the tool. |
Done. |
Seems like it doesn't cover CHIP_TYPE 7. Are you looking up these addresses from a sinowealth programmer? |
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. |
Alright, running it (on a
Any hints about the layout of these options? For example, where do the 8 programable bytes referenced in |
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). |
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.
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? |
In my case of protected SH68F90 chip, the region is filled with this:
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. 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. |
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. |
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.
|
@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. |
@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. |
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 |
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. |
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. |
How do you know? For most MCUs they manufacture there is absolutely no info even on their own web site. |
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 |
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. |
@gashtaan here's the dump of the info area with your updated code:
The code option line seems to be broken up between 8 bytes at 0x006 and 0x100. Concatenated together it becomes:
I've broke out the individual options using info from the .gpt file:
EDIT: I made a wrong guess about where the code options were located in the original comment. Things seem correct now. |
I just have reversed it and going to let you know, but it was complete waste of the time as you already know :) |
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.
The text was updated successfully, but these errors were encountered: