После компиляции в среде delphi/builder и последующей декомпиляции программами аля DeDe,
в файле многое становится понятно - название используемых компонентов, переменных и т.д.
Существую ли средства, которые изменяют эти имена на неосмысленный мусор сохраняя
работоспособность программы?

| Сообщение посчитали полезным:

Проты

| Сообщение посчитали полезным:

попробуй поищи обфускаторы для дельфи, скорее всего есть

| Сообщение посчитали полезным:

А кто из протов именно имена переделывает в нечитаемые? Имхо после снятия прота все имена как на ладони..?

| Сообщение посчитали полезным:

nope пишет:
после снятия прота все имена как на ладони
Вроде как на ладони
Лучше кодить на C++, и вставлять в компилированный код антиотладку на асм (например, основываясь на командах переменной длины и т.п). А на Делфи код легко анализировать после распаковки.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

Crawler
Это ещё спорно, что легче анализировать, Delphi или С++ код после распаковки, преимущество анализа кода делфи программ только в том, что там проще найти обработчики, но зато делфи так засоряет код своими процедурами, иногда полсотни ret'ов пройдёшь и всё равно никуда не выйдешь... так что спорно это, спорно...

| Сообщение посчитали полезным:

@Paxan
какие могут быть обфускаторы для дельфи то? что обфусцировать? имена переменных / классов / методов не хранятся (разве что только РТТИ за счет которого и выезжает ДеДе, но его, имхо, не обфусцировать).

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

NaumLeNet
ты уверен? возмём кусок дампа из dede

rbNotEqu: TRadioButton;
rbMoreEqu: TRadioButton;
rbLessEqu: TRadioButton;
Splitter3: TSplitter;
paVisible: TPanel;
btVisPanel: TSpeedButton;
acAddDisk: TAction;
Adddiskwizard1: TMenuItem;
gbActors: TGroupBox;
JvEnterAsTab: TJvEnterAsTab;
ppGetInfo: TPopupMenu;
Scanneddisk1: TMenuItem;
FromInternet1: TMenuItem;
Cancel1: TMenuItem;
acGetInfoNet: TAction;
fromfile1: TMenuItem;
FromInternet2: TMenuItem;
paPictureMain: TPanel;
acFormRegister: TAction;
Register1: TMenuItem;
miNew: TMenuItem;
N4: TMenuItem;
miOpen: TMenuItem;
acNewBase: TAction;
procedure acFormFirmExecute(Sender : TObject);
procedure acFormFamilyExecute(Sender : TObject);
procedure acFormJanreExecute(Sender : TObject);
procedure acFormCodecExecute(Sender : TObject);
procedure miExitClick(Sender : TObject);
procedure acFormCategoryExecute(Sender : TObject);
procedure FormShow(Sender : TObject);
procedure cbCategoryChange(Sender : TObject);
procedure grDisksExit(Sender : TObject);
procedure grDisksEnter(Sender : TObject);
procedure grMoviesEnter(Sender : TObject);
procedure grMoviesKeyDown(Sender : TObject);
procedure acSortJanreExecute(Sender : TObject);
procedure PageControlChange(Sender : TObject);
procedure cbJanreChange(Sender : TObject);
procedure grDisksTitleClick(Sender : TObject);
procedure grMoviesTitleClick(Sender : TObject);


| Сообщение посчитали полезным:

dermatolog
всю программу в ВМ тоже не загонишь, будет тормозить

| Сообщение посчитали полезным:

Paxan пишет:
всю программу в ВМ тоже не загонишь, будет тормозить
Как правило этого и не требуется )

| Сообщение посчитали полезным:

dermatolog это смотря что хочет топег стартер. видимо не просто защитить программу от взлома, а спрятать некие алго. тут надо смотреть на месте

| Сообщение посчитали полезным:

Paxan пишет:
спрятать некие алго
Надо разрабатывать защиту так, чтобы знание алгоритма не уменьшало безопасности,(- например, аппаратная привязка). Это справедливо не только для криптографии, но и для кодинга.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

Crawler прятанье алго это прятанье некой идеи, новшества и тд. необязательно всё сводить к безопастности.

| Сообщение посчитали полезным:

типа такого ?



535b_19.08.2006_CRACKLAB.rU.tgz - dda3.gif

| Сообщение посчитали полезным:

DDA пишет:
типа такого ?

прикольно но честно я очень редко пользуюсь ДеДе и таким не остановишь...

а по вопросу, во многих протах есть такая фишка как "маркеры" - crypt и clear, попробуй

-----
[nice coder and reverser]

| Сообщение посчитали полезным:

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

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Вот еще одна методика строки шифровать, на мой взгляд, довольно удачная реализвция.

Цитата:

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

"расшифровывается по мере необходимости" - вот это мне больше всего понравилось в Delphi String Protect


--> СКАЧАТЬ (541 Кб, Версия 1.1) <-- http://bgsopt.com/dsp10.zip

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

я про этот Delphi String Protect и говорил, попалась прога-лажа-2003годаб10;стоит ,а мучался дня 3. вот кстати ссылка http://exelab.ru/f/action=vthread&topic=6198&forum=5&page= -1

| Сообщение посчитали полезным:

sats, тоже ее есследовал, только вот сложного там ничего не нашол. Шифрование строк там впринцепе и не нужно, процедура проверки находится очень легко...

MiHaN пишет:
Единственный выход - шифрование важных функций, причём желательно с привязкой к ID

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

_________________________

Незнаю насколько ниже написанное будет по теме, вобщем встретил вот электронную книжку, защищенную протектором с COINSOFT.RU

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

Если кому интересно - могу залить книгу с ключами...

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

MiHaN пишет:
При сохранении возможности декомпиляции, скрытие строк бесполезно
Угу. Пишется простенький скрипт для IDA (или отдельный дешифровщик - код выдирается прямо из проги). После чего все 'шифрование' превращается в бесполезное украшение.

| Сообщение посчитали полезным:

to gazlan хмммюююкак я понимаю для дешифрования необходимо знать алгоритм шифрования, или как? или ты имел в виду, что выдирание происходит тогда,когда шифрованный текст дешифруется для вывода пользователю или ёще для чего-нибудь?

| Сообщение посчитали полезным:

Помню конкретно от DeDe как то помогла такая фича.
Открываем ехе-шник, ищем по тексту "TObject" и меняем на "TОbject" (во втором случае "О" русская).
После этого DeDe обломался.

| Сообщение посчитали полезным:

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

PUSH Encrypted_String
CALL Decoder
// Do smth with EAX here

Другой частый трюк - вызов декодера в начале функции и энкодера - в конце. При вызове зашифрованная функция расшифровывает себя в памяти, выполняется - и снова зашифровывает (обычно, через ROL/ROR).

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

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

Стойкость алгоритма не имеет значения - ключ всегда 'под ковриком'.

| Сообщение посчитали полезным:

А что-то про KOL никто не вспомнил ?
После неё в DeDe бесполезен.

| Сообщение посчитали полезным:

xDriver пишет:
А что-то про KOL никто не вспомнил ?
После неё в DeDe бесполезен.
В KOL API юзаются стандартно (почти как в VC++) и бряк на GetWindowText тебе поможет

| Сообщение посчитали полезным:

MiHaN
Для танкистов ...... вопрос был поставлен так:
nope пишет:
После компиляции в среде delphi/builder и последующей декомпиляции программами аля DeDe,
в файле многое становится понятно - название используемых компонентов, переменных и т.д.
Существую ли средства, которые изменяют эти имена на неосмысленный мусор сохраняя
работоспособность программы?

какие API ? какой GetWindowText ?

| Сообщение посчитали полезным: