- the cards are detected as Indala tags with lf search, no other information available such as UID
- using the Proxmark I cannot write to the cards at all, or wipe them
- the encoder only works on cards from the same manufacturer
- locks on the system must be configured with a 'master' card before they will work (unfortunately any attempts to snoop on this one have failed utterly, due to timing issues), I assumed this was to give them the password for reading, but I'm now not so sure
If there isn't a password, then it's only a case of figuring out what the various bits mean, and a way to write them/simulate them using the Proxmark. If there is a password preventing writing, that's not a particular problem as if there's a way to set blank cards to the same format and write to them, I don't care about being able to write to the specially encoded cards from the manufacturer.
- when read, the cards give a repeating 160 bit sequence, AM encoded, with sequence terminators
- erasing a card (possible with the encoder only) gives a specific bitstream, where the first 31 bits remain common with all other system cards (reregistering the system with a new code/computer causes some slight changes in this, and when asked to read cards the encoder will report that they are not for this system, but will still extract information)
- erasing a card from a different system sets the possible header to match
I'm working through the different bitstreams I've collected from different issued cards, and am trying to map out which bits control which functions.
Does anyone have any ideas on the write problem, assuming it's not password related? Or any ideas on the format it might be using and whether the Proxmark will be able to handle it, or I need to look at other equipment?
]]>and
Blk7: 00 00 00 00
Blk0: 00 08 80 99
(write-card-decimation-5.pm3)
]]>From what I've gathered from the manufacturer, it's because they not only want to be able to set a password on all cards used with the system - they only allow cards bought from them to be used with the system.
As they all appear to be standard t5557 cards, I don't see anything beyond a password requirement which could be preventing other cards from working - but notably other t5557 cards from any other source will not work either with the encoder, or with the door locks. They simply react as if no card is present.
]]>Would you mind giving a hint on how you extracted that?
]]>Most lf encoders I've experienced aren't sensitive enough to care if a tag is there or not. It's interesting yours seems to. I'll have a look at the most recent traces soon, but I expect the write cmd won't be readable at that decimation.
]]>I've also tried playing around with the decimation a bit on the card write attempt with a valid card. It looks like this is actually capturing the full trace - what I'm not sure about is whether the sampling rate is still sufficient for it to make sense - and setting d 5 seems to be the magic number (write-card-decimation-5.pm3). Is there any other way to increase the length of time that it will capture for, without sacrificing sampling rate?
Thank you for all your help so far. The additional three traces, with different downsampling rates, are in the same shared folder. Setting lf config d 5 seemed to capture the full trace between card and reader in terms of timing.
]]>each of the traces with a card just show the card and nothing from the reader. (other than power...)
]]>I've tried all three commands from the encoder (write, erase, and read) with only the proxmark present and no card. They're added to the shared folder as various .pm3s (write-attempt-no-card, etc).
I also tried, because the traces without a card completely confused me, a card write attempt with a card present but above rather than beneath the Proxmark on the reader (write-attempt-with-card-above-proxmark.pm3). The system gave an error that the card wasn't valid, but has generated a very different trace to both an attempt to write without a card, or a successful write.
]]>now your snoops appear to have not captured any write commands from the reader (at least not cleanly).
try just telling the encoder to write with just the pm3 antenna (in lf snoop mode with a threshold set) on the encoder and no tag near the encoder.
]]>I've been trying to work out a hotel door system (demo system from work that I snaffled before it could be binned, as it wasn't selected).
It uses this encoder (https://www.eproer.com/card-encoder/), and T5557 cards.
lf search recognises the issued door cards as Indala, and I believe they're password protected as I'm unable to read or write blocks using the Proxmark. I did get the bitstream from the cards (which I do not have access to at the moment, but will do later today when I'm back at my home desk), which appears to be a repeating 20 byte stream with the first 2 bytes consistent across all the issued cards. I'm assuming those two bytes are the configuration block, however they didn't match up with the T55x7 emulation sheet shared by asper and pinned at the top of this forum. The only demod that worked for this was lf rawdemod am - and lf rawdemod am s recognised sequence terminators.
On top of that the encoder does not recognise the T5577 card I have lying around as valid.
I did some research on the forum and have run lf snoop to get a trace when:
- issuing a new card from the encoder
- erasing a new card using the encoder
I've uploaded the traces to OneDrive and shared here: https://1drv.ms/f/s!Atr7aSGLmbhRtTsHSApd-WlT0UF7
erase-card.pm3 is the erasure of a card using the writer. An erased card still has the same first two bytes when read by the Proxmark3.
issue-card-1 and issue-card-2 are traces of two cards being written, with the only difference being room numbers.
reader.pm3 is an attempt to capture a trace from the card being presented to the reader, though this doesn't seem to have worked well.
key-101.pm3 is an lf read of the issued key card for room 101.
I'm really struggling with trying to decode the trace to extract the password used, if there is one. Any advice on how to make sense of this would be really helpful as I've basically hit a wall.
I'm reasonably technical, but fairly new to this level of investigating RFID.
]]>