[Solved] Schlage HID fob cloned but not working

theguy · 2019-08-12 21:44:03

I successfully cloned a Schlage HID fob, but the cloned tags won't open the door.

What more do these little grey/gray Schlage key fobs have beyond the HID tag?

Last edited by theguy (2019-08-29 04:18:26)

iceman · 2019-08-12 21:55:43

Too little information to answer the question.

theguy · 2019-08-12 22:43:36

hf search yields nothing, lf search yields exact same HID card for the original that works and the clone that doesn't.

Im exploring lf t55 dump and things seem both bitshifted and different. What can I offer to help diagnose?

Lock is this model: https://www.schlage.com/content/dam/sch-us/documents/pdf/Schlage-Control-Smart-Deadbolt-Sell-Sheet.pdf

Last edited by theguy (2019-08-12 22:50:59)

iceman · 2019-08-12 23:02:10

a HID prox card... and you use what to clone ?

theguy · 2019-08-12 23:11:17

you use what to clone?

Command: lf hid clone ##########

Hardware: A proxmark 3

Software: I tried both the iceman latest and normal latest

Not sure what you mean by what I use to clone.

theguy · 2019-08-13 00:31:30

Reupdated, recompiled, reflashed everything just to check, and now getting this when I run dump in the iceman fork:

And this is a cloned hid card that shows the same info as the original, and shows actual data when I ran lf t55 dump in basic pm3 fork.

Last edited by theguy (2019-08-13 00:32:24)

iceman · 2019-08-13 04:44:51

The lf t5577 commands have their charm. In short, you will need a successful lf t5577 detect first every time you use them.

How about you start with running lf search?

theguy · 2019-08-13 17:37:34

Done that, the lf search finds it successfully, then the dump is always blank, on 4 different tags, the original and 3 of my rewriteable t5577s in 2 different form factors. This blank dump output happens only in the iceman client. If I run regular proxmark client, i get dumps easily, but they appear to be bitshifted, and I'm having a lot of trouble copying block by block. Something will always mess up, for example, page 0 block 1 WON'T bitshift (but the other 6 blocks will), and it won't accept the write of the not-bitshifted data, so I can't copy the blocks effectively by hand. But do you think that's why the Schlage lock is ignoring my otherwise properly-cloned hid tags?

iceman · 2019-08-13 18:12:54

....and what is your exact command sequence when you do this dumping?

theguy · 2019-08-13 18:27:05

One time I saw the original tag having an offset of 33, but I think it was a bitshift fluke. It's usually 32 for both original and clones. I tried setting offset on clone to 33, but that didn't stick.

proxmark3> lf t55 detect
Chip Type : T55x7
Modulation : FSK2a
Bit Rate : 4 - RF/50
Inverted : Yes
Offset : 32
Seq. Term. : No
Block0 : 0x60107C60

proxmark3> lf t55 detect
Chip Type : T55x7
Modulation : FSK2a
Bit Rate : 4 - RF/50
Inverted : Yes
Offset : 33
Seq. Term. : No
Block0 : 0x60107C60

I still can't write correctly to block 1 of page 0. It's always shifting by 1 bit. Every other block is fine.

theguy · 2019-08-13 18:28:07

lf search
lf t55 dump

It works without lf searching first in normal proxmark client. Only the iceman distro is blank when I lf t55 dump, and it's blank whether I run lf search first or not.

theguy · 2019-08-13 18:36:32

Randomly the iceman client just worked, every dump is different, bitshifted -1, 0, or 1 bits. So it looks like my clone is good, but I can't be 100% sure. Some dumps it's matching, others it's not. But now the original gets bitshifted on the lf dump too, so I don't know. Is there another feature to this Schlage reader+lock mechanism that I might be missing?

Seems like playback speed between my clones' block 0 and block 1 is a beat too fast or slow relative to the original Schlage.

Last edited by theguy (2019-08-13 18:41:19)

theguy · 2019-08-14 00:51:15

All clones look like this, and every other block matches original.

Reading Page 0:
00 | 60107C60 | 01100000000100000111110001100000
01 | 3AAAB2AA | 00111010101010101011001010101010

But original, and what I'm writing to the blocks is:

Reading Page 0:
00 | 60107C60 | 01100000000100000111110001100000
01 | 1D555955 | 00011101010101010101100101010101

Again, all the other blocks match. It's just this bitshifty block 1 of page 0 that's not looking right, and it's highly repeatable.

Also, I've found that the clones work on all the readers EXCEPT the Schlage lock reader. So I think there must be something sneaky/extra it's checking for that my clones lack.

iceman · 2019-08-14 01:27:27

I would suggest you try RRG/Iceman repo. https://github.com/RfidResearchGroup/proxmark3/

Remember to compile it with the right target device (it defaults to RDV4) , and there is lots of docs you can enjoy reading.

theguy · 2019-08-14 03:00:09

theguy wrote:

Also, I've found that the clones work on all the readers EXCEPT the Schlage lock reader. So I think there must be something sneaky/extra it's checking for that my clones lack.

Can you please address this? I have no idea why or how this could possibly happen. Do you have any ideas?

iceman · 2019-08-14 03:27:39

How about you get some nice signal traces and share with the community via a filesharing service.
if should be a normal HID prox tag...

lf read 3000 
data save schlage_(written cardid).pm3

theguy · 2019-08-14 03:30:56

When I do full image flash after bootloader flash for RRG, I get this:

[+] Waiting for Proxmark3 to appear on /dev/ttyACM0
........... Found
[=] Available memory on this board: 256K bytes

[=] Permitted flash range: 0x00102000-0x00140000
[+] Loading ELF file armsrc/obj/fullimage.elf
[+] Loading usable ELF segments:
[+] 0 : V 0x00102000 P 0x00102000 (0x0003ec40->0x0003ec40) [R X] @0x94
[!!] Error: PHDR is not contained in Flash
[!!] Aborted on error.

Does this just mean the RRG fullimage is too big for my pm3?

Last edited by theguy (2019-08-14 03:34:29)

theguy · 2019-08-14 03:33:35

It definitely is a normal HID prox tag, but the door reader, and the door reader only, may have an additional check or quirk that the standard readers don't. The cloned cards/tags/fobs work on all the readers except the Schlage door reader. The other readers are regular, unbranded. The fob is a gray Schlage brand keyfob, but maybe it has some secret sauce inside that I haven't detected/duplicated.

iceman · 2019-08-14 03:48:18

You missed some instructions...

https://github.com/RfidResearchGroup/pr … ameters.md

mwalker · 2019-08-14 06:19:10

Some things to keep in mind.
FSK2a can be a bit hard to detect the start of. I have always seen it a bit tricky on my easy and the rdv4.0 and rdv4.1. But you will get better results with a stronger read. Being a fob, the position of the fob can affect how well it will read. I have also seen different bit patterns have different levels of success locking onto the start of the card data.
When it writes, it uses a different encoding to when it reads, so if the data "looks" mostly right (bit shifted), I would take that as the write was OK, just not a strong signal to get a good lock on the start offset.

As to the fob working on all but one reader, this confirms the write was OK and that the one reader may be a bit smarter and can see its a clone.
Here, you can try a few things that may help it.
1. Set a password on the clone : If the reader is sending a t55xx read and gets a valid response, then by setting the password, it wont get a valid response unless it also sends the correct password.
2. With the latest software you can also set the downlink mode to something different (leading 0 or 1 of 4), this will stop the card seeing commands unless sent using the correct downlink mode.

I would start with the password.
a) Set a known password (write it down) into block 7 page 0.
lf t55 write b 7 d 11223344
where 11223344 is the 8 Hex digit password you want.
b) when you are happy that is saved as needed, you will need to update block 0 page 0 to set the "use password" flag.
lf t55 write b 0 d 60107C70

That said, not sure why the master key is set (first byte is a 6), can only assume this was set to stop a reader sending the test mode command to reset the card ?

theguy · 2019-08-15 02:36:14

I think I'm onto something. The fob and reader are dual- Mifare Classic 1K and HID, so perhaps the reader wants to handshake with a disabled Mifare chip before reading and accepting the HID tag?

What would you guys recommend to test this out?

theguy · 2019-08-15 02:42:11

Also, playing with
lf t55 write b 7 d 11223344

but it writes 22446688 to block 7 (same bitshift error!)

Any ideas what's causing this inability to write to (some) blocks correctly?

theguy · 2019-08-16 00:32:07

Card/fob type is Schlage 9691T

theguy · 2019-08-16 04:25:36

Is there a command to listen/record the interaction between reader and fob?

iceman · 2019-08-16 07:37:33

RRG/Iceman repo
for lf you save the signal data with data save
for hf you save the trace data with trace save

mwalker · 2019-08-16 08:42:27

I still believe the write is ok, just that the fob is a little low on "signal strength" thus incorrect offset getting detected.

For interest can do the following.
1. Change the modulation/config to ASK
lf t55 write b 0 d 000880E0
2. lf t55 detect
3. lf t55 dump

I expect you will find the data is correct when using the ask modulation. BUT the fob wont work as it needs to be FSK
so this is just a test to check the data on the fob

(then put back to your block 0 config)
lf t55 write b 0 d 60107C60
and re detect.

The other thing that looks a little weird is the block 0. When I do a lf hid clone it is : 00107060,, yet your fob is showing PSKCF of 11 (reserved)

