Clone Legic to blank card

hlange · 2013-06-08 08:24:23

Hey,

is it possible, to copy a Legic tag to a blank card? Which card do I have to buy for this?

Thanks.
Harald

AntiCat · 2013-06-08 22:46:58

You can't write the UUID of the card.

The rest of the data can be copied. However the CRC of the section headers has to be adjusted.
See http://www.proxmark.org/forum/viewtopic.php?id=1228 on insights on how to calculate the new CRC.

albertito12 · 2013-08-05 00:43:22

I'm a newbie, with proxmark, but I've been playing with the touchatag ...
Can you recommend a link or something to initiate me with these cards??? In my work I have the legic, but do not know which model are, although they have about 4 or 5 years (readers Kaba).
I appreciate any help.

mosci · 2016-01-23 11:57:23

Hi, I'm totally new to this stuff
I want to clone my legic prime card to a keyfob
unfortunately It's not that simple as I thought - but I have time and it's just for fun
I do have three blank tags to test with
on one of them I have tried to write some bytes already (with more or less kind of success)
all the blank tags can be read, but if I try 'hf legic decode' it ends up with a segmentation fault
would be nice if someone can point me in the right direction or help me to get the card cloned
I guess I have to recalculate the crc (and probably more) - but I have no idea what and how - also I'm not that good in coding - but I'm willing to learn
cheers

iceman · 2016-01-23 17:47:49

the legic code hasn't gotten some love for a long time. There are most likely bugs in that code uncorrected. If you can test the functionality tha woud be great.

I pushed some coverity scan fixes into the legic code in my fork, you code try to apply them on your side and test the demod again

mosci · 2016-01-23 21:23:13

thx for the replay Iceman,
your fork at least didn't end with a segmentation fault after 'hf legic decode'
that's nice

[== Undefined ==]
pm3 --> hf legic reader
#db# setting up legic card                 
#db# MIM 256 card found, reading card ...                 
#db# Card read, use 'hf legic decode' or                 
#db# 'data hexsamples 256' to view results                 
pm3 --> hf legic decode

CDF: System Area          
MCD: 40, MSN: 76 35 de, MCC: ee          
DCF: ff ff, Token_Type=GAM (OLE=1), Stamp_len=4294967293          
WRP=00, WRC=0, RD=0, raw=00, SSC=00          
Remaining Header Area          
00 00 00 00 00 00 00 00 00 00 00 00 00           

ADF: User Area          
Segment 00: raw header=ee ee ee ee, flag=e (valid=1, last=1), len=3822, WRP=238, WRC=06, RD=1, CRC=ee          
WRC protected area:          
ee ee ee ee ee ee           
Remaining write protected area:          
ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee           
Remaining segment payload:          
ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee           
pm3 -->

iceman · 2016-01-23 21:53:03

yeah, its still there, but you should at least get som data out of it.

may 0xEE in your output, it that normal?

mosci · 2016-01-23 22:49:23

0xee seems to be normal on the blank card
it's also the crc of the uid and the data is xored with this crc - so 0x00 ^ 0xee will give 0xee (vice versa)

[== Undefined ==]
pm3 --> hf legic reader
#db# setting up legic card                 
#db# MIM 256 card found, reading card ...                 
#db# Card read, use 'hf legic decode' or                 
#db# 'data hexsamples 256' to view results                 
pm3 --> data hexsamples 256
40 76 35 de ee ff ff 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00          
00 00 00 00 00 00 00 00

the original proxmark3-client only crashes on those blank cards

Last edited by mosci (2016-01-26 14:42:38)

mosci · 2016-01-23 23:02:17

here ist a 'decode' from the main repository

[== Undefined ==]
proxmark3> hf legic read
#db# setting up legic card                 
#db# MIM 256 card found, reading card ...                 
#db# Card read, use 'hf legic decode' or                 
#db# 'data hexsamples 256' to view results                 
proxmark3> hf legic decode

CDF: System Area          
MCD: 40, MSN: 76 35 de, MCC: ee          
DCF: ff ff, Token_Type=GAM (OLE=1), Stamp_len=4294967293          
WRP=00, WRC=0, RD=0, raw=00, SSC=00          
Remaining Header Area          
00 00 00 00 00 00 00 00 00 00 00 00 00          

ADF: User Area          
Segment 00: raw header=ee ee ee ee, flag=e (valid=1, last=1), len=3822, WRP=238, WRC=06, RD=1, CRC=ee          
WRC protected area:          
ee ee ee ee ee ee           
Remaining write protected area:          
ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee           
Remaining segment payload:          
Segmentation fault (core dumped)

so, the data could be read also ... but the client crashes

mosci · 2016-01-23 23:11:50

I'm missing a edit-function here
ok, the payload was not shown on the 'main version' - but on your fort - that's better!
but I can only write one byte at once - at the moment
like 'hf legic write 0x10 0x01'
I would like to make a working copy of my card
there have to be 39 bytes written (with new calculated crc - like in the s_xxxx.hex)
the DCF has to be decremented, so it fits also .. and and and ... so lot of things to learn for me

iceman · 2016-01-24 10:03:23

yeah, I saw that too when I was browsing the legic code. It should really need some fixing.
as of now, you can write a lua script with all your write calls, that should work for you.

mosci · 2016-01-24 10:11:08

from my (simple) point of view ...
to 'copy the payload' of a card and set the DCF (except the UID and the CRC of the UID)
I need to do following:

1. encode the decoded payload based on the CRC of the blank-card UID-CRC and obfuscate it in reverse
2. load the encoded data into proxmark3 'hf legic load'
3. write it byte by byte to the tag ( or write a lua-script to do so - like Iceman mentioned )
4. decrement the DCF to the value of the value of the original tag

I can write from address 0x07 to 0xff
but beside a missing 'encode & obfuscate' function
the obfuscation is known - but it gets me confused for know ... will be clearer over time - I hope
I'm not able to decrement DCF (0x05 & 0x06) with 'legic write 0x06 0x01' - even not if I uncommented in legicrf.c 's function 'legic_write_byte'

[== C ==]
if(addr <= 0x06) {
  return 0;
}

