Proxmark3 community

Dose13

Contributor

Registered: 2019-09-26

Posts: 29

Segment data

Good evening,

I made a few tests with my Legic Prime MIM1024. The interesting stuff that I found is that the value for the cash is stored in Segment2. The actual value is stored in 01x14 = 03 and 01x15 = E8. Those two bytes 03 E8 equals 10€ (i.e.1000 Cent). From what I understood is that 01x16 = 4A is some kind of checksum, which is calculated with [MCD][MSN0][MSN1][MSN2]+01x14+01x15 = 4A. The value before was 0€ (00 00) and the value therefore was 4,11€ (i.e. 01 9B).

All these values are stored in line 02.

The bytes that equals 10€:
02x01 = 03;
02x02 = E8;
Cheksum in 02x03 = 4A

The bytes that equals 0€
02x05 = 00
02x06 = 00

The bytes that equals 4,11€
02x09 = 01
02x10 = 9B

Byte 02x04 = 60 seems to be a checksum as well. Unfortunately I have no idea how it is calculated. All the other bytes were never changed. At least not lately. 

The other interesting thing that I noted is that when my card is charged the new value will be overwritten at 01x14/15 and 16, as well as 02x01/02/03. However, the previous actual figure will always be replace with the latest figure. So it is always alternating between 02x05/06 and 02x09/10. Any suggestions or ideas how to calculate the second checksum? Of course I tried [MCD][MSN0][MSN1][MSN2]+02x05+02x06+02x09+02x10 as well as 02x01...03, the entire line.

 
row  | data
-----+------------------------------------------------
[00] | xx yy zz 
-----+------------------------------------------------

[+] Remaining segment payload:  (I 54 | K 54 | Remain LEN 112)

row  | data
-----+------------------------------------------------
[00] | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 33 
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 03 E8 4A 
[02] | 03 E8 4A 60 00 00 03 4D 01 9B 00 52 7C 04 00 00 
[03] | 00 00 00 00 10 00 00 00 00 00 00 7A 81 00 00 00 
[04] | 01 00 00 00 00 00 51 01 01 00 00 30 16 9C 00 00 
[05] | 00 00 00 00 00 00 2D 00 00 00 00 00 00 00 00 00 
[06] | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
-----+------------------------------------------------

The other thing that I figured when looking at the raw data I was not able to find any of the cash bytes there. Unfortunately I am not good enough to read the source code properly. My question is how are the Segment data related to the raw data?

The card has a couple of more Segments. I was wondering if Segment 2 is only used for handling my money. Would that be kind of normal or is it more likely that other data are stored in that Segment as well.

The card can be used on some doors as door opener as well. Some guy mentioned that the key for the doors is only valid for a year or so. That is why I assume that the card contains some kind time stamp(s) as well. Would this be normal? Would there be something to identify a time stamp easily?

Any hints or comments are appreciated!

Thanks

Last edited by Dose13 (2020-09-24 17:37:41)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: Segment data

try the legic lua script.  It can decode some segments that has been mapped.  Maybe it fits yours.

Dose13

Contributor

Registered: 2019-09-26

Posts: 29

Re: Segment data

I already tried it but most of the features do not work with my card. From what I understood is that the cash segment is derived from cards that have "legic-cash" segments, which my card doesn`t have.

pizza_4u

Contributor

Registered: 2018-07-28

Posts: 8

Re: Segment data

The card has a couple of more Segments. I was wondering if Segment 2 is only used for handling my money. Would that be kind of normal or is it more likely that other data are stored in that Segment as well.

Yes, that is quite normal. Segments are like applications.

Segment 1 for example is for online door access control. Segment 2 in your case for some payment system A. Segment 3 could be for offline door access control and segment 4 for payment system B and so on....

pizza_4u

Contributor

Registered: 2018-07-28

Posts: 8

Re: Segment data

The other interesting thing that I noted is that when my card is charged the new value will be overwritten at 01x14/15 and 16, as well as 02x01/02/03. However, the previous actual figure will always be replace with the latest figure. So it is always alternating between 02x05/06 and 02x09/10. Any suggestions or ideas how to calculate the second checksum? Of course I tried [MCD][MSN0][MSN1][MSN2][MSN3]+02x05+02x06+02x09+02x10 as well as 02x01...03, the entire line.

I have seen applications where the checksum for some data has been caluclated by MCD+MSN + some part of the segment header and/or the write protected area of the segment. So maybe give it a try with this.

Jason

Contributor

Registered: 2016-07-21

Posts: 55

Re: Segment data

I don't think this is a checksum.
The concept seems to be a transaction log. A transaction log only makes sense with more information than just the last cash value. I would guess the number in question is simply a unit number. So the system can show, maybe in case of corrupted cash data: Go back to unit XXX and do something.

Force 2 activities on the same unit in a row and verify the data. I assume both log entries finally show the same number.

The other assumption is correct: Segments are usually limited to a specific function, as told by pizza_4u. But there a exceptions...
Usually no one would use this, because segment switching takes a while with the Legic readers. So it makes the process quit slow if you fiddle around in a bunch of different segments. But they exists, the silly implementations.

An because the timestamp questions: In all this years I saw tons of different timestamp definitions. It seems there are more ways to encode a timestamp, than time exists in this universe. There is no simple rule, except the 2 basic concepts: Seconds counter with some kind of bias. A somehow encoded format of YYYYMMDD... BCD, binary, some bit-packed... many creative ways.

Last edited by Jason (2020-09-08 13:34:16)

Dose13

Contributor

Registered: 2019-09-26

Posts: 29

Re: Segment data

I collected a few more data. Actually I found that the last 3 cash values are stored on the card. Since only row 01 and row 02 do change I will focus only on those lines:

Actual cash-value: 4.11 € (Hex = 01 9B) - Unit 1 (Canteen)

 
row  | data
-----+------------------------------------------------
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 01 9B CB 
[02] | 01 9B CB 81 04 FF 03 4D 07 08 00 52 7C 04 00 00 
-----+------------------------------------------------

Actual cash-value: 0€ (Hex = 00 00) - Unit 2 for getting my money back

 
row  | data
-----+------------------------------------------------
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 00 00 B1 
[02] | 00 00 B1 72 04 FF 03 4D 01 9B 00 52 7C 04 00 00 
-----+------------------------------------------------

Actual cash-value: 10€ (Hex = 03 E8) - Unit 3 for uploading my card

 
row  | data
-----+------------------------------------------------
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 03 E8 4A 
[02] | 03 E8 4A 60 00 00 03 4D 01 9B 00 52 7C 04 00 00 
-----+------------------------------------------------

Actual cash-value: 8.31 € (Hex = 03 3F) - Unit 1 (Canteen)

 
row  | data
-----+------------------------------------------------
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 03 3F CC 
[02] | 03 3F CC 51 00 00 03 E8 01 9B 00 52 7C 04 00 00 
-----+------------------------------------------------

Actual cash-value: 8.05 € (Hex = 03 25) - Vending machine (Unit 4)

 
row  | data
-----+------------------------------------------------
[01] | 00 26 31 00 80 FF 30 9D 2F 00 00 00 4D 03 25 0C 
[02] | 03 25 0C 52 00 00 03 3F 01 9B 00 52 7C 04 00 00 
-----+------------------------------------------------

The last purchase was really notable. Normally the last figure in storage would have been overwritten. In this example this would have been 01 9B. However, in this case the newest figure 03 E8 was overwritten. Normally I would have expected that the "transaction log" would have decreased but this time it increased +1. I think I still need more data to get a better understanding.

I think Jasons assumption that each Unit has its special log might be right. I keep collecting data. Let me know if you have further ideas.

Last edited by Dose13 (2020-09-24 20:50:08)