[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.
]]>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.
]]>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?
]]>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.
]]>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?
]]>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.
]]>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.
]]>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.
]]>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!
]]>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.
]]>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.
]]>