Простой Mifare-сниффер

[RECTO]

Практическое руководство по копированию Mifare. Часть 1.

(Предыдущая часть: Проверка и настройка)


В этой части я представлю небольшое руководство к действию - как же всё-таки, используя данное устройство, изготовить копию своего домофонного ключа Mifare. Вся эта информация в том или ином виде открыто лежит в сети и её там можно найти (так что моя совесть будет чиста, никаких секретов я не выдал), здесь же она просто собрана вся сразу в одном месте. В своём изложении я буду предполагать, что Вы уже что-то знаете о стандарте ISO14443 Type-A, протоколе обмена данными (в частности, 3-х проходной аутентификации), а также об уязвимостях crypto1, хотя бы в общих чертах. Иначе - стоит предварительно изучить эту информацию, чтобы снятые логи не казались Вам "китайской грамотой". Информация разрознена, но тем не менее, она есть и её можно найти. Например, для начала эта статья вполне сойдёт... Итак, поехали!

...Пример простейшего лога обмена ридера и карты Mifare был представлен ранее, где-то в предыдущих постах. Так что, если Вы увидите на полученной сессии нечто подобное, то это означает, что данная СКУД использует в качестве идентификатора только UID карты. Конечно же, сделать дубликат такой метки не составит большой проблемы: нужно просто скопировать UID оригинала на любую заготовку, которая поддерживает смену UID - например, на обычную Mifare Zero. Для этого можно воспользоваться утилитой mfsetuid от DarkSimpson. Нужно запустить её из командной строки с параметрами: mfsetuid.exe 12345678, где вместо "12345678" Вы подставите те самые 4 байта UID, которые требуется записать на нашу заготовку. Остальное содержимое 0-го блока программа рассчитает сама. И вот он, дубликат готов!..

Однако на практике встреча с подобными случаями вызывает, скорее, удивление - настолько они редки. Подавляющее большинство СКУД работают в "защищённом" режиме - когда в качестве идентификатора используется информация из одного или нескольких блоков карты, доступ к которым защищён при помощи ключа. Соответственно, чтобы сделать копию такой карты, необходимо узнать ключ доступа к сектору, в котором находятся блоки, содержащие идентификатор. Дело ещё осложняется тем, что ключи доступа к неиспользуемым секторам также изменены. Это делается специально для того, чтобы нельзя было применить Nested Attack или Hardnested Attack для этой карты и вычислить все ключи доступа, если известен хотя бы один ключ (классический пример реализации такой атаки - утилита mfoc от того же DarkSimpson). На первый взгляд, ситуация безвыходная, однако необходимые ключи доступа можно получить и другим путём - расшифровав лог обмена данными, который мы перехватим при помощи сниффера. А уже зная даже один ключ, можно при необходимости вычислить и остальные...

Рассмотрим для начала самый простой случай. Допустим, мы перехватили обмен данными между панелью домофона и картой и на полученной сессии увидели следующую картину:

--- Сессия 91 ---
pcd : 26
tag : 04 00
pcd : 93 20
tag : D1 FE A6 19 90
pcd : 93 70 D1 FE A6 19 90 88 FB
tag : 08 B6 DD
pcd : 26
pcd : 26
tag : 04 00
pcd : 93 70 D1 FE A6 19 90 88 FB
tag : 08 B6 DD
pcd : 60 01 7C 6A
tag : 13 FB 6D 55
pcd : 87 E0 3B 8F 1C F5 F4 9B  ‹Parity›
tag : 6B 1E 30 80  ‹Parity›
pcd : 3B AC DB 23  ‹Parity›
tag : F8 2C F7 21 4C A4 4A 88 46 67 2E 77 DE BB 93 5E FB BB  ‹Parity›
pcd : 26
tag : 04 00
pcd : 93 20
tag : D1 FE A6 19 90
pcd : 93 70 D1 FE A6 19 90 88 FB
tag : 08 B6 DD
pcd : 26
tag : 04 00
pcd : 93 20
tag : D1 FE A6 19 90
pcd : 93 70 D1 FE A6 19 90 88 FB
tag : 08 B6 DD
pcd : 26
tag : 04 00
pcd : 93 20
tag : D1 FE A6 19 90
pcd : 93 70 D1 FE A6 19 90 88 FB
tag : 08 B6 DD
...........................
и т.д.
..

Как мы видим, некоторая часть обмена здесь зашифрована. Но даже без расшифровки, одним только беглым просмотром, можно извлечь из этого лога немало полезной информации, которая пригодится нам в дальнейшем:
1) мы имеем дело с обычным Mifare Classic 1K с 4-х байтным UID - что само по себе уже хорошо!;
2) в данной панели не используется никаких антиклон-фильтров - а значит, что скорее всего, дубликат можно будет сделать на обычный Mifare Zero или даже на такой же Mifare Classic 1K (да-да! Но об этом поговорим в следующей части...);
3) в процессе обмена производится единственная аутентификация к 1-му блоку в 0-м секторе с ключом "А", после чего происходит чтение данных из одного-единственного защищённого блока (скорее всего, тоже 1-го). Это означает, во-первых, что наш идентификатор находится в одном из блоков 0-го сектора. И во-вторых, как следствие - нам даже не нужно будет вычислять ключи доступа ко всем остальным секторам и делать полный клон карты. Достаточно будет найти только один ключ - тот, с которым производилась авторизация, а уже с его помощью прочитать содержимое 0-го сектора и скопировать это содержимое на заготовку. Красота!..

Для вычисления ключа доступа и расшифровки данных воспользуемся возможностями самой программы "RECTO Mifare Sniffer". Открываем меню "Данные" и запускаем пункт "Расшифровать лог". Программа должна выдать такой результат:

--- Расшифровка лога ---
Выбрана карта Mifare Classic 1K, UID = D1 FE A6 19
Авторизация к сектору 0 с ключом A = E6 AE B7 49 FC 2D
Прочитан блок 1 = D1 FE A6 19 00 00 00 00 00 00 00 00 00 00 00 00
--- Расшифровка завершена ---
..

Вот мы, наконец, и подошли к тому, чтобы сделать дубликат нашей карты, но теперь уже - защищённой! Как было ранее сказано, именно для нашего случая существует 2 способа изготовления рабочей копии, причём принципиально разных. Рассмотрим сперва самый простой из них - запись на заготовку с изменяемым UID.

Поскольку в нашей панели не установлено никаких фильтров, то можно сделать копию на самую простую заготовку Mifare Zero. Здесь, наверное, даже и пояснять ничего не требуется - содержимое 0-го сектора оригинала нужно просто скопировать на заготовку 1 в 1 при помощи специальной программы, умеющей записывать UID на этих заготовках. Для этого сперва нужно подготовить дамп, т.е. по сути - цифровую копию карты-оригинала. Программа "RECTO Mifare Sniffer" может сформировать такой дамп автоматически. Для этого идём в меню "Данные" и выбираем "Записать дамп". Будет записан файл с дампом, полностью готовый для записи на заготовку. Если мы откроем его в каком-нибудь HEX-редакторе, то должны увидеть следующее:

00000000 | D1 FE A6 19 90 08 04 00 00 00 00 00 00 00 00 00
00000010 | D1 FE A6 19 00 00 00 00 00 00 00 00 00 00 00 00
00000020 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 | E6 AE B7 49 FC 2D FF 07 80 69 FF FF FF FF FF FF
...........................
и т.д.

Здесь показан только 0-й сектор. Содержимое остальных секторов копии остаётся без изменения (в "транспортном" состоянии) - поскольку ридер к ним всё равно не обращается, они не нужны... Для записи заготовки воспользуемся утилитой mfclassic всё того же DarkSimpson, запустив её из командной строки с ключами: mfclassic.exe W a dump.mfd. Здесь "dump.mfd" - дамп карты, который будет залит 1 в 1 на нашу заготовку, вместе с UID. Вот и всё, теперь нам остаётся только спуститься вниз, к домофону и проверить, как работает наша копия!..

Вместо Mifare Zero для изготовления дубликата можно также использовать заготовки OTP, OTP 2.0 или MF-3 - если брать рассмотренный случай (в домофоне не используется антиклон-фильтров), то никакой разницы нет. Для записи OTP 2.0 Вы можете использовать те же программы, что и для записи Mifare Zero: например, mfclassic или mfsetuid. Всё то же самое, но записать 0-й блок с UID (в режиме "unlocked") можно будет только один раз. Для записи MF-3 можно воспользоваться программами, которые умеют записывать 0-й блок в "защищённом" режиме, например - тем же mfclassic, но только запускать его нужно будет с ключом "w". Использование этой заготовки предпочтительнее, поскольку, во-первых, она по параметрам более приближена к оригинальному "классику" и проходит (пока что) большинство фильтров. И во-вторых, она допускает многократную перезапись UID (если, конечно, при записи случайно не запороть 0-й блок). С заготовкой OTP дела обстоят несколько сложнее - она, как и Mifare Zero, сейчас уже устарела, поскольку обнаруживается и отсекается современными антиклон-фильтрами. Так что стоит с ней связываться или нет - решать, конечно же, Вам...

Продолжение: Практическое руководство по копированию Mifare. Часть 2.
..

[RECTO]

Практическое руководство по копированию Mifare. Часть 2.

(Предыдущая часть: Практическое руководство по копированию Mifare. Часть 1)


В предыдущей части был рассмотрен способ изготовления копии ключа Mifare простым копированием содержимого 0-го сектора на заготовку Mifare Zero. Теперь рассмотрим второй, более интересный способ - изготовление копии на карту Mifare Classic 1K.

- Но как же так? - возможно, спросите Вы, - ведь у этих карт UID не перезаписывается!..

Всё верно. Этот способ (как уже можно было бы догадаться) основан на использовании "дыр" в применяемой защите. Одна "дыра" - это уязвимость самой системы Mifare, которую в своё время не учли разработчики из Iron Logic (а подавляющее большинство домофонов оборудуется именно их считывателем CP-Z2 MF). Вторую дыру сделали они сами... К настоящему времени дыру, конечно, закрыли, поэтому на панелях свежей установки уже не получится применить нечто подобное. Впрочем, как не получится и записать дубликат на Mifare Zero - их тоже научились успешно фильтровать, и не только их!.. В любом случае, вывод о возможности применить ту или иную заготовку можно сделать, предварительно изучив лог обмена со сниффера и дамп 0-го сектора. Так что, если Вы увидите в своём логе нечто похожее на предыдущий пример - значит, скорее всего, данная панель оборудована считывателем CP-Z2 MF старой версии и дубликат на Mifare Classic 1K сделать можно!..

Далее мы будем рассматривать ситуацию, когда наша домофонная панель оборудована именно этим считывателем - CP-Z2 MF от Iron Logic, в защите которого применяется динамически вычисляемый ключ аутентификации, зависимый от UID (т.е., для каждой карты используется свой, "индивидуальный" ключ). Для большинства других считывателей обычно всё намного проще - там, как правило, применяется один и тот же ключ аутентификации для карт на весь подъезд. Поэтому узнать его не составит большой проблемы - достаточно посмотреть его на исходной карте...

Давайте внимательно рассмотрим дамп 0-го сектора, прочитанный нами ранее с оригинала. Думаю, Вам бросилась в глаза интересная деталь - первые 4 байта 1-го блока повторяют 4 байта UID, а всё остальное его содержимое =00. Вспомним также, что при обмене данными производится единственная аутентификация к этому блоку, а затем - его чтение. Именно его - потому что во 2-м блоке записаны одни нули, читать там совершенно нечего...

Кажется, теперь становится понятно, что к чему. В частности - в чём заключается различие между СКУД, работающей в "открытым" режиме, когда в качестве идентификатора используется один только UID и в "защищённом" режиме, когда идентификатор читается из защищённых блоков карты... Да по сути, отличия там чисто "косметические" - в основе СКУД остался всё тот же ТМ-контроллер (например, это может быть классический Z-5R) с подключённым к нему считывателем CP-Z2 MF по внешней шине 1Wire. Когда мы подносим карту, считыватель пересылает ТМ-контроллеру 4-х байтный идентификатор в формате обычной iButton, по которому система нас и "узнаёт". Только в первом случае считыватель берёт эти 4 байта напрямую из UID, а во втором - читает их из 1-го блока, защищённого ключом доступа. Вот, собственно, и вся разница... Сделано это, скорее всего, для обеспечения совместимости режимов считывания, когда ТМ-контроллеру в любом случае посылается один и тот же идентификатор. Иными словами, обнаруживается интересная вещь - для домофона, работающего в "защищённом" режиме, UID нашей карты вообще не важен, поскольку не он находится в базе ключей, а его копия, записанная в 1-м блоке!

В общем и целом, весь процесс выглядит примерно так:
1) Считыватель CP-Z2 MF читает UID карты.
2) На его основе, по "хитрой" формуле, генерируется key-A.
3) Используя полученный ключ, считыватель делает попытку аутентификации к блоку 1 сектора 0.
4) Если аутентификация проходит успешно, считывается 1-й блок.
5) Считыватель пересылает первые 4 байта, прочитанные из 1-го блока ТМ-контроллеру.
6) ТМ-контроллер сравнивает полученный идентификатор со своей базой ключей и принимает решение на открытие двери...

Теперь, наверное, уже понятен сам принцип, как можно сделать дубликат карты на обычный Mifare Classic 1K. Для этого нужно просто взять UID оригинала и записать его в 1-й блок копии. Но нужно также найти и записать в трейлер ключ "А", который будет применяться считывателем для аутентификации, поскольку собственный UID копии будет уже другой... И если с первым пунктом всё предельно ясно, то со вторым как раз наоборот - совершенно не понятно, каким образом можно узнать ключ, если не известна формула, по которой он рассчитывается?..

Оказывается, формулу знать и не обязательно - считыватель может сам любезно сообщить нам, какой ключ доступа будет применён для карты с конкретным UID (вот это поворот!). Для этого нужно всего лишь сделать попытку аутентификации с той картой, которую мы будем использовать в дальнейшем в качестве дубликата, записав при этом лог обмена и на основе полученных данных найти правильный ключ. Здесь используется примерно тот же принцип, что и при расчёте ключа на основе данных законченной аутентификации (из предыдущего примера). Отличие заключается лишь в том, что метка вместо "tag response" ответит "NACK" и аутентификация будет отклонена - поскольку ридер "знает" правильный ключ, а карта - нет. Но, оказывается, и эту проблему можно обойти - нужно просто снять серию однотипных аутентификаций для карты с одним и тем же UID (обычно бывает достаточно двух). К слову, этот же принцип заложен и в основу работы прибора SMkey, выпускаемого известной фирмой iKey. Только там весь процесс происходит автоматически, одной кнопкой...

В общем, приступим к делу - берём нашу карту Mifare Classic 1K, на которую будем делать дубликат, идём к домофону и снимаем при помощи сниффера несколько попыток аутентификации. Разумеется, никакой видимой реакции со стороны панели не будет, но красный светодиод на сниффере должен загораться каждый раз при захвате очередной сессии. Читаем полученные логи, там должно получиться примерно следующее:

--- Сессия 92 ---
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 26
pcd : 26
tag : 04 00
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 60 01 7C 6A
tag : 91 15 EB EA
pcd : 6C E4 90 B6 8A 10 AE 8A   ‹Parity›
tag : 0F
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
................................
и т.д.
..

--- Сессия 93 ---
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 26
pcd : 26
tag : 04 00
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 60 01 7C 6A
tag : D5 11 14 37
pcd : 91 D8 C1 43 54 0D E8 EF   ‹Parity›
tag : 07
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
pcd : 26
tag : 04 00
pcd : 93 20
tag : BA 35 2A 08 AD
pcd : 93 70 BA 35 2A 08 AD 7B 29
tag : 08 B6 DD
................................
и т.д.
..

Для вычисления ключа доступа, как и в прошлый раз, воспользуемся возможностями самой программы "RECTO Mifare Sniffer". Идём в меню "Данные" и запускаем пункт "Расшифровать лог". Программа должна выдать следующий результат:

--- Расшифровка лога ---
Выбрана карта Mifare Classic 1K, UID = BA 35 2A 08
1-я неполная авторизация к сектору 0 с ключом A, эти данные будут использованы.
2-я неполная авторизация к сектору 0 с ключом A = C5 1B 40 CA 61 E8
--- Расшифровка завершена ---
..

Т.е., ключ доступа "А", который будет валиден для метки с нашим UID, найден! Полученный ключ записываем в качестве "key A" в трейлер нашего дубликата. "key B" и биты доступа можно оставить, как есть (в "транспортном" положении). В блок 1 записываем 4 байта UID оригинала, остальные байты оставляем =00. Можно несколько упростить себе эту задачу, поручив программе самостоятельно сформировать дамп на основе расшифрованных данных - как и в предыдущем примере, открываем меню "Данные" и выбираем "Записать дамп". Единственное НО - перед записью дубликата всё равно нужно будет самостоятельно отредактировать содержимое 1-го блока, записав туда 4 байта UID оригинала. Записываем содержимое 0-го сектора на нашу карту - вот и всё, дубликат готов!

