Массив байт. Может кто узнает алгоритм шифрования?

Я проверил, 8-битный LFSR, к сожалению, отпал.
Дальше фантазия авторов может быть весьма разноплановой.

Это может быть 32-битный LFSR, от которого мы видим только младшие 8 бит - тогда его вычислить по 32 отсчетам невозможно.

Это может быть 8-битный нелинейный скремблер. Здесь можно попробовать найти полином скажем 2-ой или 3-ей степени от 8 бит по имеющимся 32 значениям.

В конце концов это может быть просто 32-битная константа, выдающая на каждый такт один свой бит в цикле. Поищите двоичное представление имеющихся 32 бит в прямой и в обратной записи в коде.

Я бы все таки также поискал в двоичном коде инструкцию "jp" как крайне редкую
и инструкцию test с нетривиальным (со многими ненулевыми значениями) вторым параметром.

 

А, так это не LFSR (я не стал "дорешивать" - поскольку ответ был дан)? Ну что ж, тогда можно исчо подумать.

PS Вчера я успел проверить 32-ти и 8-ми битный IMUL пытаясь получить 32-байтный период - вроде бы нет.

PPS Почему кстати 8-ми битный? После некоторого анализа это может быть 16-ти или более с отводами с 11 и 13-го битов и перексоривания их и подачи на бит 0?

 

Может. Только как бы "некрасиво". Согласитесь, 32-битным LFSR вообще можно любую 32-битную последовательность описать.

 

OLS

Не понял что вы имеете в виду. Почему 32-битную последовательность? 32 байтную же.

 

OLS
Действительно 8-битный не подходит?
Я подумал что-то типа : G(i+1) = G(i)<<1 + (G'(i+1) &(xor,or,...) Key)?1:0 ;
где G'(i+1) = G(i)<<1;

 

Линейный (содержащий только XOR) я не смог подобрать. Я конечно не считаю себя "истиной в последней инстанции", но не смог.

НЕлинейный (с OR и/или AND) я не проверял. Мне кажется, что это вполне возможно.

 

Алгоритм, который здесь используется, это некоторый эрзац, тем не менее для простых целей вполне работоспособный :

Имеется некое 8-битное состояние системы; всеми 8-мью битами этого состояния выполняется XOR над исходным текстом (гаммирование); а потом изменяется только 1 бит этого состояния, а остальные 7 сдвигаются влево; и снова производится гаммирование всеми 8 битами состояния.

То есть на каждом такте на самом деле генерируется только 1 новый бит, а используются все 8 - это не есть полноценный скремблер - каждый его "действительно уникальный" бит на самом деле используется для шифрования аж 8 раз - сначала в качестве 0-го бита, потом в следующем байте в качестве 1-го бита и т.п.

Очевидно, что если бы это была настоящая система, она была бы крайне нестойка - шифрующая последовательность используется 8-кратно, позволяя строить (выяснять) массу корреляций между битами исходного текста. Но здесь шифруемый массив очень небольшой по длине, да и авторы наверняка ставили целью, чтобы алгоритм оказался взламываемым после некоторого анализа.

Отвечая собственно на Ваш вопрос : шифруем то мы действительно 32 байта, но при этом сгенерировали "новых" всего 32 бита. О том, какой именно логике подчиняется генерация этих 32 бит и идет сейчас беседа. Хочется найти несложный алгоритм, описывающий все имеющиеся в нашем распоряжении 32 ситуации генерации нового бита как зависимость только от 8 бит текущего состояния (т.е. уложить всё это в рамки модели т.н. "8-битного скремблера"), а не от каких-либо констант, которые являются ненаблюдаемыми (зашитыми где-нибудь в код). Если это не удастся, придется считать, что правильным был второй вариант, хотя он менее "красивый", с точки зрения построения "crack_me".

 

OLS
наверное, все-таки, используется 32-битный ключ...
код на асме, что-то типа:

Код (Text):

1. rol Op(32-bit KeyMask),1
2. rcl Op(8-bit Out),1

 

там rol с xor`ом ^______^ но смысл задания не в этом.