bin for part number 04896004

Thank you! Looks like 1 byte (FF) is missing from the end but otherwise looks intact.
Something you should know, there's a widespread "bug" in the SBEC3 flash files that prevent reading them fully.

That ECU you have has 256k flash memory and the ROM reading command is limited to 128k. They probably forgot to broaden this reader backdoor.
The function that actually returns ROM values are nowhere to be found in the first 128k, that's why I'm sure it's 256k.

We have tested a patched flash file with a 1-bit modification and the SBEC3 allowed to read the whole 256k.
It's kind of a bummer. No easy way around this other than re-flashing the ECU with the patched flash file or uploading a custom worker function to read the full ROM. This involves the first few steps of the re-flashing procedure which is out of the scope of this scanner.

What were the reasons that made the flash reading sessions fail for you? Timeouts? Wiring issues?

Right, this was a bug in the earlier versions of the GUI. Please update to the latest one. It includes a fix that makes the reading session more stable as well.



That was my first impression too but I couldn't find another command to read the second portion of the flash chip.



Please don't do that, the scanner pins are not protected above 5V logic voltage, so 12V and 20V will damage them!



Will reply to this later, I just wanted to warn you about the unprotected nature of the scanner first.

Edit:



I don't know about +12V bootstrapping, SBEC3's only seem to have +20V programming voltage.

The blog post doesn't mention this because I didn't know at that time, but you should apply +20V to RX-pin while key is off, then turn key on and the ECU will start up in boot mode at 62500 baud. At this point remove +20V from RX-pin.

Stabilization time of the +20V programming voltage, according to the SCI-bus paper, must be 1 ms or less, so you can say the ECU is picky about this. The DC-DC boost circuit must be strong.

Then you must upload a bootloader function to take control of the ECU. This is a overly simplified function similar to what runs in the original firmware, it's just limited to very basic features.
After that the bootloader function can be instructed to accept a worker function that does actual work.

I have a few example reverse engineered binaries for the bootloader function and worker functions. I'll start a thread for them.

Posted all the binaries in the new thread. In the re-flashing logs the first block was always 15 bytes long. I don't know the reason behind this. Rest assured all bytes are there. First 2 bytes tell the length of the binary.

Thank you for investigating the programming voltage!

Edit: fyi block length could be anywhere between 1-256 bytes, and can vary between blocks, it depends on the buffer sizes. SEBC3 computers must be able to buffer max 256 bytes of data. Bootloader app and worker functions tend to be transmitted in 16-byte blocks and flash data in 128-byte blocks. It's a matter of choice really.