криптосюжет
Nov. 23rd, 2003 05:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaПридумал сюжет для криптофантастического романа или повести. Точнее, не сюжет даже, а завязку.
Сидит хакер, взламывает какую-то программу (игрушку, скажем, но необязательно). В программе есть проверка серийного номера. Он ищет то место внутри программы, где эта проверка происходит, чтобы её отключить. Находит функцию, которая получает строку серийного номера (достаточно длинного) и проверяет, является ли он правильным.
Смотрит внутрь этой функции, видит: там что-то вычисляется, странное и сложное. Разбираться, что именно, чтобы написать генератор номеров, лень, там куча каких-то битовых операций неясных в цикле. С другой стороны, никаких подвохов в виде проверки контрольной суммы вычисляющего кода, или побочных эффектов функции, или других проверок в других местах, вроде бы не видно. Обрадовавшись, что всё оказалось так просто, он быстро забивает код функции, чтобы она всегда возращала истинность проверки, готовит патч, перепроверяет с ним — вроде бы всё работает, программа принимает любой серийный номер без проблем — и отсылает патч по стандартным своим каналам дистрибуции. Работа сделана.
Но что-то продолжает его беспокоить, почему-то он всё время возвращается мысленно к коду этой функции. Что-то там было знакомое, хоть даже и в ассемблере... В конце концов через пару дней он открывает опять пропущенный через дизассемблер код программы, находит эту функцию, читает внимательно, тщательно выписывает, что она делает с серийным номером, мучительно пытается вспомнить, где он это видел. Наконец срывается с места, прыгает к книжной полке, хватает изрядно потрёпанное второе издание Applied Cryptography и быстро находит в нём обсуждение MD5. Да, не может быть никаких сомнений! Загадочная функция проверки серийного номера попросту пропускает его через MD5, и сравнивает после этого с фиксированным 128-битным числом. Более того, числом этим оказывается 0x0123456789ABCDEFFEDCBA9876543210 . Герой откладывает книгу в сторону и надолго задумывается, облокотившись на клавиатуру и уставив невидящий взгляд в горящие на мониторе строки ассемблерных команд, составляющих функцию проверки серийного номера...
Сидит хакер, взламывает какую-то программу (игрушку, скажем, но необязательно). В программе есть проверка серийного номера. Он ищет то место внутри программы, где эта проверка происходит, чтобы её отключить. Находит функцию, которая получает строку серийного номера (достаточно длинного) и проверяет, является ли он правильным.
Смотрит внутрь этой функции, видит: там что-то вычисляется, странное и сложное. Разбираться, что именно, чтобы написать генератор номеров, лень, там куча каких-то битовых операций неясных в цикле. С другой стороны, никаких подвохов в виде проверки контрольной суммы вычисляющего кода, или побочных эффектов функции, или других проверок в других местах, вроде бы не видно. Обрадовавшись, что всё оказалось так просто, он быстро забивает код функции, чтобы она всегда возращала истинность проверки, готовит патч, перепроверяет с ним — вроде бы всё работает, программа принимает любой серийный номер без проблем — и отсылает патч по стандартным своим каналам дистрибуции. Работа сделана.
Но что-то продолжает его беспокоить, почему-то он всё время возвращается мысленно к коду этой функции. Что-то там было знакомое, хоть даже и в ассемблере... В конце концов через пару дней он открывает опять пропущенный через дизассемблер код программы, находит эту функцию, читает внимательно, тщательно выписывает, что она делает с серийным номером, мучительно пытается вспомнить, где он это видел. Наконец срывается с места, прыгает к книжной полке, хватает изрядно потрёпанное второе издание Applied Cryptography и быстро находит в нём обсуждение MD5. Да, не может быть никаких сомнений! Загадочная функция проверки серийного номера попросту пропускает его через MD5, и сравнивает после этого с фиксированным 128-битным числом. Более того, числом этим оказывается 0x0123456789ABCDEFFEDCBA9876543210 . Герой откладывает книгу в сторону и надолго задумывается, облокотившись на клавиатуру и уставив невидящий взгляд в горящие на мониторе строки ассемблерных команд, составляющих функцию проверки серийного номера...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-11-24 02:04 pm (UTC)no subject
Date: 2003-11-24 04:24 pm (UTC)no subject
Date: 2003-11-24 04:47 pm (UTC)Но структура также содержит и "балласт" размером, например, 4-6 байт.
При генерации ключа делаем перебор переменной-балласта для достижения условия, при котором пошифрованный блок содержит в конце, например, 0x12345678 или что-то в этом роде. Программа, которая проверяет ключ, проверяет в самом начале эту константу. Предположим, патчить ее нельзя. Тогда кракер сначала впадет в ступор, затем поймет, что ему нужно задействовать определенную вычислительную мощь для генерации ключа. Моща эта будет зависеть от размера константы/балласта и типа криптоалгоритма. Допустим девелоперы могут пойти на то, что бы тратить несколько часов для генерации каждого ключа на относительно большом кластере.
Идея в итоге оказалась прикольной, но не самой хорошей, есть и лучше..
P.S. В случае с моим crackme было так: инфа занимала 16 байт, из них "балласт" 4 байта, кейген брутфорсил "балласт" для достижения условия при котором сумма первых 14-и байт пошифрованного блока равнялась последним двум. Тот несчастный, который дербанил мой crackme убил на понимание этой идеи несколько суток :)
P.P.S. При условии, когда программу нельзя патчить по каким-то причинам, лучше всего генерить/проверять ключи используя несимметричные криптосистемы - практически неломаемо.
no subject
Date: 2003-11-24 05:01 pm (UTC)