Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by couchand on Monday April 29, 2019 @09:07AM
(#19777975)
OTOH if the OEM can't code the CRC right, one might be better off packing their own parachute...
[ Parent
| on HN ]
Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by Odenwaelder on Monday April 29, 2019 @09:10AM
(#19778007)
No, you're not better off. If you want to get a medical product like this licensed, you have to prove that you performed rigorous, multi-staged testing and document all your development including all emerging risks. I have participated in such licensing efforts and I doubt that an open source project has the means of providing such rigorous testing.
Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by stefan_ on Monday April 29, 2019 @09:57AM
(#19778369)
The result of this diligent process, of course, is how a broken CRC16 routine got shipped in this medical product.
It's the most trivial thing. Copy a public domain CRC16 routine, add a unit test with a test vector.
Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by joezydeco on Monday April 29, 2019 @06:32PM
(#19783229)
Can you be sure it wasn’t a badly implemented form of obsfucatiom?
It certainly slowed down the reverse engineers. If they didn’t get to the object code what would the next step have been? Cryptographic analysis?
Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by stefan_ on Monday April 29, 2019 @06:48PM
(#19783341)
5 of the bits were never set in their "obfuscated" variant? If you want to obfuscate CRC16 you would just choose a randomized starting value.
Re:Insulin Pumps, Decapped Chips and Software Defined Radios
by joezydeco on Monday April 29, 2019 @09:30PM
(#19784328)
I didn't say it was implemented well. Perhaps they should changing shift operators would quietly change the values without any disturbance to checksum integrity.