Как обмануть хакера-крякера?

← →
Rooman (2002-03-22 19:39) [0]

У меня такой вопрос. Я делаю защиту shareware программы. Допустим, до регистрации в программе действуют некоторые ограничения, которые снимаются после регистрации программы законным путем. Допустим, я привязываю программу к конкретной машине и пользователю. Например, в качестве привязки используется имя пользователя, его ИНН, данные БИОС и винчестера.
Пользователь, оплатив программу, получает индивидуальный пароль, назвав который по телефону и сообщив ключевой идентификационный номер по телефону же получает ответный код.
Моя задача: реализовать функцию проверки правильности регистрационного кода так, чтобы хакер-крякер с большим трудом смог отыскать это место в программе. Как это лучше сделать? Есть идея - создавать отдельный поток в момент срабатывания таймера (компонента TTimer). Как лучше всего это реализовать? Подскажите, пожалуйста...

← →
drpass (2002-03-22 19:43) [1]

Нормальная идея. Можно даже без всяких потоков, просто в обработчике OnTimer. Вообще, разхакерить Delphi-программу очень сложно, код VCL настолько наворочен, что пропадет всякое желание его распутывать дизассемблером. А что за прога у тебя такая, и почем стоит?

← →
Rooman (2002-03-22 19:43) [2]

Комментарий: регистрационный номер я предполагаю считывать из общедоступного места, например, реестра. Но! данную строчку я планирую динамически перемещать в памяти по таймеру так, чтобы отследить момент считывания этой строчки было очень и очень проблемматично. Как это сделать?

← →
Rooman (2002-03-22 19:49) [3]

Просто в обработчике OnTimer - мне кажется слишком простым для взлома, т.к. в принципе можно отследить этот метод в VCL (например брейкпоинтом на TTimer.OnTimer). Надо это дело как-то усложнить.

← →
BlackJack (2002-03-22 19:52) [4]

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

← →
Rooman (2002-03-22 19:54) [5]

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

← →
Rooman (2002-03-22 19:57) [6]

BlackJack - в том то и суть, что надо и код, и строчку создавать динамически, чтобы нельзя было подменить. Вот и давайте обсуждать, как это можно сделать?

← →
SDS (2002-03-22 20:27) [7]

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

← →
Rooman (2002-03-22 20:53) [8]

SDS - дело в том, что нельзя сделать генератор ключей, но можно просто отключить (обойти) проверку кода! Вопрос об RSA не стоит - это само собой разумеется. У меня вопрос немного другой - как запрятать функцию проверки кода так, чтобы ее было бы трудно найти.

По поводу взлома Delphi - программ. VCL ломается элементарно, т.к. IDA начиная с 3.8 поддерживает сигнатуры VCL и многих других библиотек. Дизассемблим в IDA, видим, что это Дельфи, а значит есть методы, типа TTimer.OnTimer (внутри которого вызывается определенное на этапе разработки OnTimer событие). Можно записать его адрес на бумажку и поставить в SoftICE BPX на этот адрес. Тем самым мы легко отследим все события ВСЕХ (!!!) компонентов, унаследованных от TTimer.

← →
SDS (2002-03-22 22:33) [9]

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

← →
kull (2002-03-23 01:19) [10]

Есть неплохой вариант:
Защитить прогу с помощью ASProtect,
там есть разные способы и Trial и registration key и привязка к HardwareID......
http://www.aspack.com/

← →
Rooman (2002-03-23 07:11) [11]

"Все равно сломают" - как часто я слышу эту фразу без всякого обоснования.

SDS - по поводу CRC - убивается так же, как и код проверки правильности ключа. Т.е. в самом начале этой функции прописывается либо просто ret, либо последовательность mov переменная,число; ret; Это не вопрос! Таких функций можно сделать много - но не бесконечное множество!
А я хочу сделать упор на то, что функция проверки должна создаваться бесконечно много раз, причем динамически. А так же все глобальные переменные, содержащие ключ и флаг его корректности, тоже должны перемещаться по памяти бесконечно много раз.
Вот такой геморой хочу сделать! Как?

← →
Rooman (2002-03-23 07:23) [12]

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

← →
Rooman (2002-03-23 07:37) [13]

Ладно, сформулирую вопрос по другому: как лучше всего спрятать непосредственный вызов конкретной функции?
Т.е. в общем случае функция проверки вызывается из другого места программы так: "CALL proc;", при этом proc имеет статическое значение, прописываемое в скомпилированном exe-модуле. Когда хакер ломает программу - он находит такой вызов, ставит брейкпоинт в начало функции proc (напр., BPX proc в SoftICE), дожидается ее вызова, исследует ее работу и видоизменяет ее так, чтобы факт незарегистрированности программы был инвертирован (о как сказал!).
Задача: сделать вызов функции динамическим. Т.е. таким, чтобы момент ее вызова не был обнаружен простыми методами, например, трасировкой.
Есть предположение, что можно вызов делать:
1. по приходу некоторого сообщения Windows
2. в обработчике хука (WindowsHook)
3. в отдельном потоке

Все эти мысли надо превратить в код. Что посоветуете?

← →
Anatoly Podgoretsky (2002-03-23 09:32) [14]

Rooman © (23.03.02 07:11)
Почему без основания, основание что есть программа на компьютере и она работает. Дальше дело времени, что бы она работала на другом компьютере.
Другое дело если программы или части модулей нет, они подгружаются из внешнего источника динамически при каждом запуске стартового модуля и могут быть каждый раз разные, то есть посторное использование не возможно. Но у тебя не этот случай.

← →
Anatoly Podgoretsky (2002-03-23 09:33) [15]

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

← →
Rooman (2002-03-23 10:49) [16]

ASProtect страдает всеми теми же проблемами, что и UPX, и прочие упаковщики exe-файлов. Читайте соотв. литературу. Мне нужно написать СВОЮ защиту - не универсальную.

← →
Anatoly Podgoretsky (2002-03-23 11:06) [17]

Если ты такой богатый, то конечно пиши свою.

← →
JibSkeart (2002-03-23 13:19) [18]

не забуть еще то что ,как бы круто не шифровался пароль итд итп
где бы не шло сравнение ...
не использовать такие веши как
если зарегена прога ключь все подошел
то
RegProg=True; !!
сам видел такую гадость и ломал(правда не хакер я но пробовал :))
воот !!! ведь такие вещи лечатся изменением одного байта с 0 на 1

хех подумай над ентим
вообшем что в таком духе :))

← →
POOKER (2002-03-23 14:38) [19]

Нет нечего того, что нельзя былобы взломать :)

← →
Rooman (2002-03-23 15:29) [20]

>Anatoly Podgoretsky © (23.03.02 11:06)
>Если ты такой богатый, то конечно пиши свою.

Если такой бедный - покупай ASProtect.

← →
Rooman (2002-03-23 15:46) [21]

>JibSkeart © (23.03.02 13:19)

>ведь такие вещи лечатся изменением одного байта с 0 на 1
где лечатся? в ехе? а если вот так хранить:

var p:pointer;
key:string[128];

//один поток:
...
читаем откуда нибудь key;
...

//второй поток:

...
GetMem(p,128)
StrLCopy(p,pchar(key),128
...

//третий поток:
...
reallocmem(p,128);
...

//четвертый поток:
...
читаем содержимое ключа по адресу p
...

//по завершении программы:
...
freemem(p);
...

Отследить момент считывания нельзя ни по BPX, ни по BPM (если не знать, где расположено тело четвертого потока, конечно), т.к. истинное считывание будет перемежаться с бесконечным множеством левых считываний (reallocmem).

Или я не прав?

← →
cypher (2002-03-23 19:29) [22]

прав =)

← →
deleon (2002-03-25 11:34) [23]

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

← →
alexadvanser (2002-03-26 18:31) [24]

Господа, Вы знаете в чем прикол?
На каком-то сайте видел AsProtect c кряком (не который проги вскрывает, а который позволяет AsProtect работать без покупки...)
И чего тогда эта прога стоит...?
Просто вот именно нужно чаще играть на психологических факторах: изменение "обнаруживать" дней через 15, да и то по умному... Типа программа выполнила некорректную операцию, обратитесь тудато за поддержкой... А там клиента ловить сразу надо...
И т.п....

← →
Andrews (2002-03-26 19:10) [25]

>Rooman © (23.03.02 07:11)
> "Все равно сломают" - как часто я слышу эту фразу без всякого обоснования.

А ты уверен, что твою прогу захотят ломать...

Ломают то ХИТЫ, а не все подряд и утверждение "Все равно сломают" относится к ним...

Так что затраты на защиту должны быть адекватны по крайней мере комерческой ценности программы

P.S. Надеюсь анекдот про "Неуловимого Джо" помнишь :o)

← →
Andrews (2002-03-26 19:17) [26]

← →
Rooman (2002-03-31 18:32) [27]

> Andrews © (26.03.02 19:17)

Какие нафиг затраты на защиту?
Пару лишних строчек написать по определенным правилам, с учетом защиты нормальному программисту не проблема! А вот сломать будет сложно!

← →
Rooman (2002-03-31 18:37) [28]

> Так что затраты на защиту должны быть адекватны по крайней
> мере комерческой ценности программы

Затраты на защиту должны быть адекватны действиям взломщика, имхо. Тогда, даже при малой коммерческой ценности люди предпочтут купить задешево, чем сидеть ломать... ИМХО, конечно:)

← →
JibSkeart (2002-03-31 19:45) [29]

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

If my_Proge_Registering Then --- вот .то уже глуппость ...
begin
некоторые функции доступны
типо
Button1.Enabled:=True; и во это уже глуппость ...
end

то мне даже твой ключь знать ненадо будет !

а так в принципе то прав насчет потоков
хотя по статистике
программу шароварную ломают уже на следуюший день
(если она интересна народу)

← →
Rooman (2002-03-31 20:30) [30]

> JibSkeart © (31.03.02 19:45)
> но если
> программа у тебя будет действовать так :

Разумеется, если я оперирую динамическими переменными, таких глупостей я делать не собираюсь;)

← →
хакер (2002-04-02 12:21) [31]

присылай свою прогу, взлом пришлю ровно через сутки... спорим?

← →
Vogul (2002-04-02 12:45) [32]

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

← →
eSKey (2002-04-03 18:49) [33]

Если программу привязывать к каким-то пользовательским данным, то, имхо, можно сделать так :
Имеется программа, не содержащая никаких юзер-данных, скомпиленная с пуб-ключом. Работает только в демо-моде. Юзер , который хочет купить ее специальной утилиткой генерирует хэш, "дайджест" текста, отправляет ее автору. Автор подписывает этот хэш своим секретным ключом, получает деньги %) и отправляет полученную ЦП юзеру. Ну а программа используя стандартную проверку проверяет соотв. данных/подписи, используя ключ в своем теле. Разумеется придется делать проверку целостности своего ключа, опять же по хэшу (ой).
Какие тут пути взлома: ну конечно, можно убрать/сломать проверку целостности, так на то и использовать потоки+какие-нибудь случайные события виндов. А неизменность кода кстати, правда - небольшой декриптор с пуб. ключом, а остальной код зашифрован авторским секретным ключом. Тоже снимается при желании, но все-же...
Вообще, имеет смысл если эти уникальные данные юзера принципиальны - например его реквизиты для бухгалтерской проги или неизменяемая база данных.

← →
Andrews (2002-04-03 19:22) [34]

>Rooman ©

> Тогда, даже при малой коммерческой ценности люди предпочтут купить задешево, чем сидеть ломать... ИМХО, конечно:)

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

1. Снести и забыть...
2. Все таки сломать - найти кряк...
3. Снести и заняться поисками "безпроблемного" аналога...

Купить может захотеться только после рассмотрения предыдущих вариантов...

← →
Magellan (2002-04-03 19:27) [35]

ASP не поможет...
Вот здесь: www.reversing.net полно инфы о взломе ASP, VCL и етс. почитай, может передумаешь писать шарывары :) Бесполезняк

Как обмануть хакера-крякера? Найти похожие ветки