Здравствуйте, PKz, Вы писали:
PKz>А зачем, когда можно пропатчить?
Т.е. зачем нужен ключ на когда можно пропатчить? Я всегда считал что ключ ценится у хакеров больше чем патч. Или я Вас не понял?

Статья конечно гавно, но про сами факты узнал впервые
( и кажется по количеству минусов самый последний ну тогда извиняюсь, если уже все мужики в курсе )

Здравствуйте, Tee Moore, Вы писали:

TM>Т.е. зачем нужен ключ на когда можно пропатчить? Я всегда считал что ключ ценится у хакеров больше чем патч. Или я Вас не понял?

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

Здравствуйте, Tee Moore, Вы писали:
TM>Т.е. зачем нужен ключ на когда можно пропатчить? Я всегда считал что ключ ценится у хакеров больше чем патч. Или я Вас не понял?

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

TM>Статья конечно гавно, но про сами факты узнал впервые
Так проблема взлома хэш-функций родилась где-то вместе с самими хэш-функциями.

Здравствуйте, PKz, Вы писали:

PKz>Здравствуйте, Tee Moore, Вы писали:
TM>>Т.е. зачем нужен ключ на когда можно пропатчить? Я всегда считал что ключ ценится у хакеров больше чем патч. Или я Вас не понял?

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

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

TM>>Статья конечно гавно, но про сами факты узнал впервые
PKz>Так проблема взлома хэш-функций родилась где-то вместе с самими хэш-функциями.
Так значить прорыва в борьбе щита и меча не было?

Здравствуйте, Tee Moore, Вы писали:
TM>Так значить прорыва в борьбе щита и меча не было?
А какой может быть прорыв? md5 математически вроде еще не взломан. Ломают оптимизированными методами полного перебора с использованием всяких программок-генераторов.

Здравствуйте, Kubyshev Andrey, Вы писали:

KA>>>Статья ни о чем, ни про че, к делу не относится. Вообще не о том думать надо. Хеши какие то в программе...
ДП>>А чего плохого в хешах в программе?

KA>А что такое "хеши в программе" ? Что б сказать плохо это или хорошо, надо бы сначала определиться что это такое и для чего.
KA>На форуме программистов термин вообще вызывает улыбку.

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

Здравствуйте, Tee Moore, Вы писали:

TM>Если хакеру известен вид ключа, например ХХХХ-ХХХХ-ХХХХ-ХХХХ, и есть выцарапаная из программы база хешей ключей в количестве нескольких тысяч,
TM>то разве тупым перебором невозможно подобрать ни одного ключа?

Это будет обычный брутфорс длительностью в несколько лет.

TM>Из статьи, я так понял 90% подобрали, но там конечно не ключи а пороли, но разница, если и есть, она не принципиальная, что бы считать что такой способ не пройдет с ключами.
TM>Что думаете коллеги?

Разница принципиальная — поиск по словарю не подойдет, длина ключика заметно больше, ключик не содержит обычных слов/имен/дат.

I>Разница принципиальная — поиск по словарю не подойдет, длина ключика заметно больше, ключик не содержит обычных слов/имен/дат.

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

Здравствуйте, drVanо, Вы писали:
V>>Если метод хеширования известен.
V>Совсем необязательно. В дебагере видно с чем сравниваются элементы массива (достаточно поставить хардварный бряк на первый элемент чтобы всплыть на операции сравнения/чтения элементов массива) — в операции сравнения как раз и будет тот самый правильный хеш.

Если взломщик ходит по программе, как по своей квартире, то говорить о защите не приходится _вообще_.

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

А вот так уже можно о защите говорить. Только закрыто должно быть _всё_, включая хранение и проверку статуса "зарегистрирована/нет".

Здравствуйте, Kubyshev Andrey, Вы писали:

KA>>>Статья ни о чем, ни про че, к делу не относится. Вообще не о том думать надо. Хеши какие то в программе...
ДП>>А чего плохого в хешах в программе?

KA>А что такое "хеши в программе" ? Что б сказать плохо это или хорошо, надо бы сначала определиться что это такое и для чего.
KA>На форуме программистов термин вообще вызывает улыбку.

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

Здравствуйте, PKz, Вы писали:

PKz>А зачем, когда можно пропатчить?
если человек лезет на варезные сайты и качает патч/крек, то хрен да с ним, он всё равно это прогу никогда не купит,
а вот когда в паблике ключи на прогу лежат, то это хуже.

Здравствуйте, eustin, Вы писали:

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

Как вариант, хеши проверяются только чтобы вывести строчку "Registered version", а ключиком расшифровываются константы.
После этого хакер может патчить все что угодно — без валидного ключика ничего не выйдет.

TM>>Если хакеру известен вид ключа, например ХХХХ-ХХХХ-ХХХХ-ХХХХ, и есть выцарапаная из программы база хешей ключей в количестве нескольких тысяч,
TM>>то разве тупым перебором невозможно подобрать ни одного ключа?

I>Это будет обычный брутфорс длительностью в несколько лет.

Меня всё таки смущает один момент. Эта длительностью в несколько лет предполагает нахождения 1 ключа?
Но если мы имеем несколько тысяч хешей, то не возрастет ли в туже тысячу раз вероятность совпадения,
а следовательно и сокращается в те же несколько тысяч раз время нахождения хотя бы одного совпадения?
Кто у нас с математикой дружит, подскажите.
Может и не к месту, но теория вероятности выкидывает удивительные вещи парадокс дней рождения — если дана группа из 23 или более человек, то вероятность того, что хотя бы у двух из них дни рождения (число и месяц) совпадут, превышает 50% !

TM>Меня всё таки смущает один момент. Эта длительностью в несколько лет предполагает нахождения 1 ключа?
Я же писал, если хэши будут не в секции данных, а в стеке создаваться, обернутым в виртуальную машину + скрыт алгоритм получению хэша, то какой тут брут форс?
Или как писал icezone, шифровать ключом константы, тоже хороший способ.
При правильной реализации защиты взлом будет нецелисообразен.

Здравствуйте, Tee Moore, Вы писали:

TM>Меня всё таки смущает один момент. Эта длительностью в несколько лет предполагает нахождения 1 ключа?
TM>Но если мы имеем несколько тысяч хешей, то не возрастет ли в туже тысячу раз вероятность совпадения,
TM>а следовательно и сокращается в те же несколько тысяч раз время нахождения хотя бы одного совпадения?
TM>Кто у нас с математикой дружит, подскажите.

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

Здравствуйте, Tee Moore, Вы писали:

TM>Но если мы имеем несколько тысяч хешей, то не возрастет ли в туже тысячу раз вероятность совпадения,
TM>а следовательно и сокращается в те же несколько тысяч раз время нахождения хотя бы одного совпадения?
TM>Кто у нас с математикой дружит, подскажите.

Тебе станет легче если на перебор уйдет не 500, а 5 лет?