Forcing MIC failures, again

[Queisser, Andrew VfB Stuttgart '07!!]

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