Привет) В данный момент у меня стоит задача написания антивирусного блокиратора. Целевая система — Windows XP. Мне не нужно создавать эмуляторы, песочницы, прибегать к сигнатурному анализу.
В основе лежит поведенческий блокиратор всех фунциклирующих процессов. От этого момента задача делится на 2:
1) регистрация действия процесса
2) анализ поведения
Поиск по п.1 привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса. В общем, частично задача решена, только что в SYSTEM не могу пока подгружать…и жесткие тормоза и т.п.))) Т.е. в общем случае это – что-то наподобе filemon,regmon, API Monitor.
Поиск по п.2 привел к фэйлу. Сама идея как бы и понятна и непонятна. Я не нашел ни 1 методического описания построения цепочек подозрительных действий и т.д. . Только что на некоторых сайтах есть обобщенные описания действий. Кроме того, существует 1000 и 1 способ сделать 1 и тоже.
Вопросы:
1) Насчет п2. Имеет ли смысл разрабатывать эту тему? Че и как делать – не очень понятно. Хотелось бы развернутого ответа)
2) Если п1==true, правильно ли выбран метод слежения? Я не использую хуки, так как они не позволяют перехватить взаимодействия с файлами.
Скорее всего, я что-то упустил, но все же жду от вас понимания, сочувствия, комментариев по пунктам, вопросам. Заранее СПС.

Здравствуйте, qweas, Вы писали:

Q>Привет) В данный момент у меня стоит задача написания антивирусного блокиратора. Целевая система — Windows XP. Мне не нужно создавать эмуляторы, песочницы, прибегать к сигнатурному анализу.
Q>В основе лежит поведенческий блокиратор всех фунциклирующих процессов. От этого момента задача делится на 2:
Q>1) регистрация действия процесса
Q>2) анализ поведения
Q>Поиск по п.1 привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса. В общем, частично задача решена, только что в SYSTEM не могу пока подгружать…и жесткие тормоза и т.п.))) Т.е. в общем случае это – что-то наподобе filemon,regmon, API Monitor.
Q>Поиск по п.2 привел к фэйлу. Сама идея как бы и понятна и непонятна. Я не нашел ни 1 методического описания построения цепочек подозрительных действий и т.д. . Только что на некоторых сайтах есть обобщенные описания действий. Кроме того, существует 1000 и 1 способ сделать 1 и тоже.
Q>Вопросы:
Q>1) Насчет п2. Имеет ли смысл разрабатывать эту тему? Че и как делать – не очень понятно. Хотелось бы развернутого ответа)
Q>2) Если п1==true, правильно ли выбран метод слежения? Я не использую хуки, так как они не позволяют перехватить взаимодействия с файлами.
Q>Скорее всего, я что-то упустил, но все же жду от вас понимания, сочувствия, комментариев по пунктам, вопросам. Заранее СПС.

1. А чё не понятно? Тысяча и один способ как зделать. Обобщите статистику вызываемых процессоом API, Вычлените потенциально опасные действия (типа установка службы, запись в сситемный каталог, установка атрибута скрытый файл), транслируйте первое во второе. Каждый раз как процесс совершил очередное потенциально опасное действие, проверейте, чего ещё опасного делал — ну и принимайте решения. Некоторые выставляют потенциально опасным действиям балы — если их число превысило определенный порог (и число балов и порог — величины имперические), то принимаеться решение — вредоносное по. Другие орентируються на цепочки действий (допустим если процесс пишет файл autorun.inf и ставит ему скрытые атрибуты; или пытаеться переписать системный файл; или устанавливает себя как службу).
2. А вам для чего? Если как серьёзный продукт, то — fail. "п1==" false. Единственно коректный способ написать серьёзный поведенческий блокиратор — это написать драйвер и инфраструктуру к нему. Но есть сильные подозрения, что такая задача Вам будет непосильна. Если в качестве там диплома/курсовика/развлечения — то нормально и так сойдёт. Я в том смысле, что если обратиться к теории — то ваш перехватьчик можно обойти и не одним способом.

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

Здравствуйте, 11molniev, Вы писали:

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

Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора? Иначе все сводится к перебору всех разновидностей вирусни, обобщению признаков. Насчет драйвера — уже видел, читал, нацелился, но что вы подразумеваете под инфраструктурой?

Здравствуйте, qweas, Вы писали:
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора? Иначе все сводится к перебору всех разновидностей вирусни, обобщению признаков. Насчет драйвера — уже видел, читал, нацелился, но что вы подразумеваете под инфраструктурой?

Q>Именно! У меня нет теории.
К сожалению мне не известно о каких либо книгах по этой теме. Есть немало публикаций в виде статей и презентаций, но либо поверхностно, либо перспективное будущее + они как правило на разных конференциях, поэтому вообще источники есть — но найти трудно.
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора?
По поводу источников вообще — есть пара аспектов:
1. Как в предыдущем ответе я говорил — посмотрите на различные проактивки, антивирусы и прочее. Да, я понял, что это не то, что Вы ищите. НО, настройки и поведение этих защит частично раскрывает и механизм их работы. К примеру Norton AntiBot (он правда не блокиратор) — открытым текстом пишет в настройках по каким критериям он отличает вредоностное по от нормального.
2. На разных форумах типа wasm.ru, cracklab.ru, и ещё пара-тройка сайтов, по памяти не назову. На них вскользь и в большую сторону в адрес проактивных защит но возникают вопросы и ответы, которые могут вам помочь.
3. Чтобы сделать шит надо знать что такое меч. Если вы претендуете на создание хорошего продукта — вы должны знать как работает вещи которые ваша защита будет детектить. В этом ваше самое слабое место — если эти знания есть, то необходимость в теории отпадает — вы делаете защиту от конкретных угроз. Если не знаете, то надо узнать.
Q>Именно! У меня нет теории. Есть источники, где можно почитать о логике блокиратора? Иначе все сводится к перебору всех разновидностей вирусни, обобщению признаков.
Вообщето именно так и надо делать. Знаете как работает то что хотите обнаружить -> знаете опорные точки (api вызовы в данном контексте) без которых это нечто не может функционировать -> анализируете процессы на действия попадающие в эти "опорные точки".
Q>Насчет драйвера — уже видел, читал, нацелился, но что вы подразумеваете под инфраструктурой?
Одним драйвером вам не отделаться — как минимум надо будет написать программу работающую с ним в тандеме и обеспечивающею взаимодействие с пользователем (если видели и читале, то уже поняли что драйвера имеют неограниченые возможности в сторону системы и минимальные в сторону пользователя). Но самое сложное конечно это драйвер.

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

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

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

Здравствуйте, Аноним, Вы писали:
А>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал
А>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
Чё то я этого не догнал. Со времен nt 1.0 мапяться в память и там юзаеться. И чем это мешает? В обход системы загруженой работать будет? Ну так в ring0 сначала втиснуться надо для таких делов то, да и то, не очень то в обход выйдет.
А>В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD).
Ага. И порно банеры винлокеров вообще сильно повышают себе привелегии. Аж в ядро лезут. Ах нелезут? Таких как русток, эксплуатирующих уязвимости ядра — еденицы. В смысле единицы пролезающих в ядро. А вот пролезающих через дыры в ОС... Не помню че там делал русток, но к примеру tdl подпихивает себе вовсе не через сплоиты.
А>как например для киса — юзаем буфер с PAGE_GURD
каспер не образец идеальной проактивки. Любой драйвер может отмапить память любого процесса с любыми провами. У кусок виртуальной памяти с PAGE_GUARD? А друйвера кусок виртуальной памяти с PAGE_EXECUTE_READWRITE. А физическая память этих виртуальных кусков — одна и таже. Так что на кривые руки кав нечего пенять.
А>Вас спасёт только виртуальная машина, ну первую неделю спасёт после релизенга. Потом я и остальные запилят антиэмуль.
А что вы подразумеваете под виртулальной машиной? Intel VT или как-его-там? protect mode — по мне вполне себе виртуализация, дле железа. И перехват всего что идет через 2eh — тоже вполне себе виртуализация, для ос. И с этой точки зрения поведенческий блокиратор — это как раз виртуальная машина, которая прекращает работать, как только что-то не так.
А>Потом я и остальные запилят антиэмуль.
Пилите Шура, пилите)) Само собой, ничто несовершенно.

Здравствуйте, 11molniev, Вы писали:

1>Здравствуйте, Аноним, Вы писали:
А>>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал
А>>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
1>Чё то я этого не догнал. Со времен nt 1.0 мапяться в память и там юзаеться. И чем это мешает? В обход системы загруженой работать будет? Ну так в ring0 сначала втиснуться надо для таких делов то, да и то, не очень то в обход выйдет.

Вы ведь сказали:
> привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса.
Как обычно релоцируем образ или ремапим его. Все ваши патчи идут лесом.

А>>В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD).
1>Ага. И порно банеры винлокеров вообще сильно повышают себе привелегии. Аж в ядро лезут. Ах нелезут? Таких как русток, эксплуатирующих уязвимости ядра — еденицы. В смысле единицы пролезающих в ядро. А вот пролезающих через дыры в ОС... Не помню че там делал русток, но к примеру tdl подпихивает себе вовсе не через сплоиты.

Винлокеры это примитивнейшие приложения. Это не малварь. Нашли что в пример приводить.

А>>как например для киса — юзаем буфер с PAGE_GURD
1>каспер не образец идеальной проактивки. Любой драйвер может отмапить память любого процесса с любыми провами. У кусок виртуальной памяти с PAGE_GUARD? А друйвера кусок виртуальной памяти с PAGE_EXECUTE_READWRITE. А физическая память этих виртуальных кусков — одна и таже. Так что на кривые руки кав нечего пенять.

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

1>Пилите Шура, пилите)) Само собой, ничто несовершенно.

Вы вначале в паблик релиз киньте. С удовольствием ковырнём.

Здравствуйте, Аноним, Вы писали:

А>>>С инжектом разобрались, теперь рассмотрим это. Со временем маразм крепчал
А>>>Ну и что вы собрались детектить, если есчо со времён рустока копия образа мапится в память и там юзается, в обход системной загруженной.
1>>Чё то я этого не догнал. Со времен nt 1.0 мапяться в память и там юзаеться. И чем это мешает? В обход системы загруженой работать будет? Ну так в ring0 сначала втиснуться надо для таких делов то, да и то, не очень то в обход выйдет.
А>Вы ведь сказали:
>> привел к необходимости перехвата вызовов API путем загрузки dll в удаленный поток целевого процесса.
А>Как обычно релоцируем образ или ремапим его. Все ваши патчи идут лесом.

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

А>>>В добавок всегда юзаются сплоеты, кпл повышается через осевые уязвимости, либо в обход защиты(как например для киса — юзаем буфер с PAGE_GURD).
1>>Ага. И порно банеры винлокеров вообще сильно повышают себе привелегии. Аж в ядро лезут. Ах нелезут? Таких как русток, эксплуатирующих уязвимости ядра — еденицы. В смысле единицы пролезающих в ядро. А вот пролезающих через дыры в ОС... Не помню че там делал русток, но к примеру tdl подпихивает себе вовсе не через сплоиты.
А>Винлокеры это примитивнейшие приложения. Это не малварь. Нашли что в пример приводить.

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

А>>>как например для киса — юзаем буфер с PAGE_GURD
1>>каспер не образец идеальной проактивки. Любой драйвер может отмапить память любого процесса с любыми провами. У кусок виртуальной памяти с PAGE_GUARD? А друйвера кусок виртуальной памяти с PAGE_EXECUTE_READWRITE. А физическая память этих виртуальных кусков — одна и таже. Так что на кривые руки кав нечего пенять.
А>Для большинства файеров перехват сисколов обходится через рк атаку с помощью сторожевых страниц. Но вы видимо не в курсе.

Я действительно не в курсе. И подозреваю что говорим мы о разных вещах. Еще раз: я говорю о режиме ядра. Поведенческий блокиротор блокирует по факту вызовов api. Если говорит про XP — то тот же кав/кис (старые правда) патчет сервисную таблицу — ваши вызовы либо пройдут через него либо не пройдут через систему (не будут исполнены). Если говорить о семерке/современных проактивках/блокираторах и прочей хрени — то ваш вызов api в либо пройдет через callback-и/минифильтры либо не дойдет до адресата и не будет исполнен. Ставте эти права спокойно — на поведенческий блокиратор он повлиять не должен.
Если вы говорите о сигнатурном поиске, то из за кривых ручек установка данного атрибута защиты может и приводит к таким результатам. Непробовал. НО, ещё раз повторяю, драйвер (причем любой) может повторно отмапить кусок памяти любого процесса с любыми правами. У вас страница с вашим PAGE_GURD по вашему виртуальному адресу 0x04674000. У драйвера по адресу 0хB6882000 с атрубутом любого доступа. или у его доверенного приложения по адресу 0x0а124000 — а физически это один и тот же кусок оперативной памяти. Через этот механизм менеджера памяти в частности работает межпроцессорное взаимодействие через проэцируемые файлы. И все вашы атрибуты бесполезны — они работают в контексте вашей виртуальной памяти и не действую в контексте виртуальной памяти системной или других процессов.

1>>Пилите Шура, пилите)) Само собой, ничто несовершенно.
А>Вы вначале в паблик релиз киньте. С удовольствием ковырнём.

Чёй релез? Вы путаете меня с автором вопроса? Пожалуста, обратите внимание на имена авторов сообщений этого треда.

Я в шоке от происходящего. Спасибо вам ребят за столь информативные ответы...споры))
Я вообще писал на разные форумы, мне упомянули об ETW. Стоит на эту штуку расчитывать?
А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы)) Не зохват мира, не лютый взлом...Тем не менее, хочется сделать получше, и поэтому я уже приготовился к грядущей головной боли. Он действительно пишется под ХР. Вы упомянули антивирусные системы, как уних устроен такого рода перехват? И насчет межпроцессного взаимодействия...какой способ работает быстрее всего? Щас просто в уч целях, перебрав мэйл слоты, каналы, маппинг, атомы, выбрал каналы как самый подходящий.

Здравствуйте, qweas, Вы писали:

Q>Я в шоке от происходящего. Спасибо вам ребят за столь информативные ответы...споры))
Q>Я вообще писал на разные форумы, мне упомянули об ETW. Стоит на эту штуку расчитывать?
В первые слышу. Посмотрел сейчас — это же вроде настройка над счетчиками производительности? Если так то вам от нее толку не будет.

Q>А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы)) Не зохват мира, не лютый взлом...Тем не менее, хочется сделать получше, и поэтому я уже приготовился к грядущей головной боли.
Порой лучше сделать хоть что то. Во всяко случае оставте обходной путь для отката на вариант без драйверов. Если в учебных целях.
Q>Он действительно пишется под ХР.
Есть такая штука — Windows Kernel Reseach. Там есть исходники ядра Windows XP SP3. В вашем случае наверно можно просто впихнуть свой исходный код туда и пересобрать. Но для подобного опыт разработки драйверов обязателен.

Q>Вы упомянули антивирусные системы, как уних устроен такого рода перехват?
Конкретно до XP почти все баловались перехватом Nt* функциий подменой адресов сервисной таблицы дескрипторов (SDT). И для вас лучше наверно именно этот способ: он относительно прост и позволяет перехватить все общение между ядром и пользовательским пространством (читай между всеми приложениями и ос-ю). С вистой майкрософт на модификацию ядра в целом и этой таблицы в особеннгости стал смотреть косо (Path Guard), зато расширили api (ядерных) для драйверов безопастности. Второй вариант (и для хр кстати) — это использование апи безопастности: драйвер фильтр на файловую систему — полный контроль за доступом к фс, callback диспечеру конфигурации — полный контроль за доступом к реестру, нотификация от менеджера процессов — контроль за созданием новых процессов (точней загрузкой образов pe файлов). Единственное чего в хр нет точно — это контроль за доступом к чужой памяти и над gui. Как с этим в висте/7 не знаю, может и улучшили. Есть старая книга Сорокина — программирование драйвервов и систем безопастности. На руском наиболее тематическая по этому вопросу.

Q>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего? Щас просто в уч целях, перебрав мэйл слоты, каналы, маппинг, атомы, выбрал каналы как самый подходящий.
Для больших объемов данных быстрей всего — проэцируемые в память файлы. каналы, слоты, сокеты и т.д. копирует передаваемую информацию, при мапинга копирования нет. Но его придеться сочетать с способом передачи сообщений между процессами (уведомить о том что данные обновились) — самый быстрый (если я не ошибаюсь) именнованные события. По идеи у рихтора должно быть написано что быстрей и почему — посмотрите.

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

Здравствуйте, qweas, Вы писали:

Q>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

LPC.

Q>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?
А>LPC.
LPC сделан на shared memory. Так что ничем не быстрее named shared memory + SignalObjectAndWait с двух концов.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, qweas, Вы писали:

Q>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

А>LPC.

Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?

Здравствуйте, qweas, Вы писали:

Q>Большое спасибо. Кажется, среди многих вы чуть ли не единственный на помощь которого можно расчитывать В случае возникновения фундаментальных вопросов, как можно с вами связаться? Обещаю не наглеть) Пока какой-то вопрос вознкнет думаю месяц точняк пройдет)

Да тут на форуме и можно. Я его просмотриваю чаще, чем проверяю почту)

Здравствуйте, 11molniev, Вы писали:

1>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, qweas, Вы писали:

Q>>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?

А>>LPC.

1>Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?

Вполне документирован. Не менее чем SST и прочие внутренние особенности. Это мощный механизм, позволяющий безгеморно обслуживать множество клиентов. Разумеется быстрее своя синхронизация на паре событий(Event Pair, тоже обьект не дукументированный кстати ). В любом случае такая синхронизация, при которой ожидается ответ клиента повесит всю ось, либо процесс.

Здравствуйте, Аноним, Вы писали:

Q>>>>И насчет межпроцессного взаимодействия...какой способ работает быстрее всего?
А>>>LPC.
1>>Это же недокументированый механизм (я в курсе статьи). Зачем вы советуете использовать недокументированые функции ОС?
А>Вполне документирован. Не менее чем SST и прочие внутренние особенности.
Под документированостью/недокументированостью я имею в виду его описание в msdn-е. Немножко гарантирующее, что microsoft не поступит с этим фпи так же как с sst. На семерке его даже руткиты стороной обходят (я имею в виду не крутые, которые обходятся без него чтоб не палиться).

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

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

А>Разумеется быстрее своя синхронизация на паре событий(Event Pair, тоже обьект не дукументированный кстати ). В любом случае такая синхронизация, при которой ожидается ответ клиента повесит всю ось, либо процесс.
Не использовал, поэтому могу ошибаться. Но вообще вся синхронизации работающая по Wait* и ваши пары событий в частности должна иметь примерно с одинаковую скорость. Пока планировщик не выдаст квант времени потоку, с которого снят флаг ожидания — ничего до него не дойдет. Единственное, в случае использования остатков текущего кванта для разморозки ожидающего потока, при смене состояния объекта синхронизации, будет быстрей работать; Ваши пары событий по такому принципу сделаны? Это дает более быстрый отклик, но общая производительность должна деградировать из-за переключений контекста, поэтому я не уверен, что подобный подход используеться для каких либо объектов синхронизации.
И поэтому думаю особой разницы между тем, что использовать для межпроцесной сминхронизации нет. Нужно использовать, что удобней.

1>И поэтому думаю особой разницы между тем, что использовать для межпроцесной сминхронизации нет. Нужно использовать, что удобней.
нафиг eventpair'ы, они кстати разве сапортяться?
SignalAndWaitForSingleObject сигналит один ивент и переходит в режим ожидания "атомарно", то есть не отпуская планировщик сразу после сигнала. Вобщем то реализован он как

KeSetEvent(.., .., TRUE); 
KeWaitForSingleObject(...

Здравствуйте, qweas,

Q>А целью создания блокиратора(скорее перехватчика-анализатора) является сдача учебной работы))
--
Если это учебная задача, то порекомендую обратить внимание на fuzzy logic (нечеткую логику), которую можно достаточно формально использовать вместо эвристических алогиртмов.

C уважением,
Геннадий Майко.

Q>Кажется, среди многих вы чуть ли не единственный на помощь которого можно расчитывать...

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