I’ve been reading around a little and see a number of people who have issues with getting locked out of their chips either due to corrupt passwords, copying things they aren’t supposed to (like the Amiibo), and things like locked pages.
I’m still pretty new to RFID and NFC, but is there any way for future chips to have some sort of ‘return to stock’ feature? VHS used magnets, Eeproms use UV light, there has to be some way to incorporate a failsafe instead of cutting it out of your hand, right?
Just looking for ways to brainstorm
I think something like that would kind of defeat the purpose of a successful password lock, no?
I also think that it’s not an incredibly common problem that can usually be avoided
1 Like
I 100% agree, but I think it happens often enough where it should at least be in the conversation.
With how many articles about the white cloners bricking chips, the blue cloners being semi-unreliable, and other issues, I would say it is fairly common and should be addressed. I think getting a proxmark and bruteforcing is marginally an acceptable way of ‘paying for your mistakes’, but that won’t fix all of the known bricking/corruption issues
You’re not wrong, it would be lovely to have, but who’s going to pay for it?
Let’s assume we represent 0.00000000000001% of all RFID chips - instead of making our own ICs (which would be slow, expensive, possibly have compatibility issues), our implants use the same chips that are usually used for standard cards. In standard cards there is no demand for this, if a card gets bricked or damaged, you just replace it.
So who pays? Do we pay for it by developing these custom chips for our tiny market? Or does the 99.999999999999999% pay for it with us, to get a feature implemented in standard chips they don’t want or need?
Until those percentages get closer to even and people mass produce ICs designed specifically for implants, I really don’t see it happening
Here’s my inexperience speaking, but I understand you can run some chips in emulation mode or… compatibility container mode(?). Is there any way to preprogram a chip from DangerousThings that pretends to be another chip (T5577 for example) that allows writes within it’s container but not to the rest? I know that would be a locked down chip, and some people really wouldn’t appreciate that.
It would be like a Virtual Machine on a computer, it thinks it’s a real computer, it acts like a real computer, but you can wipe it with no adverse affects to the computer it runs on.
Great idea!
The problem is, DT works with COTS chips. If they want a custom chips with those features added in, they’ll either have to pay someone in China beaucoup bucks to change the design and place an initial order of one hundred fucktillion chips for them Chinese to even pay attention to the request, or start their own foundry.
1 Like
In my very limited understanding, Apex will approximate this for HF - it runs Javacard applets, so I guess if you mess up the data within an applet you could delete and reinstall it. It does card emulation, but it’s much more limited than our magic cards (I think it’s been said you can’t change the UID).
For LF, a T5577 is the closest we’ve gotten, and it’s perfect for the rest of the security industry so I don’t see that improving.
In every chip, we get components of the ‘holy grail’ - but you have to pick your battles. No chip is or probably ever will be perfect for our uses. Good thing DT has a variety to choose from!
1 Like