LINUX.ORG.RU

Помогите с XOR

 ,


0

1

Привет всем!

Уже написал в старой теме, но она была видна только в трекере, который за сегодня заполнился кучей новых тем, поэтому создаю новую.

Я изучаю формат двоичных данных одного из оффлайн-словарей, чтобы встроить его поддержку в свою свободную программу. В программе используется XOR, однако есть возможность добавлять свои данные. Данные кодируются без компрессии, байт-в-байт, кодировка cp1251. Например, вот какой фрагмент добавится, если в словаре создать комментарий и вписать в него нули (3 кавычки добавлены, чтобы не экранировать при необходимости):

"0000000000"
b'''\x18\x9f\xf0!\xec\xa0}\xefxq'''

NO  ORIG  INT1  INT2  OFFSET  DELTA
1   "0"   48    24    -24     -24  
2   "0"   48    159   111     135  
3   "0"   48    240   192     81   
4   "0"   48    33    -15     -207 
5   "0"   48    236   188     203  
6   "0"   48    160   112     -76  
7   "0"   48    125   77      -35  
8   "0"   48    239   191     114  
9   "0"   48    120   72      -119 
10  "0"   48    113   65      -7   

INT1 обозначает позицию кодируемого символа («0») в кодировке cp1251, INT2 - финальную позицию, OFFSET - смещение, DELTA - разницу между смещениями.

Заметил следующие особенности.

1) Кодирование зависит от длины фрагмента. Один и тот же символ будет закодирован по-разному в зависимости от длины фрагмента.

2) Если фрагменты одинаковой длины и отличаются, например, только конечные байты, то начальные байты будут одинаковы.

3) Обнаружил алгоритм для кодирования разных байтов, стоящих на одинаковых позициях (например, b"abc" -> b"abd"). За редким исключением, там зациклено смещение -2, -2, -2, +6, -2, -2, +10 для всей кодировки cp1251. Проблема в том, что мне надо знать, как меняются байты на разных позициях, т.е., не b"abc" -> b"abd", а, например, от чего зависит смещение b"d" в b"abcd", если смещение a, b и c известно.

Например:

"bbbbbb"
b'''`\xbe\xe4\x81\x19\x97'''

NO  ORIG  INT1  INT2  OFFSET  DELTA
1   "b"   98    96    -2      -2   
2   "b"   98    190   92      94   
3   "b"   98    228   130     38   
4   "b"   98    129   31      -99  
5   "b"   98    25    -73     -104 
6   "b"   98    151   53      126  

"bbcbbb"
b'''`\xbe\xfb\x81\x19\x97'''

NO  ORIG  INT1  INT2  OFFSET  DELTA
1   "b"   98    96    -2      -2   
2   "b"   98    190   92      94   
3   "c"   99    251   152     60   
4   "b"   98    129   31      -121 
5   "b"   98    25    -73     -104 
6   "b"   98    151   53      126  

"abc"
b'''JD%'''

NO  ORIG  INT1  INT2  OFFSET  DELTA
1   "a"   97    74    -23     -23  
2   "b"   98    68    -30     -7   
3   "c"   99    37    -62     -32  

"abcdef"
b'''a\xbeB\xd1f\xb1'''

NO  ORIG  INT1  INT2  OFFSET  DELTA
1   "a"   97    97    0       0    
2   "b"   98    190   92      92   
3   "c"   99    66    -33     -125 
4   "d"   100   209   109     142  
5   "e"   101   102   1       -108 
6   "f"   102   177   75      74   

Какой алгоритм используется? Извините, если туплю, но у меня небольшой опыт работы с бинарниками, а в шифровании вообще не разбираюсь.

Какой алгоритм используется?

Сам же в теме ответил: XOR. Только вот с чем? Мож с первым словом нужной длины?

anonymous
()

2) Если фрагменты одинаковой длины и отличаются, например, только конечные байты, то начальные байты будут одинаковы.

возможно там либо набор ключей разной длины, либо какая-то функция, которая генерит ключ подходящей длины

В программе используется XOR

man реверсивность

n_play
()

Не очень понятно, где именно здесь XOR. Если бы использовалось побитовый XOR с ключом некоторой длины
и при этом «bbbbbb» XOR key = «`\xbe\xe4\x81\x19\x97»
тогда первые 6 байтов ключа = «bbbbbb» XOR «`\xbe\xe4\x81\x19\x97» = «\x2\xdc\x86\xe3\x7b\xf5»

Но тогда результатом «bbcbbb» XOR «\x2\xdc\x86\xe3\x7b\xf5» было бы «`\xbe\xe5\x81\x19\x97», а не «`\xbe\xfb\x81\x19\x97», правильно?

Так что непонятно, где тут XOR

PeleWin
()
Ответ на: комментарий от PeleWin

А что это тогда за шифрование байт-в-байт? Вообще, если смотреть, что меняется, то изменение одного слова приводит к изменению блока на 16 Кб, однако, позиция байт слова не меняется (я это проверил, заменяя байты в оригинальных позициях на b'\x00').

anonymizer
() автор топика

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

peregrine ★★★★★
()

изучаю формат двоичных данных одного из оффлайн-словарей, чтобы встроить его поддержку в свою свободную программу

Данные ведь проприетарные, их нельзя просто так взять, это нелегально будет. А свободная ГУЯ к несвободным данным - в этом точно есть смысл?

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

… но она была видна только в трекере, который за сегодня заполнился кучей новых тем, поэтому создаю новую.

так нехорошо делать

corona
()
Ответ на: комментарий от corona

Данные ведь проприетарные, их нельзя просто так взять, это нелегально будет

Нелегально будет распространять проприетарные данные. Но не свободную программу для их считывания.

А свободная ГУЯ к несвободным данным - в этом точно есть смысл?

Зависит от популярности данных. В среде переводчиков данный проприетарный словарь - один из самых популярных. Кстати, насколько могу судить, но авторы не указали лицензию ни в установщике, ни на сайте.

Если разрабы словаря не взяли нормальный шифр - они долбодятлы.

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

так нехорошо делать

По факту, в старой теме задавался вопрос про другой алгоритм шифрования (из демо-версии).

anonymizer
() автор топика
Последнее исправление: anonymizer (всего исправлений: 2)
Ответ на: комментарий от anonymizer

А что значит «шифрование байт-в-байт»?
Что длина шифротекста равна длине исходного текста? Так это, мне кажется, верно для подавляющего большинства применяемых шифров.

Мне кажется, что тут используется потоковое шифрование (а не блочное шифрование), так как (вроде бы) если бы использовалось блочное шифрование, то изменение 1 любого байта в одном блоке исходного текста затронуло бы ВСЕ байты соответствующего блока шифротекста.

А в случае с потоковым шифрованием как раз пока начала двух исходных текстов совпадают (и ключ один и тот же), начала соответствующих шифротекстов тоже будут совпадать.

PeleWin
()
Ответ на: комментарий от PeleWin

А что значит «шифрование байт-в-байт»?
Что длина шифротекста равна длине исходного текста?

Да.

если бы использовалось блочное шифрование, то изменение 1 любого байта в одном блоке исходного текста затронуло бы ВСЕ байты соответствующего блока шифротекста.

В принципе, так и есть. Изменение слова приводит к перезаписи блока на 16 Кб. Однако, при этом сама позиция слова не меняется.

пока начала двух исходных текстов совпадают (и ключ один и тот же), начала соответствующих шифротекстов тоже будут совпадать

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

anonymizer
() автор топика
Ответ на: комментарий от anonymizer

В среде переводчиков данный проприетарный словарь - один из самых популярных.

Ну вам виднее.

авторы не указали лицензию ни в установщике, ни на сайте.

Странно конечно. Помню интересовался темой… Отсутствие лицензии - не важно. Данные - ихние, даже если никаких оговорок нет. Они в любое время могут наложить на данные любые ограничения.

Только шифр другой

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

Есть дизассемблеры. В новостях тут были. Был какой-то от американских гос-структур, выдаёт сишный код (названия переменных и функций нечелевечьи, само собой). Название не помню. EXL разбирается в этой теме. Поскольку софт оффлайновый, задача решаема, вопрос лишь во времени ;)

А такие кулибинские методы (кодировка виндоуз, анализ смещений и позиций в ней) - это как-то несерьёзно совсем. Сработает лишь если разрабы дятлы.

corona
()
Ответ на: комментарий от corona

Данные - ихние, даже если никаких оговорок нет. Они в любое время могут наложить на данные любые ограничения.

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

Им надо только ключик спрятать тщательно

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

кодировка виндоуз

Программа очень старая, корни с 80-х.

anonymizer
() автор топика
Ответ на: комментарий от anonymizer

EXL Извиняюсь за каст…

Я имел ввиду что EXL дизассемблерами пользовался, а не шифры отгадывал. И ещё то, что если уж инвестировать время в хобби, то на освоение инструмента и метода, а не на кулибинские угадывания.

Вот, нашёл тот американский дизассемблер: Ghidra. Тут на лоре в поиске много всяких рекомендаций по дизасму.

как, например, ключом с длиной в 6 байт можно закодировать гораздо более длинный текст без явных повторов.

И в чём проблема? Если 6 байт мало, добавить нулями. Без повторов - поточно (выше сказали). На входе - одинаковые блоки, а на выходе — будут разные. Это совершенно обычная практика, так делать.

corona
()
Ответ на: комментарий от anonymizer

Кстати, чем линуксовый мюллер плох? Я вот пользуюсь иногда, и не знаю как много теряю :)

$ dict -d mueller7 assemble
1 definition found

From Mueller English-Russian Dictionary [mueller7]:

  assemble
     [ɜ↗sɛmbl] _v.
     1) созывать
     2) собирать(ся)
     3) _тех. монтировать; to assemble a watch собрать часы
corona
()
Ответ на: комментарий от corona

Я вот пользуюсь иногда, и не знаю как много теряю :)

Айтишники морщатся, когда видят notepad.exe вместо vi/emacs/Notepad++/etc. Но почему-то не понимают, что то же работает и в обратную сторону. Дизайнеру не хватит mspaint, а переводчику не хватит Мюллера с вордом. См., например, эту статью про assemble.

anonymizer
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.