Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Morning,
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.
Offline
thanks for sharing traces. :
first your demod of ask/manchester with sequence terminator is correct. rf/32.
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.
Offline
Thank you.
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.
Offline
grrr. the reader has a long power on sequence and triggered the threshold prematurely. you will need to try to get the timing right, send the write command on the encoder and then bring the pm3 antenna to it. hopefully you can miss the first high and hopefully the next high will be the write command.
each of the traces with a card just show the card and nothing from the reader. (other than power...)
Offline
I've had a chance this morning to do a little more with it. I upped the decimation and tried again without a card - it seems that the encoder will not attempt to write until it has verified a card is present. Instead it generates an error about no valid card, and as you can see from the trace after a few attempts to wake up it simply stops trying (attempt-write-no-card-d2.pm3).
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.
Offline
You can intoduce the pm3 antenna to the transmission at different times and attempt to get the timing right... but that is about it... we probably should add a delay option after a threshold is detected fpr this purpose.
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.
Offline
coffeefueled, try pwd
50 52 09 01
Offline
Thank you. I will do as soon as I get back (about eight hours away).
Would you mind giving a hint on how you extracted that?
Offline
Unfortunately that password doesn't seem to have any more result.
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.
Offline
50 52 09 01(pwd) - C9 C6 2C 7B(data) - 001(addr)
50 52 09 01(pwd) - E3 92 81 01(data) - 010(addr)
50 52 09 01(pwd) - 08 68 A3 A1(data) - 011(addr)
50 52 09 01(pwd) - C5 A3 A3 00(data) - 100(addr)
50 52 09 01(pwd) - 01 01 1C D9(data) - 101(addr)
and
Blk7: 00 00 00 00
Blk0: 00 08 80 99
(write-card-decimation-5.pm3)
Last edited by anybody (2019-03-26 17:21:41)
Offline
I'm starting to think I may be on completely the wrong track. Things known so far, which led me to thinking there must be a password involved:
- 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?
Offline
Hi, I am just joined this forum (from Indonesia).
I found this topic is interesting. Is it closed/solved ?. May I know the final solution of this topic that initiated by Coffeefueled ?.
Thanks.
Offline
Pages: 1