You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 5, 2025. It is now read-only.
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,