windows deep internals: декабря 2011

пятница, 30 декабря 2011 г.

wincheck rc8.5

add -sched option to dump threads from scheduler structures. Warning: since XP scheduler contains in wait list not all waiting threads
improved support of old wk2 (sp1/sp2/sp3)

четверг, 29 декабря 2011 г.

оказывается бывает и такое
Вот например system worker из тех что отсутствуют в KiWaitListHead:
dt -r1 _KTHREAD 8A8B1C98
ntdll!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x6 ''
      +0x001 Absolute         : 0 ''
      +0x002 Size             : 0x70 'p'
      +0x003 Inserted         : 0 ''
      +0x004 SignalState      : 0
      +0x008 WaitListHead     : _LIST_ENTRY [ 0x8a8b1ca0 - 0x8a8b1ca0 ]
   +0x010 MutantListHead   : _LIST_ENTRY [ 0x8a8b1ca8 - 0x8a8b1ca8 ]
      +0x000 Flink            : 0x8a8b1ca8 _LIST_ENTRY [ 0x8a8b1ca8 - 0x8a8b1ca8 ]
      +0x004 Blink            : 0x8a8b1ca8 _LIST_ENTRY [ 0x8a8b1ca8 - 0x8a8b1ca8 ]
   +0x018 InitialStack     : 0xba4e0000
   +0x01c StackLimit       : 0xba4dd000
   +0x020 Teb              : (null)
   +0x024 TlsArray         : (null)
   +0x028 KernelStack      : 0xba4dfd24
   +0x02c DebugActive      : 0 ''
   +0x02d State            : 0x5 ''
   +0x02e Alerted          : [2] ""
   +0x030 Iopl             : 0 ''
   +0x031 NpxState         : 0xa ''
   +0x032 Saturation       : 0 ''
   +0x033 Priority         : 13 ''
   +0x034 ApcState         : _KAPC_STATE
      +0x000 ApcListHead      : [2] _LIST_ENTRY [ 0x8a8b1ccc - 0x8a8b1ccc ]
      +0x010 Process          : 0x8a8b2830 _KPROCESS
      +0x014 KernelApcInProgress : 0 ''
      +0x015 KernelApcPending : 0 ''
      +0x016 UserApcPending   : 0 ''
   +0x04c ContextSwitches : 0x6eb9
   +0x050 IdleSwapBlock    : 0 ''
   +0x051 Spare0           : [3] ""
   +0x054 WaitStatus       : 0
   +0x058 WaitIrql         : 0 ''
   +0x059 WaitMode         : 1 ''
   +0x05a WaitNext         : 0 ''
   +0x05b WaitReason       : 0xf ''
   +0x05c WaitBlockList    : 0x8a8b1d08 _KWAIT_BLOCK
      +0x000 WaitListEntry    : _LIST_ENTRY [ 0x8a8b1a90 - 0x80564828 ]
      +0x008 Thread           : 0x8a8b1c98 _KTHREAD
      +0x00c Object           : 0x80564820
      +0x010 NextWaitBlock    : 0x8a8b1d08 _KWAIT_BLOCK
      +0x014 WaitKey          : 0
      +0x016 WaitType         : 1
   +0x060 WaitListEntry    : _LIST_ENTRY [ 0x0 - 0x8055c4a8 ]
      +0x000 Flink            : (null)
      +0x004 Blink            : 0x8055c4a8 _LIST_ENTRY [ 0x895aab20 - 0x89a43c28 ]
   +0x060 SwapListEntry    : _SINGLE_LIST_ENTRY
      +0x000 Next             : (null)
   +0x068 WaitTime         : 0x46a46
   +0x06c BasePriority     : 13 ''
   +0x06d DecrementCount   : 0x10 ''
   +0x06e PriorityDecrement : 0 ''
   +0x06f Quantum          : 3 ''
   +0x070 WaitBlock        : [4] _KWAIT_BLOCK
      +0x000 WaitListEntry    : _LIST_ENTRY [ 0x8a8b1a90 - 0x80564828 ]
      +0x008 Thread           : 0x8a8b1c98 _KTHREAD
      +0x00c Object           : 0x80564820
      +0x010 NextWaitBlock    : 0x8a8b1d08 _KWAIT_BLOCK
      +0x014 WaitKey          : 0
      +0x016 WaitType         : 1
   +0x0d0 LegoData         : (null)
   +0x0d4 KernelApcDisable : 0
   +0x0d8 UserAffinity     : 3
   +0x0dc SystemAffinityActive : 0 ''
   +0x0dd PowerState       : 0 ''
   +0x0de NpxIrql          : 0 ''
   +0x0df InitialNode      : 0 ''
   +0x0e0 ServiceTable     : 0x8055c700
   +0x0e4 Queue            : 0x80564820 _KQUEUE
      +0x000 Header           : _DISPATCHER_HEADER
      +0x010 EntryListHead    : _LIST_ENTRY [ 0x80564830 - 0x80564830 ]
      +0x018 CurrentCount     : 0
      +0x01c MaximumCount     : 2
      +0x020 ThreadListHead   : _LIST_ENTRY [ 0x8a8b1db0 - 0x89fadaa0 ]
   +0x0e8 ApcQueueLock     : 0
   +0x0f0 Timer            : _KTIMER
      +0x000 Header           : _DISPATCHER_HEADER
      +0x010 DueTime          : _ULARGE_INTEGER 0xa`644f6499
      +0x018 TimerListEntry   : _LIST_ENTRY [ 0x8055ce00 - 0x8a322670 ]
      +0x020 Dpc              : (null)
      +0x024 Period           : 0
   +0x118 QueueListEntry   : _LIST_ENTRY [ 0x8a8b1b38 - 0x80564840 ]
      +0x000 Flink            : 0x8a8b1b38 _LIST_ENTRY [ 0x8a8b18c0 - 0x8a8b1db0 ]
      +0x004 Blink            : 0x80564840 _LIST_ENTRY [ 0x8a8b1db0 - 0x89fadaa0 ]
   +0x120 SoftAffinity     : 3
   +0x124 Affinity         : 3
   +0x128 Preempted        : 0 ''
   +0x129 ProcessReadyQueue : 0 ''
   +0x12a KernelStackResident : 0 ''
   +0x12b NextProcessor    : 0x1 ''
   +0x12c CallbackStack    : (null)
   +0x130 Win32Thread      : (null)
   +0x134 TrapFrame        : (null)
   +0x138 ApcStatePointer : [2] 0x8a8b1ccc _KAPC_STATE
      +0x000 ApcListHead      : [2] _LIST_ENTRY [ 0x8a8b1ccc - 0x8a8b1ccc ]
      +0x010 Process          : 0x8a8b2830 _KPROCESS
      +0x014 KernelApcInProgress : 0 ''
      +0x015 KernelApcPending : 0 ''
      +0x016 UserApcPending   : 0 ''
   +0x140 PreviousMode     : 0 ''
   +0x141 EnableStackSwap : 0x1 ''
   +0x142 LargeStack       : 0 ''
   +0x143 ResourceIndex    : 0x1 ''
   +0x144 KernelTime       : 0x19
   +0x148 UserTime         : 0
   +0x14c SavedApcState    : _KAPC_STATE
      +0x000 ApcListHead      : [2] _LIST_ENTRY [ 0x8a8b1de4 - 0x8a8b1de4 ]
      +0x010 Process          : (null)
      +0x014 KernelApcInProgress : 0 ''
      +0x015 KernelApcPending : 0 ''
      +0x016 UserApcPending   : 0 ''
   +0x164 Alertable        : 0 ''
   +0x165 ApcStateIndex    : 0 ''
   +0x166 ApcQueueable     : 0x1 ''
   +0x167 AutoAlignment    : 0 ''
   +0x168 StackBase        : 0xba4e0000
   +0x16c SuspendApc       : _KAPC
      +0x000 Type             : 18
      +0x002 Size             : 48
      +0x004 Spare0           : 0
      +0x008 Thread           : 0x8a8b1c98 _KTHREAD
      +0x00c ApcListEntry     : _LIST_ENTRY [ 0x0 - 0x0 ]
      +0x014 KernelRoutine    : 0x80502f64        void nt!KiSuspendNop+0
      +0x018 RundownRoutine   : 0x80502f6c        void nt!PopDispatchProcessorPolicyCallout+0
      +0x01c NormalRoutine    : 0x80502f74        void nt!KiSuspendThread+0
      +0x020 NormalContext    : (null)
      +0x024 SystemArgument1 : (null)
      +0x028 SystemArgument2 : (null)
      +0x02c ApcStateIndex    : 0 ''
      +0x02d ApcMode          : 0 ''
      +0x02e Inserted         : 0 ''
   +0x19c SuspendSemaphore : _KSEMAPHORE
      +0x000 Header           : _DISPATCHER_HEADER
      +0x010 Limit            : 2
   +0x1b0 ThreadListEntry : _LIST_ENTRY [ 0x8a8b1bd0 - 0x8a8b2660 ]
      +0x000 Flink            : 0x8a8b1bd0 _LIST_ENTRY [ 0x8a8b1958 - 0x8a8b1e48 ]
      +0x004 Blink            : 0x8a8b2660 _LIST_ENTRY [ 0x8a8b1e48 - 0x8a8b2880 ]
   +0x1b8 FreezeCount      : 0 ''
   +0x1b9 SuspendCount     : 0 ''
   +0x1ba IdealProcessor   : 0x1 ''
   +0x1bb DisableBoost     : 0 ''
GetContextState failed, 0x80004001
Стека в памяти нету, State 5 - это WAIT
Можно даже посмотреть на чем оно ждет:

dt _DISPATCHER_HEADER 0x80564820

ntdll!_DISPATCHER_HEADER

   +0x000 Type             : 0x4 ''

   +0x001 Absolute         : 0 ''

   +0x002 Size             : 0xa ''

   +0x003 Inserted         : 0 ''

   +0x004 SignalState      : 0

   +0x008 WaitListHead     : _LIST_ENTRY [ 0x8a8b1d08 - 0x8a8b15a0 ]

4 - это Queue
Приехали

Offtopic: нашлась полезная дока по курсу на основе WRK. Universities of China, канешна же

вторник, 27 декабря 2011 г.

scheduling on xp - wtf ?

а вот например я сегодня написал код, проходящий по всяким глубоко внутренним структурам планировщика. Например на моей тестовой xp 32bit показывает примерно такое:

понедельник, 26 декабря 2011 г.

компутерная археология

завел давеча под VBox windows 2000 без sp с целью всяких бесчеловечных опытов над wincheck

Хер найдешь нынче дистрибутив w2k в этих ваших инторнетах - только набор service packs нашел. На msdn w2k давно выпилили. Пришлось лезть на антресоли - нашел дистрибутив где-то на копии msdn апреля 2000. cdr болванка как ни странно до сих пор читается, да, хотя мой бывший препод по сопромату мамой клялся что дольше 10 лет они не проживут

Пребываю в задумчивости

воскресенье, 25 декабря 2011 г.

scheduler structures on windows 64bit

а вот например как всем давно известно (c) под 64битными версиями windows все структуры планировщика теперь расположены в KPRCB. Соотв-но определение subj мистическим образом сводится все к той же задаче определения версии KPRCB
Нужны же нам смещения следующих полей:

список WaitListHead
ReadySummary
массив LIST_ENTRY DispatcherReadyListHead
список DeferredReadyListHead

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

DeferredReadyListHead

Обращение к этому полю встречается примерно в 24 функциях, среди которых есть и немало экспортируемых. На мой вкус проще всего посмотреть начало KeAlertThread:

  mov     rbx, gs:20h

  xor     esi, esi

  lea     r13d, [rax-1]

  lock bts qword ptr [rdi+40h], 0

  jb      loc_140034F29

  mov     r8b, r14b

  mov     rdx, rdi

  mov     rcx, rbx

  call    KiAlertThread

  mov     qword ptr [rdi+40h], 0

  cmp     qword ptr [rbx+2C88h], 0 ;

KPRCB.DeferredReadyListHead



  mov     r15b, al

  jnz     short loc_140034E7B

Если поле DeferredReadyListHead содержит не NULL, то ниже по коду вызывается KiProcessThreadWaitList, из которой можно узнать еще и смещение KTHREAD.WaitListEntry:
     mov     r15, [rcx+2C88h] ; KPRCB.DeferredReadyListHead
     and     qword ptr [rcx+2C88h], 0 ; KPRCB.DeferredReadyListHead = NULL
     mov     r12d, r8d
     mov     r13, rcx
     lea     rsi, [r15-0D8h] ; offsetof(KTHREAD.WaitListEntry)

ReadySummary

Проще всего ищется в начале функции NtYieldExecution:

  sub     rsp, 20h

  mov     eax, gs:5218h   ; KPRCB.ReadySummary

  test    eax, eax

  jnz     short loc_14004A9EE

Поскольку в данном случае чтение идет не из KPRCB, то нужно вычесть размер KPCR

пятница, 23 декабря 2011 г.

СНАСХ

по результатам общения с Восторженными Поклонниками™ придумался термин - Совершенно Недетектируемая Абсолютно Секретная Хуйня. Полный аналог НЁХ, придает малограмотным пересыпанным матом сообщениям Воображаемых Авторов over9000 Многозначительности, бгг
За пределами мокрых фантазий Автора (в лучшем случае 486ой его бабушки) в диком виде не встречается

четверг, 22 декабря 2011 г.

wincheck rc8.4

download mirror
Changelog:

can dump all callback nodes from FltMgr (-fm option). Unlike fltkd.dll this code really works on xp/w2k3
add options -dsdt & -dssdt to dump SSDT & Shadow SSDT

llvm 3.0 vs w2k

и эти тоже:

On Win32(MinGW32 and MSVC), Windows 2000 will not be supported. Windows XP or higher is required

Вот уроды (c)

fltmgr callback nodes

microsoft все же никак не может удержаться от использования недокументированных вещей. Вот например в wdk в файле fltKernel.h объявлены всякие внутренние MJ_XXX до -6 и начиная с -13. Промежуток в -7..-12 не описан никак, в том числе и в ф-ции fltmgr!FltGetIrpName имена для них возвращаются как IRP_MJ_RESERVED-YY
И тем не менее:

  IRP_MJ_FAST_IO_CHECK_IF_POSSIBLE: FFFFFA800E0D4320

   PreOperation:            FFFFF880026D8414 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-12: FFFFFA800E0D4350

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-11: FFFFFA800E0D4380

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-10: FFFFFA800E0D43B0

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-9: FFFFFA800E0D43E0

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-8: FFFFFA800E0D4410

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RESERVED-7: FFFFFA800E0D4440

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000 

  IRP_MJ_RELEASE_FOR_CC_FLUSH: FFFFFA800E0D4470

   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys

   PostOperation:           0000000000000000

Как туда попали, ~~чем питаются~~ что делают - неизвестно (c)

вторник, 20 декабря 2011 г.

win32k!aatomSysLoaded 64bit

а вот например механизм поиска subj под 32битными windows давно известен
Под 64бита же на первый взгляд все выглядит намного грустнее - на aatomSysLoaded всего три ссылки вида lea и они крайне неудобны для поиска.
Однако если запустить мой замечательный IDA plugin, то ссылок на aatomSysLoaded становится уже целых пять штук ! И среди них есть например вот такой кусок кода в ф-ции xxxLoadHmodIndex:



                   lea     r14, cs:0FFFFF97FFF000000h

                   lea     rdx, [rsp+498h+SourceString]

41 B8 04 01 00 00  mov     r8d, 104h

41 0F B7 8C 76 40  movzx   ecx, word ptr [r14+rsi*2+2DA440h] ; 0FFFFF97FFF2DA440h

                   call    UserGetAtomName

FFFFF97FFF2DA440 - это например и есть нужный адрес. В rd8 загружается 3ий аргумент для вызова UserGetAtomName, а в rcx - атом из нужной нам таблички. Соотв-но поиск упрощается до сигнатуры
41 B8 04 01 00 00 41 0F B7 YY ZZ XX XX XX XX
Здесь байты XX дадут нам смещение на aatomSysLoaded от начала модуля win32k.sys. Легко можно убедиться что такая сигнатура является уникальной для всего модуля как под windows 7, так и под все версии vista

Точно так же можно найти subj под 64битными w2k3/xp - только сигнатура будет другой. Какой именно - оставляю вам в качестве домашнего задания, бгг

понедельник, 19 декабря 2011 г.

wincheck rc8.3

download mirror
Changelog:

add -kt option to dump all KTIMERs. Works on 32 & 64bit windows
add checking of FS_FILTER_CALLBACKS
add checking of callbacks which can be installed with ExRegisterAttributeInformationCallback function
add checking of KPRCB.WorkerRoutine (32bit only)

воскресенье, 18 декабря 2011 г.

make_pdmp.pl

по многочисленным просьбам - запчасть от моей системы тестирования, которая ездит по директориям, качает .pdb и делает .pdmp файлы
Модуль PEIdent я в силу врожденной паранойи выкусил - нечего вам знать какие файлы оно у меня знает, бгг
Батник get_pdb.bat идентичен приведенному ранее

про тестирование

а вот например меня тут давеча спросили - поскольку wincheck для извлечения смещений структур и адресов всякого использует статический анализ кода, то как происходит проверка стат. анализатора на куче версий windows ? Это хороший вопрос тащемта, тем более что ничего внятного про такую задачу в этих ваших интернетах по моему не написано и пришлось как обычно все делать на коленке самому.
Правильный ответ - Максимальная Автоматизация всего процесса с помощью адовой смеси perl/bat скриптов

Получаем pdb

Как известно microsoft в отличие от практически всех остальных софтоклепательных компаний предоставляет .pdb файлы от почти всех своих системных модулей. Было бы глупо не воспользоваться такой шикарной возможностью при создании эталонных данных для тестов. Соотв-но обработка любого файла начинается с получения его .pdb файла и последующего дампа этого .pdb с помощью пропатченной мною версии pdbdump

Cуществует множество способов получить .pdb. На мой вкус самый простой - использовать программу symchk.exe из Debugging Tools for Windows:

"C:\Program Files\Debugging Tools for Windows (x86)\symchk.exe" %1  /s SRV*%tmp%\ida\*http://msdl.microsoft.com/download/symbols /v 2>log

В файле log интересна следующая строчка:

DbgSizeOfImage      0x0001d000

DbgChecksum         0x0001df9b

PdbFilename         C:\DOCUME~1\USER\LOCALS~1\Temp\ida\6to4svc.pdb\FD2DAD64D03E4365A5116D01DCB424031\6to4svc.pdb

PdbSignature {FD2DAD64-D03E-4365-A511-6D01DCB42403}

Простой perl script парзит данный log, и в случае успеха копирует скачанный .pdb файл рядом с исходным бинарным, после чего запускает pdbdump, перенаправляя его вывод в файл с именем исходного PE файла и расширением .pdmp

Формирование эталонных данных

Для проведения тестов нужны файлы с эталонными данными, которые мне лениво набивать для каждого файла вручную, поэтому они также генерятся полуавтоматически. Эти данные хранятся в файле с именем исходного PE файла и расширением .et. Файл .et выглядит примерно так (взято из 32/win7/nosp/ntkrnlpa.et):

KiDebugRoutine 1689BC

KdDebuggerDataBlock 128C08

M DbgkLkmd_cblist 12DB20

PspLegoNotifyRoutine 369EE0

EPROCESS.ObjectTable F4

Для получения .et файла нужно натравить на .pdmp файл perl script make_et.pl, который распарзит выход pdbdumpа и извлечет всякие нужные адреса и смещения нужных полей в нужных структурах и сохранит их . Этот скрипт крайне прост и практически не отличается от ранее публиковавшегося. Здесь есть один тонкий момент - некоторых имен в .pdb файле может не быть. Так например в pdb от ntkrnlpa.exe от windows 7 нет переменной DbgkLkmd_cblist - она должна быть добавлена вручную. Соотв-но скрипт сначала зачитывает из уже имеющегося файла .et все строчки с символом M в начале строки (флажок, означающий что данная строчка была добавлена вручную) и сохраняет их в новой версии .et файла. Так гарантируется что однажды вручную добавленные поля никогда не будут потеряны. Как вы можете догадаться, эта функциональность также была добавлена благодаря моей выдающейся лени например

Собственно тесты

Это самая скучная часть повествования. Из общей с wincheck кодовой базы была написана специальная программа с оригинальным именем test.exe, которая делает ровно то же что и анализатор в wincheck, только еще умеет распечатать результаты в stdout. Есс-но что программа имеет 32 и 64 битные версии. Далее запускается еще один perl script, который рекурсивно ездит с помощью модуля File::Find по директориям с тестовыми данными, находит все .et файлы, запускает test.exe для исходного PE файла и сравнивает получившиеся результаты с эталонными данными. Все не найденное или не совпавшее с эталонными данными пишется в лог.
Скрипт этот имеет два режима работы - проверить вообще все, либо (что бывает значительно чаще) совершенно конкретный модуль. Откуда он знает какой файл относится к какому модулю ? Ему говорит об этом отдельный perl package PEIdent, ф-ции в котором выглядят примерно так:



sub is_hal

{

  my $fname = lc(shift);

  return ($fname eq 'hal.dll')      ||

($fname eq 'halapic.dll') ||

          ($fname eq 'halmps.dll')   ||

         ($fname eq 'halacpi.dll')  ||

         ($fname eq 'halaacpi.dll') ||

         ($fname eq 'halmacpi.dll')

 ;

}

Думаю что основная идея из этого кусочка понятна. Далее можно формировать кортежи из двух указателей на ф-ции - is_XX & do_XX, вторая вызывается если первая вернула не ноль. Еще далее из этих кортежей можно составить список кортежей, по которому можно пройтись с именем .exe/.dll/.sys файла, найти его тип модуля, вызвать нужную ф-цию для обработки. В эти списки можно добавить кортежи только для отдельных типов модулей или для всех pe файлов и так далее

Добавление нового эталонного значения

Изредка возникает необходимость добавить еще одно (или не одно) поле в .et файлы для определенного модуля. Поскольку лень моя чудовищна - это делается с помощью все того же make_et.pl. К нему дописывается еще одна (или не одна) строчка - имя переменной, которую мы хотим получить из .pdmp или поле и структура. Этот скрипт точно так же обходит рекурсивно директорию с тестовыми данными и делает свое грязное дело по изменению .et файлов, генерируя при этом отчет - для какого файла что не нашлось. По моему это единственное место когда требуется ручное вмешательство с помощью анализа кода в IDA Pro

Добавление нового файла

Бывает также иногда необходимость добавить либо файлы с какой-либо версии windows, либо совершенно новый тип модуля. Если нужно добавить новый тип модуля для анализа - правится PEIdent и прочие использующие его скрипты. Затем просто запускаются два скрипта:

make_pdmp.pl - рекурсивно ездит по директориям с тестовыми данными, ищет файлы, у которых отсутствуют .pdb/.pdmp файлы, скачивает все недостающее и вызывает pdbdump, при этом пишется два лога - для тех файлов, скачать .pdb к которым не удалось, и для всех вновь добавленных. Я думал что можно было бы make приспособить для этого дела - но тогда пришлось бы руками в нем прописывать все добавленные файлы с полными путями. Ручной рекурсивный обход дерева каталогов оказался намного проще
все тот же make_et.pl для получения эталонных данных для вновь добавленных файлов

Как следует из описания если нужно просто добавить некоторое количество файлов (например давеча я добавил файлы от 32битной w2k3 sp1) - их нужно просто скопировать в нужную директорию и запустить простой .bat файл

Организация каталогов

Чтобы не потеряться в куче файлов - .exe/.dll/.sys, а также соотв-щих им .pdb/.pdmp/.et (размер этого добра сейчас составляет что-то около 6Gb) - нужна правильная организация каталогов. Директорий с тестовыми данными две - одна для 32бит, другая для 64 (и на самом деле эти директории могут лежать на разных машинах). В каждой директории есть папки с именем версии windows, откуда был взят набор файлов, примерно такие:
32/w2k/sp4
32/xp/sp1
32/xp/sp2
32/xp.64/sp1
и так далее

В каждой папке лежит весь наборчик файлов данной битности от данной версии windows. Благодаря тому что любой скрипт для манипуляции с файлами ездит по директориям рекурсивно - всегда можно задать директорию, в которой нужно отработать - например тестировать только xp версии, скачать pdb от 32/w2k3/sp1 etc etc

Должен заметить что подобная организация тестов ~~значительно ЗНАЧИТЕЛЬНО~~ МЕГАЗНАЧИТЕЛЬНО экономит время тестирования/поиска багов/добавления новых переменных/новых типов модулей/новых версий windows

суббота, 17 декабря 2011 г.

KTIMERs with DPC per processor

а вот например как всем давно известно (c) начиная с windows 7 KTIMERs хранятся в KPRCB per processor (в поле KPRCB.TimerTable). Соотв-но я сегодня отладил таки код, вытаскивающий все KTIMERs для всех камней и вот что получилось на моей восьмиголовой windows 7 64bit:

AffinityMask

а вот например windows7 (и соотв-но w2008r2) могут поддерживать более 64 камней
А как известно ф-ция SetThreadAffinityMask в качестве маски имеет аргумент типа DWORD_PTR, что позволяет задать маску ровно для 64 камней. Если же на машине больше - то предлагают использовать всякие ритуальные пляски с бубном типа SetThreadIdealProcessorEx и заданием т.н. processor group.
Предположим (потому что у меня банально нету такого железа) что мы запущены на машине, где больше 64 камней. Количество камней я как-нть из kernel-mode узнать могу (KeNumberProcessors например). Соотв-но дальше я хочу свой поток подключить к каждому имеющемуся камню и достать всякое из KPRCB например. Ясно что я должен использовать кроме subj еще и processor group. А вот дальше непонятно - а сколько таких групп в системе ? А сколько в каждой камней (а системы бывают например на 96 камней - не кратные 64) ? А как можно провернуть такой трюк в kernel mode ?
Кто-нть имел подобный опыт ?

Update: вдумчивое разглядывание msdn подсказывает, что нужные ф-ции называются примерно так:

Наверняка все реализовано через какие-нть плохо документированные Information Classes NtQuerySystemInformation

вторник, 13 декабря 2011 г.

определение версии KPRCB 2

я тут писал уже как-то про сие невинное занятие, но внезапно выяснилось что метод не работает например под windows 8 - под ней KeIsExecutingDpc выглядит так:

  mov     eax, large fs:2354h

  and     eax, 10001h

  retn

это дает нам смещение на DpcRoutineActive равным 0x2234, что неверно

Но есть и еще один способ - например можно узнать смещение поля WorkerRoutine. В экспортируемой ф-ции KiIpiServiceRoutine есть примерно такой кусочек кода:

  mov     eax, [edx+2170h]

  mov     edx, [esp+24h+arg_0]

  mov     [esi+2128h], edx

  call    eax

0x2170 - это и есть наше искомое смещение. К недостаткам метода относится его применимость только для 32 бит, потому что под 64битными системами ф-ция KiIpiServiceRoutine не экспортируется
Также работает он только начиная с xp - под w2k ф-ция KiIpiServiceRoutine пуста

илита вирмейкинга недовольна

wincheckом:

Например есть у нас детектор типо wincheck. Вроде кошерная поделка, анализирует стопяцот внутренних структур, как юзермодных, так и нейтивных. Но это аверское дерьмо выпиливается через маршрутизацию. Что толку от мониторинга LdrpDllNotificationList, если я юзаю ShowSnaps и S/W переключение на код

это успех (c) ящетаю. Особенно угарно что wincheck на всю катушку использует анализ графа codeflow - не GPE™ понятно, а более пригодную для использования самописную либу, но идея таки да, ровно та же самая, бгг

суббота, 10 декабря 2011 г.

w8 NDIS structs 64bit

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

пятница, 9 декабря 2011 г.

wincheck rc8.2

download mirror
Changelog:

add dumping of handlers from LdrpDllNotificationList. Example output looks like:
LdrpDllNotificationList: 1 6CE16512 C:\Program Files\Internet Explorer\IEShims.dll
add dumping of callbacks which can be installed with DbgkLkmdRegisterCallback
add checking of functions imported from imm32.dll inside user32.dll

среда, 7 декабря 2011 г.

IDA 5.60 PICode analyzer plugin for win64

а вот например под 64битной windows есть собственный вариант position-independent code, который выглядит приблизительно так (примерчик выдран из win32k.sys):

   lea     rax, cs:0FFFFF97FFF000000h

   mov     edx, r11d

   call    qword ptr [rax+r10*8+2C59A0h] ; 0FFFFF97FFF2C59A0h

здесь адрес FFFFF97FFF000000h указывает на самое начало PE модуля, т.е. в оригинале данная инструкция скорее всего выглядела как (использован синтаксис yasm):
lea rax, qword [ImageBase wrt rip]

IDA Pro например такой код не распознает и соотв-но не показывает ни адресов, ни cross-refs, что представляет собой некоторую проблему при анализе всякого. Поскольку perl под ida64 я так и не удосужился завести, а IDC считаю адовой упячкой (практически такой же как писон), пришлось вспомнить молодость и написать очередной native plugin таки на C++

Собственно алгоритм работы прост - проходимся по всем секциям, содержащим исполнимый код, ищем загрузку в некий регистр адреса начала PE модуля, и далее ищем в некотором количестве нижеследующих инструкций те, что используют этот регистр как base register или как index register с нулевым SIB scale. Для найденных проставляем cross ref и новый вычисленный адрес в комментарии. Все происходит за один проход, поэтому работает относительно быстро (на файле размером 3.8Mb порядка 40 секунд на моей рабочей машине)

Поскольку старые ~~добрые~~ надежные компиляторы с IDA Pro 5.60 работать перестали, собирается все богатство на vs2008

вторник, 6 декабря 2011 г.

ida 560 sdk vs bcc 5.5

а вот например после некоторого перерыва решил пересобрать один plugin под subj на Borland C++ 5.5 for Win32. Сделал все как в install_make.txt описано - пофиксал всякое в allmake.mak и запустил make - разнообразные .cfg создались и на первый взгляд даже правильные вроде. Запускаю конпеляцию и получаю:



Error E2326 c:\ida560\sdk\include\pro.h 445: Use __declspec(spec1[, spec2]) to combine multiple __declspec's

Error E2141 c:\ida560\sdk\include\pro.h 445: Declaration syntax error

Error E2268 c:\ida560\sdk\include\pro.h 450: Call to undefined function 'vinterr' in function cdecl interr(const char *,int,cont char *,...)

Error E2326 c:\ida560\sdk\include\pro.h 749: Use __declspec(spec1[, spec2]) to combine multiple __declspec's

Error E2141 c:\ida560\sdk\include\pro.h 749: Declaration syntax error

wtf ? в readme.txt английским по синему написано:

To create 32bit or 64bit Win32 modules: Borland C++ Builder >= 5.0
or free BCC v5.5

вот у меня как раз он и есть - free BCC v5.5. И не собирается нифига

Update: на старом добром Visual C++ 6.0 тоже больше не собирается ничего - выдало простыню из 135 ошибок на какие-то templates типа вот такого:

c:\ida560\sdk\include\pro.h(1830) : warning C4003: not enough actual parameters for macro 'DEFINE_LIST_ITERATOR'

c:\ida560\sdk\include\pro.h(1830) : error C2143: syntax error : missing ')' before ';'

        c:\ida560\sdk\include\pro.h(1966) : see reference to class template instantiation 'qlist' being compiled

Придется окончательно перелезть на vs2008

воскресенье, 4 декабря 2011 г.

Анальный туннель реальности

детский юмористический журнал ксакеп снова отжигает

Перехват ключевых функций в структуре NDIS_MINIPORT_BLOCK может гарантировать твоей зверюшке уверенный контроль или модификацию сетевого трафика, если бы не одно "но" — заполучить указатель на NDIS_MINIPORT_BLOCK ой как непросто

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

суббота, 3 декабря 2011 г.

Boost

а вот например нам тут давеча разъяснили что полная поддержка языка в компиляторе вовсе и не нужна. Речь шла про c++11 есличо
а вот если подсчитать количество использований костыля BOOST_WORKAROUND в boost (например версии 1.47), то получим 540 файлов. Для языка, которому уже 28 лет. Наверняка потому что авторы отдельных компиляторов тоже полной поддержкой себя не утруждали

Думаю для c++11 и через 28 лет ситуация будет ничуть не лучше чем сейчас для "обычного" c++. А прямо сегодня его могут позволить себе использовать только ~~конченные психи~~ крайне безответственные граждане, бгг

wincheck rc8.1

Download mirror
Changelog:

New -st option to check System Threads. Print ETHREAD, ETHREAD.StartAddress, Y if this thread is worker thread, KTHREAD.InitialStack and KTHREAD.StackLimit. Example output for my xp 32bit machine looks like:Thread 867C5020 Start 80683528 N stack F79FC000 limit F79F9000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C5BD8 Start 80533CD0 Y stack F7A08000 limit F7A05000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C5960 Start 80533CD0 Y stack F7A0C000 limit F7A09000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C56E8 Start 80533CD0 Y stack F7A10000 limit F7A0D000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C5470 Start 80533CD0 Y stack F7A14000 limit F7A11000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C4020 Start 80533CD0 Y stack F7A18000 limit F7A15000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C4DA8 Start 80533CD0 Y stack F7A1C000 limit F7A19000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C4B30 Start 80533CD0 Y stack F7A20000 limit F7A1D000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C48B8 Start 80533CD0 Y stack F7A24000 limit F7A21000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C4640 Start 80533CD0 Y stack F7A28000 limit F7A25000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C43C8 Start 80533CD0 Y stack F7A2C000 limit F7A29000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C3020 Start 80533CD0 Y stack F7A30000 limit F7A2D000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C3DA8 Start 80533CD0 Y stack F7A34000 limit F7A31000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C3B30 Start 80533CD0 Y stack F7A38000 limit F7A35000 \WINDOWS\system32\ntkrnlpa.exe Thread 867C38B8 Start 806091A8 N stack F7A3C000 limit F7A39000 \WINDOWS\system32\ntkrnlpa.exe Thread 867BF020 Start 80508898 N stack F7A40000 limit F7A3D000 \WINDOWS\system32\ntkrnlpa.exe Thread 867BFDA8 Start 8064226E N stack F7A44000 limit F7A41000 \WINDOWS\system32\ntkrnlpa.exe Thread 867BFB30 Start 8053B3E8 N stack F7A48000 limit F7A45000 \WINDOWS\system32\ntkrnlpa.exe Thread 867BF8B8 Start 8053B6DE N stack F7A4C000 limit F7A49000 \WINDOWS\system32\ntkrnlpa.exe Thread 867EAA20 Start 804EC6E8 N stack F7A50000 limit F7A4D000 \WINDOWS\system32\ntkrnlpa.exe Thread 867EA7A8 Start 804EC6E8 N stack F7A54000 limit F7A51000 \WINDOWS\system32\ntkrnlpa.exe Thread 867A5BC8 Start 8050AC2A N stack F7A58000 limit F7A55000 \WINDOWS\system32\ntkrnlpa.exe Thread 867A5530 Start F74BDB10 N stack F7A5C000 limit F7A59000 ACPI.sys Thread 867325C0 Start F739C91E N stack F7A64000 limit F7A61000 dmio.sys Thread 86740DA8 Start F72DBB40 N stack F7A68000 limit F7A65000 PGPwded.sys Thread 8672E9E0 Start F72DBB40 N stack F7A6C000 limit F7A69000 PGPwded.sys Thread 86717A40 Start F720DB85 N stack F7A70000 limit F7A6D000 NDIS.sys Thread 865BB458 Start F77D1F90 N stack F7A90000 limit F7A8D000 \SystemRoot\system32\DRIVERS\redbook.sys Thread 86482DA8 Start F5F8381A N stack F7AA4000 limit F7AA1000 \SystemRoot\system32\DRIVERS\rdpdr.sys Thread 86482B30 Start F5F8381A N stack F7AA8000 limit F7AA5000 \SystemRoot\system32\DRIVERS\rdpdr.sys Thread 864828B8 Start F5F8381A N stack F7AAC000 limit F7AA9000 \SystemRoot\system32\DRIVERS\rdpdr.sys Thread 86482640 Start F5F6CCFA N stack F7AB0000 limit F7AAD000 \SystemRoot\system32\DRIVERS\rdpdr.sys Thread 863DE7D8 Start F781C92D N stack F7AC8000 limit F7AC5000 \SystemRoot\system32\DRIVERS\raspptp.sys Thread 863E9020 Start F781D103 N stack F7AC4000 limit F7AC1000 \SystemRoot\system32\DRIVERS\raspptp.sys Thread 86143598 Start F64B9E96 N stack F7166000 limit F7163000 \SystemRoot\system32\DRIVERS\USBPORT.SYS Thread 86395020 Start F64B9E96 N stack F716E000 limit F716B000 \SystemRoot\system32\DRIVERS\USBPORT.SYS Thread 86371B18 Start F64B9E96 N stack F7172000 limit F716F000 \SystemRoot\system32\DRIVERS\USBPORT.SYS Thread 85CC16F0 Start F60156D0 N stack F1D37000 limit F1D34000 \SystemRoot\system32\DRIVERS\parport.sys Thread 862B1AC0 Start F1D2C038 N stack F1D2B000 limit F1D28000 \SystemRoot\system32\DRIVERS\rasacd.sys Thread 85C636F0 Start F72DBB40 N stack F1D23000 limit F1D20000 PGPwded.sys Thread 86310B70 Start EEF75A99 N stack F1D1F000 limit F1D1C000 \SystemRoot\system32\DRIVERS\rdbss.sys Thread 85C366F0 Start EEF75A99 N stack F1D13000 limit F1D10000 \SystemRoot\system32\DRIVERS\rdbss.sys Thread 85C356F0 Start EEF5D8AF N stack F177D000 limit F177A000 \SystemRoot\system32\DRIVERS\rdbss.sys Thread 86616A78 Start 805EE5B8 N stack F7AC0000 limit F7ABD000 \WINDOWS\system32\ntkrnlpa.exe Thread 862A4308 Start EEF679C1 N stack EE2D0000 limit EE2CD000 \SystemRoot\system32\DRIVERS\rdbss.sys Thread 863B7DA8 Start F733D2A6 N stack F5EEA000 limit F5EE7000 PGPfsfd.sys Thread 862D8DA8 Start EB1AC7D8 N stack EF223000 limit EF220000 \SystemRoot\system32\DRIVERS\mrxdav.sys Thread 86600598 Start EB1AC7D8 N stack F0A1B000 limit F0A18000 \SystemRoot\system32\DRIVERS\mrxdav.sys Thread 86312580 Start EB1AC7D8 N stack EB320000 limit EB31D000 \SystemRoot\system32\DRIVERS\mrxdav.sys Thread 862F7B38 Start EB18E82C N stack EB300000 limit EB2FD000 \SystemRoot\system32\DRIVERS\mrxdav.sys Thread 8636F220 Start EB18BD18 N stack F5EFA000 limit F5EF7000 \SystemRoot\system32\DRIVERS\mrxdav.sys Thread 865FDDA8 Start F5195A48 N stack F5F06000 limit F5F03000 \??\C:\WINDOWS\system32\drivers\hcmon.sys Thread 85E03798 Start EB260B32 N stack EB16F000 limit EB16C000 \SystemRoot\system32\DRIVERS\srv.sys Thread 85E51798 Start EB260B32 N stack EB177000 limit EB174000 \SystemRoot\system32\DRIVERS\srv.sys Thread 861EC718 Start EBA847B6 N stack EBB1B000 limit EBB18000 \SystemRoot\System32\Drivers\HTTP.sys Thread 861BA8E8 Start EBA847B6 N stack EBAE7000 limit EBAE4000 \SystemRoot\System32\Drivers\HTTP.sys Thread 861BA670 Start EBA847B6 N stack EBCB7000 limit EBCB4000 \SystemRoot\System32\Drivers\HTTP.sys Thread 862409E0 Start EBA847B6 N stack EBCBB000 limit EBCB8000 \SystemRoot\System32\Drivers\HTTP.sys Thread 861F9A98 Start EBA81DDA N stack EBCA7000 limit EBCA4000 \SystemRoot\System32\Drivers\HTTP.sys
This new option is supported on both 32 and 64 bit platforms. It does not work on w2k only bcs of strange global processes locking policy on this ancient windows
From Unknown Executable Memory (-uem option) are excluded ranges used by PEB.ApiSetMap and PEB.ReadOnlySharedMemoryBase (windows 7 & 8)
Fixed some misprints in output

пятница, 30 декабря 2011 г.

четверг, 29 декабря 2011 г.

вторник, 27 декабря 2011 г.

понедельник, 26 декабря 2011 г.

воскресенье, 25 декабря 2011 г.

DeferredReadyListHead

ReadySummary

пятница, 23 декабря 2011 г.

четверг, 22 декабря 2011 г.

вторник, 20 декабря 2011 г.

понедельник, 19 декабря 2011 г.

воскресенье, 18 декабря 2011 г.

Получаем pdb

Формирование эталонных данных

Собственно тесты

Добавление нового эталонного значения

Добавление нового файла

Организация каталогов

суббота, 17 декабря 2011 г.

вторник, 13 декабря 2011 г.

суббота, 10 декабря 2011 г.

пятница, 9 декабря 2011 г.

среда, 7 декабря 2011 г.

вторник, 6 декабря 2011 г.

воскресенье, 4 декабря 2011 г.

суббота, 3 декабря 2011 г.

пятница, 30 декабря 2011 г.

четверг, 29 декабря 2011 г.

вторник, 27 декабря 2011 г.

понедельник, 26 декабря 2011 г.

воскресенье, 25 декабря 2011 г.

пятница, 23 декабря 2011 г.

четверг, 22 декабря 2011 г.

вторник, 20 декабря 2011 г.

понедельник, 19 декабря 2011 г.

воскресенье, 18 декабря 2011 г.

суббота, 17 декабря 2011 г.

вторник, 13 декабря 2011 г.

суббота, 10 декабря 2011 г.

пятница, 9 декабря 2011 г.

среда, 7 декабря 2011 г.

вторник, 6 декабря 2011 г.

воскресенье, 4 декабря 2011 г.

суббота, 3 декабря 2011 г.