Опасность использования RW-секции.

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

Сама необходимость использования само-модифицирующегося кода возникла по следующим причинам:

Есть множество функций, при первом вызове любой из которых необходимо произвести некоторые действия. Т.е. действие совершается единожды.

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

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

Посему, я решил сделать так:
В начале каждой функции стоит call foo. Этот foo выполняет нужные действия, и во всех функциях затирает call foo (прежположим, nop-ами, хотя на самом деле, jmp-ом).

Не вызовет ли подобное поведение негативной реакции у антивирусов?

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

 

Ох...

 

Вынеси call foo за пределы часто вызываемой ф-ции туда, где стоит первый вызов myfunc.

 

FireHacker
Возьми антивирус и проверь. В общем по одному такому признаку никто не палит, хотя антивирусы бывают разные и некоторые палят по малейшим косвенным признакам.

 

Согласен с KeSqueer
Дополнительно замечу, что
1) В современных компах рулит предсказание условных переходов. Если "действие совершается единожды" и устанавливается некий флаг, то "падение производительности " будет иметь место лишь при втором вызове функции и будет составлять ~10-20-30 тиков в зависимости от компа. При последующих вызовах никаких ощутимых потерь не будет (от силы 1-2 тика, что есть мелочь даже по сравнению с call+ret)
2) Модификация кода может приводить к значительно бОльшим потерям\штрафам, особенно на компах с преддекодированием - P4 и АМД, причем это эатронет не только саму именяемую функцию, но и весь окружающий код в окрестности 1Кбайт

 

KeSqueer
Не стоит придумывать программу за меня. Особенно не стоит этого делать, если не знаешь всех тонкостей и нюансов.

Функций много, функции в DLL. Функции вызываются из EXE (или из других DLL). Надо отловить первый такой вызов и произвести некоторые действия (инициализацию). Что куда предлагаешь выносить?

EvilPhreak
Проведение подобных экспериментов заняло бы много времени. Мне кажется, куда более рационально спросить у того, кто эти эксперименты уже проводил когда-то.

leo
Спасибо. Т.е. советуешь использовать всё-таки флаг?





P.S.

Я специально не стал писать сразу. Дал возможность мысли "Идиот, делай свою инициализацию в точке входа!" пожить чуть-дольше, чем секунду.

Точку входа не предлагать, она принципиально не подходит, потому как EP всех библиотек вызываются загрузчиком до вызова EP процесса. А инициализацию нужно обязательно производить после того как отработает EP процесса.

 

=))

 

FireHacker

Ну а что тебе надо тогда? Сам ведь вроде это и просил

Еще как вариант:

; text
jmp [jmp_to]

init:
;initialization
mov [jmp_to], init_ok
init_ok:

;data
jmp_to dd init

Но не знаю, вряд ли он будет работать быстрее варианта с флагом

 

не вижу принципиальной разницы. что за джамп, которым ты затираешь? точнее куда он ведет

сморя как часто встречается call foo, иначе на затирание всех вызовов ты можешь потратит ьбольше времени, чем выполнястя все такие заглушки.

почему бы не сделать просто функцию инициализации одну и все?

 

Джамп ведёт к самой функции.

Расскажу с начала. Есть n-ное количество функций (пусть 20 штук). Количество функций каждый раз разное. То две, то 600. Функции уже скомпилированы и помещены в секцию кода. В принципе не в плотную, место между функциями есть, но это паддинг и я бы не стал надеяться на то, что он там всегда будет.

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

Какие идеи у меня возникли - я уже говорил (идея с guard-страницами мне тоже нравится). Одна из идей - создать таблицу интерцепторов (перехватчиков).

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

Код (Text):

1. call init
2. call init
3. call init
4. call init
5. call init

Когда кто-то вызывает одну из наших функций, выполнение переходит на один из наших call init, в стек кладётся адрес возврата (адреса текущего интерцептора + 5 байт (засчёт инструкции call XXXXXXXXh)) и управление передаётся init-у.

init:

Код (Text):

