Jeff Yang wrote: > I’m playing with the new U.are.U 4500 module from DigitalPersona. It > doesn’t work which is not a surprise. The image is encrypted. > > > > You were able to bypass the encryption for the 4000B model by comparing > its “firmware” with an unencrypted MS reader and found one byte > difference. And now, first of all, the windows driver doesn’t send a > “firmware” to the device anymore and second there is nothing to compare > of. In the fix_firmware function, I looped through addresses and did > find the same pattern (FF 17 41) at offset 0x6c7, but after I change it > to FF 07 41, the device refused to power up (set_hwstat to 01, and > get_hwstat always returns 81). If I don’t fix the firmware, I can do > everything else except the image captured is garbage.
The powerup sequence is somewhat sensitive at least on the earlier models... or maybe you're right and they finally plugged this gap. We were pretty lucky to be able to figure out how to disable encryption on the other models just by eye, like you have attempted! If this is the case, I don't think you'll have much luck through bus traffic analysis, you'd need another approach. For a different challenge with these devices we did chinese-wall reverse engineering on the windows driver. I don't have my previous contact anymore, but if you know of someone or could do the disassembly part yourself (and never write any related code again) then it's an option. http://www.reactivated.net/weblog/archives/2007/12/libfprint-v005-supports-new-ms-hardware/ Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
