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

[iKey Android 78]

36 минут назад, Мишаня сказал:

Здравствуйте, вопрос по поводу шифрования базы данных после последнего обновления ( может такое было в предыдущих версиях, я не заметил, как только добавили эту фичу, все работало ок):

1. База данных шифруется и имеет вид «my_base_encrypted.ib2», всё ок.

2. Без ключа шифрования она не открывается - выдает ошибку 

3. Когда эту "зашифрованную базу" отправляешь кому то по мылу/месенджеру, то она меняет вид на "123456.ib2"

 4. В экспрессе ее по-прежнему не открыть без ключа. В ikeybase на андроид тоже не открывает. 

А вот для ПК (2.38) версии открывает, показывает ошибку ( неподдерживаемая версия базы: 0.) , но после нажатия "ок" этой базой можно спокойно пользоваться и редактировать 

Вопрос! Можно ли это исправить? А то не хочется 2500 ключей кому то подарить)))

Проверил, все шифруется ок. Интересует пункт 3: каким образом это происходит?

[Мишаня 0]

9 часов назад, iKey Android сказал:

Проверил, все шифруется ок. Интересует пункт 3: каким образом это происходит?

Из корневой папки експресса, берём шифрованную базу вида «my_base_encrypted.ib2», далее жму "поделится", выбираю, к примеру Яндекс диск (тоже самое происходит с месенджарами), и туда она уже загружается как "123456.ib2". далее открываю эту базу на ПК и можно работать без всяких шифров и паролей))

[Pavel 534]

3 часа назад, Мишаня сказал:

Из корневой папки експресса, берём шифрованную базу вида «my_base_encrypted.ib2», далее жму "поделится", выбираю, к примеру Яндекс диск (тоже самое происходит с месенджарами), и туда она уже загружается как "123456.ib2". далее открываю эту базу на ПК и можно работать без всяких шифров и паролей))

Да не бывает такого, у вас Андроид или посылает левый, старый файл, где-то в системе хранящийся или Вы в папке яндекса забираете старый файл. В шифрованном фале хаотичный набор байт, из которых ничего не прочесть. Прога не создает никаких 123456, в ней этого вообще не заложено. Ну а судя по описанному алгоритму программа вообще никакого отношения не имеет к проводимым действиям, никак не участвует в пересылке.

[Мишаня 0]

9 минут назад, Pavel сказал:

Да не бывает такого, у вас Андроид или посылает левый, старый файл, где-то в системе хранящийся или Вы в папке яндекса забираете старый файл. В шифрованном фале хаотичный набор байт, из которых ничего не прочесть. Прога не создает никаких 123456, в ней этого вообще не заложено. Ну а судя по описанному алгоритму программа вообще никакого отношения не имеет к проводимым действиям, никак не участвует в пересылке.

Ок, я попробую видео сделать, всего процесса, но только позднее

[Jason 9]

Недавно хвалил процедуру подготовки классик под прописку. Оказалось, поторопился... Сегодня пользовался ей. Подготовил три штуки - все окей. Процедура сработала нормально, не пришлось ничего копировать и вставлять руками. Но потом взял записанную ранее (и предварительно очищенную) заготовку OTP 2.0. Подношу ее к прибору, потом делаю захват данных, жду, пока рассчитаются ключи... И получаю сообщение: данные содержат ключи только для 14-го сектора. (Или как-то в этом роде, не помню точный текст). Пытаюсь ещё несколько раз, Подношу Smkey на разное расстояние и с разной скоростью - все время это же сообщение, хоть ты тресни. 

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

А на программе Ikeybase все получилось.

Сегодня был и 14-сектор тоже - но ключи были рассчитаны для обеих секторов. 

Программы, когда обе стоят на одном устройстве, могут конфликтовать друг с другом? 

Может, не доработано кеширование захваченных данных? Или это не баг, а фича: чтобы процедура не срабатывала для UIDов, присутствующих в базе? 

[Pavel 534]

25 минут назад, Jason сказал:

данные содержат ключи только для 14-го сектора. (Или как-то в этом роде, не помню точный текст). Пытаюсь ещё несколько раз, Подношу Smkey на разное расстояние и с разной скоростью - все время это же сообщение, хоть ты тресни.