AntiCat mentioned in this forum, that the 0x06 has to written first ( http://www.proxmark.org/forum/viewtopic.php?pid=7379#p7379 ) - but even that worked not out for me
there has also being noticed that the LSB has to be written first (lLSB=least significant bit) - but how to write bit-wise? - I can only write bytes!?! so my guess was AntiCat just meant the 'lower byte' (0x06) of both DCF bytes (0x05 & 0x06)

I'm not sure if it will be enough to copy the payload from one tag to another, might be that the UID is also part of the authentication, but to test it - I need to test it
If it just takes some blank tags to get some contributors working on all the needed stuff - no problem I do have some and will get more soon

Last edited by mosci (2016-01-24 10:27:26)

iceman · 2016-01-24 10:33:59

I think you can skip the second step in your process. You'll need to load data from file in the lua script instead.
and loop every byte / position there.

If you have some extra legic tags, I'll take one or two

mosci · 2016-01-24 10:41:28

iceman wrote:

If you have some extra legic tags, I'll take one or two

I'm pretty sure that you can (at least) create a 'encode' funtion - and you do have my email-addrress - so send me a address and I will send you one of my 3 blank cards tomorrow
It will take a while (a couple of weeks) until my keyfob tags come around

Last edited by mosci (2016-01-24 10:51:03)

mosci · 2016-01-24 22:21:03

first simple approach to loop the write command write from 0x07 to 0xff
but that does not help much as long as the data is not correct (CRC is still from the old card - which can not work)
the segment 0 is marked as valid but much to long and differs in length and WRP

clone-card:
the segment 0

Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=1802, WRP=03, WRC=00, RD=0, CRC=95

segment 1 is not valid

Segment 01: raw header=xx xx xx xx, flag=b (valid=0, last=1), len=2722, WRP=176, WRC=02, RD=1, CRC=ba

original-card:
Segment 0

Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=0013, WRP=04, WRC=00, RD=0, CRC=92

segment 1

Segment 01: raw header=xx xx xx xx, flag=c (valid=1, last=1), len=0100, WRP=03, WRC=03, RD=0, CRC=da

so ... there is need for a encode-function which will convert a 'handmade' hex-file into a valid legic.dump
anyway writing byte by byte through lua works fine - but the snippet is quite ugly code-style (minimized)

-- this script writes bytes 8 to 256 on the Legic MIM256
-- data has to be loaded from the original tag first with 'hf legic reader' or 'hf legic load cardump.hex' 

-- convert integer to hex
function num2hex(num)
   local hexstr = '0123456789abcdef'
   local s = ''
   while num > 0 do
      local mod = math.fmod(num, 16)
      s = string.sub(hexstr, mod+1, mod+1) .. s
      num = math.floor(num / 16)
   end
   if s == '' then s = '0' end
   return s
end
  
-- simple loop-write from 0x07 to 0xff
function main(args)
        local mycmd=""
        local startaddr=0
        local i
        core.clearCommandBuffer()
        for i = 7, 255 do
            if i <= 15 then
                startaddr = "0x0" .. num2hex(i)
            else
                startaddr = "0x" .. num2hex(i)
            end
            mycmd="hf legic write " .. startaddr .. " 0x01"
            print(mycmd)
            core.console( mycmd )
        end
end

main(args)

mosci · 2016-01-25 19:43:50

ok, got the segment 00 cloned
original:

ADF: User Area          
Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=0013, WRP=04, WRC=00, RD=0, CRC=92          
Remaining write protected area:          
xx xx xx xx           
Remaining segment payload:          
xx xx xx xx

clone:

ADF: User Area          
Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=0013, WRP=04, WRC=00, RD=0, CRC=92          
Remaining write protected area:          
xx xx xx xx           
Remaining segment payload:          
xx xx xx xx

now I have to check if it's opens the door also - tomorrow
Edit:
suppose it will not be enough - as long as I can't write (decrement) DCF an calculate the crc for byte 0x21
but the crc in byte 0x21 is 0x00 on my original card - which confuses me a little
I still have a GAM-type and a stamp_len of 4294967293 (should be SAM and 18) - thus the reader wouldn't accept this card for authentification - I'm a little bit scared to put that in front of the official reader
for decrementing DCF it should be possible to write byte 0x06 & 0x05 at once (in that order!?)
Edit II:
like suspected ... it will not be enough to have a valid/correct segment (at least here) - I need to figure out how to change the token,dcf and stamp_len for the next try - that's gonna be much harder

Last edited by mosci (2016-02-16 09:48:05)

mosci · 2016-01-31 19:48:11

I've forked the git-repo and added a (dirty - more or less copy & paste) possibility to write direct to the tag without the need to read the tag-data into the buffer before
this makes it a bit faster do write certain bytes (specially DCF)
of cause you will have to xor the values with your uidCRC before you write at addresses above 0x21

hf legic writeRaw <address> <byte>
eg: hf legic writeRaw 0x22 0xff

for security-reasons I added a Y/N question if you want to write at address 0x05 or 0x06
I wasn't able to write to 0x05, but was able to write to 0x06 - unfortunately I set it accidentally to 0x00 on my both cards
so I have to wait until my keyfobs have arrived to test 0x05 again.

Last edited by mosci (2016-01-31 19:49:51)

mosci · 2016-02-04 21:36:14

I don't get it ...
according to the slides from H. Plötz and K. Nohl presented at the 26c3 ...
at Slide 68: 'Segment header is 4 bytes + 1 byte CRC'

how can have 2 identical header (first 4 bytes) then have a different CRC (fifth byte)?
and both are perfectly working cards! (official created & totally different UID)
so, from my point of view, this can not be - or am I wrong?
thus the CRC must be calculated in a different way - or it is no CRC at all?

dcf, token_type and stamp_len also the same on both cards ...
UID & payload differs

[== Card-Data ==]
Data Card 1
UID-CRC: 85
Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=0013, WRP=04, WRC=00, RD=0, CRC=92
...
Segment 01: raw header=yy yy yy yy, flag=c (valid=1, last=1), len=0100, WRP=03, WRC=03, RD=0, CRC=da


Data Card 2
UID-CRC: 7e
Segment 00: raw header=xx xx xx xx, flag=4 (valid=1, last=0), len=0013, WRP=04, WRC=00, RD=0, CRC=93
...
Segment 01: raw header=yy yy yy yy, flag=c (valid=1, last=1), len=0100, WRP=03, WRC=03, RD=0, CRC=db

any idea?
it differs in both cases only in one bit
Edit:
maybe because the uidCRC 0x85 is odd & uidCRC 0x7e is even?
Edit:
anonymized the segment-header

Last edited by mosci (2016-02-07 10:08:06)

mosci · 2016-02-11 17:53:27

the problem is that the timing somehow messed up over a short time and then the pm3 didn't find the ACK and stops.
you should use a lua-script to write byte by byte, that works for me.

but copy the data from one tag to another is not enough - there is a lot more to do.
I haven't a verified clone yet, so I should not tell you how to get one.

mosci · 2016-02-12 08:26:11

so .... unfortunately ...
even if my legic-reader says 'that clone is a valid credential' it don't works like the original.
I even didn't get a 'red light' from the 'beep and blink'-reader, like it does if I try to open a Door from another Facility.

mosci · 2016-02-13 17:49:32

so , thanks to iceman, we are now able to calculate the storageCRC within the PM3.

here is a brief information what I was able to do in a couple of day's of playing with the combination of TWN4 Legic 45 & PM3:
the Legic-Reader now accepting every tag with valid segments or unsegmented Master-Token.
I have created several Master-Token (IAM, SAM & SAM63) and EndUser-Token ('credentials') with the PM3.
the 'launching' Tag (SAM63) even did successfully launches the reader (the reader stores some key into it's internal database)
asking the reader to do it again results in the answer 'key already in database' - which sounds good to me - but I could not find the key in the database yet ... I do not have the full documentation for the SM-4500 chip - but at least some.

one 'funny' thing ... with my Linux-Box I was able to change the DCF-Byte 0x05 and 0x06, but not on my MacBook
(with same source-base) - from my 'feelings' it has something to do with (in)correct timing .. I was fiddling around with
and it works better or not - but it always has bad side-effects like a slow responding pm3 over time (after 1-3 minutes) - thus I gave up that 'try & error approach'.

spoofing the traffic between reader and and tag is not working for me
simulating a tag is also not possible for me - thus I have to use real tags

my 'cloned' tags don't work like the original - my reader accepts them in the same way like the original
but they don't open the door.
I'm just at the beginning of 'learning' whats possible with the TWN4 Legic - maybe/hopefully there is more outcome over time ...
it's kind of time consuming to send series of hex-strings against the reader and 'decoding' the answers - but nothing else more is possible until nobody provides me a Legic-Software like DKS-4000 or CSW-4000
but so I can learn how to program it on my own - even if it took years

iceman · 2016-02-13 18:31:30

You have done lots of succes, don't stop now.

mosci · 2016-02-14 10:31:30

yes iceman, but it's easy to get that far, if you have a reader with legic-chip and the command-set for that chip.
the goal would be to be able to do it without that legic-reader - therefor some kind of sniffing, snooping, emulating must work - which does not
at this stage, i can only use the pm3 to write my data onto the tag and verify it with the legic-reader
that is possible since years.
the only thing that changes, and that's very important to create valid tags, is your working crc-code

btw ...
found my (IAM)Key in the database of that chip and it disappears after the given timeout ... that means I should now be able to create any tag with that stamp (or longer) ... and I can create Matser-Token with any Stamp I like to ...
ok, Henryk and Karsten where able to do so years ago and without there work I should not even try to get there, but I'm happy about that anyway.

and - no, I don't stop now - I have not even started really - I'm just at the stage of gathering information

iceman · 2016-02-14 11:12:09

Did you use the suggested fix for the legic_prng? I added it to my fork, you can test it out.

mosci · 2016-02-14 13:09:47

yes - have had tested that a couple of days before also (prng_forward) but I can't see any difference
if I start the sim with the values (given in the function) 'hf legic sim 6 3 0' then I get at least some console-output from the pm3 ...
but I'm not able to interpret that for now ... I'm playing with it ... and try to understand the code ...

I started the sim ('hf legic sim 6 3 0' but it's the same as if I use 'hf legic sim 0 0 0') and told the legic-reader to continuously search for a tag, select the tag, search segment00 on tag ...
and sometimes (I guess if the IV from the reader is 0x55)
got some messages like:

pm3 --> hf legic load ../proxmark3_icsom/client/legic_dumps/s_xxxx.hex
loaded 1024 samples
pm3 --> hf legic sim 6 3 0
#db# Starting Legic emulator, press button to end
#db# Unexpected: sz:10, Data:02b, State:2, Count:0
#db# IV: 055
#db# Cycles: 9, Frame Length: 6, Time: 10173
#db# Unexpected: sz:10, Data:02b, State:2, Count:0
#db# IV: 055
#db# Cycles: 9, Frame Length: 6, Time: 10174
#db# Unexpected: sz:10, Data:02b, State:2, Count:0
#db# IV: 055
#db# Cycles: 9, Frame Length: 6, Time: 10172
#db# Unexpected: sz:7, Data:01d, State:2, Count:3
#db# IV: 055
#db# Read Nb: 0, Addr: 62
#db# Read Nb: 1, Addr: 69
#db# Read Nb: 2, Addr: 66
#db# Cycles: 9, Frame Length: 6, Time: 10175
#db# Cycles: 20, Frame Length: 11, Time: 17371
#db# Cycles: 56, Frame Length: 11, Time: 38611
#db# Cycles: 92, Frame Length: 11, Time: 59852
#db# Unexpected: sz:10, Data:02b, State:2, Count:0
#db# IV: 055
#db# Cycles: 9, Frame Length: 6, Time: 10178
#db# Unexpected: sz:7, Data:013, State:2, Count:3
#db# IV: 055
#db# Read Nb: 0, Addr: 62
#db# Read Nb: 1, Addr: 69
#db# Read Nb: 2, Addr: 66
#db# Cycles: 9, Frame Length: 6, Time: 10149
#db# Cycles: 20, Frame Length: 11, Time: 17344
#db# Cycles: 56, Frame Length: 11, Time: 38584
#db# Cycles: 92, Frame Length: 11, Time: 59825
#db# Stopped

but the legic-reader did not recognize anything - not even a tag

Last edited by mosci (2016-02-14 14:57:22)

mosci · 2016-02-18 09:44:59

So ... finally I was able to clone my official tag - and the door opens with it (or with all three of them - just to get sure)
but, since my card uses a 'Kaba Group Header - aka KGH), which is just a crc with (yet) unknown credentials, I was not able to do it completely without official reader (you need a sm-4500 to calculate the kghCRC - sm-4200 doesn't support that feature)
But to authorize the reader - I needed the pm3 (to create me a Master-Token).
I did all of the tag-manipulation (except the kghCRC-Calculation) and Matser-Token creation with the pm3.
Here are the two main things that where missing in the Master-Branch:
calculating the storageCRC LegicCRC8(thanks to iceman for implementing this)
possibility to decrease the DCF (I did a dirty hack to get that possible dirty hack)

If your card does not uses a KGH, and the readers does not uses the UID of the card in a kind of white-list - (at my place there is 'only' the KGH white-listed) - then it should be able to clone any Legic MIM.

so, next step should be to make the pm3 able to calculate that kghCRC also, I will identify the bytes, over which it gets created soon and provide some examples - so that the credentials can be reverse-engineered by a guy (or women) how feels fit enough to do so. since it is only a 8-bit crc, that should be possible.

beside the cloning ...
the sm-4500 ( I have no sm-4200 or lower version of the Legic security-module) will not accept a 'UberIAM' with stamp-len 0 or a GAM with stamp-len 1- at least I was not able to get it loaded into the Auth-DB on the reader.
A IAM with stamp-len 1 was the best I could load into the reader - but that does not matter at all, because we can create everey stamp we like to with the pm3 - changing the stamp only need to recalculate the crc on byte-addr 0x15).
And if the kghCRC is reverse-engineered - we don't even need a official sm-4500.

Last edited by mosci (2016-02-19 19:30:44)

mosci · 2016-02-18 15:59:57

a example for a user-data segment with kgh:

CDF: System Area          
MCD: DE, MSN: AD BE EF , MCC: E2         
DCF: 60 EA , Token_Type=SAM (OLE=0), Stamp_len=18       
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area          
00 00 00 11 00 00 00 00 00 00 00 00 00 

Segment 00: raw header=0d c0 04 00, flag=c (valid=1, last=1), len=13, WRP=4, WRC=00, RD=0, CRC=E9
WRC protected area:          
ee ee ee ee
Remaining segment payload:  
00 11 22 8A

the '11' in the 'Remaining Header Area' (on addr 0xc)
seems to important for official readers - setting this to '00' will result in not being accepted by the sm-4500.
at least if I try to create a kghCRC (there I have to investigate a little more), first assumption that this is the backup0-byte
did not match.

MCC = LegicCRC8 over MCD+MSN0..2 (all not changeable)

segmentCRC = LegicCRC8 over MCD + MSN0..2 + raw header0..3 (all freely writable with a pm3)

payload:'00 11 22' ... let's say 'User-ID' will be mapped to a authorized person - an can be moved out of the white-list if he loses his tag
8A will be the kghCRC calculated at least over:

the segmentHeader (0d 80 04 44), (maybe/possibly) the segmentCRC, the stamp (ee ee ee ee), and the payload (00 11 22)
obviously MCD,MSN0..2 and maybe the MCC are also involved

a working simulator could give more reliability - then I can change also the MSN to see if is involved or not - but even then the MCC also will change also - but it's more/better 'testable'

the three bytes payload seems to be 2 digit decimal values only (so not higher than 0x63) - at least at those 5 official tags I have seen - but the paylod can surly be longer than 3 bytes + crc

here are two more 'decodes' from valid segment & kgh (kghCRC created from a sm-4500, which will fail on inconsistent data in a segment):

CDF: System Area
MCD: 3e, MSN: 95 85 e2, MCC: c2
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 00 00 00 00 00 00 00 00 00

ADF: User Area
Segment 00: raw header=0d c0 04 00, flag=c (valid=1, last=1), len=0013, WRP=04, WRC=00, RD=0, CRC=a0
Remaining write protected area:
ee ee ee ee
Remaining segment payload:
00 00 00 a5

CDF: System Area
MCD: 79, MSN: 7a 74 47, MCC: 20
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 00 00 00 00 00 00 00 00 00

ADF: User Area
Segment 00: raw header=0d c0 04 00, flag=c (valid=1, last=1), len=0013, WRP=04, WRC=00, RD=0, CRC=08
Remaining write protected area:
ee ee ee ee
Remaining segment payload:
00 00 00 62

there a only 3 possibilities mentioned to restrict reader-access only to authorized tags - if the tag not match the criteria the reader will do nothing - not even blink & beep (at least in my case):
user-id white-list (KGH) -> a clone & simulator will work (that's what we use)
MCD + MSN white-list -> only a simulator will work (that's what we should use - but then we could not create 'groups' )
parts of MCD / MSN (prefix-match) white-list -> simulator & some clones may work (if they match the right part of MCD + MSN)

of cause there is a possibility to guarantee access to every tag with a valid segment, but then you don't have any possibility to act against cloned, lost or stolen tags

Last edited by mosci (2016-02-19 07:53:49)

mosci · 2016-02-24 08:04:54

some more about the kaba-group-header aka kgh:
I have found two tags with different MCD,MSN but same MCC (CRC over MCD & MSN0..2)
I've configured them to have the same stamp (4 bytes) and the same payload of 4 bytes (incl. kghCRC)
this results in the same kghCRC (addr 0x22) on both tags.
Furthermore it was clear to see and 'along the way' noticed that addr 0x18 & 0x19 (WRP/WRC/RD) are involved in the calculation.
since the kghCRC did not change while adding or deleting additional segments, or changing the length of the payload or stamp, addr 0x016 & 0x017 ( segment-len, 'valid' & 'last' flag ) are not involved at all.
addr 0x07, 0x08 & 0xc have to be set to 0x9f, 0xff & 0x11 - otherwise the SM-4500 reports an error and will not create a kghCRC -
at least at this setup (4 bytes stamp & 3 bytes payload + kghCRC)

on this setup, the parameters for the correct calculation of a kghCRC (with a SM-4500) has to be set to
'crc-position': 0x07
'include-data-start': 0x00
'include-data-len': 0x07
which makes sense if ...
segment_len is 13 (segmentHeader+segmentCRC+stamp+payload / 4+1+4+4)
'crc-position' 0x07 will be 'segment-len - segmentHeader - segmentCRC + included-data'' (in my example 13-4-1=7=last addr of segment_data)
addr 0x00 for 'include-data-start will be 'segment-len - segmentHeader - segmentCRC=segment_data_start'
and 'include-data-len' 0x07 is 'stamp + payload - 1=segment_data_len - kghCRC' (4+4-1=7)

but since the kghCRC is different on Tags with same segment_data but with different MCC - there is more involved than just this -
at least the MCD and/or MSN0..2 and/or MCC (should be MCD & MSN0..2).
I guess there is nothing more to poke at this stage (without a working simulator and/or oscilloscope) the only thing I can do is: create some some examples with different stamps & payload (e.g. stamp 0x00 0x00 0x00 0x00, 0x00 0x00 0x00 0x01 ...) but even then, someone has to reverse-engineer the crc-credentials since it does not seems to be the storageCrc (aka legicCrc8).
and reversing the kghCRC by not knowing surly which bytes ar included (and in which order) would be pain in the a**
I have tried many possible combinations ... surly not all ... but since SM-4200 and lower versions can not create the kghCRC, I strongly believe that here comes another credential-set/procedure into place.

btw: my fork includes a lua-script 'legic_clone.lua' which produces a working clone if the clone-Tag has the same MCC like the original Tag (even if a kghCRC is used)

Last edited by mosci (2016-02-24 08:37:30)

mosci · 2016-02-24 19:20:44

got it ...
at least almost ...
I can not explain one credential (yet) for the kghCRC, but I can at least create it
first ... it's also the LegicCrc8 over:
MCD+MSN0..2+WRP+WRC+RD+00+Stamp0..n+Payload0..n
here is a very simple (but valid) excample:

CDF: System Area
MCD: 3e, MSN: 79 83 e2, MCC: 31
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 00 00 00 00 00 00 00 00 00

ADF: User Area
Segment 00: raw header=08 c0 01 00, flag=c (valid=1, last=1), len=0008, WRP=01, WRC=00, RD=0, CRC=8e (valid)
Remaining write protected area:
00
Remaining segment payload:
00 c4

so the kghCRC in this example is C4
let's verify it with pm3 and Iceman's LegicCrc8 functionality:

proxmark3> hf legic crc8 3e7983e2010000000000
Bytes: 3e 79 83 e2 01 00 00 00 00 00  || CRC8: C4

confirmed
explanation:

3e MCD 
79 MSN0
83 MSN1
e2 MSN2
01 WRP
00 WRC
00 RD
00 ??
00 Stamp0
00 Payload0

stamp and payload in this example are very short - you won't find it in 'real life scenarios' that way - but it was easier to poke against it that way ;-)
have verified that on three valid tags (stamp 4 bytes & payload 4 bytes) -> works on all of them
(would be nice to get some more/different valid dumps to verify even more)
so, maybe 'clone' is the wrong wording - but we can at least create valid Legic-Prime Tags without the need of a Legic Security-Module

Last edited by mosci (2016-02-24 20:20:12)

iceman · 2016-02-24 20:36:40

Sweet work bro!
You have done great progress here. With your lua-scripts, you have made a good contribution to the community

ikarus · 2017-04-12 17:39:46

First of all: Thank you, mosci and iceman, for your amazing work on the KGH and Legic Prime in general!

I've got my hands on some Legic Prime tags that have a KGH. However, the data is arranged
in a different way, which breaks mosci's assumption on how the KGH is calculated.

Tag 1:

CDF: System Area
MCD: 41, MSN: a2 1a 9b, MCC: b7
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 04 89 c0 04 c0 dd 83 00 00

ADF: User Area
Segment 00: raw header=16 40 0a 30, flag=4 (valid=1, last=0), len=0022, WRP=10, WRC=03, RD=0, CRC=11
WRC protected area:
fb 0a 01
Remaining write protected area:
02 02 01 32 16 01 ad
Remaining segment payload:
00 00 00 00 00 00 00

Tag 2:

CDF: System Area
MCD: 41, MSN: a1 22 9b, MCC: 8c
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 04 89 c0 04 c0 f2 cb 00 00

ADF: User Area
Segment 00: raw header=16 40 0a 30, flag=4 (valid=1, last=0), len=0022, WRP=10, WRC=03, RD=0, CRC=3e
WRC protected area:
fb 0a 01
Remaining write protected area:
02 02 01 32 17 01 13
Remaining segment payload:
00 00 00 00 00 00 00

The KGH-CRC of tag 1 is "0xad" and of tag 2 "0x13". The "0x11" in the Header is also there.
Until now I did not figured out what bytes are included in the calculation and in what order.
But I'm sure it is a KGH because cloning these tags does only work, if the MCC (UID checksum)
is identical.

Feel free to join me in the search for the algorithm behind the KGH.

EDIT:
I do not have the possibility to create arbitrary tags with KGH in order to see how the CRC is changing.

Last edited by ikarus (2017-04-12 17:44:03)

mosci · 2017-04-13 16:25:17

I don't think that this is a KGH - because I would expect that at the end of the payload, not at the end of the 'write-protected area'.
you can see in the legic.lua what bytes are needed for a kgh

I suppose that this is a 'ordinary' legic-crc8 over various bytes (which have to be figured out)

unfortunately the legic.lua do not work on iceman's fork - so you should use mine instead - there you will find also a undocumented 'map' functionallity - which will surly help on such tasks (thats what I did it for)

Last edited by mosci (2017-04-13 16:28:16)

mosci · 2017-04-13 18:44:11

ok - seems not to be a kgh
but I found out how to calculate it
( it worked at least for your two exmples )
and because it was quite simple ... I guess you can do it too.

I don't understand your assumption
'But I'm sure it is a KGH because cloning these tags does only work, if the MCC (UID checksum)
is identical.'

This only tells me, that the mcd+msn0..msn2 (address 0x00..0x03) is included in the checksum -
like always - except on legic-cash segments.

this was my 'testobject' - all crc should be valid

CDF: System Area
MCD: 3e, MSN: 4b 84 e2, MCC: b2
DCF: 60 ea, Token_Type=SAM (OLE=0), Stamp_len=18
WRP=15, WRC=1, RD=1, raw=9f, SSC=ff
Remaining Header Area
00 00 00 11 01 0d c0 08 40 ec 13 00 00

ADF: User Area

Segment 00: raw header=16 40 0a 30, flag=4 (valid=1, last=0), len=0022, WRP=10, WRC=03, RD=0, CRC=90 (valid)
WRC protected area:
fb 0a 01
Remaining write protected area:
02 02 01 32 17 01 10
Remaining segment payload:
00 00 00 00 00 00 00

Segment 01: raw header=0d c0 04 00, flag=c (valid=1, last=1), len=0013, WRP=04, WRC=00, RD=0, CRC=00 (valid)
Remaining write protected area:
00 01 02 03
Remaining segment payload:
04 05 06 07

Last edited by mosci (2017-04-13 20:20:12)

iceman · 2017-04-14 01:18:03

Without @mosci all changes wouldnt have been done at all. But we didnt get it all the way, the sim command is still broken.

However all knowledge inside mosci's scripts is a great souce for those who wants to learn about Legic Prime.

I still need Legic Advant datasheets, if someone has them feel free to send them to me.

mosci · 2017-04-14 11:14:07

@ikarus
don't get me wrong ... it's not that I'm not willing to help -
but I guess this forum is not meant to copie tags for anyone - but meant
to help to learning about the tags and make the proxmark3 even better.

It takes me less than 5 minutes to figure out which bytes are used to caclulate this checksum.
that's such a less effort - that I have to think that you don't even have tried it

there are not millions of bytes - just 35 of them could be involved
if we think simple, and focus on the segment, where the crc8 is placed,

look at the the simple facts of a simple tag and a so called 'security-module' of legic:
- you can use the MCD+MSN bytes while create a crc - but you don't have to.(in your case they seem to be used)
- to create a crc with a security-module - you can use any userdata-bytes within your desired segment - except the header/header-crc
- to create a KGH some of the segment-header-bytes are involved too
- to create a crc the security-module can not skip back&forth while collecting the data - just one direction -> forward

and some now som facts about your tag:
- the segment is 22 bytes long
- the segment header has 4 bytes
- the segment header-crc is one byte
- the userdata must by 17 bytes
- 7 bytes of the userdata are placed behind the crc - so they can not be involved
- 1 byte is the crc itself - that can also not be involved
- only 9 bytes left - if we don't need the header / maximumm 14 bytes if it is a KGH

so, we can assume:
1. the MCD+MSN0..MSN2 is involved in the crc
2. some or all of the first 9 bytes of userdata are involved
3. the first 3 bytes seems to be the stamp
4. the next 6 bytes might be employee/company/facility/'security' related
5. then there is the crc
6. the rest seems to be unused, but reserved - we can ignore that for now

so take assumption 1 & 2 will lead us to a first try like:
in my test

proxmark3> hf legic crc8 3e4b84e2fb0a01020201321701
Bytes: 3e 4b 84 e2 fb 0a 01 02 02 01 32 17 01  || CRC8: 10

and verify with your examples

proxmark3> hf legic crc8 41a21a9bfb0a01020201321601
Bytes: 41 a2 1a 9b fb 0a 01 02 02 01 32 16 01  || CRC8: AD
proxmark3> hf legic crc8 41a1229bfb0a01020201321701
Bytes: 41 a1 22 9b fb 0a 01 02 02 01 32 17 01  || CRC8: 13

that was not so hard to find out - ha?

FYI:
some of my 'facts' are only assumptions from my tests/work
but until they are not disproved - I will call them facts

Last edited by mosci (2017-04-14 11:22:19)

ikarus · 2017-04-14 15:42:09

First of all: Thank you! I was really stuck.

mosci wrote:

unfortunately the legic.lua do not work on iceman's fork - so you should use mine instead - there you will find also a undocumented 'map' functionallity - which will surly help on such tasks (thats what I did it for)

I was already using your fork. But did not stumble upon the map function yet.

mosci wrote:

I don't understand your assumption
'But I'm sure it is a KGH because cloning these tags does only work, if the MCC (UID checksum)
is identical.'

This assumption was build on the fact, that in your case, the MCD+MSN0..MSN2 was part of the
KGH-CRC. And as I noticed that in my case the MCD+MSN0..MSN2 is also part of the CRC,
I thought it is a KGH-CRC (It's my first time playing with Legic Prime). Also, I think the
reader is build by the Kaba Group.

mosci wrote:

It takes me less than 5 minutes to figure out which bytes are used to calculate this checksum.
that's such a less effort - that I have to think that you don't even have tried it wink

Oh I have tried. A lot actually. But I guess I made some very wrong assumptions. I did
stick too much to your example. I was too sure that this CRC is very similar to yours. So
I figured it must contain the same parts of the header like yours does. Therefore, I did not drop
any of the components (like the WRP, WRC, etc.) and spend lot of time on figuring out
what that unknown component of your example is. I thought because my example is
different, there might by another unknown component like your "0x00"... Well, I was wrong.

mosci wrote:

@ikarus
don't get me wrong ... it's not that I'm not willing to help - but I guess this forum is not
meant to copie tags for anyone

Don't worry, I've been here long enough to notice that. I just thought this would be the
right place since you posted your progress on your research here too. If this makes
you feel any better: I'm a Pentester and I was investigating the security of a
access control system. I'm not trying to copy tags for illegal reasons

iceman wrote:

Without @mosci all changes wouldnt have been done at all. But we didnt get it all the way, the sim command is still broken.
However all knowledge inside mosci's scripts is a great souce for those who wants to learn about Legic Prime.
I still need Legic Advant datasheets, if someone has them feel free to send them to me.

You are right, iceman, the scripts were a pretty good source to understand what is going on. And they really helped me
to make the Legic Prime pentesting more effective. A working sim command would of course be perfect.
One of the systems I was investigating checks the UID and the data on the tag. You can only overcome it
with a 100% identical clone. But I do understand that fixing the sim command is not that easy. Especially if
you don't own a Legic reader (I don't have one either). Also, I did not find any UID changeable Legic tags,
like there are for Mifare Classic. That would have been awesome.

Last edited by ikarus (2017-04-14 15:44:30)

mosci · 2017-04-14 16:11:18

np
here is a sample-mapfile for your tag, including segment00
there must be at least one segment more on the tag
(save it as ikarus.map in the client-folder and load it iwith the cmd 'lm' within the main-menu of the legic.lua)

choose the cmd 'em', to enter the 'edit-map submenu' and play a litlle with it
the cmd 'sc8' will let you check a single mapped crc8 - and it will compare
the calculated value to the one on the tag ...
such mappings might help to investigate on unknown legic-prime-tags
there is a undocumented cmd called 'mas' which means 'map all segments'
this tries to identify segments & segment-crc on it's own - this might be a good startingpoint
for unknown (legic-prime) tags

since anyone can create a uniq 'application' for such tags, there are a lot of variants out there
but all of them have to respect the security-module features.

name,ikarus
crc8,1,TAG-CRC,5,1-4
crc8,2,Segment 00 CRC,27,1-4,23-26
crc8,3,CRC8,37,1-4,28-36
mappings,1,Tag-ID,1,4,1
mappings,2,Tag-CRC,5,5,0
mappings,3,DCF,6,7,1
mappings,4,THDR-Raw/Stamp-Len,8,8,1
mappings,5,SSC,9,9,1
mappings,6,Header,10,13,0
mappings,7,Backup,14,19,1
mappings,8,Bck-CRC,20,20,0
mappings,9,TokenTime,21,22,0
mappings,10,Segment 00 HDR,23,26,0
mappings,11,Segment 00 CRC,27,27,1
mappings,12,Stamp,28,30,0
mappings,13,WRP-1,31,36,0
mappings,14,CRC8,37,37,1

I thougt about collecting such maps and automaticly try to apply them to unknown tagdata - if one matches, then I know what kind of tag it is.
but I don't have much of them collected until know
but again - one segment more

Last edited by mosci (2017-04-14 16:26:08)

pentoo423 · 2017-04-15 10:42:04

which blanco cards are u using here?

mosci · 2017-04-15 12:10:38

Legic Prime aka MIM256 / MIM1024

Jason · 2017-04-20 09:47:03

mosci wrote:

some of my 'facts' are only assumptions from my tests/work
but until they are not disproved - I will call them facts

So I would like to un-fact one of your facts

The CRC calculation, you are handling in your script, is wrong ... After reading this thread I took a closer look into the script and noticed it. It's just working under special cases, but not in a common way.
Two assumptions are wrong:

1)
The KGH (KABA Group Header) ist not just limited to a segment size of 8 bytes. The KGH is a definition of the first 8 bytes only. The segment itself could be at any size. The KGH defines simply the following structure in the begining of the segment:
[4 byte STAMP] [3 Byte BCD encoded card number (CN)] [CRC8] ... after here any length of user bytes may follow.

2)
The CRC generation is not correct, and it only will work for normal KABA segments with it's default WRP/WRC/RD settings. Other combinations will fail.
You are calculating:

 [MCD]
 [MSN0]
 [MSN1]
 [MSN2]
 [WRP]
 [WRC]
 [RD]
 [0x00/0x93]
 [STAMP0]
 [STAMP1]
 [STAMP2]
 [STAMP3]
 [CN0]
 [CN1]
 [CN2]

Thats not the correct order, the correct one is:

 [MCD]
 [MSN0]
 [MSN1]
 [MSN2]
 [WRP]
 [0x00]
 [WRC]
 [RD]
 [STAMP0]
 [STAMP1]
 [STAMP2]
 [STAMP3]
 [CN0]
 [CN1]
 [CN2]

With this order any parameter combination will calculated correctly.

Just want to know more? ...
The CRC calculation it configurable, you can decide what kind segment-parameter option are included or not. So you will get 2 additional calculation modes:

 ...
 [MSN2]
 [WRC]
 [RD]
 [STAMP0]
 ...

 ...
 [MSN2]
 [RD]
 [STAMP0]
 ...

Other combinations are not possible. But, just to noticed that: I never saw someone using the other 2 possible configurations... With the newest advant-Series (4000) this modes are not possible anymore. You can use KGH style, or not... thats it.

And to give some more nice information:
The KGH segment style is present on advant too, but there the CRC ist not calculated the same way. The CRC on advant is just strictly user-data based. No UID is included, no segment parameters, nothing just the user data itself. So the CRC8 calculation for a advant segment ist:

 [CN0]
 [CN1]
 [CN2]

Like to know the the CRC8 parameters? ... Here it is:

width=8  poly=0x07  init=0xFF  refin=false  refout=false  xorout=0x00  check=0xFB

I use this for some years now to save time on segment creation, and no competitor does know how I do this ... okay, now this may change

Edit:
BTW: KGH is the common segment-style used by about 90% of the market. Some modified the KGH a little but, just say expanded the CN field to 4 bytes or does not do a BCD encoding (they do binary encoding). But except this little differences the structure is the same.

Last edited by Jason (2017-04-20 10:01:24)

Dot.Com · 2017-08-21 08:34:06

Can someone guide me on legic prime ?

Like how to operate mosci script ?

Till date, I am still unclear about it.

mosci · 2017-08-22 10:44:30

@Dot.com
if you want to sell the script (or parts of it) - you have to understand & rewrite it anyway

Last edited by mosci (2017-08-22 15:40:32)

Dot.Com · 2017-08-23 05:09:49

Not selling it.

Just want to solve it.

Legic is such a small market I believe. Not much of a commercial value too.

I have friends who need to understand how it works so we can pen test on some system.

So just asking on his behalf.

mosci · 2017-08-28 15:41:01

'how to use' can be read in the source ...
but you have to find a branch/fork which works together with the script...
I don't know if the script has being updated to work with the iceman-fork also ... otherwise you will have to use my old fork or
make it work with your preferred fork/branch.

the script covers only application/segments which I could test - so there might by a lot of segments on which it wouldn't work unless it gets updated.
once, all requirements are solvedyou can can clone a tag in 3 steps:
1. start the script in the pm3-shell ('script run legic')
2. read the original tag ('rt')
3. write the new tag ('wt')

so, nothing really comlicated ;-)
there are a lot of more features, which can be found while reading the source ;-)

Dot.Com · 2017-08-28 19:21:23

Thanks Mosci. Really appreciate it. We will provide the results when if it works. Will be testing with Lohcm88.

I am left with 1 Legic Prime so I guess our good friend lohcm88 got to test it since he has 2 on his hands.

717 · 2017-10-05 13:53:50

thanks

Proxmark · 2019-12-16 18:57:57

mosci wrote:

Legic Prime aka MIM256 / MIM1024

Hello ,
i know this is a novice question but it's my first step in this amazing world of PM3 , we do use LEGIC PRIME MIM 1024 CARD
cards for door access (and KABA controllers) and i was able to simulate some badges using the PM3 , i searched lot to see if it's possible to clone the cards into other blank cards , and i went also through the amazing job of "mosci" and his great contribution to understand this type of cards. in this article .

unfortunately i have not found lot of resources talking about this cloning and the most valuable information i found them in this forum , as far as see it's "only" possible to clone Legic cards into an other " Blank Legic Cards" and then do the adjustment for CRC ..etc.

My Question : there is a lot of blank cards in market (eBay,Amazon,....) and they are UID writable too, so is there any way to write the dump of Legic prime card into this fully writable cards (UID included) ? i am not 100% sure if the micro-controller inside this cards that make them so different , if so can the card dump be adjusted or the micro-controller (like reprogram it) to behave as an Legic card ?

