информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Портрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
 С наступающим 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да нет, так не должно быть: 11.06.02 03:55  Число просмотров: 1072
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
по F8 он НЕ ДОЛЖЕН передавать управление другим тредам. По F10, F12,ctrl+D - да, но в пошаговой трассировке он должен выполнять только отлаживаемый поток. И только по одной команде.
<programming>
Ну, ваще! 04.06.02 10:33  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Трейсю прогу айсом под 98... (Оле-сервер, я в него защиту встраиваю)
Цепочка флоут пойнт операций. Делаю очередной степ (F8) - операция флоут-умножения. Вдруг: Поверх айса (!!!) всплывает месагбокс клиента - "рунтайм еррор" и включается мышка!!! Потом под ним - сам клиент. Когда я жму Ок, клиент дохнет, вместо него остается белое пятно, а вокруг него - клочья айса! Мало того! Когда я изрядно о--ев я запускаю ИЕ, чтобы поделиться ох-ением с общественностью (с Вами т.е.) клочья винайса проступают сквозь окно эксплорера и вних бегут строчки!!!
Это что же получается?! До сих пор, я считал айс единственной надежной прогой под МД, крайним средством распутывания проблем, если ничего больше не помогает (крайнее только мыло и веревка), а теперь и на него надеяться нелзя!
Выходит, захочешь удавиться, мыло обернется клеем, а веревка превратится в лом?
И вообще, конструктивно: как под айсом ОЛЕ-клиент ухитрился обнаружить, что сервер не отвечает, если айс даже часы останавлвает!?
Есть такой глюк в Soft Ice 19.06.02 10:42  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
Подобное у меня случалось в Win9x, когда трейсишь обработчик прерывания в V86 и доходишь до команды iret. А сразу после iret иногда пападаешь на команду ARPL. В принципе это стандартный для win9x способ перехода из ring3 в ring0 (по ARPL генерится исключение и оно ловится в ring 0). Но если на этом ARPL нажать F8/F10, то произойдет в точности то же самое, что у Zef'а: винда "выскальзывает" из под Софт-Айса, причем похоже что Софт-Айс этого даже не понимат (его картинка остается на экране, а потом сообщения из его command window выползают поверх Десктопа, пока не нажмешь Ctrl+D)

Вот как этот глюк воспроизвести (Win98SE, Soft Ice 4.01).
следующий код в io.sys (это конец обработчика int 2Fh, imho):
4636: 7503       jne       00000463B
4638: 83C9FF     or        cx,-001 
463B: 1F         pop       ds ;<========= сюда ставим BPX
463C: CF         iret

---

bpx я ставлю так:
:s 0 l ffffffff 75 03 83 c9
Pattern found at 0028:00102426 (00102426)
:bpx 0028:0010242B
Ждем пока сработает bpx, трейсим до ARPL и офигеваем :-)
[Win32] A ARPL то откуда берется?! 19.06.02 11:51  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
[Win32] A ARPL то откуда берется?! 19.06.02 14:47  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
From SoftICE Users Guide
Understanding Transitions From Ring-3 to Ring-0
Many times when tracing into code using Windows 95 and Windows 98, you arrive at either an INT 0x30 or an ARPL. Both are methods for making a transition from Ring-3 to Ring-0.When you wish to follow the ring transition, you can save yourself the time and effort of stepping through a large amount of VMM code by using the G(o) command to execute up to the address shown in the disassembly.
Windows 95 and Windows 98 uses the following methods to transition Ring-3 code to Ring-0 code:
* For V86 code, Windows 95 and Windows 98 use the ARPL instruction, which causes an invalid opcode fault. The invalid opcode handler then passes control to the appropriate VxD. The ARPL instruction is usually in ROM. Windows 95 and Windows 98 use only one ARPL and it varies the V86 segment:offset to indicate different VxD addresses. For example, if the ARPL is at FFFF:0, Windows 95 and Windows 98 use the addresses FFFF:0, FFFE:10, FFFD:20, FFFC:30 and so on.
The following example shows sample output for disassembling an ARPL:
FDD2:220D ARPL DI,BP ; #0028:C0078CC9 IFSMgr(01)+0511
[Win32] Да нет, ты не понял! (Или я не понял) 20.06.02 04:32  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
как через ARPL передавать управление в R0 я знаю, но по твоему посту я понял, что ARPL появляется в коде там, где его раньше не было. А если это не так, то почему он стоит сразу после возврата? Или сей глюк появляется только когда прерывание пришло непосредственно перед выполнением этой команды? Но какова тогда вероятность на него нарваться?!
[Win32] ARPL находится в BIOS 20.06.02 13:56  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
А iret на него прыгает потому, что при вызове обработчика прерывания в стек кладется адрес этого arpl в качестве адреса возврата.
Ясно. Значит и у меня именно это и получается 21.06.02 05:29  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Обвал происходит в драйвере CDROM (WinASPI), а он естессно работает через БИОС.
Ну, ваще! 05.06.02 23:39  
Автор: Dr.Golova Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Трейсю прогу айсом под 98... (Оле-сервер, я в него защиту
> встраиваю)
> Цепочка флоут пойнт операций. Делаю очередной степ (F8) -
> операция флоут-умножения. Вдруг: Поверх айса (!!!)
> всплывает месагбокс клиента - "рунтайм еррор" и включается
> мышка!!! Потом под ним - сам клиент. Когда я жму Ок, клиент
> дохнет, вместо него остается белое пятно, а вокруг него -
> клочья айса! Мало того! Когда я изрядно о--ев я запускаю
> ИЕ, чтобы поделиться ох-ением с общественностью (с Вами
> т.е.) клочья винайса проступают сквозь окно эксплорера и
> вних бегут строчки!!!
> Это что же получается?! До сих пор, я считал айс
> единственной надежной прогой под МД, крайним средством
> распутывания проблем, если ничего больше не помогает
> (крайнее только мыло и веревка), а теперь и на него
> надеяться нелзя!
> Выходит, захочешь удавиться, мыло обернется клеем, а
> веревка превратится в лом?
> И вообще, конструктивно: как под айсом ОЛЕ-клиент ухитрился
> обнаружить, что сервер не отвечает, если айс даже часы
> останавлвает!?

Ничего удивительного - в какой-то цепочке проги произошло исключение и сдохла та цепочка которую ты отлаживал. Обычное дело - пока ты трейсишь одну цепочку по команде, другие выполняются потихоньку.
Айс по идее должен останавливать все, или? 06.06.02 04:43  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
если отлаживаемый тред дохнет (там и правда был пэйдж фолт из-за неправильной передачи указателя в функцию), он разрешает выполняться другим?
Айс по идее должен останавливать все, или? 06.06.02 08:52  
Автор: SerpentFly <Vadim Smirnov> Статус: Member
<"чистая" ссылка>
> если отлаживаемый тред дохнет (там и правда был пэйдж фолт
> из-за неправильной передачи указателя в функцию), он
> разрешает выполняться другим?

Когда ты нажимаешь F10 чтобы перейти к следующей команде твоего thread'а система начинает жить своей жизнью (как жила до того как ты ее остановил) до тех пор пока твой Thread не добереться до своей следущей команды...
F8 06.06.02 14:08  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Не суть важно... 06.06.02 15:22  
Автор: SerpentFly <Vadim Smirnov> Статус: Member
<"чистая" ссылка>
В сущности имеется ввиду останов на следующей инструкции, а уж как его добиваться, хоть bpx на нее поставь будет то же самое...
Фу - у - х, отстояли SoftIce-таки, а то я уже вспотел ;-))) 10.06.02 23:07  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Да нет, так не должно быть: 11.06.02 03:55  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
по F8 он НЕ ДОЛЖЕН передавать управление другим тредам. По F10, F12,ctrl+D - да, но в пошаговой трассировке он должен выполнять только отлаживаемый поток. И только по одной команде.
Да нет, так не должно быть: 11.06.02 09:45  
Автор: SerpentFly <Vadim Smirnov> Статус: Member
<"чистая" ссылка>
> по F8 он НЕ ДОЛЖЕН передавать управление другим тредам. По
> F10, F12,ctrl+D - да, но в пошаговой трассировке он должен
> выполнять только отлаживаемый поток. И только по одной
> команде.

