The flex units will be available in some months when the kung flu dies down a bit
Either really good word play or not so great choice of words you be the judge
07:00 me is not the brightest, but let’s say it was a planned wordplay
The Doorman is on the door. Note to self: don’t install a fucking door lock when it’s -10C outside and the sun has gone down…
I’ve presented the cloned M1k card to the reader for registration as a working key, and it seems to be accepted. But I let the registration process time out, to see if the lock wrote anything into the tag just by presenting it once. And then I quit playing with it for now, because it’s 8:30pm and the missus is starting to get mad at me for letting the cold air in, and because the Doorman is friggin’ loud…
-10 sounds like shorts weather after I was monkeying around in -38 trying to get frozen water lines running.
Aaand… I finally have me an NFC-enabled door lock that works with my implant. Woohoo!
I couldn’t resist: I found the command to lower the lock’s volume, and nevermind the cold: I really wanted to get that thing going. I couldn’t wait for tomorrow.
So, the lock does write to my implant each time I open the door - always the same bytes on the same sector, which bothers the hell out of me. But, well, there really isn’t anything I can do about it if I want a door that I unlocks with my implant. I suppose that sector will go dead in 273 years (=100,000 write)
As planned, I have real Yale tag #1 cloned into a gen1a magic Chinese card, and real Yale tag #2 cloned into my implant. Both clones work perfectly, but the originals are now off-limit from the lock: normally they should just be rejected, but I don’t want to risk the clones being struck off the list of working tag in the lock’s memory. Real Yale tag #3 is registered with the lock normally, and will be the missus’ key to get into the house.
I also have a full log of the magic Chinese card and my implant (keys and data) in the following states:
1/ Blank (transport configuration)
2/ After cloning (exact clone, byte-to-byte)
3/ After presenting the clone to the lock for registration, but letting the process time out (1st time)
4/ After presenting the clone to the lock for registration, but letting the process time out (2nd time)
5/ After presenting the clone to the lock for registration, completing the registration
6/ After unlocking the door, 1st time
7/ After unlocking the door, 2nd time
8/ After unlocking the door, 3rd time
9/ After unlocking the door, 4th time
10/ After unlocking the door, 5th time
At no point after cloning do the M1k keys change (A nor B, any sector/block). The lock does not rewrite the keys at all, apparently. But interestingly, it does change 3 bytes to in sector 0 / block 2 just by presenting the card for registration, even if the process isn’t carried out all the way:
I’m not sure why it does that. But in theory, it means another lock is able to know that the tag is not entirely “virgin”. What it does with that information, I don’t know.
Once the tag is registered, the lock writes to sector 2 / block 1 (first and only registered lock, out of 6 possible registered locks for a given tag) each time the tag is presented and the lock opens. But again interestingly, at the very first opening, the lock also writes again to sector 0 / block 2:
I assume it’s some sort of flag set by the lock to know the working sector / block has been written to after the first opening, so it rotates the keys - or whatever it does - in there instead of resetting it to the same value over and over as if it was the first opening each time the tag is presented. But I don’t think it needs that to properly “follow” a tag’s encrypted sequence in sector 2 / block 1. So maybe not.
I’ll goof around some more with it when I have time. But at least right now I finally have a friggin’ NFC lock on my door, and that’s something. At long last!
Finally, a thought occurred to me: maybe Iceman’s hacking effort isn’t terribly useful after all: if his ultimate goal is to be able to create cheap-ass tags that work with Doorman locks instead of getting ripped off by Yale for genuine tags, the only thing a lock owner needs is a dump of a genuine, unused tag that hasn’t been registered with their lock yet. Since those things aren’t connected, even if one million locks around the world share the same tag, neither the locks nor Yale would able to know that.
And it’s perfectly secure too: even if my neighbor had a Doorman lock and used a cloned tag based on one of mine, as soon as it’s registered with his lock and one of us uses their tag at least once more than the other, his tag couldn’t be used with my lock, nor mine with his.
So, if a few of us posted, say, a dozen unused Yale tag dumps, each and every Doorman owner in the world could create a dozen cheap tags for themselves with that pool of dumps.
Ergo, no need for hacking. Unless of course the hacking effort is for its own sake - for the beauty of it - which is a perfectly valid justification also
I also got my lock up and running.
Tell me @Rosco do you trigger the lock on the * button to det a read on your x-series, my lock is even tricky to get the read on the original tags sometimes😅
I’ll have a go today or tomorrow for fi ding the sweetspot
The scans that you want u can provide 2-3 of these as long as I can get it without a proxmark, my acr122u might get the trick done?
As far as I could tell doing experiments at the hardware store with the RF diagnostic card, the keypad is used strictly for keycode entry and for configuration. It has zero interaction with the NFC reader during normal operations. In other words, punching a key won’t wake it up or force it to perform a read at full power - which is exactly what I tried to find out when I experimented with it at the hardware store, when I still thought my implant couldn’t wake it up on its own. Turning the handle won’t wake it up either.
The original tags aren’t exactly hard to read, but they need to be right up against the reader. The issue comes from the RF pings that the reader sends out every second to sense if a tag is present: they’re much weaker than the RF field generated for actively reading or writing. The reason why the reader’s range feels so bad is because it is during the tag discovery phase.
You’ll probably find it at or very close to the very center of the reader, where the embossed NFC logo is. Don’t bother trying to find it at the edge of the reader, like you normally would on a desktop reader: for some reason it’s not there.
You’ll have to “make a fist” to get your chip to poke out as much as possible, and you’ll have to ram your hand real good against the reader to stand a chance to trigger the lock. If your chip is implanted a little too deep, it might even fail to work altogether. That’s how finicky it is. But if you do manage to trigger it, very soon you’ll be able to perform the trick repeatedly quite reliably.
Also, when you look for the sweet spot, give it a second or two, because like I said, the lock only sends out a discovery ping every second.
You can find the keys with an ACR122. There are a couple utilities for Linux that do that (mfcuk comes to mind). Then getting a dump is doable too. But I’m not too sure you can reprogram a magic Chinese tag - sector 0 and all - with that hardware. You should be able to, but I’ve never tried.
I don’t need anymore dumps for the moment though. I have mine to peruse and try to make sense of right now. But at some point I’ll do some change-react testing with the magic Chinese card, and most likely that’ll “burn” a tag after each failure. So I’ll need some more “virgin” tag dumps to continue testing.
I think I should be okay, it’ll be fun to see how it works with the xM1vs. flex vs. Original😮
I’ll try to get a few dumps of my virgin cards and save them
That’s a floater
Yeah, you should be okay with that one.
In the spirit of “video or it didn’t happen”, here’s a video of me unlocking my Yale Doorman V2N door lock with my implant:
Your front door opens out??
Hmm yes. What’s so odd about it?
Like most Finnish houses, mine has an eteinen - a heated vestibule or entrance hallway in which you leave your shoes, your cold clothes and whatever snow or grime you picked up outside behind. My house is small, and so is the eteinen. So if the door opened inward, it would waste a lot of space.
At least in the states, most doors open inward. Which makes them very easy to kick down, unfortunately
I have a small hallway at my place too. I don’t like wearing shoes inside so jackets and shoes get taken off and left there. Mines not heated though
Here in Ireland, and the UK too I think, uPVC doors are the most prevalent for homes and use a multipoint locking mechanism.
edit: which is why I couldn’t get a deadbolt NFC lock
The doors open outwards in Norway too
Med deling with the ACR122U here to copy one of my yale doorman fobs to my xM1
Door lock was installed earlier today, and I can agree with @Rosco, fiddling with this in the Scandinavian winter is no fun for four fingers
I grabbed myself a few extra fobs today too, so I can leave one in the xM1 and one in the M1flex, to see wich one works better over time
I’ve played some more with the test magic Chinese card. I tried to see if I could add a NDEF message / record after the Yale Doorman sectors without invalidating the card with the lock. The idea was to use my implant as a key for the lock, and also as a business card that vanilla cellphones could read.
That didn’t go very far: I replaced sector 0 key A with a0a1a2a3a4a5 (the default public key to access the mifare classic’s MAD), and left everything else intact. That immediately disabled the card as a key. The good news is, the lock didn’t strike the card off its memory based on the UID alone: I rewrote the original Yale sector 0 key A and the card started working again.
In any case, it looks like the Yale Doorman uses sector 0 / blocks 1 and 2 for its own purposes, completely subverting the Mifare MAD mechanism. So even if the card had worked with the default public key, I probably couldn’t have written a valid MAD to point to a NFC Forum NDEF message. Yale apparently uses sector 0 / block 1 to store a unique but immutable proprietary key, and the 3 first bytes of sector 0 / block 2 to store flags.
So, screw that idea. It looks like I’m gonna have to implant a new chip to share NDEF records with other people Fuck Yale…
Also, I have another idea to unlock my Yale Doorman with my EM4xxx (LF) implant: install the YL-119 remote control receiver module in the lock, get a YL-120 keyfob and a DT xEM Access Controller, one resistor and one 3V zener diode, and activate the fob with the xEM Access Controller.
It’s an expensive proposition though: we’re talking EUR 69.90 for the receiver, EUR 69.00 for the fob, and $24 for the xEM Access Controller - not to mention the insane price of the Yale Doorman lock itself. That make for a pricy dual-frequency NFC / RFID door lock. But… I have all the parts, and I’m almost ready to fire up the ole soldering iron
I’m a firm believer in “there are no stupid questions”
So I shall, being very ignorant of this level of RFID tinkering, ask a possibly dumb question.
Are you writing the Yale key AND THEN writing the business card info?
Is there a way to compile the two together and then do a single write to the implant? possibly avoiding an overwriting of dependent sectors?
Well it doesn’t matter how you write things to the tag. What’s important is that the lock doesn’t throw a fit when it sees an unusual data structure on it, and cellphones recognize it as a valid NDEF message bearer.
In this case, I started off with a valid Doorman tag and tweaked a sector a bit. I could also have wiped it and written an entire, suitably doctored dump. The end result would have been the same.
But that case of dual use with a Doorman tag ain’t gonna happen - unless you build your own compatible app for the second use, which is perfectly doable. Like if you want to use the remaining sectors to store personal data or something.