Pavel

Основное, что как это может помочь обычному пользователю, было в описании обновления 1.79: В опции добавлена функция тестирования ключей Dallas. При копировании ключей для домофонов Vizit можно сразу определить, оригинальный или китайский ключ у клиента и решить, нужно или нет использовать специальную заготовку для Vizit (например RW99), или можно обойтись обычной rw1990. Если пишет ОD - да, значит ключ не китайский. Это уже знак, что делать лучше на что-то для Визита, RW99 например. А если пишет OD нет, делать можно на что угодно. Остальные параметры из документации на чип. Например, tPDL это время импульса, который выдает ключ, показывая, что он на шине. Если у вас копии работают через одну на одном и том же домофоне (или 1 из 10), то попробуйте подобрать заготовки с близким к оригиналу значением. Или посмотреть в чем отличие у рабочей и нерабочей копии и поискать заготовки из кучи с теми же параметрами, что у той, которая работает. Так же год-два назад массово везли китайцы сюда очень плохие RW1990, у которых этот импульс был около 80-90 мкс, тогда некоторые домофоны просто не видели такой ключ. Нормальные ключи обычно имеют длительность около 120-160 мкс. Так что, при покупке "по дешевке", есть смысл проверить, что это партия не из отбраковки, проверив этот параметр. И чтобы Петр опять тираду сухих, бесполезных данных на 2 страницы не накатал ниже, отмечу основное: по документации допустим tPDL 60-240, но в реальности программисты некоторых домофонов установили свои, более строгие рамки. FAM это Family Code, последний байт кода. Он определяет тип ключа. Есть разные ключи даллас.

Да, есть такое, только сегодня заметили. На работу и копии не влияет, но с толку сбивает. Исправили уже в новой сборке.

На самом ключе написан всегда UID. Если не работает, то пробуйте писать байты, читая их справа налево. вместо 12 34 56 78 - 78 56 34 12.

Ответа не было, т.к. все работает, нереальное описание проблемы, которое к прошивке отношения не име Почему UID другой - потому что копировали сектор, вместо копирования UID. Причины, почему нельзя так копировать для бевардов смотрите в описании ролика https://youtu.be/DpgPxHQBYs4

Пишите на UL-5.

Добрый день. Надеемся, что появятся к концу месяца. Сейчас может разве что по сусекам, пару десятков.

Считайте чистую метку, проставьте в правой части таблицы текущие криптоключи А, которые сейчас в стираемой метке, нажмите записать.

Ошибка авторизации означает, что текущие криптоключи в метке не дефолтные, метка не очищена и не даст записать новые данные пока действительно ее не очистите или не укажете правильные криптоключи (в правой части программы указать текущие криптоключи и установить галку на классик).

Берите ОТР первой версии, записывайте 09 в 6й байт, получите сак 09

Судя по всему, вы смотрите на UID который считался при чтении сектора, иначе (при копировании только уид) тип метки был бы сразу показан. В некоторых чипах, например в Plus работающих в режиме классик, в самом дампе могут быть другие данные в блоке 0, не совпадать с UID. Соответственно, при записи считанного сектора 0 на заготовку вы получите UID из тех данных, что были в блоке 0, а не тот, который реально был оригинале. Таким образом, копировать дом ру нужно через функцию копирования уид, а не чтения-записи сектора. Если же копируете через чтение сектора, то проверяйте потом уид, чтобы и в оригинале и в сделанной копии он совпадал.

Может там был 7 байтный UID, не ясно, как делали. Через чтение сектора или через копирование UID. Проверяйте тип оригинала. По типу будет ясно, был ли это вообще классик.

Там метки дезфаер+классик, с sak28 и проверка устроена не только по sak, исп. функция дезфаера.

В заготовках MF OTP (не 2.0 вы можете задать SAK только через 6й байт, прописав туда 09, отдельно sak ни в каких заготовках не задается (мы таких не знаем). Но зачем это? Ридеры не хранят, не передают в систему SAK или содержимое 6-го байта.

Старые прошивки считываетелей читают UID, проверяют криптоключ и считыв информацию из блока 1 выдают ее в домофон, который уже проверяет есть ключ в базе или нет. Можно было подставить уид от ключа клиента в блок 1, прописать криптоключ верный для реального UIDа метки и все работало. После того, как это все стало использоваться в приборах (отправляем любой рабочий дамп 0 сектора на запись, затем функция изменить/Uid/блок 1, считываем UID клиента), вышла новая прошивка, в которой считыватель проверяет, чтобы UID из блока 0 совпадал с данными в секторе 1 и если они не совпадают, метка фильтруется. Хоть классик, хоть что. Поэтому эмуляция перестает работать. Можно встретить оригиналы которые работают, при этом данные в блоке 1 не совпадают, но при этом там весь блок 1 (и вроде даже блок 2) занят какими-то данными, из которых считыватель понимает, что это не подмена UID, а реально настоящий ключ. Тогда она не фильтруется, не смотря на то, что UID в блоке 1 отличается. Как они там формируются никто не знает. Если делается копия 0го (или 0+14 сектора), в котором дублируется UID в блоке 1, то рекомендуется удалять все данные в блоке 1 и 2, заменяя их 00, оставляя только первые 4 байта (UID). Тогда полный дамп не требуется. Если данные есть, то считыватель может требовать и полную копию.

При достижении полного заряда ток зарядка уменьшает, потом отключает (светодиод начинает гореть постоянно). Временами, конечно, она снова включает заряд. Может вы попали на такой период. Просто проверьте еще раз. Если зарядка не начинается когда ключ заряжен на 100% это нормально. Если он разряжен, а заряд не пошел, то приподнимите на пару мм ключ, и когда заряд пойдет (замигает светодиод), опустите на разрядник.

Нет

Этим https://ikey.ru/32150-ds9490b/

1) Мы же пишем не конкретно ПИК метку, а свою. И использовать чужие названия нельзя. 2) Архив в тмд-5s защищен паролем, эта функция активна только для тмд-4.

Оказалось, это баг в прошивке прибора. С 2.28 версии сделали, чтобы не нужно было убирать метку от прибора на первом шаге при работе функции копия на заготовку, для этого добавилась новая команда. А программа начала использовать эту функцию с 1.6.0 версии. Проверяли на одной и той-же метке и не заметили. Получилось, что проявляется баг, только если обновить и программу и прошивку. По тревоге все силы были подняты, ближайшее время сделаем обновление прошивки. Пока как и сказали, можно сначала считать UID вручную, потом уже запустить функцию.

Писаться будут, да.

Простецкие проги пишут обычно только протоколом предназначенным для Зеро. А МФ3 пишется как классик. А настоящий классик не подразумевает записи UID и штатные проги его не пытаются писать. Собственно, что нужен или спецсофт или программатор даже в описании заготовки есть.

Конечно будет скидывать, само собой не исправится. А чаще стал глючить онлайн, ну так это понятное дело, сейчас каждый и без нужды запускает без разбору поиск продвинутый и 30 минут ждет, пока все сектора рассчитаются. Раньше 3,5 человека в день заходило, а сейчас людей куда больше пользуется, а для каждого харднестеда несколько ядер и десяток гб оперативы нужно. Приложение в этом никак не участвует, оно только ждет ответ.

По падению на локальном поиске открывайте настройки, включайте режим отладки. После падения отправляйте лог на почту. Расчет на сервере - причин может быть множество. Мог пакет не дойти до сервера из-за интернета. Мог ответ от сервера не дойти до телефона, приложение, ждет. Таймер в приложении есть, происходит или повторная отправка или уведомление о сбое.

Вот ошибка 8 это нормально. Просто сервер загружен. 1-5 минут и все будет ок.

Сомневаюсь, что дело в настойчивости. Уже давненько iL по другому стал шифровать метку, возможно специально, чтобы не работало через сервер. Функции на сервере и эти функции в приложении не менялись уже очень давно, пожалуй, с момента реализации.