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

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

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

Защита от перезаписи кодав памяти

Mundrik © (2008-09-05 14:37:00)
Пишу на delphi 2007.
Подскажите, возможно ли защитить загруженное приложение от изменения его кода другими процессами, а главное через модификацию динамически загружаемых библиотек?

Renegat (2008-09-06 17:47:00) [1]
> [18] palva © (06.09.08 17:09)

=)

http://www.delphimaster.ru/cgi-bin/forum.pl?n=3&id=1220267957

palva (2008-09-06 17:09:00) [2]

> откажись от dll, реализуй весь ее функционал в своей проге. dll зло.

А что делать, если dll уже украдена, а реализовать ее функционал я не умею? :(

sniknik (2008-09-06 11:12:00) [3]
> Servy, да это разве усилия ))
> а можно ещё пару других идей? )
можно еще одну.

> путем модификации сторонней, динамически загружаемой моей прогой dll.
откажись от dll, реализуй весь ее функционал в своей проге. dll зло.

Сергей М. (2008-09-06 10:56:00) [4]

> неужели никак от этого на защититься?

Со 100%-й гарантией - никак.

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

Servy (2008-09-05 21:56:00) [5]
Да в гугле тебе этих идей три вагона найдется, если усилий-то не жалко :).

Самый верный способ был предложен еще в [8]. Отлаживать какие-нибудь VisualBasic приложения мало какой адекватный человек станет. Правда для Visual Basic'а наверняка уже тулз понаписали, чтобы облегчить сей процесс, а вот если использовать что-нибудь малоизвестное, или свое - потенциальный ломатель 10 лет угробит, чтобы разобраться.

Также из универсальных советов, которые как-то высказывались на этом форуме в подобных темах - использовать многопоточность (многонитевость, как ее кое-кто любит величать ^^) для проверки своей зарегестрированности/целостности, так как дебажить такие приложения то еще удовольствие. Не хранить зарегестрированно/не зарегистрированно в одном месте, не делать функций IsRegistered: Boolean, так как это место довольно быстро найдут и поменяют. Должно быть несколько проверок в разных местах, зависящих от разных параметров. Также, стоит почаще обращаться к переменным, отвечающим за регистрацию (ну ключ, файл .slip или что там у тебя для регистрации используется), и проводить над ними длительные бесполезные рассчеты, чтобы потенциальный взломщик заколебался искать, где же именно у тебя проверка на зарегистрированность. Проверять время выполнения небольшого участка кода, который на любой машине будет выполнятся доли секунды. Если выполняется больше секунды - ахтунг, нас отлаживают, ставим флаг, через пару минут разваливаемся. Вот все, что вспомнилось сходу.

Mundrik (2008-09-05 21:10:00) [6]
Servy, да это разве усилия ))
а можно ещё пару других идей? )

Servy (2008-09-05 20:41:00) [7]
> вот смотрите, в внедренном в dll коде будет только команды
> изменения в моей проге байтика, отвечающего за регистрацию
> "optRegister: Boolean " сам код естественно будет не тронут.

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

Mundrik (2008-09-05 20:19:00) [8]
Сергей М., вот смотрите, в внедренном в dll коде будет только команды изменения в моей проге байтика, отвечающего за регистрацию "optRegister: Boolean " сам код естественно будет не тронут.

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

неужели никак от этого на защититься?

а разного рода протекторы типа asprotect как-то контролируют эти моменты? а то получается один фиг в памяти уже в распакованном виде байтик изменил и весь протект коту под хвост..

Сергей М. (2008-09-05 19:43:00) [9]

> хоть чуть чуть поподробней

Ну, скажем, контрольная сумма участка кода перед передачей ему управления.

Mundrik (2008-09-05 19:23:00) [10]
Renegat, не удержался от остроумной реплики?
мне не стока уже ту прогу защищать как сам процесс понять можно или нет.. на будущее так сказать ЦЕ знать..

KilkennyCat (2008-09-05 19:22:00) [11]

> раз уж так важна защита кода...

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

Renegat (2008-09-05 18:44:00) [12]
может быть, ст0ит написать свою виртуальную машину и перегнать прогу в специфические команды этой ВМ?
ЗЫ. я знаю что це на грани безумия %) однако, раз уж так важна защита кода...

Mundrik (2008-09-05 18:20:00) [13]
не )) но тоже так подламывают..

Сергей М. ©, "Кой-какие меры можно, конечно, предпринять" хоть чуть чуть поподробней )

Rouse_ (2008-09-05 18:17:00) [14]

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

Эммм... офффтоп. Это не ты случаем ГосСтройСмету пишешь? :) А то в своей практике встречал я ее, как раз так и подламывалась ;)

Mundrik (2008-09-05 17:22:00) [15]
насчет внедрить свои не знаю, но взлом братья по разуму делают путем модификации сторонней, динамически загружаемой моей прогой dll.

допустим в проге есть переменная optRegister: Boolean;
подскажите пожалуйста как можно запретить\затруднить изменение данной переменной?

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

evvcom (2008-09-05 15:07:00) [16]

> а главное через модификацию динамически загружаемых библиотек?

а зачем модифицировать твои dll, если проще внедрить свои?

Сергей М. (2008-09-05 14:50:00) [17]

> Mundrik

Кой-какие меры можно, конечно, предпринять, но 100%-й гарантии это в любом случае не даст.

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

Rouse_ (2008-09-05 14:39:00) [18]
Нельзя

Ega23 (2008-09-05 14:38:00) [19]
Ты сначала скажи, что ты хочешь сделать.

Наверх

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