1. //Тут собственно происходит сам init
2. // Поверх таблицы интерцепторов записываем новую таблицу:
3. // jmp A
4. // jmp B
5. // jmp C
6. // jmp D
7. // jmp E
8. sub dword [esp], 5
9. retn 0

sub dword [esp], 5 всем кажется бредом, вплоть до того момента, пока они не поймут замысла:

Код (Text):

1. foo:
2. call bar
3. nop
4. nop
5. nop
6.  
7. bar:
8. // тут поверх инструкции call bar записывается инструкция jmp quux
9. // они обе 5-байтоые...
10. sub [esp], 5
11. retn 0
12.  
13. // Если бы здесь мы не отняли от [esp] 5, после retn 0 управление
14. // передалось бы куда? Правильно - на nop. А так оно передастся
15. // на call foo. Только там уже не call foo, а jmp quux.
16. // FlushInstructionCache, кстати, надо вызывать?
17.  
18. quux:
19. // Ы!

Теперь понятно, что и чем затирается?

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

Потому что фигово это будет. Представь себе сишника, который в msvc++ сделал DLL-шку, в которой кроме его функций появилась ещё одна - InitMe. И которую если он не вызовет - всё упадёт нахрен. Понравится ли ему (сишнику), что его инструмент производит такие не совсем прямые библы?

(Блин, половину программы рассказал)
А вообще, см. http://bbs.vbstreets.ru/viewtopic.php?t=34902

 

Теперь понятно.

.
В таком случае все упаковцики могут вызвать проблемы. Я стараюсь не использовать RWE секции из принципа.
Короче, если не хочется использовать RWE секции, пиши флаг в RW секцию. Один вариант сам уже предложил. Вот так можно:

;text
any_exported_func:
call [pinit]
...
ret
;---------
init:
;initialization
mov [pinit], stub
retn
;----------
stub:
retn
;----------
;data
pinit dd init

 

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

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

А вы... охать, лолкать, переделывать мои задумки давай.

 

Уж прости, но не ты один такой умный на такие "задумки". Каждый через это проходит и каждый для себя выбирает подходящий метод рассмотрев все плюсы и минусы. Для меня писать в сецию с кодом - вопрос эстетики. А вот "пололкать" есть над чем. Особенно над тем, что человек борется за производительность приложения на VB.

 

Да будет тебе известно, KeSqueer, что миф о низкой производительности VB придуман безграмотными личностями или невнимательными личностями, которые пишут бредовый код, а потом удивляются.

У меня на этот счёт есть даже один примечательный топик, в котором есть один примечательный комментарий.

 

ога VB работает в тыщу раз быстрее оссемблера это ещё вассерман доказал и пох что там п-код =)

 

sl0n
Хватит писать чушь. Там Native-код.

 

FireHacker
Действие законно, со всех точек зрения. Фаеры и антивири много чего мониторят, хотя именно это по-мойму бред, вроде пока не встречал. Интересно это в принципе возможно отмониторить? Это же защита на уровне ЦП. Поменял атрибут страницы, и пиши себе, контролирует процессор, а не ОС. Как мониторить? Перехватывать проц? А вот запись в другой процесс это уже другой табак.

 

Страницы с кодом не своппятся. Но ровно до тех пор, пока они имеют только R_E-атрибуты. Страницы с W-атрибутом - своппятся.
Динамический код требует, чтобы страница с кодом была Write-абельной. Таким образом, полагаю, антивирус может "вклиниваться" в процесс memory manag-инга и ловить попытки записи в страницы с кодом. Эвристически определить, что в этой RW-странице именно код я думаю, антивирусу не составит труда.

Хотя я не знаю, насколько это соответствует действительности, в ring-0 глубоко не лез, с механизмами работы ВП досконально не знаком.

PS. Что за напасть, обязательно да опечатаюсь. В каждом сообщении как назло - пометка о правке.

 

[offtop] Самый интересный вопрос всей темы - на кой нужны нативные длл на VB? =)) [/offtop]

 

Думаю автору не столько интересно, кому это надо, а интересен сам процесс исследования и создания. К сожалению, на васме в последнее время все меньше подобных персон...