[Graziano_M]

It's probably to keep the payload in SRAM for longer.

If it's the attack I believe it to be, basically it:

1. Acts as a debugger (core blocks touching flash) and writes a 2-part payload to SRAM.

2. Detaches the debugger, straps the boot pins to boot from SRAM (payload 1)

3. Resets the board via reset pin (keeping SRAM)

4. SRAM payload 1 runs (core blocks touching flash), configuring the FPB to 'overlay' the reset vector on flash with a pointer to payload 2

5. Flicks off the power just long enough for the hardware to reset, but not long enough for the SRAM to clear (this is where I think being cold helps).

6. Device boots 'unlocked' into 'flash', but the FPB hijacked the vector table and so the CPU immediately jumps to payload 2.

7. Payload 2 can now do whatever with flash (e.g. dump it out over UART or SPI)

[pseudohadamard]

Freezing RAM keeps its contents intact for remarkable amounts of time. For DRAM it's long enough to unplug the DIMM from the target device and move it across to the analysis device for recovery of the data on it. It's one of those things that's hard to believe until you actually do it, that you can have the RAM totally disconnected and unpowered while it retains its contents.

[rustyhancock]

Very neat!