Indeed. If you’re worried about people reading your implant from a distance (unlikely but possible) and the implant in question isn’t designed with an anticollision protocol, your best countermeasure would be to tape a tag of the same kind over it. Even an implant that could be read with anticollision might be “overshadowed” by a similar, full-size tag of the same kind that couples much better with the reader over it, and become unreadable as a result.
As for implant-killing EM pulses, well… I doubt that’s much an issue even in a hostile environment. The baddie would have to come quite close to you to have a chance of succeeding. Killing an RFID implant from a significant distance would require such a powerful pulse it would take out nearby computers and cellphones with it. I don’t think it’ll happen, unless they approach you with the suspicious device while you’re sleeping.
So while designing anti-RFID-kill garment is certainly an interesting exercise, I’m fairly sure it’s not terribly useful.
Is there a way to have an RFID tag that ruins whatever scans it? So if someone is trying to scan your stuff and they scan the wrong one, it causes the program to freeze?
If this is a dumb question, that shows my technical ability.
If this is a good question, then yeah, I totes know this stuff.
Unless there’s a bug in the reader’s firmware, no. And even so, you’re only likely to crash it at best, not disable it permanently. The only one I know of is the Halo scanner that can’t handle EM4xxx UIDs with zeros - and that doesn’t kill or crash it: it just fails to report them.
Having said that, you raise an interesting point. It might be worth investigating for one reason: I have a feeling most engineers who coded such firmware probably didn’t expect the card to return malformed datagrams. Or said another way, most readers probably don’t treat data returned by a card as unstrusted input, like they would a regular user input.
So there’s a good chance that you might crash more than a few readers by returning oversized datagrams to cause a buffer overflow, or datagrams containing “impossible” values in key bitfields to trigger division-by-zero errors.
If you’re old enough to remember, there was one infamous such bug in Windows 3.11, 95 and NT: if you sent a very large packet to a Windows computer on port 139, you would crash the entire OS. Back in the days, there was a considerable number of script kiddies having fun crashing computers on IRC chatroom.
I’m willing to bet you probably can use the same trick to crash a good few RFID readers - and possibly lock up a few of them permanently, if they’re silly enough to write that malformed data, or something that derives from it, in flash.
Other devices that might be susceptible to exploits are readers with undocumented features, like special “programming” or “configuration” cards. These devices treat certain cards as “master keys” that unlock certain configuration options, or set certain things. If you manage to identify what makes a card special for such a device, you could possibly set the device in an impossible state, disabling it.
My hunch is that if you presented the NFC Kill device, which is designed to kill NFC tags, to an NFC reader instead… you would be able to fry a large percentage of NFC readers, probably including some smartphones.
To answer the question nobody asked (but mostly to follow up on this exchange in the proper thread): chainmail as a Faraday cage doesn’t work to shield LF or HF implants: