Написал перехват на SDT, по идее всё правильно, но почему то возникает STOP 0x000000D1 при поиске файлов, указывая на строку (!) И ещё мне пришлось поставить cli...sti чтобы устранить STOP 0x0000008E который тож указывает на эту же строку. Хотелось бы знать в чём сдесь ошибка и как её устранить. Вот код: NewNtQueryDirectoryFile: mov eax, [esp+18h] mov lpFileInformation, eax mov eax, [esp+20h] mov dwFileInformationClass, eax pop QDF_OldRet push offset QDF_NewRet jmp OldNtQueryDirectoryFile QDF_NewRet: test eax,eax jnz QDF_Exit cmp dwFileInformationClass, FileBothDirectoryInformation jnz QDF_Exit push ebx push ecx push edx push esi push edi push eax cli mov eax, lpFileInformation xor edx,edx assume eax:ptr FILE_BOTH_DIRECTORY_INFORMATION assume edx:ptr FILE_BOTH_DIRECTORY_INFORMATION QDF_loop: mov ecx, [eax].FileNameLength (!) shr ecx,1 cmp dwFileNameLength, ecx jne QDF_Next lea esi, [eax].FileName mov edi, offset uszFileName repe cmpsw test ecx,ecx jnz QDF_Next test edx,edx jnz QDF_Modify mov ebx,[eax].NextEntryOffset test ebx,ebx jz QDF_ModifyOne mov esi,eax mov edi,eax mov ecx,ebx add esi,ecx rep movsb add [eax].NextEntryOffset,ebx jmp QDF_loop QDF_ModifyOne: mov dword ptr [esp+4], STATUS_NO_SUCH_FILE jmp QDF_Exitloop QDF_Modify: mov ebx,[eax].NextEntryOffset test ebx,ebx jz QDF_ModifyLast add [edx].NextEntryOffset,ebx add eax,[eax].NextEntryOffset jmp QDF_loop QDF_ModifyLast: mov [edx].NextEntryOffset,0 jmp QDF_Exitloop QDF_Next: mov edx,eax add eax,[eax].NextEntryOffset cmp eax,edx jne QDF_loop QDF_Exitloop: assume eax:nothing assume edx:nothing sti pop eax pop edi pop esi pop edx pop ecx pop ebx QDF_Exit: jmp QDF_OldRet
Vol4oK Проблема видимо та же что и у всех кто пишет перехват NtQueryDirectoryFile, смотри правильную структуру FILE_BOTH_DIRECTORY_INFORMATION, вопрос поднимался на форуме неоднократно
Нет проблема не в этом, я знаю что в документации есть опечптка с UCHAR, я уже нашёл и испрвил этот баг и у меня всё сходиться байт в байт...
кароча такая же херня с перехватом 1. что касаеца структур - оин должны быть выровнены наскока я понимаю по 4 байта (кароча по скока там C++ выравнивает по умолчанию? - вот по столько, ошибок в определениях никаких нет, правильные версии - в NTIFS.H из Widnows IFS Kit) 2. DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1) The system attempted to access pageable memory using a kernel process IRQL that was too high. The most typical cause is a bad device driver (one that uses improper addresses). It can also be caused by caused by faulty or mismatched RAM, or a damaged pagefile (а если по русски, это значит что ты шото не то спамятью творишь и при это у тя слишком высокий уровень IRQ, уменьши его - KeLowerIrq(), скорее всего ты просто обращаешься к неверным адресам памяти) 3. cli/sti реально спасают
При отчаянии найти баг, я ставлю int 3 в коде, и в SoftIce анализирую каждую выполненую команду. Чего и тебе советую
по поводу DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1) я знаю, но откуда там может быть неверный адрес, данные копируються из стка, потом вызываеться true функция и в случае успеха этот код получает управления, следовательно там не может быть неверного адреса... По поводу IRQL, то теоретически он должен быть всегда passive, поэтмоу куда уж понижать не знаю... Сайсом отладить баг не получаеться ошибка возникаетвы лучшем случае 1/1000, как её отследить я не знаю...
вобщем ошибка была в том что я хранил некоторые данные в глобальных переменных, и если например данный код прерывает другой поток и вызывает эту ф-ию то он затирает значения переменной предыдущего потока, а когда возвращаеться управление прежнему потоку то там уже не те адреса и возникает бсод... поэтому для хранения переменных нужно использовать стэк, при переключении потоков переключаються стеки в том числе и стеки ядра, и таких проблем уже произойти не может)) Вобщем терь у меня всё работает, уже 3ий день драйверок в памяти весит никаких тормозов и бсодов))
