Реверс протокола шифрования в закрытом устройстве. Возможно ли? Имеется система из двух устройств общающихся по цифровой шине, первое устройство управляет оборудованием, второе устройство разрешает или запрещает первому работу на основе считанных рфид меток.
Реализовано таким образом, что первое устройство при попытке включения отправляет некую, судя по всему рандомную последовательность вида «43 50 47 9d e0 d1 21 8e» во второе устройство, которое в свою очередь преобразовывает её в «66 e8 f4 4f a0 d8 de 71» и работа разрешается. Видимо первое устройство сравнивает с заранее известным ему результатом. Алгоритм преобразования всегда дает одни и те-же ответы на выходе при одинаковых запросах, во времени не меняется.
Сами рфид метки считанные вторым устройством на алгоритм шифрования тоже не влияют, любая считанная метка приводит к шифрованию одним алгоритмом. Но алгоритм меняется каждый раз при обучении меток и судя по всему устройства 1 и 2 обмениваются неким ключом во время этой сервисной процедуры, дабы потом работать в паре.
Задача сэмулировать поведение второго устройства, т.е. разобрать алгоритм по какому производятся преобразования. Из исходных данных можно сколько угодно получить пар значений вход-выход ну и предположительно есть ключ из процесса обучения (не знаю только зашифрован ли он тоже как-то или нет).
Путем не хитрого анализа удалось самому понять, что из 8 байт, последние 2 в ответе являются просто инвертированными последними двумя байтами запроса и от ключа шифрования не меняются. Соответственно остается 6 байт для анализа.
Для предположительного ключа «30 95 ca 3b c8 98 5e 84»
Пары выглядят так:
Вход: 00 00 00 00 00 00
Выход: 62 1e af 7c da 27
Вход: 01 00 00 00 00
Выход: dd 3e 53 d6 50 05
Для ключа «39 72 98 4e 69 4a 6b af»
Вход: 00 00 00 00 00 00
Выход: 2d c2 cb 75 4e ec
Вход: 01 00 00 00 00 00
Выход: 2d d1 32 2c e4 69
Из наблюдений, первые 4 байта похоже шифруются отдельным блоком, и на их результат не влияют 5 и 6 байт в запросе. При изменении 5 и 6 байтов в запросе, в ответе меняются тоже только 5 и 6 байты, но при изменении первых 4 в запросе, 5 и 6 тоже меняются в ответе. В общем шифрование 5 и 6 байта похоже зависят от результатов шифрования первых четырех.
Возможно ли вообще по этим параметрам определить алгоритм шифрования? Или это гиблое занятие если нет доступа к прошивке? Может быть это некий общеизвестный алгоритм? Микроконтроллер во втором устройстве, которое занимается шифрованием — PIC16.
Реверс протокола шифрования в закрытом устройстве. Возможно ли? Имеется система из двух устройств общающихся по цифровой шине, первое устройство управляет оборудованием, второе устройство разрешает или запрещает первому работу на основе считанных рфид меток.
Реализовано таким образом, что первое устройство при попытке включения отправляет некую, судя по всему рандомную последовательность вида «43 50 47 9d e0 d1 21 8e» во второе устройство, которое в свою очередь преобразовывает её в «66 e8 f4 4f a0 d8 de 71» и работа разрешается. Видимо первое устройство сравнивает с заранее известным ему результатом. Алгоритм преобразования всегда дает одни и те-же ответы на выходе при одинаковых запросах, во времени не меняется.
Сами рфид метки считанные вторым устройством на алгоритм шифрования тоже не влияют, любая считанная метка приводит к шифрованию одним алгоритмом. Но алгоритм меняется каждый раз при обучении меток и судя по всему устройства 1 и 2 обмениваются неким ключом во время этой сервисной процедуры, дабы потом работать в паре.
Задача сэмулировать поведение второго устройства, т.е. разобрать алгоритм по какому производятся преобразования. Из исходных данных можно сколько угодно получить пар значений вход-выход ну и предположительно есть ключ из процесса обучения (не знаю только зашифрован ли он тоже как-то или нет).
Путем не хитрого анализа удалось самому понять, что из 8 байт, последние 2 в ответе являются просто инвертированными последними двумя байтами запроса и от ключа шифрования не меняются. Соответственно остается 6 байт для анализа.
Для предположительного ключа «30 95 ca 3b c8 98 5e 84»
Пары выглядят так:
Вход: 00 00 00 00 00 00
Выход: 62 1e af 7c da 27
Вход: 01 00 00 00 00
Выход: dd 3e 53 d6 50 05
Для ключа «39 72 98 4e 69 4a 6b af»
Вход: 00 00 00 00 00 00
Выход: 2d c2 cb 75 4e ec
Вход: 01 00 00 00 00 00
Выход: 2d d1 32 2c e4 69
Из наблюдений, первые 4 байта похоже шифруются отдельным блоком, и на их результат не влияют 5 и 6 байт в запросе. При изменении 5 и 6 байтов в запросе, в ответе меняются тоже только 5 и 6 байты, но при изменении первых 4 в запросе, 5 и 6 тоже меняются в ответе. В общем шифрование 5 и 6 байта похоже зависят от результатов шифрования первых четырех.
Возможно ли вообще по этим параметрам определить алгоритм шифрования? Или это гиблое занятие если нет доступа к прошивке? Может быть это некий общеизвестный алгоритм? Микроконтроллер во втором устройстве, которое занимается шифрованием — PIC16.
Реализовано таким образом, что первое устройство при попытке включения отправляет некую, судя по всему рандомную последовательность вида «43 50 47 9d e0 d1 21 8e» во второе устройство, которое в свою очередь преобразовывает её в «66 e8 f4 4f a0 d8 de 71» и работа разрешается. Видимо первое устройство сравнивает с заранее известным ему результатом. Алгоритм преобразования всегда дает одни и те-же ответы на выходе при одинаковых запросах, во времени не меняется.
Сами рфид метки считанные вторым устройством на алгоритм шифрования тоже не влияют, любая считанная метка приводит к шифрованию одним алгоритмом. Но алгоритм меняется каждый раз при обучении меток и судя по всему устройства 1 и 2 обмениваются неким ключом во время этой сервисной процедуры, дабы потом работать в паре.
Задача сэмулировать поведение второго устройства, т.е. разобрать алгоритм по какому производятся преобразования. Из исходных данных можно сколько угодно получить пар значений вход-выход ну и предположительно есть ключ из процесса обучения (не знаю только зашифрован ли он тоже как-то или нет).
Путем не хитрого анализа удалось самому понять, что из 8 байт, последние 2 в ответе являются просто инвертированными последними двумя байтами запроса и от ключа шифрования не меняются. Соответственно остается 6 байт для анализа.
Для предположительного ключа «30 95 ca 3b c8 98 5e 84»
Пары выглядят так:
Вход: 00 00 00 00 00 00
Выход: 62 1e af 7c da 27
Вход: 01 00 00 00 00
Выход: dd 3e 53 d6 50 05
Для ключа «39 72 98 4e 69 4a 6b af»
Вход: 00 00 00 00 00 00
Выход: 2d c2 cb 75 4e ec
Вход: 01 00 00 00 00 00
Выход: 2d d1 32 2c e4 69
Из наблюдений, первые 4 байта похоже шифруются отдельным блоком, и на их результат не влияют 5 и 6 байт в запросе. При изменении 5 и 6 байтов в запросе, в ответе меняются тоже только 5 и 6 байты, но при изменении первых 4 в запросе, 5 и 6 тоже меняются в ответе. В общем шифрование 5 и 6 байта похоже зависят от результатов шифрования первых четырех.
Возможно ли вообще по этим параметрам определить алгоритм шифрования? Или это гиблое занятие если нет доступа к прошивке? Может быть это некий общеизвестный алгоритм? Микроконтроллер во втором устройстве, которое занимается шифрованием — PIC16.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Попытка реверс инжиниринга алгоритма шифрования без доступа к исходному коду может быть достаточно сложной задачей, особенно если алгоритм не является общеизвестным. Тем не менее, по имеющейся информации вы можете попытаться провести дальнейший анализ, чтобы попытаться понять логику работы алгоритма.
Дальнейший анализ данных, рассмотрение зависимостей между входными и выходными данными, а также изменение входных данных для получения дополнительной информации могут помочь вам приблизиться к пониманию алгоритма.
Тем не менее, стоит отметить, что попытка обойти шифрование или взломать систему без соответствующих разрешений может быть незаконной и недопустимой. Мы рекомендуем обратиться к производителю устройства или специалистам по информационной безопасности для решения данной проблемы.