Обнаружение шаблона лицензионного ключа?

Question

Это не настоящая ситуация; пожалуйста, не обращайте внимания на юридические вопросы, которые, по вашему мнению, применимы, потому что они этого не делают.

Допустим, у меня есть набор из 200 известных действительных лицензионных ключей для гипотетического фрагмента алгоритма лицензирования программного обеспечения, а лицензионный ключ состоит из 5 наборов из 5 буквенно-цифровых символов без учета регистра (все заглавные буквы). Пример: HXDY6-R3DD7-Y8FRT-UNPVT-JSKON

Возможно ли (или вероятно) экстраполировать другие возможные ключи для системы?

Что если бы набор был известен как последовательный; как методы меняются в этой ситуации, и какое преимущество это дает?

Я слышал о «кейгенах» раньше, но я полагаю, что они, вероятно, создаются путем декомпиляции лицензионного программного обеспечения, а не путем изучения известных действительных ключей. В этом случае мне дают только набор ключей, и я должен определить алгоритм. Мне также сказали, что это стандартный промышленный алгоритм, поэтому он, вероятно, не является чем-то базовым, хотя, я полагаю, всегда есть шанс.

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

Answer 1

Это общеизвестно трудно решить в общем случае. Однако, если

Мне также сказали, что это алгоритм промышленного стандарта

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

Мое наивное предположение состоит в том, что большая часть генерации ключей имеет форму x || hash (x || fixed), где x - случайно сгенерированное значение для каждого ключа, а fixed - фиксированное значение. Используя эту форму, ключи можно легко проверить (извлечь x, вычислить хеш (x || исправлено), посмотреть, соответствует ли он).

Предполагая, что вы знаете точный используемый алгоритм, вам придется либо найти слабость в алгоритме (маловероятно, если только они не используют хеш с известными уязвимостями), перебором фиксированного значения и т. Д.

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

Так что проблему очень трудно решить, если ребята, которые разработали алгоритм, не глупы. Но они могут быть ...

Answer 2

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

Если вы исследовали общие алгоритмы генерации ключей, вы, вероятно, могли бы придумать вселенную возможных свойств. Затем вы можете использовать индуктивное логическое программирование, чтобы найти, какие из этих свойств применимы ко всем действительным ключам, но не недействительным ключам. (Вам также нужен набор недействительных ключей, но их легко генерировать). Из результатов можно теоретически написать кейген. Вы также можете написать статью, если сможете заставить ее работать. Удачи.

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

Answer 3

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

Совсем немного назад оценки конверта говорят, что такой ключ имеет 125 (было 800 уп, спасибо, что поймал это) бит информации, если вы взяли достаточно места, вы могли бы совершить какую-то атаку, но вы говорите об огромном количестве точек выборки. Но какие планы у тебя были на свободное время?

Даже большие парни испортили это, полдюжины лет назад была ошибка в том, как генерировались ключи MSDN, которые допускали какую-то грубую атаку. Вы найдете парней, продающих подписки MSDN на eBay как часть пакета корпоративного лицензирования. Вы предоставите свои данные, и они предоставят вам предварительно зарегистрированную учетную запись MSDN через пару дней. Я почти уверен, что они воспользовались ошибкой в ​​реализации и грубым принуждением к регистрации, пока одна из них не застряла.

Компания, в которой я работал, купила одну, Microsoft почитала ее, поскольку мы не были мудрее, когда мы ее покупали, но они интересовались адресом парня, который продал ее нам.

Answer 4

В общем, ответ: «Нет, вы не можете сделать ничего полезного».

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

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

Answer 5

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