Test HAB on IMXRT1024 without burning fuses I have taken unsigned led blinky code and implemented HAB audit API (report status and report event). EVK board is open and fuses not burnt Unsigned image(CSF=0) - HAB fail with 4 events Signed image - HAB pass 0 events So i assumed that even board is open HAB authentication runs and hence i can see events. But now i taken project firmware with same IVT (CSF=0) and i implemented same HAB audit but this time Unsigned image - HAB pass with 0 events Led blinky logs (unsigned): RVT header at 0x 2002c0: tag=0xdd len=0x 038 par=0x43 HAB: RVT version = 0x 40305 HAB: report_status() = 0x33(HAB_FAILURE) HAB: config = 0xf0(HAB_CFG_OPEN) HAB: state = 0x66(HAB_STATE_NONSECURE) HAB: event[0], 8 bytes HAB: hdr: tag=0xdb len=0x 0 8 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x22(HAB_INV_ADDRESS) context=0x a(HAB_CTX_AUTHENTICATE) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 8 43 33 22 a 0 HAB: event[1], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB: event[2], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB: event[3], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 20 0 0 0 0 4 HAB: VERDICT = 4 EVENT(S) LOGGED -- see decoded fields above but my project firmware(unsigned) HAB: RVT header at 0x002002c0 HAB: tag=0xdd len=0x0038 par=0x43 HAB: RVT found and valid HAB: RVT version = 0x00040305 HAB: report_status() = 0xf0 HAB: config = 0xf0 HAB: state = 0x66 HAB: querying audit events... HAB: report_event(idx=0) returned 0x33 (no events or query HAB: VERDICT = PASS (no audit events logged) Why there is a difference Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 ,
Thanks for the reaching out! May I have the sdk version that has the led blinky code and the SPT version used for building the image?
Thank for your patience!
Have a great day, Kan
------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses This is SDK version - SDK_25_06_00_MIMXRT1024xxxxx SPT version - 26.06 MCU xpresso - v25.6.136 unsigned image for led blinky if compiled through mcu xpresso and then signed image is created through both SPT and CST 4.0 Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 ,
Thanks for the info and detailed logs — this is a great observation and the difference comes down to one thing: whether the CSF pointer in the IVT is zero or non-zero.
How HABv4 decides to authenticate
On i.MX RT10xx, the Boot ROM checks the CSF field of the IVT before deciding whether to attempt authentication:
If CSF = 0x00000000 (null): HAB skips authentication entirely — no events are logged and report_status() returns 0xf0 (HAB_SUCCESS). This is not a "pass" in the security sense; authentication was never attempted.
If CSF = non-zero (points to a CSF region): HAB attempts authentication — if the signature is missing or invalid, failure events are logged and report_status() returns 0x33 (HAB_FAILURE). On an open board this does not halt boot.
Why your LED blinky (unsigned) showed 4 failure events
Your LED blinky binary was built by MCUXpresso IDE and then processed through SPT (Secure Provisioning Tool) to create a bootable image. Even for an "unsigned" build type, SPT's bootable image pipeline writes a non-zero CSF pointer into the IVT and reserves a CSF region in the image. The Boot ROM found that non-zero pointer, attempted authentication, found no valid signature data, and logged the 4 events:
Event 0 ( HAB_INV_ADDRESS / HAB_CTX_AUTHENTICATE 😞 HAB tried to locate the image for authentication but encountered an invalid address — consistent with an empty/stub CSF region.
Events 1–3 ( HAB_INV_ASSERTION / HAB_CTX_ASSERT 😞 HAB's internal assertion checks on the image regions failed because there is no real CSF data present.
Why your project firmware (unsigned) showed 0 events
Your project firmware was compiled directly through MCUXpresso IDE without going through SPT's bootable image generation step. The resulting binary has a genuinely null CSF pointer in the IVT. The Boot ROM sees CSF = 0 , skips authentication entirely, and HAB reports clean. The 0x33 return from report_event(idx=0) in your log means "no event at this index" (i.e., the query itself returns HAB_FAILURE because there is nothing stored), not that HAB detected a failure.
Quick way to verify
Inspect the IVT of both binaries at byte offset +0x18 (the CSF field):
SPT-built LED blinky: non-zero value (e.g., 0x60006xxx or similar flash address)
Your project firmware: 0x00000000
To properly test HAB audit with your project firmware
You need to build the bootable image through SPT (or elftosb/nxpimage) so that a CSF region is embedded in the image — even for an unsigned build. This ensures the Boot ROM attempts authentication and HAB events are generated. Only then will your HAB audit code capture meaningful data for testing purposes.
In summary, your original assumption is correct that HAB authentication runs on an open board — but only when a non-zero CSF pointer is present in the IVT. The behavior you observed with your project firmware is expected and correct.
Hope this helps clarify! Let us know if you have further questions.
Have a great day, Kan
------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses Yes Kan_Li the explaination you mentioned is correct but the correct scenario us - LED blinky (unsigned) -> This binary i generated through MCU xpresso IDE only (not processed through SPT). size - 30KB And even i compare the IVT for both led blinky unsigned and my project unsigned both have exactly same IVT (CSF=0) .- size 64KB See hex compare left side is Led blinky and right side is my project firmware Also please mention what is the right way to test HAB without burning fuses Abhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.png Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 ,
Thank you for the hex comparison — this gives a much clearer picture. You're correct that both binaries have identical IVTs with CSF=0. The actual root cause is in the Boot Data size field, not the CSF pointer.
What the hex dump shows
Looking at the Boot Data structure at file offset 0x1020 (pointed to by boot_data in the IVT):
Field
LED Blinky
Project Firmware
start (0x1020)
0x60000000
0x60000000
size (0x1024)
0x00004000 = 16 KB
0x00000400 = 1 KB
plugin (0x1028)
0x00000000
0x00000000
Both CSF fields in the IVT are 0x00000000 — confirmed identical.
Why the HAB behavior differs
The HAB library's authenticate_image() uses the Boot Data region ( start to start + size ) to determine the image scope before attempting authentication. Crucially, the IVT itself is located at flash offset 0x1000 (= 4096 bytes from base). HAB checks whether the IVT falls within the declared Boot Data region:
LED Blinky — Boot Data declares 16 KB ( 0x4000 ). IVT at offset 0x1000 (4096) is inside [0x60000000, 0x60004000) . HAB finds the IVT, attempts authenticate_image() , encounters CSF=0 → logs HAB_INV_ADDRESS + 3 assertion failures → report_status() = HAB_FAILURE .
Project Firmware — Boot Data declares only 1 KB ( 0x400 ). IVT at offset 0x1000 (4096) is outside [0x60000000, 0x60000400) . HAB cannot locate a valid IVT within the declared region → authentication is skipped entirely → report_status() = HAB_SUCCESS , 0 events.
In summary: the 1 KB Boot Data size in your project firmware is incorrectly too small — the IVT sits beyond that boundary, so HAB never touches it.
Note that neither Boot Data size matches the actual binary file sizes (30 KB and 64 KB respectively). Both images have Boot Data that was generated by the IDE directly rather than through a proper bootable image builder. The difference in how wrong the size is determines whether HAB engages.
Root cause
When you compile directly from MCUXpresso IDE without going through SPT or elftosb, the resulting binary does not have a properly formed Boot Data structure for HAB evaluation. The size field ends up set to a value that may or may not encompass the IVT, giving unpredictable HAB audit results.
The correct way to test HAB without burning fuses
The reliable methodology on an Open board is:
Build through SPT or elftosb — this correctly populates the Boot Data ( start , size covering the entire image from base to end of CSF/code), FCB, IVT, and optionally the CSF block. Never test HAB using a raw IDE-compiled .bin — the Boot Data will be unreliable.
Test with an unsigned image (CSF=0, correct Boot Data) — HAB will attempt authentication, find no CSF, and log HAB_INV_ADDRESS + assertion failures. report_status() = HAB_FAILURE . This confirms HAB is running correctly and your audit code is working. This is exactly what your LED blinky + SPT result showed.
Test with a signed image (CSF valid, correct Boot Data) — build a properly signed image via SPT or CST 4.0 with your keys. On an Open board, HAB authenticates the image with the embedded SRK/CSF. If the signature is valid → report_status() = HAB_SUCCESS , 0 events. If the signature is wrong or absent → failure events. Boot continues in both cases on an Open board.
Confidence check before burning fuses — only after you see HAB_SUCCESS with your signed image on an Open board should you proceed to burn the SRK hash fuses. This validates the entire authentication chain safely.
Recommended test sequence (all on Open board):
Step 1: SPT -> Build unsigned image -> Flash -> Run HAB audit
Expected: HAB_FAILURE, 4 events (HAB is running, audit code is correct)
Step 2: SPT/CST -> Build signed image -> Flash -> Run HAB audit
Expected: HAB_SUCCESS, 0 events (signing + authentication working end-to-end)
Step 3: Corrupt the signed image or swap keys -> Flash -> Run HAB audit
Expected: HAB_FAILURE, events logged (confirms rejection logic)
Step 4: Burn fuses (SRK hash) -> confirm Step 2 still passes on Closed board
Hope this fully explains the difference. The key takeaway is to always use SPT/elftosb for building the bootable image when testing HAB — never the raw IDE binary.
Have a great day, Kan
------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses @Kan_Li i think you misunderstood since Boot data is stored in little Endian 32-bit word, So Start in both binaries are same Start 0x60000000 Boot data size is LED blinky - 0x00400000 (4MB) My project it is - 0x00040000 (256KB) So as per your explanation IVT falls inside the defined boot data Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 ,
You're right — apologies for the byte order error. Both Boot Data sizes (4 MB and 256 KB) include the IVT, so my previous explanation was incorrect.
Root cause: HAB event log cleared by startup code
The Boot ROM generates the same 4 failure events for both images (CSF=0, authentication attempted). The difference is that your project firmware's C runtime startup zeroes a larger OCRAM region — which includes the area where the HAB library stores its event log and status — before your HAB audit code runs. This is why report_status() returns 0xF0 and 0 events are found; the HAB state itself was wiped.
How To Fix: Move your HAB audit calls to Reset_Handler , before the BSS zero-init loop, and the events will be visible.
Please kindly let me know if you have any further question.
Have a great day, Kan
------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
View full article
