Здрасте.

Задача следующая. Необходимо определить что по указателю произойдёт выборка данных из кернел. Тоесть нужно знать, будет ли обращение из км к юм-структуре в произвольной апи.

Содержимое апи может быть произвольным, могут быть выборки юм и км, очевидно что заранее это не известно.

Можно сформировать список апи, но это лишь частное решение. Возможно ли какое то общее решение или это смысла не имеет ?

Я не вижу связи между передачей ptr в км и произвольным кодом.

При этом имеется два потока данных - CFG и DFG.

-----
vx

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

Захват и разрушение указателей (IDP-мотор или как оно там?) уже не робит, чтоле?

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

rmn

По делу есть что нибудь ?

-----
vx

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

гарантированно никак - by design. сама архитектура не позволяет подобный контроль.

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

shellstorm

Тогда можно ли решить задачу на этапе сборки апп, допустим вынести апи в секцию, отдельную от основного кода ?

-----
vx

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

difexacaw пишет: Тогда можно ли решить задачу на этапе сборки апп, допустим вынести апи в секцию, отдельную от основного кода ?

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

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

shellstorm

Мне нужно знать факт передачи юм указателя в км для известной апи. Если такое обращение есть, то защита падает, так как поток данных перестаёт отслеживаться. Именно это и интересно, я ничего не говорил про подмену данных(IDP).

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

-----
vx

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

difexacaw пишет: Именно это и интересно

С такой постановкой задачи решения нет, для этого пилят другие оси с прослойкой абстракции которая отделяет пользовательский софт от системного и эта прослойка контролирует обращения к системному коду, но такие абстракции не бесплатны и существенно замедляют работу, поэтому в windows этого нет и вряд ли будет.

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

shellstorm

Архитектура ядра нт подразумевает обмен данными в виде ptr:size, так как перед обращением к ptr должна следовать валидаций указателя, размер которого передаётся в км. Также имеет смысл и обратное - на запрос в км юм клиент получает размер возвращаемой инфы. Это фундаментальный принцип архитектуры.
На основе этого можно составить сервисные прототипы, но опять же - это сомнительный способ и геморный/не портабельный.
Если это статик, то можно попытаться решить в динамике - это возможно(мониторить рабочий набор, рестартить сервисы етц), но я не рассматриваю этот вариант, не профайл. Всякий км фильтр на события #GP - слишком медленно.
Определить прототипы в динамике - может быть, но сомнительно, так как это вероятностный подход наверно.

-----
vx

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

ловить обращения нужно не по указателям а по самой памяти
очевидно ставить атрибуты на нее при которым будет доступ с ring3 в rig0
и на реагировать эксепшин

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

reversecode

> очевидно ставить атрибуты на нее при которым будет доступ с ring3 в rig0

Ловушки не дадут размер памяти. Тогда будет поток срабатываний при каждом обращении в буфер(тк размер не известен), что очень долго. А есчо км использует разные синхронизации и удержания памяти - юзер буфера блокируются на уровне менеджера памяти, если их размер большой. Как это всё в случае ловушек обработать - не понятно.
Эта задача и нужна что бы избежать обращений в память, которой нет. Происходит выборка из N/A памяти ядром(анклав), это нужно избежать. Иначе получается что анклав может быть создан только для X памяти или которая не передаётся в км.

-----
vx

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

reversecode пишет: очевидно ставить атрибуты на нее при которым будет доступ с ring3 в rig0
и на реагировать эксепшин

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

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

shellstorm

Решения не видно

Отсутствие возможности для такого контроля делает не возможным реализацию полноценной защиты. Как же не продумано сделано всё

Колхозить забивая сервисные прототипы ой как не гуд. Накопить прототипы так же не просто и не хорошо, короче тупик.

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

NT архитектура фундаментально не безопасная, раз данные не разделяются в модах.

-----
vx

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

Данные разделяются на уровне страниц.
Этого достаточно.

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

cppasm

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

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

-----
vx

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

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

difexacaw пишет:
Всякий указатель имеет размер области, без размера указатель не имеет смысла, так как выборка данных по указателю имеет размер. Именно в это всё упирается, нет способа определить размер указателя.
Потому что нет у указателя размера, есть только адрес куда он указыват.

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

cppasm

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

Смотрите, есть указатель на некоторый блок данных, он передаётся в км аргументом, напрямую или как часть некой структуры(это новая задача - связывание этих указателей). Есть не известный сервисный интерфейс, он принимает на вход некоторую последовательность структур. Каждая часть этой последовательности имеет указатель и размер. Но это извествно для не известного интерфейса. Короче есть адрес структуры и второй указатель в тело структуры, дельта не есть размер.

