Perhaps I am thinking too much in terms of an embedded project I'm working on myself, and thus making too many assumptions about how the ECU firmware is laid out.
Basically, the project I'm working on has a boot loader that resides in two specific blocks of memory. The boot loader knows how to un-protect and write to every other block of memory, but if you tell it to modify itself, it does nothing.
The boot loader's job is to listen for few image firmware at boot time, and jump into the new image after (if) one is transferred.
Can we find the boot loader code in the ECU images? Is it fairly well localized, i.e. the first-instruction code, set, communications, etc, all in a reasonably well-defined address range?
If so, could the Subaru boot loader, the reflashing kernel, or EcuFlash itself be modified to never write anything to the boot loader address ranges? (Insert magic here r.e. each ROM having its own protected ranges, we'll solve that problem later if at all).
That was you could write hamburgers (0xDEADBEEF) across the whole ECU, minus the bootloader range, and still be able to deploy a good image since the bootloader would still boot up and accept new images.
Would this type of protection would have saved Zuczek's ECU?
It seems too easy right now for a minor mistake to brick an ECU - which bricks the whole car, basically. It also seems like a solvable problem. Given the seriousness of such mis-steps, it would be REALLY nice to see the developers in this group highly prioritize features that protect users from themselves (or, from each other, as the case may be).