Может тогда и sheduling потоков отменить? Если слайс времени потока истек контекст должен переключиться, а в твоем понимании получается что при трассировке контекст потока никогда не переключается, то есть сайс превращает систему в однозадачную/однопоточную. Это вообще-то создает искуственную среду отладки забивая весь смысл отладки в реальной живой системе. Не говоря уже о том что должны вызываться обработчики прерываний, исполняться DPC и т.п..

То есть реален сценарий когда у тебя есть драйвер с ISR(устройство с прерыванием) и трассируешь какой-нить рабочий поток по F8, который допустим в цикле проверяет значение какой-то переменной в памяти (для большей реальности эксперимента устанавливаемой например в обработчике ISR, это так называемая spin блокировка в упрощенном варианте) и делает что-то как только ISR присвоит переменной определенное значение. В твоем понимании трассируя поток по F8 ты должен будешь вечно крутиться в цикле проверяющем эту переменную!!! Что же в этом правильного?

Да и если не упираться в драйвера, то как отлаживать многопоточные приложения?

Ну и на закуску, чем же отличается F8 от F10:

F8- The T command uses the single step flag to single step one instruction.
Execution begins at the current CS:EIP, unless you specify the start-address parameter.


F10 - The P command executes a logical program step. In assembly mode, one instruction at the current CS:EIP is executed unless the instruction is a call, interrupt, loop, or repeated string instruction. In those cases, the entire routine or iteration is completed before control is returned to SoftICE.

То есть в режиме асма обе команды работают идентично за исключением "call, interrupt, loop, or repeated string instruction".
но именно так и проиходит, тем не менее 12.06.02 01:02  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> присвоит переменной определенное значение. В твоем
> понимании трассируя поток по F8 ты должен будешь вечно
> крутиться в цикле проверяющем эту переменную!!! Что же в
> этом правильного?

правильно-неправильно это все субъективно
вопрос-то был как происходит на самом деле при степах - бежит мультипотоковость-мультизадачность или стоит
смотри:
---------------------test.asm----------------------
.386

extrn ExitProcess :near
extrn ExitThread :near
extrn CreateThread :near

code32 segment use32 para private 'code'
assume cs:code32
assume ds:data32

entry:
push esp ;lpThreadId
xor eax,eax
push eax ;dwCreationFlags
push eax ;lpParameter
push offset thread ;lpStartAddress
push eax ;dwStackSize
push eax ;lpThreadAttributes
call CreateThread ;
entry_0:
cmp dword ptr [check],1
jne entry_0
dec dword ptr [check]
push dword 0 ;dwExitCode
call ExitProcess

thread:
db 0cch ;please use F8/f10 from here
inc dword ptr [check]
thread_0:
cmp dword ptr [check],0
jne thread_0
push dword 0 ;dwExitCode
call ExitThread

code32 ends

data32 segment use32 para private 'data'
check dd 0
data32 ends

end entry
--------------------------------------------------------------

ну и что? скажешь добредешь по F8/F10 до exit-а?

так что комрад Zef правильно понимает, а вот что ты хочешь доказать - я не въехал

[z0]
Не хочу вдаваться в твой асм, но... 13.06.02 15:32  
Автор: SerpentFly <Vadim Smirnov> Статус: Member
<"чистая" ссылка>
Я отлаживал многопоточность в ядре и контексты потоков у меня переключались (по крайней мере при трассировке по F10). Не говоря уже о том что при трассировке на PASSIVE_LEVEL пришедшее DPC прерывает текущий трассируемый поток... Это из опыта, что думает по этому поводу айс сказать сложно не помев его сырцов, поведение может и разниться между версиями...
Не хочу вдаваться в твой асм, но... 14.06.02 16:42  
Автор: z0 <z0> Статус: Member
<"чистая" ссылка>
> Я отлаживал многопоточность в ядре и контексты потоков у
> меня переключались (по крайней мере при трассировке по
> F10). Не говоря уже о том что при трассировке на
> PASSIVE_LEVEL пришедшее DPC прерывает текущий трассируемый
> поток... Это из опыта, что думает по этому поводу айс
> сказать сложно не помев его сырцов, поведение может и
> разниться между версиями...

ну ядро это круто конечно! УВАЖАЮ!!!
хотя... а давай посмотрим что там в ядре творится...
может чего нового узнаем...
итак ядро - а значит драйверочек:
----------------------drvdrv.asm-------------------------
.386

extrn IoCreateDevice :near
extrn IoCreateSymbolicLink :near
extrn IoDeleteDevice :near
extrn IoDeleteSymbolicLink :near
extrn IoCompleteRequest :near

_text segment use32 para private 'code'
assume cs:_text
assume ds:_data

DriverStart:
xor eax,eax
push offset DeviceObject ;PDEVICE_OBJECT
push eax ;Exclusive
push eax ;DeviceCharacteristics
push dword 16h ;DeviceType
push offset DeviceName ;DeviceName
push eax ;DeviceExtensionSize
push dword ptr [esp+0+1ch] ;DriverObject
call IoCreateDevice
test eax,eax ;NTSTATUS
jnz DriverStart_abort
push offset DeviceName ;DeviceName
push offset DeviceLink ;DeviceLinkName
call IoCreateSymbolicLink
test eax,eax ;NTSTATUS
jnz DriverStart_delete_and_abort
mov ecx,[esp+4]
mov dword ptr [ecx+34h],offset DriverStop
mov eax,offset IRPprocessor
mov [ecx+38h],eax ;IRP_MJ_CREATE
mov [ecx+40h],eax ;IRP_MJ_CLOSE
mov [ecx+70h],eax ;IRP_MJ_DEVICE_CONTROL
mov eax,[DeviceObject]
mov dword ptr [eax+01ch],050h ;DEVICE_FLAGS
xor eax,eax
DriverStart_done:
retn 8
DriverStart_delete_and_abort:
push dword ptr [DeviceObject] ;DEVICE_OBJECT
call IoDeleteDevice
DriverStart_abort:
mov eax,0c0000001h ;STATUS_UNSUCCESSFUL
retn 8

DriverStop:
push offset DeviceLink ;DeviceLinkName
call IoDeleteSymbolicLink
push dword ptr [DeviceObject] ;DEVICE_OBJECT
call IoDeleteDevice
xor eax,eax
retn 4

IRPprocessor:
mov ecx,[esp+8] ;IRP
mov eax,[ecx+60h] ;IRP->CurrentStackLocation
cmp byte ptr [eax],0eh ;operation code = DEVICE_IO_CONTROL
mov eax,0
mov [ecx+18h],eax ;IRP->IoStatus.Status
mov eax,[nBytes]
mov [ecx+1ch],eax ;IRP->IoStatus.Information
push eax ;IO_NO_INCREMENT
push ecx ;pIRP
jne IRPprocessor_not_interesting
inc dword ptr [check]
cmp dword ptr [check],1 ;only this IRP is processing by now
;если не сделать эту проверку
;то быстренько попадем в deadlock
;когда ВСЕ потоки торчат на cmp/jne (классика жанра)
jne IRPprocessor_not_a_case
mov ecx,1000h ;здесь может произойти переключение задачи и начнет
delay: ;выполнятся IRPprocessor для другой задачи(inc) но не успеет
loop delay ;закончиться(dec). сам он сюда не проходит (см. выше)
;тогда мы попадаем в айс
;на быстрых цпу тут можно поиграть задержкой
cmp dword ptr [check],2 ;2+ IRPs are processing now
jb IRPprocessor_not_a_case
db 0cch ;please use F8/F10 from here
IRPprocessor_loop:
cmp dword ptr [check],1 ;wait for other IRPs to gonna away...
jne IRPprocessor_loop
IRPprocessor_not_a_case:
call IoCompleteRequest
xor eax,eax
dec dword ptr [check]
retn 8
IRPprocessor_not_interesting:
call IoCompleteRequest
xor eax,eax
retn 8

_text ends

_data segment use32 para private 'data'

