Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.119.167.196] |
|
Сообщ.
#1
,
|
|
|
Приветствую,
Есть устройство с удалённым доступом через интернет. Клиентское приложение написано под Windows и позволяет мониторить текущие данные оборудования без возможности сохранения логов. Возникла идея написать свою утилитку, которая бы писала нужные логи. Заказать нужные изменения не представляется возможным (продавец оборудования отказывается это делать). Поэтому, как всегда, пытаемся разобраться своими силами. Итак, поснифив запросы/ответы удалось выяснить следующее: 1. клиентское приложение всегда отправляет запрос размером в 16 байт 2. в запросе клиента всегда меняются первые два байта и последние четыре, остальные данные статичны 3. второй байт в запросе клиента всегда лежит в диапазоне 00 - 03 (hex) пример запроса: xx xx 00 00 00 0A F7 43 00 64 00 56 xx xx xx xx где xx - меняющиеся значения. 4. Если запрос верный, то устройство возвращает ~250 байт с данными. 5. Благодаря наличию в ответе текста выяснилось, что ответ зашифрован каким-то странным алгоритмом: меняются местами последовательно 2-й и 4-й, 4-й и 6-й, 6 и 8-й байты и т.д. в последовательности. Например, текст asutp будет выглядеть так: a.uspt 6. для работы в клиентском приложении необходимо ввести ip-адрес устройства и пароль (любая строка, требований и ограничений по длине нет). клиентское приложение пароль не отправляет (не похоже чтобы отправляло), а вот устройство отправляет пароль в ответе со смещением, как указано в п.5 7. если длина запроса не 16 байт, то устройство ничего не отвечает. 8. если длина запроса 16 байт, но он неверный, то устройство всегда в ответе возвращает 9 байт первые два из которых всегда равны первым двум из запроса, что очень похоже на crc. Остальные байты всегда одинаковы и не меняются, что позволяет сделать вывод что ответ содержит что-то типа "Ошибка авторизации". 9. "Ошибку авторизации" мы получаем всегда при неверном пароле в клиентском приложении. 10. первые 2 байта в запросе всегда дублируются и равны первым двум байтам в ответе. 11. Разрыв соединения не требует повторной авторизации на устройстве. После успешной авторизации (когда указан правильный пароль) приложение открывает окно с текущими параметрами устройства. Если это окно не закрывать, то обновление данных производится всегда по клику на соответствующую кнопку в приложении. Таким образом, я сделал вывод о том, что нет никакой сессии и её срока действия между приложением и устройством. Вся соль только в первых 2-х и последних 4-х байтах запроса. Моя задача сгенерировать правильный запрос. Точно известно, клиентское приложение писал один программист. Не думаю, что он сильно заморачивался по поводу шифрования. Скорее всего, использовались известные алгоритмы CRC. |
Сообщ.
#2
,
|
|
|
Цитата bur80 @ Заказать нужные изменения не представляется возможным (продавец оборудования отказывается это делать). А поделиться протоколом обмена он тоже отказывается? Цитата bur80 @ Моя задача сгенерировать правильный запрос. Накапливайте массив данных запрос-ответ-отображение. Цитата bur80 @ После успешной авторизации (когда указан правильный пароль) приложение открывает окно с текущими параметрами устройства. Авторизация - в приложении или на приборе? |
Сообщ.
#3
,
|
|
|
Цитата Akina @ Цитата bur80 @ Заказать нужные изменения не представляется возможным (продавец оборудования отказывается это делать). А поделиться протоколом обмена он тоже отказывается? Цитата bur80 @ Моя задача сгенерировать правильный запрос. Накапливайте массив данных запрос-ответ-отображение. Цитата bur80 @ После успешной авторизации (когда указан правильный пароль) приложение открывает окно с текущими параметрами устройства. Авторизация - в приложении или на приборе? 1. Протокол обмена не доступен. 2. Накапливаем. Что делать с накопленными данными? 3. Приложение в запросе пароль не передаёт. Пароль передаёт в открытом виде прибор, в нем он в настройках прописывается. И, если пароль из приложения соответствует полученному из прибора, то приложение вроде как прошло авторизацию (если это можно так назвать) и дальше открывается окно с текущими данными прибора. Добавлено Есть предположение, что защита паролем нужна только для безопасности приложения, так как прибор успешно отдает данные приложению даже если приложение не обращалось к прибору несколько часов. |
Сообщ.
#4
,
|
|
|
Прочитал вопрос дважды. Прошелся поиском по странице. При чем тут modbus из заголовка сообщения? Вроде тут не тытруба, за лишние просмотры денег не платят...
|
Сообщ.
#5
,
|
|
|
Цитата Dushevny @ Прочитал вопрос дважды. Прошелся поиском по странице. При чем тут modbus из заголовка сообщения? Вроде тут не тытруба, за лишние просмотры денег не платят... В приложении есть такое диковенное слово. Я написал исходя из того, что это может как-то помочь. |
Сообщ.
#6
,
|
|
|
Цитата bur80 @ Помочь что? Загуглить это слово, залезть хотя бы в википедию и сравнить за вас ваши посылки с описанием протокола modbus? Дык, "чтение документации из интернета вслух - 100 евро/час". Я написал исходя из того, что это может как-то помочь. |
Сообщ.
#7
,
|
|
|
Цитата bur80 @ Что делать с накопленными данными? Анализировать, ясен пень. Искать соответствия между пакетом и дешифрованными данными. перестановку букв-то сыскали - вот и всё остальное так же. |
Сообщ.
#8
,
|
|
|
bur80
Из памяти программы данные вытаскивать не вариант? |