Good news for mo-lock (aftermarket motorcycle nfc ignition) folks?

Support
37

hm. But when I try what he did, I get

$ ./02run_test.sh 
Traceback (most recent call last):
  File "/home/miststlkr/workspace/proxmark3/client/experimental_lib/example_py/./test.py", line 3, in <module>
    import pm3
  File "/home/miststlkr/workspace/proxmark3/client/pyscripts/pm3.py", line 15, in <module>
    import _pm3
ImportError: /home/miststlkr/workspace/proxmark3/client/experimental_lib/example_py/_pm3.so: undefined symbol: bf_generate

It’ll need some poking, but it look promising based on his video.

2 Likes
38

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.

2 Likes
39

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
2 Likes
40

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.

List

Summary 
UID            PWD      ACK
----------------------------
049cb76aba1090 0825CFE0 6f03
045dea6aba1090 69EF1FEF 6f03
04097a1aba1090 68AF0B95 4c02
04dc633aba1090 FB787DD0 4c02
04da171aba1090 51995E63 ????
0495701aba1090 0FDF4B2E ????
41

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;

UID            PWD      ACK
----------------------------
049cb76aba1090 0825CFE0 6f03
045dea6aba1090 69EF1FEF 6f03
04097a1aba1090 68AF0B95 4c02
04dc633aba1090 FB787DD0 4c02
04da171aba1090 51995E63 4c02
0495701aba1090 0FDF4B2E 4c02
42

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?

2 Likes
43

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 )

2 Likes
44

Thanks!

In testing this, I took an NTAG213 fob from the mo-lock NFC product and read it in TagInfo to get memory contents.

image
image945×2048 273 KB

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.

image

Unfortunately when reading, it did not read any UID or changes memory?

image
image945×2048 269 KB

1 Like
45

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)

1 Like
46

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 :wink:

2 Likes
47

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.

48

You could just use the 12v output from the mo.lock

Yes this won`t work :face_with_peeking_eye:

1 Like
49

i don’t think this works because successful enrollment does not trigger 12v out (i don’t think?) does it?

2 Likes
50

it’s potted like a concrete brick

2 Likes
51

ok i got this part figured out…

image
image703×78 4.55 KB

results in…

image
image945×2048 267 KB

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?

2 Likes
52

I would have to set mine back up to verify, but I’m 99% sure enrollment did not trigger the relay, only the light.

1 Like
53

Ok!! Actually with a little more testing I answered at least some of my questions…

image
image256×555 16.3 KB

I was able to use NFC Shell on my phone to send in a test password, and I got an ACK back! The default ACK is 0x00 0x00 so this is great news!

The trace from emulation also shows the interaction;

image
image1242×953 47.7 KB

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;

image
image1045×610 72.5 KB

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;

image
image707×118 5.33 KB

image
image1205×116 7.45 KB

The emulator still returns a PWD_ACK of 00 00.

So I guess the question I still have is… can the PWD_ACK be manipulated at all for type 7 simulations with the current code?

3 Likes
54

Amazing progress, you are frankly blowing my mind here. I have so much to learn about RFID/NFC protocols.

2 Likes
55

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

2 Likes
56

Difference between hex and decimal…

Easy to forget.

1 Like