Fault201, Lab 1_2, Faulty Ciphertexts not resulting in any key guess

Hey, I’m using the CW1200 trying to glitch the unmodified TINYAES128 as described in fault201 Lab 1_2 (1.5 Round AES Attack). The target is the STM32F3 target board mounted on the CW308 UFO board.
I’ve successfully glitched the controller in every other course, but this one is giving me no results despite seeing the wanted behavior in the power traces.

The glitch shows a success at sample 988 (some other samples also show success near this area, such as 972). I can only embed one image right now because I am a new forum user, so just trust me that I can see round 1 and the final round (no MixColumns).

This is the trace zoomed in towards the most interesting area. The glitch is happening right after the 2nd AddRoundKey and all 16 XORs are visible in the power trace, which means the glitch isn’t happening too early from my understanding.

Here are the settings I am using. Similar settings also worked for 1_1B where the end of the first AddRoundKey operation was successfully glitched with the volatile round counter, and the key was recovered correctly in that lab.

MIN_STEP = 0.15625
gc.set_range(“width”, 16, 16)
gc.set_range(“offset”, -10, -10)
gc.set_range(“ext_offset”, 988, 988)
scope.glitch.repeat = 5

The attack phase shows that no key was recovered. As you can see in Known, I did indeed capture 2 different faulty CTs but while debugging the Attack function, I noticed that some kind of if-check is failing which results in no kguess being generated. So there’s either some some kind of problem with the function (less likely) or some kind of problem with my glitch (more likely). Both CTs were recovered at the sample location (988 in this case) and of course both were using the same PT of [0x00]*16.

Print of Known:
[1, 141, 9, 235, 148, 90, 82, 131, 227, 56, 85, 234, 18, 40, 153, 110, 116, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 246, 114, 168, 166, 165, 44, 62, 118, 101, 96, 117, 209, 89, 192, 38, 135]

Print of kguess:

Is the repeat parameter screwing with the SubBytes/ShiftRows operation of the final round? I would need to get completely new settings if that was the case, but it would surprise me considering this attack worked in 1_1B.

Thanks for the help, I haven’t seen any forum entries on this lab yet so I wonder if I’m the only one with this issue.