Forcing MIC failures, again
Queisser, Andrew VfB Stuttgart '07!!
Wed May 30 22:35:15 PDT 2007
Jouni Malinen wrote:
>> if (corruptCondition)
>> 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.
More information about the Hostap