Interesting. There are only two bytes we are dealing with here, so I don’t mind if it takes a few days even… but I seriously doubt it will take that long to run through 16 bits of entropy… 65536 different values… I think the actual lock registration process is going to be the bottleneck not the script. Let’s assume 3 seconds per registration attempt… it would still only take an absolute maximum of 2 and 1/2 days to arrive at the solution.
I’ll give it a go
Don’t have one of these locks though, so I can’t test the actual functionality
Is there a command in the traces which only occurs after a successful (or non-successful) authentication as far as we can tell?
Then I can probably have it attempt to auto-detect a successful PACK… maybe…
In the meantime, here’s a script that just iterates from 0000 to FFFF at about one per second (which can be slowed down if necessary):
molock.py (1.4 KB)
Pre-flight checklist:
pm3
should be installed in the terminal the script is running in- Dump the tag you’re interested in testing, copy the dump.json file to the same directory as the script and rename it
pack.json
2a. Only made to work with I2C Plus and NTAG 213/215/216 tags - Made for a linux environment, so those pre-compiled windows binaries won’t work probably
Creates a temp.json
where all the rewrite shenanigans happen, can be deleted afterwards
Nope this is for registration so the plan is to set up a machine vision application to look for a green LED response from the lock vs red haha
“not a quick process”
It’s been a “some day…” project of mine for almost two years that I’ve never gotten around to. As long as it eventually ends, you will have beaten my record