Здрасти.

Задача - обнаружить исполнение ROP последовательности.

Те способы что существуют, не пригодны. К примеру i-CET не позволяет работать любому приложению, которое использует пакеры/протекторы/системную_обработку.

Нужен способ для обнаружения последовательности ROP для приложений с защитой пе(протекторы/сис_код).

Эффективный способ - тот, что реализован как куки в прологах функций(перезапись адреса возврата при условии что она происходит после записи предыдущего (esp-4) значения. Но этого не достаточно.

Так как при ROP происходит извлечение GRP регистров, то видимо как то можно это использовать, к примеру создать битмапу для стека и в ней помечать регистры, но конкретного решения не видно

-----
vx

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

difexacaw пишет:
Эффективный способ - тот, что реализован как куки в прологах функций(перезапись адреса возврата при условии что она происходит после записи предыдущего (esp-4) значения. Но этого не достаточно.


У тебя есть пример для этого способа?!

Control-Flow Enforcement Technology Preview - Intel® Software - если кому интересно
--> Link <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

после прошлой темы прям лес рук с предложениями вариантов.

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

хардварный шадоу стек от интел решает все проблемы с rop, никакие другие кривые велосипеды не нужны.
и никакие пакеры протекторы rop не юзают

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

SegFault пишет: и никакие пакеры протекторы rop не юзают

не юзают, но костыли с треском ломаются, бггг. ситуация такая же, как и с dep, говнософт отваливается.

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

mak

А какой пример, запись значения ниже адреса возврата и адреса возврата, при этом нужны некоторые спец критерии - возврат из процедуры не происходит етц.

SegFault

Если бы ты понимал как это работает, то такую чушь бы не говорил. CET не совместимо ни с чем, обычный софт под ним запущен не может быть. Пакеры протекторы не юзают ROP, я это не говорил мисье не читает, он пишет; манипуляции стеком не совместимы с CET, а значит и никакой выше описанный софт.

Ни одно приложение накрытое защитой, ни один плаг или какой то хук не может работать под CET. Но не смотря на это, эта техника не является годной защитой, помимо ROP есть есчо множество способов обойти CET - COP etc.

-----
vx

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

что то совсем уныло зашел тред. индей, а что тебе мешает запилить свой теневой стек? насколько я понял тебе это нужно для твоего "мотора", можешь подсмотреть у pin или drio, инструменты так и называются shadow stack, реализация говно, но для общего понимания достаточно, а так, еще в каком то году была нормальная дока на bh. самому лень искать, а после прошлого треда еще и желания нет. cet рассчитан на rop\jop, естественно это не серебряная пуля и не предлагает универсальное решение для всех векторов атак, но это лучше чем ничего, особенно в критических системах.

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

shellstorm

Теневой стек это просто проверка что адрес возврата сформирован именно через call и серия таких адресов в стеке соответствует последовательности исполнения call. Можно и по другому без стека это проверить, отследив последовательность ветвлений, это не принципиальные детали конкретной реализации.
Что бы была возможность работы произвольного приложения проверка такой цепочки call-ret не годится, к примеру какой то хук или например win-seh нарушит эту последовательность, хотя это не будет исполнением rop. Нужен другой критерий.

Например извлечение регистров из стека без их загрузки как вариант. Или есчо как то можно обнаружить.

-----
vx

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

difexacaw пишет: Например извлечение регистров из стека без их загрузки как вариант.

так реализация теневого стека у pin проверяет не только call\ret но и контекст анализирует, загугли доки за 2014\2015 год, там уже с учетом регистров, а рядом лежат доки с описанием захвата атомов, тоже придется учитывать.

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

difexacaw пишет:
Если бы ты понимал как это работает, то такую чушь бы не говорил. CET не совместимо ни с чем, обычный софт под ним запущен не может быть.
ты бредишь? ты сам не понимаешь, что говнопакеры всякие и прочие костыли типа твоих моторов это и есть негодный софт, и правильно што ето будет блочиться новыми процами интел с шадоу стеком.
Пили лучше тему про обход шадоу стека от интел!

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

SegFault

Обычные приложения запускаться не будут, а это никому такое не нужно - механизм просто не будут использовать(отключат).

shellstorm

А что именно искать, дайте пруф. То что находит гугл по первым ссылкам не содержит никакой важной инфы:

--> Link <--
--> Link <--
--> Link <--
--> Link <--

-----
vx

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

difexacaw пишет:
Обычные приложения запускаться не будут, а это никому такое не нужно - механизм просто не будут использовать(отключат).
бля что за наркомания

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

SegFault

Смотри --> Link <--

Затем пойми общий принцип и разницу между COP/JOP vs ROP.
Метод типо валидации call-ret не годится в случае выше, это не общее решение. Я ведь сказал что мне не нужна данная валидация(push X/ret - это никак не исполнение шелла!, хотя CET это блокирует). Тема про поиск общего решения.

-----
vx

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

difexacaw пишет:
Обычные приложения запускаться не будут, а это никому такое не нужно - механизм просто не будут использовать(отключат).
херню не неси, rfg уже прекрасно работает, говнософт отвалится если - это гоже, это нам подходит

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

SegFault

Перечитайте моё сообщение выше, вы не улавливаете смысл.

-----
vx

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

difexacaw
наслышан про твои делишки.



при начале декодирования на один байт позже, даёт


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

Zoeken

Не знаю что вы имели ввиду, впрочем не важно.

Решение найдено.

-----
vx

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