The ACK is sent to the reader from a legit chip after a legit pwd_auth from the reader. In the sniff, data you see at the bottom the last PWD_AUTH KEY and then a response from the tag of 4 bytes… the first two bytes are the PWD_ACK and the last two bytes are at 16 bit parity / crc for the data packet.
In your case, the UID with PWD of 51995E63 has a PWD_ACK of 4c02… so if we look at your two relevant sniff logs, our list becomes;
Ok so the computer vision part seems pretty straightforward;
Python has libraries that can capture the screen as well;
So I guess Python is the answer… we just have to now find a way to control the proxmark3 to reliably;
initiate emulation of an NTAG21x with;
a specific UID
specific data in page 4
a specific password to handle PWD_AUTH from the reader
a PWD_ACK returned to the reader we can update each iteration
end emulation to “remove” the tag from the reader field
… and do it quickly.
The only question I have right now is - can the proxmark emulate the PWD_AUTH function of an NTAG21x tag and respond with a specified PWD_ACK value? @iceman is this possible with current firmware?
Dunno what yall trying to solve but you would use some kind of combo from the following, its not optimized to do this. I can see a hf mfu eset to to be useful
hf 14a sim -t 7 ( supports MIFARE_ULEV1_AUTH ) hf mf eset ( to update parts of emulator memory ) hw break ( to break out of simulation from client side )
Then I tried to set emulator memory starting with block 0 to match using hf mf eset -b 0 -d 049cb7a76aba109050480000e1101200 and then started emulation.
Unfortunately when reading, it did not read any UID or changes memory?
Instead of the computer vision, you could probably use an arduino with a color sensor. Could even get away with a photosensor if it has a single color led. It would be easy to have the arduino emulate a keyboard so it could stop the script when it hits the right key. (Or even have it type in the commands itself)
possibly! but the lock has a single led that blinks red or green or stays blue between. might be hard to tell the difference with a simple photosensor… and a color sensor is just like . a webcam
If you’re going to get a microcontroller involved, you might as well solder a few cables to the pins of the LED and skip the light sensor altogether. If the thing is not potted, of course.
However, I’m still not sure if the sim / emulator is capable of emulating password functions. The reader is going to send a PWD_AUTH command (0x1b) followed by 4 bytes (the password). The emulator must respond with PWD_ACK which is what we are trying to bruteforce here.
@iceman do you know who is working on the emulator code for the hf 14a sim command? Ooooorrr… is it maybe possible to handle lower level stuff like emulating support for the PWD_AUTH command with a LUA script?
So the next trick is to try to figure out how to set the emulator password (PWD) and password acknowledgement (PWD_ACK). These are both stored in memory pages… but since the SIM command -t 7 supports only NTAG215, those pages are 85 and 86;
However, because the hf mf eset command requires 16 bytes, we have to start at page 83. Sadly, I set those memory pages but I do not get back the expected PWD_ACK;
I reached out to the iceman discord … we’ll see if anyone has ideas. I think what we will need is some modification to the sim code base to support changing PWD_ACK responses to PWD_AUTH commands, and perhaps still a LUA script for automating the whole process
Yes but the bigger issue is that the sim code (emulator code) doesn’t currently output anything for PACK other than 00 00. In short, you can’t emulate PACK it’s always 00 00.
I have been able to in testing by dumping a tag which has a non-zero PACK
I can hack something together in python which edits and re-loads a dump file with a new PACK, but I think it would not be a quick process to go through all the numbers…
Not just because brute-forcing is inherently slow, but because the method of PM3 python scripting I’ve used in the past is hecca un-optimized
