Ok we can see the tag 2 training is failing at the read block 4 stage. It doesn’t even bother with the password.
This might be more complicated.
What is the value of block 4 on each tag. It might also be some sort of derivation scheme that requires specific data be programmed in that block per UID. It means more brute forcing unfortunately.
After personally examining one of these locks, their NFC version specifically, the only way would be to brute force the pwd ack. This means using a proxmark3 to do emulation and run a lua script through all the possible combinations. You’d also need some way to detect success, like a computer vision system to watch for a green LED vs red.
The pwd ack is only 2 bytes so it would only take testing 65536 values to arrive at a solution… but once a few are cracked I think the derivation scheme could be discovered.
To be clear we just need someone familiar with lua scripting for proxmark to create a way to break and clone stuff for mo-lock NFC. The hurdle right now is just a two byte PWD_ACK response from the chip and I think we can get a script together that will let either me or the public at large create the correct response for their xSIID, NExT, or xNT to work with mo-lock NFC.
vielen Dank für deine Anfrage. So gerne ich dir an dieser auch Stelle helfen würde,
es ist uns leider nicht möglich, auf derartige Kundenwünsche einzugehen. Ich selbst
finde dein Vorhaben sehr interessant und würde es begrüßen, dich in dem Vorhaben
zu unterstützen - aber leider sind mir durch die Entwicklungsabteilung an der Stelle
die Hände gebunden. Tut mir wirklich sehr leid.
Just to clarify how this is working when you try to enroll (and use) a new legit NFC chip;
Lock reads chip UID
Lock reads block 4 (the first user mem page)
If expected data is there, lock sends calculated password (visible in sniff)
Tag responds to PWD_AUTH with PWD_ACK
The problem here is that both the PWD_AUTH password and PWD_ACK are calculated values (aka derived keys) that a programmer sets on the tags before shipping. The good news is, because there is no secure channel for NTAG2x chips, we can get the calculated password from the reader itself. Frankly I don’t know why they bother to even randomize this, but whatever.
So, all we need to do is figure out how the PWD_ACK is calculated, or we need to just create a brute force LUA script to allow NFC implants to be programmed with the expected correct PWD_ACK for mo-lock locks.
In testing my own small set of 4 legit tags, I found something interesting…
The ACK for 2 tags are identical, and the ACK for the other 2 are also identical.
I did try to enroll another transponder with a set pwd based on lock output with both of those ACK values but it didn’t work… however that lead me to notice something else. The UIDs of the tags I have are very close together, meaning they probably came off the safe serialized wafer. I would bed the algorithm used to derive the ACK values is rather simpllistic given the difference in bytes between all 4 UIDs is small.
If we can continue to add to this list through sniffing, it might become possible to crack the derivation scheme.
Failing that, I would take a LUA script that just brute forces the PWD_ACK (it’s only two bytes after all) and set about pre-programming a bunch of xNT chips as “mo-lock compatible” and ship them with the PWD and PWD_ACK values so it could be re-programmed at will by the owner.
Just as a side note… unless it wasn’t clear, this situation perfectly illustrates to me how a security mechanism is only as secure as its weakest link. In this scenario, the password length of NTAG2xx chips is 4 bytes (32 bits), however because the communication channel the chips use is not secured, we are really left with a 2 byte security mechanism in the PWD_ACK response… and that might not even be a consideration for some implementations which would basically ignore the ACK value as long as the PWD_AUTH command returned successfully.
That makes it pretty clear that brute forcing the PWD_ACK response with a script shouldn’t be all that difficult… i just don’t know LUA well enough to write the script. Let’s break it down…
Interestingly, Iceman made a video a couple months ago about how to use the pm3 client using python, lua, c, and others. I might try to do it in python, unless there is some reason you know of that it needs to be in lua??
The thing that needs to happen is being able to control the emulation mode such that the emulated tag can appear and disappear from the reader field between attempts.
The other thing that will be needed is probably some kind of simple machine vision method that points a camera at the lock’s LED and looks for a green color blink, then takes a screenshot of the script to get the PWD_ACK being used.
Anyone know any very simple open source libraries that can do simple color detection in real-time and launch some sort of command line executable that can do the screen capture and save it to a jpg or whatever?
Need a script that displays the PWD_ACK being tried
Need a computer vision thing to watch for a green success light
Need a simple until that runs and saves a screenshot to an image file
Just for my understanding how did u get/ wher to find the ACK value?
im still learning just try to unterstand… unfortunately my knowledge isnt enough to help whit any of this.