[Legic Prime] CRC Calc with KGH

akileos · 2017-05-25 18:22:04

Hi all,

Seen quite some smart guys here who know a lot more than I regarding legic

I've started to adapt the lua to read my token but still facing issues with CRCs :
https://github.com/akileos/proxmark3/blob/bf413f1b871d3adae107ed03a5fbfd03a5e3603a/client/scripts/legic.lua

1 st issue, it doesn't see that my token has a KGH, knowing that it does.
2nd issue, CRC are also wrong with legic cash segments, disabling the CRC check yields the correct results

 > dlc
autoSelect . 
[CRC1]10 01 04 01 20 1a 00 01 02 f4 01 86 a0  ==> 6f80!=7e98
[CRC2]5481~=705c
Legic-Cash Segment detected
autoselected Index: 09
in Segment 09 :
--------------------------------
	Legic-Cash Values
--------------------------------
Currency:		 CHF
Limit:			 1000.00
Balance:		 0.00
Transaction Counter:	 1
Reader-ID:		 1098576
--------------------------------

Any tips on figuring the correct fields for CRC ?

I can offer a copy of my dump for anyone willing to help but would prefer not posting it publicly even though it is disabled

iceman · 2017-06-03 17:54:42

Well, its not CRC-16/CCITT nor the Legic Advant CRC-16 polys... Must be another one.

Jason · 2017-06-06 12:34:42

As I mentioned in an other thread here, the CRC calculation done in the LUA script is wrong. The script will likly fail to detect the KGH on many (probly not most) of the cards.

Please supply a RAW dump. I never investigated Legic cash, maybe it's easy to get the CRC.

iceman · 2017-06-06 18:25:47

Yeah, @jason and @mosci had a go at eachother regarding the crc used. Would be nice if you two could agree about things

akileos · 2017-06-06 19:15:45

@jason for full dump mail me.
Segment dump here

Segment 00: raw header: 19 40 09 00, flag=4, (valid=1, last=0), len=0025, WRP=09, WRC=00, RD=00, CRC=b3 (valid)
Remaining write protected area:
02 00 0d 55 01 05 43 1f 00
Remaining segment payload:
00 00 00 00 00 00 00 00 00 00 00


Segment 07: raw header: 25 40 08 70, flag=4, (valid=1, last=0), len=0037, WRP=08, WRC=07, RD=00, CRC=13 (valid)
WRC protected area:
1e ff 03 f4 00 30 02
Remaining write protected area:
01
Remaining segment payload:
02 f4 00 fd e8 fb df 00 01 54 1e 00 00 86 c9 00 01 54 1e 00 00 6a d6 10

Jason · 2017-06-07 16:30:38

Okay, lets see...

The segment 0 (must be one, since segment 0 would be an "unsegmented" card... also a "bug") is a KGH for sure.
Stamp: 02-00-0D-55 ... this is a KABA segment (02 and 03 as first byte is the KABA GAM)
Than theres the BCD encoded card number: 01-05-43 ... your card numer is: 10543
The byte behind is the CRC8: 1F

The remaining bytes are garbage... not part of the KGH. And here's why the LUA script failes: If I remember correctly mosci just get the segment size and assumes size-1 is the CRC8 offset. This is not correct. A KGH structure always have 8 Byte (including CRC), regardless of the segment size itself. The problem with the wrong calculation order for the header-values I wrote already there: http://www.proxmark.org/forum/viewtopic … 280#p27280 ... this will most likly not result in an issue until WRC and RD is on it's default of 0.
Feel free to modify the script, iceman will make it part of his fork for sure. I don't have the time... and yeah... I hate LUA ;-)

So just proof it: Calculate the Legic CRC8 for this data as follows:
[UID1] [UID2] [UID3] [UID4] [WRP=09] 00 [WRC=00] [RD=00] 02 00 0d 55 01 05 43 ... this must result in 1f

Segment 7: (so 8 in fact)
Ist starts with 1E ... I don't know the owner of this GAM, but the followed FF-03-xx-xx is used by some payment systems. So this is likly a cash segment. The usage of Legic Cash is not very wide spread in buissenes, so funny to see it here.

The structure for Legic Cash is defined as follows:

---Stamp---
STAMP0
STAMP1
STAMP2
STAMP3
STAMP4
STAMP5
STAMP6
---Parameter section----
CSV               - Legic cash segment version, this is always 01 (since no other version exists)
CURRENCY_H  - High byte of ISO4217 encoded currency value
CURRENCY_L   - Low byte...
CLIMIT_H        - Cash value limit
CLIMIT_M        - Middle byte of limit
CLIMIT_L         - Low byte...
CRC_H            - CRC16 high byte (Calc over: All bytes in parameter section)
CRC_L             - ...low byte
--- Data section ---
CASHVALUE_H  - Cash value highes byte
CASHVALUE_M  - ... middle byte ...
CASHVALUE_L  - ... lowest byte
READER_ID_H  - Reader ID data was written with (high byte)
READER_ID_M  - ... middle byte ...
READER_ID_L   - ... low byte
CRC_H            - CRC16 high byte (Calc over: All bytes in data section)
CRC_L             - ...low byte
--- Mirror section ---
CASHVALUE_H  - Cash value highes byte
CASHVALUE_M  - ... middle byte ...
CASHVALUE_L  - ... lowest byte
READER_ID_H  - Reader ID data was written with (high byte)
READER_ID_M  - ... middle byte ...
READER_ID_L   - ... low byte
COUNTER        - transaction counter value (incremented on every write operation)
CRC_H            - CRC16 high byte (Calc over: All bytes in mirror section)
CRC_L             - ...low byte

Heres the problem: Legics CRC16!
First you have to add the UID in the calculation (this is not done in the LUA), so the correct way to start is: [UID1] [UID2] [UID3] [UID4] [...data...]
The other part is the crc algo... I don't know it, but I'm sure it is such weird as it is on CRC8 algo. I think it is just extended in size... but need to know the upper poly bits. I think this could be brute forced. If I get some time, I'll try it.

So in your example the CRC16 of all three blocks are:
CRC#1: FB-Df (data offset 6)
CRC#2: 86-C9 (data offset 14)
CRC#3: D6-10 (data offset 23)
Definition: Data offset is the user data offset excluding the 7 byte Stamp!

For advant it is much more easier. There the CRCs are just commonly known CRC algos. Iceman got the CRC16 one, I have documented the CRC8 algo in the linked post. But for Legic prime this isn't a usefull information.

Last edited by Jason (2017-06-07 16:35:59)

akileos · 2017-06-07 20:27:54

Thanks Jason. Will try fixing LUA accordingly.

BTW, we do actually have 3 Legic Cash segments, and many of the segments I've not identified yet ( Plus identified for printer, computer logon )
The Segment 07 above should be for "Selecta" vending machines.

Jason · 2017-06-08 10:02:19

akileos wrote:

we do actually have 3 Legic Cash segments, and many of the segments I've not identified yet

Just provide a dump if possible... normaly theres not much stored on the cards. A card number and system specific data, the last part is hard to figure out... A fun fact is: In the belief of Legics safety, historically nearly all in this marked do not chipher there data in any way. Nearly all systems could be easily analysed if you get access to such a system for generating card changes. Especially payment systems are freaking easy to hack...

akileos wrote:

should be for "Selecta" vending machines.

The machines doesn't matter. The Selecta payment system is extremly old and uses an other encoding (which I know of...). Possibly theres an other payment system installed in this machines. I know some of the names behind SSCs, currently Selecta is not part of this list... so maybe 1E is in fact Selectas Legis license. But I don't know.

akileos · 2017-06-08 10:48:19

My first objective is to open the front door Please tell me where to send the dump, I don't want anyone to enter the company using a clone of my access badge !

Jason · 2017-06-08 13:06:05

You already published all necessary data to create a clone for door opening

CDF: System Area
------------------------------------------------------
MCD: xx, MSN: xx xx xx, MCC: xx 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 01 19 80 0D 00 DB 12 00 00

ADF: User Area
------------------------------------------------------
Segment 01
raw header | 0x19 0xC0 0x09 0x00
Segment len: 25,  Flag: 0xC (valid:1, last:1), WRP: 09, WRC: 00, RD: 0, CRC: 0x7
2 (OK)
Remaining write protected area:  (I 27 | K 0 | WRC 0 | WRP 9  WRP_LEN 9)


row  | data
-----+------------------------------------------------
[00] | 02 00 0D 55 01 05 43 3F 00
Remaining segment payload:  (I 36 | K 36 | Remain LEN 11)

row  | data
-----+------------------------------------------------
[00] | 00 00 00 00 00 00 00 00 00 00 00
-----+------------------------------------------------

Where do I have to pass by to open the door with my just yet created card?

But I don't know how to send me stuff, this forum lack the feature of PMs Maybe I create a fake mail account somewhere.

iceman · 2017-06-08 14:22:56

someones dump looks differently than current legic.lua
Do you have your own script maybe?

Jason · 2017-06-08 20:30:36

iceman wrote:

Do you have your own script maybe?

Oh no, it isn't the script. I still use my old firmware fork from last year. It is simply the fixed "decode" function inside of the client-code.
Tried few days ago your current release but noticed you broken the (now called) "info" function once again (client craches). Will take look on it. Also think about implementing some card manipulation and master-tooken creation funktion in the client with a somehow similar command-set the Legic chips will do such a job. But as alwas: Time ....

iceman · 2017-06-08 21:02:03

don't spend time on it, its fixed ... I just have the monster merge to perform before I release the new icemanfork version.

akileos · 2017-06-12 13:39:39

Hey.

Just dumped few colleagues badges (With the official RF_10 app and reader) . Doesn't seem to match the Legic Cash specs.

The CRC for the Param secton is always different :

2E 8E //  26 6E  //  BA FE // 46  19

00: -- -- -- -- | -- -- 0C 02 | 00 29 01 00 | B8 01 02 F4 
16: 01 38 7F 2E | 8E 00 01 54 | 0C 00 01 A2 | 22 00 01 54 
32: 0C 00 01 5E | 3C 78 


00: -- -- -- -- | -- -- 0C 02 | 00 29 01 00 | B8 01 02 F4 
16: 01 38 7F 26 | 6E 00 01 90 | 0C 00 01 76 | 5F 00 01 90 
32: 0C 00 01 1D | 43 46 



00: -- -- -- -- | -- -- 0C 02 | 00 29 01 00 | B8 01 02 F4 
16: 01 38 7F BA | FE 00 06 54 | 0C 00 01 A3 | E6 00 06 54 
32: 0C 00 01 34 | F1 2B 


00: -- -- -- -- | -- -- 0C 02 | 00 29 01 00 | B8 01 02 F4 
16: 01 38 7F 46 | 19 00 02 D0 | 0C 00 01 6E | 23 00 02 D0 
32: 0C 00 01 0C | 2B 16

Card uid or kgh uid included in calc maybe ? Will try to dump badges with "zero" amount.

Last edited by akileos (2017-06-12 13:55:17)

iceman · 2017-06-12 13:51:33

Yes, @jason mentioned that the UID is used and some other data for this crc-calc.

See post #6 in this thread for the details

akileos · 2017-06-12 14:08:52