I Hope my question make sense , and sorry if it's really novice question ^_^"

*my contribution, i saw in the article of "mosci" that he was limited to the available tags to him to decode all the information inside , we do have a bunch of this cards "LEGIC PRIME MIM 1024 CARD" if you need dump or something to help progressing this work i will be glad to provide this information

zeppi · 2021-04-03 15:29:44

I tried to make a valid copy of a Legic MIM256 time punch card to a blank Legic MIM256 card, and I am still missing pieces to the puzzle:

Dump the original card in deobfuscated/editable format:
hf legic dump --deobfuscate -f original

Wipe the blank card where we want to restore the dump onto:
hf legic wipe

Dump the blank card to get the first 7 bytes:
hf legic dump -f blank

Copy the first 7 bytes from blank.bin to original.bin (overwrite the first 7 bytes in original.bin)
(I wonder why the restore --obfuscate command is using the MCC in the dump file, would it not make more sense to use the MCC of the card that we are writing to, as the MCC cannot be changed anyway?)

Write the modified dump to the blank card:
hf legic --obfuscate -f original.bin

Is there anything else that needs to be done for a copy that is accepted by the reader?

I saw that the DCF of the blank card is FFFF and not 60EA as in the original card? How can we correct the DCF?
Any scripts available for this?

As the blank has a DCF of FFFF, can we create a master token somehow? Are there scrips available for this?

Last edited by zeppi (2021-04-03 15:37:46)

Proxmark3 community

Announcement

#1 2013-06-08 08:24:23

Clone Legic to blank card

#2 2013-06-08 22:46:58

Re: Clone Legic to blank card

#3 2013-08-05 00:43:22

Re: Clone Legic to blank card

#4 2016-01-23 11:57:23

Re: Clone Legic to blank card

#5 2016-01-23 17:47:49

Re: Clone Legic to blank card

#6 2016-01-23 21:23:13

Re: Clone Legic to blank card

#7 2016-01-23 21:53:03

Re: Clone Legic to blank card

#8 2016-01-23 22:49:23

Re: Clone Legic to blank card

#9 2016-01-23 23:02:17

Re: Clone Legic to blank card

#10 2016-01-23 23:11:50

Re: Clone Legic to blank card

#11 2016-01-24 10:03:23

Re: Clone Legic to blank card

#12 2016-01-24 10:11:08

Re: Clone Legic to blank card

#13 2016-01-24 10:33:59

Re: Clone Legic to blank card

#14 2016-01-24 10:41:28

Re: Clone Legic to blank card

#15 2016-01-24 22:21:03

Re: Clone Legic to blank card

#16 2016-01-25 19:43:50

Re: Clone Legic to blank card

