I also hit it with an infrared thermometer before and after being introduced to the field. The temperature was elevated by 1.5°C, probably due to eddy currents.
5 Likes
Nice 
1 Like
Just got the PLA-Graphene filament in today. I’ve got a 3D printer being delivered tomorrow, so I should have another couple of test videos up by the weekend.
5 Likes
Any progress you can share?
2 Likes
125kHz is more electromagnetic coupling than radio. Faraday cages are useless for that.
I have made a little progress. I’m really new to 3D printing so that’s been a bit of a learning curve.
At this point, I’m going to try the glove approach first using a layer of the Titan fabric between an outer layer of mesh fabric and PLA-Graphene hexagons, with an inner layer of soft fabric. I have some glove templates to start with, debating on if I need to buy a new sewing machine to handle the thicker material, but I can totally do it by hand for a proof of concept piece. I’ve tried printing directly on to the Titan stuff but it’s not quite porous enough for anything to stick.
I’ve also tried printing the PLA “fabric” but they really turned out horrible, but that’s largely due to my inexperience. Just have to keep trying.
As far as the solid cast/gauntlet route, I have a 3D scanner coming in this week should help get that design fitting correctly. I just got an email too saying my Prusa MK3s just got shipped and should be here tomorrow, so that should really help improve the quality of prints.
2 Likes
Well here’s something you might find interesting. Literally, right after reviving this thread I stumbled on this video by @DeviantOllam detailing RFID blocking methods beyond the traditional tinfoil wrapper.
EDIT: So in theory a field detector glove would be RFID blocking. I feel like that should be possible to weave into a breathable, lightweight glove. Not easy but an idea.
5 Likes
I wouldn’t say totally useless, just not super effective… but they can have an effect.
1 Like
Would embedding lots flexible tags into some clothing work, basically intentionally causing collisions?
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.
2 Likes
No luck with these. The PLA-Graphene has no discernible blocking characteristics for 13.56MHz.
2 Likes
Could you share what model of printer you have, I may have some ideas.
1 Like
I’m currently using an Ender 3 pro with a few upgrades. The Prusa will be here on Friday.
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.
1 Like
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.
4 Likes
4 posts were merged into an existing topic: The anti-derailment & thread hijacking thread 
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.
2 Likes
They list readers as being effected by it, it even kill’s wireless power chargers AFAIK
2 Likes
They fry a reader starting at the 2 min mark in this
I’ve been tempted to test it on an old phone.
2 Likes