Здравствуйте, WoldemaR, Вы писали:
WR>Есть некая функция. можно с++, можно extern "C".
WR>я её тело копирую в свободный (в куче) участок памяти.
WR>запускаю через кастинг указателей.
WR>выскакивает ACCESS VIOLATION на совершенно бредовый адрес.
WR>Доктор. Скажите, это как-то лечится?
Боюсь, что нет. Куча — это сегмент данных, там разрешены чтение и запись, но не выполнение (execution).
Если только в операционной системе нет средств позволяющих переназначать атрибуты защиты памяти.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, WoldemaR, Вы писали:
WR>>Есть некая функция. можно с++, можно extern "C".
WR>>я её тело копирую в свободный (в куче) участок памяти.
WR>>запускаю через кастинг указателей.
WR>>выскакивает ACCESS VIOLATION на совершенно бредовый адрес.
WR>>Доктор. Скажите, это как-то лечится?
WoldemaR wrote: > Есть некая функция. можно с++, можно extern "C". > я её тело копирую в свободный (в куче) участок памяти. > запускаю через кастинг указателей. > выскакивает ACCESS VIOLATION на совершенно бредовый адрес. > Доктор. Скажите, это как-то лечится?
В-нулевых, все это жуткий UB и может работать только на определенных
системах.
Во-первых, если код — не Position Independent, то ничерта работать не
будет. Для генерации PIC нужно использовать опции компилятора (-fPIC для
GCC).
Во-вторых, может быть важно выравнивание.
В-третьих, на сегменте данных скорее всеог стоит защита от исполнения. В
винде для руления правами можно использовать функцию VirtualProtect. В
Линуксе — не помню, но тоже можно.
WR>Есть некая функция. можно с++, можно extern "C". WR>я её тело копирую в свободный (в куче) участок памяти. WR>запускаю через кастинг указателей. WR>выскакивает ACCESS VIOLATION на совершенно бредовый адрес.
Начнем от простого к сложному.
1) Откуда ты знаешь диапазон адресов где лежит функция? Она между прочим запросто может быть разбросана компилером кусками с jmp'ами туда-сюда по разным местам, если ему так захочется.
2) Внутри твоей функции есть вызовы других функций? Обращения к глобальным переменным? В таком случае тебе надо будет ее в процессе копирования диззассемблировать, найти все относительные jmp'ы и откорректировать согласно новому положению их в памяти.
WR>Доктор. Скажите, это как-то лечится?
Нет, генная инженерия пока не настолько развита.
Здравствуйте, WoldemaR, Вы писали:
WR>Есть некая функция. можно с++, можно extern "C". WR>я её тело копирую в свободный (в куче) участок памяти. WR>запускаю через кастинг указателей. WR>выскакивает ACCESS VIOLATION на совершенно бредовый адрес. WR>Доктор. Скажите, это как-то лечится?
Там снизу уже на все ответили. Но я все-таки влезу и спрошу:
зачем, зачем, зачем, ДА КАКОГО ДЬЯВОЛА ТЫ ВСЕ ЭТО ДЕЛАЕШЬ?
Не смогу спать, пока не получу ответ...
Тот, кто желает, но не делает, распространяет чуму.
"WoldemaR" <15414@users.rsdn.ru> wrote in message news:2080508@news.rsdn.ru... > Есть некая функция. можно с++, можно extern "C". > > я её тело копирую в свободный (в куче) участок памяти. > > запускаю через кастинг указателей. > > выскакивает ACCESS VIOLATION на совершенно бредовый адрес. > > Доктор. Скажите, это как-то лечится?
Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.
Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ
Похоже это решение поставлено на поток. А ведь это как красная тряпка для быка.
Жаль ещё и потому, что неполучается реализовать это дело втихаря. — То копировать нельзя, то запускать...
Ой, неспроста оно так сделано, ой неспроста...
> S>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла. > > Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ > Похоже это решение поставлено на поток. А ведь это как красная тряпка для быка.
А толку-то? Время от времени при работе программы работы перезаписывать туда новые функции — ни дампер, ни патчер памяти не поможет. Тока придется научиться применять релокейшены
> Жаль ещё и потому, что неполучается реализовать это дело втихаря. — То копировать нельзя, то запускать...
Ну заметят твои вызовы VirtualProtect, и дальше что? Бинарник-то просто-так не поправишь, нужный кусок шифрованный. И вылазит столько геморроя — найти и расшифровать все кодированные секции (а они изначально общей кучкой в секции данных лежат), предварительно идентифицировав алгоритм шифрования и найдя в бинарнике открытый ключ (а дампить мало поможет, некоторые куски не чаще раза в месяц должны использоваться), отломать расшифровывалку и вставить на ее место просто копировщик и применяльщик релокейшенов — что нафиг оно кому нужно, такую гадость ломать.
> Ой, неспроста оно так сделано, ой неспроста...
Разные аттрибуты защиты для разных секций? Конечно неспроста — для пущего отлова ошибок.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, Sergey, Вы писали:
S>>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.
WR>Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ
Ну так может тебе так и сделать?
Есть набор функций, выполняющих элементарные действия.
Алгоритм программы состоит в последовательности вызовов этих функций.
Последовательность задается строкой (типа байт-кода).
Строка перед использованием шифруется-дешифруется.
Здравствуйте, rus blood, Вы писали:
RB>Ну так может тебе так и сделать? RB>Есть набор функций, выполняющих элементарные действия. RB>Алгоритм программы состоит в последовательности вызовов этих функций. RB>Последовательность задается строкой (типа байт-кода). RB>Строка перед использованием шифруется-дешифруется.
Нет. мне кажется, что этот вариант ненадёжен. Потому как есть одно узкое место — красная тряпка.
лучше если обращение к критическому коду будет разбросанно по всему телу проги.
Здравствуйте, WoldemaR, Вы писали:
WR>Есть некая функция. можно с++, можно extern "C".
WR>я её тело копирую в свободный (в куче) участок памяти.
WR>запускаю через кастинг указателей.
WR>выскакивает ACCESS VIOLATION на совершенно бредовый адрес.
WR>Доктор. Скажите, это как-то лечится?
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, rus blood, Вы писали:
RB>>Ну так может тебе так и сделать? RB>>Есть набор функций, выполняющих элементарные действия. RB>>Алгоритм программы состоит в последовательности вызовов этих функций. RB>>Последовательность задается строкой (типа байт-кода). RB>>Строка перед использованием шифруется-дешифруется.
WR>Нет. мне кажется, что этот вариант ненадёжен. Потому как есть одно узкое место — красная тряпка. WR>лучше если обращение к критическому коду будет разбросанно по всему телу проги.
Что ж, ситуация прояснилась, снова могу спать.
А действительно ли необходимо динамически подменять именно куски кода?
Может быть, разнообразить программу безусловными переходами, адреса для которых будут браться из ячеек данных? Представим, что программа периодически лазит в некоторую ячейку памяти и вытаскивает оттуда адрес для джампа, каждый раз разный. А попадает этот адрес в эту ячейку в совершенно другом месте кода. Точку в программе, где этот адрес в очередной раз задается, от точки, где он потом используется, может отделять мегабайт ассемблерного кода.
Чем такое не подходит?
Тот, кто желает, но не делает, распространяет чуму.
Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка.
А хотелось что нибудь незаметно-тривиальное.
Здравствуйте, WoldemaR, Вы писали:
WR>Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка.
Э-э-э, оператор new, функции типа malloc — это все "фичи" языка и библиотек.
На конкретной платформе они сводятся с вызовам системных функций.
Под windows это будет HeapAlloc, или что-то аналогичное.
Так что непонятно, где ты здесь видишь нестандартность...
Здравствуйте, WoldemaR, Вы писали:
WR>А хотелось что нибудь незаметно-тривиальное. WR>Кстати, как скопировать функцию так и не ясно...
Вообще, обычно занимаются не сокрытием места использования кода, а просто шифровкой его участков без всякого перемещения.
Причём, чтобы не закладываться на расположение функций и их размер, используют сигнатуры. Потом криптуют внешним криптором эти участки.
Далее, если использовать в лоб — расшифровываем на лету перед вызовом функции ключом, ставим обработчик исключений и вызываем. В случае неверного ключа вызывается исключение, т.к. код расшифровался неверно. Или же (правильнее) проверять контрольную сумму расшифрованного участка, чтобы избежать бесполезного вызова. Не имея ключа расшифровать код будет невозможно, вне зависимости от того, видны ли
эти трюки или же они скрыты за полиморфом/метаморфом.
WR>Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка. WR>А хотелось что нибудь незаметно-тривиальное.
WR>Кстати, как скопировать функцию так и не ясно...
Чисто для справки — malloc из msvcrt.dll (та что dynamic CRT) это почти прямой вызов HeapAlloc.
Еще раз повторю — почти все вызовы внешних функций в x32 коде — это относительные jmp'ы/call'ы. Так что даже если ты перенесешь удачно код своей функции в новый участок она там будет неработоспособна без коррекции этого самого кода. Врядли эта твоя функция "вся в себе", скорее всего у нее есть вызовы других функций, и из самой длл и апи, что по сути неважно. Прежде чем применять термины типа "красная тряпка", советую глянуть хотябы дизасм функции которую хочешь перенести. С начала и до конца, внимательно смотря на сами инструкции типа jmp и call и на то как они выглядят в памяти.
> WR>Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка. > WR>А хотелось что нибудь незаметно-тривиальное. > > WR>Кстати, как скопировать функцию так и не ясно... > Чисто для справки — malloc из msvcrt.dll (та что dynamic CRT) это почти прямой вызов HeapAlloc.
Ты же сам написал — из msvcrt.dll. А не из MyCoolApp.exe или MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp, и сразу становится ясно, где расположен код распаковщика.
> Еще раз повторю — почти все вызовы внешних функций в x32 коде — это относительные jmp'ы/call'ы. Так что даже если ты перенесешь удачно код своей функции в новый участок она там будет неработоспособна без коррекции этого самого кода. Врядли эта твоя функция "вся в себе", скорее всего у нее есть вызовы других функций, и из самой длл и апи, что по сути неважно. Прежде чем применять термины типа "красная тряпка", советую глянуть хотябы дизасм функции которую хочешь перенести. С начала и до конца, внимательно смотря на сами инструкции типа jmp и call и на то как они выглядят в памяти.
В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Ты же сам написал — из msvcrt.dll. А не из MyCoolApp.exe или MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp, и сразу становится ясно, где расположен код распаковщика.
Я это к тому что необязательно выделять память через HeapAlloc как в примере на пост выше
>> Еще раз повторю — почти все вызовы внешних функций в x32 коде — это относительные jmp'ы/call'ы. Так что даже если ты перенесешь удачно код своей функции в новый участок она там будет неработоспособна без коррекции этого самого кода. Врядли эта твоя функция "вся в себе", скорее всего у нее есть вызовы других функций, и из самой длл и апи, что по сути неважно. Прежде чем применять термины типа "красная тряпка", советую глянуть хотябы дизасм функции которую хочешь перенести. С начала и до конца, внимательно смотря на сами инструкции типа jmp и call и на то как они выглядят в памяти.
S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что >по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.
Релоками в таблице импортов настраиваются вызовы к внешним функциям относительно данного модуля. И используются они когда модуль грузится не по той image base на которую рассчитан. А вызовы чисто _внутренних_ функций и джампы _внутри_ длл — относительные и в таблице фиксапов никак не упоминаются ибо при загрузке модуля по другой базе их трогать не надо — относительные адреса то остались теми же.. А тут человек хочет перенести ну другую базу какой то участок кода длл. Называется — почуствуй разницу.
>S>Ты же сам написал — из msvcrt.dll. А не из MyCoolApp.exe или MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp, и сразу становится ясно, где расположен код распаковщика. > Я это к тому что необязательно выделять память через HeapAlloc как в примере на пост выше
Необязательно. Можно еще VirtualProtect вызвать Но он тоже очень заметен
> >>> Еще раз повторю — почти все вызовы внешних функций в x32 коде — это относительные jmp'ы/call'ы. Так что даже если ты перенесешь удачно код своей функции в новый участок она там будет неработоспособна без коррекции этого самого кода. Врядли эта твоя функция "вся в себе", скорее всего у нее есть вызовы других функций, и из самой длл и апи, что по сути неважно. Прежде чем применять термины типа "красная тряпка", советую глянуть хотябы дизасм функции которую хочешь перенести. С начала и до конца, внимательно смотря на сами инструкции типа jmp и call и на то как они выглядят в памяти. > > S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что >по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные. > Релоками в таблице импортов настраиваются вызовы к внешним функциям относительно данного модуля. И используются они когда модуль грузится не по той image base на которую рассчитан.
К IAT релокейшены отношения не имеют, про IAT лоадеру и так известно. Грубо говоря, он просто пишет в нужное место таблицы результат соответствующего GetProcAddress. А в теле программы есть либо вызов через переходник, либо косвенный вызовов по адресу из IAT.
А вот для внутримодульных косвенных вызовов уже нужны релокейшены — например, адреса в таблицах виртуальных функций кто-то должен поправить.
> А вызовы чисто _внутренних_ функций и джампы _внутри_ длл — относительные и в таблице фиксапов никак не упоминаются ибо при загрузке модуля по другой базе их трогать не надо — относительные адреса то остались теми же.. А тут человек хочет перенести ну другую базу какой то участок кода длл. Называется — почуствуй разницу.
Никто и не говорил, что будет легко Проблема с относительными вызовами решается аккуратным программироавнием и выносом всего сильно звязанного стаффа в отдельную секцию. Шифровать и переменщать при этом надо всю секцию. Если понадобилось что-то из другой секции, извольте обеспечить косвенный вызов — информация о нем попадет в .reloc и его можно будет благополучно пропатчить.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
>>S>Ты же сам написал — из msvcrt.dll. А не из MyCoolApp.exe или MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp, и сразу становится ясно, где расположен код распаковщика. >> Я это к тому что необязательно выделять память через HeapAlloc как в примере на пост выше
S>Необязательно. Можно еще VirtualProtect вызвать Но он тоже очень заметен
VirtualProtect надо вызывать только если в системе включен DEP и target апликуха работает под ним (что само по себе очень редко бывает). А иначе в винде мона исполняеть readable-области памяти.
>> >>>> Еще раз повторю — почти все вызовы внешних функций в x32 коде — это относительные jmp'ы/call'ы. Так что даже если ты перенесешь удачно код своей функции в новый участок она там будет неработоспособна без коррекции этого самого кода. Врядли эта твоя функция "вся в себе", скорее всего у нее есть вызовы других функций, и из самой длл и апи, что по сути неважно. Прежде чем применять термины типа "красная тряпка", советую глянуть хотябы дизасм функции которую хочешь перенести. С начала и до конца, внимательно смотря на сами инструкции типа jmp и call и на то как они выглядят в памяти. >> >> S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что >по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные. >> Релоками в таблице импортов настраиваются вызовы к внешним функциям относительно данного модуля. И используются они когда модуль грузится не по той image base на которую рассчитан.
S>К IAT релокейшены отношения не имеют, про IAT лоадеру и так известно. Грубо говоря, он просто пишет в нужное место таблицы результат соответствующего GetProcAddress. А в теле программы есть либо вызов через переходник, либо косвенный вызовов по адресу из IAT. >> Релоками в таблице импортов настраиваются вызовы
Тут я просто зарапортовался. Читать — в заголовке модуля.
S>А вот для внутримодульных косвенных вызовов уже нужны релокейшены — например, адреса в таблицах виртуальных функций кто-то должен поправить.
>> А вызовы чисто _внутренних_ функций и джампы _внутри_ длл — относительные и в таблице фиксапов никак не упоминаются ибо при загрузке модуля по другой базе их трогать не надо — относительные адреса то остались теми же.. А тут человек хочет перенести ну другую базу какой то участок кода длл. Называется — почуствуй разницу.
S>Никто и не говорил, что будет легко Проблема с относительными вызовами решается аккуратным программироавнием и выносом всего сильно звязанного стаффа в отдельную секцию. Шифровать и переменщать при этом надо всю секцию. Если понадобилось что-то из другой секции, извольте обеспечить косвенный вызов — информация о нем попадет в .reloc и его можно будет благополучно пропатчить.
Просто на самом деле я сильно подозреваю что человек даже не подозревает какой геммор хочет осуществить . Я еще иногда встречаю когда компилер отдельные (даже не общие с другими функциями, а просто так) участки кода выносит хз куда и делает туда джамп, а потом оттуда назад в функцию. В результате код выглядит примерно так:
//начало функции
//чета делаем
jmp метка2:
//чета делаем
метка1:
//чета делаем
//конец функции
ret
//начало другой функции
//чета делаем
//конец другой функции
//начало третьей функции
//чета делаем
//конец третьей функции
метка2:
//чета делаем
//jmp метка 1
Ну и различные вариации — вплоть до того что середина или конец функции может оказаться раньше ее начала, вкупе с относительной адресацией это выйдет в том что реализация подобной защиты окажется по трудозатратам дороже чем ее взлом
> S>Необязательно. Можно еще VirtualProtect вызвать Но он тоже очень заметен > > VirtualProtect надо вызывать только если в системе включен DEP и target апликуха работает под ним (что само по себе очень редко бывает). А иначе в винде мона исполняеть readable-области памяти.
Можно. Только у WoldemaR почему-то не получилось. Почему — не очень понятно. При включенном хардварном DEP у него бы все ATL/WTL'ные программы бы отваливались (полвинды, грубо говоря). Может он просто FlushInstructionCache не вызвал? А написал VirtualAlloc — фишка по-другому легла и кэш сбросился.
> Просто на самом деле я сильно подозреваю что человек даже не подозревает какой геммор хочет осуществить .
Мне тоже так показалось
> Я еще иногда встречаю когда компилер отдельные (даже не общие с другими функциями, а просто так) участки кода выносит хз куда и делает туда джамп, а потом оттуда назад в функцию. В результате код выглядит примерно так: > > //начало функции > //чета делаем > jmp метка2: > //чета делаем > метка1: > //чета делаем > //конец функции > ret > > //начало другой функции > //чета делаем > //конец другой функции > > //начало третьей функции > //чета делаем > //конец третьей функции > > метка2: > //чета делаем > //jmp метка 1 > > Ну и различные вариации — вплоть до того что середина или конец функции может оказаться раньше ее начала, вкупе с относительной адресацией это выйдет в том что реализация подобной защиты окажется по трудозатратам дороже чем ее взлом
Насколько я понимаю, такие приколы лечатся с помощью #pragma optimize + отдельная секция. Хотя на практике не проверял.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Sergey wrote:
> Ты же сам написал — из *msvcrt.dll*. А не из MyCoolApp.exe или > MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp, > и сразу становится ясно, где расположен код распаковщика.
Статически слинковать?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, volk, Вы писали:
V>Чем такое не подходит?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, volk, Вы писали:
V>>Чем такое не подходит?
Минус не проставился; попробуйте поставить еще раз.
Если контрольных ячеек три штуки -- то да, watchpoint рулит.
Если их за сотню -- вручную не распутать.
А если часть из них при этом еще и реализует дважды косвенную адресацию перехода (не "возьмите адрес в ячейке 10", а "спросите в ячейки десять, где лежит этот адрес") -- вот тогда жизнь ломателя существенно осложнится.
Тот, кто желает, но не делает, распространяет чуму.
[]
S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.
Релоки нужны для корректировки абсолютных адресов (в основном — статические переменные). Адреса команд относительных переходов в этой таблице отсутствуют. Так что не поможет.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, WoldemaR,
RB>>Есть набор функций, выполняющих элементарные действия. RB>>Алгоритм программы состоит в последовательности вызовов этих функций. RB>>Последовательность задается строкой (типа байт-кода). RB>>Строка перед использованием шифруется-дешифруется.
WR>Нет. мне кажется, что этот вариант ненадёжен. Потому как есть одно узкое место — красная тряпка. WR>лучше если обращение к критическому коду будет разбросанно по всему телу проги.
Как раз всевозможные виртуальные машины признаны наиболее надёжными в последнее время.
Обычную программу довольно просто протрейсить до нужного места.
Помимо красных тряпок, существует еще 68 научных и эзотерических способов найти этот банальный jnz в конечной точке. Пошифрованные куски кода возможно даже статическим анализом найти и расшифровать. А вот когда программа управления полётом на Марс использует в расчетах константу полученную из ключа, то...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[3]: Вызов копии функции
От:
Аноним
Дата:
01.09.06 08:25
Оценка:
Здравствуйте, WoldemaR, Вы писали:
WR>Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка. WR>А хотелось что нибудь незаметно-тривиальное.
Можно использовать свой менеджер памяти
> S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные. > > Релоки нужны для корректировки абсолютных адресов (в основном — статические переменные). Адреса команд относительных переходов в этой таблице отсутствуют. Так что не поможет.
Я уже писал в этой ветке — относительным переходам ничего не сделается, если они выпоняется внутри перемещенного блока кода. А для вызова в "обычный" код надо применять косвенные переходы — они фиксапами пофиксятся.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Я уже писал в этой ветке — относительным переходам ничего не сделается, если они выпоняется внутри перемещенного блока кода. А для вызова в "обычный" код надо применять косвенные переходы — они фиксапами пофиксятся.
А я тоже уже писал что относительные переходы внутри одной и той же длл в фиксапах никак не фигурируют ибо их загрузчику трогать не нужно
Тот, кто желает, но не делает, распространяет чуму.