Если есть сомнения в программе, то получив данное сообщение открываем последние захваченные данные и смотрим, что захватилось.

[Jason 9]

В 05.03.2021 в 23:23, Pavel сказал:

Если есть сомнения в программе, то получив данное сообщение открываем последние захваченные данные и смотрим, что захватилось.

Захватились ключи только для нулевого сектора, как и положено на считывателе с тремя линиями. 

[iKey Android 78]

В 07.03.2021 в 14:52, Jason сказал:

Захватились ключи только для нулевого сектора, как и положено на считывателе с тремя линиями.

 

Разобрались, скоро будет обнова (завтра вечером прошка/послезавтра с утра для плэй маркета).

[iKey Android 78]

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

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

 

Список изменений 1.1.7 -> 1.1.8:

Исправления:

• добавлена поддержка TK-17 для iKey;
• исправлена ошибка, приводившая к невозможности завершить логику мастера
  "Классик под прописку" в случае, если захвачен только 0-й сектор;
• исправлена ошибка, приводившая к некорректной работе навигации внутри приложения после отключения устройства;
• добавлен принудительный перевод баз данных в режим journal_mode = DELETE.

[nikola91 1]

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

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

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

 

Список изменений 1.1.7 -> 1.1.8:

Исправления:

• добавлена поддержка TK-17 для iKey;
• исправлена ошибка, приводившая к невозможности завершить логику мастера
  "Классик под прописку" в случае, если захвачен только 0-й сектор;
• исправлена ошибка, приводившая к неккоректной работе навигации внутри приложения после отключения устройства;
• добавлен принудительный перевод баз данных в режим journal_mode = DELETE.

классик обычно прописываю без этой функции, реализована ли как-то прописка в автоматическом режиме, если рассчитывается ключей 7 при захвате?

[Pavel 534]

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

классик обычно прописываю без этой функции, реализована ли как-то прописка в автоматическом режиме, если рассчитывается ключей 7 при захвате?

Каким образом? Панель не сообщает прибору какой из ключей ей понравится больше. Берется последний из списка.

[Jason 9]

В 27.02.2021 в 14:03, Pavel сказал:

при сохранении MF1K выводится именно UID, а не криптоключ, потому что там 16 секторов и в каждом UID может быть свой, от какого выводить UID, почему не от 4 или 7? Может в 0 там FF-ки, а используется только 12й

В 01.03.2021 в 20:37, iKey Android сказал:

Там два сценария: получен нулевой сектор, содержащий uid и получен 14-й сектор, в котором uid нет. Т.е. адекватный дамп можно создать только для нулевого сектора. Т.е. будет ок, к примеру, такое условие: если секторов больше одного или есть нулевой сектор - то создаем mf1k, в противном случае - mfsector?

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

[Pavel 534]

14 минут назад, Jason сказал:

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

Что за уид первого достоверного, UID находится только в 0 секторе.

[Jason 9]

В 10.03.2021 в 19:09, iKey Android сказал:

исправлена ошибка, приводившая к невозможности завершить логику мастера
"Классик под прописку" в случае, если захвачен только 0-й сектор;

И все равно не работает на UIDах из базы. 😞

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

[Pavel 534]

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

И все равно не работает на UIDах из базы. 😞

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

Значит у клиента уже копия. Покажите созданную метку, считайте её и пришлите дамп.

[Pavel 534]

Значит у клиента была уже копия. Покажите созданную метку, считайте её и пришлите дамп.

[Jason 9]

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

Значит у клиента была уже копия. Покажите созданную метку, считайте её и пришлите дамп.

Не совсем понял вас. Сегодня делал эту процедуру для UID вездехода, для которого был известен только UID. А раньше пытался сделать эту процедуру, когда у меня оставались заготовки OTP 2.0, если на другом адресе они не работали из-за фильтра, чтобы не выбрасывать их. А ещё пользуюсь этой процедурой, когда нужно прописать ключ в несколько домофонов и чтобы UID не вызвал подозрений. 

 

P.S. Процедура "Копия на заготовку" тоже не срабатывает на некоторых UIDах, сегодня столкнулся с этим второй раз. При этом все захватывается нормально, получилось скопировать только программой Ikeybase. Такое ощущение, что некоторые криптоключи куда-то теряются. Или это глюк прошивки SMKey? 

[Pavel 534]

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

Не совсем понял вас. Сегодня делал эту процедуру для UID вездехода, для которого был известен только UID. А раньше пытался сделать эту процедуру, когда у меня оставались заготовки OTP 2.0, если на другом адресе они не работали из-за фильтра, чтобы не выбрасывать их. А ещё пользуюсь этой процедурой, когда нужно прописать ключ в несколько домофонов и чтобы UID не вызвал подозрений. 

 

P.S. Процедура "Копия на заготовку" тоже не срабатывает на некоторых UIDах, сегодня столкнулся с этим второй раз. При этом все захватывается нормально, получилось скопировать только программой Ikeybase. Такое ощущение, что некоторые криптоключи куда-то теряются. Или это глюк прошивки SMKey? 

По классик под прописку я не то написал, перепутал с "копия на классик".

Если не работает "под прописку" - сохраните дамп и пришлите снимок с данными, что в этом дампе. И страницу "последние захваченные данные", причем ничего больше не захватываем после работы функции "под прописку", просто откройте потом "последние захваченные" и сделайте скрин, посмотрим.
По поводу P.S. - не срабатывает, значит не все нормально захватывается. А при следующем разе просто более удачный захват происходит (как раз и ikeybase запустили).
Чтобы разобраться - сохраняйте дамп, затем, если не работает, присылайте скрины сохраненного дампа (всех сделанных секторов) и снимок из окна "последние захваченные данные". Иначе это все гадания.

[Jason 9]

10 часов назад, Pavel сказал:

А при следующем разе просто более удачный захват происходит (как раз и ikeybase запустили

Несколько раз подряд неудачно? Или качество захвата тоже зависит от программы? 

 

Дамп пришлю.

[Pavel 534]

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

Несколько раз подряд неудачно? Или качество захвата тоже зависит от программы? 

 

Дамп пришлю.

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

[Jason 9]

Сегодня протестировал на считывателе с тремя линиями и без фильтра. Сохранил оба захвата в ячейки

 

Вот дампы, получившиеся в разных программах.

А вот захваченные данные. Ячейка 2 - то, что сохранил после неудачной попытки, сделанной Ikey Express, 3 - после удачной, сделанной Ikeybase. 

[Pavel 534]

26 минут назад, Jason сказал:

Сегодня протестировал на считывателе с тремя линиями и без фильтра. Сохранил оба захвата в ячейки

А вот захваченные данные. Ячейка 2 - то, что сохранил после неудачной попытки, сделанной Ikey Express, 3 - после удачной, сделанной Ikeybase.

Вижу, что ключ А съехал на пол байта вперед, будем исправлять, ставить в угол программиста и лишать конфет.

Неудачной попытки - это про какую функцию, классик под прописку?

[Jason 9]

13 минут назад, Pavel сказал:

Неудачной попытки - это про какую функцию, классик под прописку?

Да, про нее.

А вот ещё результаты вчерашнего теста. Одна и та же ячейка в разных программах

[Pavel 534]

Уже разобрались, просто если первый байт криптоключа имеет 0, то он съедается.

[iKey Android 78]

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

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

 

Список изменений 1.1.8 -> 1.1.9:

Исправления:

• теперь карта скрыта по умолчанию на экране редактирования адреса;
• изменение порядка ключей на экране выбора типа ключа;
• для TK-17 изменена форма ввода, добавлен принудительные расчет контрольной суммы;
• исправлена ошибка получения данных Mifare7b;
• исправление неверной генерации захваченного криптоключа в случае, когда его значение начинается с байта, значение которого меньше 10;
• исправлены некоторые случаи циклического переподключения к устройству в автоматическом режиме;
• вынесен в отдельный поток код, обращающийся к сервисам геолокации (на некоторых устройствах есть вероятность попадания в бесконечную блокировку потока);
• вынесен в отдельный поток код, обращающийся к сервисам телефонии (на некоторых устройствах есть вероятность попадания в бесконечную блокировку потока);
• исправление ошибки, в некоторых ситуациях приводящей к вылету приложения при переходе в фоновый режим;
• исправление ошибки, в некоторых ситуациях приводящей к вылету приложения при сканировании устройств;
• исправление ошибки, приводившей к вылету приложения на версиях Android ниже 24;

• улучшения, направленные на ускорение первого старта приложения.