---Parameter section----
CSV               - Legic cash segment version, this is always 01 (since no other version exist[s)
CURRENCY_H  - High byte of ISO4217 encoded currency value
CURRENCY_L   - Low byte...
CLIMIT_H        - Cash value limit
CLIMIT_M        - Middle byte of limit
CLIMIT_L         - Low byte...
CRC_H            - CRC16 high byte (Calc over: All bytes in parameter section)
CRC_L             - ...low byte

First you have to add the UID in the calculation (this is not done in the LUA), so the correct way to start is: [UID1] [UID2] [UID3] [UID4] [...data...]

Have noted down all the UID, will test with "hf le crc c 16 d xxxx" once back @home. Reveng doesn't find anything ( Or not using it properly )

UID      |Param        |CRC
---------------------------
3D2BE304  0102F401387F  2E8E
3D2FEAD2  0102F401387F  BAFE
3D2BE2B3  0102F401387F  4619
3D2FE5E6  0102F401387F  266E
41F08579  0102F401387F  B291
41A8DCD3  0102F401387F  9233
57b89826  0102F401387F  2B8A
7704eefc  0102F401387F  AF24

Last edited by akileos (2017-06-12 14:45:18)

Jason · 2017-06-12 15:12:28

As mentioned I don't know the CRC algo, and here I mean exactly: Also Reveng can not reverse-engeneer it!
Reveng will not give any results... I tried this a longer time ago. I know the UID is bound into the CRC, that can we verified by writing the same data on different cards. I don't know if the UID1,2,3,4 order is correct, but since it is that way for Legic-CRC8, it doen't makes sense why it should be in an other way here.
I never investigated my thoughts above (same algo as on CRC8 but extended) deeper, since - for me (!) - it's way easier to just create the relevant GAM/IAM/XAM and let the Legic reader do the job. Of course: It would be fine to know the algo, since less people here have access to the Legic reader stuff.
If I get some time tomorror I try your data with a brute-force aproche by extending the known CRC8 algo to 16 bits and brute-forcing the Poly. Maybe this works.

akileos · 2017-06-12 15:54:01

Jason,
I do have an official reader ( even 4 .... launched for different segments ... ), I can of course read all segments the readers are launched for, but no software for writing using those reader. Does it even exist ?
Will try to do it with RS232 commands maybe ?

Jason · 2017-06-13 14:31:36

What kind of "official" reader? Legic does not sell any reader. They just sell reader chips (and in the past reader-modules). And finaly it depands on what kind of chip-set is in the reader, not all of them allow to create segments. For 4000 series you need a SM-4500 min. and for 2000 series a SC-2560.

But I think you have some sort of reader sold for public use. This kind of readers have a µC inside to hide the Legic reader chip protocol, since this documentation is only available to licensees. You got the communication protocol documentation from me. This could be used to communicate directly with the Legic chip, and therefore all available functions could be executed this way...

BTW: Didn't had time take a look on the crc issue yet... brb at this point.

Last edited by Jason (2017-06-13 14:32:14)

iceman · 2017-06-13 16:50:36

I think user has a twn-4

akileos · 2017-06-13 17:33:46

Got a SM4500 that can create segments ( and Elatec TWN3 & TWN4 + Kaba Legic key reader i go no clue about), it's only used for segment creation right now. It's a EVIS TL GECKO 2A1
http://www.evis.ch/kassenleser.html
Managed to sniff some part of the comm protocol over serial for the legic cash part. If sucessful will try bitflip comparisons to try guessing the CRC. also found some LRC code but seesm frame related instead of segment.

private void SendFrame(CardReaderEvis.Frame frame, bool fullTrace)
		{
			StringBuilder stringBuilder = new StringBuilder();
			byte b = frame.Command;
			stringBuilder.Append((char)frame.Command);
			for (int i = 0; i < frame.Length; i++)
			{
				string text = frame.Data[i].ToString("X2");
				stringBuilder.Append(text);
				b ^= (byte)text[0];
				b ^= (byte)text[1];
			}
			stringBuilder.Append(b.ToString("X2"));
			stringBuilder.Append("\r");
// YadaaYadaa
		}

Last edited by akileos (2017-06-13 19:57:02)

iceman · 2017-06-13 19:36:23

hrm, it looks like it tries to xor all nibbles.
start value is frame.command.
xor nibbles from data

Jason · 2017-06-14 10:30:21

akileos wrote:

Got a SM4500 that can create segments ( and Elatec TWN3 & TWN4

As of my knowing the Elatec readers use a µC, so the Legic command protocol is hidden from user. They created his own protocol to communicate with the µC (which itself communicats with the Legic chip). I can't help with it, since I don't use any kind of OEM reader (they not suite my needs).

What's not clear for me is: You have some Elatec reader AND a SM4500 (naked) reader? Or does it mean you have a Elatec reader WITH SM4500 chipset? In the last case rip off all the µC stuff and connect the Rx/Tx lines of the SM-4500 chip to the board connector. Than you can do all the stuff the chip can do.

akileos wrote:

also found some LRC code

This have nothing to do with your problem. The communication is commonly secured by a simple LRC, checksum or CRC value. This makes sure no false commands are executed by the reader.
As I written above: I send you the reader communication specification already. If you take a closer look on it you will see that every command frame is CRC secured. The crc code snipped is also inside this document. Older Legic reader chips (2000 series and older chips like SM-05) had used a more simpler LRC. Just a XOR over all bytes append to the command frame. Seems Elatec used the same concept to make sure commands are valid. Legic changed this concept to CRC16 usage in 4000 series reader chips (2000 series reader could communicate in both modes: LRC and CRC). But the command concept is still the same: [LEN] [COMMAND] [... DATA ...] [CRC.high] [CRC.low] ... very simple. The LEN value does include the CRC bytes, but not the LEN byte itself. But as said: You got the documents.

BTW @iceman: You got it too? I'm not sure if the service send it properly.

akileos · 2017-06-14 10:56:23

Here's what it's look like. That's the EVIS reader. Never opened others. Will try to see if usable testpoints are hooked up to the chip, but don't know which pins are used on chip itself

Notice the JTAG port on bottom. Will try Blackmagic to dump firmware

Last edited by akileos (2017-06-14 11:20:01)

Jason · 2017-06-16 16:53:36

akileos wrote:

but don't know which pins are used on chip itself

Just ask

Just to note that: The SM-4500 chip can be encrypted. In this mode the communication is AES enchipered. If the chip was switched to this mode, it is quit useless. But normally the chips are open. Just trace the chip RxD if there are normal commands.
Looking at the PCB it seems to be easy to route the RxD/TxD lines directly to the FTDI USB2Serial chip.

Last edited by Jason (2017-06-16 17:02:02)

akileos · 2017-06-18 10:57:42

Hi,

Fiddling with traces, seems to be connected to the SIPEX RS232 Level shifter just below. Does the chip work on 3v3 by any chance ?

Last edited by akileos (2017-06-18 10:58:12)

Jason · 2017-06-18 18:46:57

The logic part runs on 3.3V, the rf driver runs on 5V (could be 3.3V too, but gives poor antenna range).
So the SM4500 runs already on 3.3V for the RxD/TxD lines (the logic part). If the rs232 driver also runs on 3.3V it's easy. If not just put a ~100R resistor in series with pin 29 of the SM4500 chip. Not perfect, but suitable...

akileos · 2017-07-02 09:02:18

Hi there, just a word to say I'm not dead. Been way more busy than intented lately but will return to Legic soon

loupetre · 2020-11-06 08:21:22

Jason wrote:

The machines doesn't matter. The Selecta payment system is extremly old and uses an other encoding (which I know of...). Possibly theres an other payment system installed in this machines. I know some of the names behind SSCs, currently Selecta is not part of this list... so maybe 1E is in fact Selectas Legis license. But I don't know.

Hi Jason, still around ? I have some questions about the selecta system ...
Thank you

Jason · 2020-11-19 16:49:12

loupetre wrote:

I have some questions about the selecta system ...

Just ask, maybe I have an answer on hand.

loupetre · 2020-11-20 08:55:27

It is about keys derivation. Do you have some hints about this ?

Jason · 2020-11-20 13:05:50

If this is related to Selecta and you ask for key diversification, I could assume you are speaking about one of there newer systems on advant media? I don't know any variant on prime medias, where key div. is present. They use not just one concept (over the time), some of them are even not there own. But the prime versions I know of, are all together not really "protected" in a way it should be (especially related to the term "key div.")...
You should be more specific in terms of what media you asking for, what can you read out of it, STAMP bytes and/or chip UID (upper bytes) so on.
I have less information about there advant system, but as of my information they use some kind of... lets say: Wallet standard, standardized by a technology forum. Some "one size fits all" stuff. And, of course, some kind of security risk by its own...

Last edited by Jason (2020-11-20 13:08:06)

loupetre · 2020-11-25 16:32:53

I don't really understand what you mean by "advant" and "prime" media ?
The tags I'm talking about are old ones probably the ones that you saiy they are "not really protected".

Thus, I think I'm talking about prime media, I can fully manipulate the tag that I know the meaning of quite all the data stored inside. Only one thing is still not clear for me : how key diversification is done (I can't correlate the UID and the keys I have, despite I have several full dumps).

Jason · 2020-11-26 17:31:48

You are talking about prime media in case you can read it with proxmark.
In case of prime and the fact you read all data and know the meaning of the elements says, that no data is encrypted - as like the system versions I know of. So what kind of key diversification you are talking about? Key diversification is a process to diversify a known key or salt to manipulate it in a way (with card data, as like the UID), you can derive a key to encrypt/decrypt data. There's no encrypted data, so there's now key diversification, even not a key at all.
Is it possible you are talking about checksums as part of some data blocks and the possibility of additional elements included in there calculation process?

The Selecta formats, if I remember correctly, just use the reader supplied CRC function. So it will use the Legic CRC method, as like it is used to generate checksums in Legic's header elements for example. The difference for data payload in segments is, that they might include (this could be defined as parameter for this generation command) additional elements beside the UID. These are the STAMP bytes, RD flag and so on... the required "buffer header", if you try to do this with "low level" equipment like proxmark, is:

buf[0] = UID1;
buf[1] = UID2;
buf[2] = UID3;
buf[3] = UID4;           // Is checksum over the first 3 bytes for Legic
buf[4] = WRP + OL;	 // OL = STAMP size
buf[5] = 0x00;
buf[6] = WRC;
buf[7] = 0x01;           // RD flag: 0x01 if set, 0x00 if not set
buf[8+n] = ... payload

After this "header" the data payload must be added. Finally this is passed to the LegicCRC8 calculation. As far as I know there's no CRC16 in Selecta data structures, if I remember correctly.

Last edited by Jason (2020-11-26 17:35:12)

loupetre · 2020-11-27 08:16:57

Maybe I used the wrong word with "key diversification".
The selecta tags I'm talking about are mifare 1k. Usually there is only 1 sector containing data (except sector 0). The data are not encrypted as you mentionned. It is not my point to understand the data as I already know who's who amoung them.
I got several dumps of these tags, and all were differents regarding the B key of this sector.
The B key on this sector, in my opinion, is derivated from the UID because the whole sector 0 is always the same from a tag to another, except UID (and BCC).
Do you see what I mean ?

iceman · 2020-11-27 09:37:13

If you swapping between talking about legic and mifare classic in a topic thread about legic, you will confuse everyone.
Keep to the topic, in order to keep the threads clean and understandable.

loupetre · 2020-11-27 16:54:05

Yes sure. Sorry about that

Jason, do you want to continue on discord, I open a thread in the mifare section or anything you want.
You choose

Jason · 2020-11-30 10:22:58

Your assumption should be right in this case. But I don't have any information about there Mifare classic stuff. Was never digging into it, sorry. As a general rule: It's normally (more or less) impossible to get the diversification algorithm just by plane dumped data. It gets just once a good result for me, because it was a more or less simple XOR calculation. If the A Key (possible read key) is static in this case, the diversification may include payload of this sector as well. Most likely some kind of "project code", to separate individual system installation from each other. Some other systems use project specific key calculations to separate them in some kind of "physical" way from each other. Normally these "clients" are programmed with there "project specific" parameters (somehow). So you end up with lots of possible variants. This makes it somehow impossible to guess the right way just by data dumps. It's more luck than science, so to speak.

I don't use Discord by the way. It's on my personal blacklist. I can't give any further information anyway on this topic...

loupetre · 2020-11-30 11:14:15

Ok, thank you anyway Jason

changetotower · 2021-09-22 17:33:21

Hello guys,

Any news on an updated LEGIC LUA script, where the LEGIC-Cash CRCs are calculated correctly? I'd have the means of testing... Many thanks!

Best regards

Proxmark3 community

Announcement

#1 2017-05-25 18:22:04

[Legic Prime] CRC Calc with KGH

#2 2017-06-03 17:54:42

Re: [Legic Prime] CRC Calc with KGH

#3 2017-06-06 12:34:42

Re: [Legic Prime] CRC Calc with KGH

#4 2017-06-06 18:25:47

Re: [Legic Prime] CRC Calc with KGH

#5 2017-06-06 19:15:45

Re: [Legic Prime] CRC Calc with KGH

#6 2017-06-07 16:30:38

Re: [Legic Prime] CRC Calc with KGH

#7 2017-06-07 20:27:54

Re: [Legic Prime] CRC Calc with KGH

#8 2017-06-08 10:02:19

Re: [Legic Prime] CRC Calc with KGH

#9 2017-06-08 10:48:19

Re: [Legic Prime] CRC Calc with KGH

#10 2017-06-08 13:06:05

Re: [Legic Prime] CRC Calc with KGH

#11 2017-06-08 14:22:56

Re: [Legic Prime] CRC Calc with KGH

#12 2017-06-08 20:30:36

Re: [Legic Prime] CRC Calc with KGH

#13 2017-06-08 21:02:03

Re: [Legic Prime] CRC Calc with KGH

#14 2017-06-12 13:39:39

Re: [Legic Prime] CRC Calc with KGH

#15 2017-06-12 13:51:33

Re: [Legic Prime] CRC Calc with KGH

#16 2017-06-12 14:08:52

Re: [Legic Prime] CRC Calc with KGH

#17 2017-06-12 15:12:28

Re: [Legic Prime] CRC Calc with KGH

#18 2017-06-12 15:54:01

Re: [Legic Prime] CRC Calc with KGH

#19 2017-06-13 14:31:36

Re: [Legic Prime] CRC Calc with KGH

#20 2017-06-13 16:50:36

Re: [Legic Prime] CRC Calc with KGH

#21 2017-06-13 17:33:46

Re: [Legic Prime] CRC Calc with KGH

#22 2017-06-13 19:36:23

Re: [Legic Prime] CRC Calc with KGH

#23 2017-06-14 10:30:21

Re: [Legic Prime] CRC Calc with KGH

#24 2017-06-14 10:56:23

Re: [Legic Prime] CRC Calc with KGH

#25 2017-06-16 16:53:36

Re: [Legic Prime] CRC Calc with KGH

#26 2017-06-18 10:57:42

Re: [Legic Prime] CRC Calc with KGH

#27 2017-06-18 18:46:57

Re: [Legic Prime] CRC Calc with KGH

#28 2017-07-02 09:02:18

Re: [Legic Prime] CRC Calc with KGH

#29 2020-11-06 08:21:22

Re: [Legic Prime] CRC Calc with KGH

#30 2020-11-19 16:49:12

Re: [Legic Prime] CRC Calc with KGH

#31 2020-11-20 08:55:27

Re: [Legic Prime] CRC Calc with KGH

#32 2020-11-20 13:05:50

Re: [Legic Prime] CRC Calc with KGH

#33 2020-11-25 16:32:53

Re: [Legic Prime] CRC Calc with KGH

#34 2020-11-26 17:31:48

Re: [Legic Prime] CRC Calc with KGH

#35 2020-11-27 08:16:57

Re: [Legic Prime] CRC Calc with KGH

#36 2020-11-27 09:37:13

Re: [Legic Prime] CRC Calc with KGH

#37 2020-11-27 16:54:05

Re: [Legic Prime] CRC Calc with KGH

#38 2020-11-30 10:22:58

Re: [Legic Prime] CRC Calc with KGH

#39 2020-11-30 11:14:15

Re: [Legic Prime] CRC Calc with KGH