Read flash

[AlexDaniel]

Hi! It seems like currently there is no way to read flash from the device (this feature is not available even in their own tool).

However, I really need this feature for one of the projects I'm working on.

Perhaps there is a way to implement it? E.g. maybe the verify sequence can be abused to get the data?

[grigorig]

It looks like it is considered a feature by STC that this isn't supported. If there is no (official) way to read back the memory in the bootloader, that's the best readout protection. Some Chinese developers are quite paranoid, apparently. :)

Why do you need this for your project? You can add code to read out the data yourself. It's not very convenient, but not hard to do either.

I'll still leave this open if I can manage to find out a way.

[AlexDaniel]

I am working on a free software project that is basically an alternative firmware for a broad range of robotic vacuum cleaners (it is on early stages, so I didn't publish much yet).

One of the problems is that I don't want people to be forced to say goodbye to their old firmware, so the software is built in such a way that it will pull the original firmware first. Later the user may decide to revert back to the original firmware.

That works fine on most robotic vacuum cleaners, but the one that I work on right now has a STC microcontroller.

Right now I don't even have other STC microcontrollers to play around with, so I can't try it myself. :-(

[zerog2k]

Actually, STC considers this bootloader "security", i.e. not being able to read the contents of flash/eeprom and only being able to write it, as a feature. As Grigori put it, the Chinese mcu manufacturers are inexplicably paranoid about stealing code, perhaps because much of the industry there is ironically based upon clone/knock-off/reverse engineering IP.

As for this project, I suspect only exploitation and abuse of some existing bootloader bug would be the only way to dump flash without some other true-reverse engineering of the chip.

[nekromant]

For now we don't even have a the dump of the BSL itself to reverse (And apparently no way to get one). I still have a feeling there is a readback capability there up to some point (or that last phase, when the host sw spits out a packet of data and prints "Encrypt OK" doesn't make any sense at all. I tested that one can safely omit that and everything would be fine). But without the BSL dump we're unlikely to ever find it.

[AlexDaniel]

I have found this in the datasheet:

That's from stc90c58rd english datasheet. It clearly says “read”, but what are they talking about exactly?

[zerog2k]

From my limited experience w/ STC, IAP (in-application programming) is basically reading/writing/erasing flash blocks (program code) from your running code. I dont think this is from bootloader. You would have to load some amount of your own code (which does the IAP routines)... In order to do this, you have to overwrite some of the existing code on the chip with your own. I'm not sure if it's possible to not erase the rest of the flash blocks when writing such that you can read back parts of the flash that your code did not occupy, and might have some left over code from previous programming.

[nekromant]

@zerog2k From what I remember the bootloader always does a full chip erase prior to programming and there's no way to make it start the write, say, at somewhere near the end of the device.

[grigorig]

Yes, IAP allows you to read and write flash memory from your own code. It's used for the "EEPROM" section of the flash memory. On devices that are called "IAP" instead of "STC" in their name, the whole flash memory can be accessed via IAP. However, like nekromant said, it looks like all of the flash memory is erased every time.

The bootloader unfortunately lives in a separate memory space (the upper 2 or 3 KB) that supposedly can't be accessed via IAP or regular read instructions. I haven't actually tried to read the bootloader code, though.

[zerog2k]

After reading this a while back, http://jjmz.free.fr/?p=191

From what I can recall, I was able to read the code sections of memory, not just EEPROM section. (I think they are really just a logical partition of a larger flash memory.) I dont recall if I was able to read any flash blocks from previous writes - I didnt test that. But from what I recall on the STC-ISP tool, I think there was an option whether or not to write 00/FF to unused blocks in flash or not during programming. I assume stcgal works in a similar way - I recall seeing that stcgal only attempts to program the flash blocks which have program code in them.

I was also trying to read past obvious boundaries with IAP, but not able to read anything beyond flash and eeprom sections. I was wondering if it might be possible to do some timing tricks on IAP registers to try to bypass whatever read protections they have and read bootloader sections.. There might be some exploit vector possible here...

@AlexDaniel perhaps you want to experiment and share your findings?

[grigorig]

From what I can recall, I was able to read the code sections of memory, not just EEPROM section. (I think they are really just a logical partition of a larger flash memory.)

Yes, you can read the whole memory (except for the bootloader), but you cannot write all of it on non-IAP devices.

But from what I recall on the STC-ISP tool, I think there was an option whether or not to write 00/FF to unused blocks in flash or not during programming.

Yes, there is such an option on some devices (IIRC STC12 series only). The erase command allows you to set the number of sectors that should be erased, but I haven't verified that it actually does anything useful. They may as well have dropped this feature on STC 15 series to get around this "loophole" which allows you to snoop some code. :)

I was wondering if it might be possible to do some timing tricks on IAP registers to try to bypass whatever read protections they have and read bootloader sections

Maybe disabling BOD and playing around with the voltage could be an interesting way. Chips tends to behave erratically in low-voltage situations and this can sometimes be used to advantage.

[zerog2k]

well, @jjmz discovered an interesting hack w.r.t. flash vs eeprom space on these chips. Seems that sdcc can produce code that resides in eeprom space, stcgal will upload it (stc-isp truncates this), bootloader will write, and code can be executed from eeprom. One could write a small program that lived at the end of eeprom, with only a small bit of startup code at start of flash to jump into eeprom, and dump out flash. I think stcgal might have to be modified not to erase other blocks of code section.

more details here: https://github.com/zerog2k/stc_diyclock/pull/6#discussion-diff-69225949