Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Шифровка значений констант в Дельфи [D5, WinXP]

Страницы: 1 2 >
arbin © (2008-08-21 10:42:00)
Добрый день.
Существует ли возможность стандартными средствами Дельфи при компиляции осуществить простейшую шифровку значений констант и начальных значений переменных, прописанных в коде в явном виде (например, для проверки пароля), так как в случае открытия полученного екзешника в любом редакторе, все эти значения констант легко обнаруживаются, что позволяет узнать пароль даже без дизассемблирования.
Спасибо.

Deep (2008-08-31 00:04:00) [1]

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

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

(2008-08-26 22:47:00) [2]
Удалено модератором

TStas (2008-08-26 21:22:00) [3]
Есть ведь очень простой способ: берем флешку. Совсем любую, в т. ч. за 250 руб купленную в переходе. У флешки есть номер - это число типа Cardinal. Вот и ключ самый простой. На него-то и делим придешифровке. А для хакеров пишем различные ненужные файлы на флешку и массу бессмысленных чтений этих файлов.

brother (2008-08-25 05:08:00) [4]
> Не отшутивайся, я же серьезно спросил.

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

Игорь Шевченко (2008-08-22 14:16:00) [5]
DVM © (22.08.08 13:55) [28]

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

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

DVM (2008-08-22 13:55:00) [6]

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

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

Игорь Шевченко (2008-08-22 13:47:00) [7]

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

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

Anatoly Podgoretsky (2008-08-22 13:07:00) [8]

> brother © (22.08.08 12:24) [24]

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

Jeer (2008-08-22 12:52:00) [9]

> arbin (21.08.08 10:42)

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

brother (2008-08-22 12:24:00) [10]
> а для чего там стоит аппаратный ключ?

упс )

DVM (2008-08-22 12:15:00) [11]
Автоматическая защита - это полумера. Не может считаться надежной. Об этом говорят и сами создатели ключа. Наилучшие результаты дает сочетание автоматической защиты и защиты на уровне GuardantAPI. А защита на уровне API требует хранения ключа, т.к. защита использует цепочку функций API:

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

Anatoly Podgoretsky (2008-08-22 12:13:00) [12]
> brother (22.08.2008 11:50:18) [18]

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

Anatoly Podgoretsky (2008-08-22 12:12:00) [13]
> DVM (22.08.2008 11:02:16) [16]

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

DVM (2008-08-22 12:11:00) [14]

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

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

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

Игорь Шевченко (2008-08-22 12:06:00) [15]

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

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

brother (2008-08-22 11:50:00) [16]
> Защищал с помощью ключа Guardant, в исполняемом файле не
> хранил ни ряд ключей, ни единственный ключ.

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

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

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

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

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

DVM (2008-08-22 11:02:00) [18]

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

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

Anatoly Podgoretsky (2008-08-22 10:57:00) [19]

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

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

Anatoly Podgoretsky (2008-08-22 10:55:00) [20]
> DVM (22.08.2008 10:50:12) [12]

Плохо

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »