My Legic Prime story

Vinnie · 2016-04-06 14:38:29

Hi!

I am student in Computer & Cybercrime and doing my thesis about RFID security.
The company I do my internship uses Legic Prime. (which is bad)

But I need to provide them a POC of me "breaking in" with a fake card or an emulation card.
My research goes slowly due my lack of knowledge but I learn things everyday.

So the purpose of this topic would be a kind of Diary and if you want to help me feel free to do so.

What I achieved so far:

1) Compiling and flashing new firmware on the proxmark (the iceman1001 fork)
2) Reading Legic Prime cards (ultra short read distance ~ 0,5 cm)
3) Only the first 16 bytes have values and I found a kind of pattern:
Pattern

The rfid administrator told me that only the UID of the card is used during reading.

My next step will be figuring out what the bytes mean. Red could be a part of the Master Token System Control.

Feel free to help me in any way
I will post updates when I find something new.

iceman · 2016-04-06 16:58:07

Do you have some legic datasheets or documents to read?
As a student you might have access to the ACM database...

Vinnie · 2016-04-06 18:20:43

iceman wrote:

Do you have some legic datasheets or documents to read?
As a student you might have access to the ACM database...

Documents I use now are:
100616.EUSecWest.LegicPrime.pdf
SAR-PR-2011-03_.pdf

I have no access to the ACM database.

iceman · 2016-04-06 20:20:52

google for "legic prime - dismanteling.pdf" or "Peeling Away Layers of an RFID Security System"

Vinnie · 2016-04-07 07:52:55

iceman wrote:

google for "legic prime - dismanteling.pdf" or "Peeling Away Layers of an RFID Security System"

Already have that document
Documentname is: SAR-PR-2011-03_.pdf

This kind of documentation would be helpful:

Programming 101 for proxmark
Low level explanation RFID
More legic prime docs

Are ISO standards also good to read?

Vinnie · 2016-04-07 11:01:46

My next step will be figuring out what the bytes mean. Red could be a part of the Master Token System Control.

After reading some documents I figured out what those bytes mean.
Now I am trying to find a way to 1) emulate that card or 2) write that UID onto a new card.

1) Try to emulate the card with "hf legic sim", green light goes on but terminal is not doing anything:
Emulation
2) Contacted some firms if they have cards where you can write the UID of the legic MIM256.

mosci · 2016-04-07 11:15:14

I have not found any UID-Writable Legic-Prime Tag until now - lucky me I didn't need to change the UID of the Tag - in our System the UID is not that important.

So I guess a working Simulator will be the only thing that will help you to achieve your goal.

Vinnie · 2016-04-07 12:01:06

mosci wrote:

I have not found any UID-Writable Legic-Prime Tag until now - lucky me I didn't need to change the UID of the Tag - in our System the UID is not that important.
So I guess a working Simulator will be the only thing that will help you to achieve your goal.

Ok thanks for the help

Does the simulator work in your fork?

mosci · 2016-04-07 12:15:27

no - I'm not able to simulate a Legic Prime with PM3 either.
But ... I'm interested in your Tag since it looks quite different from what I have seen before.

since all user-credentials (DCF = 60 EA) I have seen until now do have '9F FF' for byte 7 & 8 and '11' on byte 12
I wonder how the Segment-Data looks like ;-)

since you said there are only 16 bytes with data on your tag - I really wonder what kind of tag this will be ...
ordinary User-Credentials will have their first segment started on byte 16 (start counting from zero)
so you tag seems to be a unsegmented tag - which I only knew as 'Master-Token'
I have never seen a unsegmented user-credential - so I would like to know more about it - maybe I can implement it into
my legic-Script for PM3

Last edited by mosci (2016-04-07 12:32:10)

Vinnie · 2016-04-07 12:38:10

mosci wrote:

