Помогите взломать энигму

Доброго времени суток.
На счет Энигмы, конечно, шутка - разработчик всю жизнь страдал обычным XOR'ом к которому ключик подбирался либо сравнением вход-выход, либо перебором от 1 до 255, либо частотным анализом. На большее он способен не был.

Сейчас же обнаруживаю интересный шифр который оказался чуть сложнее чем мой уровень развития.

Исходные данные: черный список IPv4, порт. На ввод я могу влиять. На выходе зашифрованный дамп. Сделал список из адресов 0.0.0.0 с нулевым портом, ожидая что при ксоре вылезет ключик в чистом виде. Не сложилось. При изменении номера порта на единицу в дампе меняются сразу 8 байт данных. При изменении порта следующего элемента в списке - другие 8 байт данных. Короче логика и смещение понятны - по 8 байт на каждый адрес, хотя могли бы в 6 уложиться (4 на IP и 2 на порт).

Далее я провожу следующий эксперимент:
Меняю определенному адресу из черного списка порт от 0 до 10 последовательно, и каждый раз записываю результат. Ожидал что там выплывет какая-то закономерность, но на выходе равномерное распределение у каждого байта дампа. При изменении на единицу нет постоянного сдвига. Очевидный XOR тоже подобрать не могу.


Красным помечаются отличные от предыдущей строки значения.

Факты:
1. Ширина фиксирована, то есть шифрование идет побайтно.
2. Адрес из нулей с нулевым портом на любой позиции в дампе представлен одинаковой последовательностью байт (25 3b 4e ba 7b 4b 57 3f).
3. Адрес с любым другим номером порта на разных позициях в списке - в дампе будет абсолютно разным. Например, третий по списку 0.0.0.0:2 в дампе представлен как (e2 48 61 14 eb 2a 78 3a), он же на четвертой в списке позиции уже как (86 a4 cf 27 14 94 6f 34). Адрес 0.0.0.0:10 на позиции 3 отображается как (86 7 3e 7d 79 4 e3 1c) а на 4й позиции уже (bc 2b b3 bd 3 f2 d3 66)


Прошу подсказать что здесь может быть. Опять же уверен что тут ничего существенно более сложного чем XOR не будет, учитывая предыдущие разработки того же автора.

 

Авторы тоже развиваются...

Вероятно, используется блочный шифр с размером блока 8 байтов.

Если шифрующий (или дешифрующий, без разницы) софт доступен, то все подробности надо искать у него внутри. Если недоступен, то шансы угадать алгоритм+ключ по валидным парам близки к 0.

 

Просто сам блок это IP адрес и порт, возможно какой-то дурак вместо integer 2 байта unsiged использовал integer 4 байта в структуре, либо к адресу и порту прилагается какая-то 2-байтная контрольная сумма либо даже ключ шифрования для xor. При изменении в списке некоторых адресов, меняется соответствующие 8 байт. Соседние байты никогда не "цепляет". Но при изменении некоторых строк, в частности первых двух, почему-то меняется один и тот же блок. Было предположение что предыдущий блок используется для шифрования следущего, или как-то так но разгадать пока не получается.

Шансы угадать алгоритм+ключ по валидным парам иногда неплохо срабатывают. Я когда-то смог подобрать ключ для xor'а длиной байт 10-12 зная только то что начало зашифрованных данных это строка '<xml'.

Софт есть, но я не умею декомпилировать бинарники под Linux. В винде опыт был.