-
Публикаций
4 785 -
Зарегистрирован
-
Посещение
-
Победитель дней
374
Весь контент Pavel
-
Волков бояться - в лес не ходить. Спросите в ответ: "Вам шашечки или ехать?"
-
Потому что нет никакой эмуляции 2.0 или не 2.0, протокол одинаков, считыватель видит метку по параметрам, и не сообщает, о, ты мне не нравишься. Нет, он продолжает работать и всё делать, как и при любой другой нормальной метке. И попытка открыть, откуда она должна взяться, если ещё даже криптоключи не вычислены? Захват данных это далеко ещё не ключ в открытом виде. Кроме того, нужно и 0 и 14 сектора эмулировать. Полный дамп загрузить в прибор, так что на стадии захвата данных нет никаких новых данных от считывателя, чтобы его отличать. тогда я не понимаю как и выше вопрошающий, каким образом выявлялся фильтр Zero и ОТР , потому что мне казалось , видимо не верно , что прибор представлялся меткой данного протокола и пытался получить ответ от панели , если в ответ была тишина - значит такой формат фильтруется. Мы все прекрасно понимаем , что протокол заготовок чем-то отличается от протокола исходного классика , метки принимают какие-то недокументированные команды еще какие-то мелочи , фильтр оперирует именно этими отличиями. нет , ну пусть прибор получит uid , вычислит ключи , а перед предложением записать , попытается открыть дверь в разных режимах , чтобы не пороть заготовку , которая точно не сработает я так понимаю , раз 3.0 появилась , вы знаете по каким параметрам выявляется 2.0 и сэмулировать их труда не составляет Как у Вас всё просто. Еще раз повторюсь, что перед тем как что-то эмулировать и пытаться открыть нужно провести расчет ключей на телефоне и загрузку их в прибор и это все совершенно не молниеносно делается и не прибор вычисляет ключи, а смартфон. Далее, нужно делать рассчёт криптоключей для второго сектора, а это минут 5. Далее, нужно оба дампа загружать в смкей на эмуляцию, а оба нельзя сейчас загружать в смкей, он эмулирует один сектор. Нужно все переделывать. И приложение. И прошивку. И результата все равно не будет, потому что Вы просто будете периодически получать неправильные ключи, тыркаться, не понимать, что не так. Зеро и ОТР1 отличить можно было, ОТР2 не отличается ни по каким командам от оригинала, нечего там эмулировать как-то иначе.
-
Потому что нет никакой эмуляции 2.0 или не 2.0, протокол одинаков, считыватель видит метку по параметрам, и не сообщает, о, ты мне не нравишься. Нет, он продолжает работать и всё делать, как и при любой другой нормальной метке. И попытка открыть, откуда она должна взяться, если ещё даже криптоключи не вычислены? Захват данных это далеко ещё не ключ в открытом виде. Кроме того, нужно и 0 и 14 сектора эмулировать. Полный дамп загрузить в прибор, так что на стадии захвата данных нет никаких новых данных от считывателя, чтобы его отличать.
-
Зашифровать базу то можно, но ведь её нужно тогда "поставить" на устройство другое и запустить - ввести пароль. При этом экспорт не должен отдавать базу в уже открытом виде. Других идей пока не приходит. Но по 1 коду слить можно, даже через дубликатор или просмотр, хоть это и довольно утомительно будет.
-
Потому что так же нельзя это определить
-
А разве у них разный протокол? Mifare, он у всех одинаков.
-
Отличить, есть там или нет фильтр OTP2, нельзя.
-
"По просьбам в личке" просьба скидывать ссылки и файлы в лички. Домен уже разок был в бане у яндекса из-за ссылок на подозрительные, по их мнению, exe файлы.
-
Да, примерно так. У ПК скорость процессора это гигаГерцы, да еще и несколько ядер. Утилита NFC/iKeyBase раскидывает расчет на все ядра. А у контроллера 180 MHz, да ещё и всё скоростью работы памяти ограничено дополнительно, там большой массив данных, не один только контроллер занимается вычислением. Поэтому при автономном расчёте время соответственное. По этой же причине любые другие аппараты, все требуют внешний ресурс в виде ПК или смартфона.Если есть рядом Пк, то криптоключ можно рассчитать быстрее, запустив iKeyBase. Что обнаружите - лучше на почту скидывайте. Вышенайденные баги отметил, будем исправлять.
-
Расчет криптоключа это не постоянная долбежка метки. Это получение набора данных, затем вычисление возможных вариантов, потом только их проверка, поэтому и нелинейно идет прогресс, т.к. заранее нельзя знать, как быстро появятся результаты вычислений, все зависит от исходных наборов, которые удалось получить от метки. Отсюда и отсутствующие предупреждения, если метку убрали, прибор увидит это только когда начнет проверять результаты расчетов. По скорости в автономном конечно медленее чем на ПК. Основная сложность именно в вычислениях, у ПК скорость процессора и объем оперативной памяти куда больше. А тут прибор даже на часы не отвлекается, считает) Потому, что этот файл содержит доп. данные, какой сектор считан, какой нет, т.е. можно сохранить только 1, иил только 1 и 14 сектор, и при вызове на запись только этот сектор и будет показан/записан. Конвертировать не сложно, я думаю, можно будет это организовать. По вайфай - исправим. По звукам после праздников уточню как менять.
-
Если правильно помню, то нужно создать на флешке прибора папку AUDIO в которой подменить штатные звуки, оставив то-же имя. Во вложении штатные звуки. AUDIO.zip
-
Комментарий где, у адреса или ключа?
-
Просто нажать записать полный дамп, и всё.
-
Сколько считалось, все и пишите
-
Кончились, убрали пока. Будут в середине-конце января
-
Описание добавил, инструкция более полная через день-два.Мелкие недоработки пока находим, устраняем, осталось с ПК и моб. приложениями отладить, а так, если очень нужно, то в наличии они есть, можно или в комментарии к заказу указать или в магазинах в Москве взять.
-
Только полезное:Версия v2.2.28 (Андроид): * исправлено отображение настроек ключа TM01A для USB устройств (3R, 5R, 5RF); * добавлена поддержка устройства TMD-5R (USB); * добавлена поддержка устройства TMD-3R (USB); * исправлен ряд ошибок, приводивших к крашу приложения.
-
Добавили описание: Версия 1.37 (23.12.19): Небольшие правки в выводимых текстах и исправления мелких ошибок. Например, показ уведомления "Записан" или "Ошибка записи" (при записи Mifare), будет отображаться пока заготовка не убрана. Выровняли положение этих уведомлений, теперь они по центру. При чтении Mifare c 7и байтным UID прибор выводил только 4 на экран, хотя в архиве отображалось как 7. В данной версии это исправили. Добавили возможность загрузить в прибор весь дамп Mifare 1K (все 0-15 сектора за раз), после чего прибор может записывать заготовку сам, без программы, показывая прогресс на экране. То есть, приложению больше не нужно будет отправлять на запись каждый сектор отдельно. Осталось добавить это в само приложение, ближайшее время оно будет реализовано на ПК версии и затем на мобильных устройствах. При этом старый, "посекторный" вариант записи никуда не делся и будет работать как и прежде.
-
Верните расширение, которое удалил андроид или сохраните сначала файл базы к себе на телефон в папку, а потом уже пересылайте его.
-
Странно, ок, перепроверим еще разок.
-
Перед захватом менять режимы. Простой 2-10, или Сложный 2-10. Будет захватываться другой криптоключ, и какой-то из них будет верный. Последняя страница инструкции, последний пункт. Заготовки MF2.0, OTP не подвержены взлому через "поиск", он будет идти бесконечно. Если считать оригинал, то криптоключ уже будет известен прибору. Поэтому сделанная заготовка считается.
-
Нет, даже если карат объекта одна, замену UID нельзя делать, считыватель с такой прошивкой проверяет, чтобы UID в блоке 0 совпадал с данными в блоке 1, если подменить, он даже реагировать не будет. Приветствую! А для каких типов ключей или домофонов UID подменять тогда можно? Для считывателей, которые не имеют фильтра и работают с 1 блоком.