Шифровка значений констант в Дельфи

← →
arbin (2008-08-21 10:42) [0]

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

← →
Сергей М. © (2008-08-21 10:43) [1]

Не существует.

← →
brother © (2008-08-21 10:45) [2]

только самописно... можно хранить уже шифрованное значение (хоть xor) и при обращении декодировать в нормальный вид на лету... это как вариант...

← →
Сергей М. © (2008-08-21 10:47) [3]

> brother © (21.08.08 10:45) [2]

Истинные маньяки-извращенцы создают и подключают к IDE свой эксперт)

← →
Palladin © (2008-08-21 10:54) [4]

> arbin (21.08.08 10:42)

в топку такие программы... и аффтаров следом

← →
DVM © (2008-08-21 12:24) [5]

> Palladin © (21.08.08 10:54) [4]

> в топку такие программы... и аффтаров следом

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

← →
Leonid Troyanovsky © (2008-08-21 13:04) [6]

> DVM © (21.08.08 12:24) [5]

> > в топку такие программы... и аффтаров следом

> Ну почему же сразу в топку. Например, для организации защиты
> программы с помощью ключа Guardant

И Guardant - следом.

--
Regards, LVT.

← →
DVM © (2008-08-21 13:08) [7]

> И Guardant - следом.

Что так?

← →
Leonid Troyanovsky © (2008-08-21 13:46) [8]

> DVM © (21.08.08 13:08) [7]

> Что так?

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

--
Regards, LVT.

← →
Ega23 © (2008-08-21 13:56) [9]

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

Самое простое - хранить не пароль, а его хэш.

← →
Anatoly Podgoretsky © (2008-08-21 15:39) [10]

> Leonid Troyanovsky (21.08.2008 13:46:08) [8]

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

← →
Правильный$Вася (2008-08-21 20:04) [11]

если уж хочется хранить пароль, то можно его разодрать на кусочки, а где-то в коде собирать по нужному тебе алгоритму

← →
DVM © (2008-08-22 10:50) [12]

> Anatoly Podgoretsky © (21.08.08 15:39) [10]

> Leonid Troyanovsky © (21.08.08 13:46) [8]

Вот фрагмент обычной схемы работы с ключом (взято из примеров, поставляемых с их SDK):
{ Initialize this copy of GrdAPI. GrdStartup() must be called once before first GrdAPI call at application startup } writeln("Initialize this copy of GrdAPI : " ); nRet:=GrdStartup(GrdFMR_Local); ErrorHandling(nil,nRet); { Create Grd protected container & return it"s handle } writeln("Create Grd protected container : " ); hGrd:= GrdCreateHandle(@abyGrd, { pointer to memory allocated for Grd protected container } { if NULL, Grd API allocates memory for new Grd protected container by itself } GrdCHM_MultiThread, { handle can by use in multy-thread } nil ); { reserved and must be 0 } if( hGrd = nil ) then { Some error found? } halt(ErrorHandling(nil, GrdE_MemoryAllocation )); ErrorHandling(hGrd,nRet); { Store dongle codes in Guardant protected container } writeln("Storing dongle codes in Guardant protected container : " ); nRet:= GrdSetAccessCodes(hGrd, { Handle to Guardant protected container } CryptPU, { Must be already specified } CryptRD, { Must be already specified } CryptWR, { == 0 if not needed } CryptMS); { == 0 if not needed } ErrorHandling(hGrd,nRet);

Обратите внимание на функцию GrdSetAccessCodes и передаваемые ей ключи, в частности CryptPU и CryptRD. Первый это ключ Public, второй Read, т.е. для чтения. Если программа хочет считать значения из ячеек памяти эл.ключа, то ей не обойтись без CryptRD ключа. И его как ни крути придется помещать в код программы. Ну пусть не в открытом виде, а как то зашифрованном, но придется все равно. Но даже если ключ будет закодирован, то в исполняемом файле все равно будет и функция декодирования ключа, изучив которую можно будет получить исходное значение ключа. Вот строчка из SDK описания этой функции:

Важная информация
Рекомендуется хранить коды доступа в приложении в зашифрованном виде и динамически собирать их и проверять их целостность непосредственно перед помещением в хэндл. Не следует хранить коды "в чистом виде".

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

← →
DVM © (2008-08-22 10:52) [13]

> Правильный$Вася (21.08.08 20:04) [11]

> то можно его разодрать на кусочки, а где-то в коде собирать
> по нужному тебе алгоритму

Но алгоритм тоже будет в этом коде. Т.е. ключ все равно будет в коде программы.

← →
Anatoly Podgoretsky © (2008-08-22 10:55) [14]

> DVM (22.08.2008 10:50:12) [12]

Плохо

← →
Anatoly Podgoretsky © (2008-08-22 10:57) [15]

> Но алгоритм тоже будет в этом коде. Т.е. ключ все равно
> будет в коде программы.

Многие верят в защиту.
Некто сказал - нет человека, нет проблем. Вот это единственная рабочая защита, вскрывается терморектальным криптоанализатором.

← →
DVM © (2008-08-22 11:02) [16]

> Anatoly Podgoretsky © (22.08.08 10:55) [14]

Но тем не менее ключи Guardant Stealth III одни из самых стойких.
А как по другому то? Ведь программа должна как то идентифицировать ключ свой-чужой, соответственно ключ должен понять программа своя-чужая и им по всей видимости не обойтись без обмена некоторыми значениями, которые как ни крути будут храниться в программе (если только их не будет вводить пользователь с клавиатуры).

← →
Игорь Шевченко © (2008-08-22 11:43) [17]

> Например, для организации защиты программы с помощью ключа
> Guardant может потребоваться хранить в исполняемом файле
> ряд ключей

Защищал с помощью ключа Guardant, в исполняемом файле не хранил ни ряд ключей, ни единственный ключ.

Что я делал не так ?

← →
brother © (2008-08-22 11:50) [18]

> Защищал с помощью ключа Guardant, в исполняемом файле не
> хранил ни ряд ключей, ни единственный ключ.

в отдельном, шибко хитро зашифрованном файле? в БД, на бумажке у юзверя, по сети? ;)

← →
Игорь Шевченко © (2008-08-22 12:06) [19]

> в отдельном, шибко хитро зашифрованном файле? в БД, на бумажке
> у юзверя, по сети? ;)

да мало ли на свете источников

← →
DVM © (2008-08-22 12:11) [20]

> Игорь Шевченко © (22.08.08 11:43) [17]
>
>

> Защищал с помощью ключа Guardant, в исполняемом файле не
> хранил ни ряд ключей, ни единственный ключ.

Автоматическую защиту что ли использовал? Так там все за тебя сделали и в исполнямый файл ключ тоже поместили :)

← →
Anatoly Podgoretsky © (2008-08-22 12:12) [21]

> DVM (22.08.2008 11:02:16) [16]

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

← →
Anatoly Podgoretsky © (2008-08-22 12:13) [22]

> brother (22.08.2008 11:50:18) [18]

Начнем с того, а для чего там стоит аппаратный ключ?

← →
DVM © (2008-08-22 12:15) [23]

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

GrdStartup()
GrdCreateHandle()
GrdSetAccessCodes()
GrdSetFindMode()
GrdFind()
GrdLogin()
...тут работаем....
GrdLogout()
GrdCloseHandle()
GrdCleanup()

> а для чего там стоит аппаратный ключ?

упс )

> arbin (21.08.08 10:42)

Например, правишь строки в DFM-файле, заменяя их на шифрованные.
В программе перед использованием делаешь расшифровку.

> Автоматическую защиту что ли использовал? Так там все за
> тебя сделали и в исполнямый файл ключ тоже поместили :)

Нет, не помещали ключ в исполняемый файл. Ключ прошивался в само устройство, а открытый ключ натурально распространялся вместе с EXEшником, отдельным небольшим файлом

> Игорь Шевченко © (22.08.08 13:47) [27]

А каким образом происходила проверка в программе, что ключ вставленный в порт это ваш ключ? Последовательность вызова функций одна и я ее привел в [23]. GrdSetAccessCodes для прав чтения данных из аппаратного ключа требует числовой ключ для чтения.

DVM © (22.08.08 13:55) [28]

> А каким образом происходила проверка в программе, что ключ
> вставленный в порт это ваш ключ?

А хоть и не наш - этот ключ использовался для расшифровки неких данных, согласно прошитому в нем ключу. Если там не наш ключ - данные не расшифруются, ну и соответственно...

> Не отшутивайся, я же серьезно спросил.

а он там стоит? если да, то как раз для "железной" идентификации...

Есть ведь очень простой способ: берем флешку. Совсем любую, в т. ч. за 250 руб купленную в переходе. У флешки есть номер - это число типа Cardinal. Вот и ключ самый простой. На него-то и делим придешифровке. А для хакеров пишем различные ненужные файлы на флешку и массу бессмысленных чтений этих файлов.

← →
имя (2008-08-26 22:47) [32]

Удалено модератором

> На него-то и делим придешифровке. А для хакеров пишем различные
> ненужные файлы на флешку и массу бессмысленных чтений этих
> файлов.

а тупые хакеры никак не смогут увидеть, что в программе происходит считывание серийного номера флешки? ;) Под отладчиком все ж видно будет, кого вы хотите обмануть?

Шифровка значений констант в Дельфи Найти похожие ветки