theguy · 2019-08-22 00:12:14

Iceman, you're not making sense to this noob.

Please first explicitly answer whether or not it's possible to listen/record the interaction between the fob/reader, yes or no, with a regular pm3 and regular or iceman software/firmware.

If yes, please write out all the commands I need to do to this. I'm noob, and everyone who will read and gain value from this thread will likely be pretty noobish as well, so having all the commands is essential. When I hf snoop, it insta-finishes. When I lf read, same deal. For example, your suggestion to "lf read 3000" does nothing, because "3" isn't a valid argument. I assume it's supposed to be lf read d 3000. But, when I do that, nothing happens. I'm not able to produce traces with the commands you've written, and the readmes of normal pm3 and iceman pm3 are insufficient to figure this out. I can't use rd4 rrg/iceman because my pm3 is rd3 / too small of memory, as you pointed out above.

I'm hoping for some insight into this specific card type, 9691T. If you have some, please share it. If not, you can just tell me you have no idea how to figure this out, and to get lost. I'm unhappy because I'm in this weird limbo where you act like if I type the commands you share, I'll get somewhere, but they're incomplete and incorrect, so I feel like I'm not getting anywhere.

mwalker, I'll try your idea, but the hid clone has worked. It's only on this one Schlage reader, and with this particular Schlage dual-technology 9691T key that the clones aren't working.

Last edited by theguy (2019-08-22 05:36:43)

theguy · 2019-08-22 00:25:43

mwalker, I don't understand. If I do the following:

1. lf t55 write b 0 d 000880E0
2. lf t55 detect
3. lf t55 dump

It won't detect, because it's turned into Indala.

Maybe need more commands?

When everyone does hid clones, the first block 00 is 00107060. Do you have any insight into what the PSKCF of 11 means or what I could do about it?

mwalker · 2019-08-22 05:07:26

Yes, I did say "BUT the fob wont work as it needs to be FSK"

Some background.

When you write data to the T5577 card it will ALWAYs use the same modulation regardless of the block 0 config (just some little difference IF a downlink mode has been changed by the user).

But when you read the data from the T5577 it will output in the modulation that it has been programmed to output in the block 0 config. (e.g. PSK/FSK/ASK)
Some of these modulations (and speeds) and the way the fob deals with them, can make it a little tricky to get a good read. Most of the time it works well, but I have seen some FOBs on FSK2 RF/50 a little hard to "read" (yet a full size card, reads perfect).

Note: In some of my tests even changing the speed can improve the read... BUT its not what the clone needs to be set to.
So given that one of the things you wanted to do was ensure the correct data was on the card, we can change the modulation (as per my instructions) to output using ASK rather then FSK. then perform the detect and dump.
(I am in the middle of a bigger research project around modulations and way to early to say more then a theory, but I think its related to the way FSK works and RF/50 (which is not an even multiple of 8. 50/8 = 6.25)

Back on track.....
What I was trying to do is send the data from the card to the pm3 using the ASK modulation, which seems to easier to get a good read.

If this works, it should show that the data on the FOB is correct. So its a test.

Then by writing the original block 0 (config) back to the fob, it will put it back into FSK mode for it to work as needed.

If it still gives bit offset data, then we can look into playing with the speeds for a test.

Key Point: I believe the data on the card is correct, I am trying to find a simple way to prove it for you.

As to
"...The other thing that looks a little weird is the block 0. When I do a lf hid clone it is : 00107060,, yet your fob is showing PSKCF of 11 (reserved)..."
since PSKCF of 11 is reserved, I would expect it would have no impact and the fob would fall back the to default value.
I was just interested in why some of the other values had been set.
I am assuming that you just run lf hid clone <id> and did not make any other changes ?

Last edited by mwalker (2019-08-22 05:11:57)

theguy · 2019-08-22 05:29:31

What I was trying to do is send the data from the card to the pm3 using the ASK modulation, which seems to easier to get a good read.

I need more commands. I tried to look up commands, but I doubt whether I even used ASK, and I don't think I tested your idea correctly/completely. I did "lf t55 config d ASK", but I don't think anything's different. Please give a complete set of commands I can run to do this ASK write test. For example, how exactly do I set to ASK? Is the command I created above accurate? Which order I run the commands in matters too. I need to be able to run this test from start to finish with complete commands.

I can't even get to the 3rd command you listed, because the 1st command breaks the ability to dump, I only assume/guess it's Indala because I'm running "lf sea" in an effort to diagnose *how* it's failing. I assume you expect useful outputs/responses to the dump command, but that's not happening because I have an inaccurate/incomplete/out-of-order recipe of commands I'm following.

I am assuming that you just run lf hid clone <id> and did not make any other changes ?

I'm running the lf hid clone command, and then writing every block manually, in an effort to make sure I've a bit-perfect copy clone.

Some of these modulations (and speeds) and the way the fob deals with them, can make it a little tricky to get a good read. Most of the time it works well, but I have seen some FOBs on FSK2 RF/50 a little hard to "read" (yet a full size card, reads perfect).

OK, but these bit errors are consistently occurring across both fobs and full size cards I've cloned, suggesting this is a general problem, not device-specific, and stemming from a different root cause.

Last edited by theguy (2019-08-22 05:39:51)

mwalker · 2019-08-22 05:58:00

To be honest, I think we need to take a step back and ensure things are done correctly.
the first thing to keep in mind with th T55 chips.
The lf t55 detect will try to work out WHAT settings the card has so the pm3 knows how to decode the data. (e.g. Speed, Modulation, offset etc)
So, if ANY of the data in Block 0 changes or you put a different card on the PM3 you ALWAYS run the lf t55 detect.
So if you run the lf t55 detect, then dump then lf t55 write b 0 <data>, then you MUST run the lf t55 detetct again as things may have changed.

1. lf t55 write b 0 d 000880E0
2. lf t55 detect
3. lf t55 dump

With the above, when you said it turned into an indala, i can only assume you say that because you run the "lf serarch" again. you dont need to run that as we know we are looking at a T5577 card. we need the lf t55 detect
So try as written.

This time can you run the command 1 2 and 3 and post the entire command and output for review.
Once we can ensure that bit looks ok we can move forwards.
Thanks

iceman · 2019-08-22 06:42:27

I am not in favour spoonfeeding, so no, I am not gonna tell you command for command.

theguy · 2019-08-26 01:05:16

Please first explicitly answer whether or not it's possible to listen/record the interaction between the fob/reader, yes or no, with a regular pm3 and regular or iceman software/firmware.

I assume this is a very common goal within the community. Therefore, it'd be extremely useful if somewhere there was an example of how to do it. Google, RTFM turn up nothing. It's not clear whether this is possible. The commands you gave me were incomplete and in at least one case, flat out wrong.

Is it possible with a regular rd3 pm3 and either the regular or iceman fork to listen/record the whole interaction between fob/reader?

Last edited by theguy (2019-08-26 01:07:17)

theguy · 2019-08-26 01:14:48

pm3 --> lf t55 write b 0 d 000880E0
Writing page 0 block: 00 data: 0x000880E0
pm3 --> lf t55 detect
[!] Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'
pm3 --> lf t55 dump
Reading Page 0:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
Reading Page 1:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
pm3 -->

Not sure why you thought it'd be anything different...

pm3 --> lf sea
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible

Checking for known tags:

[+] Valid Indala ID Found!

Last edited by theguy (2019-08-26 01:15:29)

mwalker · 2019-08-26 09:50:24

In short, I was trying to see what it does and the fact that you got no data with the ASK config is interesting in its own.
I was expecting to see something like the following.

[usb] pm3 --> lf search
[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags...

[+] HID Prox TAG ID: 055667321 (211344) - Format Len: 37bit - OEM: 000 - FC: 1366 - Card: 211344

[+] Valid HID Prox ID found!

[usb] pm3 --> lf t55 det
Chip Type  : T55x7
Modulation : FSK2a
Bit Rate   : 4 - RF/50
Inverted   : Yes
Offset     : 34
Seq. Term. : No
Block0     : 0x00107060

Downlink Mode used : default/fixed bit length
[usb] pm3 --> lf t55 dump
Reading Page 0:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 00107060 | 00000000000100000111000001100000 | ..p`
 01 | 1D555555 | 00011101010101010101010101010101 | .UUU
 02 | CCCCD2D2 | 11001100110011001101001011010010 | ....
 03 | D4B4B2AC | 11010100101101001011001010101100 | ....
 04 | 00000000 | 00000000000000000000000000000000 | ....
 05 | 00000000 | 00000000000000000000000000000000 | ....
 06 | 00000000 | 00000000000000000000000000000000 | ....
 07 | 11223344 | 00010001001000100011001101000100 | ."3D
Reading Page 1:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 00107060 | 00000000000100000111000001100000 | ..p`
 01 | 00000000 | 00000000000000000000000000000000 | ....
 02 | 00000000 | 00000000000000000000000000000000 | ....
 03 | 00000000 | 00000000000000000000000000000000 | ....
[usb] pm3 --> lf t55 write b 0 d 000880E0
[=] Writing page 0  block: 00  data: 0x000880E0
[usb] pm3 --> lf t55 det
Chip Type  : T55x7
Modulation : ASK
Bit Rate   : 2 - RF/32
Inverted   : No
Offset     : 32
Seq. Term. : Yes
Block0     : 0x000880E0

Downlink Mode used : default/fixed bit length
[usb] pm3 --> lf t55 dump
Reading Page 0:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 000880E0 | 00000000000010001000000011100000 | ....
 01 | 1D555555 | 00011101010101010101010101010101 | .UUU
 02 | 66666969 | 01100110011001100110100101101001 | ffii
 03 | 6A5A5956 | 01101010010110100101100101010110 | jZYV
 04 | FFFFFFFF | 11111111111111111111111111111111 | ....
 05 | FFFFFFFF | 11111111111111111111111111111111 | ....
 06 | FFFFFFFF | 11111111111111111111111111111111 | ....
 07 | 11223344 | 00010001001000100011001101000100 | ."3D
Reading Page 1:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 000880E0 | 00000000000010001000000011100000 | ....
 01 | FFFFFFFF | 11111111111111111111111111111111 | ....
 02 | FFFFFFFF | 11111111111111111111111111111111 | ....
 03 | FFFFFFFF | 11111111111111111111111111111111 | ....

[usb] pm3 --> lf sea
[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags...

[-] No known 125/134 kHz tags found!
[usb] pm3 --> lf t55 write b 0 d  00107060
[=] Writing page 0  block: 00  data: 0x00107060
[usb] pm3 --> lf t55 det
Chip Type  : T55x7
Modulation : FSK2a
Bit Rate   : 4 - RF/50
Inverted   : Yes
Offset     : 33
Seq. Term. : No
Block0     : 0x00107060

Downlink Mode used : default/fixed bit length
[usb] pm3 --> lf t55 dump
Reading Page 0:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 00107060 | 00000000000100000111000001100000 | ..p`
 01 | 1D555555 | 00011101010101010101010101010101 | .UUU
 02 | 66666969 | 01100110011001100110100101101001 | ffii
 03 | 6A5A5956 | 01101010010110100101100101010110 | jZYV
 04 | 00000000 | 00000000000000000000000000000000 | ....
 05 | 00000000 | 00000000000000000000000000000000 | ....
 06 | 00000000 | 00000000000000000000000000000000 | ....
 07 | 11223344 | 00010001001000100011001101000100 | ."3D
Reading Page 1:
blk | hex data | binary                           | ascii
----+----------+----------------------------------+-------
 00 | 00107060 | 00000000000100000111000001100000 | ..p`
 01 | 00000000 | 00000000000000000000000000000000 | ....
 02 | 00000000 | 00000000000000000000000000000000 | ....
 03 | 00000000 | 00000000000000000000000000000000 | ....

Since you got no detect with the ASK config there may be a different issue.
Can you run and post the result of

hw tune

theguy · 2019-08-27 06:44:41

pm3 --> hw tune

[=] measuring antenna characteristics, please wait...

...

[+] LF antenna: 26.34 V - 125.00 kHz
[+] LF antenna: 19.97 V - 134.00 kHz
[+] LF optimal: 26.48 V - 123.71 kHz
[+] LF antenna is OK

[+] HF antenna: 25.45 V - 13.56 MHz
[+] HF antenna is OK

[+] Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

pm3 --> X Error: BadAccess (attempt to access private resource denied) 10
Extension: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0x18d

iceman · 2019-08-27 07:00:46

looks like you have some kind of problems with your xserver aswell. The pm3 client shouldn't crash when running hw tune.
It should show the data plot window.

theguy · 2019-08-27 07:08:36

Assuming the snoop command is supposed to listen to the interaction... I do
lf snoop
data samples
data plot

and it sees nothing.

I know my data plot command works because it sees nice data for dump/read commands

The mit/shm error I fixed with a google search. It wasn't crashing the client, just preventing draws of data plot.

Last edited by theguy (2019-08-27 07:11:19)

theguy · 2019-08-27 07:24:37

mwalker, interestingly, in regular pm3 client, i get:

proxmark3> lf t55 write b 0 d 000880E0
Writing page 0 block: 00 data: 0x000880E0
proxmark3> lf t55 det
Chip Type : T55x7
Modulation : ASK
Bit Rate : 2 - RF/32
Inverted : No
Offset : 31
Seq. Term. : No
Block0 : 0x000880E0

proxmark3> lf t55 dum

But I believe the 31 offset issue here is related to mixing pm3 software w pm3iceman firmware. I tried monkeying with configging the offset many days ago, and it couldn't overcome the bit shift. It's weird, the bit shift is only in later blocks, like page 1 b 1-2. In this regular pm3 client with iceman flash, I can get it to clone every block but page 1 b 2 (last block). That one I can't un-bit-shift.

I'm pretty sure it's a proper clone, but something just not reading right on the dump command.

I'm also pretty sure the door reader is somehow checking for the mostly-inactive mifare in the real fob that my clones lack.

theguy · 2019-08-27 07:28:01

Perhaps I need better troubleshooting on hf.

Hf sea has never detected a card for me. I'm pretty sure I have a shipment of mifare hf cards right here, but lf sea and hf sea turn up nothing for them!

I followed examples for mifare detection/cracking, but I must be missing something, because I have yet to detect a mifare card, or any form of hf card!

theguy · 2019-08-27 07:32:11

pm3 --> hw tune

[=] measuring antenna characteristics, please wait...

....

[+] LF antenna: 26.48 V - 125.00 kHz
[+] LF antenna: 20.11 V - 134.00 kHz
[+] LF optimal: 26.63 V - 123.71 kHz
[+] LF antenna is OK

[+] HF antenna: 25.38 V - 13.56 MHz
[+] HF antenna is OK

[+] Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

Is there a chance my hf antenna is actually totally busted? That would explain why I have never detected any hf technology cards/fobs, and might be the heart of this issue! It would explain everything...the door reader is sniffing both hf and lf tags in the key, but I can't detect hf mifare classic tag in the key, because I don't know the commands, or my hf antenna is busted.

iceman · 2019-08-27 07:38:42

We like the threads to be to the point and no hijack of threads. Thread stared with LF. So if you have another HF question, please start a new thread in the suitable category.
Don't forget to start with mention which device, firmware, and which commands and/or tracelist outputs etc. All of which helps in order to understand what you are trying to do and why it fails. If not, we can only speculate.

mwalker · 2019-08-27 09:32:55

"...mixing pm3 software w pm3iceman firmware..."
I would not recommend mixing software and versions. Things can change that can result in unpredictable results.

Try using the same client and firmware.

As to the 31 v 32 offset I would not worry to much about that as there can be valid reasons why the offset can change. E.g. the card is slow to respond or too fast when responding. The offset is where the client believes the data should start.

Last edited by mwalker (2019-08-27 10:55:18)

theguy · 2019-08-27 17:08:44

Thread stared with LF.

So what? Thread is about a specific Schlage credential with both lf and hf chips. It's not about only lf nor only hf. There is no hijack. Move the thread where you think it fits best, but it's been about the Schlage 9691T the whole time. The point is to have a google-able resource to help people looking to clone their Schlage 9691Ts and other dual-technology cards with their proxmark3s.

I can open a thread about hf if you want, but this thread needs to continue existing, and it needs to mention both hf and lf, because that's what the Schlage 9691T is.

Don't forget to start with mention which device, firmware, and which commands and/or tracelist outputs etc. All of which helps in order to understand what you are trying to do and why it fails. If not, we can only speculate.

Now you know how I feel! Unless you mention (or somewhere it's easily googlable) correct commands, in the correct order, with a real example, there's no way I know what to do.

Take MiFare. The manual is useless. The only 2 examples I found use a command that doesn't exist: hf mf mifare.

Hf sea has never detected a single card/fob for me.

Hf mf *anything* throws an error about a card not being found.

I've shown my hw tune, which suggests my hf antenna works. I don't think so. Hf sea should find mifare classics, the UID cards that come with a pm3, etc. My mobile phone finds 3 mifare tags, so it's strange hf search doesn't/can't.

Last edited by theguy (2019-08-27 17:16:47)

theguy · 2019-08-27 17:18:51

mwalker wrote:

Try using the same client and firmware.

I do. I try using the different client/firmware, because it's interesting, and gets me a couple blocks closer to a bit-perfect clone. I'm still curious why either ice/ice, reg/reg, or ice/reg combinations of fw/client can't produce a bit-perfect clone of the original credential. Aren't you?

iceman · 2019-08-27 19:10:24

Good luck with your endeavors.

mwalker · 2019-08-28 04:51:04

theguy wrote:

I'm still curious why either ice/ice, reg/reg, or ice/reg combinations of fw/client can't produce a bit-perfect clone of the original credential. Aren't you?

While this is starting to drift a little, I will try to explain.

A clone of an HID card to a T5577 (for example) is taking a dedicated device and emulating that on a generic multi-purpose device.
As such, first thing to note is the T5577 needs MORE information then just the ID. It needs to know the Modulation and speed configuration etc (block 0).

When you write to the T5577 it is completely independent to how you will READ the data back. Dont think of this like reading and writing to a serial port. If would be more like sending in morse code and reading via voice reply. The morse/write is always the same, but the voice reply/read could be in a different language (modulation)

The T5577 has 2 main modes when it sends data to the reader/pm3
a) In response to a power up event (or invalid command/request).
b) In response to a valid block request.

In (a), when the card is powered, it (normally) will start sending out the data in Block 1 (page 0) 32 bits up to block X (page 0) and repeat.
Note: block X will be what is configured in the config (block 0)

In (b), you may request the data in any block (eg block 1 - page 0), that card will then send the 32 bits in block 1 and repeat until the next request (or power lost).

Key Note: The data it sends will repeat until a new request or power down.

How it sends that data depends on the config (e.g. FSK, PSK, FSK2, ASK etc.... then speed RF/50, RF/32 etc)

So at this point, lets assume the card has been set to send out a HID format packet (on power up).
So we know the config is set to RF/50 and FSK2a (from memory) and to send the data in blocks 1,2 and 3 (don't quote me here)

You send a card detect (lf t55 detect). The PM3 will send a "lf t55 read b 0" request. It will then try all the different modulations/speeds etc on the raw data until it finds one (and hope there is only one) match of a valid formatted 32 bit config block.

Most of the time it does a great job of this.

Once it finds that valid config block, it will see "how far" into the packet (how many bits) was it from the start to the clean config data.
This is the Offset you see (eg. 32 bits will be start at 32 bits in)

Key Note: You should see how this offset is not fixed and will vary based on many factors. In short, it should not matter what value this is, as long as its correct for THAT card, with THAT config at that moment in time.

From here, the only thing the PM3 can do is assume all future reads to THAT card will have a good read at the same offset. There is no real way to know where the data really starts (or the start of a clean 32 bits for a block read) but it SHOULD be at the same place as the detect found it. As the PM3 does not know what the data should look like, it cant check.

When you have cards Like HID/EM4100 etc, the MAY have know start patterns, so the door readers will search the bit pattern for that ID (e.g. lf search), but the lf t55 read is not reading a HID card, its reading a T55xx card.

As an example.
let say we do a read of block 1. The T5577 will send back the 32 bits and repeat. e.g.
0100111101011010001000111010110101001111010110100010001110101101010011110101101000100011101011010100111101011010001000111010110101001111010110100010001110101101010011110101101000100011101011010100111101011010001000111010110101001111010110100010001110101101010011110101101000100011101011010100111101011010
With no more information, where is the start of that bit stream ? Answer: No way to know (so the PM3 will assume at the some offset detected via the lf t55 detect and then take the next 32 bits as the data.

Now, to add to the challenge, lets say the T5577 is not working as well as it could and the clock drifts a little or boot up time is too fast or to slow (a little out of spec).
Based at the same offset you COULD end up with this example
01001111010110100010001110101101 <- Correct
10011110101101000100011101011010 <- One bit early/fast (Lost first bit)
10100111101011010001000111010110 <- One bit slow/late (Got one bit to early at start)

So I am hoping now we can start to see HOW the data may be a little mis-aligned.

From my testing and research, I have found that some cards/fobs and modulations/speeds are more prone to this then others.

So, given the above.
My takeaway is.
1. Most of the time the PM3 does a great job (and is improving all the time).
2. When it is a little off, my tests has shown its either an issue with a cheap card/fob and a good card shows correct data, or its a weird combo of the data and modulation the leads to demodulation challenges (and missed bits).
3. If we can see the data is just one bit out, chances are the data on the card will be correct.
If the data was NOT correct, then it would not give the correct HID ID from lf search AND it would not work on the real reader.

We are looking to see if this can be improved and I agree it would be nice for 100% correct 100% of the time (thats the target), but I also understand the challenges in meeting this (Remember everyone working on this is a volunteer and will allocate time as they can).

In short, for your final purpose. if you clone the HID and it opens the door, that data MUST be correct.

theguy · 2019-08-28 20:51:15

@mwalker Got it. So it's just that my Elechouse china cards and china fobs are a little "sloppy" relative to the official ISO spec timing, and bits "drift" over a fairly long period of time because the "slop" adds up?

One thing I tried to test this was read block by block vs dump.

However, block by block still reads different on the clone vs original, but only on that last b 2 of page 1.

I'm guessing it's just that the cheap chinese tag takes a bit or two too long or short of time to access and "yell" b 2 of p1 in your analogy of writing in morse code and reading by voice? Like, the card's chip is fast or slow to "turn pages" of its book before answering back to the proxmark?

mwalker · 2019-08-28 22:32:50

From memory the dump simply does the block by block for you, so I would expect the same results.

As to you exact case, i dont know what the base cause is, my reply was to help you understand why it can happen and why the offset can very. You would need to test different things to find the base cause.

I still dont know why the ASK test did not return anything.
That cant be explined with my above comments.

If you want to learn about this I suggest reading the t5577 datasheet. Then ask specific questions as needed.

The key takeaway from me would be.
The lf hid clone did work. This is verified by the lf search and working on some readers.
Its confirmed the write does work.

The read should work, but due to many factors it may glitch from time to time.

Given the thread heading, I think you lf issue has been addressed. If you agree, make it as solved.

theguy · 2019-08-29 04:17:55

Where/how do I mark as solved?

[Solution:]

For anyone who comes to this thread from Google, the 9691T Schlage key has two chips with two loops in it: one is a mifare 13.56mhz, the other is a HID 125khz. You will have to clone both to get it to operate on readers of high and low frequency. Usually elevators/doors will be low frequency 125k HID prox readers, and apartment rooms will be mifare high frequency 13.56mhz readers. Nothing special goes on. Each reader only interacts with one chip and loop of wire in your fob. You can clone two separate tags, or buy a combo 2-in-1 tag on ebay.

Proxmark3 community

Announcement

#1 2019-08-12 21:44:03

[Solved] Schlage HID fob cloned but not working

#2 2019-08-12 21:55:43

Re: [Solved] Schlage HID fob cloned but not working

#3 2019-08-12 22:43:36

Re: [Solved] Schlage HID fob cloned but not working

#4 2019-08-12 23:02:10

Re: [Solved] Schlage HID fob cloned but not working

#5 2019-08-12 23:11:17

Re: [Solved] Schlage HID fob cloned but not working

#6 2019-08-13 00:31:30

Re: [Solved] Schlage HID fob cloned but not working

#7 2019-08-13 04:44:51

Re: [Solved] Schlage HID fob cloned but not working

#8 2019-08-13 17:37:34

Re: [Solved] Schlage HID fob cloned but not working

#9 2019-08-13 18:12:54

Re: [Solved] Schlage HID fob cloned but not working

#10 2019-08-13 18:27:05

Re: [Solved] Schlage HID fob cloned but not working

#11 2019-08-13 18:28:07

Re: [Solved] Schlage HID fob cloned but not working

#12 2019-08-13 18:36:32

Re: [Solved] Schlage HID fob cloned but not working

#13 2019-08-14 00:51:15

Re: [Solved] Schlage HID fob cloned but not working

#14 2019-08-14 01:27:27

Re: [Solved] Schlage HID fob cloned but not working

#15 2019-08-14 03:00:09

Re: [Solved] Schlage HID fob cloned but not working

#16 2019-08-14 03:27:39

Re: [Solved] Schlage HID fob cloned but not working

#17 2019-08-14 03:30:56

Re: [Solved] Schlage HID fob cloned but not working

#18 2019-08-14 03:33:35

Re: [Solved] Schlage HID fob cloned but not working

#19 2019-08-14 03:48:18

Re: [Solved] Schlage HID fob cloned but not working

#20 2019-08-14 06:19:10

Re: [Solved] Schlage HID fob cloned but not working

#21 2019-08-15 02:36:14

Re: [Solved] Schlage HID fob cloned but not working

#22 2019-08-15 02:42:11

Re: [Solved] Schlage HID fob cloned but not working

#23 2019-08-16 00:32:07

Re: [Solved] Schlage HID fob cloned but not working

#24 2019-08-16 04:25:36

Re: [Solved] Schlage HID fob cloned but not working

#25 2019-08-16 07:37:33

Re: [Solved] Schlage HID fob cloned but not working

#26 2019-08-16 08:42:27

Re: [Solved] Schlage HID fob cloned but not working

#27 2019-08-22 00:12:14

Re: [Solved] Schlage HID fob cloned but not working

#28 2019-08-22 00:25:43

Re: [Solved] Schlage HID fob cloned but not working

#29 2019-08-22 05:07:26

Re: [Solved] Schlage HID fob cloned but not working

#30 2019-08-22 05:29:31

Re: [Solved] Schlage HID fob cloned but not working

#31 2019-08-22 05:58:00

Re: [Solved] Schlage HID fob cloned but not working

#32 2019-08-22 06:42:27

Re: [Solved] Schlage HID fob cloned but not working

#33 2019-08-26 01:05:16

Re: [Solved] Schlage HID fob cloned but not working

#34 2019-08-26 01:14:48

Re: [Solved] Schlage HID fob cloned but not working

#35 2019-08-26 09:50:24

Re: [Solved] Schlage HID fob cloned but not working

#36 2019-08-27 06:44:41

Re: [Solved] Schlage HID fob cloned but not working

#37 2019-08-27 07:00:46

Re: [Solved] Schlage HID fob cloned but not working

#38 2019-08-27 07:08:36

Re: [Solved] Schlage HID fob cloned but not working

#39 2019-08-27 07:24:37

Re: [Solved] Schlage HID fob cloned but not working