Forcing MIC failures, again

Queisser, Andrew (VfB Stuttgart '07!!) andrew.queisser at
Thu May 31 01:35:15 EDT 2007

Jouni Malinen wrote:
>> if (corruptCondition)
>>   pos[0]++;
>> at the end of the function ieee80211_michael_mic_add, just before the
>> return 0 statement.
>> - Would the contents of pos match the bytes in the sniffer or is there

>> another level of encryption that happens?
>No, they should not match. Michael MIC value is encrypted with rest of
> the frame.

Ok, makes sense.

>> - Why doesn't the change to the MIC cause a MIC failure on the AP? Do I
>> have the code in the wrong spot?
>If your driver is only using software encryption for TKIP, this would be
>suitable place to change the MIC value. Are you sure the AP implements
>TKIP countermeasures correctly?
I'll try to find out if the driver uses HW encryption, I thought it didn't but I'm not 100% sure.

I'm not sure at all whether the AP implements the countermeasure correctly. What  I do know is that the countermeasures fire all the time with a particular client we're using. That's why I'm trying to put together some test tools so I can figure out what's going on.

I'm also using hostapd (thanks for all the great work, Jouni) as a "reference" since that allows me to do all sorts of debugging. Just now I got hostapd running with my madwifi notebook so I can test both my modified zd1211 driver as well as my problematic clients to see what's going on.


Thanks again,

Andrew Queisser

More information about the HostAP mailing list