netio.sys exports 64bit

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

netio.sys exports

netio.sys - главная запчасть Network Programming Interface

A catalog of NTDLL kernel mode to user mode callbacks

а вот если кто не читал например - отличное чтиво в дождливый вечер про subj:
раз
два
три
четыре
пять
шесть
чтиво старенькое (2007) но душеполезное. А вобще жаль что гражданин кроме своего jit engine больше ни про что не пишет в последнее время

дочитал C++ Concurrency in Action

был неиллюзорно поражен скудностью и лаконичностью главы 10 - Testing and Debugging Multithreaded Applications

Автор упоминает про combination simulation testing - идея в том чтобы протестировать все возможные комбинации всех локов всеми потоками на симуляторе. Несложно догадаться что сложность этого алгоритма O(N!), где N - сумма потоков и объектов блокировки, и вряд ли когда-нибудь этот метод будет реализован на практике. Однако - на самом деле нам не нужно прогонять все возможные комбинации при тестировании некоего куска кода - в большинстве случаев достаточно всего лишь прогнать все возможные комбинации одновременно работающих потоков, что на машине с n камнями и N потоками (как правило N > n) дает нам подмножества n конечных множеств из N (биномиальный коэффициент, ага). Практически этого можно достигнуть например применяя под linux соответствующим образом написанный планировщик - нужно дописать к нему интерфейс общения из user mode и ровно 3 ioctls:

• поместить некий поток в группу
• запустить перебор на одновременное исполнение для всех потоков в группе
• сообщить результаты перебора (готово-неготово-сколько циклов прогнано)

Также автор упоминает про tests with special library, но из целой одной странички, посвященной изложению темы, можно почерпнуть мало чего. Однако - это крайне богатая идея, например можно придумать достаточно простой алгоритм для нахождения взаимной блокировки потоков. Пусть у нас есть два три потока - A, B и С, и скажем поток C делает join к потоку B, поток B делает join к потоку A, а поток A собирается сделать join с потоку C, что даст в результате вечный deadlock. Нет ничего проще - заводим внешний орграф, в нем узлы - потоки, а операции join - ребра, при добавлении нового ребра проверяем граф на наличие циклов. Если цикл обнаружен - у нас deadlock в коде

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

• A, залочивший mutex a и пытающийся залочить mutex b
• поток B, залочивший mutex b и висящий на ожидании mutex a. 

По моему для случая двух потоков нахождение таких взаимоблокировок - совершенно тривиальная задача. Или можно представлять объекты синхронизации как узлы графа, а использующие их потоки - как ребра (например в вышеописанном примере поток A будет ребром между mutexes a & b, а поток B - ребром между b & a). Нахождение взаимоблокировки в таком случае - поиск циклов графа, составленных из ребер разных потоков.

Локализация бывает смертельно опасна

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

CmRegisterCallback(Ex) on Vista

полагаю что функция, про которую я сегодня будут писать всякое, в представлении не нуждается - про нее знает даже детский юмористический журнал ксакеп
Очень хочется иногда посмотреть кто же имено тут такой умный поставил этот хук и например снять его с мясом чтоб неповадно было. Техника просмотра установленных хуков под windows xp достаточно подробно описана в первом номере журнала no bunkum (кому объяснения в статье кажутся недостаточно подробными - могут курить файл base\ntos\config\cmhook.c из wrk). Это хорошая новость. Плохая новость - начиная с висты формат хранения хуков, установленных функциями CmRegisterCallback(Ex), радикально поменялся и требует больше ударов в бубен и человеческих жертвоприношений

ndis!_NDIS_M_DRIVER_BLOCK

Начало
Часть 1
Часть 2
Часть 3 
Часть 4
Часть 5
Эта последняя (я надеюсь) часть дает определения структур _NDIS_M_DRIVER_BLOCK и описывает способ их получения.

C++ Concurrency in Action

осилил например за неделю примерно половину subj (автор книжки кстати тоже блоггер, бгг)
осмелюсь заметить что

• судя по приводимым примерам C++0x - не менее бесмысленно многословный монстр чем java, а уж его standard library - вобще template hell с длиннейшими названиями для всего и к использованию непригодна чуть более чем полностью
• дико порадовала фраза при обсуждении reader-writers mutexes "Unfortunately, the new C++ Standard Library does not provide such a mutex out of box...the examples in this section use the implementation provided by the Boost". Какое богатое поле для толкований ! Можно прочитать как "в комитете по стандартизации C++0x сидят полные придурки, ничего в жизни сами не написавшие и просто не понимающие что людям действительно нужно". Ну и без бессмысленного пожирателя ресурсов буста вы все равно обойтись не сможете, даже не надейтесь. Я прям даже и не знаю как умудрялся писать многопоточные проги на одном лишь чистом win32 api доктор что со мной ?
• глава 5 про atomic types - это нечто запредельное по невнятности изложения. Если б я не знал например как оно устроено на уровне ассемблера - хер бы чего понял. Ибо автор не описывает что и почему, а просто излагает как оно реализовано. И пойди догадайся, что после записи в переменную на самом деле значение пишется в кеш, а в память может еще и не сразу попасть без соответствующего танца с саблями бубном. Примеры из реальной жизни почему-то полностью игнорируются. Я понемаю, виндовс сделан прямыми наследниками сотоны и потому про семейство Interlocked функций автор может быть и не в курсе. Но можно было бы взять например файлы atomic.h, mutex.h, spinlock.h из директорий arch\xxx\include\asm того же ядра linux, и даже не обязательно чтобы xxx==x86. Хотя linux тоже написан отпочковавшимися наследниками сотоны по другой линии 
• при попытке скопировать куски из pdf получаю бодрое сообщение "Sorry, copying text from this document is not allowed". Ампутировать нужно железу алчности без наркоза таким издателям ящитаю

Глава 6 про конкурентные структуры данных пока что самая информативная из всей книги.
С интересом продолжаю чтение

ndis.sys exports 64bit

то же самое только для 64 бит

ndis.sys exports

для всяких разных версий windows

скрипт для подсчета частоты импортированных символов

таки пришлось сегодня самому писать
берет на входе 1 или больше файлов, произведенных dumpbin /imports (я использовал от visual c++ 2008 - возможно для других версий формат выходного файла поменялся и нужно поправить функцию parse_file) и выдает на выходе статистику

Most frequently imported symbols

нашол давеча
Было бы полезно аналогичную статистику иметь для \SystemRoot\System32\Drivers\*.sys,но похоже снова самому придется делать
И да - если вы думаете что мои предыдущие четыре поста обладают неприлично огромными размерами - можете сравнить или тут еще

ntoskrnl.exe exports 64bit

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

ntoskrnl.exe exports

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

ntdll.dll exports 64bit

бонус-трек к предыдущей записи - теперь банановый для 64бит

ntdll.dll exports

Потребовалось мне тут найти, какие имена экспортируются из ntdll.dll для всех 32битных windows - и ведь не нашел в этих ваших интернетах
Точнее нашел, но только по w2k3
Пришлось как обычно - кряхтя слазить с печи и делать самому

дровопейсатели - страшные люди

A computer that monitored drilling operations on the Deepwater Horizon had been freezing with a [BSOD] prior to the explosion that sank the oil rig last April, the chief electrician aboard testified Friday at a federal hearing.

In his testimony Friday, Michael Williams, the chief electronics technician aboard the Transocean-owned Deepwater Horizon, said that the rig’s safety alarm had been habitually switched to a bypass mode to avoid waking up the crew with middle-of-the-night warnings.
отсюдова

kaspersky небось какой стоял, бгг

ndis!_NDIS_FILTER_DRIVER_BLOCK

Начало
Часть 1
Часть 2
Часть 3 
Часть 4
В этой части даются определения структур _NDIS_FILTER_DRIVER_BLOCK, описывающих фильтры ndis 6.x (доступны начиная с висты) и как их получить
Должен заметить что тема весьма мутная и в интернете представлена крайне слабо - например я нашел только одну более-менее подробную статью, да и та на китайском

Offsets plugin

Залил на sourceforge сорцы еще одного античного (2001 года выпуска) баяна, портированного (с borland c++ между прочим и ida 4.15) на visual c++ 6.0 и ida 5.0

user32!apfnDispatch

а вот если кто не знал например - есть в природе такой способ перехвата в usermode PEB.KernelCallbackTable, причем насколько я знаю его мало кто детектит
Индексы функций можно посмотреть например тут
Соотв-но написал сегодня проверяльщик - ничего особенного, находит в user32.dll таблицу apfnDispatch и проверяет ее целостность и что PEB.KernelCallbackTable указывает именно на нее.
По ходу дела выяснилось что

• начиная с windows 7 она живет в секции .rdata
• можно обойтись без ассемблера - например получить TEB в своем процессе на чистом как слеза комсомолки Visual С++ можно так - под 32битами через __readfsdword(0x18), под 64битами - через __readgsqword(0x30)
• получить PEB в чужом процессе - через NtQueryInformationProcess с классом ProcessBasicInformation

Language Implementation Patterns

дочитал давеча subj
имею крайне раздраженное мнение - во-первых все примеры даются на склизком неповоротливом бессмысленно многословном монстре языке java
Во-вторых я умею использовать bison уже лет 15 и всегда считал что lalr парзеры рвут ll с их backtrackingом по скорости как тузик грелку.

Но по прочтении выяснилось и кое-что полезное:

• antlr умеет генерить код не только для java, но и для более приличных языков
• antlr умеет также автоматически строить в процессе разбора AST дерево, чего мне в bison всегда не хватало
• и даже более того - вместе с построением AST умеет также строить к нему tree walker
• и даже tree pattern matcher ! правда во всей книге дано ровно полтора примера как с его помощью можно делать tree rewriting

Первую часть книги можно вобще пропустить (ну или пролистать), потому что в ней долго и нудно объясняется что такое парзер и как он работает, при этом автор умудрился не дать определение lr и lalr парзерам
Вторая часть самая содержательная - в ней объясняется как строить AST, как по нему ходить, как строить символьные таблицы и scope trees. Крайне рекомендую главу 8 - даны вполне понятные примеры построения static type checker
Третья часть очень лихо пробегает по техникам построения виртуальных машин - стековых и регистровых. Не особо подробно впрочем, как прикрутить к AST генератор байт-кода вы из нее не узнаете.
А вот четвертая часть, посвященная самому интересному - трансляции языков и созданию генераторов, откровенно лажает - в главе 11 кратко упоминается про существование rule engines для создания генераторов и дальше автор съезжает на использование templates, в особенности на применение StringTemplate

Прочитать книжку определенно стоило, но некоторые вещи описаны весьма поверхностно

MachO PICode plugins

Продолжая тему анализа в IDA Pro position independent code - залил на sourceforge еще парочку plugins - для 32битных Mach-O файлов
MachOPIC - для 32битных PPC файлов
machiPIC - для 32битных i386 файлов