Attack Firmware v1.2, Target firmware v1.4, Dump Script v1.5

This release brings some minor changes introduced in @deividAlfa's recent PR.

Here's a summary of what has changed:

Target Firmware:

• If WDG_SW is enabled in the option bytes, the IWDG is continiously refreshed. This fixes infinite dumping loops such as in #20

• The flash size register is no longer utilized, improving compatibility with F1 clones that do not implement the flash size register. The flash is now simply dumped until a fault occurs.

Dump Script:

• Show address when printing dump to terminal

Attack Firmware v1.2, Target firmware v1.3, Dump Script v1.4

This release brings fixes and enhancements to the target exploit firmware. Notably, it improves compatibility across the entire F1 family. Once again, special thanks to @deividAlfa for their generous contributions.

Here's a summary of what has changed:

Target Firmware:

• Varying SRAM execution entry points are now dealt with dynamically by allocating a trampoline from 0x100 - 0x300. This eliminates the need to compile different binaries for each entry point. See #18 and 3bdbdd6 for more details.

• Fixed hard-faults occurring on F1's with smaller SRAM sizes (00, 01, 02) by only allocating 4KB of RAM. Lower SRAM devices would experience hard-faults when pushing to the stack (e.g. when a function was called). See #18 and 3bdbdd6 for more details. Likely also fixed #10.

• Removed the need for USART RX. Since the dump only transmits data to the attack board, the RX pin is not required. That's one less pin that needs to be accessed!

• Overhauled the target firmware code. That includes removing lots of dead/unused code from the original POC, fixing some minor bugs, as well as improving the readability of the code through the use of structs and comments. The assembly section has been renamed from test.S to entry.S and now features comments that explain exactly what each step does.

Dump Script:

• Entry point check now only tests if the detected entry point lies in the range of 0x100 - 0x300. See first point in Target Firmware changes.

• Mentions that Pico TX -> STM RX communication is no longer required. Completely omitting any mentions of Pico TX -> STM RX wiring has not been done since that could cause users to confuse GPIO0 with GPIO1 on the Pi Pico. Switching GPIO's was also out of the question since that could potentially break hard-wired set-ups.

Attack Firmware v1.2, Target firmware v1.2, Dump Script v1.3

This release mostly consists of @deividAlfa's contributions (special thanks) and a couple of minor fixes for issues pointed out by people.

Here's a summary of what has changed:

dump.py:

• Updated minimum OpenOCD version to 0.11.0 until backwards compatibility for 0.10.0 has been implemented (See #2)
• Fixed OpenOCD version detection to work with dev builds by switching to regex based version testing
• Wait 2 seconds to give the user some buffer/head-room to properly connect the debug probe (See #9)
• Fixed target fw upload failing if the absolute path of dump.py contains spaces (See #3)

Attack Firmware:

• Set the Pico's nRST sensing input to pull-up to avoid a voltage divider forming between the nRST's pull-up and the Pi's GPIO's pull-down. Depending on the target device, this could have lead to instability due to the nRST line being too low. (See #5)

Target Firmware:

• Dynamically determine flash size by reading the Flash size register (0x1FFFF7E0, see RM0008 page 1076). On 64kB, 128kB's are read as it's the same die and some firmwares make use if this. (See #8)

Other fixes:

• Fixed "Note" with GPIO wiring in the Bluepill Fritzing sketch in the README.md (See #6)

Here's an oscilloscope comparisont to showcase the voltage accross the nRST line without the Pi's input being set to pull-up, and with its input being set to pull-up:

Without pull-up:

The max voltage was around 2.7V

With pull-up:

The voltage now reaches the expected and desired 3.3V (alright... its 3.2V, but that's close enough 😉)

Attack Firmware v1.1, Target firmware v1.1

This release serves as a companion to the recent modifications made to the dump.py script (v1.2). The script has been updated to address an issue where the attack was not functioning correctly on STM32F1 chips with a distinct SRAM entry point offset from the value of 0x108 found on the F103 series (refer to #1). Special thanks to @luistmw for pointing out the issue and testing the fix!

In this release, instead of compiling a single target firmware, we now compile target firmware binaries for each possible SRAM entry point offset, namely 0x108, 0x1CC, and 0x1E0. Additionally, we compile binaries for each possible USART peripheral, resulting in a total of nine firmware binaries. The dump script automatically detects the SRAM entry point offset and now prompts the user to select the USART peripheral for dumping the firmware (alternatively the -u flag can be also be used to select the target dumping USART). It then selects the appropriate binary corresponding to the detected entry point offset and selected USART peripheral.

Besides dealing with varying entry point offsets and now allowing the user to select the target dumping USART peripheral during script execution, here are some additional changes in this release:

dump.py:

• Script now requires to disconnect the debugger before prompting to reset/re-connect the Pi Pico. This ensures that the target device is power cycled when the Pico is reset/reconnected.
• Changes in printed output/instructions

Attack Firmware:

• Power pin is first set to HIGH before being configured as OUTPUT to prevent accidental short when debugger is connected

Attack Firmware v1.0, Target firmware v1.1

Target: Updated makefile with usart targets

Signed-off-by: CTXz <[email protected]>

Attack and target firmware v1.0

README: Added banner

Signed-off-by: CTXz <[email protected]>