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
I'd like to identify the checksum used in hotel cards in the OTP section on page 3 of their ultralight cards
it appears to be calculated on the 7 byte UID of the Ultralight chips.
here are some UID's and their corresponding Page 3 checksum: (in hex)
[ICQ me for samples]
any ideas?
Last edited by marshmellow (2014-08-08 14:05:22)
Offline
Are you absolutely sure that no other bytes are changing between cards ?
Offline
here it is again with all the memory pages that are not blank (includes the UID which is in page 0 and page 1)
Last edited by marshmellow (2014-08-08 14:05:36)
Offline
the only additional changing values are the BCC0 and BCC1 which are auto checksums on the UID. (i'd guess they aren't used in the calc but could be wrong)
Offline
Well, I found some good correlation; can you double check those UIDs and their correspondant Page3 values:
80223BC2E5D004
8029C4FAB1B204
Offline
I confirmed what is above is what reads on those tags.
Offline
I would guess that instead of a scramble bits this is likely a calculated checksum of some sort, possibly a xor or similar
Offline
For now I found this:
3 values always correct except for the 2 UIDs mentioned in the post above where only 2 are correct.
The yellow-marked UIDs are very similar and can help to find out the solution.
Last edited by asper (2014-02-22 09:14:39)
Offline
[ICQ me for samples]
Last edited by marshmellow (2014-08-08 14:05:59)
Offline
044E879A1F2380 F7057E17
0442952AC42F80 25101210
04A4C59A1F2380 B510D420
0414525AA82A81 F313570C
04164A2AC42F81 6A07F608
042BB732C42F80 570BAB11
Offline
@app_o1
Having a very quick look:
- the 6th UID value correspond to the 2nd block value (except for 1 case);
- the 4th UID value correspond to the 6th block value (except for 2 cases).
Also your values seems to be with bytes inverted indianess:
044E879A1F2380 -> 80231F9A874E04
now 80231F9A874E04 is more similar to marshmellow values ex. 802D018AF75C04 (strats with 80 ends with 04): you probably read it with a different reader.
In my opinion the algo is based on the 2nd part of the UID (divide it in 2 blocks and take the right one) elaborated with a probably quite simple math function.
Last edited by asper (2014-03-29 08:48:14)
Offline
I got the UID from the command hf 14a reader. Or from a simple NFC app on my phone.
Block 0 or page 0 combined with page 1 (minus the last 2 hex characters of page 0) gives the UID ?
UID : 04 2b b7 32 c4 2f 80
Block 00:04 2b b7 10
Block 01:32 c4 2f 80
Block 02:59 48 00 00
Block 03:57 0b ab 11 [0]
In the case of the magic UID cards, Block/Page 00, 01 and 02 are writable ?
And then Page 03 is calculated from Page 00 and 01 ?
What is the correct word "page" or "block" ?
Offline
Block 0 or page 0 combined with page 1 (minus the last 2 hex characters of page 0) gives the UID ?
Yes. http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf page 11
In the case of the magic UID cards, Block/Page 00, 01 and 02 are writable ?
Yes
And then Page 03 is calculated from Page 00 and 01 ?
Not by default. Page 13 of the above link. Bytes in this block can be used as you want according to the datasheet specs/limitations.
What is the correct word "page" or "block" ?
It's the same.
How many blocks has your key ? 15 or more ? If more (47) it's an ultralight C.
Last edited by asper (2014-03-29 13:05:33)
Offline
The perfect answer. Thank you for your patience. I haven't read the datasheet obviously :s
Offline
How many blocks has your key ? 15 or more ? If more (47) it's an ultralight C.
Offline
According to my phone: alll of them are 16 pages.
On the Proxmark, all of them go from Block 0x00 to 0x0F
Is the Proxmark actually able to do the difference between UL and UL C when using command hf mf urdcard ?
Last edited by app_o1 (2014-03-29 13:55:43)
Offline
No.
Offline
According to my phone: alll of them are 16 pages.
Is the Proxmark actually able to do the difference between UL and UL C when using command hf mf urdcard ?
Not yet, hopefully have an Ultralight C on order. So might happen in the next few months?
Offline
Great man
Offline
Updated list:
ICQ me for samples
Any help on math algo's would be greatly appreciated.
The more I look at it the more I believe it is calculated on Page 0's 4 bytes only
Last edited by marshmellow (2014-08-08 14:06:20)
Offline
@marshmellow:
Hello, your dumps are reversed or Little Endian, as I see. According to NXP specification, Mifare Ultralight card's UID must start with $04 byte, which is manufacturer code (NXP). So please rearrange your dumps to be reversed in byte order, like your last example : 84 36 E5 B2 23 8A 04 is equal to 04 8A 23 B2 E5 36 84. So, 04 8A 23 are first 3 bytes of UID, 25 is first checksum (88 xor 04 xor 8A xor 23, where 88 is CT= cascade tag ) and Page 1 bytes are next four bytes of UID (B2 E5 36 84). Checksum for them is in Page 2 byte 0 (E5). Other bytes are proprietary (not documented).
According to this, your OTP (page 3) value is 13 02 BA 16.
The cards you are showing are "Vingcard" hotel system guest cards. They have OTP values calculated from UID, Page 2 and some keys. If OTP is regular, hotel system will accept them for programming, otherwise not.
There is known solution, as I heard some rumors.... but it can not be made public since Vingcard has a good team of lawyers and people are little afraid of them
Whole idea is that hotel can use only Vingcard cards, e.g. they buy cards from Vingcard dealers for much more money than regular blank Ultralight card.
Offline
There was this guy who looked into the vingcard structures..
http://blog.j-michel.org/post/773785321 … er-matters
http://blog.j-michel.org/post/857556297 … n-vingcard
Offline
@marshmellow:
Hello, your dumps are reversed or Little Endian, as I see. According to NXP specification, Mifare Ultralight card's UID must start with $04 byte, which is manufacturer code (NXP). So please rearrange your dumps to be reversed in byte order, like your last example : 84 36 E5 B2 23 8A 04 is equal to 04 8A 23 B2 E5 36 84. So, 04 8A 23 are first 3 bytes of UID, 25 is first checksum (88 xor 04 xor 8A xor 23, where 88 is CT= cascade tag ) and Page 1 bytes are next four bytes of UID (B2 E5 36 84). Checksum for them is in Page 2 byte 0 (E5). Other bytes are proprietary (not documented).
According to this, your OTP (page 3) value is 13 02 BA 16.
Thanks for the information. I have yet to get my hands on a full datasheet for the ultralight chips so I didn't realize my reader auto reversed these. the datasheet I have it doesn't even list the manufacturer bytes or explain the UID section at all.
The cards you are showing are that company's hotel system guest cards. They have OTP values calculated from UID, Page 2 and some keys. If OTP is regular, hotel system will accept them for programming, otherwise not.
There is known solution, as I heard some rumors.... but it can not be made public since that company has a good team of lawyers and people are little afraid of them
Whole idea is that hotel can use only that company's cards, e.g. they buy cards from that company's dealers for much more money than regular blank Ultralight card.
yes I removed the company name because of said lawyers. But I also know that hotels are dissatisfied paying that premium and some are buying from a Chinese company who appear to have cracked this.
If anyone is willing to share information more privately my ICQ # is 6s|x8f@ur00seven7four
Offline
There was this guy who looked into the vingcard structures..
http://blog.j-michel.org/post/773785321 … er-matters
http://blog.j-michel.org/post/857556297 … n-vingcard
Thanks for the links! interesting info.
Offline
...
Last edited by marshmellow (2014-08-08 14:06:37)
Offline
@marshmellow:
Page 1 bytes are next four bytes of UID (B2 E5 36 84). Checksum for them is in Page 2 byte 0 (E5).
do you have the calculation for this checksum?
Thanks
Offline
isn't it a XOR ?
Offline
isn't it a XOR ?
it appears it is a straight xor. yes. I kept trying it with the 88 like the first part, but that is not needed. Thanks.
Offline
@marshmellow:
Any progress, news?
Offline
none. I haven't had enough math training to know where to go from here. but I'm trying to talk with those that have.
Last edited by marshmellow (2014-06-24 13:53:32)
Offline
Unofficially, that algorithm is weak and broken. Nobody wants to make it public 'cos some people have it under NDA or some of them are selling pre-programmed cards with "valid" OTP values.
If you do not have business interest in it, I suggest to wait, hoping that someone will make it public soon.
Offline
for those that don't want to make it Public, my private ICQ number is listed in this topic on an earlier post.
Last edited by marshmellow (2015-04-15 00:14:46)
Offline
Unofficially, that algorithm is weak and broken. Nobody wants to make it public 'cos some people have it under NDA or some of them are selling pre-programmed cards with "valid" OTP values.
If you do not have business interest in it, I suggest to wait, hoping that someone will make it public soon.
What makes you think someone will make it public soon? if it is weak and broken, and no one will share how, I will continue examining and sampling so that it can be broken again. if I break it I will continue sharing with the community like I always try to do. if someone else has broken it and shares it with me it would not be mine to share publicly so I would not.
And it may prove to have business interest to me, I will not deny or hide that fact.
Offline
You asked: What makes you think someone will make it public soon?
Cos it is weak, as you can see. It has two nibbles repeating in each output image. I say "image", 'cos if it is hash, it couldn't be reverse engineered.
Also, it has only 4 bytes, so common sense says it is not so hard to break.
Also, Vingcard moves to much higher security cards and Ultralight is kept only as cheap guest card. Many hotels still use them and that makes the main reason for keeping Ultralight.
As I said, some people knows algo, but it is under Non-Disclosure Agreement with Vingcard.
Also, you can find chinese manufacturers selling Vingcard Ultralight cards. So, someone is still making money on that. If you make it public, it is not a problem. Problem lies in fact that many of them will lose a lot of money if you show people how to make cheap Ultralight card "valid" in Vingcard hotel system. You can, for example, get Ultralight card as low as 0.20 $ and hotels are paying a few bucks for them when buying from Vingcard dealers.
Personally, I think that I wouldn't like to see some lawsuits regarding intellectual property or similar. Remember what happened when Mifare 1K Crypto1 algo was officially broken in 2008 (or it was 2009). Finally, NXP lost that trial, but it took some time.
So, solution of this OTP value problem is still very commercial. That is the reason I asked if you have business interest.
Best regards.
Offline
I am aware of the legal implications, and I appreciate your concern.
Regards.
Offline
if it is a hash, then I suspect 4bytes will only be a subset of the generated hash, so if you cant identify the hash-algo it will be easier to find weaknesses. But since it is a subset of the hash-bytes the number of false positives will be very high. In some other cases I've seen DES, AES used as a hash-algo, so you figure out the math yourself in finding the correct key used.
Offline
If you mean Ultralight UID changeable? (aka magic) , I suppose you can search on taobao and see what the price is there.
I think I paid 15yuan(?)
Offline
Anyone heard of a leak so far?
Offline
@bishop, what leak is it that you are after?
Offline
I'm also interested in this. I've got the Iceman fork on my Proxmark,and I'm trying to test the ability to simulate the opening of a hotel door lock using Ultralight tags to show a client, But all the Proxmark does is claim its simulating the card and nothing happens. I'm somewhat confused.
Last edited by neoprema (2017-02-01 11:26:58)
Offline
mifare sim can be somewhat finicky especially against some readers. positioning and antenna strength are often the keys.
Offline
ok,... since a forum user mailed me about this old thread, I revisited it..
Progress so far is 5 of 8 nibbles is calculated correct. Very annoying to have only 3 nibbles left.
Offline
... it was partially wrong, however it layed down the path to actually finding it.
Given these samples here you can figure it out. Its a good excercis for your brain.
Offline
Hello.
I am also looking for OTP algo and have over 1000 cards.
Does somebody find algo?
Offline
Offline
Pages: 1