no - I'm not able to simulate a Legic Prime with PM3 either.
But ... I'm interested in your Tag since it looks quite different from what I have seen before.
since all user-credentials (DCF = 60 EA) I have seen until now do have '9F FF' for byte 7 & 8 and '11' on byte 12
I wonder how the Segment-Data looks like ;-)
since you said there are only 16 bytes with data on your tag - I really wonder what kind of tag this will be ...
ordinary User-Credentials will have their first segment started on byte 16 (start counting from zero)
so you tag seems to be a unsegmented tag - which I only knew as 'Master-Token'
I have never seen a unsegmented user-credential

There is no more data on the card. It are all 00 starting from byte 16.
(I used hf legic read and hexsamples to view these data)
So my card is probably a GAM, IAM or SAM card?

mosci · 2016-04-07 12:43:26

it's definitely a SAM-Tag (DCF = 60 EA)
so ... for me it sounds like a unsegmented user-credential - maybe the system, on which this tag is being used, is quiet old?

Vinnie · 2016-04-07 12:58:05

mosci wrote:

it's definitely a SAM-Tag (DCF = 60 EA)
so ... for me it sounds like a unsegmented user-credential - maybe the system, on which this tag is being used, is quiet old?

The readers are from 2009 I think. (Will ask the administrator again when I meet him)

You think it's possible to fix the simulator?

mosci · 2016-04-07 13:18:13

I'm sure that it will be possible to get the Simulator to work - but unfortunately not by me - due to a lack of knowledge about C.
I was hoping that you will fix that ;-)

Vinnie · 2016-04-07 13:25:30

mosci wrote:

I'm sure that it will be possible to get the Simulator to work - but unfortunately not by me - due to a lack of knowledge about C.
I was hoping that you will fix that ;-)

It will be very hard for me
I have only seen the basics of C.
But I am willing to delve in the world of C
And I can probably ask help from my teacher who dreams about C.

mosci · 2016-04-07 13:39:40

for what is this tag used for?
as door-opener?

I would ask the RFID-Admin also
works the system online or offline (is there any backend that will guarantee access based on the read data, or does the reader works completely autonomous and just checks the stamp)

as you mentioned earlier ... your RFID-Admin said that only the UID will be used to guarantee access or not, so I guess that there is a backend on which a whitelist with UIDs exists - this will mean that the system works online.
otherwise it would not be possible to act adequate if a user looses his tag (remove it from the whitelist).

Do you have access to more of those tags, so that you can compare different tag-data?
On our system the UID was completely unused - there was user2card-mapping within a segment, which makes it very easy to clone such a tag - once I understsood the data in the segment

Vinnie · 2016-04-07 14:04:10

mosci wrote:

for what is this tag used for?
as door-opener?
I would ask the RFID-Admin also
works the system online or offline (is there any backend that will guarantee access based on the read data, or does the reader works completely autonomous and just checks the stamp)
as you mentioned earlier ... your RFID-Admin said that only the UID will be used to guarantee access or not, so I guess that there is a backend on which a whitelist with UIDs exists - this will mean that the system works online.
otherwise it would not be possible to act adequate if a user looses his tag (remove it from the whitelist).
Do you have access to more of those tags, so that you can compare different tag-data?
On our system the UID was completely unused - there was user2card-mapping within a segment, which makes it very easy to clone such a tag - once I understsood the data in the segment

It is used as a door-opener.

The systems works "semi-online".
You have the server, controller and the reader.
If something happens between the server and controller, the reader will still work because of local backup data in the controller.
Server Controller Reader

Yes I had one more tag where only the UID was different and the 3 last bytes.

Next week I will have access to more cards, the master tokens and I will do some testing with the original software to change cards.

Last edited by Vinnie (2016-04-07 14:05:02)

mosci · 2016-04-07 18:30:27

byte address 15 seems to be a crc8 over byte address 0..3+7..14

byte address 0..3 : 79 74 26 65
byte address 7..14: 08 02 0a 00 05 03 44 96
byte address 15: 71

must be verified on other tags - could also be a accidentally match
since byte address 7..12 is always the same - maybe byte 13+14 are used for some user-mapping or authorizations (on the server/controller side)

and ... if that theorie matches => most of the bytes can be identified even if we not totally sure what meaning the bits and bytes do have in detail now:
addr 0..3 => UID
addr 4 => uidCRC
addr 5 => DCF low
addr 6 => DCF high
addr 7 => some kind of one-byte-header? or simply the 'data-length' ? could also be the first stamp-byte
addr 8..12 => (partial) stamp and maybe some data (stamp can have 2 to 7 bytes and some stamp must be there - some portion of data can be the same on 'n' tags)
addr 13..14 => unknown - some data or also stamp, but since it seems to be different on different tags, this is more likely not part of the stamp
addr 15 => crc8 over 0..3+7..14

so as first attempt I would create me a tag with a copy of the data and recalculate the crc for addr 0x15 and look how the reader behaves - might work already but also might not ;-)

Last edited by mosci (2016-04-07 20:50:51)

Vinnie · 2016-04-08 09:29:40

mosci wrote:

byte address 15 seems to be a crc8 over byte address 0..3+7..14
byte address 0..3 : 79 74 26 65
byte address 7..14: 08 02 0a 00 05 03 44 96
byte address 15: 71

I am in!
I changed byte 13 and 14 to the values of another card and I did the CRC on byte 15.
This was enough to open doors as someone else.

Thanks for the help

I am stunned that they don't use the UID of the card.
The UID is not writeable which makes it a bit more secure (just a little bit)

iceman · 2016-04-08 09:52:14

Well done!
strengthen from your success you can now foucs on a deeper understanding in Legic tags.

mosci · 2016-04-08 10:16:10

fine - thanks for providing a example of a unsegmented user-credential
I will have to implement that into my legic.lua

Last edited by mosci (2016-04-08 10:18:00)

Vinnie · 2016-04-08 11:02:18

iceman wrote:

Well done!
strengthen from your success you can now foucs on a deeper understanding in Legic tags.

Thanks, no idea how to go deeper yet

mosci wrote:

fine - thanks for providing a example of a unsegmented user-credential
I will have to implement that into my legic.lua

Hah no problem.
Goodluck with it!
I looked at your script and I must say, you did a good job ;p

mosci · 2016-04-08 13:02:27

BTW ... I'm very interested in the 'original software' - so if you can make me a copy of that - would be great
hopefully it is the csw-2000 or csw-4000 software

Last edited by mosci (2016-04-08 13:03:33)

Vinnie · 2016-04-08 13:10:04

mosci wrote:

BTW ... I'm very interested in the 'original software' - so if you can make me a copy of that - would be great
hopefully it is the csw-2000 or csw-4000 software

Ok I will ask some information about the software next week.
But chances are very small that I will be allowed to copy that

mosci · 2016-04-08 13:24:19

maybe you should make a copy first - and ask afterwards

mosci · 2016-04-09 10:08:11

Vinnie wrote:

Thanks, no idea how to go deeper yet

oh, missed that ...
you can help us to understand a unsegmented user-credential in more detail ...
so, we only do know what is needed to copy a valid tag, but
we don't know the data-structure

we only know about 10 of 16 bytes
UID = 4 bytes
uidCRC= 1 byte
DCF= 2 byte
data-portion= 2 bytes
dataCRC= 1 byte

assuming there is some kind of header ... we do not know how much bytes, and what bits does have what meaning.
we know there is a stamp but we do not know how long it is and where it starts exactly
we do not know much about 7..12 ...
but, the header would be before the stamp, and before the data-portion ...
we know also, that in a 'real-life'-scenario the stamp would be longer than 2 bytes and shorter than 8 bytes (min 3 / max 7)

value 08: I assume this is treated like on Matser-Token (low nibble/bit 0..3 = WRP = DataLen inklusive stamp)
then bit 4..7 maybe does have also some meaning like WRC,OLE,RD - which can be tested best
with the original software
value 02: could be first stamp-byte .... but, since it has a value of 2 and the assumed 'data-portion' does have a length of 2 bytes
it might be that this byte maybe isn't the first stamp byte ...
so I would test what happens if I made a 03 out of it, prepend a 00 to the 'data-portion' (13..15 = 00 44 96)
append the crc8 (0..3+7..15) to addr 16 and
change addr 7 to value 09
maybe the tag would work also, then all assumptions are satisfied
but then we still need to test if addr 08 does do more then just that ...

or
we can check if the controller is configured to 'auto-update' from SAM63-tags, then you would be able to create tags, with different stamp, but the same 'data-portion'

And with access to the software ... it should just be : read the tag, play around with some options in the software, and compare byte-changes on the tag
unfortunately I have never get my hands on a 'legic software'
so, you can do a lot of

Last edited by mosci (2016-04-09 11:05:39)

Vinnie · 2016-04-09 13:49:49

That would be indeed interesting to know what those bytes mean.

I have another card which was an employee card embedded into a banking card.
The data looks like this:

40 a0 3c d7 6e 60 ea 09
02 0a 00 05 05 X X X

(I will start hiding the ID of the user with "X" because I don't want to harm the business.)

Byte is 7 is changed and byte 12, which could be interesting for further analysis.

Monday I will have time to check the mastertoken of the RFID administrator (which is called a GAM?).
He uses that card to make changes to the cards. What kind of changes (probably bytes 13-15) will be known after I did some test with his software.

After that we will probably know more about the rest of the bytes.

mosci · 2016-04-09 15:07:21

the 'tripple X' ... is it really a 3 byte ID or is it 2 byte ID and 1 byte CRC?

the master-token would be a IAM or GAM - both will do the job user-credential-creation
Master-Token are only interesting because they hold the main stamp (the stamp on a user-credential is always the same (or longer) byte-sequence as the stamp of the master-token)
but if you know where the stamp starts, you can create your own master-token with the minimum of a 2 byte stamp - and this master-token would allow you in the software to create any master-token or user-credential you would - so master-token are not that interesting if you have a PM3, you just need them in an official environment - but you can create it easily with a PM3 to bypass this 'security-feature' of legic

Vinnie · 2016-04-09 15:21:01

mosci wrote:

the 'tripple X' ... is it really a 3 byte ID or is it 2 byte ID and 1 byte CRC?

It's a 2 byte ID + CRC of byte 0-3 + 7-12.
What you assumed

Ok, maybe the master-token gives us more information where the main stamp starts

Vinnie · 2016-04-11 15:22:25

I have some more information

I made a mistake. I told you that byte 0x7..0xc is nog writeable.. but apparently it is.
So the only thing I can't change on the card is the UID and I don't know how to change the DCF yet.

I was allowed to make a scan of the IAM card.

40 4f c2 c6 a5 20 f8 08
02 0a 00 05 00 00 00 bc
00 00 00 00 00 ee 00 00

It has a different DCF and the 0xc..0xe is 00. And on byte 21 there is a value. (which is the start of the payload??)
I tried to copy this one aswell. But didn't succeed copying the DCF value.

Unfortuantly I am not allowed to copy the original software and I do not have access to it so that's a nope.

But I got a screenshot with information about the values:
Legic software
The scanned card is the one in the first post,
with these values:

79 74 26 65 31 60 ea 08
02 0a 00 05 03 44 96 71

mosci · 2016-04-12 12:08:14

so ...
DCF is changeable, but only in one direction (lower the value - so you will need to have a blank tag, where dcf is 'ff ff' or a tag that has actually a dcf-value which is higher than the desired one) - and you need some small change in the code.
I don't really know if Iceman included that into his fork.

'08' (addr 0x07) seems to be a header ... the stamp on the IAM is 4 byte long (0xfc- 0xf8=0x04) thus
02 0a 00 05 is the stamp of the IAM tag
and since the stamp on a SAM should be at least one byte longer: 02 0a 00 05 03 is the stamp on the SAM

byte addr 0x21 on the IAM will be a checksum (crc8) over certain bytes: UID+DCF high+DCF low+byte-addr 0x06..0x07+stamp (0x08..0x0c => '02 0a 00 05')
so crc8 over 404fc2c6f82008020a0005 => EE

Last edited by mosci (2016-04-12 15:46:58)

Vinnie · 2016-04-12 14:21:53

mosci wrote:

so ...
DCF is changeable, but only in one direction (lower the value - so you will need to have a blank tag, where dcf is 'ff ff' or a tag that has actually a dcf-value which is higher than the desired one) - and you need some small change in the code.
I don't really know if Iceman included that into his fork.

DCF value "60 ea" is higher then "20 f8". So it should be possible to change the DCF value?
(All my testcards have "60 ea" as DCF which means its not a master token.)
A bit strange that the DCF for master tokens are lower than normal cards..

mosci wrote:

'08' (addr 0x07) seems to be a header ... the stamp on the IAM is 4 byte long (0xfc- 0xf8=0x04) thus
02 0a 00 05 is the stamp of the IAM tag
and since the stamp on a SAM should be at least one byte longer: 02 0a 00 05 03 is the stamp on the SAM

This header could mean the type of card. Because employee cards embedded in banking cards have "09" as value.

mosci wrote:

byte addr 0x21 on the IAM will be a checksum (crc8) over certain bytes: UID+DCF high+DCF low+byte-addr 0x07..0x08+stamp ('02 0a 00 05')
so crc8 over 404fc2c6f82008020a0005 => EE

Will confirm this when I am able to lower the DCF value on the cards and create a copy of the IAM card.
(rfid administrator asked for a backup copy )

A schema of what we know now:
(Probably not perfect yet)
rfid card

mosci · 2016-04-12 15:05:19

Vinnie wrote:

DCF value "60 ea" is higher then "20 f8".

no, it isin't - on the tag the dcf ist stored on address 0x05 & 0x06 whereas 0x05 hold the lower byte and 0x06 holds the higher byte
thus: the DCF on your SAM is for real 'EA 60' and on your IAM it is 'F8 20' - as you can see, you can't make a IAM out of a SAM - only the other way round!

Vinnie wrote:

A schema of what we know now:
(Probably not perfect yet)

the stamp of the SAM is one byte longer then on the IAM thus: stamp an the SAM is: 02 0A 00 05 03 (5 bytes)

Last edited by mosci (2016-04-12 15:09:35)

Vinnie · 2016-04-12 16:18:18

Ok, I understand the DCF now

(I updated the rfid schema)

mosci · 2016-04-12 17:50:11

the structure for the Master-Token will be:
UID: 40 4f c2 c6
uidCRC: a5
DCF low: 20
DCF high: f8 (also stamp-len -> FC - F8 = 04)
Header: 08
Stamp: 02 0a 00 05 (write protectd for legic security-modules)
(should be) unsused: 00 00 00 (write protectd for legic security-modules)
address 0x0f: bc (write protectd for legic security-modules)
unused : 00 00 00 00 00
mastertokenCRC:ee
unused: 00 00

Header (byteaddr 0x07) in detail:
bit 0..3 = WRP (write protection - can only be read by legic-security-module, but not written)
bit 4..6 = WRC (read/write protection - only works if RD is set also)
bit 7 = RD (tells the security-module how many bytes of the stamp have to match on the reader-side to allow reading of this part - never set on Master-Token)

hex: 08
bin : 00001000
bit 0..3 (lsb right)= WRP = 1000 = 8 so, the 8 bytes (starting at stamp-byte 0) are write-protected (if a legic security-module is used)
WRC: not set
RD: not set

on byte-addr 0x0f is a crc8 over uid+ header (addr 0x07) + addr 0x08..0x0e (404fc2c6+08+020a0005000000)
on byte-addr 0x21 is a crc8 over uid+ dcf high+ dcf low+ addr 0x07+ stamp (404fc2c6+f820+08+020a0005)

funny thing is that the software says that 'Anlagennr'=0344 whereas '03' is part of the stamp (from my point of view) and '44' is part of the user-mapping - so maybe my assumptions are not totally correct !?!
From what I have learned: The Stamp on a SAM must be (at last) one byte longer than on the Master-Token from which the SAM was created from ... at least, so it might have 2 byte more also, but then there is only one byte left for user-mapping, which should be a little to short. so I'm pretty unsure about that - but it works anyway.

I'm not interessted in such a 3rd-Party sorftware, I thought you where comming up with some original legic software (csw-2000 or csw 4000)

Last edited by mosci (2016-04-12 21:10:51)

Vinnie · 2016-04-13 09:43:51

I made a visual for the IAM card aswell now:

mosci wrote:

funny thing is that the software says that 'Anlagennr'=0344 whereas '03' is part of the stamp (from my point of view) and '44' is part of the user-mapping - so maybe my assumptions are not totally correct !?!
From what I have learned: The Stamp on a SAM must be (at last) one byte longer than on the Master-Token from which the SAM was created from ... at least, so it might have 2 byte more also, but then there is only one byte left for user-mapping, which should be a little to short. so I'm pretty unsure about that - but it works anyway.

That is the reason why I thought the ID of the user is byte 0xc...0xe.
This is also the number that is printed on the card. (Which is another weakness because we could now impersonate somebody by just having to see their card, but you still need to scan another card for the stamp etc.)

From now on I think we found almost everything that there needs to be found here.
I will now focus more on the coding part.
First thing I will research is how the "writeRaw"-function of you is implemented.
Once I know the basics for sending commands and etc, I can start making my own functionality.(Like simulating, lowering DCF)

mosci · 2016-04-13 10:07:08

lowering the DCF is quiet easy ... you don't need WriteRaw for that
as I remember there are just two changes needed (but maybe I forgot something, you can dig in my commits )
if you don't want to use my fork - which I can totally understand ) ...

adjust the addr-check in function legic_write_byte from 0x06 to 0x04

implement a reverse writing for 0x05 & 0x06 in fucntion LegicRfWriter (0x06 must be changed before 0x05)

then ... just load a tag into the buffer (hf legic read)
save the buffer-data to file (hf legic save test.hex)
edit the file with your favorite text-edior, and change the DCF to whatever you want
load the file into the buffer (hf legic load test.hex)
and write the new dcf from buffer to tag (hf legic write 0x05 0x02)
this should do the trick - at least on my machine it does ;-)

emulating would be much more complicated

Last edited by mosci (2016-04-13 10:24:04)

Vinnie · 2016-04-13 12:34:48

Aight thanks for the help
The code reference will help me getting started.

I will try to lower DCF when I find a card with "ff ff" as DCF
(all my testcards have "60 ea")

mosci · 2016-04-13 12:36:55

I can sell you empty tags (2.50 €/piece + shipping) - no problem ... I've got (too) many of them

btw ... your drawing for the Master-Token reports 5 Stamp bytes, but there are only 4
0x0c..0x0e are empty, but will be used on Master-Token with a longer Stamp
I guess they are just kind of 'reserved' and write-protected for the maximum possible Stamp_Len of 7 bytes+crc
so for my eyes it looks more like this (without engagement):

Master-Token:
3rd-party Master-Token
User-Credentials:
3rd-party User-credential
the last one is the 'embedded' one, I suppose the firmware/software checks the header too - so like you mentioned, that's some kind
of 'tag-type' bit/byte in there

Last edited by mosci (2016-04-14 21:18:08)

Vinnie · 2016-04-18 09:52:41

mosci wrote:

I can sell you empty tags (2.50 €/piece + shipping) - no problem ... I've got (too) many of them

Not necessary

Thanks for the correct visuals!

Vinnie · 2016-04-26 12:56:20

Question about read distances.
With the offcial HF proxmark reader I can read the card from 0,5 cm.
Another legic reader I have has a read distance of ~ 5 cm.

The official website states that a read distance of 50 cm can be achieved.
Is this true?

It probably depends on the cards antenna also?

And a question about NFC - legic.
Are there tools to read legic prime cards with NFC enabled tablets/cellphones?

iceman · 2016-04-26 13:08:20

The pm3 short distance is because of how its imp in the arm-side. Some kind of bit-banging (on-off the antenna power). Making the output low and the antenna powers the tag. I'm planning to remake it, but haven't gotten around to contiue what I've started.

Vinnie · 2016-04-26 14:08:45

iceman wrote:

The pm3 short distance is because of how its imp in the arm-side. Some kind of bit-banging (on-off the antenna power). Making the output low and the antenna powers the tag. I'm planning to remake it, but haven't gotten around to contiue what I've started.

Ok thanks for the info
Any idea how far the read distance can be for legic prime?

iceman · 2016-04-26 17:40:28

Don't know, but up to 5cm should be do-able with a better imp.

Proxmark3 community

Announcement

#1 2016-04-06 14:38:29

My Legic Prime story

#2 2016-04-06 16:58:07

Re: My Legic Prime story

#3 2016-04-06 18:20:43

Re: My Legic Prime story

#4 2016-04-06 20:20:52

Re: My Legic Prime story

#5 2016-04-07 07:52:55

Re: My Legic Prime story

#6 2016-04-07 11:01:46

Re: My Legic Prime story

#7 2016-04-07 11:15:14

Re: My Legic Prime story

#8 2016-04-07 12:01:06

Re: My Legic Prime story

#9 2016-04-07 12:15:27

Re: My Legic Prime story

#10 2016-04-07 12:38:10

Re: My Legic Prime story

#11 2016-04-07 12:43:26

Re: My Legic Prime story

#12 2016-04-07 12:58:05

Re: My Legic Prime story

#13 2016-04-07 13:18:13

Re: My Legic Prime story

#14 2016-04-07 13:25:30

Re: My Legic Prime story

#15 2016-04-07 13:39:40

Re: My Legic Prime story

#16 2016-04-07 14:04:10

Re: My Legic Prime story

#17 2016-04-07 18:30:27

Re: My Legic Prime story

#18 2016-04-08 09:29:40

Re: My Legic Prime story

#19 2016-04-08 09:52:14

Re: My Legic Prime story

#20 2016-04-08 10:16:10

Re: My Legic Prime story

#21 2016-04-08 11:02:18

Re: My Legic Prime story

#22 2016-04-08 13:02:27

Re: My Legic Prime story

#23 2016-04-08 13:10:04

Re: My Legic Prime story

#24 2016-04-08 13:24:19

Re: My Legic Prime story

#25 2016-04-09 10:08:11

Re: My Legic Prime story

#26 2016-04-09 13:49:49

Re: My Legic Prime story

#27 2016-04-09 15:07:21

Re: My Legic Prime story

#28 2016-04-09 15:21:01

Re: My Legic Prime story

#29 2016-04-11 15:22:25

Re: My Legic Prime story

#30 2016-04-12 12:08:14

Re: My Legic Prime story

#31 2016-04-12 14:21:53

Re: My Legic Prime story

#32 2016-04-12 15:05:19

Re: My Legic Prime story

#33 2016-04-12 16:18:18

Re: My Legic Prime story

#34 2016-04-12 17:50:11

Re: My Legic Prime story

#35 2016-04-13 09:43:51

Re: My Legic Prime story

#36 2016-04-13 10:07:08

Re: My Legic Prime story

#37 2016-04-13 12:34:48

Re: My Legic Prime story

#38 2016-04-13 12:36:55

Re: My Legic Prime story

#39 2016-04-18 09:52:41

Re: My Legic Prime story