Particularly for this adventure, I have kept it strictly private. It was a hobby project and also was a challenge to myself.
In the process I learned not only of M32C(backwards compatible with M16C processor module in Ghidra), but as I mentioned, certain compiler bugs(not following the ISA spec strictly) that it is more flexible despite what the M16/M32C software manual says. However this meant that emulation produced wrong results, and thus my patches to fix it and ultimate success
I have opened a Ghidra support ticket, but I needed to provide proof that there is ISA behavior not described in the software manuals.
The glitch has to happen within the window shown to you by the microcontroller. It seems to be in a different location for each microcontroller evaluated. The fact that it shows you where depending on which processor you’re attacking is pretty convenient!
Thanks, makes a lot more sense now, I guess if Vcc was lower the effect would be more pronounced if anything, never really considered this as an attack vector, but looking online now it seems to well established, I'm surprised Microchip engineers didn't pick it up.
There are two radio’s in the meter, one for zigbee and one for the 900MHz mesh that sends this data back to power company. The zigbee side isn’t used at all here anymore, they killed our ability to view our usage with it.
Gave a talk at hardwear.io this year on it. YouTube live stream here: https://youtube.com/live/0tkdst3JE0g