On the risk for bricking and how to mitigate it:
When reverse engineering and trying things unknown, it is always helpful to be able to restore the device to the condition it was before you started messing with things - ie dump all non-volatile memories so they can be restored later or having a working set of tools for doing firmware update etc with the same version that you have on the device and then also having confirmed that such an update would also reset or wipe configurations / settings or other data storage outside of the actual firmware. Under those conditions you can hammer it pretty hard without having to worry about breaking digital things at least - and when it breaks you just restore it and start again. This is actually much more helpful than just not breaking things since it gives you the confidence and freedom to explore much more freely and always be able to restore to a known state not having to worry about accumulated effects or memory of previous actions in the device. Unfortunately there is a chance of burning mechanical or other things of the physical world by sending broken commands still of course…
- Serial memories, I2C or SPI, you can easily just hook up 3 wires to them permanently and be able to dump or write contents while holding the rest of the system in reset for example - beware of serial NAND-memories that require error correction and wear-levelling though - see below. EEPROMs and FRAM is a breeze and typically are used for configuration, settings etc even though less and less so (replaced by storing in NAND, eMMC etc to reduce BOM more often now)
- eMMC is actually an SD-card so you can typically wire in a SD-card dummy adapter that you can put in a reader and make sure you only power the eMMC and then access it for reading and writing as if it was an SD-card. You can even remove an eMMC-chip and put a SD-card socket instead and then you can just change and replace the content by swapping he SD-card but even if this has been working it has been error-prone and resulting in weird bugs and such things that you just don’t want - and also it’s a bit tricky to solder on bga pads…
- Parallell NAND-flash is a bit trickier for many reasons: needs 12-15 or so pads connected, and it is inherently error-prone so in order to be able to reconstruct broken data you need to understand error-correction used, and since it needs wear-leveling, locations where data is stored moves around so if you would move to another chip you cannot just rewrite the image because bad blocks wouldn’t match and as your chip ages it will deteriorate and things might have moved so you might not be able to rewrite the original image in a way that works. Typically easiest to dump/restore from within a system or a bootloader/u-boot or so which already handles those things for you as expected by the rest of the system - wear-leveling and error correction applies to serial NAND memories above also.
- Parallell NOR chips you typically have to de-solder to dump and rewrite - separate address and databus makes it just too many pins and too complicated to wire it in(even though that has been done too, replacin with a socket e.g.) - so also preferably read/written from within the system. No wear-leveling or error correction needed on NOR typically so can be dumped and restored at will. Solder/desolder chips can be done a few times but typically the traces and the PCB give in after a few cycles and then you need a new PCB…
- Most processors also have embedded non-volatile memory apart from the program memory - EEPROM or so - and typically this needs device-specific tools to access…
Once you have the ability to store and restore all non-volatile data you can break things at will and also create a library of different versions and configurations and be able to clone systems to try them out and explore them.