VAB>>>Запустите image какой под VMWare с 64-96 Mb RAM и поищите там свои 120 метров?

А>>Для этого есть System Requirements (Memory: ...) в readme.txt, чтобы указать явно сколько минимум нужно софтине (драйверу) памяти.
VAB>Замечу что драйвер, пусть и неродной, по определению становится TCB частью ОС и не должен соотв. кардинально требования завышать, без серьезной причины.

Вот с этим не согласен. Совсем не обязательно, да вы и сами сделали оговорку.

VAB>софтина-драйвер запросто может не знать сколько ей нужно. но работать и не кашлять как правило обязана, это раз.

Должна знать предел! Иначе — 99% кривая архетиктура, ошибки при пректировании или ещё что там...

VAB>от ламеров как изволили выразиться, скушавшими весь стек и почти всю память заодно, это также не спасет. с таким подходом мол "чего non-paged pool жалеть у нас дядя на nonpagedpool фабрике работает!" — заберем последние, сколько там осталось К ценного ресурса абсолютно без нужды, да расшибемся лишний раз на ровном месте носом оземь. Ну и посмотрим как на нас будут показывать пальцем. Ибо без нас вроде работало. И правильно сделают. это два.

Да никто не говорит, что её, память, нужно забирать всю! Я сам, например, периодически занимаюсь оптимизацией расхода.

VAB>и как часто Вы читаете readme и проверяете что все что там написано соблюдается до запуска своей любимой программулины? это три.

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

VAB>так что не спасет никоим образом никакой readme.txt от кривого кода. Разве что от исков к производителю. Но не от репутации и не от недовольных пользователей, которые унесут фактически ваши денежки кому-то другому.

Ну а ламеры... всегда остануться нашей проблемой...

VAB>>Замечу что драйвер, пусть и неродной, по определению становится TCB частью ОС и не должен соотв. кардинально требования завышать, без серьезной причины.

А>Вот с этим не согласен. Совсем не обязательно, да вы и сами сделали оговорку.
я ее сделал по причине что какому-то mirror драйверу к примеру в явном виде может быть нужно никак не меньше чем занимает экранная поверхность — неск Мб сразу вынь да положь. И это можно учесть легко.

Когда же идет фильтрация сетевого траффика или файлового\дискового ввода-вывода — тут как Вы понимаете зависит от числа коннектов, открытых файлов и интенсивности самого ввода-вывода. А кол-во сие в свою очередь как правило уже упирается в наличие памяти разных типов причем, можно и pagedpool вперед истощить легко. Соотв. учету поддается с трудом в таком фильтре расход — от 0 до всей свободной, и разбрасываться ресурсами в ситуации когда каждый след. коннект\открытый файл\IRP летящий по стеку может стать последним не стоит конечно.

Ведь кто знает, может быть эти неск Кб, которые в Вилларибо предусмотрительно съэкономили, как раз и позволили пройти критическую точку и не уронить систему в условиях временно истощенных ресурсов. Дальше файлы позакрывались, коннекты отвалились и ситуация с ресурсами выровнялась. А в Виллабаджо все упало и там до сих пор греют дебаггеры, вспоминая чью-то мать

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

А>Должна знать предел! Иначе — 99% кривая архетиктура, ошибки при пректировании или ещё что там...
выше написал про случай без предела — фильтр чего-либо. Ошибок может и не быть никаких.

ну ладно, откровенно говоря, мы у себя пишем в design documents на каждую фичу и т.п. в разделе Resource Usage что-то вроде:

Memory usage is just few kilobytes of non-paged memory to store:
• the list of IDs for known files on permanent basis
• the names of protected files
• the pointers to referenced file objects
One additional worker thread is required for the internal file open operations.

но это же не совсем то, что имеет смысл помещать в readme.txt

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

В принципе можно вычислить, сколько памяти нужно на сколько коннектов и записать уже в таком виде в readme.txt — это имеет практический смысл, пожалуй.

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

CO>К тому же много багов

Это же школьник и руткит, о каких багах может идти речь?

Что бы не разводить беспочвенный флейм на тему "наколенная разработка vs работа 24*7" приведу фрагмент коммерческого Rustock rootkit. Из аналога ndis.sys!ndisReferenceMiniportByName:

.text:00014486     ;  ndisReferenceMiniportByName
.text:00014486
.text:00014486     ; struct NDIS_MINIPORT_BLOCK * __stdcall get_NDIS_MINIPORT_BLOCK(struct _UNICODE_STRING *RootDeviceName)
.text:00014486     get_NDIS_MINIPORT_BLOCK proc near
.text:00014486
.text:00014486     NewIrql         = byte ptr -1
.text:00014486     RootDeviceName  = dword ptr  4

.text:00014486 000                 push    ecx
.text:00014487 004                 mov     ecx, ndisMiniDriverListLock ; SpinLock
.text:0001448D 004                 push    ebx
.text:0001448E 008                 push    esi
.text:0001448F 00C                 xor     ebx, ebx
.text:00014491 00C                 call    ds:KfAcquireSpinLock
.text:00014497 00C                 mov     [esp+0Ch+NewIrql], al
.text:0001449B 00C                 mov     eax, p_ndisMiniDriverList
.text:000144A0 00C                 mov     esi, [eax]      ; NDIS_M_DRIVER_BLOCK ptr
.text:000144A2 00C                 test    esi, esi
.text:000144A4 00C                 jz      short loc_144F0
.text:000144A6 00C                 push    ebp
.text:000144A7 010                 push    edi
.text:000144A8     loc_144A8:
.text:000144A8 014                 test    ebx, ebx
.text:000144AA 014                 jnz     short loc_144EE
.text:000144AC 014                 lea     ebp, [esi+90h]
.text:000144B2 014                 mov     ecx, ebp        ; SpinLock
.text:000144B4 014                 call    ds:KefAcquireSpinLockAtDpcLeve

