iKey Express: рабочие версии

[iKey Android 88]

В 15.04.2021 в 18:10, k777-Slava сказал:

Да он очищает 0-й сектор только крипто-ключи сам же UID не трогает. Понятно что в зеро его трогать и нет смысла, за исключением когда, к примеру если считать ультролайт и записать случайно на зеро, то заготовка становится не пойми чем, но при этом она живая, но чтоб её оживить нужно восстановить структуру 0-ого сектора, а очистка этого не делает, но возможность именно восстановить реально существует.

Не могу сказать ничего дельного по этому поводу. По идее, на зерохах кривые условия доступа могут запретить на уровне заготовки перезапись страниц, поэтому, скорее всего, это не возможно. Но это уже скорее вопрос по прошивкам. Если устройство сможет перезаписать метку с неправильными условиями доступа - то это возможно. Но, это маловероятно.

В 15.04.2021 в 18:25, k777-Slava сказал:

Хорошо SMKey не уведомляет о смене режима работы и ладно, но при нажатии на чтение можно показывать запрос о типе ключа что будет считан а не ставить по умолчании Texkom? Я понимаю у кого то больше Texkom используется у кого то другие типы ключей как у нас в регионе, по этому удобней когда есть возможность самому назначить тип ключа или к примеру, чтоб программа сама запоминала последний считанный тип ключа и оставалась по умолчании на этом типе ключа и в дальнейшем чтоб каждый раз не матюкаться когда нажимаешь чтение, а он не читается потому что там Texkom стоит а не MF sector.

У SMKey нет единого режима чтения ключей, т.е. чтобы считать Mifare надо сам прибор перевести в режим чтения Mifare, для iCode - перевести в режим чтения iCode. Можно реализовать, к примеру, возможность ручного определения ключа в списках ключей, но это усложнит логику приложения, так как придется этот список где-то хранить, рисовать экран для ручного управления положением ключа и т.п. Если Вы убедите Павла, что этот функционал нужен, то сделаем.

2 часа назад, Ivan40 сказал:

А можно тогда сделать поиск (что бы вбивать в карту адрес и оно само находило) или хотя бы что бы можно было геоданные вставить с другого приложения.

Можно. Мы можем использовать API геокодирования от Google и автоматически генерировать адреса из данных геолокации. Но между картами Google и Yandex есть расхождения, поэтому могут быть ситуации, когда на Yandex картах дом есть, а на Google картах дома нет и в итоге мы не сможем определить адрес. Но да, это можно сделать на API Google.

[iKey Android 88]

Релиз iKey Express 1.2.3 (устанавливать обновлением поверх версий, полученных из Google Play).

Релиз iKey Express Pro 1.2.3 (устанавливать вместо версий, полученных из Google Play, приложение подписано другим сертификатом).

 

Список изменений 1.2.1 -> 1.2.3:

Изменения:

• добавлена эмуляция ключей для устройства SMKey (Texkom, iCode, Faktorial, MFSector);
• добавлена эмуляция Mifare1k для устройства SMKey (версия устройства 2.13 и выше);
• добавлена функция генерации Mifare дампа из UID;
• упрощен экран поиска и подключения к устройствам;
• изменена сортировка устройств поблизости, теперь ближние устройства в списке находятся ближе дальних;
• режим создания криптоключа продублирован в меню работы с устройством для TMD-5S;
• теперь при подключении TMD-5S происходит синхронизация ключей с дампом;
• исправлена ошибка, приводившая к вылету приложения: создать закладку из записи БД -> назад -> создать закладку из записи БД;
• исправлена ошибка некорректного отображения режима записи больших ключей для TMD-5S (экран дубликатора);
• исправлена ошибка, приводившая к тому, что проверенные стандартные криптоключи игнорировались при поиске криптоключей для закрытых секторов;
• кнопка получения дампа для SMKey перенесена в меню "три точки" (экран дубликатора);
• добавлена кнопка получения дампа для TMD-5S (экран дубликатора, меню "три точки");
• изменен формат iCode, теперь в приложении можно задавать флаги финализации страниц дампа;
• изменен формат Pac, теперь размер ключа составляет 16 байт;
• добавлена поддержка базы iKey версии 22;
• добавлен сброс дампа ds1996 для устройства iKey (в FF или 00);
• исправлено зависание сервиса Smart Ключ при попытке подключения сервиса к поставщику NMEA данных;
• изменено название ключа MF Ultralight на Ultraligh 16;
• добавлен ключ Ultraligh 20;
• добавлен ключ Ultraligh 41.

[Ivan40 0]

 

6 минут назад, iKey Android сказал:

Можно. Мы можем использовать API геокодирования от Google и автоматически генерировать адреса из данных геолокации. Но между картами Google и Yandex есть расхождения, поэтому могут быть ситуации, когда на Yandex картах дом есть, а на Google картах дома нет и в итоге мы не сможем определить адрес. Но да, это можно сделать на API Google.

Да было бы хорошо, что бы ещё можно было самому написать координаты. 

[Бамбаклян 70]

21 минуту назад, iKey Android сказал:

• добавлена функция генерации Mifare дампа из UID;
• теперь при подключении TMD-5S происходит синхронизация ключей с дампом;

Можно пожалуйста чуть по подробнее насчёт этих пунктов? 

Генирация mifare дампа из uid это как? 

И при подключении какие ключи с каким дампом синхронизуются? 

Спасибо! Завтра обновлюсь, просто завтра трудный день нужен стабильный smkey online, а тут в программе куча всего нового добавлено не дай Бог глюканет в самый не подходящий момен..

[iKey Android 88]

5 минут назад, Бамбаклян сказал:

Можно пожалуйста чуть по подробнее насчёт этих пунктов? 

Генирация mifare дампа из uid это как? 

И при подключении какие ключи с каким дампом синхронизуются? 

Спасибо! Завтра обновлюсь, просто завтра трудный день нужен стабильный smkey online, а тут в программе куча всего нового добавлено не дай Бог глюканет в самый не подходящий момен..

Часть пользователей просили возможность сохранения uid Mifare в MFSector с ключами по умолчанию и этим UID в первом блоке. Вроде как часть домофонов работает только по UID и нет необходимости в подборе ключей и считывании всего сектора. Мелкая автоматизация.
В случае, если сейчас прибор в режиме записи ключа с дампом, программа при подключении получает этот дапм и отображает в экране дубликатора. Просто синхронизация состояния клиента и устройства.

[Бамбаклян 70]

16 минут назад, iKey Android сказал:

Часть пользователей просили возможность сохранения uid Mifare в MFSector с ключами по умолчанию и этим UID в первом блоке. Вроде как часть домофонов работает только по UID и нет необходимости в подборе ключей и считывании всего сектора. Мелкая автоматизация.
В случае, если сейчас прибор в режиме записи ключа с дампом, программа при подключении получает этот дапм и отображает в экране дубликатора. Просто синхронизация состояния клиента и устройства.

Всё, ясно! Спасибо большое! Просто думал, по uid создаётся весь рабочий ключ) а то что только по uid некоторые домофоны работают, это подтверждаю, только делал это всегда просто через tmd5s напрямую через меню и всё ок.

 

Сегодня делал копию mifare через поиск криптоключей и после того как ключи нашёл, автоматом прочитал метку, удобно! 

Раньше по моему этого не было, находил ключи, потом выбирал прочитать метку с найденными ключами.. Короче, удобно! Спасибо! 

[Jason 7]

Здорово. 

Только зачем этот пункт сделан первым в меню для адреса? 

 

И логичнее было бы по нажатию на адрес в списке переходить к списку ключей на адресе? 

Функцию эмуляции протестирую в скором времени

[iKey Android 88]

В 17.04.2021 в 18:54, Jason сказал:

Здорово. 

Только зачем этот пункт сделан первым в меню для адреса? 

 

И логичнее было бы по нажатию на адрес в списке переходить к списку ключей на адресе? 

Функцию эмуляции протестирую в скором времени

Попытка усидеть на двух стульях. Для пользователя эмулятора iKey будет удобным отправить на устройство приоритетный код одним нажатием на адрес. Эта логика масштабируется на TMD-5S, так как там нет функции эмуляции, логичным будет назначить на нажатие на адрес отправку кода на запись. В случае же SMKey - главное предназначение этого устройства - сниффинг, второе - дубликатор, третье - эмулятор. Поэтому на нажатие мы повесили отправку на запись приоритетного кода, второе по значимости действие (эмуляцию) мы повесили на первый пункт контекстного меню, ну а просмотр связных с адресом ключей, по остаточному принципу - на второй пункт контекстного меню.

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

1. это лишние трудозатраты и неочевидные баги;

2. это неочевидно для конечного пользователя с двумя и более типами устройств, донести до пользователя, что поведение разнится для разных устройств  - задача, которая ложится на техподдержку, самого пользователя и на программистов.

Как вариант - мы можем добавить настройку "Выбрать поведение при нажатии на элемент списка 'адрес'", но это, опять же, лишние трудозатраты, лишние баги, лишняя головная боль при техподдержке, а самое главное, это настройка будет находиться где-нибудь по пути "Главное меню" -> "Настройки" -> "Настройки отображения", до которого дойдет от силы 5% пользователей.

Это развернутый ответ. Краткий: как сделать так, чтобы действие при клике на элемент списка "Адрес" было максимально удобным для всех категорий пользователей, мы пока не придумали :)

[hackerman 18]

Поддержу мысль переходить к списку ключей при тыке на адрес. Абсолютно всегда если на адресе больше 1 ключа я жму показать ключи. Крайне неудобно что это не делается при тыке в адрес. Если на адрес больше одного ключа значит они чем то отличаются и наобум эмулировать один нельзя пользователь захочет выбрать определённый. Если можно эмулировать любой из доступных то 99.9% второй ключ на адрес будет отсутствовать. У меня есть в базе записи шарага с картами "болеющих" сокурсников есть адрес свои вездеходы где один и тот же код в виде тм емарин и мифаре. И нет в таком случае не похуй какой ключ от адреса использовать нужен конкретный. У меня вообще ни разу не было ситуации когда на адресе больше 1 ключа и при этом подойдёт любой из них. Если у меня уже есть ключ от адреса я просто дополнительный не храню. Есть адрес с названием 1140бе он максимально близок к "похеру какой эмулировать" но даже там разные коды из за 5-8 байтовых домофонов. Ну а если показывать нечего ключ один то просто эмулируем его сразу. Не давать пользователю выбрать ключ а отправлять первый по списку очень плохая практика

[hackerman 18]

Самое нормальное сохранить пункт ключи на адресе но при тыке в адрес показывать ключи. А при тыке в ключ уже эмулировать. Если ключ один на адрес при тыке сразу эмулировать все равно пользователь выберет именно его а для редактирования ключей в адресе с 1 ключом как раз будет пункт ключи на адресе

[Pavel 582]

Для этого есть приоритетный ключ. Отправляется не любой, а именно он. И для раскидывающего рекламу не нужно каждый раз видеть список ключей, ему нужно оперативно открыть дверь одним нажатием.

[hackerman 18]

Двойной тык по адресу решает проблему. Точно так же будет отправлен самый верхний ключ. А для всех остальных страдание. И откуда у спамера несколько ключей от одного подъезда? Это почти не имеет смысла

[hackerman 18]

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

[Pavel 582]

Только что, hackerman сказал:

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

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

[hackerman 18]

Я смотря на работу рекламщика совершенно не понимаю зачем нужно каждый раз искать адрес вида вездеходы окраина целиться в три точки попадать в пункт ключи и пробовать уже ключи по списку. 2 лишних действия х2 по времени. И совершенно не понимаю как у рекламщика может быть сразу два ключа от одного адреса. Если адрес каким то чудом не открывается вездеходом рекламщик идёт в квартиру к тому кто заказал газеты/доставку копирует ключ и забивает болт на коллекционирование ключей из всех квартир если есть один рабочий. Не будет рекламщик искать у кого скопировать второй ключ от того же подъезда а свалить довольный пока пизды не дали

[Jason 7]

1 час назад, iKey Android сказал:

Как вариант - мы можем добавить настройку "Выбрать поведение при нажатии на элемент списка 'адрес'",

Думаю, это было бы лучшим вариантом

[Jason 7]

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

[Pavel 582]

1 час назад, hackerman сказал:

Я смотря на работу рекламщика совершенно не понимаю зачем нужно каждый раз искать адрес вида вездеходы окраина целиться в три точки попадать в пункт ключи и пробовать уже ключи по списку. 2 лишних действия х2 по времени. И совершенно не понимаю как у рекламщика может быть сразу два ключа от одного адреса.

Именно, зачем ему целиться в три точки и выбирать из списка? ему нужно рабочий ключ и всего один. А в базе их окажется несколько, потому что он предыдущие нерабочие не удалил, а новый добавил.

[hackerman 18]

Ну хз. Единственный способ при котором требовался уникальный ключ для адреса который не районка а ключ жильца это замена нормального домофона на бевард. Один хрен старый ключ удалять. Не было в моей практике ещё ни одного случая чтобы ключ привязанный к адресу переставал работать. Даже если панель пиздят ставят её или з5р в автосборе. Я долго ходил по подьездам правда в качестве обслуги а не спама и было немало залоченых элтис булыжников с уникальным ключом. Всегда ключ один на адрес. Зато есть в текущих базах 100500 адресов вида

шарага

вездеходы

свои

Район такой то

Контроллер адрес такой то (5 ключей добавление удаление автосбор обнуление че то ещё)

 

В случае шараги/работы или китайского скуда очень важно не затупить и с 1 попытки ткнуть чем надо а не тем что первое в списке. Районки тоже разные хоть и называются все одинаково. Или мне создавать почти сотню адресов с 1 ключом вида центр разное 1 центр разное 2... ? 

А как быть с адресами вида жк такой то где один тм емарин и ммфаре каждый открывает все чем он может прочитаться но дофига умная программа естественно не может знать какая версия ключа от одного и того же адреса мне нужна. А ещё на территории солянка из калиток парковки технических помещений и отсечек это к плану создать все 10 подъездов на адресе и записать дубли если подъезды открываются одним ключом

Из 150+ адресов у меня всего 4 с одним ключом. Из 150 всего один адрес похеру каким ключом тыкать он из себя представляет список всех ключей подьезда из з5р. Остальные 150 адресов содержат больше одного ключа и если ключ не один значит не похеру каким тыкать и они чем то отличаются. Один хрен не получив нужный результат (с вероятностью 90% кстати) придётся делать 2 лишних действия и ручками выбирать ключ из адреса так почему бы это сделать сразу не через жопу?

[Aprel 28]

У меня база состоит из названий улиц. У уж в них  дома, подъезды, комментарии. 

В принципе мне удобно.  Ключ выбираю по приоритету. А если необходимо, открываю ключи на адресе. 

В Keibase удобнее переключаться между  загруженными базами. Вот бы в Kei Express  реализовать аналогично. 

[Jason 7]

Когда пытаешься отправить на эмуляцию ключ типа Mf Sector, возникает ошибка

 

Кстати, можете сделать для режима эмуляции подсветку при начале обмена данными со считывателем, как во время захвата? 

Иногда приходится долго держать SMKey около считывателя, прежде чем домофон среагирует, и не понятно, из-за чего он не реагирует - не тот ключ или не то расстояние

[Jason 7]

16 часов назад, hackerman сказал:

  остальные 150 адресов содержат больше одного ключа и если ключ не один значит не похеру каким тыкать и они чем то отличаются. Один хрен не получив нужный результат (с вероятностью 90% кстати) придётся делать 2 лишних действия и ручками выбирать ключ из адреса так почему бы это сделать сразу не через жопу?

А в чем разница? В том, в какую квартиру будет отзвонка?

[hackerman 18]

Ещё раз. Разные ключи. Не дубли одного и того  же с абсолютно одинаковыми правами но с разным кодом а реально разные засунутые в один адрес. 10 вездеходов одной конторы 10 ключей от одного района без привязки к конторам или солянка из емарина тм мифаре вездеходов в пределах одного жк с кучей отсечек секционных дверей с парковкой мусорками и прочими объектами которым невозможно назначить осмысленный адрес только свалить в кучу с подписью жк такой то. С подъездами вообще проблем нет уникальных ключей с конкретным осмысленным адресом у меня два остальное вездеходами открывается. Если ключей на адрес больше одного значит они РАЗНЫЕ!!! В три подъезда прописан один ключ в 7 другой оба свалены в один адрес вместо создания дублей с адресами. Или создавать два адреса вида жк кукуево 1 жк кукуево 2? Если здравый смысл не победит придётся реально создавать 150 улиц с названиями вида приморский 1 приморский 2 приморский 3 приморский 4.... с одним ключом в улице чтобы не приходилось остальные ключи доставать из какой то задницы просто потому что авторы считают что если на адресе больше 1 ключа нужен только 1 остальные никто никогда не будет использовать. Или предлагается взять основные 50 районок и создать все 15 000 подьездов с привязкой нужного из 50 кодов к подъезду? С тем же успехом можно создать 20 000 адресов своего города с пригородом с кодом 1140бе но смысла будет немного

[iKey Android 88]

1 час назад, Jason сказал:

Когда пытаешься отправить на эмуляцию ключ типа Mf Sector, возникает ошибка

 

Кстати, можете сделать для режима эмуляции подсветку при начале обмена данными со считывателем, как во время захвата? 

Иногда приходится долго держать SMKey около считывателя, прежде чем домофон среагирует, и не понятно, из-за чего он не реагирует - не тот ключ или не то расстояние

1. Проблема есть, эмулируйте пока через просмотр ключа, там работает. Сделаем хотфикс.

2. Уточню, скорее всего возможно.

[iKey Android 88]

Релиз iKey Express 1.2.4 (устанавливать обновлением поверх версий, полученных из Google Play).

Релиз iKey Express Pro 1.2.4 (устанавливать вместо версий, полученных из Google Play, приложение подписано другим сертификатом).

 

Список изменений 1.2.3 -> 1.2.4:

Изменения:

• исправлена ошибка эмуляции MFSector при отправке из контекстного меню списков БД/Закладок (SMKey);
• исправлена ошибка переключения доступных действий при смене ключа на экранах редактирования закладки/ключа (SMKey);
• исправлен вылет при ситуации, когда ОС не отдает объект адаптера Bluetooth.