Оказалось, что в карточках одного типа бит коллизии установлен в одном и том же месте, поэтому коллизии не происходит. Добился выбора карты, аутентификации и чтения/записи из EEPROM, однако это происходит только один раз. Повторный цикл антиколлизии возможен только после перезагрузки устройства. Не могу никак победить проблему....
а добился чтения еепром всего 1Кбайта??? Если да то можно алгоритм? Номер карты читаю без проблем, а как почитать остачу памяти и записать туда что нибудь, это вопрос?
Неделю сражаюсь с mfrc522 второй ревизии. rc522 переведен в режим UART. Пока что командами обмениваюсь вручную через Terminal 1.9. Могу писать в FIFO, читать, присваивать значения регистрам. Застрял на WUPA для Mifare 1k (52h) - то-ли я не так понял даташит (надо сказать даташит тот еще...). Приведу свой инит и команды коммуникации, может будут мысли по этому поводу - буду признателен. Инит: 11 3D 2D 30 2C 00 2A 8D 2B 3E 14 03 15 40 Попытка отправить 52 карте Mifare 1k: 09 52 0D 07 01 0C 0D 80 После команды буфер просто пустеет, то-есть ответа (предполагаемого мной) не происходит. Видимо я что то не так понял из даташита?
Добавлю заранее. REQA тоже пробовал. 09 26 0D 07 01 0C 0D 80 Данные из буфера уходят, и Status2Reg:ModemState = 101 wait for data. Однако буфер все равно пуст. Или я упускаю какой то регистр, который должен активировать правильный прием данных, или я абсолютно не понимаю что делаю
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Маленькая поправка к нижесказанному - на самом деле проблема только с Arduino Mega и режиме i2c, на самодельном переходнике (usb > ttl) на базе ch340 все работает хорошо. В общем продолжу тему, ибо она мне интересна и возможно кто то придет после с подобными же вопросами. В моем случае происходит крайне странная хрень. Команды приведенные мной оказываются рабочие и делал я все правильно, но проблема заключается в том что по какой то причине в i2c режиме и по всей видимости в режиме UART моя плата (ЛУТ) а так же китаец rc522 выдает очень маленький вольтаж на антенне. Совершенно не понятно почему, буду разбираться, но подав на камешек 5в платы заработали. Копаю дальше и потиху буду складывать здесь отчеты. SPI режим отлично работает с 3.3в
Последний раз редактировалось maddogmaycry Вс сен 10, 2017 17:59:21, всего редактировалось 1 раз.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
В общем какие косяки я словил на данный момент. Arduino Mega отказывается нормальные 3.3 вольта выдавать, и дело тут даже не в ASM1117 так как на моей плате с этим регулятором все работает хорошо - будьте внимательны - сам камень может работать, но антенна при этом ничего не принимать (проверено в режиме i2c rc522). Таки команды были неправильными. Недостаточно установить бит "StartSend" по адресу BitFramingReg, требуется еще и сохранить 7битную длинну, и именно в этой части кода 0D 80 я и пролетел. Нужно отправлять сохраняя 7 битное значение, а значит команда отправки будет 0D 87.
Так же я допустил ошибку по адресу TxControlReg. 14 80 - Должно быть 14 83, ведь бит nvTx2RF должен быть On, почему пока не понятно, но я разберусь позже и наверняка выложу отчет. В общем REQA можно получить следующей командой (для терминала 1.9 - $ = HEX) Инит $01$0F$11$3D$2D$30$2C$00$2A$8D$2B$3E$14$03$26$70$15$40 Отправка / получение $14$83$09$52$01$0C$0D$87 Classic - 04 00 Desfire EV1 4k - 44 03 Ultralight c - 04 00 Ultralight c без переделки rc522 не заработает, так как требуются более мощные индукторы на > 100ma!
Продолжаю копать, следующий шаг - анти-коллизия. О успехах отчитаюсь. Всем кто желает помочь, всегда рад. На выходе планирую библиотеку для недооцененного на мой взгляд mfrc522,- i2c и Uart для работы с шифрованными картами Desfire ev и ultralight c.
На данный момент есть вопрос: [вопрос снят. Ответ: есть разные варианты на разные случаи и разной степенью надежности] После каждого приема/передачи требуется-ли делать софт/хард ресет зверька? То-есть выходит этакая итерация - инициализация, запрос, чтение, ресет. И по новой - инит...
И так, на текущий момент я дошел до пункта Select и застрял. Отправил REQA (ответ 04 00) Получил UID. Сгенерировал CRC (MSB и LSB). Отправляю 93 70 UID BC MSB LSB И... тишина. UPD Похоже что то не так с CRC. Сейчас читаю ГОСТ 14443 дабы понимать как правильно его формировать.
В общем ознакомился с 14443 и пришел к выводу что все должно работать. Проверочный 00 00 дает CRC 1ЕА0. Проверочный 12 34 дает СF 26. Хм, что ж не так то. UPD Разобрался. "Кадр CRC_A является функцией k бит данных, которые состоят из всех бит данных в кадре, за исключением бита контроля четности, S, Е и самого CRC_A. Поскольку данные кодируются в байтах, количество бит k кратно 8." Заветный SAK 08 B6 DD Копаю дальше.
Небольшая программка на PHP помогла увеличить скорость обучения. На данный момент разбираюсь с Classic 1k: -> 010F [Reset] -> B7 [Version] <- 92 -> 010F113D2D302C002A8D2B3E148326701540 [Init] -> 0952010C0D87 [Send REQA] -> 8989 [Read REQA] <- 0400 -> 09930920010C0D80 [Anticol] -> 8989898989 [Read UID] <- 90F60BC5A8 -> 09930970099009F6090B09C509A801030100 [Calculate CRC] -> A2A1 [GET CRC] <- CE6F -> 09930970099009F6090B09C509A809CE096F010C0D80 [Select] -> 898989 [Read SAK] <- 08B6DD
UDP: Угу, действительно SAK - Coding of Select Acknowledge. В моем случае [08 (00001000) указывает на то что UID передан полностью] [B6DD По всей видимости CRC] UPD: DD - CRC, B6 фиг знает что, надо будет выяснить. Desfire ev1. Первая анти-коллизия у него возвращает только первые 4 byte UID. Смотрим табличку. https://www.nxp.com/docs/en/application ... df#page=11 XX1XX0XX - UID not Completed. Все сходится. SAK - 24D836 (24 [00100100]) Позже проверю что он вдаст если его антиколизить правильно. Кстати, параллельно выяснил, что есть два типа карт classic 1k. До 10 года (4 byte UID) и после (7 byte UID). В общем дальше авторизация classic 1k.
Последний раз редактировалось maddogmaycry Сб сен 23, 2017 22:47:58, всего редактировалось 8 раз(а).
maddogmaycry, слежу за темой. Выкладывайте инфу - пригодиться однозначно! У меня сейчас времени нет продолжать свой проект: когда доберусь будет куча вопросов....
В общем продолжаем. Пробуем авторизоваться. Честно сперто из примера https://image.slidesharecdn.com/mifare- ... 1278953071 что значит 07671EC1 я пока не разбирался, что то это значит и когда я преодолею свою лень, обязательно узнаем ))) -> 010F [Reset] -> B7 [Version] <- 92 -> 010F113D2D302C002A8D2B3E148326701540 [Init] -> 0952010C0D87 [Send REQA] -> 8989 [Read REQA] <- 0400 -> 09930920010C0D80 [Anticol] -> 8989898989 [Read UID] <- 90F60BC5A8 -> 09930970099009F6090B09C509A801030100 [Calculate CRC] -> A2A1 [GET CRC] <- CE6F -> 09930970099009F6090B09C509A809CE096F010C0D80 [Select] -> 898989 [Read SAK] <- 08B6DD -> 096009300976094A010C0D80 [Auth block 30] -> 89898989 [Answer] <- 07671EC1
Вообще странно пока, откуда в примере взялся block 30 не понимаю, тогда как http://cache.nxp.com/docs/en/data-sheet ... pdf#page=8 сообщает явно = блока 4: 0-3. Копаем UPD In Mifare Classic 1K tags There are 16 Sectors and each Sectors contains 4 Blocks and each block contains 16 bytes. Теперь все ясно. Идем дальше.
Чуть отвлекусь от основной темы, и коснусь смежной.
Цитата:
// Wait for the CRC calculation to complete. Each iteration of the while-loop takes 17.73us. for (uint16_t i = 5000; i > 0; i--) { // DivIrqReg[7..0] bits are: Set2 reserved reserved MfinActIRq reserved CRCIRq reserved reserved byte n = PCD_ReadRegister(DivIrqReg); if (n & 0x04) { // CRCIRq bit set - calculation done PCD_WriteRegister(CommandReg, PCD_Idle); // Stop calculating CRC for new content in the FIFO. // Transfer the result from the registers to the result buffer result[0] = PCD_ReadRegister(CRCResultRegL); result[1] = PCD_ReadRegister(CRCResultRegH); return STATUS_OK; } }
Код взят из самой популярной библиотеки для mfrc. Мне подобный подход к построению логики кажется странным. 5000 итераций, приблизительно понимая, что каждая итерация займет 17 микросекунд. Интересно, одному мне подобный подход кажется странным?
http://nickholdren.com/wp-content/uploa ... pstone.pdf Занимательнейшее чтиво. Конечно не очень мне интересно Classic ковырять - не актуально, но в образовательных целях сгодится. Что то мне подсказывает, что у Desfire более разумный процесс авторизации, а не эта чушь с XOR'ами у Crypto1.
И так, авторизация и что я на данный момент о ней знаю. Команда 60 говорит карте - авторизуюсь в таком то блоке. Карта вызывает нас на челлендж высылая NT. Теперь у нас есть key, nt, и uid. Теперь из данных обьектов требуется создать NR, KS1, AR, KS2. Формулы ни в одном из даташитов найти не удалось (лишь только поверхностные данные). Что есть еще:
Цитата:
The challenge nT has a length of 32bits, but as mentioned before the LFSR is only 16 bits.This means that the 16 bits that are not accounted for are enerated by theLFSR from the initial seed and .The value of the LFSR updates with every clock tick (every 9.44Μs) and value depends on thetime the tag powers p nd when communication is invoked. Therefore, the challenge nonce,nT, since LFSR of the tag isdeterministic, can be replicated at anytime by controlling start up nd when communications begins. Initially, the state of theLFSR is only the input bit 1 and the rest of the register are 0 s.With each clock tick, the feedback bits are omputed using thespecified taps and XOR - ing them to generate a new input bit. This bit is fed back into the register onto the right and the registeris shifted to he eft. The operation can be defined as
В принципе зачем то описывается процесс генерации NT со стороны карты. Продолжение следует.
nT - Tag nonce. nR - Reader nonce. KS - key stream или sector key.
Приветствую. Сегодня пробуем авторизовать Classic 1k. В общем суть там простая. Для начала открываем доку http://cache.nxp.com/docs/en/data-sheet ... df#page=15 9. Command overview гласит, что команда авторизации KEY A - 60h и KEY B - 61h Теперь идем и смотрим 72 страницу доки на mfrc522 - https://www.nxp.com/docs/en/data-sheet/ ... df#page=72 Смотрим порядок формирования строки для авторизации. Теперь идем https://www.nxp.com/docs/en/data-sheet/ ... df#page=70 и смотрим команду инициализации авторизации MFauth. 1110 (4 бита, но нам то нужно 8 - 00001110) соответственно "0E", а вместе с CommandReg, который инициализирует выполнение встроенных команда получается "010E". Ок, авторизовать будем блок 00h. В соответствии с докой открытой ранее, строка лежащая в FIFO должна иметь следующий вид: 6000KEYAUID. В моем случае 6000FFFFFFFFFFFF90F60BC5 60 - Авторизация 00 - Блок FFFFFFFFFFFFF - KEY A (по умалочанию кстати) 90F60BC5 - UID карты. Кстати, многие считают, что UID переводится как user id, на самом же деле - unical id. Хотя в случае с Classic 1k 4 byte uid это уже далеко не актуальная информация. То-есть команда для mfrc522 будет следующей:
Ну во всяком случае FIFO опустел уже хорошо, значит некий процесс по всей видимости произошел. Копаем дальше. Не берусь утверждать, но вроде как все получилось. Сейчас будем разбирать основные моменты. Используя краски и BB-коды
Я если честно со структурой карты Classic 1k в настоящее время на вы так сказать но уже знаю, что в блоке 00 сектора 0 находится так называемая Manufacture data, и первые 4 байта этого блока содержит UID. http://cache.nxp.com/docs/en/data-sheet ... pdf#page=8 Вот именно этот сектор я и прочитал, о чем свидетельствует последняя строка лога.
Как данные читать после авторизации. В логе есть регистр - Status2Reg. Его адрес 08 на зпись, и соответственно 88 на чтение. Регистр возвращает нам 08 hex - 00001000 bit's. Если открыть доку https://www.nxp.com/docs/en/data-sheet/ ... df#page=43 то можно понять, что третий бит "MFCrypto1On" установлен в 1, а это значит, что "ndicates that the MIFARE Crypto1 unit is switched on and therefore all data communication with the card is encrypted" - вся дата между картой и mfrc522 зашифрована, то есть авторизация по идеи сработала (вроде сработала) Сейчас сделаю пометки прямо в логе, что бы было понятно куда и что.
То-есть после того, как мы авторизовались, и хотим почитать какие-то блоки с карты, то нам надо отправить команду 30 и номер блока (к примеру 00). Опять же, для MFRC522 команда записи чего либо выглядит так - 09 00 - Запишет в FIFO 00. Соответсвенно если мы хотим отправить на карту команду 30 00, то обвязка будет следующей 09300900 - в буфере окажется команда 3000. Все элементарно (c) Но перед тем, как команда уйдет на карту, нам нужно добавить в конец этой команды ее CRC сумму. В логе можно увидеть, что сначала я отправляю в буффер 30 00. Потом вычисляю CRC.
09 30 09 00 01 03 01 00 - лог 09 30 09 00 - Положить в буфер 30 00 (30 READ, 00 - block) 01 03 - запустить CRC сопроцессор. 01 00 - IDLE - остановить все команды (ну это как бы что бы остановить CRC сопроцессор)
Затем читаю CRC. -> A2 A1 [GET CRC] - В регистрах A1 и A2 (их последовательность требуется перевернуть) хранится результат вычисления CRC для строки из буффера. Надо помнить, что буффер пустеет после окончания подсчета. <- 02 A8 - А вот и результат для команды 30 00
Теперь опять помещаю в буфер команду 30 00 но уже добавляю к ней CRC 09 30 09 00 09 02 09 A801 0C0D 80 09 30 09 00 - положить в буфер 30 00 09 02 09 A8 - положить в буфер CRC 01 0C 0D 80 - включаю передачу данных и отправляю все это на карту.
89 - операция чтения буфера. В логе - 89898989898989 - произвести чтение 7 байт. Буфер возвращает нам - 90F60BC5A88804
Сегодня читаем и пишем. Открываем https://www.nxp.com/docs/en/data-sheet/ ... pdf#page=8 и смотрим что там со структурой Classic 1k 4 byte "UID". У карты 15 секторов. Каждый сектор содержит 4 блока. Нумерация блоков 0-3 (4). Каждый из четырех блоков содержит 16 ячеек. Каждая ячейка равна одному байту. (0-15) (16) 16 байт. Каждый из 15 секторов, в блоке номер 3 (если отсчет блока идет от нуля) содержит KEY A, Access bits (некие биты доступа), KEY B. Вот как block 3 выглядит у меня:
Цитата:
000000000000FF078069FFFFFFFFFFFF
000000000000 - KEYB (угу, по всей видимости все зеркалируется) FF078069 - Access bits FFFFFFFFFFFF - KEYA Это из того что наверняка. Вроде как наверняка
Теперь о порядке авторизации в секторе, как я его понял на данный момент (может не совпадать с действительностью). Смотрите,- сектор, это вообще условная как я понял единица, ну что бы упростить визуальную составляющую (хотя не факт конечно). То-есть сектор надо высчитать блоками. Допустим 4 блок = 1 сектор, 0 блок. 5 блок = 1 сектор, 1 блок.
Далее. Если авторизоваться скажем во втором блоке, то для чтения/записи доступен и блок 0, 1, 3. Если авторизоваться в блоке номер 4, а блок номер 4 приналежит уже к сектору 1, то картина будет аналогичной. То-есть по большому счету нет необходимости для доступа к блоку номер 5, авторизоваться в блоке 7. Карта сама определяет сектор авторизации. Но это пока только моё ИМХО. Вот пример, который демонстрирует авторизацию в блоке номер 01 (где не может быть ключа, но чтение блока номер 03 при этом работает)
Я использую простой вариант, авторизацию провожу в том же блоке, в котором предполагаю операцию чтения/записи. Хотя конечно возможны и иные ситуации.
Иду дальше. Логично предположить, что авторизовавшись в секторе, мы могли бы получить доступ ко всем 4 блокам. Но вроде как это не так. После того как один из блоков прочитан, мы получаем следующую картину.
Работает. Перед каждой итерацией производим полную очистку буффера, видимо там что то есть. Странно конечно, после операции чтения 89 каждый прочитанный байт должен удаляться.
Все верно, видимо читаю не все что есть в буффере, видимо после операции чтения блока там не только 16 байт данных, но еще какая то системная инфа.
Да, все верно. 90F60BC5A88804008500B42EF0BB6AA8671E В буффере 18 байт, я читаю только 16. Соответсвенно, когда сопроцессор забирает из буфера данные, то все это дело перемешивается с остатками и CRC высчитывается неверно. Или читаем все 18 байт, или чистим буфер каждый раз когда требуется посчитать CRC. Или можно считать CRC отдельно от mfrc522.
UPD Все же надо выяснить что за два байта после каждого блока в FIFO. Делаю предположение что это CRC Сейчас проверим. Блок 1 - 000000000000000000000000000000003749 Кладу 00h x 32 в FIFO, запускаю просчет CRC. Читаю CRC регистры и получаю 3749. Все верно, это CRC блока.
В общем прочитал блоки 0 - 3. 90F60BC5A88804008500B42EF0BB6AA8671E 000000000000000000000000000000003749 000000000000000000000000000000003749 000000000000FF078069FFFFFFFFFFFFD455
Меняем ключ. В 3-ем блоке каждого сектора лежит ключ а,б, и байты доступ. Предполагаю, что достаточно сформировать 16 байт в соответствии со структурой изложенной выше, и тем самым менять все эти ключи и байты доступа. Не думаю что все так гладко, но шагать начинаю с этого.
Так, напоминаю, что там у нас в третьем блоке 000000000000FF078069FFFFFFFFFFFFD455 000000000000 - KEYB FF078069 - Access bytes FFFFFFFFFFFF KEYA D455 - CRC В общем пока есть несколько предположений. 1 - 000000000 KEYB, но мы его не видим из-за Access bytes (Это мое ИМХО на данный момент) 2 - Если 000000 это KEYA, то мы его не видим по той же причине, зато видим KEYB и он FFFFF Пробую поменять все 16 байт в блоке номер 7 (1 сектор 3 блок). Для начала просто подсунем ему 000000000000FF078069FFFFFFFFFFFF (как есть в общем). Так, в общем по всей видимости 00000 это скрытый KEYA
Теперь наш ключ FF0000000000. Со старым ключем чтение заданного блока не работает (0000000000000000000000000000). Авторизовавшись новым KEY A при чтении 7 блока я получил 0000000000FF078069FFFFFFFFF1. Видимо Access byte's настроены на скрытие KEYA.
000000000000FF078069FFFFFFFFFFF1AABC - пример демонстрирует, что KEYB не скрыт.
Ох, Access bytes. Читаем https://www.nxp.com/docs/en/data-sheet/ ... df#page=12 6 7 8 9 байты содержат access bits. Моя строка 000000000000FF 07 80 69FFFFFFFFFFF1AABC FF - 1111 1111 - 6 байт 07 - 0000 0111 - 7 байт 80 - 1000 0000 - 8 байт 69 - 0110 1001 - 9 байт - вроде как не учавствует в формировании. Вообще в даташите сказано что 9-ый байт Access Byte's = user data. Правила доступа из него не складываются.
Если вы разобрались в этой таблице, то вы молодец.
Небольшая подсказка. У нас три байта. 1 байт = 8 бит. В наших трех байтах всего 24 бита. Первые 12 БИТ это биты доступа (три блока по 4 бита). Другие 12 БИТ это инверсия битов доступа. Зачем? Честно скажу - не изучал. Читать БИТы требуется справа налево. Например FF = 1111 1111 <-. Вот мы видим 3 2 1 0 3 2 1 0 биты. 0 бит управляет 0 блоком. 1 бит - первым, ну и в таком ключе. Система доступа состоит из трех блоков C1 C2 C3 (три блока по 4 бита). 12 / 3 = 4 бита.
Возможно инверсия сверху, а вот биты доступа снизу! Надо проверить. FF - 1111[c2]1111[c1] 07 - 0000[c1] 0111[c3] 80 - 1000[c3] 0000[c2]
Первые 12 бит (три блока по 4 бита) 0111[c3]1111[c2]1111[c1] 1000[c3] 0000[c2] 0000[c1] Как видите, другие 12 бит это инверсия первых 12-ти или наоборот. Надо бы доку еще раз пошерстить.
Так. Сначала в соответствии с этой таблицей https://www.nxp.com/docs/en/data-sheet/ ... df#page=13 проверим какие выставлены правила доступа для моей карты. FF | 0~7 | 80 | (69) = 1111 1111 | 0000~0111 | 1000 0000 | ( 0110 1001 ) - Справа налево! Три блока по 4 бита.
Соответственно, в настоящий момент для блока 3,- сетка доступа выглядит следующим образом. Если первые 12 бит = access bits: С1 = 1, С2 = 1, С3 = 0 Если нет, то: C1 = 0, С2 = 0, С3 = 1
Sector trailer это каждый третий блок сектора, в котором располагается KEYA ACCESS BITS KEYB.
Пока что больше похоже что зелёненький вариант является TRUE Кстати, судя по таблице доступа - KEYA вообще никогда прочитан быть не может.
По всей видимости эпопея с Classic заканчивается. И начинается совсем другая история
Пару пояснений. В настоящий момент я не подписывал NDA с NXP, и если мне не будет хватать информации для обучения, то я его подпишу. Это будет означать окончание моего публичного образовательного процесса о DESFIRE на этом форуме.
https://www.nxp.com/docs/en/data-sheet/ ... 81_SDS.pdf - короткий даташит, ознакомиться с характеристиками, не более! Для обучения не пригоден. Но кое что из него почерпнуть можно. Вот на пример. Первое что необходимо будет выделить "7 bytes unique identifier (cascade level 2 according to ISO/IEC 14443-3 and option for random ID)" Значит потребуется использовать Cascade Level 2 в Anticollision cycles. https://www.nxp.com/docs/en/application ... pdf#page=3 Допустим у нас 7 byte UID. - В случае с Desfire это уже TRUE UID!
Пример: 01 02 03 04 05 06 07
Таблица говорит нам, что первый каскадный уровень отдаст нам: CT UID0 UID1 UID2 BCC
Второй уровень: UID3 UID4 UID5 UID6 BCC Теперь нам известно как получить UID. Пробуем.
Кстати, не на всех rc522 можно гонять Desfire. Не хватает у них мощи. Требуется индукторы менять. Ссылки на видео я сбрасывал выше. Любые индукторы на 100мА подойдут. Найдете 0805 - класс, найдете 1206 - 1210 - тоже норм. У меня плата самодельная, с мощными индукторами в корпусе 1812. Desfire EV1 и UltralightC работают хорошо. ИМХО на SPI если вы работаете через микроконтроллер, то может и без переделки Desfire работать будет хорошо. Но вот на UART у меня вроде как не хочет. ВРОДЕ! Не очень достоверная информация, не изучал особо. ИМХО в общем.
4403 - REQA. Приходит в зеркале. Переворачиваем 0344. Читаем тут - https://www.nxp.com/docs/en/application ... pdf#page=9 Тип карты определен как desfire ev1/desfire. Так, и еще. Тоже не менее важно для понимания. 0344h = 00000011 01000100 0000 - RFU 01 - UID Size (00 = 4 byte, 01 - 7 byte, 11 я так понимаю 10 byte. По поводу 10 byte - ИМХО) CT- 88 UID0 - 04 UID1 - 5E UID2 - 6F BC - BD
На сколько я помню 88 означает что UID передан не полностью. ИМХО! Сейчас найду доку. Угу, так и есть "The CT (0x88) indicates that the UID is not yet complete, and another Cascade Level has to follow." - https://www.nxp.com/docs/en/application ... pdf#page=3 внизу там листните.
Ок, как получить вторую часть UID. https://www.nxp.com/docs/en/application ... pdf#page=4 Вообще надо понимать, что публичные даташиты NXP - это чисто ознакомительная и я бы сказал неточная теоретическая часть, которая для работы подходит не очень хорошо. К пример, описывается команда CL, но не сказано сколько байт мы запрашиваем. Крайне рекомендую изучить ГОСТ 14443 прежде чем вообще приступать к работе с не то что бы Desfire, а вообще к какой либо другой карте Mifare. http://docs.cntd.ru/document/1200118652 Если вы уже изучили ГОСТ, то в настоящий момент нас интересует "6.5.3 Антиколлизия и Выбор" пользуйтесь поиском вашего браузера. Таблица 7 - Кодирование SEL 93 - каскадный уровень 1. 95 - выбор каскадного уровня 2. Ну и так далее.
06 75 77 81 02 80 02 F0 - ATS. Что это значит сейчас будем узнавать. Так, что то я пока не нашел описание ответа ATS. Так что отодвину данный вопрос на завтра.
Копаю дальше. Предположительно после RATS и ответе на него, мы должны выделить Application. У Desfire карт в отличии от Classic работа с памятью проходит посредством взаимодействия с Application ID. Ну, что то вроде блоков, с которыми мы можем взаимодействовать при помощи разных механизмов. Что можно делать с Application: Set Key Settings Get Key Settings Change Key Get Key Version Create App (Master) Delete Application Get AID List Get Card Version Format PICC (Master) Get File List Get File Settings Change File Settings Create Data File Create Value File Create Record File Delete File Read Data (All) Write Data (Std) И много чего еще, но меня пока интересует базис.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 24
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения