Как устроен билет Московского Метро, часть 2

Спустился в метро в очередной раз, купил билет на 5 поездок и обнаружил, что кое-что поменялось на билете и он теперь более защищен от чем было раньше

Например, lock bytes теперь имеют значение F0 99, а не 00 00, что привело к изменению формата "трека":


17 C9 2D 00 00 05 00 00 27 AB 28 41 00 00 00 00

+0 Len 2 ro Дата покупки билета (может быть дата + 1 день?)
+2 Len 1 ro Срок действия билета в днях (от дня покупки!)
+3 Len 1 ro 00 ?
+4 Len 1 rw 00 ?
+5 Len 1 rw оставшиеся поездки
+6 Len 2 rw на новом билете 00 00
+8 Len 4 rw MAC
+С len 4 read-only всегда 00 00 00 00 ?

Раньше после первого прохода дата по смещению +0 менялась на дату первого прохода, теперь нет (этот блок read-only), т.е. билеты стали работать дольше, нет правила "билет работает X дней со дня первого прохода". Это хорошая новость. Плохая новость для желающих ездить бесплатно это то, что теперь валидаторы "портят" OTP, то есть состояние карты нельзя восстановить полностью и она в конце концов протухает!

Все это правильные меры, но смущает то, что оставлена возможность заблокировать запись в OTP, зачем? Казалось бы байты блокировки должны быть F199, а не F099... иначе можно поменять их на F899 и... интересно, что валидатор делает если не может поменять биты OTP? Это очень легко проверить, что я бы и сделал, если бы ездил на метро :)

Так же немного подозрительно, что авторы блокируют запись в некоторые блоки "трека"... если это сделано из соображений "зачем давать писать куда писать не надо", то все в порядке... это правильно... но вдруг это значит, что MAC не включает в себя UID, как я думал должно было бы быть, чтобы исключить клонирование. Вдруг защита от записи это на самом деле всего лишь защита от использования б/у карт метрополитена для изготовления новых клонов?! Тогда клоны можно делать, но использовать "чистые" карты...

Это то же легко проверить...

И еще, хорошо бы догадаться, что пишется по смещению +6...

Хорошо бы посмотреть на билет в 10 проходов или какое-то там максимальное?

Видимо все же придется спуститься в метро.

Все будет еще веселее, когда таки опубликуют алгоритм Crypto1 и желающие смогут наконец узнать ключ mifare московского метро и заглянуть внутрь... там нас могут ждать еще большие чудеса.

Сколько еще итераций потребуется авторам этого "приложения", чтобы наконец максимально затруднить жизнь мошейников и окончательно защитить билеты от подделки? Почему-то у них не получается с первого раза, помните смешную историю со скотчем и магнитными билетами? Это конечно был баг, но это была не опечатка! Mifare Ultralight как он выглядел в прошлом году баг такого же порядка. Хорошо, что люди исправляются, плохо, что так медленно.

Как устроен билет Московского Метро?

Купил вчера (28.07.2007) билет метро Mifare Ultralight, номер 0024797406 на 10 проходов, "желтый ящик" говорит про него, что его надо использовать до 28.08.2007. Вот его содержимое:

04 E7 4E 25 D1 C4 02 80 97 48 00 00 00 00 00 00
41 87 50 17 A6 0D E4 16 37 1B C0 00 16 38 00 00
16 38 1E 40 0A 00 00 00 00 04 C1 43 00 00 00 00
16 38 1E 40 0A 00 00 00 00 04 C1 43 00 00 00 00

Насколько можно догадаться первый сектор
4187 -- не ясно, что это такое
5 -- бывает 5 бывает 6
0 -- может быть часть номера билета
17A60DE = 24797406 т.е. номер билета. (Не ясно начинается ли номер с 0?) Странно, если номер занимает не целое число байт.
4 -- не ясно, похоже на константу
1637 -- похоже на дату, дата изготовления билета (?)
1B C0 00 -- не ясно что такое, на всех билетах, которые я видел до сих пор -- константа
1638 -- похоже на дату, дата продажи билета (?)
00 00 -- не ясно, что такое

второй сектор (третий -- его резервная копия)
1638 -- дата первого использования, или дата начала действия билета, если билет новый
1E -- похоже на срок действия в днях (30) от даты продажи билета (?)
40 -- не ясно, что это такое, но при первом использовании превращается в 00, думаю, что "желтый" ящик именно по этому полю определяет, что билет новый и выдает другое сообщение ("использовать до ...")
0A -- количество оставшихся проходов
00 00 -- не ясно
00 -- бывает 01 на билетах 20 поездок
00 04 С1 43 -- похоже на MAC
00 00 00 00 -- не ясно

после первого использования в турникете 29.07.2007, второй сектор изменил значение на

16 39 1E 00 09 00 00 00 DB 0E F1 D5 00 00 00 00

интересно, что изменится при проходе завтра?

Превратится ли 1639 в 163A, что будет означать, что это дата прохода, или не изменится и тогда -- это дата начала действия билета и + 30 дней к ней -- срок окончания действия билета.

Новое значение "второго сектора"

16 39 1E 00 08 00 00 00 A1 46 F9 D4 00 00 00 00

что подтверждает, что дата 16 39 это дата первого прохода!

Видно так же, что кроме оставшегося количества проходов (стало 8) меняется и MAC или как там они его называют

Ясно, что билет можно "восстановить" в исходное значение, не видно что этому может помешать!

Скорее всего, система обнаружит подделку через некоторое время. Через час? Два? Сутки?

Надеюсь, что "MAC" включает в себя уникальный ID кристалла, иначе карту будет слишком легко клонировать!

Интересно так же. как система ведет себя если резервная копия трека отличается от основной... на магнитных билетах это одно время приводило к проблемам.

Надеюсь на Ultralight их нет, но с другой стороны зачем нужна копия? Что если оригинал говорит, что осталось 1 поездка, а копия, что осталось 10?

Все мои гипотезы легко проверить, одна беда -- я не пользуюсь метро! :)

Есть желающие помочь?