What changed, and why it matters
This commit adds a small piece of code that writes a fixed 'magic number' marker to flash memory after a successful bootloader update. The marker is stored in the last 4 KB of the application flash region. This is likely intended as a flag so the system can later detect that a boot update has occurred. The change itself is not obviously malicious, but it modifies sensitive boot-update logic and writes to flash, so it deserves careful review in context.
Review the full boot_update.c file and the definitions of MAGIC_NUMBER, MAGIC_NUMBER_SIZE, and APP_END_ADDR. Confirm the flag sector does not overlap valid application data, that the flag is read and validated securely elsewhere, and that repeated updates do not cause excessive flash wear or bricking. Consider whether the flag needs authentication or anti-rollback checks.
Security signals we found
Flash write in bootloader update path
Use of hardcoded/fixed MAGIC_NUMBER marker
Write to APP_END_ADDR - 4096, which may overlap application region
No visible authentication or rollback protection for the flag itself
Change is minimal and lacks explanatory commit message
Evidence from the diff
In UpdateBootFromFlash(), after verifying the SHA-256 hash of the new bootloader image and erasing/writing the updated image, the code now: (1) copies MAGIC_NUMBER into g_fileUnit, (2) erases and writes that 4 KB block to APP_END_ADDR - 4096 via QspiFlashEraseAndWrite(), and (3) zeroes g_fileUnit. The intent appears to be setting a persistent post-update flag. Without surrounding code and definitions of MAGIC_NUMBER, APP_END_ADDR, and the broader update flow, it is unclear whether this introduces security issues such as flash wear, unintended overwrites of application data, or reliance on an unauthenticated flag.
Changed components
src/boot_update.cBootloader update routineExternal QSPI flash managementInspect captured patch +3 / −0
diff --git a/src/boot_update.c b/src/boot_update.c
index 89ca8d2..d89ea03 100644
--- a/src/boot_update.c
+++ b/src/boot_update.c
@@ -114,6 +114,9 @@ int32_t UpdateBootFromFlash(void)
if (memcmp(hash, calHash, 32) == 0) {
printf("update success\n");
memset(g_fileUnit, 0xFF, sizeof(g_fileUnit));
+ memcpy(g_fileUnit, MAGIC_NUMBER, MAGIC_NUMBER_SIZE);
+ QspiFlashEraseAndWrite((uint32_t *)(APP_END_ADDR - 4096), g_fileUnit, 4096);
+ memset(g_fileUnit, 0, sizeof(g_fileUnit));
return 0;
} else {
printf("update failed\n");
Why this scored 40/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.