#17 2016-01-31 19:48:11

Re: Clone Legic to blank card

#18 2016-02-04 21:36:14

Re: Clone Legic to blank card

#19 2016-02-11 17:53:27

Re: Clone Legic to blank card

#20 2016-02-12 08:26:11

Re: Clone Legic to blank card

#21 2016-02-13 17:49:32

Re: Clone Legic to blank card

#22 2016-02-13 18:31:30

Re: Clone Legic to blank card

#23 2016-02-14 10:31:30

Re: Clone Legic to blank card

#24 2016-02-14 11:12:09

Re: Clone Legic to blank card

#25 2016-02-14 13:09:47

Re: Clone Legic to blank card

#26 2016-02-18 09:44:59

Re: Clone Legic to blank card

#27 2016-02-18 15:59:57

Re: Clone Legic to blank card

#28 2016-02-24 08:04:54

Re: Clone Legic to blank card

#29 2016-02-24 19:20:44

Re: Clone Legic to blank card

#30 2016-02-24 20:36:40

Re: Clone Legic to blank card

#31 2017-04-12 17:39:46

Re: Clone Legic to blank card

#32 2017-04-13 16:25:17

Re: Clone Legic to blank card

#33 2017-04-13 18:44:11

Re: Clone Legic to blank card

#34 2017-04-14 01:18:03

Re: Clone Legic to blank card

#35 2017-04-14 11:14:07

Re: Clone Legic to blank card

#36 2017-04-14 15:42:09

Re: Clone Legic to blank card

#37 2017-04-14 16:11:18

Re: Clone Legic to blank card

#38 2017-04-15 10:42:04

Re: Clone Legic to blank card

#39 2017-04-15 12:10:38

Re: Clone Legic to blank card