Форум РадиоКот

Вот еще из той же оперы, но есть немного комментариев...

Отличная ссылка!

[uquote="isx",url="/forum/viewtopic.php?p=3123460#p3123460"]Оказалось, что в карточках одного типа бит коллизии установлен в одном и том же месте, поэтому коллизии не происходит.
Добился выбора карты, аутентификации и чтения/записи из EEPROM, однако это происходит только один раз. Повторный цикл антиколлизии возможен только после перезагрузки устройства. Не могу никак победить проблему....[/uquote]
а добился чтения еепром всего 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.
Однако буфер все равно пуст. Или я упускаю какой то регистр, который должен активировать правильный прием данных, или я абсолютно не понимаю что делаю

Маленькая поправка к нижесказанному - на самом деле проблема только с Arduino Mega и режиме i2c, на самодельном переходнике (usb > ttl) на базе ch340 все работает хорошо.
В общем продолжу тему, ибо она мне интересна и возможно кто то придет после с подобными же вопросами. В моем случае происходит крайне странная хрень. Команды приведенные мной оказываются рабочие и делал я все правильно, но проблема заключается в том что по какой то причине в i2c режиме и по всей видимости в режиме UART моя плата (ЛУТ) а так же китаец rc522 выдает очень маленький вольтаж на антенне.
Совершенно не понятно почему, буду разбираться, но подав на камешек 5в платы заработали. Копаю дальше и потиху буду складывать здесь отчеты.
SPI режим отлично работает с 3.3в

В общем какие косяки я словил на данный момент.
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!

1 - Видео без модификации https://www.youtube.com/watch?v=jaqr-JE8MwA
2 - Модифицированный - https://www.youtube.com/watch?v=42DRSZrFyKc
Озвучивать не стал (особо нечего). О том как произвести модификацию см. коммент ко второму видео.

Продолжаю копать, следующий шаг - анти-коллизия. О успехах отчитаюсь.
Всем кто желает помочь, всегда рад. На выходе планирую библиотеку для недооцененного на мой взгляд mfrc522,- i2c и Uart для работы с шифрованными картами Desfire ev и ultralight c.

На данный момент есть вопрос: [вопрос снят. Ответ: есть разные варианты на разные случаи и разной степенью надежности]
После каждого приема/передачи требуется-ли делать софт/хард ресет зверька? То-есть выходит этакая итерация - инициализация, запрос, чтение, ресет. И по новой - инит...

Еще если вы вовлечены в мир NFC и RFID советую посетить канал https://www.youtube.com/watch?v=tuMjCsIyyuw&t=0s
Человек выкладывает ценнейший материал.

И так, на текущий момент я дошел до пункта 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, слежу за темой. Выкладывайте инфу - пригодиться однозначно! У меня сейчас времени нет продолжать свой проект: когда доберусь будет куча вопросов....

Чуток ссылок которые мне помогают в работе.
https://nfc-wisp.wikispaces.com/file/vi ... 4443-3.pdf
http://docs.cntd.ru/document/1200118652
https://www.nxp.com/docs/en/application ... N10833.pdf
http://cache.nxp.com/docs/en/data-sheet ... YYX_V1.pdf
https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf

В общем продолжаем. Пробуем авторизоваться.
Честно сперто из примера 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.

Читаем, есть формулы расчета - http://www.ict-forward.eu/media/worksho ... mifare.pdf
Собственно формула аутентификации великолепно демонстрирует слайд ниже

Но все что ниже NT - темный лес.
Создал тему https://www.mifare.net/support/forum/to ... procedure/ жду помощи зала.
Параллельно почитываю http://bcc.portal.gov.bd/sites/default/ ... 9798-2.pdf
https://www.researchgate.net/publicatio ... re_Systems
UDP
Вот я тупень то а. Crypto1 закрытый протокол, и в те времена, когда он все еще был актуален а принципах его работы знать никто не должен был. Именно по этой причине у mfrc522 есть специальная команда для авторизации карты MFAUTH(UID+BLOCK+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 будет следующей:

0960090009FF09FF09FF09FF09FF09FF099009F6090B09C5

Привожу полный лог

-> 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
-> 0960090009FF09FF09FF09FF09FF09FF099009F6090B09C5 [Auth string]
-> 010E [Authenticate]
<- 01
-> 89 [In FIFO?]
<- 00

Ну во всяком случае FIFO опустел уже хорошо, значит некий процесс по всей видимости произошел. Копаем дальше.
Не берусь утверждать, но вроде как все получилось. Сейчас будем разбирать основные моменты. Используя краски и BB-коды

-> 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
-> 0960090009FF09FF09FF09FF09FF09FF099009F6090B09C5 [Auth string]
-> 010E [Authenticate]
-> 88 [Status2Reg]
<- 08
-> 0930090001030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 02A8
-> 09300900090209A8010C0D80 [Send Read block 00 to Card]
-> 89898989898989 [Read]
<- 90F60BC5A88804

Я если честно со структурой карты 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 A8 01 0C 0D 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 при этом работает)

0960090109FF09FF09FF09FF09FF09FF099009F6090B09C5 [Авторизация в блоке 01]
010E [Authenticate]
88 [Status2Reg]
08
0930090301030100 [Calculate CRC]
A2A1 [GET CRC]
999A
093009030999099A010C0D80 [читаем блок 03]
89898989898989898989898989898989 [Read]
000000000000FF078069FFFFFFFFFFFF

Я использую простой вариант, авторизацию провожу в том же блоке, в котором предполагаю операцию чтения/записи. Хотя конечно возможны и иные ситуации.

Иду дальше. Логично предположить, что авторизовавшись в секторе, мы могли бы получить доступ ко всем 4 блокам. Но вроде как это не так.
После того как один из блоков прочитан, мы получаем следующую картину.

-> 0960090309FF09FF09FF09FF09FF09FF099009F6090B09C5 [Auth string]
-> 010E [Authenticate]
-> 88 [Status2Reg]
<- 08
-> 0930090001030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 02A8
-> 09300900090209A8010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 90F60BC5A88804008500B42EF0BB6AA8
-> 0930090101030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 60AA
-> 09300901096009AA010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 05FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
-> 0930090201030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 108B
-> 093009020910098B010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 90909090909090909090909090909090

Первый блок прочитан, два других - нет.
На данный момент есть подозрение, что требуется increment для таких вот задач. Но не факт!

UPD.
Не, не факт.

-> 0960090309FF09FF09FF09FF09FF09FF099009F6090B09C5 [Auth string]
-> 010E [Authenticate]
-> 88 [Status2Reg]
<- 08
-> 0930090001030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 02A8
-> 09300900090209A8010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 90F60BC5A88804008500B42EF0BB6AA8
-> 0A80 [Clear FIFO]
-> 0930090101030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 8BB9
-> 09300901098B09B9010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 00000000000000000000000000000000
-> 0A80 [Clear FIFO]
-> 0930090201030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 108B
-> 093009020910098B010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 00000000000000000000000000000000
-> 0A80 [Clear FIFO]
-> 0930090301030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 999A
-> 093009030999099A010C0D80 [Send Read block 00 to Card]
-> 89898989898989898989898989898989 [Read]
<- 000000000000FF078069FFFFFFFFFFFF

Работает. Перед каждой итерацией производим полную очистку буффера, видимо там что то есть. Странно конечно, после операции чтения 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

Поздновато, но попробуем что нить записать.
https://www.nxp.com/docs/en/data-sheet/ ... df#page=15
Write = A0h
Но не все так просто. https://www.nxp.com/docs/en/data-sheet/ ... df#page=24
Запись делится на две части. Я так понимаю сначала мы карте отправляем намерение записать что-то в определенный блок, и только затем отправляем это что-то второй частью. Каждая из двух частей сопровождается CRC суммой.
Продолжение следует.

Запись.
-> 09A0090109D609A0010C0D80 [Prepare write]
-> 89 [ACK]
<- 0A - успешно!
-> 0A80 [Clear FIFO]
-> 09FF09FF090009000900090009000900090009000900090009000900090009000103 [Calculate CRC для FF FF 00 x 14]
-> 0100 [IDLE] - просто делаю отмену команд отдельной строкой, дабы дать чуть больше времени на калькуляцию CRC
-> A2A1 [GET CRC]
<- 6119
-> 09FF09FF0900090009000900090009000900090009000900090009000900090009610919010C0D80 [Отправляем FF FF 00 x 14 на карту]
-> 89 [ACK]
<- FF (очень странный ACK - должен быть 0A) Надо разобраться.
-> 0A80 [Clear FIFO]
-> 0930090101030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 8BB9
-> 09300901098B09B9010C0D80 [Команда прочитать 01 блок]
-> 898989898989898989898989898989898989 [Читаем FIFO]
<- FFFF00000000000000000000000000006119

UPD
C ACK разобрался. Там как бы надо читать все 16 байт, в моем случае я записывал два байта FF FF.
Ответ - FFFF0AFFFF.. в общем все хорошо.

Завтра попробуем сменить ключ.

Меняем ключ.
В 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

-> 09600907090009000900090009000900099009F6090B09C5 [Формируем строку для авторизации]
-> 010E [Запускаем Cryopo1]
-> 09A0090701030100 [Calculate CRC]
-> A2A1 [CRC]
<- E0C5
-> 09A0090709E009C5010C0D80 [Готовим запись]
-> 89898989898989898989898989898989 [ACK]
<- 0A000000000000000000000000000000
-> 0100 [IDLE]
<- 01
-> 0A80 [Clear FIFO]
-> 09FF0900090009000900090009FF09070980096909FF09FF09FF09FF09FF09F10103 [Calcula
te CRC]
-> 0100 [IDLE]
-> A2A1 [GET CRC]
<- B306
-> 09FF0900090009000900090009FF09070980096909FF09FF09FF09FF09FF09F109B30906010C0
D80 [Write]
-> 89898989898989898989898989898989 [ACK]
<- 00000A00000000000000000000000000
-> 0A80 [Clear FIFO]
-> 0930090701030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- BDDC
-> 0930090709BD09DC010C0D80 [Read 00]
-> 898989898989898989898989898989898989 [Read]
<- 000000000000FF078069FFFFFFFFFFF1AABC

Теперь наш ключ 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. Правила доступа из него не складываются.

Суть такая.
4 бита управляют 4 блоками.
https://www.nxp.com/docs/en/data-sheet/ ... df#page=12

Если вы разобрались в этой таблице, то вы молодец.

Небольшая подсказка.
У нас три байта. 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 заканчивается. И начинается совсем другая история

Desfire EV1.

Пару пояснений.
В настоящий момент я не подписывал 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 у меня вроде как не хочет. ВРОДЕ! Не очень достоверная информация, не изучал особо. ИМХО в общем.

Так, первая Анти-коллизия возврашает нам
-> 0952010C0D87 [Send REQA]
-> 8989 [Read REQA]
<- 4403
-> 09930920010C0D80 [Anticol]
-> 8989898989 [Read UID]
<- 88 04 5E 6F BD
-> 0993097009880904095E096F09BD01030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- 0E60
-> 0993097009880904095E096F09BD090E0960010C0D80 [Select]
-> 898989 [Read SAK]
<- 24D836 - SAK

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

24D836 - SAK (Select AcKnowledge). Очень важная штука для понимания того с чем мы имеем дело.
Как им пользоваться описано тут - https://www.nxp.com/docs/en/application ... pdf#page=7

На сколько я помню 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.
Ну и так далее.

Так, нашел иллюстрацию в примерах на ГОСТ 14443


Делаем CL2
-> 010F113D2D302C002A8D2B3E148326701540 [Init]
-> 0952010C0D87 [Send REQA]
-> 8989 [Read REQA]
<- 4403
-> 09 93 09 20 01 0C 0D 80 [Anticol]
-> 8989898989 [Read UID]
<- 88 04 5E 6F BD
-> 09 93 09 70 09 88 09 04 09 5E 09 6F 09 BD 01 03 01 00 [Calculate CRC]
-> A2A1 [GET CRC]
<- 0E 60
-> 09 93 09 70 09 88 09 04 09 5E 09 6F 09 BD 09 0E 09 60 01 0C 0D 80 [Select]
-> 898989 [Read SAK]
<- 24 D8 36
******************************CL1 выполнили, теперь нам требуется произвести CL2 (команда 95 и 20 байт)
-> 09 95 09 20 01 0C 0D 80 [Anticol]
-> 8989898989 [Read UID]
<- DA 49 34 80 27
-> 0995097009DA094909340980092701030100 [Calculate CRC]
-> A2A1 [GET CRC]
<- A4E1
-> 0995097009DA094909340980092709A409E1010C0D80 [Select]
-> 898989 [Read SAK]
<- 20FC70

DA 49 34 80 27
Фиолетовым выделены 4 байта UID3 UID4 UID5 UID6, и его BCC 27.

И так, UID: 04 5E 6F DA 49 34 80

Теперь надо отправить RATS - Request for
Answer To Select
На что карта должна ответить нам ATS - Answer To Select
Вроде так - https://www.nxp.com/docs/en/application ... df#page=13

-> 0A80 [Clear FIFO]
-> 09E0098009310973010C0D80 [Send RATS]
-> 8989898989898989 [Answer]
<- 06 75 77 81 02 80 02 F0

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)
И много чего еще, но меня пока интересует базис.