перевод с касперского

читая выл от вострога ! там прекрасно решительно все

В общем, мы тут напряглись, посчитали и обалдели. В результате появился апдейт: 70 тысяч

а почему не 100500 миллионов ? доказательств все равно нет никаких

у нас уже год не меняется количество сотрудников в вирлабе

кризис посетил внезапно и найм заморожен ?

У нас уже много лет как на боевом дежурстве … авто-дятлы! Человеческому фактору достаётся только самая интеллектуальная работа – разбирать самые сложные образцы, исследовать ботнеты, следить, чтобы авто-дятлы не фолсили

ололо, автодятел виноват в необнаружении stuxnetа, ога

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

а мы типа не при делах - 30 миллионов мух хомячков в нашем облаке не могут ошибаться - у твоего файла реальне плохая репутация. Кто сразу вспомнил про цензуру ?

C другой стороны какие богатые возможности к накрутке репутации открываются - читайте в ближайших выпусках сми - ботнет KSN большинством голосов забанил KIS 2012 как fake av, бгг

concurrent_queue::clear bug

все неделю проебвозился с одной крайне муторной багой
Есть например некий объект, использующий concurrent_queue из номоводного Concurrency от vs2010. В деструкторе зовется как положено метод clear. И падает иногда. Очень хитро падает, тварь - только на smp машинах с xp. Под другими (проверялось на w7 & ws2008r2) не падает
Оказалось что subj глючен:

char _Buf[sizeof(_Ty)]; // <-- тут создаем неинициализированный буфер
if (!_Internal_pop_if_present(reinterpret_cast<_Ty*>(_Buf)))

virtual void _Assign_and_destroy_item( void* _Dst, _Page& _Src, size_t _Index )
{
_Ty& _From = _Get_ref(_Src,_Index);
_Destroyer _D(_From);
*static_cast<_Ty*>(_Dst) = _From; // а тут присваиваем неинициализированному объекту по адресу _Buf. Соотв-но оператор = тошнит
}

лучше всего использовать простой но рабочий код вроде
while(queue.try_pop(dst)){}

Ненависть, ненависть, ненависть

bundestrojaner

если кто не читал например:

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

Разработчики антивирусных программ F-Secure и Sophos заявили, что обновляют базы и добавляют защиту от "бундестрояна". Ожидается, что и другие компании последуют их примеру

Надо полагать Спасатели Вселенной™ не добавят, ибо социально близкие, бгг

RegisterApplicationRecoveryCallback

А вот например начиная с висты появилась такая местами документированная ф-ция
Сохраняет она все что нужно в поле PEB.WerRegistrationData, тип и назначение которого нигде не описано. Но когда это кого останавливало, бгг ?
Краткий просмотр ф-ции WerpRegisterRecovery говорит нам, что поле это присваивается в ф-ции WerpInitPEBStore примерно таким кодом:

  push    4               ; flProtect
  push    3000h           ; flAllocationType
  push    8D0h            ; dwSize
  push    edi             ; lpAddress
  call    ds:__imp__VirtualAlloc@16 ; VirtualAlloc(x,x,x,x)
  mov     [esi+230h], eax ; PEB.WerRegistrationData


размер структуры чуть ниже кладется в ее первый dword:

  mov     dword ptr [eax], 8D0h
Размер зависит от версии windows - под vista (на всех sp) он равен 0x10c8 байт, на w7 & w8 0x8d0 байт
Вся структура впрочем не нужна - интересен только следующий кусочек:

  push    [ebp+pRecoveryCallback]
  call    ds:__imp__RtlEncodeSystemPointer@4 ; RtlEncodeSystemPointer(x)
  mov     [edi+830h], eax

Смещение, по которому хранится закодированный указатель на pRecoveryCallback на разных версиях windows также разное - на vista 0x1030, на w7 & w8 0x830

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

мне тут давеча пришлось сопрягать свою замечательную прогу, написанную на устаревшем (как мне было замечено, бгг) visual c++ 2008 с внешней .dll, написанной на новомодной visual c++ 2010
Оно не сопрягается наглухо и вообще MS кажется полностью забили на обратную совместимость своих компиляторов. Например у них теперь std::string бинарно различаются в разных версиях. Что характерно names mangling при этом не поменялся и оно спокойно себе линкуется, только падает потом во всяких непредсказуемых местах. Коммерческий продукт, ага, хуже gcc.
API design for C++, угу-угу
Ненависть, ненависть, ненависть

кризис к ним приходит

кризиса вкус всегда настоящий
По моему они конкретно охуели code search все. Где же я теперь буду искать всякое полезное ?

wincheck rc5

скачать
Изменения делятся на две группы
Лучшая поддержка windows8

• опция -ndis работает. По крайней мере в синяк не падает, бгг. Показывает всякий треш для FilterBlocks - я не буду доделывать пока хотя бы rc windows8 не выйдет
• shim handlers показываются
• windows8 specific RPC интерфейсы опознаются вроде бы все

Поддержка структур LSA
и прочих всяких мест, где теоретически можно поставить перехват и потырить ваши шестисимвольные пароли от порнухи, бгг

• проверяются всякие таблицы ф-ций в ksecdd.sys. Не все есс-но - только те которые я смог достать
• обработчики, поставленные с помощью LsaIRegisterPolicyChangeNotificationCallback
•  всякие таблицы ф-ций, возвращаемые LSA Security Providers. С немалым удивлением обнаружил, что они почти все живут в секции данных и соотв-но их перехват не детектит никто например, бгг

Традиционно были добавлены пофикшены некоторые баги

w8 DelayLoadFailureHookImplementation

а вот например я тут писал уже давеча про эту чудесную ф-цию
Намедни выяснилось что в windows 8 она живет в kernel32.dll и теоретически может вызываться из практически любого процесса
Под катом ужас и моральный террор (413 модулей !)

LsaIRegisterPolicyChangeNotificationCallback

а вот например в lsasrv.dll есть такая традиционно недокументированная ф-ция, которая умеет регистрировать указатель на ф-цию. Соотв-но было бы весьма неплохо посмотреть чего там зарегистрировано всякими разными
Например из дизасма очевидно что для хранения callbacks используется массив LsaPolicyChangeNotificationList, который состоит из 8 (под w7 & w8 - 9) структур

struct PolicyChangeNotification
{
  struct _LIST_ENTRY List;
  ULONG Count;
};
List соотв-но хранит уже непосредственно структуры, описывающие callback - примерно такие:

struct PolicyChangeNotification_item
{
/* Win32 Win64 */
/*  0x0  0x0  */  struct _LIST_ENTRY ListLink;
/*  0x8  0x10 */  PBYTE  function_cb;
/*  0xC  0x18 */  PBYTE  unk1;
/* 0x10  0x20 */  PBYTE  unk2;
/* 0x14  0x28 */  PBYTE  unk3;
};
По моему навигация по этим структурам представляет собой тривиальную задачу, так же как их нахождение
Результаты на моей рабочей машине например

ыыыы

Для лечения вируса были использованы инструкции по удалению вредоносного ПО с сайта Лаборатории Касперского, однако, это не помогло

отсюда. хабр, бывает, доставляет иногда
Есть мнение что Е.В. вкладывает немалые бабки не туда, иначе такого антипиара просто не могло бы случитца. Ничего, Люди поправят направление денежных потоков, бгг

внезапно

в продаже с 22 декабря


В пятом издании было 1232 страницы
в этом 1344
интересно там есть список глав, которые были полностью copy & pasted из предыдущего издания ? Вот почему бы им например не выпускать патчи к предыдущим изданиям ?

w8 kernel mode RPC

я тут писал уже как-то про msrpc например
А теперь дискотека список драйверов от windows 8 и используемые ими RPC interfaces

afd.sys - использует 30ADC50C-5CBC-46CE-9A0E-91914789E23C
appid.sys - использует 8A7B5006-CC13-11DB-9705-005056C00008
dfsc.sys - использует 7F1343FE-50A9-4927-A778-0C5859517BAC
FWPKCLNT.SYS - использует 2 интерфейса:

1. IkeRpcIKE A398E520-D59A-4BDD-AA7A-3C1E0303A511
2. BfeRpcBFE DD490425-5325-4565-B774-7E27D6C09C24

ksecdd.sys - использует 4F32ADC8-6052-4A04-8701-293CCF2096F0
mrxsmb.sys - использует F2C9B409-C1C9-4100-8639-D8AB1486694A
netio.sys - использует 2 интерфейса:

1. WinNsi 7EA70BCF-48AF-4F6A-8968-6A440754D5FA
2. BiSrvSigna C605F9FB-F0A3-4E2A-A073-73560F8D9E3E

ntfs.sys - использует 04EEB297-CBF4-466B-8A2A-BFD6A2F10BBA
srvnet.sys - использует 3 интерфейса:

1. XactSrvRPC 98716D03-89AC-44C7-BB8C-285824E51C4A
2. IdSegSrv 1A0D010F-1C33-432C-B0F5-8CF4E8053099
3. и один неопознанный 9D5F40FF-F1C2-4394-8671-9E56427FCD70. Используется впрочем единственный метод NotifyGroveler

tunnel.sys - использует 6F201A55-A24D-495F-AAC9-2F4FCE34DF99

srvsvc.dll RPC interfaces

Server Service DLL

Например под windows 8 интерфейс srvsvc имеет версию 3.0 и 0x45 методов
Добавленные методы:
0x3A: LocalrSessionEnum
0x3B: LocalrSessionGetInfo
0x3C: LocalrSessionDel
0x3D: LocalrFileEnum
0x3E: LocalrFileGetInfo
0x3F: LocalrFileClose
0x40: LocalrShareEnum
0x41: LocalrShareGetInfo
0x42: LocalrShareSetInfo
0x43: LocalrShareAdd
0x44: LocalrShareDelEx


XactSrv 98716D03-89AC-44C7-BB8C-285824E51C4A version 1.0
регистрируется в epmapper с аннотацией XactSrv service
6 methods:

• XsOpenPrinter
• XsClosePrinter
• XsAddJob
• XsScheduleJob
• XsProcessPnp
• XsProcDownLevelAPI

 вызывается через msrpc из драйвера srvnet.sys

IdSegSrv 1A0D010F-1C33-432C-B0F5-8CF4E8053099 version 1.0
регистрируется в epmapper с аннотацией IdSegSrv service
2 methods:

• IdSegRequestNextSequence
• IdSegRequestNodeInvalidation

 вызывается через msrpc из драйвера srvnet.sys

wkssvc.dll RPC interfaces

Workstation Service DLL
кроме всем известного wkssvc под windows 8 имеет следующие RPC интерфейсы:

F2C9B409-C1C9-4100-8639-D8AB1486694A version 1.0
регистрируется в epmapper с аннотацией Witness Client Upcall Server
2 methods:

• ClusterConnectUpcall
• ClusterDisConnectUpcall

вызывается через msrpc из драйвера mrxsmb.sys

EB081A0D-10EE-478A-A1DD-50995283E7A8 version 3.0
регистрируется в epmapper с аннотацией Witness Client Test Interface
1 method:

• GetWitnessNodes

7F1343FE-50A9-4927-A778-0C5859517BAC version 1.0
регистрируется в epmapper с аннотацией DfsDs service
4 methods:

• DfsDsGetDcName
• DfsDsIsDomainController
• DfsCredWrite
• DfsCredDelete

вызывается через msrpc из драйвера dfsc.sys

connhlp.dll RPC interface

Connectivity Helper API
cpprovider 6F201A55-A24D-495F-AAC9-2F4FCE34DF99 version 1.0
0xd methods:

• SpiEstablishSession
• SpiTerminateSession
• SpiTransitionFromDormantToActive
• SpiTransitionFromActiveToDormant
• SpiAddTransportId
• SpiRemoveTransportId
• SpiIsRemoteTransportIdReachable
• SpiSendData
• SpiReceiveData
• SpiReceiveAuthorizeCallback
• SpiReceiveAuthorizeCallbackComplete
• SpiQueryPeerLinkInformation
• SpiQueryProviderSubscriptionInformation

 вызывается через msrpc из драйвера tunnel.sys

efssvc.dll RPC interfaces

EFS Service
efsrpc DF1941C5-FE89-4E79-BF10-463657ACF44D version 1.0
0x15 methods:

• EfsRpcOpenFileRaw
• EfsRpcReadFileRaw
• EfsRpcWriteFileRaw
• EfsRpcCloseRaw
• EfsRpcEncryptFileSrv
• EfsRpcDecryptFileSrv
• EfsRpcQueryUsersOnFile
• EfsRpcQueryRecoveryAgents
• EfsRpcRemoveUsersFromFile
• EfsRpcAddUsersToFile
• EfsRpcSetFileEncryptionKey
• EfsRpcNotSupported
• EfsRpcFileKeyInfo
• EfsRpcDuplicateEncryptionInfoFile
• EfsUsePinForEncryptedFiles
• EfsRpcAddUsersToFileEx
• EfsRpcFileKeyInfoEx
• EfsRpcGenerateEfsStream
• EfsRpcGetEncryptedFileMetadata
• EfsRpcSetEncryptedFileMetadata
• EfsRpcFlushEfsCache

efskrpc 04EEB297-CBF4-466B-8A2A-BFD6A2F10BBA version 1.0
4 methods

• EfsKRpcEstablishRpcConnection
• EfsKRpcDecryptFek
• EfsKRpcGenerateKey
• EfsKRpcGenerateDirEfs

вызывается через msrpc.sys из драйвера ntfs например

ida 6.2

вышла например
changelog впрочем не впечатляет

wininet.dll RPC interfaces

CAD784CB-4C1B-4D96-B8F7-4716B568B13C version 1.0
0x37 methods:

• s_UrlCacheGetManagerInterface
• s_UrlCachePingServer
• s_UrlCacheOpenContainer
• s_UrlCacheCloseContainer
• s_UrlCacheAddUrl
• s_UrlCacheLookupUrl
• s_UrlCacheCheckUrlsExist
• s_UrlCacheGetUrlBinaryBlob
• s_UrlCacheAddUrlBinaryBlob
• s_UrlCacheDeleteUrl
• s_UrlCacheUnlockUrl
• s_UrlCacheUpdateUrl
• s_UrlCacheEntryEnum
• s_UrlCacheEntryEnumClose
• s_UrlCacheEntryEnumNext
• s_UrlCacheCleanupUrls
• s_UrlCacheGetSize
• s_UrlCacheGetLimit
• s_UrlCacheSetLimit
• s_UrlCacheGetBloomFilter
• s_UrlCacheGetNextDirectory
• s_UrlCacheAddLeakFile
• s_UrlCacheCreateGroup
• s_UrlCacheDeleteGroup
• s_UrlCacheGetGroupIds
• s_UrlCacheGetGroup
• s_UrlCacheUpdateGroup
• s_UrlCacheSetUrlGroup
• s_UrlCacheGetContentContainerDirectories
• s_UrlCacheCreateExtensibleContainer
• s_UrlCacheDeleteExtensibleContainer
• s_UrlCacheGetExtensibleContainersList
• s_UrlCacheRpcSetGlobalLimit
• s_UrlCacheRpcGetGlobalLimit
• s_AppCacheOpenContainer
• s_AppCacheCloseContainer
• s_AppCacheRpcCheckManifest
• s_AppCacheRpcLookup
• s_AppCacheRpcDeleteGroup
• s_AppCacheRpcDeleteIeGroup
• s_AppCacheRpcGetFallbackUrl
• s_AppCacheRpcGetDownloadList
• s_AppCacheRpcCloseHandle
• s_AppCacheRpcGetInfo
• s_AppCacheRpcGetGroupsList
• s_AppCacheRpcGetIeGroupList
• s_AppCacheRpcFreeIeSpace
• s_AppCacheRpcRetrieveUrl
• s_AppCacheRpcCommitUrl
• s_AppCacheRpcFinalize
• s_DependencyStoreOpenContainer
• s_DependencyStoreCloseContainer
• s_DependencyStoreUpdateUrl
• s_DependencyStoreRetrieveUrl
• s_DependencyStoreDeleteContainer

7856FB07-7EFE-4029-A4CB-4848641C40FF version 1.0
0x1F methods:

• s_IDBFactory_openDatabase
• s_IDBFactory_deleteDatabase
• s_IDBDatabase_createObjectStore
• s_IDBDatabase_deleteObjectStore
• s_IDBDatabase_setVersion
• s_IDBDatabase_transaction
• s_IDBDatabase_close
• s_IDBTransaction_openObjectStore
• s_IDBTransaction_abortAndClose
• s_IDBTransaction_commitAndClose
• s_IDBObjectStore_put
• s_IDBObjectStore_add
• s_IDBObjectStore_get
• s_IDBObjectStore_getFromKeyRange
• s_IDBObjectStore_delete
• s_IDBObjectStore_clear
• s_IDBObjectStore_openCursor
• s_IDBObjectStore_createIndex
• s_IDBObjectStore_openIndex
• s_IDBObjectStore_deleteIndex
• s_IDBObjectStore_close
• s_IDBIndex_openCursor
• s_IDBIndex_get
• s_IDBIndex_getFromKeyRange
• s_IDBIndex_getKey
• s_IDBIndex_getKeyFromKeyRange
• s_IDBIndex_close
• s_IDBCursor_update
• s_IDBCursor_continue
• s_IDBCursor_delete
• s_IDBCursor_close

appidsvc.dll RPC interface

Application Identity Service
8A7B5006-CC13-11DB-9705-005056C00008 version 1.0
2 methods:

• AppIDRpcVerifyFile
• AppIDRpcVerifyPackageMoniker

Регистрирует себя в epmapper с аннотацией AppIDSvc
Вызывается через msrpc из драйвера appid.sys

надо полагать

теперь в полночь все ваши айфоны превратятся в тыкву перейдут на windows 7 mobile, бгг

ViErrorDescriptions

и вот еще на сладкое - диагностические сообщения, которые driver verifier может выдать в ф-ции ViErrorDisplayDescription (в квадратных скобках внутренний код сообщения). По моему дают весьма наглядное представление о технологии

VerifierExt.sys

а вот например начиная с w8 driver verifier также содержит часть кода во внешнем драйвере VerifierExt.sys. Я понятия не имею зачем было так сделано - никакого механизма plugins в driver verifier по прежнему не предусмотрено и имя VerifierExt.sys жестко прошито в ntoskrnl.exe
Соотв-но интересен интерфейс сопряжения между этим драйвером и ядром
Например таблицы ф-ций driver verifierа в ядре имеют примерно такой формат:

struct THUNK_ITEM
{
  const char *func_name;
  PVOID verifier_thunk;
  PVOID unknown;
  ULONG index;
  PVOID *original_func;
};
Здесь интерес представляют три поля

•  verifier_thunk - это собственно указатель на ф-цию, производящую разнообразные проверки параметров, уровень Irql и так далее
• original_func - указатель на указатель на оригинальную ф-цию, перехват которой осуществлен driver verifier
• index - просто некое уникальное число

 Драйвер VerifierExt.sys помимо всякого предоставляет экспортируемую ф-цию GetXdvDDIWrappers, которая возвращает примерно такую структуру:

struct ddi_wrappers
{
  DWORD version; // равен 4, что проверяется в ф-ции ViXdvBindXdvDDIWrappers
  DWORD tab_size;
  PVOID wrappers[tab_size];
};
Соотв-но связь между указателем на ф-цию верификации в wrappers и набором THUNK_ITEM в ядре происходит по полю THUNK_ITEM.index
Например ф-ция валидации ExCreateCallback лежит по индексу 24 в массиве wrappers. Она же имеет index 24 в VfXdvThunks
Список ф-ций из VerifierExt.sys: