Сейчас на форуме: jinoweb (+6 невидимых)

 [email protected] —› Программирование —› Указатели в км.
Посл.ответ Сообщение


Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 21 октября 2017 05:11 · Поправил: difexacaw
· Личное сообщение · #1

Здрасте.

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

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

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

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

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

-----
vx




Ранг: 158.4 (ветеран), 123thx
Активность: 0.140.49
Статус: Участник

Создано: 21 октября 2017 12:34
· Личное сообщение · #2

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 21 октября 2017 13:22
· Личное сообщение · #3

rmn

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 21 октября 2017 23:50
· Личное сообщение · #4

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 22 октября 2017 15:23
· Личное сообщение · #5

shellstorm

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 22 октября 2017 20:08 · Поправил: shellstorm
· Личное сообщение · #6

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 23 октября 2017 19:58 · Поправил: difexacaw
· Личное сообщение · #7

shellstorm

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

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 24 октября 2017 09:14
· Личное сообщение · #8

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 24 октября 2017 20:22
· Личное сообщение · #9

shellstorm

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

-----
vx





Ранг: 1053.6 (!!!!), 1078thx
Активность: 1.060.81
Статус: Участник

Создано: 24 октября 2017 21:27
· Личное сообщение · #10

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 25 октября 2017 03:37 · Поправил: difexacaw
· Личное сообщение · #11

reversecode

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

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 25 октября 2017 10:15
· Личное сообщение · #12

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


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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 07 ноября 2017 03:03 · Поправил: difexacaw
· Личное сообщение · #13

shellstorm

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

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

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

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

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

-----
vx




Ранг: 251.3 (наставник), 81thx
Активность: 0.140.11
Статус: Участник

Создано: 07 ноября 2017 18:52
· Личное сообщение · #14

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 08 ноября 2017 19:30 · Поправил: difexacaw
· Личное сообщение · #15

cppasm

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

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

-----
vx




Ранг: 251.3 (наставник), 81thx
Активность: 0.140.11
Статус: Участник

Создано: 08 ноября 2017 20:19
· Личное сообщение · #16

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

Сказал то же самое другими словами.
Ограничение (контроль) доступа это и есть разделение.

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

Потому что нет у указателя размера, есть только адрес куда он указыват.




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 08 ноября 2017 20:52 · Поправил: difexacaw
· Личное сообщение · #17

cppasm

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

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

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

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

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 09 ноября 2017 15:23
· Личное сообщение · #18

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

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




Ранг: 1131.7 (!!!!), 447thx
Активность: 0.670.2
Статус: Участник

Создано: 09 ноября 2017 17:19 · Поправил: Gideon Vi
· Личное сообщение · #19



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



Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 09 ноября 2017 17:28
· Личное сообщение · #20

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 09 ноября 2017 19:22
· Личное сообщение · #21

shellstorm

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 09 ноября 2017 19:55
· Личное сообщение · #22

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 09 ноября 2017 20:14 · Поправил: difexacaw
· Личное сообщение · #23

shellstorm

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

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 09 ноября 2017 20:18
· Личное сообщение · #24

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 18 ноября 2017 20:42 · Поправил: difexacaw
· Личное сообщение · #25

shellstorm

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

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

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

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

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

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

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

Solved, closed.

-----
vx



 [email protected] —› Программирование —› Указатели в км.
Эта тема закрыта. Ответы больше не принимаются.
   Для печати Для печати