I recently got my hands on a new model “Mo-lock NFC”. They are now using an NTAG213 instead of the T5577 in the older models. This is one of the keys that came with mine:
[usb] pm3 --> hf search
🕕 Searching for ISO14443-A tag...
[+] UID: 04 DC 63 1A BA 10 90
[+] ATQA: 00 44
[+] SAK: 00 [2]
[+] MANUFACTURER: NXP Semiconductors Germany
[+] Possible types:
[+] MIFARE Ultralight
[+] MIFARE Ultralight C
[+] MIFARE Ultralight EV1
[+] MIFARE Ultralight Nano
[+] MIFARE Hospitality
[+] NTAG 2xx
[=] proprietary non iso14443-4 card found, RATS not supported
[?] Hint: try `hf mfu info`
[+] Valid ISO 14443-A tag found
[usb] pm3 --> hf mfu info
[=] --- Tag Information --------------------------
[+] TYPE: NTAG 213 144bytes (NT2H1311G0DU)
[+] UID: 04 DC 63 1A BA 10 90
[+] UID[0]: 04, NXP Semiconductors Germany
[+] BCC0: 33 ( ok )
[+] BCC1: 20 ( ok )
[+] Internal: 48 ( default )
[+] Lock: 00 00 - 0000000000000000
[+] OneTimePad: E1 10 12 00 - 11100001000100000001001000000000
[=] --- NDEF Message
[+] Capability Container: E1 10 12 00
[+] E1: NDEF Magic Number
[+] 10: version 0.1 supported by tag
[+] : Read access granted without any security / Write access granted without any security
[+] 12: Physical Memory Size: 144 bytes
[+] 12: NDEF Memory Size: 144 bytes
[+] 00: Additional feature information
[+] 00000000
[+] xxx..... - 00: RFU ( ok )
[+] ...x.... - 00: don't support special frame
[+] ....x... - 00: don't support lock block
[+] .....xx. - 00: RFU ( ok )
[+] .......x - 00: IC don't support multiple block reads
[=] --- Tag Counter
[=] [02]: 00 00 00
[+] - BD tearing ( ok )
[=] --- Tag Signature
[=] IC signature public key name: NXP NTAG21x (2013)
[=] IC signature public key value: 04494E1A386D3D3CFE3DC10E5DE68A499B1C202DB5B132393E89ED19FE5BE8BC61
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: D4C8E4D94AF055A1708440B0CE28E420FE9A2E512C5B9C5FF37ED21CD5F922FC
[+] Signature verification ( successful )
[=] --- Tag Silicon Information
[=] Wafer Counter: 19011395 ( 0x1221743 )
[=] Wafer Coordinates: x 220, y 99 (0xDC, 0x63)
[=] Test Site: 2
[=] --- Tag Version
[=] Raw bytes: 00 04 04 02 01 00 0F 03
[=] Vendor ID: 04, NXP Semiconductors Germany
[=] Product type: NTAG
[=] Product subtype: 02, 50pF
[=] Major version: 01
[=] Minor version: 00
[=] Size: 0F, (256 <-> 128 bytes)
[=] Protocol type: 03, ISO14443-3 Compliant
[=] --- Tag Configuration
[=] cfg0 [41/0x29]: 04 00 00 10
[=] - strong modulation mode disabled
[=] - page 16 and above need authentication
[=] cfg1 [42/0x2A]: 18 05 00 00
[=] - Unlimited password attempts
[=] - NFC counter enabled
[=] - NFC counter password protection enabled
[=] - user configuration writeable
[=] - write access is protected with password
[=] - 05, Virtual Card Type Identifier is default
[=] PWD [43/0x2B]: 00 00 00 00 - (cannot be read)
[=] PACK [44/0x2C]: 00 00 - (cannot be read)
[=] RFU [44/0x2C]: 00 00 - (cannot be read)
[+] --- Known EV1/NTAG passwords
[!] ⚠️ password not known
[?] Hint: try `hf mfu pwdgen -r` to get see known pwd gen algo suggestions
[=] ------------------------ Fingerprint -----------------------
[=] Reading tag memory...
[=] ------------------------------------------------------------
It recognizes my NeXT but won’t let me register it (it blinks an “invalid card” error when I try to train it). I’m hoping someone can help figure it out.
I scanned an Apex Flex with my ACR1252U on Windows and it’s a lot because Windows will attempt to probe the hell out of it… but you should get a nice output;
I really hope you solve this. I got my bike back yesterday after the crash repairs and an nfc ignition is way up at the top of my wish list. I want to be a cyborg centaur!
Yeah it looks like password checks… but I don’t see any tag data. How are you sniffing? The proxmark3 hf antenna should be right up against the reader and the tag should be right up against the proxmark3. You could tape the tag to the pm3 and present the whole thing to the reader at the same time while sniffing.
So… the question is… did they use the same password for every fob or did they use a derivation system based on the UID… if they used the derivation system you would get a different password for a different tag.
At this point I would present a different working fob and see if the password check changes. If it does, then you can get the password for your non-working NExT by sniffing the registration process. If it’s the same password for both working fobs then just change the password on your NExT to FB 78 7D D0 and try to register it.
[usb] pm3 --> hf search
🕓 Searching for ISO14443-A tag...
[+] UID: 04 5D EA 6A BA 10 90
[+] ATQA: 00 44
[+] SAK: 00 [2]
[+] MANUFACTURER: NXP Semiconductors Germany
[+] Possible types:
[+] MIFARE Ultralight
[+] MIFARE Ultralight C
[+] MIFARE Ultralight EV1
[+] MIFARE Ultralight Nano
[+] MIFARE Hospitality
[+] NTAG 2xx
[=] proprietary non iso14443-4 card found, RATS not supported
[?] Hint: try `hf mfu info`
[+] Valid ISO 14443-A tag found
ON:
[usb] pm3 --> hf 14a list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 560 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 1056 | Rdr |26(7) | | REQA
2228 | 4596 | Tag |44 00 | |
30752 | 35520 | Rdr |50 00 57 cd | ok | HALT
202448 | 203440 | Rdr |52(7) | | WUPA
204676 | 207044 | Tag |44 00 | |
243040 | 245504 | Rdr |93 20 | | ANTICOLL
246692 | 252580 | Tag |88 04 5d ea 3b | |
297712 | 308176 | Rdr |93 70 88 04 5d ea 3b 20 9c | ok | SELECT_UID
309412 | 312932 | Tag |04 da 17 | ok |
345760 | 348224 | Rdr |95 20 | | ANTICOLL-2
349396 | 355220 | Tag |6a ba 10 90 50 | |
400400 | 410928 | Rdr |95 70 6a ba 10 90 50 35 1f | ok | SELECT_UID-2
412116 | 415700 | Tag |00 fe 51 | ok |
489488 | 494256 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
552788 | 573588 | Tag |04 5d ea 3b 6a ba 10 90 50 48 00 00 e1 10 12 00 98 f0 | ok |
606928 | 611632 | Rdr |30 04 26 ee | ok | READBLOCK(4)
612884 | 633748 | Tag |6d 6f 74 6f 67 61 64 67 65 74 2d 6b 65 79 30 30 6a 04 | ok |
663088 | 671312 | Rdr |1b 69 ef 1f ef bb d9 | ok | PWD-AUTH KEY: 0x69EF1FEF
672484 | 677156 | Tag |6f 03 a6 ca | ok |
6190256 | 6191312 | Rdr |26(7) | | REQA
6192484 | 6194852 | Tag |44 00 | |
6220992 | 6225760 | Rdr |50 00 57 cd | ok | HALT
6393056 | 6394048 | Rdr |52(7) | | WUPA
6395300 | 6397668 | Tag |44 00 | |
6433536 | 6436000 | Rdr |93 20 | | ANTICOLL
6437188 | 6443076 | Tag |88 04 5d ea 3b | |
6488080 | 6498544 | Rdr |93 70 88 04 5d ea 3b 20 9c | ok | SELECT_UID
6499796 | 6503316 | Tag |04 da 17 | ok |
6536000 | 6538464 | Rdr |95 20 | | ANTICOLL-2
6539652 | 6545476 | Tag |6a ba 10 90 50 | |
6590544 | 6601072 | Rdr |95 70 6a ba 10 90 50 35 1f | ok | SELECT_UID-2
6602244 | 6605828 | Tag |00 fe 51 | ok |
6679184 | 6683952 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
6742468 | 6763268 | Tag |04 5d ea 3b 6a ba 10 90 50 48 00 00 e1 10 12 00 98 f0 | ok |
6796656 | 6801360 | Rdr |30 04 26 ee | ok | READBLOCK(4)
6802612 | 6823476 | Tag |6d 6f 74 6f 67 61 64 67 65 74 2d 6b 65 79 30 30 6a 04 | ok |
6852816 | 6861040 | Rdr |1b 69 ef 1f ef bb d9 | ok | PWD-AUTH KEY: 0x69EF1FEF
6862212 | 6866884 | Tag |6f 03 a6 ca | ok |
OFF:
[usb] pm3 --> hf 14a list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 280 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 1056 | Rdr |26(7) | | REQA
2228 | 4596 | Tag |44 00 | |
30784 | 35552 | Rdr |50 00 57 cd | ok | HALT
202272 | 203264 | Rdr |52(7) | | WUPA
204516 | 206884 | Tag |44 00 | |
242720 | 245184 | Rdr |93 20 | | ANTICOLL
246356 | 252244 | Tag |88 04 5d ea 3b | |
297264 | 307728 | Rdr |93 70 88 04 5d ea 3b 20 9c | ok | SELECT_UID
308964 | 312484 | Tag |04 da 17 | ok |
345136 | 347600 | Rdr |95 20 | | ANTICOLL-2
348772 | 354596 | Tag |6a ba 10 90 50 | |
399680 | 410208 | Rdr |95 70 6a ba 10 90 50 35 1f | ok | SELECT_UID-2
411380 | 414964 | Tag |00 fe 51 | ok |
488304 | 493072 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
551588 | 572388 | Tag |04 5d ea 3b 6a ba 10 90 50 48 00 00 e1 10 12 00 98 f0 | ok |
605712 | 610416 | Rdr |30 04 26 ee | ok | READBLOCK(4)
611652 | 632516 | Tag |6d 6f 74 6f 67 61 64 67 65 74 2d 6b 65 79 30 30 6a 04 | ok |
661888 | 670112 | Rdr |1b 69 ef 1f ef bb d9 | ok | PWD-AUTH KEY: 0x69EF1FEF
671284 | 675956 | Tag |6f 03 a6 ca | ok |
The range on these fobs is really surprising.
So not a fixed pwd. If it’s generated based on the UID, I’m thinking we’d need more than two samples to reverse engineer it… Hopefully you see something I don’t
Yes it appears to be a derived password. But, don’t think we need to reverse engineer the password. The reader should give us the password during registration of a new chip. This is because it’s clear the registration process is checking for the password during registration, and because the protocol between chip and reader is not encrypted, we get to sniff that password.
However, there is another factor here which is the password acknowledgement passed back on successful password authentication. That appears to be different for each as well. This may be somewhat difficult to derive because it’s what the tag sends back and the reader will not reveal this… and it does appear that each good tag does have a unique ack. The ack is only two bytes though so it may be easy enough to brute force that with a lua script and continuous registration attempts.
Yeah so now the fun starts… either the method for calculating the pwd ack needs to be reverse engineered, or it needs to be brute forced.
To brute force it you may need to create a script that is quite involved. My guess is the script will need to be able to control tag emulation (turn it on and off) and you’ll need to probably screen record as the proxmark3 is running through the registration process and emulating different pwd ack responses (assuming it can do this). At the same time you’ll need to probably have a video feed on the lock to detect different LED patterns for successful registration vs invalid registration… and record audio to hear the tone differences as well.
We’re now stepping firmly outside my comfort zone unfortunately. I’ve never actually made a lua script and I’m not even sure the current proxmark3 firmware can do what’s necessary.
For a one-time thing, I should be able to “just” write a script that can send the ack bytes in sequence until one works, right? All the rest is just to make it automated and repeatable for the future? Let’s say I find the needed ack bytes, how would I teach the NeXT to respond with it?
I have a HuskyLens (computer vision module) currently hooked up to a raspberry Pi… I think I can rig it to watch for a blue light and take a photograph when it detects it… So if the script tried each combo and output it to a display, I could capture the successful bytes… But I’m not sure how I would broadcast the my next ID and bytes.
It’s two bytes… That’s only 10,000 possible combinations give or take two . If I manually do one every 10 seconds thats… Erm… two bottles of scotch? 28 hours of active work time… That’s dumb brute force, but… It’s a thing… I guess…
Yeah maybe… I’m not sure if there is a max failure counter in the registration process or not. If not then yeah just go to town on it.
If you can do blue light detection great but I was thinking more simply like obs to record your screen and a webcam zoomed way in on the blue light so it takes up nearly all the screen and put the webcam on your obs scene really big so you can capture the script output and the led status in one video.
Could possibly use post processing to detect when the blue light shows or there may also be some other software like a color picker thing that can do the same detection on the computer and screen cap when it goes blueish. Dunno.
If your pi cam solution can capture the screen output as well in the same photo so you can read which ack worked, that’s fine too
and I’m not sure if it is idempotent, but here’s the output when I train Tag 1 and get the blinking green 'success" light. This might be “successfully trained” or it might be “tag already exists”, I suppose.
[usb] pm3 --> hf 14a list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 280 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 1056 | Rdr |26(7) | | REQA
2228 | 4596 | Tag |44 00 | |
30720 | 35488 | Rdr |50 00 57 cd | ok | HALT
202032 | 203024 | Rdr |52(7) | | WUPA
204260 | 206628 | Tag |44 00 | |
242464 | 244928 | Rdr |93 20 | | ANTICOLL
246100 | 251924 | Tag |88 04 dc 63 33 | |
297024 | 307488 | Rdr |93 70 88 04 dc 63 33 8c 1d | ok | SELECT_UID
308740 | 312260 | Tag |04 da 17 | ok |
344976 | 347440 | Rdr |95 20 | | ANTICOLL-2
348628 | 354516 | Tag |1a ba 10 90 20 | |
399552 | 410080 | Rdr |95 70 1a ba 10 90 20 41 79 | ok | SELECT_UID-2
411252 | 414836 | Tag |00 fe 51 | ok |
488352 | 493120 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
551636 | 572436 | Tag |04 dc 63 33 1a ba 10 90 20 48 00 00 e1 10 12 00 89 5c | ok |
605728 | 610432 | Rdr |30 04 26 ee | ok | READBLOCK(4)
611684 | 632548 | Tag |6d 6f 74 6f 67 61 64 67 65 74 2d 6b 65 79 30 30 6a 04 | ok |
661888 | 670112 | Rdr |1b fb 78 7d d0 ef 94 | ok | PWD-AUTH KEY: 0xFB787DD0
671300 | 675972 | Tag |4c 02 74 d2 | ok |
[usb] pm3 -->
. If I manually do one every 10 seconds thats… Erm… two bottles of scotch? 28 hours of active work time… That’s dumb brute force, but… It’s a thing… I guess…