Но, правда, здесь есть пара нюансов. Во-первых, может случиться так, что открыв лог вы увидите сразу несколько неоконченных авторизаций, принадлежащих одной сессии. Дело в том, что многие современные считыватели имеют алгоритмы, "сбивающие с толку" программы расчёта ключей, чтобы препятствовать их захвату. Это реализуется, например, так: первая попытка авторизации делается с заведомо неправильным ключом, которая отклоняется меткой и только потом происходит авторизация с правильным ключом, которая завершается успешно. Но - это если метка "знает" правильный ключ. А в нашем случае, с "чистой" меткой, получается 2 совершенно одинаковые на вид неоконченные авторизации. Программа (или какое-то другое устройство захвата ключей) не может самостоятельно определить, которая из них правильная и не может вычислить ключ...

Подробнее об этом я напишу как-нибудь потом, в следующей части, посвящённой фильтрам. А здесь же поделюсь рецептом, что можно попробовать сделать в подобных случаях. А именно - можно сделать весь процесс, что называется, "ручками" - например, при помощи программы qrapto1. Т.е., Вам необходимо будет самостоятельно оперделить, какие именно данные вашего лога принадлежат авторизации с правильным ключом и ввести их в соответствующие поля на вкладке "partial". Если всё сделано правильно, программа рассчитает ключ. Ниже приведён скриншот окна программы с данными из нашего примера. Саму программу можно взять здесь.



Кстати, в этой программе я нашел один недочёт - найденный ключ выводится как обычное целое 16-ричное число, поэтому если слева окажутся "незначащие" (с т.з. программы) нули, то они будут отсечены. Желательно это исправить, для этого в файле "qrapto1.cxx" нужно найти строчку:
"strSecret_2-›setText(QString::number(key, 16));"
и заменить её на:
"strSecret_2-›setText(QString::number(key, 16).rightJustified(12, '0').toUpper());".
Во-от, теперь будут выводиться все разряды найденного ключа, и даже - в верхнем регистре, ведь так гораздо удобнее...

Второй нюанс - в качестве рабочего идентификатора (для записи в 1-й блок) правильнее будет брать не сам UID оригинала, а содержимое его собственного 1-го блока. Дело в том, что не исключена вероятность, что Ваш "оригинал" может оказаться вовсе не оригиналом, а такой же точно копией, сделанной на Mifare Classic. И если Вы запишите его UID в 1-й блок своей копии, копия может не заработать.

Ну а если, допустим, такое всё же случилось и в 1-й блок копии попали не те данные? Например, что будет, если записать в 1-й блок не UID оригинала, а собственный UID карты-дубликата? Попробуйте! Тут возможны 2 варианта развития событий:
1) Домофон, как ни в чём ни бывало, откроет дверь! Это значит, что в данной панели включена функция автосбора ключей. Т.е., ТМ-контроллер принимает от считывателя любой переданный идентификатор, заносит его в свою базу и с этих пор считает "своим". Вся защита в этом режиме происходит только на уровне считывателя... Что-ж, очень полезная опция - ведь тогда у нас будет уже не дубликат, а полноценная карта. И она уже гарантированно не "отвалится", если впоследствии функцию автосбора отключат и обновят прошивку считывателя.
2) Домофон пискнет "Error" и дверь не откроется. Значит, автосбор ключей отключён и панель переведена в полноценный защищённый режим. В этом случае дубликат будет работать только с UID оригинала, записанного в 1-й блок.

Продолжение: Практическое руководство по копированию Mifare. Заключение.
..

[mcu51]

Есть карты.

[RECTO]

Есть карты.

Карта или брелок - принципиальной разницы нет, внутри может быть один и тот же чип. Значение может иметь несоответствие размеров антенны метки и ридера. Например, считыватель "CP-Z-2 (мод MF-1)" нормально работает с картой, но сниффером их обмен перехватывается плохо, иногда ответы карты на сессии могут быть не видны вообще... Поэтому с этим считывателем в качестве "оригинала" следует брать метки в формате брелока.

P.S. В 2023 году была выложена обновлённая схема устройства и новые печатные платы, в т.ч. и внешней антенны. Этот вариант уже одинаково хорошо работает на CP-Z-2 со всеми типами меток: с картами на большой внутренней антенне и с брелоками на внешней. Пробовал и вариант "брелок + большая внутренняя антенна (закрепив метку на задней стенке устройства примерно напротив катушки) - также получил "чистую" сессию, без ошибок...
..

[petr5555]

Карта или брелок - принципиальной разницы нет, внутри может быть один и тот же чип. Значение может иметь несоответствие размеров антенны метки и ридера. Например, считыватель "CP-Z-2 (мод MF-1)" нормально работает с картой, но сниффером их обмен перехватывается плохо, иногда ответы карты на сессии могут быть не видны вообще... Поэтому с этим считывателем в качестве "оригинала" следует брать метки в формате брелока.
..

Это смотря какой сниффер ..........

[RECTO]

Это смотря какой сниффер ..........

В данном случае я не вижу особой разницы между "ответы карты не видны вообще" и "вместо ответов карты виден один мусор"...
..

[RECTO]

Практическое руководство по копированию Mifare. Заключение.

(Предыдущая часть: Практическое руководство по копированию Mifare. Часть 2)


Думаю, Вы уже сталкивались (или неизбежно столкнётесь) с ситуацией, когда всё, вроде бы, сделано правильно, но тем не менее - записанная Вами копия не работает. Когда Вы подносите её к считывателю, домофон вообще никак на неё не реагирует и даже не выдаёт "Error". Почему так происходит?.. Конечно, Вы уже слышали о "фильтрах", которыми снабжены считыватели последних поколений, а также о том, что для обхода этих фильтров нужно подбирать "правильную" заготовку. Но как определить, что за фильтр там установлен и какую заготовку выбрать в том или ином случае?.. Об этом я и попытаюсь здесь рассказать. Поэтому данная часть не будет содержать никаких руководств к действию, а будет носить в основном информационно-познавательный характер. В общем, приступим!

...Ваше счастье, если посмотрев лог обмена, Вы увидите там нечто похожее на предыдущий пример. Но, как Вы понимаете, не всё так просто в этом мире. Производители СКУД внедряют в программное обеспечение своих устройств специальные методы, препятствующие копированию и несанкционированному добавлению в систему новых ключей. Поэтому в реальной практике Вы, скорее всего, увидите там нечто вроде:

pcd : 26
tag : 04 00
pcd : 93 20
tag : F9 59 06 05 A3
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
pcd : 50
pcd : 40
pcd : 26
tag : 04 00
pcd : 93 70 F9 59 06 05 A3 DB 04
pcd : 26
tag : 04 00
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
pcd : 60 01 7C 6A
tag : B1 09 A6 7A
pcd : A5 98 BC A8 9D 06 DA AB  ‹Parity›
tag : 02
pcd : 26
tag : 04 00
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
pcd : 26
pcd : 26
tag : 04 00
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
pcd : 60 01 7C 6A
tag : D5 90 7C C2
pcd : A4 52 79 25 19 6D 97 8E  ‹Parity›
tag : 1A 6E B1 16  ‹Parity›
pcd : 9F 8D AC 7C  ‹Parity›
tag : 97 42 E5 87 D2 85 DB 4C 46 09 26 F5 82 D6 6A 80 84 60  ‹Parity›
pcd : 51 39 D4 88  ‹Parity›
tag : 73 AE 4D E1 72 4B 19 24 30 0F D9 38 DF 62 5A 44 C9 67  ‹Parity›
pcd : 26
tag : 04 00
pcd : 93 20
tag : F9 59 06 05 A3
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
pcd : 26
tag : 04 00
pcd : 93 20
tag : F9 59 06 05 A3
pcd : 93 70 F9 59 06 05 A3 DB 04
tag : 08 B6 DD
................................
и т.д.

или что-нибудь ещё более страшное...

Собственно, это и есть "фильтр-антиклон" в действии. Принцип здесь примерно тот же, что и ранее применялся в фильтрах для Touch Memory: заготовка, в отличие от обычного ключа имеет набор дополнительных команд. Следовательно, по реакции на такие команды можно определить, что перед нами - оригинал или его копия (на заготовке). То есть, получив такую "спецкоманду", заготовка пошлёт определённый ответ на неё, в то время как оригинальный Mifare Classic будет молчать. Либо наоборот - заготовка может ответить как-то иначе, чем настоящий Mifare Classic в определённой ситуации - просто в силу неполной реализации протокола в её чипе.

Рассмотрим полученный лог более подробно. Первое, и самое очевидное, что сразу же бросается в глаза: команды ридера 50h и 40h, следующие одна за другой. Для тех, кто не совсем в курсе, поясню: данные команды - это часть протокола записи заготовок с изменяемым UID (например, Mifare Zero). Если эти команды получит обычный Mifare Classic, то он "промолчит" - что, собственно, мы и видим на нашей сессии. А заготовка Mifare Zero в этой ситуации пошлёт ответ "ACK" = 0Ah (4 бита), чем и "выдаст себя с головой". На этом её "общение" с домофонной панелью закончится...

Я не зря упомянул здесь именно Mifare Zero - дело в том, что в отличие от других, более поздних заготовок (например, MF-OTP) она перезаписываемая, т.е. содержимое её 0-го блока в режиме "unlocked" можно переписать много раз. Разработки, которые появились позднее, имели цель решить как раз эту проблему - чтобы заготовка при работе с панелью не отвечала на "спецкоманды", генерируемые фильтром, и не выдавала бы этим себя. Проблему решили самым очевидным образом - сделали заготовку однократно записываемой (OTP = One Time Programming). В результате, протокол записи в "unlocked" у такой заготовки можно выполнить только один раз, после чего заготовка ни на какие "спецкоманды" реагировать уже не будет. Правда, и переписать UID у неё тоже больше не получится. Но, как правило, конечному потребителю это и не важно...
В общем, данную часть фильтра можно условно назвать "анти-Zero" - она обнаруживает клоны на заготовках Mifare Zero, в то время как более поздние заготовки, начиная с MF-OTP, её успешно обходят...

Следом, в "порядке очерёдности", идёт фильтр заготовки MF-OTP. Распознать его тоже несложно. Мы видим, вроде бы, обычную команду "select uid", за которой ридер сразу же посылает сброс REQA (26h). Странно?.. Да, но дело в том, что вместе с командой "select uid" здесь происходит ещё кое-что, не предусмотренное протоколом ISO 14443-A (на логе этого не видно, но тем не менее, это так). Поэтому нормальный Mifare Classic в ответ на эту команду промолчит и ридер, не дождавшись ответа, пошлёт REQA. Но заготовка MF-OTP (впрочем, как и MF-Zero) в силу упрощённой реализации протокола такую ситуацию спокойно "проглатывает" и, как ни в чём ни бывало, посылает ответ SAK. Таким образом домофон "понимает", что ему пытаются подсунуть клон ключа на MF-OTP и он прекращает работу с такой меткой...

Эту часть фильтра условно назовём "анти-OTP". Она не столь очевидна, как "противозерошная", но если знать, куда и на что смотреть, её также можно легко обнаружить. Ситуация впоследствии была исправлена выпуском заготовки OTP 2.0 - начиная с неё заготовки уже более точно воспроизводят протокол, не посылают SAK в описанной выше ситуации и позволяют обходить данный фильтр...

Далее следует довольно интересная "конструкция": ридер посылает запрос на аутентификацию с ключом "А", после чего начинается, вроде бы, обычная процедура двухстороннего обмена. Но в конце, вместо ответа "tag response" метка отвечает NACK (4 бита) и на этом попытка аутентификации заканчивается... На первый взгляд можно предположить, что произошёл какой-то сбой - ведь потом ридер, как ни в чём ни бывало, возобновляет попытку аутентификации, которая теперь уже проходит успешно. Но - нет! Если мы посмотрим серию однотипных сессий, снятых с того же считывателя, то увидим на них аналогичный "контент", в том же самом месте. Значит - это не ошибка и сделано не просто так!

А именно, что здесь происходит: ридер специально делает первый запрос на аутентификацию с заведомо неверным ключом, скорее всего даже - посылает метке какие-то случайные значения вместо "reader challenge" и "reader response". В этом можно легко убедиться, если попробовать рассчитать ключ аутентификации по нескольким таким сессиям через программу qrapto1 - никакого ключа по этим данным получить не удасться...

Зачем это нужно? Да просто таким способом реализуется защита СКУД от устройств захвата ключа аутентификации: SMKey, или например, ранних версий этого проекта. Ну, это и очевидно - устройство захвата эмулирует метку и ждёт от считывателя запрос на аутентификацию. Обработав первый же запрос, оно пытается вычислить ключ по полученным данным (точнее, по данным от двух таких запросов). Но рассчитать ничего не удасться, поскольку этот запрос не содержит информации о правильном ключе...

