EM4170 Listen Window detected, but no response from tag

sirloins · 2020-11-30 22:02:57

Hi guys,

I thought I would create a new topic for this work. I know other people have gotten this tag working, and it is very similar to the existing em4x05 that is implemented.

The key differences seem to be:

* 32 RF period clock instead of 64 (actually em4x05 can do both 32 or 64, just only 32 is implemented).
* Command is 3 bits instead of 8. 4 bits including the parity.
* Does not send any data when in field, only constant LIW (listen windows).

So I created a bunch of new files, and compiler options similar to the 4x05 but for the 4170. So now I have a em4170_info command I can play with. I also converted the entire thing to use the new "Ticks" API.

First, I logged the duration of 1's and 0's to get an idea of the listen window, something like this:

Duration - Value
[#] 21 1
[#] 55 0
[#] 34 1
[#] 44 0
[#] 21 1
[#] 56 0
[#] 33 1
[#] 44 0
[#] 21 1
[#] 55 0
[#] 33 1
[#] 45 0

These values are in RF Periods, this is a 125KHz tag, 8us per RF period. 1us == 1.5 ticks. So 8us is 12 Ticks.
Those numbers above are obviously a bit "off", but I think they roughly translate to:
16 high
64 low
32 high
48 low
repeats.

These high/low values are inverted from my understanding, so if we invert them, they match the data sheet for the EM4170 quite well which shows:

16 high
16 low
64 high
32 low <---- Start sending command here
32 high

So I also updated the code that measures the duration between falling/rising edges. The EM4x05 code only looks for the second window period (96 -> 64).

From the data sheet, they recommend doing:

80 +/- 10
80 +/- 10
Invert Edge Detection
96 +/- 10
64 +/-10
Begin sending command after the 32 high period.

So the code from em4x05 seems to mostly do that (although just looking at the 96 and 64 periods, then sends the command after about 64 more RF clocks).

So this tag seems to match everything from the EM4170 data sheet + App note so far. The issue I am having is when trying to send it a command to read the ID.
The data sheet shows sending the RM (two 0's) then send the 4 bit command (including parity) of 0 0 1 1. I send that, and then run the loop again that recording the time periods for 1's and 0's but I end up just seeing the LIW windows.

1. LIW command sent at wrong time, I have tried varying the time at which I send the RM and command to the tag with no change.

2. Perhaps my antenna is not good enough? I have the RDV4 without the Q switches at the back. The tag is a glass pill type (transponder) that I have placed directly on the antenna. I get good results seeing the LIW periods but maybe it is not good enough to send commands?

3. Maybe this tag is slightly different, and my command is wrong.

I've purchased a new antenna that seems to be meant for those transponders people install in their body. It should work better with this small tag I think. So that should take care of #2.

As for #1, I have tried running a loop that sends the command at different parts of the LIW and records the results, no change though.

For #3, I have also tried the 0 1 0 1 Read UM-1 command, but I have not tried any longer commands.

sirloins · 2020-12-04 06:45:00

Alight, seems pretty empty here (or my post was a bit overwhelming maybe?)

I purchased another LF antenna to rule that out. The ProxLF antenna, meant more for implants I think, but the transponder I have is one in a glass tube as well (so small antenna).

Anyway, I found out that the antenna is not really my issue.

I decided to take it one step at a time, maybe this will help other people with different tags.

I had code that found the listen window. I then made a loop to basically send the first 0 in the RM command (go into receive mode), and timed how long after that the listen windows started back up again. If you send the 0 at the right time, then the RFID will not send data for some amount of time. I found the correct time to send this command by looping through maybe 0->128 RF periods. The best result I had was waiting for 1 full tag period (32 rf periods).

Then basically I did the same thing to try and figure out what commands I can send. Since I knew this tag was close to the EM4170, I looped from 0000b to 1111b testing all the commands. After each test command, I again measured the next 30 pulse durations. I printed these out and it was easy to see which commands send the 12 manchester encoded 1's versis the tag just going back into standby mode (sending the listen window).

I have a list of commands now, and so far this is what I have:

0000 Read ID
0001 Read UM1
0100 Read UM2
0011 Authenticate/Send crypt key

I could be wrong of course, but I manually verified that Read ID was returning the ID from my tag. The length of data returned by the other commands seem to match. UM2 is 64 bits, and Authenticate expects 56 bit key.

Send PIN and Write Word I am not sure of yet.

So the next step for me is to implement the read command correctly and hopefully print non-binary numbers.

My planned contribution will be to read and write the tag. I think the Authentication part can be a different project on its own.

Note: I've been calling this EM4170, but I think this can be called some kind of em4170 derivative. Most of the stuff is the same, except the commands themselves. Specifically, this tag is from a 2005 Volvo which has Megamos on the keyfob PCB.

Last edited by sirloins (2020-12-04 06:54:46)

iceman · 2020-12-04 08:30:26

Well done,
Some fine learning going on.
if you have the datasheet then it helps when figuring out some sense in your tag readings.
So you think megamos is a EM4170 derivative?

And pass by the discord server for faster interactions.

sirloins · 2020-12-04 14:22:48

Thanks,

I was trying to join the discord, but so far every link I have tried says expired.

The first paper I had read regarding this was "Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobilizer"

They mention that there are two types of Megamos used in the list of vehicles they have. Magic I based on the V4070 and Magic II based on the EM4170. Some sites seem to refer to this as the ID48 transponder when looking for buying blank ones for the same vehicle.

So I could still be out to lunch, and the only reason I am seeing different commands than the datasheet is that I am doing something wrong, but so wrong that it works.

The two things that kind of threw me off at first was the data sheet showing non-inverted signal, and the proxmark I believe having inverted raw readings (or at least the interpretation from the em4x05 code). I think this is also the reason some of the papers claim the listen window is different than the EM4170, where I found it was exactly the same.

Really the best help to me was the em4x05 code that was already written, as well as comparing the em4170 datasheet to the em4150 while modifying the code.

If anyone else is interested in the documents that helped me so far:

https://www.cs.bham.ac.uk/~garciaf/publ … Crypto.pdf

https://www.emsec.ruhr-uni-bochum.de/me … thesis.pdf Page 264

https://m.eet.com/media/1150096/22897-45988.pdf

https://www.digchip.com/datasheets/down … ber=EM4170

https://pdf1.alldatasheet.com/datasheet … M4150.html

Last edited by sirloins (2020-12-04 14:24:42)