Аналогичное место в оригинале XPSP2 выглядит несколько иначе:

PAGENPNP:00020451                 mov     ebx, _ndisMiniDriverList
PAGENPNP:00020457                 test    ebx, ebx
PAGENPNP:00020459                 mov     byte ptr [ebp+name+3], al
PAGENPNP:0002045C                 jz      loc_20501
PAGENPNP:00020462                 push    edi
PAGENPNP:00020463 loc_20463:
PAGENPNP:00020463                 lea     ecx, [ebx+0ACh]
PAGENPNP:00020469                 call    ds:KefAcquireSpinLockAtDpcLevel(x)

Причина различий находится простым поиском в дампе ndis.pdb значения 0xac:

struct _NDIS_M_DRIVER_BLOCK {
  // non-static data --------------------------------
  /*<thisrel this+0x0>*/ /*|0x4|*/ struct _NDIS_M_DRIVER_BLOCK* NextDriver;
  /*<thisrel this+0x4>*/ /*|0x4|*/ struct _NDIS_MINIPORT_BLOCK* MiniportQueue;
  /*<thisrel this+0x8>*/ /*|0x4|*/ struct _NDIS_WRAPPER_HANDLE* NdisDriverInfo;
  /*<thisrel this+0xc>*/ /*|0x4|*/ struct _NDIS_PROTOCOL_BLOCK* AssociatedProtocol;
  /*<thisrel this+0x10>*/ /*|0x8|*/ struct _LIST_ENTRY DeviceList;
  /*<thisrel this+0x18>*/ /*|0x4|*/ struct _NDIS_PENDING_IM_INSTANCE* PendingDeviceList;
  /*<thisrel this+0x1c>*/ /*|0x4|*/ void  (UnloadHandler*)(struct _DRIVER_OBJECT*);
  /*<thisrel this+0x20>*/ /*|0x7c|*/ struct _NDIS51_MINIPORT_CHARACTERISTICS MiniportCharacteristics;
  /*<thisrel this+0x9c>*/ /*|0x10|*/ struct _KEVENT MiniportsRemovedEvent;
  /*<thisrel this+0xac>*/ /*|0x8|*/ struct _REFERENCE Ref;
  /*<thisrel this+0xb4>*/ /*|0x2|*/ unsigned short Flags;
  /*<thisrel this+0xb8>*/ /*|0x20|*/ struct _KMUTANT IMStartRemoveMutex;
  /*<thisrel this+0xd8>*/ /*|0x4|*/ unsigned long DriverVersion;
};

и _NDIS51_MINIPORT_CHARACTERISTICS в ndis.h

typedef struct _NDIS51_MINIPORT_CHARACTERISTICS
{
#ifdef __cplusplus
    NDIS50_MINIPORT_CHARACTERISTICS Ndis50Chars;
#else
    NDIS50_MINIPORT_CHARACTERISTICS;
#endif
    //
    // Extensions for NDIS 5.1
    //
    W_CANCEL_SEND_PACKETS_HANDLER   CancelSendPacketsHandler;
    W_PNP_EVENT_NOTIFY_HANDLER      PnPEventNotifyHandler;
    W_MINIPORT_SHUTDOWN_HANDLER     AdapterShutdownHandler;
    PVOID                           Reserved1;
    PVOID                           Reserved2;
    PVOID                           Reserved3;
    PVOID                           Reserved4;
} NDIS51_MINIPORT_CHARACTERISTICS;

При этом реализован относительно универсальный (порядка 80 строк на C — это к обходу на 200 строк

Автор: Andrew.W Worobow
Дата: 15.02.07

) поиск неэкспортируемых ndis.sys!ndisMiniDriverList и ndis.sys!ndisMiniDriverListLock. Кто-нибудь может дать рациональное объяснение, почему используется захардкоженная NDIS50_MINIPORT_CHARACTERISTICS ? У меня варианта 2:
— ватермарк (но лок на другом поле — в любом случае баг )
— автор не знал что делает этот чужой код

http://tarasc0.blogspot.com/2007/02/inside-ndis-60.html

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

TC>http://tarasc0.blogspot.com/2007/02/inside-ndis-60.html

А старый добрый метод — pdbdump — в висте не работает уже ?

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

TC>Хорошие новости — NDIS 6.0 имеет дырок для установки руткитов не менее предшествующей 5.0. Я потратил фактически 1 час на легкий реверс, чтобы из одного NDIS компонента получить доступ к другому, в том числе точкам передачи данных. Связанные списки похоже форева. Кстати, любителям реверса — NDIS 6.0 просто создана для Вас — каждая структура имеет в начале неповторимую сигнатуру, чтоб не дай Боже не спутать ).

Может пора уже открывать форум по написанию руткитов? =)

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

GN>А старый добрый метод — pdbdump — в висте не работает уже ?

не спортивно