Как Вы помните, нечто подобное проделывали и мы в предыдущей части - когда делали дубликат на обычный Mifare Classic. Но там мы перехватывали обмен считывателя с реальной меткой, к тому же нам был виден весь лог обмена. В этом-то и заключается главное преимущественное отличие сниффера от подобных устройств - мы без труда найдём в логе настоящий запрос на аутентификацию и вычислим правильный ключ. В то время как устройство захвата обычно умеет лишь частично воспроизводить протокол обмена по заданному UID... Так что эту часть фильтра (тоже условно) можно назвать "антизахват" - она защищает от устройств захвата ключа аутентификации.

Оставшаяся часть фильтра реализуется уже на уровне самого считывателя: теперь при чтении метки считыватель проверяет соответствие её реального UID и рабочего идентификатора, находящегося в 1-м блоке. Нетрудно догадаться, что такая мера введена для того, чтобы невозможно было сделать копию на обычный Mifare Classic, тем самым обойдя рассмотренные ранее фильтры. То есть, даже получив (при помощи сниффера) правильный ключ аутентификации к сектору 0 для метки-дубликата, мы не сможем ею воспользоваться - копия не будет работать, поскольку идентификатор из 1-го блока не будет совпадать с UID метки.

А кроме того, помимо самого идентификатора (копии UID) в 1 и 2 блоки 0-го сектора записывается дополнительная информация - возможно, зашифрованная копия UID и(или) контрольная сумма. В этом легко убедиться, если посмотреть их содержимое - помимо копии UID там теперь вместо "нулей" записаны ещё какие-то данные. То есть здесь, видимо, по задумке Iron Logic, должна была закрыться ещё одна "лазейка" - чтобы Вы больше не смогли самостоятельно добавить новые метки в систему, даже если у Вас есть доступ к ТМ-контроллеру и Вы можете включить функцию добавления ключей. Однако на практике эта мера носит, по большому счёту, формальный характер и довольно легко обходится - достаточно просто забить эту область "нулями" (как на старых ключах). Впрочем, эти вопросы уже выходят за рамки данной статьи...

..........

Так как же, всё-таки, располагая логом обмена со сниффера, подобрать "правильную" заготовку для изготовления копии вашей метки?.. В общем, резюмируя всё вышесказанное, на сегодняшний день можно дать следующие рекомендации (здесь я буду исходить из того, что ваша домофонная панель оборудована считывателем CP-Z2 MF от Iron Logic-а. Для других считывателей рекомендации будут другими). Итак, какие тут могут быть варианты:

1. Если вы видите лог, аналогичный примеру из 1-й части, то можно с уверенностью сказать, что этот считыватель не использует никаких фильтров, поэтому для дубликата можно взять любую имеющуюся заготовку, начиная с MF-Zero. Или, что ещё лучше - сделать копию на такой же Mifare Classic используя методику, описанную в предыдущей части.

2. Если лог будет похож на разобранный выше пример - т.е., видны фильтры "Zero" и "OTP", а чтение зашифрованных данных происходит только из блоков 0-го сектора, то в качестве заготовки нужно использовать OTP 2.0 или MF-3.

3. Если на логе будут видны фильтры "Zero" и "OTP", при этом чтение зашифрованных данных происходит сначала из одного из блоков 14-го сектора, а затем из 2-х блоков 0-го сектора, то в качестве заготовки следует брать MF-3.

4. И, наконец, в логе может обнаружиться странная команда E0 80 31 73, на которую метка отвечает 4 бита NACK (а может и не отвечать). Фильтры "Zero" и "OTP" обычно присутствуют, но если метка до этого ответила "нестандартным" SAK = 28h на запрос "select uid", то их может и не быть. Да и сама команда E0 80 31 73 тогда подаётся уже где-то ближе к концу, вместе с другими специфичными для этой метки (IL-30) командами...
В любом случае, на сегодняшний день сделать копию метки конкретно под эту домофонную панель пока что не представляется возможным. Прошивка 7.20 считывателя (а в данном случае - это именно её работа) фильтрует все существующие заготовки. Так что, к сожалению, пока что придётся временно отказаться от этой идеи, запастись терпением и ждать выхода новой заготовки (MF-4). Ну, а там поглядим...

Конец!

..

[seregkasa]

Программу можно взять здесь.

В какой среде собрать EXE-шник (qrapto1) или в какой среде она работает?
..

[RECTO]

В какой среде собрать EXE-шник или в какой среде она работает?

Qt4.
......

[seregkasa]

Qt4.
......

не получается версий Qt море