Hi Gillian,
These types of attacks are typically looking for "fault injection mitigation" strategies. Basic strategies are relatively well-known, Jasper & I have a few in Chapter 14 of our book too for example. You can find a few examples in the Trusted Firmware-M bootloader I mentioned - a short overview is at https://www.trustedfirmware.org/docs/TF-M_fault_injection_mitigation.pdf, but if you look into their code base there is more examples there. More advanced countermeasures can sometimes take advantage of hardware features. There is a whole area of research around "code flow integrity" - some of this is protecting against code flow changes due to software injection, but some of it protects hardware injection too. This can be anything from pointer integrity to validating things like the cycle count is what you expect at a certain point in time. For many of these protections you could bypass them with multiple glitches, but the reality is that most systems still have no protection. So if you're putting a little bit of thought into this & making life a little hardware, you are probably way ahead of most other designs out there.

On more serious devices you can have glitch detectors too. Basically the glitches happen due to either timing violations (the timing violations often caused by voltage perturbations), or directly flipping bits in static registers. Glitch detectors are just the same sort of digital circuits but they simply sit there confirming there is no invalid value loaded (checking for static bit flipped, invalid value loaded into a shifter, etc). They may also look for the actual signal inserting the glitch (such as a bright pulse of light that should never exist on the chip surface, or a strong EM wave). The hardware detectors are less common in generic micros but some have them as part of a security subsystem - the EFR32MG21A/B from Silicon Labs has glitch detectors in the trusted 'secure element' subsystem. If you attempt to insert a glitch during certain operations (such as any crypto operation) the subsystem will return an error.

On firmware you can do some minor glitch detection too. If you have very sensitive operations, you can for example add some long for() loops around them that simply increment a variable, and at the end of the loop you confirm the variable has the expected value. Someone trying to insert glitches into your sensitive operation are likely to accidently hit your "mine". Reacting to this error can be tricky though - if an attacker can try forever to hit the right spot, you're still vulnerable. But if you can slow them down (maybe you just reboot, and the reboot process takes some time) or even erase sensitive data they are much more effective.

Of course anything with firmware be careful of the compiler - I really love godbolt.org or testing these sorts of things quickly. Hopefully the above gives you some ideas of what is out there - there is no "easy" solution I know of yet, it still tends to be a lot of tuning for specific devices or use-cases it seems.

One use-case for EMFI is just "see what goes wrong" - in a lot of designs this may include for example some failsafe mode that cannot be externally triggered (there is a paper called BadFET showing this - https://www.usenix.org/system/files/conference/woot17/woot17-paper-cui.pdf). My demo on the RSA one is a "cheat" as it sits there in a loop doing RSA signatures (normally you wouldn't do that). In reality you would need to trigger on the location of the RSA - this isn't as hard as it sounds, since RSA is so slow this glitch can be easily applied.

But more realistic use-cases always need a careful test of the trigger conditions. My example of the car ECU one was bypassing a password check which required me to figure out when the password check is happening. This isn't as difficult as it sounds since you often have lots of external information (when I sent the password, when it responds, if I can see power usage differences). You can see this example at https://colinoflynn.com/2020/11/bam-bam-on-reliability-of-emfi-for-in-situ-automotive-ecu-attacks/.

The other link in the comment above to Lennert's example also shows using EMFI with specific timing. So sometimes it can be as easy as triggering some invalid mode, but most of the time it requires a lot of effort to get there.

The primary goal of it is for educational, including research and evaluating your own designs against FI. But even with some effort one can push it towards more real-world usage - Lennert Wouters' demo that I mention in the presentation shows using PicoEMP on an (unhardened) microcontroller to circumvent the security settings (https://github.com/KULeuven-COSIC/SimpleLink-FI/blob/main/notebooks/5_ChipSHOUTER-PicoEMP.ipynb for direct link).