Как сделать копию транспортной карты
Как взломать транспортную карту.
Сразу скажу, я не хакер и не взломщица, а простой фронт-энд разработчик, мои знания по работе с ПК, если отбросить знания во фронт-энд разработке, можно охарактеризовать, как «опытный пользователь».
Я не разрабатывала специальные приложения, как делали это авторы упомянутых статей, а покажу, как доступными средствами можно легко взламывать транспортные карты. Методы взлома известны давно (лет 5-7 точно).
Если бы я, как разработчик, использовала старые версии фреймворков с известными уязвимостями, мне бы давно оторвал работодатель голову, но на разработчиков транспортных систем это, по-моему, не распространяется. Возможно, это связано с низкой подкованностью самих разработчиков.
Но вернусь к взлому. Итак, обо всем по порядку.
Все описанные мною действия я проводила осенью прошлого года, но, насколько мне известно, все работает и сейчас.
Итак, у меня есть недорогой смартфон с NFC. Я в свое время покупала транспортные карты «Ситикард» (так получилось, что у меня их несколько – порой забывала карту то дома, то на работе и приходилось покупать новую).
Я скачала официальное приложение производителя карт Mifare NXP Taginfo и просканировала свою транспортную карту:
Оказалось, что карта основана на чипе Mifare Plus S, но что самое важное, работает она в режиме безопасности № 1. А это значит, что по сути это простая карта Mifare Classic, которая легко взламывается.
Я скачала в Google Play замечательное приложение Mifare Classic Tool и просканировала транспортную карту стандартными ключами:
Тут меня постигло разочарование – ни один из известных ключей не подошел. Соответственно, использовать взлом способом, как было описано в статье про «Подорожник», было не возможно.
«Постойте-ка» — подумала я, «но ведь можно попробовать способ, как описано в статье про взлом «Тройки».
Действительно, у «Ситикард» тоже есть приложение из Google Play, которое позволяет проверять баланс карты, а впоследствии прикрутили возможность и пополнять карту.
Я скачала и установила это приложение. Но теперь передо мной встала дилемма: ключи к карте зашиты или в самом приложении, или «прилетают» с сервера. Декомпиллировать Android-приложения достаточно просто, но я в этом не очень хорошо разбираюсь.
Наверняка, более или менее соображающий разработчик может это достаточно легко сделать. Я такими умениями не обладала и обратилась к брату, который занимается ремонтом домофонов, думала, у него есть знакомый программист, но он предложил более элегантное и простое решение.
Он к тому времени получил плату с Кикстартера, которая позволяет подсматривать протокол между ридером и картой. Оказывается, в домофонах стали использовать брелки, внутри которых зашит все тот же чип Mifare, и эта плата ему понадобилась для каких-то дел, связанных с этими брелками (я в подробности не вдавалась).
Итак, он взял свою плату, поместил ее к моему смартфону, который выступил в роли ридера, а в роли карты выступила собственно транспортная карта, и снял лог обмена данными между ридером и картой.
Дальше встал вопрос, что делать с полученным логом. Но непродолжительный поиск в Интернете привел к утилите под название crapto1gui. Ссылки приводить не будут, достаточно легко находится и так.
Скриншот утилиты привожу ниже (взято с одного из сайтов в интернете, так что данные там не реальные, которые мы использовали).
В общем, достаточно в эту утилиту вставить нужные куски лога и 6-байтный ключ мгновенно вычисляется. Я сама удивилась, как легко это делается, самое сложное было скопировать нужные части из лога и вставить в соответствующие поля программы.
Затем я открыла все тоже приложение Mifare Classic Tool (MCT), вставила в приложение полученный ключ и на этот раз мне отобразилось содержимое 0-го и 8-го секторов.
В нулевом секторе в основном были одни нули, а вот в восьмом были какие-то данные, из чего я сделала вывод, что данные по транспортной карте хранятся в 8-м секторе (как и в карте «Тройке» — неужели один и тот же разработчик?), а полученный ключ оказался ключом B (у сектора два ключа A и B).
Дальше, ради интереса, я с помощью опенсорсной утилиты libnfc и ридера бесконтактных карт получила и все остальные ключи от карты (подробнее об этом было написано в статье про «Подорожник» — я тоже использовала этот способ. Он также описан на сайте libnfc).
[ad name=»Responbl»]
С помощью полученных ключей я попробовала прочитать содержимой другой транспортной карты. Оказалось, что ключ A совпадал, а ключ B – нет. Но с помощью упомянутой утилиты его тоже оказалось легко получить.
Дальше я принялась исследовать содержимое транспортной карты. 8-й сектор состоит из 4-х блоков по 16 байт. С помощью MCT стало понятно, что первый блок является т. н. Value-блоком. Первым делом пришла мысль, что в этом блоке и хранится баланс карты. С помощью MCT удалось его декодировать – он содержал число 2147483647. На баланс карты, будь он даже в копейках, это явно было не похоже.
Потом я совершила поездку по этой карте и обнаружила, прочитав содержимое сектора, что значение не поменялось, а вот содержимое других блоков изменилось. Из чего был сделан вывод, что баланс карты хранится в них.
Разбирать содержимое карты особого желания не было, ведь я хотела попробовать так называемую replay attack (это я уже потом узнала, как она правильно называется).
Утром перед поездкой в метро я сохранила содержимое восьмого сектора, приложила карту к турникету и отправилась на работу. Днем же, отправившись по делам, я с помощью MCT записала предыдущее состояние карты и попробовала проехать в метро… И у меня получилось!
(картинка не моя — мне совсем не хотелось привлекать внимание)
Так я поняла, что таким образом можно делать «вечный проездной». Я решила немного побаловаться и записала содержимое сектора транспортной карты в домофонный брелок.
(вот такой же брелок я использовала для записи в него транспортной карты)
Я попробовала пройти через турникет, приложив брелок, но тут меня постигло разочарование – брелок, к моему удивлению, не сработал. Я подумала, что мою транспортную карту заблокировала (ведь брелок был ее клоном), но при прикладывании «оригинала» (транспортной карты) пройти через турникет удалось.
Я поговорила с братом, хотела узнать, что он думает по этому поводу, и он мне рассказал, что у каждой карты и брелка есть свой идентификационный номер. По всей видимости, мой «клон» был не полным, а содержимое в карте неким образом завязано на ее номер.
Но оказалось, что был выход и из этой ситуации: есть некоторые виды брелков, которые по виду точно такие же, но у них можно менять их номер (у обычных транспортных карт это сделать не получится). Более того, в MCT есть такая функция по перезаписи номера, поскольку он храниться в первом блоке нулевого сектора.
Правда, почему-то поменять номер с помощью MCT не получилось. Но получилось это сделать с помощью ридера и все того же libnfc.
На сей раз у меня получился полный клон транспортной карты в виде брелка, ведь даже номер совпадал. Я попробовала пройти через турникет по домофонному брелку, и это у меня легко получилось. В автобусе прикладывать брелок не рискнула, поскольку тетенька кондуктор могла бы очень удивиться, а вот «вечная» транспортная карта сработала тоже без проблем.
Итак, подводя итоги, можно сказать следующее: транспортные карты для оплаты проезда в Нижнем Новгороде так же легко взламываются, как и «Тройка» (Москва) и «Подорожник» (Санкт-Петербург).
Даже я, девушка, не имея специальных знаний, но умеющая скачивать Android приложения и пользоваться поиском в Гугле и Яндексе, смогла это сделать с использованием подручных средств и доступных в открытом доступе программ и утилит (будь я разработчиком, наверное, это было бы даже легче, хотя куда уж легче…) Да, мне понадобилось некоторое время на поиск в интернете и на изучение форумов, но все оказалось очень просто.
Хочу сразу отметить, предвидя вопросы, что никакого ущерба метрополитену нанесено не было – я учитывала все поездки, совершенные по «вечному проездному», поэтому соответствующий сумме таких поездок остаток на карте не стала расходовать, а саму карту потом уничтожила.
Но ведь злоумышленники не такие сознательные, наверняка они пользуются подобной уязвимостью и наносят ущерб городскому транспорту. Мы же получаем регулярно растущие тарифы на проезд (может быть, в том числе из-за потерь по подделке транспортных карт). Кстати, залог за транспортную карту составляет 50 руб. А ведь точно такие же по безопасности карты Mifare Classic стоят 12,5 руб и ниже.
Складывается ощущение, что все транспортные системы, где используются транспортные карты, небезопасны. Не хочу рассуждать, почему так происходит (эта тема не для Хабра), остается лишь задать вопрос: кто (какой город) следующий и когда ждать про это статью на Хабре?
PS Данная история, конечно же, выдуманная. Все персонажи — вымышленные, все совпадения — случайны. Ну, вы поняли…
Взлом метро: копирование и подделка билетов метрополитена
Содержание статьи
Как все начиналось
Интерес к системам подземки появился у меня давно, можно сказать, со школьной скамьи, когда в ходу еще были билеты с магнитной полосой. Тогда же (с десяток лет назад) ввели в оборот бесконтактную социальную карту для учащихся. Я стал интересоваться, что же это такое и как работает. Но в те времена и у меня не было достаточно навыков, да и информации, особенно по этим технологиям, в открытом доступе было немного. Пришлось отложить идею исследований в долгий ящик, но я пообещал себе, что обязательно к ней вернусь… Года три назад у меня снова проснулся интерес к теме метро. Я активно изучал магнитные билеты (информации по этой теме в интернетах было предостаточно) и даже собрал маленький станочек для изготовления дубликатов из двух головок от катушечных магнитофонов и небольшого количества рассыпухи. Не забыл и про свою социальную карту (уже студенческую). Но после изучения документации мне стало понятно, что система практически неприступна — чип MF1S50 Mifare Classic 1K, на базе которых изготавливаются социальные карты, защищен двумя 48‑битными ключами. На аппаратном уровне взломать его так просто не получится, а перебирать ключи можно до скончания солнечной системы. Да и картоводы, поддерживающие Classic, стоили по тем временам каких-то неподъемных денег (про Ebay я как-то не подумал, увы). Интерес к магнитным билетам быстро остыл, а социальную карту пришлось снова отложить до лучших времен.
Встречайте: «Ультралайт»
Билеты «Ультралайт» появились в нашем метро недавно, но сразу же вызвали у общественности бурный интерес. Их начали курочить, рвать, расклеивать утюгом и применять прочие методы терморектального криптоанализа. Надо признаться, жажда знаний заставила и меня раскурочить парочку. В результате их изучения и поисков в интернетах было установлено — это не что иное, как Mifare Ultralight, «облегченная» совместимая версия Mifare Classic. Беглый просмотр документации по чипам этого стандарта дал понять — встроенных систем защиты у этих карт нет. Ко всему прочему я напал на статью, детально описывающую успешный взлом похожей транспортной системы голландскими студентами. Все вместе подтолкнуло меня к новым исследованиям.
Поехали!
Для начала, разумеется, просто необходимо было где-то раздобыть беспроводной картовод, поддерживающий «Ультралайт». Было два варианта: или собрать самому (что заняло бы много времени), или купить уже готовое устройство. При мысли о втором варианте, памятуя о ценах трехгодичной давности, у меня пошли мурашки по коже. Но я все же решился посмотреть актуальные цены. И не зря! Я был приятно удивлен, узнав, что можно купить полностью функциональный девайс (OmniKey CardMan 5321), который поддерживает кучу проводных и беспроводных карт по привлекательной цене — 4000 рубликов. Конечно, не мало, но с другой стороны, это и не 10000; тем более, покупка готового ридера давала возможность сразу сосредоточиться на исследованиях билетов, а не на конструировании и отладке железа, которая могла затянуться на неопределенный срок. Вместе с ридером у той же фирмы (ISBC) был приобретен очень удобный оригинальный SDK местного производства. Он, опять же, позволил не растрачивать силы и время на написание низкоуровневки и отладку работы ПО с ридером, а сосредоточиться непосредственно на билетах.
Итак, за пару дней неспешного кодинга родилась маленькая программка, с помощью которой можно было в удобной форме наблюдать и править всю внутреннюю структуру «Ультралайтов». Тогда я начал изучать билеты.
Глухая стена
В процессе изучения через мой ридер прошло очень много билетов. Какие-то я, закатав рукава, доставал «из помойки», какие-то покупал — смотрел, что на них записано, затем проходил и смотрел еще раз. Это были билеты почти всех типов, за исключением, пожалуй, проездного «Ультралайта» на 70 поездок. Через пару недель у меня накопилась большая и отсортированная база дампов разных билетов и в разных состояниях. Были и дампы, снятые с одного и того же билета после каждой поездки, и несколько билетов с метрополитеновскими номерами, идущими подряд. В мою коллекцию попало даже несколько дампов двух разных временных единых социальных билетов (один был выдан сроком на 5 дней, другой на 30), снятых через некоторый временной интервал. Это оказались очень интересные экземпляры, и при этом очень редкие (мне они доставались из первых рук с немедленным возвратом, только на «прочитать»). По сути, это почти единственный тип «Ультралайтов», который работает не только в метро, но и на наземном транспорте. К тому же, только у этого типа билетов вообще нет ограничения на количество поездок. Впоследствии, именно они сослужили мне большую службу.
Весь этот зоопарк я собирал с одной целью — четко определить структуру и формат записи данных на билете. Конечно, какие-то поля были видны сразу, невооруженным глазом, но некоторые нет. Например, я не сразу понял, где записан номер билета метро (тот самый, который на нем напечатан). Осознание пришло совершенно случайно. Дело в том, что я (как и, думаю, большинство из нас), смотря в хекс, привык выравнивать для себя информацию по байтам и мыслить, минимум, байтами. Выяснилось, что здесь этот подход неверен. Глядя на дамп билета, нужно мыслить более мелкими единицами — тетрадами, а иногда и битами. Понял я это тогда, когда «узрел» наконец номер билета, — он оказался сдвинут на 4 бита относительно начала байта, а оставшиеся 4 бита с той и с другой стороны номера занимала прочая служебная информация.
Через некоторое время формат записи данных на билеты стал почти полностью понятен. Стало очевидно, где и как хранятся все даты, счетчики, идентификаторы. Оставалась лишь пара полей, назначение которых было неясно просто потому, что от дампа к дампу данные в них были одинаковы.
Но на этом вся радость и закончилась — глупо было бы предполагать, что такие билеты могут оставить незащищенными. В каждом дампе было 32 бита различной информации, никак не коррелировавшей с остальным содержимым. Я предположил, что это своего рода контрольная сумма, «хэш» данных, написанных на билете. Все попытки прикинуть или рассчитать эти 32 бита обернулись полным провалом (в частности, было предположение, что это какой-то вид CRC32, с нестандартным полиномом и стартовым значением). При попытке изменить хотя бы полтора бита информации внутри билета терминал проверки в метро высвечивал «ПЛОХОЙ БИЛЕТ», увесистым домкратом заколачивая последние гвозди в крышку гроба. Конечно, были попытки обойти систему и другими способами, например, попытаться скопировать билет на чистую карту один-в-один (тут, увы, помешал заводской серийник, который, как выяснилось, тоже участвовал в генерации «хэша») или выставить биты блокировок так, чтобы запретить турникету изменять содержимое билета. Проверочный терминал такой «вечный» билетик признавал, но турникет пускать отказывался. Таким образом, я уперся в стену. В ту большую, крепкую бетонную стену, об которую многие имеют привычку убиваться с разбега. Не найдя никакой информации на форумах и досках, я решил, что на этом мои исследования закончены — путей больше нет, и поставил жирную точку. Как выяснилось, зря.
Странное знакомство
Сентябрьский вечер ничем не отличался от других. Уже почти наступила ночь, на улице было прохладно и сыро. Я сидел перед экраном монитора, и, попивая теплый, чуть сладкий зеленый чай, мирно разводил плату для очередной своей поделки. DipTarce, немного башорга, аська. Кто-то позвонил по скайпу — отвлекают! Опять аська, опять DipTrace — в общем, все как обычно. В очередной раз на передний план вывалилось окно аськи — кто-то, доселе мне неизвестный, написал «Привет». Я, ничтоже сумняшеся, ответил тем же. Следующее сообщение явилось переломным во всей истории: «Ты вроде метро интересуешься, у меня тут кое-какое барахлишко есть. Если интересно, давай встретимся, я тебе передам».
Сначала меня это немного смутило и насторожило (может быть, развод или подстава, а может, и «спецслужбы» заинтересовались — паранойя берет свое), но потом я подумал: почему бы и нет? Спецслужбы мной интересоваться вряд ли бы стали, а почвы для развода, и уж тем более, для подставы тут вроде бы и нет. После недолгой беседы мы договорились о встрече днем, в центре зала одной из станций московского метро. Незнакомец оказался высоким молодым человеком, в очках, с большим черным полиэтиленовым пакетом в руках. Мы поздоровались, затем он передал мне пакет со словами: «На, держи. Мне это все равно не пригодилось, может тебе будет полезно». Заглянув внутрь, я увидел два метрошных терминала, переложенных газетами, несколько хаотично разбросанных белых пластиковых карточек и болванку в коробочке. На мой вопрос о том, сколько я за это должен (денег), парень помотал головой, улыбнулся и сказал: «Да ты что, никто ничего никому не должен, занимайся. Так, мне уже бежать надо, вон и поезд мой как раз! Давай, пока!». С этими словами он убежал, запрыгнул в уже закрывающиеся двери вагона и уехал. А я, признаюсь, немного в непонятках поехал домой.
Контакт из аськи я на всякий случай удалил, заодно почистив контакт-лист на сервере и прибрав логи (еще раз привет, паранойя). В конце концов, напишет еще раз, если что. Но больше он мне так и не написал.
Явление софта народу
Придя домой, я разобрал пакет. Второй из терминалов оказался автобусным валидатором (тяжеленный, блин!); карточки были Mifare Classic 1K (чистые), а на диске красовался один единственный архив. После беглого ознакомления с содержимым выяснилось — это софт, который используется на кассах метро. Отложив в сторону терминал и валидатор, я решил вплотную заняться изучением интересного софта. Примерно за час из бардака, который распаковался, мне удалось выстроить и запустить у себя на компьютере эту программу. Еще час потребовался, чтобы разобраться в ее структуре. Прочесав все ini-файлы (с комментариями, любезно оставленными разработчиком), я уже имел полное представление что это, как это работает и с чем это едят. Едят, как выяснилось, с ридером Parsec PR-P08, поэтому, за отсутствием оного, попробовать софт в действии не удалось.
Разработчиком значилась фирма «Смартек» — крупный государственный подрядчик, разрабатывающий системы такого рода (подробнее можно почитать на их сайте). Программа была написана на Delphi с использованием рантайм-bpl’ок. Причем, софт имел модульную структуру, и все подпрограммы, классы и компоненты располагались в отдельных DLL или bpl’ках с говорящими названиями (вот это был и самый главный фэйл раз- работчиков). После беглого анализа внутренностей софта я выяснил, что, во-первых, информация обо всех выданных билетах передается в централизованную базу данных (к слову, это Oracle) и, во-вторых, в программе используется некий механизм ключей. Программа могла общаться с БД не только в режиме реального времени. Делаем выводы: все операции в системе могут происходить с определенной задержкой. Теоретически, это дает нам фору. Но прежде всего меня заинтересовал механизм ключей (я примерно уже начал догадываться, зачем он может быть нужен).
Итак, я взялся за дизассемблер и приступил к работе. Механизм состоял из двух файлов — CryptKeyRef.dll и keys.d (единственный «хитрый» файл во всей программе, который, кроме как на файл с ключами, больше ни на что не похож). А пользовалась всем этим добром рантайм-bpl’ина SmLayout.bpl. Эта библиотека оказалась просто находкой для моих исследований — в ней содержались классы для работы с внутренним наполнением билетов. Так как это рантайм-bpl, то достаточно было просто взглянуть на ее таблицу экспорта, чтобы уже процентов на 60 понять, что к чему. Более детальный анализ расставил все на свои места. Помнишь, в начале статьи я говорил о том, что в структуре «Ультралайта» остались еще несколько полей, назначение которых было непонятным? Одно из этих полей — так называемый «идентификатор раскладки». По сути, все билеты метро строятся из фиксированной заголовочной части и переменной части данных. Так вот, это поле «Layout» в заголовке как раз и определяло, каким образом и какие данные расположены в оставшейся части билета. Таких раскладок существует несколько (каждая под свой тип билета), и в SmLayout.bpl каждой из них соответствовал свой класс (плюс общий класс-родитель, в котором были методы для работы с заголовочной частью). Поэтому разобраться, какие поля в каждой раскладке за что отвечают, было просто (еще бы, с говорящими-то именами методов в экспорте!).
Добив полностью весь Layout 8 (который используется в «Ультралайтах») и перепроверив, обо всех ли полях в структуре билета у меня было верное представление, я взялся за механизм ключей. Действительно, он отвечал за генерацию «хэша». Как работает механизм, стало полностью ясно после изучения работы метода, отвечавшего за вычисление «хэша».
Сначала, из файла с ключами (keys.d) выбирается верный ключ. Система устроена так, что у каждого типа билетов есть свой идентификатор (в комплекте присутствовала полная таблица с идентификаторами и названиями билетов, в виде текстового файла со значениями, разделенными запятой). Состоит он из идентификатора зоны (приложения) и идентификатора типа карты. Так вот, исходя из этих чисел, в файле ключей выбирается кейринг, внутри которого может быть уже несколько ключей (на случай, когда новый ключ ввели, а старые билеты еще используются). Запись нового билета происходит с использованием самого первого, а проверка на валидность — с использованием всех ключей в кейринге. Далее выбранный ключ расшифровывается с помощью CryptKeyRef.dll (зачем их хранят зашифрованными, ума не приложу). После чего расшифрованный ключ и почти все данные билета, а также его аппаратный серийный номер и число (метод генерации «хэша», который указывается для кейринга в keys.d) — передаются в функцию ckCalcHashCode, находящуюся в той же CryptKeyRef.dll. На выходе мы получаем значение, на котором я в свое время и «застрял» — тот самый «хэш». Разумеется, я написал маленькую программку, которая, используя эти функции из CryptKeyRef.dll и файл keys.d, могла проверять и, в случае чего, пересчитывать «хэш» внутри любого дампа. Я перепроверил все на нескольких дампах, и, получив положительный результат, ушел, довольный, спать.
Протухшие ключи
Несмотря на теоретический успех, хотелось проверить все, так сказать, «в бою». На следующий день, возвращаясь с работы, я специально прикупил свежий «Ультралайт» на одну поездку, чтобы посмотреть, действуют ли мои ключи или уже нет (судя по всему, они были старенькие). Можно, конечно, сразу было попробовать записать «сфабрикованный» «Ультралайт» и пойти проверить, но на тот момент у меня закончились пустые карты, да и немного страшновато идти «наобум» — вдруг что? По приходу домой я первым делом, даже не помыв руки, с нетерпением бросился проверять свежий билет своими ключами. И тут меня поджидал большой облом — «хэш», записанный в билете не проходил ни по одному из ключей. Стало быть, ключи действительно уже протухли и на смену им пришли новые. Это полностью перечеркивало все мои труды. Мне немного взгрустнулось. Я заварил зеленого чая, поиграл немного на фортепиано (да-да) и сел дальше разводить свою неоконченную плату.
Еще не все потеряно
Идея пришла ко мне неожиданно, когда я в очередной раз зачем-то смотрел внутрь файла с ключами. Я заметил, что в «ходовом» кейринге (который используется для расчета 1-, 2-, 5‑поездочных и прочих «Ультралайтов») было два ключа — новый (на тот момент, разумеется) и, по всей видимости, — старый. Но был также кейринг, в котором лежал всего один ключ. Раньше я не обращал на него внимания, а концентрировался на «ходовом». Для расчета каких билетов используется этот ключ, я не знал. Когда я посмотрел, что за тип билета привязан к кейрингу, то у меня вспыхнула маленькая искорка надежды. Дело в том, что этот тип билета был — ВЕСБ. Да, именно тот редкий тип билета, — временный проездной на все виды транспорта. Я прикинул, что если билет единый, то этот ключ должен использоваться не только в метро, но и на наземном транспорте, где его очень сложно и долго заменять на новый. К тому же, ключ в кейринге всего один, что косвенно подтверждало мою догадку. Ко всему прочему, я вспомнил, что, когда вычищал метрошную программу от разного «мусора», там было нечто, похожее на архив старых файлов ключей. Откопав и открыв оригинальный архив, я увидел, что это действительно так. И самое главное, просмотрев все старые файлы ключей, я обнаружил, что именно этот ключ оставался неизменным!
Уже без единой капли сомнения я склепал свой собственный ВЕСБ (благо, у меня были дампы такого типа, что в разы упростило задачу — я просто поменял в дампах даты и номер), а «хэш» рассчитал с использованием этого ключа. Итак, настало время проверки (тем более, я как раз купил еще немного чистого пластика).
Зайдя в вестибюль, я сначала приложил свой «билет» к проверочному терминалу. На табло высветился срок действия билета, который я указал, и загорелся зеленый светодиод. Стало быть, работает. Сделав гримасу попроще и спрятав белоснежный пластик в рукав, я подошел к турникету, приложил руку к валидатору и. спокойно прошел на весело загоревшийся зеленый. Это ознаменовало окончательную победу.
А что же дальше?
А дальше начались эксперименты, в ходе которых было выяснено множество интересных вещей. Например, по такому «левому» ВЕСБу можно ходить всего два-три дня. Дело в том, что номер, который внутри билета я указываю «от балды», при каждом проходе сохраняется в памяти головы турникета, а через какое-то время отсылается вместе с остальными в центр обработки данных. Там система не находит реально выданного билета с таким номером и вносит его в стоп-лист, который затем рассылается по всем турникетам метро. И так должно происходить со всеми типами билетов, не только с ВЕСБ — в дополнение к «хэшу» и часто меняющимся ключам это очень хорошая защита. Обойти ее, по понятным причинам, не представляется возможным. Также было замечено, что установка или не установка битов блокировки не играет никакой роли на то, сработает билет или нет. Исключение составляет только бит блокировки зоны OTP, который турникет, видимо, проверяет всегда, даже несмотря на то, что писать в OTP не собирается.
В дальнейшем я взялся за метрошный и автобусный терминалы, привел их в порядок, изучил и запустил на стенде. Теперь, чтобы проверить очередную догадку, уже не надо было бежать со свежеиспеченным билетиком-мутантом в метро, а стало возможным проверять их «не отходя от кассы». Тем более, терминал метро оказался такой же старый (ко всему прочему и глючный), как и мои ключи. Так что я мог попробовать «в работе» и любые другие типы билетов «Ультралайт» — то, чего я никогда не смогу сделать «вживую» в метро.
Параллельно с этими экспериментами я продолжал заниматься софтом. Так как велось много споров о том, что же за алгоритм используется при вычислении «хэша», я решил полностью восстановить его, переписав алгоритм с нуля на «людском» языке программирования, а в процессе как раз надеялся понять, какой же это алгоритм — что-то широко известное или же какая-то своя, внутренняя разработка. Попутно меня посещало много разных мыслей (в том числе, что это может быть и AES), но при детальном изучении уже работающего кода без использования Смартековских библиотек выяснилось, что алгоритм этот — «всего-на-всего» ГОСТ — отечественный стандарт шифрования (всю необходимую информацию о нем ты сможешь без труда найти в Сети). Конкретно, для вычисления «хэша» использовался цикл 16‑З. «Хэш», по сути, это не что иное, как имитовставка ГОСТ.
The End, или Подведем итоги
Системы метро, а в частности, новые билеты «Ультралайт», вопреки мнениям и догадкам, оказались хорошо защищены. Очень радует, что разработчики использовали надежный и проверенный временем ГОСТ, а не стали изобретать велосипед. С такой защитой подделать билет «Ультралайт», не имея доступа к конфиденциальным данным (ключевой информации), просто невозможно. Замечательно продумана и система сменных ключей, и механизм стоп-листов.
Конечно, не обошлось без недостатков и ошибок. Самая большая из них — программное обеспечение, которое никак не защищено. Достаточно было отказаться от использования рантайм-bpl, и это затруднило бы анализ в десятки раз! Как вариант, — обработка особо важных частей программы AsProtect’ом или ExeCryptor’ом, с последующей запаковкой всех файлов MoleBox’ом свели бы возможность анализа почти к нулю. Инструментарий-то недорогой. А использование хорошей (желательно, малоизвестной или сделанной на заказ) защиты подобного рода, но с аппаратными ключами сделало бы разбор программы полностью невозможным. Разумеется, Метрополитен — это режимное предприятие, но не стоит при этом забывать про человеческий фактор. Ведь еще Кевин Митник говорил (и не только говорил, но и демонстрировал на собственном примере, за что и сел, гы), что иногда для достижения цели проще и эффективнее использовать «социальную инженерию», нежели пытаться сломать непробиваемую защиту.
Что ж, на этой ноте я и закончу свое повествование. А тебе, читатель, желаю больше интересных и удачных исследований!