Журнал "Компьютерра" №754

Год назад я купил на Павелецком вокзале такой билет: это просто старый Mifare Ultralight, у которого перерезана антенна, а сзади налеплена наклейка с чипом (вроде тех, что используются для маркировки грузов), которая собственно и программируется. Мне стало интересно. Когда появился ридер, решил сам попробовать: сперва изучал формат, разбирался, где какая информация записана (номер по внутренней базе метро, тип билета, количество поездок и т. д.). Застопорился на "хэше" - данных, генерируемых для защиты от подделки, - до того момента, пока мне в руки не попали программы "Смартека", подрядчика, создававшего систему для московского метрополитена. Случилось это довольно странным образом: грубо говоря, человек написал в аську и предложил, мол, "ты этой темой вроде бы интересуешься; я поковырялся, ничего не получилось - может, ты окажешься удачливее". Своих источников он раскрывать не стал, просто передал мне архив. Как выяснилось позже, это ПО - одно из самых уязвимых мест системы.

До сих пор клонирование Mifare Ultralight сводилось к созданию устройств, эмулирующих билет, вы пошли по этому же пути?

- Я не стал заморачиваться созданием эмулятора. Технически эта задача не особо сложная, современного восьмибитного контроллера для этих целей вполне достаточно. Но очевидно, что таким девайсом неудобно пользоваться - так что интерес здесь скорее теоретический. Конечно, можно вытащить катушку и сигнальные проводки через рукав, но согласитесь, решение не слишком красивое. Кроме того, пройдете вы с таким эмулятором несколько раз, и данные используемого билета, скорее всего, угодят в стоп-лист. Да и по правде говоря, мною двигало не столько желание ездить бесплатно, сколько интерес изучить работу системы.

Взломать Ultralight с помощью информации, полученной из билетов, невозможно - защита на очень приличном уровне. Как выяснилось из моих исследований, "хэш" - это не что иное, как имитовставка, вырабатывающаяся по алгоритму ГОСТ, метод 16-3. Ключи, необходимые для генерации "хэша", без которого не удастся сделать работающий билет, распространяются в специальном файле-хранилище зашифрованными. Причем, судя по формату файла, он един для компьютеров обслуживающего персонала, турникетов и терминалов проверки. Ключи, а также новые версии программы распространяются по внутренней сети подземки.

Расскажите, как устроена инфраструктура метрополитена?

- На станциях сеть построена примерно следующим образом: есть несколько компьютеров у кассиров, у старшего кассира и компьютер ревизора. Предположительно, где-то находится и аппаратный пункт, "приземляющий" локалку на сеть RS-485, которой объединены турникеты и терминалы проверки билетов. Хотя есть также информация, что локальная сеть Ethernet и сеть устройств RS-485 не объединены (или же объединены, но не на всех станциях), а обновлением ПО и ключевой информации в турникетах и терминалах проверки занимается специальный обслуживающий персонал.

По сути, билет - это самодостаточный организм: в нем записана вся информация, необходимая для прохода, включая унифицированный идентификатор, определяющий географическую зону или предприятие; тип билета (например, на одну поездку, социальный и т. д.); количество оставшихся/совершенных поездок и все даты (дату выдачи, сроки действия), поэтому турникету дополнительно никуда обращаться не надо (за исключением случаев предотвращения повторного прохода по социальному билету "ультралайт" - так как время прохода в билете не указано, турникет обращается за этой информацией к своим "соседям", и, если этот билет уже был недавно использован, отказывает в повторном проходе до истечения определенного времени).

Однако при использовании билетов информация о них заносится в память турникетов (это нужно хотя бы для того, чтобы вести статистику) и в определенное время (возможно, по расписанию) сливается в центральную базу данных и уже там обрабатывается. Каждый раз при покупке билета его данные заносятся в локальную БД, а оттуда отправляются в ЦОД. Это подтверждают метрополитеновские программы: они могут функционировать как в режиме накопления данных, так и в онлайн-режиме, сразу отправляя информацию в центральную базу. Если несколько раз засвечивается номер, который не зафиксирован в БД, это быстро выявляется и билет попадает в стоп-лист, который закачивается в турникеты при следующем обновлении (их память, конечно, не резиновая, но даже за вычетом объема памяти, используемой микропрограммой турникета в служебных целях, ее должно хватить, чтобы занести достаточное количество записей). Так что все сгенерированные мною Mifare Ultralight в течение нескольких дней попадали в стоп-лист.

А можно ли многократно перезаписывать карточку?