Очень интересует тема - обнаружение самомодифицирующегося кода (в дальнейшем просто СК).
Все статьи на тему СК в основном связаны с обходом дизассемблеров и с методами такого обхода, но хочется решить обратную задачу.
Толкового материала по обнаружению СК мне найти не удалось.
Знаком с IDA, думаю, он может решить поставленную задачу с помощью SDK'ашного инструментария.
Возможно, кто-нибудь уже сталкивался с подобной задачей и может "наставить на путь истинный".
С какого бока подходить к обнаружению СК, всё ли там завязано на копировании в стек/кучу?

Спасибо!

| Сообщение посчитали полезным:

Для СК вовсе необязательно копирование в стек, тем более что в системах с DEP его просто так не исполнишь ;) Есть вариант просто править собственный код, юзая WriteProcessMemory, а еще проще - задать атрибуты секции с кодом так, чтобы можно было ее править, и трактовать код как данные, перезаписывая его..

| Сообщение посчитали полезным:

northdemon пишет:
думаю, он может решить поставленную задачу с помощью SDK'ашного инструментария.
Поставь бряк на чтение/запись в любом месте большой программы, и ты убедишься как долго будет работать IDA только из-за того, что проверяет изменился код или нет, а подобное решение через SDK, вероятно, замедлит процесс до беспредела. А вообще, если ты видишь в IDA в секции текста какую-ту абракадабру не похожую на инструкции (например, есть переходы типа jmp 00000007) и на данные (которых там в большинстве компиляторов быть не должно; если есть, то где-то должно быть обращение к ним), то можешь на 50% быть уверен что это СК. Но это только мой опыт. Кроме того, в принципе абсолютно правильной тактики не существует

| Сообщение посчитали полезным:

Mordred, на кой хрен юзать WriteProcessMemory для своего кода?

| Сообщение посчитали полезным:

MoonShiner пишет:
Mordred, на кой хрен юзать WriteProcessMemory для своего кода?
А я разве рекомендовал это делать? Просто говорю, что можно править его таким образом. Если секция кода не разрешена на запись, просто даешь разрешение через VirtualProtect и правишь - вполне допустимо. Другое дело, я хз, юзает ли это кто-то

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

northdemon пишет:
С какого бока подходить к обнаружению СК
ИМХО, качественное решение получить не просто
1. Определить атрибуты секций кода
если есть write, то поиск всех команд, которые меняют память в области этой секции.
2. Определить атрибуты секций данных
если есть exec, то поиск всех переходов на выполнение области данных
3. Определить все API, которые способны модифицировать память процесса и доступ на выполнение/запись
если есть, то найти параметры, указывающие на код определённый выше.
...потом стек и т.д.
Осложняется картина тем, что статически анализировать команды вроде call EAX не всегда просто. Но можно.

-----
Всем привет, я вернулся

| Сообщение посчитали полезным:

Спасибо всем за наставления.
Прояснилось, в каком направлении надо двигаться. И делов в этом направлении предстоит наворотить много Сплошная эвристика и теория вероятностей

Тему закрывать пока что не буду, возможно, ещё откликнутся люди, столкунувшиеся с обнаружением СК на практике.

| Сообщение посчитали полезным:

ну допустим возьмём 2. переходы на выполнение области данных могут быть разными:
1. jmp/ret/call/iret и т.д.
2. использование Api: CreateThread, CreateRemoteThread, WriteProcessMemory (последнее делается с затиранием адреса возврата, хотя можно и просто заменить следующий за этим код), QueueUserApc
3. осложнённое использование API: два процесса с разделяемыми секциями, созданными при помощи ntdll!ZwCreateSection и использованием объектов LPC (аналог RPC, работающий тоже на разделяемых секциях). Данные пишутся в другой процесс через LPC-канал, тот при поступлении замораживает поток, и меняет eip на тот адрес, где находятся те же данные, но с адресом в другом процессе. Дело в том, что при создании разделяемой секции можно узнать адрес её в другом процессе! И создавать можно даже в системном, другое дело что ему эти данные читать не хочется.
4. seh-фреймы, тут главное заметить заполнение будущего eip

некоторые программы производят какой-то анализ, например, OllyDbg. можно глянуть в него, хотя можно сделать и лучше. API-методы он ловить с полной смелостью не будет наверно. Итак, надо помнить:
1. мы находимся в защищённом режиме
2. мы имеем доступ к системным функциям, которые способны изменять ход выполнения программы
3. мы располагаем многозадачностью и многопоточностью
4. неплохо иметь качественный эмулятор
__это нужно, чтобы поставить это на поток, обычно же настолько извращённым всё это дело не оказывается (мне не попадалось, но я бы попробовал это замутить).

| Сообщение посчитали полезным:

NullSession пишет:
мне не попадалось, но я бы попробовал это замутить
А не попадалось, потому что чем больше извратов, тем больше шансов для эвристики и стенки выловить такую подлянку.
Про SEH ты верно вспомнил, это очень часто используется.

-----
Всем привет, я вернулся

| Сообщение посчитали полезным:

Bitfry что такое "стенка"? насчёт эвристики-то понятно.

| Сообщение посчитали полезным:

имхо ре4ь о фаере

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

| Сообщение посчитали полезным:

Bitfry пишет:
что такое "стенка"?
Firewall'ы не любят когда процессы "влезают" друг в друга.

-----
Всем привет, я вернулся

| Сообщение посчитали полезным: