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
Hi there,
I have a Legic Prime 1024 with a Legic-Cash on segment 02 and some other data in the other segments.
My goal is the clone the complete card or at least to manipulate certain information stored on it.
So, I first got the latest iceman version and started my tests....
[ CLIENT ]
client: iceman build for RDV40 with flashmem; smartcard;
[ ARM ]
bootrom: master/v3.0.1-361-ge069547-suspect 2018-04-16 16:04:18
os: iceman/master/ice_v3.1.0-1057-g2a6a727d 2018-09-21 14:15:30
[ FPGA ]
LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23
[ Hardware ]
--= uC: AT91SAM7S256 Rev D
--= Embedded Processor: ARM7TDMI
--= Nonvolatile Program Memory Size: 256K bytes, Used: 237342 bytes (91%) Free: 24802 bytes ( 9%)
--= Second Nonvolatile Program Memory Size: None
--= Internal SRAM Size: 64K bytes
--= Architecture Identifier: AT91SAM7Sxx Series
--= Nonvolatile Program Memory Type: Embedded Flash MemoryThat is the source card looks like...
pm3 --> hf legic info
hf legic info
Reading tag memory 1024 b...
CDF: System Area
------------------------------------------------------
MCD: 41, MSN: 01 74 e5, MCC: fe OK
DCF: 60000 (60 ea), Token Type=IM-S (OLE=0)
WRP=15, WRC=1, RD=1, SSC=ff
Remaining Header Area
00 00 00 11 02 21 C0 08 70 F4 0F 00 00
ADF: User Area
------------------------------------------------------
Segment 01
raw header | 0x15 0x40 0x08 0x40
Segment len: 21, Flag: 0x4 (valid:1, last:0), WRP: 08, WRC: 04, RD: 0, CRC: 0x16 (OK)
WRC protected area: (I 27 | K 0| WRC 4)
row | data
-----+------------------------------------------------
[00] | 2C 2D 00 05
Remaining write protected area: (I 31 | K 31 | WRC 4 | WRP 8 WRP_LEN 4)
row | data
-----+------------------------------------------------
[00] | 48 68 84 60
Remaining segment payload: (I 35 | K 35 | Remain LEN 8)
row | data
-----+------------------------------------------------
[00] | 00 00 00 00 00 00 00 00
-----+------------------------------------------------
Segment 02
raw header | 0x21 0x40 0x08 0x70
Segment len: 33, Flag: 0x4 (valid:1, last:0), WRP: 08, WRC: 07, RD: 0, CRC: 0xD6 (OK)
WRC protected area: (I 48 | K 43| WRC 7)
row | data
-----+------------------------------------------------
[00] | 0C 01 01 31 01 00 2C
Remaining write protected area: (I 55 | K 55 | WRC 7 | WRP 8 WRP_LEN 1)
row | data
-----+------------------------------------------------
[00] | 01
Remaining segment payload: (I 56 | K 56 | Remain LEN 20)
row | data
-----+------------------------------------------------
[00] | 02 01 00 1A E4 00 00 00 00 01 00 0C 02 01 31 01
[01] | 00 2C 42 6B
-----+------------------------------------------------
Segment 03
raw header | 0x25 0xC0 0x08 0x70
Segment len: 37, Flag: 0xC (valid:1, last:1), WRP: 08, WRC: 07, RD: 0, CRC: 0xF9 (OK)
WRC protected area: (I 81 | K 76| WRC 7)
row | data
-----+------------------------------------------------
[00] | 0C 02 01 31 01 00 2C
Remaining write protected area: (I 88 | K 88 | WRC 7 | WRP 8 WRP_LEN 1)
row | data
-----+------------------------------------------------
[00] | 01
Remaining segment payload: (I 89 | K 89 | Remain LEN 24)
row | data
-----+------------------------------------------------
[00] | 03 D2 01 38 7F 7E D8 00 00 00 10 00 01 BE 8B 00
[01] | 00 00 10 00 01 EB 84 A5
-----+------------------------------------------------After a successful dump of the card I first tried to write the complete dump on a new and empty card which looks like this.
pm3 --> hf legic info
hf legic info
Reading tag memory 1024 b...
CDF: System Area
------------------------------------------------------
MCD: 77, MSN: 4b 61 45, MCC: 4b OK
DCF: 65535 (ff ff), Token Type=NM (New Media)I tried the restore and on the first glance it showed success.
pm3 --> hf legic restore i 410174E5
hf legic restore i 410174E5
TYPE : MIM1024 card (1002 bytes)
Restoring to card
Wrote chunk [offset 7 | len 512 | total 519
Wrote chunk [offset 519 | len 505 | total 1024
Wrote 1024 bytes to card from file 410174E5.binBut on the new card nothing was written.
pm3 --> hf legic info
hf legic info
Reading tag memory 1024 b...
CDF: System Area
------------------------------------------------------
MCD: 77, MSN: 4b 61 45, MCC: 4b OK
DCF: 65535 (ff ff), Token Type=NM (New Media)After this not successful first step I tried to get some more success with the scripts legic and legic_clone.
I tried to read the Tag and it showed success.
pm3 --> script run legic
script run legic
[+] Executing: legic.lua, args ''
Legic command? ('h' for help - 'q' for quit) (default: h )
> rt
UID : 41 01 74 E5
TYPE : MIM1024 card (1002 bytes)
Reading emulator memory...
Saved 256 bytes from emulator memory to file: legic.temp.bin
[36m
256 bytes from legic.temp.bin loaded
create virtual tag from 256 bytes
[0m
[32mTag-Type: IAM[0m
[36m256 bytes for Tag processed[0m
Legic command? ('h' for help - 'q' for quit) (default: h )Unfortunately the written file "legic.temp.bin" is only filled with 0x00.
Nonetheless I tried to write the new and empty token.
> wt
[31m
place the (empty) Tag onto the PM3
and confirm writing to this Tag: [0m [y/n] ?y
UID : 77 4B 61 45
TYPE : MIM1024 card (1002 bytes)
Reading emulator memory...
Saved 256 bytes from emulator memory to file: legic.temp.bin
[36m
256 bytes from legic.temp.bin loaded
create virtual tag from 256 bytes
[0m
[32mTag-Type: IAM[0m
[36m256 bytes for Tag processed[0m
write temp-file 'MylegicClone.hex'
[36m
wrote 1024 bytes to MylegicClone.hex
[0m
[33menter number of bytes to write?[0m (default: 22 )I tried to read the new token but it still remained empty.
pm3 --> hf legic info
hf legic info
Reading tag memory 1024 b...
CDF: System Area
------------------------------------------------------
MCD: 77, MSN: 4b 61 45, MCC: 4b OK
DCF: 65535 (ff ff), Token Type=NM (New Media)My next step was to use the legic_clone script and therefore I first dumped my source card
pm3 --> hf legic dump
hf legic dump
TYPE : MIM1024 card (1002 bytes)
Reading tag memory 1024 b...
Wrote 1024 bytes to 410174E5.binA look in the created file and it showed at least data.....
xxd 410174E5.bin
00000000: 4101 74e5 fe60 ea9f ff00 0000 1102 21c0 A.t..`........!.
00000010: 0870 f40f 0000 ebbe f6be e8d2 d3fe fbb6 .p..............
00000020: 967a 9efe fefe fefe fefe fedf bef6 8e28 .z.............(
00000030: f2ff ffcf fffe d2ff fcff fee4 1afe fefe ................
00000040: feff fef2 fcff cfff fed2 bc95 db3e f68e .............>..
00000050: 07f2 fcff cfff fed2 fffd 2cff c681 8026 ..........,....&
00000060: fefe feee feff 4075 fefe feee feff 157a ......@u.......z
00000070: 5b00 0000 0000 0000 0000 0000 0000 0000 [...............Next step was this......and it ended in an error....
pm3 --> script run legic_clone -i 410174E5.hex -w
script run legic_clone -i 410174E5.hex -w
[+] Executing: legic_clone.lua, args '-i 410174E5.hex -w'
read 2 bytes from 410174E5.hex
...\iceman-64-20180921\win64\scripts/legic_clone.lua:220: bad argument #1 to 'sub' (string expected, got nil)
[+] FinishedDo I have completely wrong assumptions or is playing around with legic prime cards still a big mess?
Thanks upfront for some hints to get me on the right way. :-)
Offline
The current code does not write bytes 0 to 6 since those bytes have special properties and writing them might render the card useless.
If you dump your newly written card (instead of using hf legic info) you will see that the remaining bytes were written.
Last edited by AntiCat (2018-09-22 20:25:28)
Offline
I am suprised, as you are absolutely right and the cards are exact the same and only the first six bytes differ.
So the first 4 bytes are the ID of card which are cannot be changed.
Whate are byte 5 and 6 for?
As I am not able to read the card via "hf legic info", I think that an official reader would not read it either???
Offline
I did some more reading about Byte 5 and figured out that Byte 5 (MCC) is an important piece of xor(ing) the information stored on the token. Without properly xor(ing) the data stored on the token, the card seems to be useless. If I am wrong, just point me in the right direction.
After that I tried to understand how Mosci's "legic_clone" script works, which could do the xor(ing) with the unique MCC Byte on my blank card.
Unfortunately as can seen, the legic_clone script has a problem in its function "getInputBytes". It only reads the first two bytes of the dump and is not able to go further in the process of re-xor(ing) the data.
pm3 --> script run legic_clone -i 410174E5.hex -w
script run legic_clone -i 410174E5.hex -w
[+] Executing: legic_clone.lua, args '-i 410174E5.hex -w'
read 2 bytes from 410174E5.hex
...\iceman-64-20180921\win64\scripts/legic_clone.lua:220: bad argument #1 to 'sub' (string expected, got nil)
[+] FinishedMaybe Mosci or anyone else has an idea what's going wrong at this point. My knowledge about LUA and the low-level read/write bytes from a token is more or less 0.
Offline
26C3: Legic Prime: Obscurity in Depthl Covers pretty much all bytes and their meaning.
I can't comment on any of the scripts. I never used them.
Last edited by AntiCat (2018-09-24 17:55:02)
Offline
The DCF field ist not written properly. This field defines the type of card. In your case it is FFFF - this means: Blank Media.
Anyway: You can't just dump the card data and copy it to another one. The CRCs embedded in the Legic Cash segments need to be re-calculated related to the UID of the new target card.
Offline
Pages: 1