Это не первый мой вопрос, всё крутится вокруг накопления данных, так накапливаются указатели(под визором), так же может быть накоплена выборка данных из км, просто я пока не вижу оптимального решения.

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

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

-----
vx

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

difexacaw пишет: Как же не продумано сделано всё

Напротив, очень даже продуманно, назови хоть одну массовую ось без подобных брешей, их нет.
Когда проектировалась windows то на тот момент даже такое ядро считалось тяжелым для железа того времени, а затем легаси, миллионы сторонних проектов, сложно что то в одночасье переделать, ибо некому не будет нужен этот гомункул если ради него придется переписывать всю кодовую базу. Другая проблема в сишке, этот уродец в своем дизайне явно имеет лишние хромосомы, язык не безопасен и портировать его хоть на тот же близкий D затруднительно, компиляторы и тот не всегда способны нормально распарсить этот высер сумрачного гения Кернигана и КО. Безопасные оси есть, но они настолько специфические и используются в критических сферах типа космонавтики или ядерной энергетики, тем более это не главная проблема, чаще проблемы возникают из за логических ошибок. Ко всему этому еще и архитектура фон Неймана уязвима, есть конечно камни с другой архитектурой, но тут все аналогично осям. Все свелось к тому, либо несовершенно уже в дизайне, но работает сейчас или все хорошо в дизайне, но скорее всего проект никогда не увидит свет.

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

это к вопросу о С, Кернигане, архитектуре Windows и т.п.

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

Gideon Vi пишет: это к вопросу о С, Кернигане, архитектуре Windows и т.п.

Но аргументировать мы конечно можем (на самом деле нет) и ума хватает лишь на пикчи для децепешников, да?
1. Причины выбора такой архитектуры описаны архитекторами.
2. Прежде чем говорить о языке не плохо его знать и еще что то кроме него. Cи это проблема и эта проблема далеко не в сырых указателях или ручном управлении памяти, проблема именно в дизайне языка, в грамматике (КС) и легаси которым он оброс за годы, и зависимой от платформы специфики.
Мораль сей басни, прежде чем постить пикчи неплохо бы для начала изучить матчасть.

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

shellstorm

Вот и я сказал что не продумано всё и теперь они сами со своим архитектурным косяком столкнулись. Противодействие OP не заложено на уровне архитектуры, а значит она дырявая. А что фиксят это за счёт железа - глупо и не эффективно.

-----
vx

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

difexacaw пишет: и теперь они сами со своим архитектурным косяком столкнулись

Дважды за последнее время, но они считают это не баг, а фича, даже если она позволяет обойти пачгвард.

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

shellstorm

KMP никакого отношения не имеет к OP. Это сложного типа ошибки. Они бывают и км, но это не рассматривается.

OP фикс был на уровне камня - icet. Это не решает задачу, я говорил и подробно описывал. кажется что архитектура пилится под железо. Не используются разработки на уровне софта. Печальна это всё. Но мне интересно вернуться к изначальной задаче и поискать решение. Какие то слоники вместо анализа - может быть комуто забавно, но я потратил огромную кучу времени на размышление(анализ) данной темы, впрочем мнение слоников не важно.

-----
vx

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

difexacaw пишет: KMP никакого отношения не имеет к OP.

Это всего лишь следствие, как конечная цель закрепления в системе. По поводу же задачи, все же на osdev или форуме reactos быстрее ответят.

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

shellstorm

Я вижу лишь два пути решения.

A. На уровне компилера. Понятно что это не общий способ.
B. Дефейн сервисных прототипов.

Второй метод довольно сложен из на многих нюансов, но думаю это единственное возможное решение.

Пусть в сервис передаётся некоторый указатель P. Память по тому указателю является анклавом и не доступна для чтения ни из какого мода - там данных нет, не зависимо от состояния памяти.

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

Добавлено спустя 19 часов 14 минут
Решение найдено по пути B.

Так как исходная область памяти не доступна, то необходимо отобразить её на новую область. Для исключения RC-чтений памяти при сервисном вызове аллоцируется буфер и указатель отобращается на данный буфер, для быстрой трансляции нужно авл дерево.
После отработки сервиса данные из буфера не пересылаются в хранилище, а новый буфер остаётся отображённым на указатель - при дальнейшей выборке данных по указателю выборка направляется в этот буфер. При корреляции буферов - наложении их друг на друга две области памяти сливаются в одну.

Solved, closed.

-----
vx

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