- Специальный корреспондент
Однажды мне срочно понадобилось попасть в один бизнес-центр с пропускной системой в виде турникетов, открывающихся при помощи карт-пропусков. Человек, у которого находился в этот момент пропуск, был далеко, передать мне его он не мог, а оформление новой карты в силу бюрократических особенностей заняло бы много времени.
С чем мы имеем дело
Итак, человек с пропуском находится далеко, считывателя для бесконтактных карт у него с собой конечно же нет, но есть телефон, на который можно сделать фотографию карты.
По фото карта была опознана как EM-Marin, она же EM4100. Эти бесконтактные карты работают на частоте 125 КГц и содержат номер (далее — ID) размером 40 бит или 5 байт, который записывается на карту еще на заводе и не может быть изменен. Какой-либо защиты от чтения или копирования в них нет. Для создания дубликатов этих карт используются заготовки T5577 и EM4305, которые свободно продаются.
Перезаписываемые карты-болванки выглядят как обычная пустая пластиковая карта в форм-факторе кредитки, а не перезаписываемые (с прошитым на заводе серийным номером) чуть толще и на лицевой стороне у них нанесен текст, состоящий из нескольких групп десятичных цифр. Встречаются и карты в виде брелков.
Для записи таких карт потребуется соответствующий копировщик. Я использую Proxmark3, но можно взять любой другой, который может работать с T5577 и позволяет ввести ID карты вручную. Или же вовсе использовать эмулятор, тогда можно обойтись без болванок.
Карта не имеет своего источника питания, оно поступает со считывателя «по воздуху», как в беспроводных зарядках. Считыватель генерирует электромагнитное поле, карта улавливает его через антенну и включается. Далее карта модулирует поле и начинает циклически передавать свой ID, который улавливается считывателем, связь при этом односторонняя.
Как именно передаются данные с карты: сперва идет преамбула из 9 бит «1», затем передается 1 байт Version Number, 2 байта Facility Code и 2 байта уникального номера карты, периодически следуют биты контроля четности. Взято , там кстати еще неплохое описание протокола (на английском).
В самом простом варианте построения СКУД считыватель сам является контроллером доступа – сравнивает ID карты с номерами в памяти и принимает решение об открытии замка или турникета. В системах посложнее он отправляет эту информацию на контроллер по какому-либо интерфейсу.
Эксперимент
Итак, на карте нанесены некие цифры. Было логично предположить, что это и есть ее ID. Для того, чтобы это выяснить, я взял данные аналогичной карты, получилось следующее:
Цифры на карте: 0013396136 204.26792
ID: 4A00CC68A8
После преобразования ID из HEX в DEC, получилось 317840976040, что не похоже на цифры с карты. Спойлер: если бы я сделал наоборот, и конвертировал цифры с карты в шестнадцатеричный формат, то я добился бы успеха сразу, но тогда эта статья была бы не такой содержательной
Размышляя над тем, что еще оно может значить, я вспомнил, что Proxmark помимо ID карты показывает еще кое-какие данные:
lf search
proxmark3> lf search
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
EM410x pattern found:
EM TAG ID : 4A00CC68A8
Possible de-scramble patterns
Unique TAG ID : 5200331615
HoneyWell IdentKey {
DEZ 8 : 13396136
DEZ 10 : 0013396136
DEZ 5.5 : 00204.26792
DEZ 3.5A : 074.26792
DEZ 3.5B : 000.26792
DEZ 3.5C : 204.26792
DEZ 14/IK2 : 00317840976040
DEZ 15/IK3 : 000352190666261
DEZ 20/ZK : 05020000030301060105
}
Other : 26792_204_13396136
Pattern Paxton : 1256236712 [0x4AE0A6A8]
Pattern 1 : 10853441 [0xA59C41]
Pattern Sebury : 26792 76 5007528 [0x68A8 0x4C 0x4C68A8]
Valid EM410x ID Found!
proxmark3>
Ага, 0013396136 и 204.26792 — это именно то, что написано на карте!
Но ведь на ней хранится всего лишь 5 байт, значит эти числа должны вычисляться из ID по некому алгоритму ридером или его клиентом. К счастью, Proxmark – open-source проект, его исходные коды доступны на . Я сделал поиск в репозитории по строке «DEZ 10» и нашел функцию cmdlfem4x.c.
Часть кода cmdlfem4x.c:
...
//output 88 bit em id
PrintAndLog("\nEM TAG ID : %06X%016" PRIX64, hi, id);
} else{
//output 40 bit em id
PrintAndLog("\nEM TAG ID : %010" PRIX64, id);
PrintAndLog("\nPossible de-scramble patterns");
PrintAndLog("Unique TAG ID : %010" PRIX64, id2lo);
PrintAndLog("HoneyWell IdentKey {");
PrintAndLog("DEZ 8 : %08" PRIu64,id & 0xFFFFFF);
PrintAndLog("DEZ 10 : %010" PRIu64,id & 0xFFFFFFFF);
PrintAndLog("DEZ 10 : %010" PRIu64,id & 0xFFFFFFFF);
PrintAndLog("DEZ 5.5 : %05lld.%05" PRIu64,(id>>16LL) & 0xFFFF,(id & 0xFFFF));
PrintAndLog("DEZ 3.5A : %03lld.%05" PRIu64,(id>>32ll),(id & 0xFFFF));
PrintAndLog("DEZ 3.5B : %03lld.%05" PRIu64,(id & 0xFF000000) >> 24,(id & 0xFFFF));
PrintAndLog("DEZ 3.5C : %03lld.%05" PRIu64,(id & 0xFF0000) >> 16,(id & 0xFFFF));
...
Из кода выше становится ясно, что эти числа – части ID карты:
0013396136 (DEZ 10) – первые 4 байта, если считать от младшего к старшему.
204.26792 (DEZ 3.5C) – третий байт отдельно (он же Facility Code) и непосредственно 2 байта серийного номера карты.
Таким образом, по цифрам на карте можно восстановить часть ее ID. Но как быть, если известны 4 байта, а требуется 5? И если четвертый байт имел значение 0 на всех считанных мной картах, то пятый байт всегда ненулевой. Перебирать этот байт в конкретном случае не вариант — не хочется вызывать подозрения у охраны.
Тут я вспомнил, что СКУД в этом бизнес-центре установлен достаточно давно, поэтому я предположил, что там может использоваться для передачи данных популярный, но устаревший . Этот протокол предназначен для связи считывателя с контроллером, и позволяет передавать за одну посылку 24 бита данных и 2 бита четности, итого 3 байта. Это означает, что ID карты не передается полностью и неизвестный пятый байт никак в идентификации не участвует и может быть рандомным.
Стоит отметить, что некоторые современные считыватели все же читают и сравнивают старший байт карты, в таком случае придется перебирать 255 комбинаций, но это можно сделать за приемлемое время, особенно если использовать эмулятор.
Ну что же, теперь осталось проверить на практике все изыскания выше. Для создания копии карты я взял заготовку T5577 и записал на нее полученный ID (пятый байт — случайный):
Запись карты
Получилась почти полная копия карты с фото, отличается только старший байт. Для уверенности можно еще раз ввести команду lf search и проверить, совпадают ли DEZ 10 и DEZ 3.5C с цифрами на оригинальной карте.
После этого я записал уже преобразованный аналогичным образом ID нужного мне пропуска.
Как и ожидалось, карта считалась корректно, турникет щелкнул, мигнул зеленым индикатором.
Пост-скриптум
Если вы отвечаете за безопасность, то скорее всего, все описанное в этой статье не будет для вас новостью. В противном случае все же не стоит преждевременно рвать волосы на теле. Проблема кроется в том, что данный формат карт изначально не обеспечивает высокого уровня безопасности. Эти карты не поддерживают каких-либо механизмов аутентификации и шифрования, следовательно могут быть скопированы в любой момент подходящим считывателем. На серьезных объектах, таких как банки, дата-центры и хранилища ядерных боеголовок, вместо EM-Marin применяются более защищенные форматы карт (по крайней мере, хочется в это верить). Например, это семейство MIfare, где карты разделены на сектора с индивидуальными ключами чтения и записи, а некоторые карты этого стандарта поддерживают даже алгоритм шифрования AES. Ну и не стоит забывать про дополнительные методы контроля доступа.
С чем мы имеем дело
Итак, человек с пропуском находится далеко, считывателя для бесконтактных карт у него с собой конечно же нет, но есть телефон, на который можно сделать фотографию карты.
По фото карта была опознана как EM-Marin, она же EM4100. Эти бесконтактные карты работают на частоте 125 КГц и содержат номер (далее — ID) размером 40 бит или 5 байт, который записывается на карту еще на заводе и не может быть изменен. Какой-либо защиты от чтения или копирования в них нет. Для создания дубликатов этих карт используются заготовки T5577 и EM4305, которые свободно продаются.
Перезаписываемые карты-болванки выглядят как обычная пустая пластиковая карта в форм-факторе кредитки, а не перезаписываемые (с прошитым на заводе серийным номером) чуть толще и на лицевой стороне у них нанесен текст, состоящий из нескольких групп десятичных цифр. Встречаются и карты в виде брелков.
Для записи таких карт потребуется соответствующий копировщик. Я использую Proxmark3, но можно взять любой другой, который может работать с T5577 и позволяет ввести ID карты вручную. Или же вовсе использовать эмулятор, тогда можно обойтись без болванок.
Карта не имеет своего источника питания, оно поступает со считывателя «по воздуху», как в беспроводных зарядках. Считыватель генерирует электромагнитное поле, карта улавливает его через антенну и включается. Далее карта модулирует поле и начинает циклически передавать свой ID, который улавливается считывателем, связь при этом односторонняя.
Как именно передаются данные с карты: сперва идет преамбула из 9 бит «1», затем передается 1 байт Version Number, 2 байта Facility Code и 2 байта уникального номера карты, периодически следуют биты контроля четности. Взято , там кстати еще неплохое описание протокола (на английском).
В самом простом варианте построения СКУД считыватель сам является контроллером доступа – сравнивает ID карты с номерами в памяти и принимает решение об открытии замка или турникета. В системах посложнее он отправляет эту информацию на контроллер по какому-либо интерфейсу.
Эксперимент
Итак, на карте нанесены некие цифры. Было логично предположить, что это и есть ее ID. Для того, чтобы это выяснить, я взял данные аналогичной карты, получилось следующее:
Цифры на карте: 0013396136 204.26792
ID: 4A00CC68A8
После преобразования ID из HEX в DEC, получилось 317840976040, что не похоже на цифры с карты. Спойлер: если бы я сделал наоборот, и конвертировал цифры с карты в шестнадцатеричный формат, то я добился бы успеха сразу, но тогда эта статья была бы не такой содержательной
Размышляя над тем, что еще оно может значить, я вспомнил, что Proxmark помимо ID карты показывает еще кое-какие данные:
lf search
proxmark3> lf search
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
EM410x pattern found:
EM TAG ID : 4A00CC68A8
Possible de-scramble patterns
Unique TAG ID : 5200331615
HoneyWell IdentKey {
DEZ 8 : 13396136
DEZ 10 : 0013396136
DEZ 5.5 : 00204.26792
DEZ 3.5A : 074.26792
DEZ 3.5B : 000.26792
DEZ 3.5C : 204.26792
DEZ 14/IK2 : 00317840976040
DEZ 15/IK3 : 000352190666261
DEZ 20/ZK : 05020000030301060105
}
Other : 26792_204_13396136
Pattern Paxton : 1256236712 [0x4AE0A6A8]
Pattern 1 : 10853441 [0xA59C41]
Pattern Sebury : 26792 76 5007528 [0x68A8 0x4C 0x4C68A8]
Valid EM410x ID Found!
proxmark3>
Ага, 0013396136 и 204.26792 — это именно то, что написано на карте!
Но ведь на ней хранится всего лишь 5 байт, значит эти числа должны вычисляться из ID по некому алгоритму ридером или его клиентом. К счастью, Proxmark – open-source проект, его исходные коды доступны на . Я сделал поиск в репозитории по строке «DEZ 10» и нашел функцию cmdlfem4x.c.
Часть кода cmdlfem4x.c:
...
//output 88 bit em id
PrintAndLog("\nEM TAG ID : %06X%016" PRIX64, hi, id);
} else{
//output 40 bit em id
PrintAndLog("\nEM TAG ID : %010" PRIX64, id);
PrintAndLog("\nPossible de-scramble patterns");
PrintAndLog("Unique TAG ID : %010" PRIX64, id2lo);
PrintAndLog("HoneyWell IdentKey {");
PrintAndLog("DEZ 8 : %08" PRIu64,id & 0xFFFFFF);
PrintAndLog("DEZ 10 : %010" PRIu64,id & 0xFFFFFFFF);
PrintAndLog("DEZ 10 : %010" PRIu64,id & 0xFFFFFFFF);
PrintAndLog("DEZ 5.5 : %05lld.%05" PRIu64,(id>>16LL) & 0xFFFF,(id & 0xFFFF));
PrintAndLog("DEZ 3.5A : %03lld.%05" PRIu64,(id>>32ll),(id & 0xFFFF));
PrintAndLog("DEZ 3.5B : %03lld.%05" PRIu64,(id & 0xFF000000) >> 24,(id & 0xFFFF));
PrintAndLog("DEZ 3.5C : %03lld.%05" PRIu64,(id & 0xFF0000) >> 16,(id & 0xFFFF));
...
Из кода выше становится ясно, что эти числа – части ID карты:
0013396136 (DEZ 10) – первые 4 байта, если считать от младшего к старшему.
204.26792 (DEZ 3.5C) – третий байт отдельно (он же Facility Code) и непосредственно 2 байта серийного номера карты.
Таким образом, по цифрам на карте можно восстановить часть ее ID. Но как быть, если известны 4 байта, а требуется 5? И если четвертый байт имел значение 0 на всех считанных мной картах, то пятый байт всегда ненулевой. Перебирать этот байт в конкретном случае не вариант — не хочется вызывать подозрения у охраны.
Тут я вспомнил, что СКУД в этом бизнес-центре установлен достаточно давно, поэтому я предположил, что там может использоваться для передачи данных популярный, но устаревший . Этот протокол предназначен для связи считывателя с контроллером, и позволяет передавать за одну посылку 24 бита данных и 2 бита четности, итого 3 байта. Это означает, что ID карты не передается полностью и неизвестный пятый байт никак в идентификации не участвует и может быть рандомным.
Стоит отметить, что некоторые современные считыватели все же читают и сравнивают старший байт карты, в таком случае придется перебирать 255 комбинаций, но это можно сделать за приемлемое время, особенно если использовать эмулятор.
Ну что же, теперь осталось проверить на практике все изыскания выше. Для создания копии карты я взял заготовку T5577 и записал на нее полученный ID (пятый байт — случайный):
Запись карты
Получилась почти полная копия карты с фото, отличается только старший байт. Для уверенности можно еще раз ввести команду lf search и проверить, совпадают ли DEZ 10 и DEZ 3.5C с цифрами на оригинальной карте.
После этого я записал уже преобразованный аналогичным образом ID нужного мне пропуска.
Как и ожидалось, карта считалась корректно, турникет щелкнул, мигнул зеленым индикатором.
Пост-скриптум
Если вы отвечаете за безопасность, то скорее всего, все описанное в этой статье не будет для вас новостью. В противном случае все же не стоит преждевременно рвать волосы на теле. Проблема кроется в том, что данный формат карт изначально не обеспечивает высокого уровня безопасности. Эти карты не поддерживают каких-либо механизмов аутентификации и шифрования, следовательно могут быть скопированы в любой момент подходящим считывателем. На серьезных объектах, таких как банки, дата-центры и хранилища ядерных боеголовок, вместо EM-Marin применяются более защищенные форматы карт (по крайней мере, хочется в это верить). Например, это семейство MIfare, где карты разделены на сектора с индивидуальными ключами чтения и записи, а некоторые карты этого стандарта поддерживают даже алгоритм шифрования AES. Ну и не стоит забывать про дополнительные методы контроля доступа.
