msrpc.sys exports

А вот например начиная с vista  rpc еще и в ядре живет в драйвере msrpc.sys
Список драйверов на чистой windows 7, имеющих в своем импорте ссылки на msrpc:

• afd.sys
• appid.sys
• fwpkclnt.sys
• ksecdd.sys
• netio.sys
• ntfs.sys
• srvnet.sys
• tcpip.sys
• tunnel.sys

На висте правда список значительно скромнее:

• fwpkclnt.sys
• netio.sys
• tcpip.sys

Собственно сами экспортируемые символы (они одинаковы на vista, vista sp2 & w7, так что в одну табличку все свел и отличаются они только битностью)

rpcrt4.dll exports 64bit

для симметрии с

rpcrt4.dll exports

экспорты rpcrt4.dll в vista & vista sp2 совершенно одинаковы

и еще про stuxnet

Первую иранскую АЭС заразил компьютерный вирус

"Лаборатории Касперского" - лидер потребительского рынка в России, странах СНГ и Балтии. За прошедший год "ЛК" стала безусловным лидером в некоторых странах: Иран, ЮАР, Ливия, где она переместилась по консьюмерским продажам на первое место

отсюдова - между прочим датировано 1 сентября 2010.

Чисто риторический вопрос - что случится раньше - ад замерзнет или Спасатели Вселенной™ хоть раз признаются что они дико обосрались ?

RPC enumeration

Поскольку в ответ на критическую заметку про ловлю stuxnet мне кинули предъяву в духе "а ты кто такой и сам ловить RPC интерфейсы не умеешь", то пришлось озаботиться данным вопросом
Гугл сказал мне что технология для rpc interfaces enumeration уже 9 лет как известна - rpctools
Используются при этом три вещи:

• список зарегистрированных в системе rpc ports, который можно посмотреть например в WinObj в директории \RPC Control
• совершенно официальная функция RpcMgmtInqIfIds из RPCRT4.dll
• пара не менее официальных функций RpcMgmtEpEltInqBegin & RpcMgmtEpEltInqNext

Далее берется список well known ms rpc named pipes и можно найти интерфейсы, которых на чистой машине быть не должно

Процесс можно автоматизировать даже, я думаю - написать к тому же perlу xs модуль для выгребания имен портов из \RPC Control (через ф-ции NtOpenDirectoryObject & NtQueryDirectoryObject) и вызывать ifids.exe для всех из них. Можно также запросить в каких процессах эти порты открыты (Process Explorer так умеет делать например)

Возвращаясь к исходному вопросу - какой онтевирус умеет проверять зарегистрированные в системе RPC интерфейсы ?

stuxnet

тут производители т.н. онтевирусов с выпученными глазами закатили истерику про stuxnet - типа караул, цыбервойна покупайте наших слонов и прочий обычный в подобных случаях маркетинговый бред
Тем временем по прочтении довольно подробного описания можно сделать следующий вывод - несмотря на кучу 0-days и векторов распространения палится присутствие этого поделия крайне примитивными дедовскими методами десятилетней давности- достаточно совершенно банально просканить содержимое памяти всех процессов и сравнить с содержимым файлов с диска (и про древние трюки с угоном IAT & EAT еще не забыть) + посмотреть наличие нотификаторов в kernel mode - например в IopFsNotifyChangeQueueHead & PspCreateProcessNotifyRoutine
А еще было бы недурно посмотреть какие RPC интерфейсы зарегистрированы в системе и в каких процессах, но по моему ни один av такое не умеет. Да чо там, я тоже не умею

Выводы - непечатно матом делайте сами

dlopen notifiy

а вот скожите мне - правда ли в linux никак не можно поставить штатными средствами нотификатор на событие загрузки/выгрузки программой модуля ? Я тут покурил давеча в стотыщпервый раз сорцы ld-linux.so - ад и содомия, риальне, причем за последние десять лет все стало еще страшнее пользоваться этим невозможно категорически
И эти люди еще смеют поливать всячески самую лучшую в мире операционную систему !

race condition attacks

пришлось мне тут на старости лет изучать создание оголтело многопоточных программ и после изнуряющего чтения разнообразных книжек возник у меня крайне глупый вопрос - а существуют в природе какие-нть инструменты (полагаю типа fuzzers, только перебирающие комбинации из временных задержек), которые умели бы делать вид находить subj ?
Вот например частный случай таких атак - double fetching
Гугл также говорит что бывают всякие разные случаи и их чуть более чем дофига, что характерно

Кто-нть уже автоматизировал способы нахождения такого рода атак ? Может даже книжка какая есть с описаниями и простынями формул чтобы стать дико умным и кидать понты например ?

aslr

дико угарная технология - с одной стороны мы помещаем ntdll.dll в память по псевдослучайным адресам (на самом деле их 256 штук всего, так что анекдот про миллиард кетайцев, вводящих пароль на сервере пентагона - это грустная реальность), а с другой

• адрес ntdll.dll одинаков во всех процессах. Ибо ядро при старте зачитывает некоторое количество экспортируемых из ntdll функций и периодически вызывает их просто по указателю
• если например в результате 256ой попытки эксплойт наконец получил управление - то можно получить TEB, из него PEB и дальше пройтись по списку PEB.Ldr.InLoadOrderModuleList например - там все указатели лежат в открытом виде (даже RtlEncodePointer не используется, в чем может убедиться любой желающий, продизассемблировав например функцию ntdll LdrpUpdateOrderLinks). Код уместится байт в 60 примерно

Если кто не читал например - дичайше рекомендую

глядя в окно

русская народная осенняя песня "ой морось-морось"

ndis!_NDIS_IF_PROVIDER_BLOCK

бонус-трек к жалким описаниям структур ndis
Начиная с висты в ndis появилась пара функций NdisIfRegisterProvider и NdisIfDeregisterProvider
WinDbg традиционно не умеет показывать какие провайдеры были зарегистрированы в системе, так что запускаем дизассемблер например

многопоточность в linux

поимел тут следующую содержательную беседу с весьма мною уважаемым человеком, который уже лет 12 (если не больше) занимается server-side программированием под всякие разные unix:

> на серверсайде тредов вообще быть не должно

обоснуй. я серьезно спрашиваю

> треды - легкие процессы, живущие в одном процессе в его хипе и стеке, за ними ос вообще не следит как за процессами по таблице процессов. отлаживать такое говно невозможно, как и наращивать.

за счет этого как раз и достигается профит - они юзают одну и ту же память

> промышленное использование тредов на серверсайде есть только у:
mysql, какое это говно - знают все.

java апликухи типа томкатов или веб сфер, но там жаве везет, т.к. по протоколу http 1.1 рано или поздно коннект отвалится и тред уничтожается, иначе падение неминуемо.

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

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

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

вообще все нормальные серверные решения сводятся к очень ограниченному объему:
надо быстро сделать говна кусок и веб - apache + mod_php,
так пхпистов развелось за 10 лет дох*я и готовы работать за еду.

надо что-то мощное и на нагрузках - c++ + libs + ipcs.

надо базы данных и есть бабло - оракл, лучшая платная реляционная дб.
бабла нету - постгрес, лучшая бесплатная.

все остальные жавы, питоны, отмиращий перл, руби, и прочие байтмашины
и говнотехнологии типа xml с еб*нутыми xslt и расширениями - оцтой и говно.

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

Дальше были простыни цыфр и мата
Надо много подумать

NDIS object types

смотрел я давеча примерчик network\ndis\filter из wdk7, и потратил довольно большое количество времени на отыскание всяких констант вроде NDIS_OBJECT_TYPE_DEVICE_OBJECT_ATTRIBUTES
Выяснилось что их определения лежат в файле inc\api\ntddndis.h, так что перепощу их здесь (мало ли - может у кого wdk нету например)

gcc atomic built-ins

с немалым интересом обнаружил давеча, что библиотека pthreads не имеет поддержки атомарных операций 21век на дворе есличо
гугл сказал что они имеются в наличии в gcc - и таки не обманул. Опыты показали что gcc настолько умен, что если результат функции не используется, то например вызов __sync_fetch_and_add(&some_var, 1) и вовсе превращается в lock inc [some_var]
Их правда не так чтобы особо много - с семейством Interlocked функций под windows не сравнить, но работает, да даже удивительно
Казалось бы все хорошо, но вот тут сказано, что появилась эта возможность начиная  с gcc версии 4.4.0, который был выпущен аж в апреле 2009 года ! Я не буду злорадствовать как линуксоиды писали свои гениальные многопоточные программы до 2009 года, но это просто - ...

И вот все у них так - дегенеративная совершенно os, отставшая от windows лет этак на 15

ntdll official hooks

Не так давно я выкладывал ссылки на catalog of NTDLL kernel mode to user mode callbacks
В ntdll.dll есть и некоторое количество экспортируемых функций, позволяющих user mode программам ставить всякие разные хуки и callbacks. И некоторые из этих функций даже документированы !
Соотв-но я сугубо для себя запишу тут некоторые из них. Память алкоголика - вещь загадочная, так что список наверняка не полон, а большую часть я просто не знаю например

profiler-driven linker

навеяло тут чтением всяких разных умных книжек
Вот например у нас есть некая прога и мы хотим выжать из нее максимум производительности кисонька, еще капельку. Как известно у современных процессоров есть кэш, код из которого исполняется на порядок быстрее, чем из RAM. Можно было бы собрать профайлером граф вызовов функций, найти в нем самые тесно (по числу вызовов во время тестовых прогонов) связанные подграфы, и подсунуть эту информацию линкеру для генерации окончательной версии программы, чтобы он сложил эти функции рядом. Тогда при исполнении они скорее всего попадут в кэш все сразу, что должно дать некоторый profit в виде довольно ощутимого прироста производительности. Можно кстати аналогичный трюк исполнить и со статическими данными программы.
Более того, поскольку у разных процессоров даже того же Intel размер кэша отличается - линкер мог бы заточить прогу под конкретно наш процессор

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

Update: все украдено придумано до нас - visual studio 2005 умеет делать практически вышеописанные действия под именем profile-guided optimization:

Block Layout. In this optimization, we form the hottest paths through a function, and lay them out such that hot paths are spatially located closer together. This can increase the utilization of the instruction cache and decrease the working set size and number of pages used.

patched pdbdump

залил на sourceforge сорцы обточенного грубым рашпилем pdbdump
Хотя оригинал и не обновляется уже 8 лет - у него правильная BSD-style license, так что его можно править для всяких своих целей невозбранно.
Я правда уже и не особо помню, что именно там пофиксил - добавил в PdbRender.cpp регистров от amd-64 и еще была пара мест где он у меня падал на всяких разных странных pdb - вроде бы уже не падает :-)
Еще для линковки либы от dia sdk больше не нужны - функция NoRegCoCreate коряво реализована в rp.cpp
Проект для visual studio 2005 прилагается

fltmgr.sys 64bit exports

Должен признаться что в предыдущем посте я несколько ошибся - у fltmgr.sys есть механизмы для enumeration (просто я их ни разу не использовал). Нужно смотреть правда насколько сложно их пропатчить/обмануть

руткиты под windows x64

прочитал тут наконец (я.тормоз) про tdl4
много нервно курил думал
Насколько я понимаю самым большим препятствием к распространению subj был именно запрет на загрузку неподписанных драйверов. После его обхода виста и windows 7 представляют собой отличное благоустроенное гнездо для проживание всякого с блэкджеком и шлюхами. Мы конечно помним про patch guard, но

•  во-первых у них всегда есть fltMgr.sys и с написанием фильтра файловой системы справится любой школьник. Значит сокрытие файлов и директорий делается намного проще, чем поддерживать зоопарк версий под 32битные версии windows (на некоторых из них fltMgr.sys например нету)
•  во-вторых у них всегда есть CmRegisterCallback, про который писал даже детский юмористический журнал ксакеп. Значит сокрытие веток в реестре представляет тривиальную задачу
•  в-третьих у них всегда есть windows filtering platform. Так что фильтровать и следить за трафиком опять же проще чем под 32битным дурдомом
• в-четвертых у них всегда есть ObRegisterCallbacks
• в-пятых все вышеописанное богатство (кроме fltMgr.sys) не предоставляет механизмов даже простой энумерации зарегистрированных драйверов и хуков. грабь воруй убивай - совершенно анонимно с точки зрения windows

apisetschema.dll

Если вы когда-нибудь смотрели windows 7, то могли заметить что многие системные .dll имеют очень странные импортированные модули api-MS-Win-Core-XXX.dll, которые хотя и присутствуют в %SystemRoot%\System32 (как hidden files), но кода внутри себя явно не содержат.
Гугл говорит что это извращение было сделано для поддержки мифического режима MinWin, хотя мне эта версия не кажется убедительной. Как бы там ни было, было бы весьма недурно знать, как резолвится импорт на эти модули на самом деле

windows 7 64bit PEB & TEB

для симметрии с

windows 7 PEB & TEB

не осилил найти в этих ваших инторнетах - проще самому все сделать как обычно