Всем доброго времени суток.
Появились вопросы по поводу протокола передачи e-mail и fax в модемах clover.
Есть примеры но под передачу файлов не подходит. Помогите пожалуйста

Есть информация по протоколу передачи файлов.
А так же есть информация по сжатию, только очень мало. Необходима помощь по декодированию и протоколам. Возможна взаимопомощь.

Есть информация по протоколу передачи файлов.
В смысле Bit transfer protocol? Так он описан производителем.
так же есть информация по сжатию, только очень мало.
Так ведь на сайте HAL Communication утверждают, что используется алгоритм PKWARE, в сети полно исходников; если память не изменяет implode explode.

На сайте описан протокол, но протокол, используемый в настоящее время существенно отличается.
А по поводу сжатия - мало знать алгоритм - надо еще знать параметры кодирования.

Я полнстью согласен с eralgen протокол который в действительности используется значительно отличается. Вот именно эти отличая мне инужны. Если у кого есть. Я могу выделить команды и предположить что они означают.

eralgen
Хочется уточнить, Вы имеете ввиду параметры кода Рида-Соломона? Или в сжатии есть какие-то параметры?

xxx
Какие команды и откуда Вы собрались выделять?

После демодуляции и декодирования идут двоичтные данные. Протокол передачи двоичных файлов.
В нём есть команды. Часть из них описана в документе e2004.pdf. На официальном сайте. А в реальности используется видоизменённый протокол. Вот отдуда можно получить команды, а вот что они обозначают я не знаю

xxx
Ну почему же, в том файле, который Вы мне присылали, все строго соответствует протоколу передачи
файлов (документ E2004) и сжатию PKWARE.

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

xxx
Если не секрет. Каким модемом и каким программным обеспечением Вы пользовались для получения
образцово-показательного сеанса связи? Может у Вас есть еще сеансы с передачей факсимиле?

eralgen
Согласен с Вами. Действительно, непонятно почему после декодирования и снятия протокола передачи
файлов получается какой-то битовый поток, не являющийся сжатым PKLIBом. Либо версия сжатия другая,
либо еще какая-нибудь ерунда.

xxx
Я полнстью согласен с eralgen протокол который в действительности используется значительно отличается.
Значительно это как? Формирование пакетов или префиксация. Что Вы имеете в виду?
eralgen
А по поводу сжатия - мало знать алгоритм - надо еще знать параметры кодирования.
Какие еще параметры? Для файлов в формате PKLIB первый байт либо 00 либо 01 и указывает на вид сжимаемых данных текст/двоичные, второй байт указывает на размер словаря 01..06.
Другими словами, если в начале файла Вы наблюдаете что-либо отличное, то это не формат PKLIB!

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

xxx
Перед тем как файл получить его надо сначала собрать, т.е. узнать его имя, размер и метод сжатия
Все верно, никаких противоречий ;-)
Только как-то трудно вслепую говорить о тонкостях протокола, потому что с одной стороны
Есть информация по протоколу передачи файлов.
с другой
Необходима помощь по декодированию и протоколам.
А в действительности никакой конкретики. Как помочь? Битовый поток в студию!

Выкладываю файл в копилку называется main.bit

Файл называется Main.txt но он не текстовый а битовый. Там остался только вторичный протокол

Файл посмотрим.
Кстати вопрос в тему, кто чем пользуется при разборе подобных файлов (типа шестнадцатиричные редакторы, всякие вьюверы)?
Я использую hiew, winhex, search&replace, 010editor.

При просмотре двоичных файлов я пользуюсь VIEW64. Очень удобна программа.

Все таки протокол отличается от того, что описан в e2004, но не сильно.
Мне даже кажется что он очень похож на BTP, такое же начало и конец пакета, так же префиксируются байты со значением 00, 01, единственное что реализовано, так это контроль целостности (последнее есть мое предположение, а не заключение).
Итак по порядку:
1. оставляем в покое служебную часть, в которой просматривается имя передаваемого файла размер после декомпресии, размер до компресии (о применении сжатия говорит наличие PKLIB , ну и само различие в значении этих полей).
2. последовательность 016302 (в е2004 0190) заменяем на 00
3. последовательность 0101 (в е2004 0191) заменяем на 01
Дальше следует то, из-за чего я выдвигаю предположение о применении контроля целостности.
Если поток побить на пакеты длиной в 104 байта, то последние 4 представляют собой соответсвенно 4 символа в ASCII кодировке, очень похожие на HEX представление 2-х байтовой проверки CRC или чего-то в этом роде. С помощью упоминавшегося 010Editor'a я получил контрольную сумму 100 байтного буфера (пакет) полином стандартный 0х1021, но она отличается для всех пакетов.
Отсюда пара вопросов к xxx:
-какова вероятность того, что предоставленный образец получен корректно, в смысле декодирован правильно, исправлены ошибки и т.д.;
-есть ли еще подобные образцы (нужно проверить одну гипотезу).
P.S.
Кстати забыл упомянуть еще одну утилиту - CrypTool.

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

Сто процентной уверенности в том что полученный образец декодирован правильно нет, т.к. сигнал реально записанный с эфира
Нужно выжать из Рида-Соломона всю его исправляющую способность.
Одно пока не понятно, почему полученный файл не похож на PKLIB формат :-(
Есть ещё ряд сигналов могу выложить, для просмотра.
Конечно выкладывай, есть еще вопросы к полям протокола (38574.8278009259 например), а также другие подозрения.

xxx
а вот скажите, вот Вы уже не раз здесь в форуме публиковали свои темы по поводу протоколов передачи данных, демодуляции сигналов. А для кого Вы всё это делаете? неужели свой, чисто личный, или скажем так "домашний", интерес? Или всетаки это всё для чего то одного грандиозного? Или Вы студент, пишущий некую работу по протоколам с прилагаемым софтом для декодирования (что нить типа Коде 300)?

Просто очень интересно и любопытно :)

xxx
readt
eralgen
Каким программным (аппаратно-программным) обеспечением Вы пользуетесь при демодуляции и декодировании сигнала Clover?

ana
Нет у уменя ни демодулятора, ни декодера для Clovera. Может как нибудь станет очень интересно и разберусь с недвоичными кодами.

Загрузил в копилку ещё один файл с битовым потоком Clover.
Shephard
Я это всё делаю для себя, пока ни чего вразумительного у меня не получилось, но это только пока
Программными продуктами пользуюсь исключительно только своими.

Загрузил в копилку ещё один файл с битовым потоком Clover.
Ну что же. Если судить по экземпляру либо исходный сигнал лучше, либо декодер заработал как надо, а именно таки используется CRC (теперь об этом видно и по служебному полю). Только у меня после пакета с полем CRC 7f28 идет сбой, далее опять хорошие пакеты, хотя это уже не важно (см. ниже).
Итого: имеем 3 файла (2 doc 1 mail.fwd) с длинами 9216, 3296 и 88 байт. Первые два похожи в начале но не смотря на расширение doc и на упоминание pklib ни капли не похожи на эти форматы. Для файла mail.fwd сжатие не применяется, при этом с размера 83 байта длина выравнивется до 88 и тоже ничего общего ни с архивом ни с каким другим форматом IMHO.
Вопрос: в данном контексте, что общего в числах 9216, 3296, 88?
Ответ: числа кратны 8.
В общем думаю имеет место быть блочный шифр. Миссия выполнена - Сушите весла! :-(
xxx
А есть ли доступ к телу? Или хотя бы какая нибудь информация? Так, для успокоения души.

P.S. В упоминаемом выше CrypTool реализован один из алгоритмов криптоанализа DES, но времени это займет не меряно (при этом не факт, что здесь используется DES и что это вообще шифр)

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

И все таки, сбойные пакеты - вина декодера?
Если ещё появятся сигналы подходящего качество можно будет ещё посмотреть.
Посмотреть конечно можно, но если применяется шифрование, то только с позиции шлифовки декодера.
Кстати, если число с плавающей точкой из служебной части вогнать в ячейку Exel'а и поставить формат "дата время", то получите временную метку осуществления передачи.

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

Нет сбойные пакеты скорее всего вина демодулятора,...
Как то несерьёзно "скорее всего" 8-(
А можно ли выложить данные после демодулятора? Думаю на форуме найдутся спецы, которые декодируют Рида Соломона или расскажут как это сделать.

Впринципе можно выложить. Только вот надо определиться в каком виде. Какие бадут предложения