DeviceObject dd 0
check dd 0
nBytes dd 10h ;для выхода измени этот dword и скажи на jne 'r fl +z'

DeviceName dw DEVICE_NAME_SIZE-2
dw DEVICE_NAME_SIZE
dd offset _DeviceName
_DeviceName db '\',0,'D',0,'e',0,'v',0,'i',0,'c',0,'e',0,'\',0,'D',0,'R',0,'V',0,'D',0,'R',0,'V',0,0,0
DEVICE_NAME_SIZE equ $-_DeviceName

DeviceLink dw DEVICE_LINK_SIZE-2
dw DEVICE_LINK_SIZE
dd offset _DeviceLink
_DeviceLink db '\',0,'D',0,'o',0,'s',0,'D',0,'e',0,'v',0,'i',0,'c',0,'e',0,'s',0,'\',0,'D',0,'R',0,'V',0,'D',0,'R',0,'V',0,0,0
DEVICE_LINK_SIZE equ $-_DeviceLink

_data ends

end DriverStart
------------------------------------------------------
можно было конечно и в ините запустить поток например PsCreateSystemThread - и было бы попроще конечно
но там и придраться легче - а тут железно: 2 равноправных thread-а в ядре
проверка степов предлагается на одновременной обработке IRP от разных процессов
соответственно два+ раза запускается вот такой екзешничек:
------------------------ app.asm ----------------------
.386

extrn DeviceIoControl :near
extrn ExitProcess :near
; skipped some imports

_text segment use32 para private 'code'
assume cs:_text
assume ds:_data

entry:
call LoadDriver ;возвращает handle от CreateFileA('\\.\DRVDRV' и так далее)
mov esi,eax
test eax,eax
jz exit
entry_loop:
push esp
mov eax,esp
push dword 0 ;lpOverlapped
push eax ;lpBytesReturned
push dword BufferSize ;nOutBufferSize
push offset Buffer ;lpOutBuffer
push dword BufferSize ;nInBufferSize
push offset Buffer ;lpInBuffer
push dword 0babebabeh ;ControlCode
push esi ;hDevice
call DeviceIoControl
pop eax
cmp eax,10h
je entry_loop
call UnloadDriver
exit:
push dword 0
call ExitProcess

LoadDriver:
; skipped
UnloadDriver:
; skipped

_text ends

_data segment use32 para private 'data'

;skipped some data

BufferSize equ 10h

align 4
Buffer db 10h dup('?')

_data ends

end entry
------------------------------------------------------
очень (по-моему) убедительно доказывает ОТСУТСТВИЕ мультивсего при НОРМАЛЬНЫХ степах
и покажи мне версию айса где это не так
а объясняется все довольно тривиально: у TraceFlag-а САМЫЙ высокий приоритет
поскольку он обрабатывается ПОСЛЕ ПРЕДЫДУЩЕЙ инструкции (это кстати отразилось
в "КАК-БЫ пропуске" одной команды после установки флага) и никакие IRQ0 etc
не проходят т.к. принимаются МЕЖДУ инструкциями (в зазоре, который ПРОПАДАЕТ внутри EXCEPTION1)

поэтому для всех степов по флагу - никаких внешних событий НЕ СУЩЕСТВУЕТ
для других степов типа 'F10-call' которые в общем-то и степами назвать
трудно (редко чтоли call не возващает или не туда...) - сколько угодно

[z0]

ЗЫ: проверялось на nt4 english server sp6 + ntice 4.0.5 build 334 cpu=p166mmx
Ты на асме пишешь наверное чтобы легче код читался? 15.06.02 10:47  
Автор: SerpentFly <Vadim Smirnov> Статус: Member
<"чистая" ссылка>
А ты все-таки создай потоки через PsCreateSystemThread. В твоем примере возможно айс препятствует второму потоку войти в ядро. Повторюсь, я не знаю как айс организует трассировку и не хочу вдаваться в детали. Однако как я уже говорил между двумя потоками в ядре переключение все-таки происходит !!! (Win2k SP2 SoftIce Driver Suite 2.6)
У меня поток не в ядре. Не понял, кому совет? 16.06.02 04:56  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach