The pm3 short distance is because of how its imp in the arm-side. Some kind of bit-banging (on-off the antenna power). Making the output low and the antenna powers the tag. I'm planning to remake it, but haven't gotten around to contiue what I've started.
Ok thanks for the info
Any idea how far the read distance can be for legic prime?
The official website states that a read distance of 50 cm can be achieved.
Is this true?
It probably depends on the cards antenna also?
And a question about NFC - legic.
Are there tools to read legic prime cards with NFC enabled tablets/cellphones?
I can sell you empty tags (2.50 €/piece + shipping) - no problem ... I've got (too) many of them
Not necessary
Thanks for the correct visuals!
]]>btw ... your drawing for the Master-Token reports 5 Stamp bytes, but there are only 4
0x0c..0x0e are empty, but will be used on Master-Token with a longer Stamp
I guess they are just kind of 'reserved' and write-protected for the maximum possible Stamp_Len of 7 bytes+crc
so for my eyes it looks more like this (without engagement):
Master-Token:
User-Credentials:
the last one is the 'embedded' one, I suppose the firmware/software checks the header too - so like you mentioned, that's some kind
of 'tag-type' bit/byte in there
I will try to lower DCF when I find a card with "ff ff" as DCF
(all my testcards have "60 ea")
adjust the addr-check in function legic_write_byte from 0x06 to 0x04
then ... just load a tag into the buffer (hf legic read)
save the buffer-data to file (hf legic save test.hex)
edit the file with your favorite text-edior, and change the DCF to whatever you want
load the file into the buffer (hf legic load test.hex)
and write the new dcf from buffer to tag (hf legic write 0x05 0x02)
this should do the trick - at least on my machine it does ;-)
emulating would be much more complicated
]]>funny thing is that the software says that 'Anlagennr'=0344 whereas '03' is part of the stamp (from my point of view) and '44' is part of the user-mapping - so maybe my assumptions are not totally correct !?!
From what I have learned: The Stamp on a SAM must be (at last) one byte longer than on the Master-Token from which the SAM was created from ... at least, so it might have 2 byte more also, but then there is only one byte left for user-mapping, which should be a little to short. so I'm pretty unsure about that - but it works anyway.
That is the reason why I thought the ID of the user is byte 0xc...0xe.
This is also the number that is printed on the card. (Which is another weakness because we could now impersonate somebody by just having to see their card, but you still need to scan another card for the stamp etc.)
From now on I think we found almost everything that there needs to be found here.
I will now focus more on the coding part.
First thing I will research is how the "writeRaw"-function of you is implemented.
Once I know the basics for sending commands and etc, I can start making my own functionality.(Like simulating, lowering DCF)
Header (byteaddr 0x07) in detail:
bit 0..3 = WRP (write protection - can only be read by legic-security-module, but not written)
bit 4..6 = WRC (read/write protection - only works if RD is set also)
bit 7 = RD (tells the security-module how many bytes of the stamp have to match on the reader-side to allow reading of this part - never set on Master-Token)
hex: 08
bin : 00001000
bit 0..3 (lsb right)= WRP = 1000 = 8 so, the 8 bytes (starting at stamp-byte 0) are write-protected (if a legic security-module is used)
WRC: not set
RD: not set
on byte-addr 0x0f is a crc8 over uid+ header (addr 0x07) + addr 0x08..0x0e (404fc2c6+08+020a0005000000)
on byte-addr 0x21 is a crc8 over uid+ dcf high+ dcf low+ addr 0x07+ stamp (404fc2c6+f820+08+020a0005)
funny thing is that the software says that 'Anlagennr'=0344 whereas '03' is part of the stamp (from my point of view) and '44' is part of the user-mapping - so maybe my assumptions are not totally correct !?!
From what I have learned: The Stamp on a SAM must be (at last) one byte longer than on the Master-Token from which the SAM was created from ... at least, so it might have 2 byte more also, but then there is only one byte left for user-mapping, which should be a little to short. so I'm pretty unsure about that - but it works anyway.
I'm not interessted in such a 3rd-Party sorftware, I thought you where comming up with some original legic software (csw-2000 or csw 4000)
]]>(I updated the rfid schema)
]]>DCF value "60 ea" is higher then "20 f8".
no, it isin't - on the tag the dcf ist stored on address 0x05 & 0x06 whereas 0x05 hold the lower byte and 0x06 holds the higher byte
thus: the DCF on your SAM is for real 'EA 60' and on your IAM it is 'F8 20' - as you can see, you can't make a IAM out of a SAM - only the other way round!
A schema of what we know now:
(Probably not perfect yet)
the stamp of the SAM is one byte longer then on the IAM thus: stamp an the SAM is: 02 0A 00 05 03 (5 bytes)
]]>so ...
DCF is changeable, but only in one direction (lower the value - so you will need to have a blank tag, where dcf is 'ff ff' or a tag that has actually a dcf-value which is higher than the desired one) - and you need some small change in the code.
I don't really know if Iceman included that into his fork.
DCF value "60 ea" is higher then "20 f8". So it should be possible to change the DCF value?
(All my testcards have "60 ea" as DCF which means its not a master token.)
A bit strange that the DCF for master tokens are lower than normal cards..
'08' (addr 0x07) seems to be a header ... the stamp on the IAM is 4 byte long (0xfc- 0xf8=0x04) thus
02 0a 00 05 is the stamp of the IAM tag
and since the stamp on a SAM should be at least one byte longer: 02 0a 00 05 03 is the stamp on the SAM
This header could mean the type of card. Because employee cards embedded in banking cards have "09" as value.
byte addr 0x21 on the IAM will be a checksum (crc8) over certain bytes: UID+DCF high+DCF low+byte-addr 0x07..0x08+stamp ('02 0a 00 05')
so crc8 over 404fc2c6f82008020a0005 => EE
Will confirm this when I am able to lower the DCF value on the cards and create a copy of the IAM card.
(rfid administrator asked for a backup copy )
A schema of what we know now:
(Probably not perfect yet)
'08' (addr 0x07) seems to be a header ... the stamp on the IAM is 4 byte long (0xfc- 0xf8=0x04) thus
02 0a 00 05 is the stamp of the IAM tag
and since the stamp on a SAM should be at least one byte longer: 02 0a 00 05 03 is the stamp on the SAM
byte addr 0x21 on the IAM will be a checksum (crc8) over certain bytes: UID+DCF high+DCF low+byte-addr 0x06..0x07+stamp (0x08..0x0c => '02 0a 00 05')
so crc8 over 404fc2c6f82008020a0005 => EE
I made a mistake. I told you that byte 0x7..0xc is nog writeable.. but apparently it is.
So the only thing I can't change on the card is the UID and I don't know how to change the DCF yet.
I was allowed to make a scan of the IAM card.
40 4f c2 c6 a5 20 f8 08
02 0a 00 05 00 00 00 bc
00 00 00 00 00 ee 00 00
It has a different DCF and the 0xc..0xe is 00. And on byte 21 there is a value. (which is the start of the payload??)
I tried to copy this one aswell. But didn't succeed copying the DCF value.
Unfortuantly I am not allowed to copy the original software and I do not have access to it so that's a nope.
But I got a screenshot with information about the values:
The scanned card is the one in the first post,
with these values:
79 74 26 65 31 60 ea 08
02 0a 00 05 03 44 96 71