Along the lines of #21 -- I'd like to add some U-Boot image automation that can quickly locate accesses to memory-mapped SoC peripheral registers.
I envision creating a separate project and git repository to aggregate SoC memory maps (if one does not already exist), and then making that a Depthcharge dependency (or pulling it in as a subrepo).
By understanding what SoC-specific functionality the bootloader is using, one can gain insight into customization a vendor may have made, as well as what functionality is or is not in use (i.e. helping establish the attack surface).
For example, one of the more adorable custom U-Boot "protections" I've come across is the use of a debug enable GPIO pin that would allow the console to be access when the pin as asserted. I found this while reversing code dumped from the device's NOR,
Along the lines of #21 -- I'd like to add some U-Boot image automation that can quickly locate accesses to memory-mapped SoC peripheral registers.
I envision creating a separate project and git repository to aggregate SoC memory maps (if one does not already exist), and then making that a Depthcharge dependency (or pulling it in as a subrepo).
By understanding what SoC-specific functionality the bootloader is using, one can gain insight into customization a vendor may have made, as well as what functionality is or is not in use (i.e. helping establish the attack surface).
For example, one of the more adorable custom U-Boot "protections" I've come across is the use of a debug enable GPIO pin that would allow the console to be access when the pin as asserted. I found this while reversing code dumped from the device's NOR,