Здравствуйте, 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, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.

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 и его можно будет благополучно пропатчить.

Здравствуйте, 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 + отдельная секция. Хотя на практике не проверял.

Sergey wrote:

> Ты же сам написал — из *msvcrt.dll*. А не из MyCoolApp.exe или
> MyCoolApp.dll Ставится бряка на переходник из таблицы импорта MyCoolApp,
> и сразу становится ясно, где расположен код распаковщика.
Статически слинковать?

Здравствуйте, volk, Вы писали:

V>Чем такое не подходит?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, volk, Вы писали:

V>>Чем такое не подходит?

Минус не проставился; попробуйте поставить еще раз.

Если контрольных ячеек три штуки -- то да, watchpoint рулит.
Если их за сотню -- вручную не распутать.
А если часть из них при этом еще и реализует дважды косвенную адресацию перехода (не "возьмите адрес в ячейке 10", а "спросите в ячейки десять, где лежит этот адрес") -- вот тогда жизнь ломателя существенно осложнится.

Здравствуйте, Sergey, Вы писали:

[]

S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.

Релоки нужны для корректировки абсолютных адресов (в основном — статические переменные). Адреса команд относительных переходов в этой таблице отсутствуют. Так что не поможет.

Здравствуйте, WoldemaR,

RB>>Есть набор функций, выполняющих элементарные действия.
RB>>Алгоритм программы состоит в последовательности вызовов этих функций.
RB>>Последовательность задается строкой (типа байт-кода).
RB>>Строка перед использованием шифруется-дешифруется.

WR>Нет. мне кажется, что этот вариант ненадёжен. Потому как есть одно узкое место — красная тряпка.
WR>лучше если обращение к критическому коду будет разбросанно по всему телу проги.

Как раз всевозможные виртуальные машины признаны наиболее надёжными в последнее время.
Обычную программу довольно просто протрейсить до нужного места.

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

Здравствуйте, WoldemaR, Вы писали:

WR>Тут видиш в чём дело. всякие HeapAlloc/VirtualAlloc — это вещи достаточно нестандартные по сравнению с new char[]. Следовательно они для сканера верный признак — красная тряпка.
WR>А хотелось что нибудь незаметно-тривиальное.
Можно использовать свой менеджер памяти

> S>В случае защиты не MyCoolApp.exe, а MyCoolApp.dll, в этой самой dll обычно (если специально не отрезали) есть секция .reloc, в которой написано, что по какому адресу надо подправить, чтобы код заработал, будучи загружен по другому адресу. Надо всего лишь уметь применять эти данные.
>
> Релоки нужны для корректировки абсолютных адресов (в основном — статические переменные). Адреса команд относительных переходов в этой таблице отсутствуют. Так что не поможет.

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

S>Я уже писал в этой ветке — относительным переходам ничего не сделается, если они выпоняется внутри перемещенного блока кода. А для вызова в "обычный" код надо применять косвенные переходы — они фиксапами пофиксятся.
А я тоже уже писал что относительные переходы внутри одной и той же длл в фиксапах никак не фигурируют ибо их загрузчику трогать не нужно