Есть некая функция. можно с++, можно extern "C".

я её тело копирую в свободный (в куче) участок памяти.

запускаю через кастинг указателей.

выскакивает ACCESS VIOLATION на совершенно бредовый адрес.

Доктор. Скажите, это как-то лечится?

Здравствуйте, 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>>Доктор. Скажите, это как-то лечится?

У тебя, случаем, не AMD64?

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>Доктор. Скажите, это как-то лечится?

Там снизу уже на все ответили. Но я все-таки влезу и спрошу:

зачем,
зачем,
зачем,
ДА КАКОГО ДЬЯВОЛА ТЫ ВСЕ ЭТО ДЕЛАЕШЬ?

Не смогу спать, пока не получу ответ...

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

WM>У тебя, случаем, не AMD64?

не, у меня пень 4.

"WoldemaR" <15414@users.rsdn.ru> wrote in message news:2080508@news.rsdn.ru...
> Есть некая функция. можно с++, можно extern "C".
>
> я её тело копирую в свободный (в куче) участок памяти.
>
> запускаю через кастинг указателей.
>
> выскакивает ACCESS VIOLATION на совершенно бредовый адрес.
>
> Доктор. Скажите, это как-то лечится?

Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.

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

K_O>Если только в операционной системе нет средств позволяющих переназначать атрибуты защиты памяти.

VirtualAlloc спасает.

но появилась другая проблема — как скопировать тело функции?
http://www.rsdn.ru/Forum/Message.aspx?mid=2081316

Автор: WoldemaR
Дата: 29.08.06

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

S>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.

Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ
Похоже это решение поставлено на поток. А ведь это как красная тряпка для быка.
Жаль ещё и потому, что неполучается реализовать это дело втихаря. — То копировать нельзя, то запускать...
Ой, неспроста оно так сделано, ой неспроста...

> S>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.
>
> Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ
> Похоже это решение поставлено на поток. А ведь это как красная тряпка для быка.

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

> Жаль ещё и потому, что неполучается реализовать это дело втихаря. — То копировать нельзя, то запускать...

Ну заметят твои вызовы VirtualProtect, и дальше что? Бинарник-то просто-так не поправишь, нужный кусок шифрованный. И вылазит столько геморроя — найти и расшифровать все кодированные секции (а они изначально общей кучкой в секции данных лежат), предварительно идентифицировав алгоритм шифрования и найдя в бинарнике открытый ключ (а дампить мало поможет, некоторые куски не чаще раза в месяц должны использоваться), отломать расшифровывалку и вставить на ее место просто копировщик и применяльщик релокейшенов — что нафиг оно кому нужно, такую гадость ломать.

> Ой, неспроста оно так сделано, ой неспроста...

Разные аттрибуты защиты для разных секций? Конечно неспроста — для пущего отлова ошибок.

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

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

S>>Если оно для того, для чего я подумал — шифруй целую секцию PE-файла.

WR>Почитал MSDN. Да. Жалко что мы пока не используем .НЕТ

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

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

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

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

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

...
Очень хочу пообщаться с тобой в привате. Если найдёшь время — постучись мне на мыло.

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

WR>Есть некая функция. можно с++, можно extern "C".

WR>я её тело копирую в свободный (в куче) участок памяти.

WR>запускаю через кастинг указателей.

WR>выскакивает ACCESS VIOLATION на совершенно бредовый адрес.

WR>Доктор. Скажите, это как-то лечится?


может так сойдет ?


HANDLE hMyHeap = ::HeapCreate(HEAP_CREATE_ENABLE_EXECUTE, 0, 0);
PVOID pMyFunctionBody = ::HeapAlloc(hMyHeap, 0, dwSizeOfMyFunction);

RtlCopyMemory(pMyFunctionBody, (PVOID)(...), dwSizeOfMyFunction);

__asm call pMyFunctionBody

::HeapFree(hMyHeap, 0, pMyFunctionBody);

::HeapDestroy(hMyHeap);

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

WR>Здравствуйте, rus blood, Вы писали:

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

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

Что ж, ситуация прояснилась, снова могу спать.

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

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

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

X>может так сойдет ?


X>HANDLE hMyHeap = ::HeapCreate(HEAP_CREATE_ENABLE_EXECUTE, 0, 0);
X>PVOID pMyFunctionBody = ::HeapAlloc(hMyHeap, 0, dwSizeOfMyFunction);

X>RtlCopyMemory(pMyFunctionBody, (PVOID)(...), dwSizeOfMyFunction);

X>__asm call pMyFunctionBody

X>::HeapFree(hMyHeap, 0, pMyFunctionBody);

X>::HeapDestroy(hMyHeap);

Может и сойдёт...

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

Кстати, как скопировать функцию так и не ясно...

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



WR>Кстати, как скопировать функцию так и не ясно...
Функцию, в общем случае, никак. Но не будет ли достаточно просто ассемблерной вставки?..

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

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

Э-э-э, оператор new, функции типа malloc — это все "фичи" языка и библиотек.
На конкретной платформе они сводятся с вызовам системных функций.
Под windows это будет HeapAlloc, или что-то аналогичное.
Так что непонятно, где ты здесь видишь нестандартность...