Обнаружение шаблона лицензионного ключа?
Это не реальная ситуация; проигнорируйте юридические вопросы, что Вы могли бы думать, применяются, потому что они не делают.
Скажем, у меня есть ряд 200 известных действительных лицензионных ключей для гипотетической части лицензирования программного обеспечения алгоритма, и лицензионный ключ состоит из 5 наборов 5 алфавитно-цифровых нечувствительных к регистру (весь верхний регистр) символы. Пример: HXDY6-R3DD7-Y8FRT-UNPVT-JSKON
Действительно ли возможно (или вероятно) экстраполировать другие возможные ключи для системы?
Что, если набор, как было известно, был последователен; как методы изменяются для этой ситуации, и какое преимущество это дает?
Я услышал о "keygens" прежде, но я полагаю, что они, вероятно, сделаны путем декомпиляции программного обеспечения лицензирования вместо того, чтобы исследовать известные допустимые ключи. В этом случае мне только дают набор ключей, и я должен определить алгоритм. Мне также говорят, что это - алгоритм промышленного стандарта, таким образом, это - вероятно, не что-то основное, хотя шанс всегда там, я предполагаю.
Если Вы думаете, что это не принадлежит Переполнения стека, по крайней мере, предложите, чтобы альтернативное место для меня посмотрело или задало вопрос. Я честно не знаю, где начать с проблемы как это. Я даже не знаю терминологию для этого вида проблемы.
5 ответов
В общем, ответ такой: «Нет, вы не можете сделать ничего полезного».
Если люди, генерирующие ключи, ленились и не могли использовать какой-то хэш криптографического качества на основе номера индекса ( с достаточным битовым смешиванием, чтобы помешать любой проверке с вашей стороны), тогда вы можете принять какую-то функциональную форму генерации случайных чисел и посмотреть, можете ли вы отказаться, например, от модуля линейного конгруэнтного генератора случайных чисел или серия сдвигов и добавлений битового смешивания, например, в хэш-функции Дженкинса или в чем-то еще.
Не существует алгоритмов для перехода от некоторой общей структуры, которую вы заметили, к алгоритму, который создает эту структуру; кажется, что вы просите что-то похожее на это. (Такие алгоритмы в целом доказуемо невозможны; если вам нужен простейший алгоритм, который может вычислить ваши ключи, проблема изоморфна вычислению колмогоровской сложности, вычислить которую чертовски сложно («фактически невозможно»).)
Как известно, эту задачу трудно решить в общем случае. Однако, если
мне также сказали, что это стандартный алгоритм
если это так, вам следует получить список этих "стандартных алгоритмов" и проанализировать их на предмет слабых мест.
Мое наивное предположение состоит в том, что большинство генераций ключей имеют форму x || hash(x || fixed), где x - случайно сгенерированное значение для каждого ключа, а fixed - фиксированное значение. Используя эту форму, ключи можно довольно легко проверить (извлечь x, вычислить hash(x || fixed), посмотреть, совпадает ли оно).
Предполагая, что вы знаете точный используемый алгоритм, вам придется либо найти слабое место в алгоритме (маловероятно, если только они не используют хэш с известными уязвимостями), либо перебирать фиксированное значение и т.д.
Учитывая, что существует множество хэшей, которые не имеют известных уязвимостей, и если предположить, что ребята, выбравшие фиксированное значение, не были тупыми... это может оказаться непростой задачей, если у вас нет хороших навыков криптоанализа.
Так что проблему очень трудно решить, если ребята, разработавшие алгоритм, не тупые. Но они могут быть...
Ключи, которые проверяются в автономном режиме, обычно определяются набором некоторых свойств. Определенные подмножества битов имеют определенные значения или симметрии. Если определенные подмножества байтов, переданные определенным функторам, возвращают ожидаемый результат, то ключ считается действительным.
Если вы исследуете общие алгоритмы генерации ключей, вы, вероятно, сможете найти все возможные свойства. Затем вы могли бы использовать индуктивное логическое программирование, чтобы найти, какие из этих свойств применимы ко всем действительным ключам, но не к недействительным. (Вам также понадобится набор недействительных ключей, но их легко сгенерировать). На основе полученных результатов теоретически можно написать кейген. Вы также можете написать статью, если сможете заставить ее работать. Удачи.
Однако, если они проверяются онлайн, они могут быть просто псевдослучайными числами, которые проверяются по базе данных. В этом случае вам ничего не светит.
Система может генерировать ключи случайным образом, после чего клиенты проверяют их на центральном сервере. Это так же безопасно, как и любой другой алгоритм DRM, то есть совсем нет. В этом случае экстраполяция невозможна.
Предполагается, что система криптографически стойкая, зная эти ключи не принесут вам никакой пользы. Сейчас многие такие системы внедряются парнями, слишком дешевыми, чтобы покупать настоящий кейген, так что у вас все еще есть надежда.
Только небольшая часть оценки конверта говорит, что такой ключ содержит 125 (было 800 ой, спасибо за то, что уловил) бит информации, если вы выберете достаточно этого места, вы сможете провести какую-то атаку, но вы говорите об огромном количестве точек выборки.Но послушайте, какие еще планы у вас были в свободное время?
Даже большие парни напортачили, полдюжины лет назад в способе генерации ключей MSDN произошла ошибка, которая позволила провести какую-то атаку методом грубой силы . Вы найдете парней, продающих подписки MSDN на eBay как часть пакета корпоративных лицензий. Вы отправите свою информацию, и они предоставят вам предварительно зарегистрированную учетную запись MSDN через пару дней. Я почти уверен, что они воспользовались ошибкой в реализации и грубо форсировали регистрацию, пока одна из них не застряла.
Компания, в которой я работал, купила ее, Microsoft удостоила ее чести, поскольку мы не были мудрее, когда купили ее, но их интересовал адрес парня, который нам ее продал.