Здрасте.

Я поднимал несколько тем по защите, на них решение найдено - по защите данных(анклавам) и инжектам. Это приводится к одной технике, но появилась третья задача. Динамик поиск OP-уязвимых конструкций.

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

Очевидно что тема весьма сложна, так как всё вножество её частей нельзя свести под какую то абстракцию.

Исходить можно из следующих соображений. Мы имеем потоки данных предоставляемые визором в виде CFG, DFG, PFG. Мы имеем полное состояние потока на каждой интерации(интрукции) и все базовые зависимости(указатели на указатели етц).

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

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

-----
vx

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

начинать нужно отсюда: https://en.wikipedia.org/wiki/Design_by_contract
затем продолжить вот это: https://en.wikipedia.org/wiki/Decision_tree

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

shellstorm

Чем эта странная инфа мне помогла или может помочь в разработке ?

-----
vx

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

difexacaw пишет: Чем эта странная инфа мне помогла или может помочь в разработке ?


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

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

shellstorm

Не согласен. В начале нужна формулировка проблемы, только затем можно найти частное решение и в общем случае понять".

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

По вашему описанию:

4. Какую ошибку и каким деревом. Что есть дерево" ?

Опишите плз подробно что это всё значит, доступно и кратко.

Добавлено спустя 8 минут
shellstorm

Есть такая статья и на ру, как я и думал, это ооп понятия:



Что никакого отношения к задаче не имеет.

-----
vx

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

difexacaw пишет:
Не согласен. В начале нужна формулировка проблемы,

Ну, так когда ты её сформулируешь?
Или кто-то должен это сделать вместо тебя?



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

difexacaw пишет: В начале нужна формулировка проблемы

В начале нужно выбрать задачу, затем строится модель исходя из задачи.
Например есть компоненты CFG, DFG, PFG, есть задача, то есть то, что хочешь сделать на базе этих компонентов, после определения с целью нужно сделать связи между этими компонентами, выставить триггеры, на триггеры повесить функции и связать результат функция с компонентами, все в целом похоже на проектирование сетевой архитектуры, сервера, базы данных и вот это все. Для задач на графах\деревьях есть визуальные дизайнеры, чем то похоже на проектирование формы в delphi\Qt, только раскидываются алгоритмы, триггеры и функции, вот во время такого проектирования видны недочеты архитектуры, и удобно отлаживать связи между компонентами, те самые функции и триггеры, правда на ассемблере не знаю подобных систем, все java да python, после проектирования выгружается код в котором все спроектированные связи и интерфейсы. Писать же наугад по принципу получится-неполучится или вдруг чего перепишу, это полное непонимание задачи. По поводу контрактов, само это понятие старее ООП и мир не вертится вокруг ООП, есть и лучше альтернативы. Деревом является набор условий через которые проходят данные после срабатывания триггера, допустим в коде есть деление, срабатывает триггер которые проверяет деление на ноль, аналогично с размером буфера и так далее, составляется контракт между определенными данными и триггером\функций и из таких контрактов строится дерево. Например знаешь как найти уязвимость определенного класса, описываешь условия пройдя которые можно с какой то степенью вероятности сказать, что здесь есть уязвимость и такими условиями наполняется дерево, вокруг дерева строится конечные автомат, которые связывается с триггерами и потоком данных. Если совсем упрощенно, возьмем компилятор, сначала пишется БНФ, затем лексер\парсер\etc и эти сущности связываются по правилам БНФ. И это не статическая фигня, а базовые основы, этой фигне лет больше чем мне и применяется по сей день, базы данных или графы самый яркий пример контрактных моделей.
вот подобная система: https://orange.biolab.si/ дабы было понятно о чем вообще речь, это довольно простой вариант, есть системы которые на порядке круче и покрывают функционал целых научных пакетов в которые входят и графы с деревьями в том числе.

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

shellstorm пишет:
есть системы которые на порядке круче и покрывают функционал целых научных пакетов в которые входят и графы с деревьями в том числе.

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

-----
Give me a HANDLE and I will move the Earth.

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

Здесь что-то на эльфийском, я не могу прочитать.жпг

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

shellstorm

#7 понятно, вот только вы забываете всё множество нюансов, которых очень много, системное поведение, кодировки и трансляции, что делает матем. формулиование и решение таких задач бесполезным и невозможным. Как пример - две первые паблик остались не решёнными.

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

dosprog

> Ну, так когда ты её сформулируешь?

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

-----
vx

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

difexacaw пишет: вот только вы забываете всё множество нюансов, которых очень много, системное поведение, кодировки и трансляции, что делает матем. формулиование и решение таких задач бесполезным и невозможным

Матан по умолчанию обладает тьюринг полнотой, то есть, все что вы можете сформулировать в своей голове то же самое можете выразить в алгоритме, если совсем просто, нельзя написать того, чего мы не понимаем, всякие сверъюринговые вычисления и прочая философия.

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

Берете граф компонент чтения, добавляете функцию построения cfg, на cfg вешаются связи с другими компонентами или функциями, допустим нужно разбить cfg еще на бэйзик блоки, а в бэйзик блоках уже можно выделить логические блоки если есть такая необходимость.
модель строится поступательно.
выделяем отдельные, самостоятельные сущности, чтобы правка в парсере не приводила к необходимости переписывать хоть то же построение cfg, после выделения всех самостоятельных сущности делаем интерфейсы для взаимосвязи между ними set\get функции для взаимодействия. вот эта часть на первый взгляд кажется простой но как раз ее нужно внимательно делать, чтобы не упереться где нибудь в недостаток переменной или в зависимые функции между компонентами правка которой влияет на несколько сущности.
поэтому подобные вещи лучше проектировать в ui интерфейсе, проще передвинуть стрелочку виджета чем переписывать код.
вокруг этого строим конечный автомат. в самом потоке кода ищем якоря на которые опираться для выделение необходимого блока, будь то функция, бэйзик блок, логической блок, etc, создаем правила и через эти правила пропускам потом, нет же смысла гонять поток по нескольку раз, чтобы выделить функцию, цикл итд.
с моделью контрактов это проще делать, допустим есть код char buff[20]; это простой пример контракта, допустим вы арендовали склад на 20 ящиков, а засунуть туда 100500 это нарушение контракта, менять размер ящика это нарушение контракта, размер ящика и число указаны, но сторож склада мог уснуть в пьяном угаре и в склад могут отгрузить 100500, вот на такие моменты пишется триггер, которые в потоке выделяют контракт (создание буфера, выделение память) и далее сверяют исполнение условия, залив данных в буфер и размер этого добра, при нарушении запускать связанную с контрактом функцию, например остановка исполнения потока на месте нарушения. собственно эта система пришла из экономики и с точки зрения экономики ее проще объяснить программистам.

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

shellstorm

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

Допустим есть элементарная OP уязвимая конструкция, любая например ошибка проверки пределов case - какой смыл применительно к этой конструкции и решение ?

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

Покажите плз конкретно вашу идею/смысл применительно к этим частным и простейшим семплам. Что бы понять ход мыслей.

-----
vx

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

Парни, это не относится к теме "программирование". Это оффтоп, сферическая вакуумная конюшня.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

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

-----
Give me a HANDLE and I will move the Earth.

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

ARCHANGEL пишет:
Это оффтоп, сферическая вакуумная конюшня.

И даже хуже.

plutos пишет:
Но может и правда нужен новый раздел для подобного рода дискуссий?

а смысл?



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

dosprog пишет:
а смысл?
смысла очень много.. буквально вчера Vamit-а вспоминал.. до него никто ТАК к вопросу девиртуализации не подходил.. а в спорах рождается истина
ЗЫ 1 голова хорошо 2 лучше 3 уже дракон
ЗЫЫ есть у меня друг.. нифига в реверсе не смыслит.. когдато кодил.. ща админ.. так вот.. когда я впадаю в ступор.. набираем пиво.. и я начинаю ему рассказывать суть проблемы.. а он по мере того как я рассказываю.. задает наводящие вопросы.. где он че не понял. в результате, во первых я структурирую свою мысли, во вторых иногда проскакивают действительно креативные моменты. называется это мозговой штурм (он как логик.. нифига не дурак)

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

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

difexacaw пишет: Не понимаю

Может из этой статьи станет понятно зачем весь этот огород, сама архитектура должна быть спроектирована так, чтобы поток мог автоматически проходить валидацию через дерево правил.
https://habrahabr.ru/post/38612/
cfg можете дернуть отсюда https://github.com/bdcht/amoco
python, но кода мало и много комментариев, сам python читается практически так же, как псевдокод в среднестатистической книге, на этом же примере можно увидеть недостатки архитектуры. остальное не понятно, вы предлагаете написать за вас?
добавлю, уже писал как то о виртуальной машине erlang "beam", вот с точки зрения архитектуры она хорошо подходит под задачу "мотора визора", кроме задач которые на поверхности стоит подумать и над не очевидными задачами, что делать с легитимными инжектами и как быть с горячей заменой кода, последнее и вовсе является неотъемлемой частью разработки серверного и системного кода.

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

shellstorm

Начало по вашей ссылке:

> Я считаю, что корректная программа – это программа, которая выполняет не больше и не меньше того, на что она претендует.

Тоесть дальше можно не читать. Описан какой то старпёрский бред, основанный на комерс идеях и статистике. А ну конечно же примеры, они там только и способны выдать пару строк на вб)

> cfg можете дернуть отсюда

При задании вопроса я указал что доступны потоки данных, как один из них CFG. Он может быть статический и динамический. Тоесть выполнена часть CFG, который может быть целеком описан в статике. Я не спросил как это делать, каким образом и какой то софт тоже не просил. Вы наверно потеряли смысл вопроса

> кроме задач которые на поверхности стоит подумать и над не очевидными задачами, что делать с легитимными инжектами и как быть с горячей заменой кода, последнее и вовсе является неотъемлемой частью разработки серверного и системного кода.

Я всё понял. У вас не связанный поток мыслей. Просто что бы ответить, накидать всякого треша. Это тупо спам.

ARCHANGEL

Что значит конюшня" ?
Что вы увидели в этой теме относящееся к троям ?
Тут как раз таки наоборот, это механизмы защиты.

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

-----
vx

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

difexacaw пишет: Описан какой то старпёрский бред

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

difexacaw пишет: Я всё понял

Думаю давно все всё поняли и всё с вами ясно.

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

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

-----
Give me a HANDLE and I will move the Earth.

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

plutos пишет: получиться интересная тема

Не получится, достаточно спросить, как ТС собирается обрабатывать ошибки и что делать если все же с буфером что то случится, в ответ будет у меня на XP мотор работает без ошибок, можете сами посмотреть в отладчике, только не запускайте по F9, ибо чтение буфера идет в бесконечном цикле. intel точно о*ет от такого мотора и всем отделы направят на внедрение этой прорывной технологии.
По сути единственное, что он сейчас сделал этот hot swapping в виде буфера и по верх которого говнопарсер то-ли графов, то-ли деревьев. В софтварном решении монолитная реализация обречена на провал, никто не гарантирует работоспособность компонентов, никто не гарантирует, что компоненты будут оставаться нетронутыми во время работы, тем более никто не гарантирует устойчивость к отказам, навернулся буфер и мотор заглох и все маглы. Здесь просто нечего комментировать, в хогвардсе не проходили проектирование отказоустойчивых систем, совсем кратко https://habrahabr.ru/post/118496/

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

shellstorm, а зачем такой какбэ прошареный перец, как вы, все это писал ...?

От модератора: не надо здесь ругани базарной

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

shellstorm

Не правда, софтверная реализация полностью проработана.

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

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

> говнопарсер то-ли графов, то-ли деревьев.

Это нельзя сделать в реалтайме, он просядет в десятки/сотни раз, что приведёт к висяку или заметному отличию в работе апп(тормозам).

> в хогвардсе не проходили проектирование отказоустойчивых систем

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

-----
vx

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

microxa
когда же ты, млять, самовыпилишься... достали скрины дерьмоигр и сырки наикорявейшие
difexacaw
походу, по твою душу прошлись с намеком... если не прочел до модераторства
difexacaw
это радует, что не паришься

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

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

ajax

Так спам тут везде, мне лк этим спамят тоже.)

Добавлено спустя 33 минуты
ajax

> это радует, что не паришься

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

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

Моё мнение - авторов спама забанить, а данный топик привести в надлежащее состояние, эта задача весьма важна и не нужно вводить мусор в обсуждение. Посты с #24, этот и последующие удалите, спустя некоторое время.

ps: Тут нет пола или предпочтений, есть только задачи.

-----
vx

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

difexacaw
да, плевать. тип неадекват. о, и киса моя приехала с бухлом джеймесон!

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

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

difexacaw пишет: Не правда, софтверная реализация полностью проработана.

while(true){...} и все, game over, как раз для подобных вещей нужен агент, который следит за тем же флагом зацикливания, но чукча не читатель, чукча писатель о*тельных историй. целостность самого мотора какбэ тоже нелишне проверять.)

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

shellstorm

Что за флаг зацикливания" ?

Я поднимал задачу по выделению циклов --> Link <--

> while(true){...}

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

-----
vx

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

difexacaw пишет: При этом ничего не упадёт, поток будет выполнять бесконечный цикл, но этот цикл - корректная работа потока.

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

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

shellstorm

Как пример - когда я пишу это сообщение, клавиатурный ввод принимает поток сырого ввода(RIT), который ничего не делает, кроме как ретранслирует IOCTL(смена интерфейса) в гуй, крутясь в небольшом бесконечном цикле.

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

-----
vx

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