Есть ли какой-нибудь способ заставить JIT-компилятор .net запустить другой метод?

Question

Хорошо, допустим, что мое приложение отправляет инструкции (x86) в память, делая страницу исполняемой и т.д.Есть ли какой-либо способ изменить заглушку метода un-JITted метода, чтобы указать на мой отправленный поток команд?

Например.:

Предположим, я создал поток команд x86 в памяти, который выполняет что-то произвольное.Теперь, далее, предположим, что у меня есть метод 'int Target()'.Я еще не вызывал его, так что он не был скомпилирован.Есть ли какой-нибудь способ:

1. Получить указатель на заглушку цели
2. Сделайте так, чтобы он указывал на мой исходящий поток команд.

Я понимаю, что практически каждая отдельная функция безопасности .Net предназначена для предотвращать угон, подобный этому.Но возможно ли это, скажем, через hosting API?

Answer 1

да, вы можете это сделать!

Подключите метод getJit к mscorjit.И вас будут спрашивать каждый раз, когда какой-либо метод потребует Jitting.ты можешь передавать все, что захочешь.Некоторые средства защиты .net работают следующим образом.

Answer 2

Это возможно с помощью API профилирования.Я никогда не использовал его, но он используется для аналогичной цели в TypeMock.

Редактировать:Я думаю, что в блогах MSDN была хорошая публикация, пойду поищу ее.

Правка 2:Дох, первый удар!

Answer 3

Как вы говорите, это нелегко и, возможно, даже невозможно.Если я правильно помню, код будет включать адрес JIT-компилятора для метода, который не был скомпилирован.Поэтому, когда вы попытаетесь вызвать этот метод, JIT-компилятор выполнит свою работу и вставит адрес во вновь скомпилированный метод.Если вы можете изменить этот адрес, возможно, вы сможете вставить вызов в свой собственный код.Как вы могли бы сделать это незамеченным, выше моего понимания.Я, конечно, надеюсь, что CLR обнаружит такого рода вмешательство.

Я не думаю, что API профилирования поможет вам в этом случае (как предлагает Leppie), поскольку вы не пытаетесь модифицировать MSIL.Если вы думаете иначе эта статья может быть полезен, поскольку он описывает, что вы должны сделать, чтобы реализовать то, что делает TypeMock.

Answer 4

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

Еще одна вещь, на которую стоит обратить внимание, - это Постшарповый проект, который предоставляет вам методы входа и выхода, если вы применяете атрибуты.

Answer 5

Я бы не стал пытаться напрямую связываться с памятью, и я не уверен, что это вообще возможно, вместо этого вы можете использовать API profiler - там есть несколько примеров, но нет реальной документации.Взгляните на статью в журнале MSDN - Перепишите код MSIL "на лету" с помощью API профилирования .NET Framework