2008년 09월 19일
덤프분석하다 IRQL이 FF인 것을 경험해보셨다면..읽어보세요~
오늘 작업을 하다가
우연히 KeGetCurrentIrql 내부를 분석해보게 되었습니다.
KeGetCurrentIrql의 ASM 코드
1: kd> u hal!kegetcurrentirql
hal!KeGetCurrentIrql:
806e6428 a18000feff mov eax,dword ptr ds:[FFFE0080h]
806e642d c1e804 shr eax,4
806e6430 0fb68018126f80 movzx eax,byte ptr hal!HalpVectorToIRQL (806f1218)[eax]
806e6437 c3 ret
간단하게 보면 FFFE0080의 내용을 EAX에 넣고
HalpVertorToIRQL이라는 함수를 통하여 EAX에 대응하는
IRQL 값을 얻는 것이죠...
그래서 실제로 그런지 그냥 무심코 디버깅해보았습니다.
1: kd> p
hello!DriverEntry+0x13:
bafbf4c3 ff1580f5fbba call dword ptr [hello!_imp__KeGetCurrentIrql (bafbf580)]
==> KeGetCurrentIrql 안으로 진입합니다.
1: kd> t
806e6428 a18000feff mov eax,dword ptr ds:[FFFE0080h]
==> FFFE0080의 값이 FF임을 확인하고요
1: kd> dd fffe0080 l1
fffe0080 000000ff
==> 한 스텝 실행합니다.
1: kd> p
806e642d c1e804 shr eax,4
==> EAX값을 확인하였더니.. FF가 아닌 0 이 들어있습니다..
1: kd> r eax
eax=00000000
음.. 왜그럴까요? 분명 우리가 처음 확인하였을땐 FF값이었는데
실제로 들어간 값은 0 입니다....-.-;;;
처음엔 이게 왜그런지 몰라서..한참 해맸습니다만,
결국.. FF 라는 값은 현재 디버거가 attach하였기 때문에
그에 대응하는 IRQL로 변경이 된것입니다.
그리고 디버거가 detach되면, 원래 IRQL로 원복이 되고 그때의 값이 0 이 되는 것이죠...
사실 FFFE0080 이 값은 APIC의 TPR(Task Priority Register)를 가르킨다고합니다..
APIC는 주소 FFFE0000과 매핑이되어있고 APIC중에 한 레지스터인 TPR은 FFFE0080에
매핑되어 있는 것이죠...
이 TPR은 인터럽트가 발생할때 현재 인터럽트에 대한 우선순위 값을 가지고 있는 것인데요
이 값은 운영체제가 설정을 해준다고 합니다...
즉 IRQL을 구한닫는 것은 APIC의 TPR의 값을 가지고 와서
HalpVectorToIRQL 라는 함수를 통해 IRQL을 획득하는 것이지요..
실제로 디버거가 붙어있을 때 TPR값은 !apic명령으로도 확인가능합니다.
1: kd> !apic
Apic @ fffe0000 ID:1 (50014) LogDesc:02000000 DestFmt:ffffffff TPR FF
TimeCnt: 09e8c610clk SpurVec:1f FaultVec:e3 error:0
Ipi Cmd: 000008e1 Vec:E1 FixedDel Lg:01000000 edg high
Timer..: 000300fd Vec:FD FixedDel Dest=Self edg high masked
Linti0.: 0001001f Vec:1F FixedDel Dest=Self edg high masked
Linti1.: 000004ff Vec:FF NMI Dest=Self edg high
TMR:
IRR:
ISR:
어째든.. 이번 경우엔
디버거가 attach되어있을때는 TPR값이 바뀌기 때문에 이와 같이
메모리(FFFE0080h)에서 확인한 값과 실제 레지스터(eax)가 다른 현상이 발생한 것이었습니다.
덤프를 받아보시면, 현재 IRQL이 FF라고 나와있는 경우를 종종 경험하셨을것입니다.
이걸 보시고 IRQL이 왜이리 높아졌지?.. 이런경우도있나?.. 그래서 죽었나?
이렇게 생각하신분들 계실것입니다.
사실 이것도 bugcheck가 발생하면서 윈도우즈가 APIC의 TPR을 FF로 바꾸었기 때문에
덤프에 그런 흔적이 남아있는 것으로 생각하면됩니다.
실제 IRQL은 얼마였는지는 알수가 없죠...^^...
좀더 자세한 내용은 APIC(Advanced Programmable Controller)의 TPR레지스터를
찾아보시면, 좀더 이해가 쉬울 것이라고 생각이 되네요...^^
저는 여기까지만 확인하고 더 깊숙히 공부하는 것은..남겨두었답니다...
우연히 KeGetCurrentIrql 내부를 분석해보게 되었습니다.
KeGetCurrentIrql의 ASM 코드
1: kd> u hal!kegetcurrentirql
hal!KeGetCurrentIrql:
806e6428 a18000feff mov eax,dword ptr ds:[FFFE0080h]
806e642d c1e804 shr eax,4
806e6430 0fb68018126f80 movzx eax,byte ptr hal!HalpVectorToIRQL (806f1218)[eax]
806e6437 c3 ret
간단하게 보면 FFFE0080의 내용을 EAX에 넣고
HalpVertorToIRQL이라는 함수를 통하여 EAX에 대응하는
IRQL 값을 얻는 것이죠...
그래서 실제로 그런지 그냥 무심코 디버깅해보았습니다.
1: kd> p
hello!DriverEntry+0x13:
bafbf4c3 ff1580f5fbba call dword ptr [hello!_imp__KeGetCurrentIrql (bafbf580)]
==> KeGetCurrentIrql 안으로 진입합니다.
1: kd> t
806e6428 a18000feff mov eax,dword ptr ds:[FFFE0080h]
==> FFFE0080의 값이 FF임을 확인하고요
1: kd> dd fffe0080 l1
fffe0080 000000ff
==> 한 스텝 실행합니다.
1: kd> p
806e642d c1e804 shr eax,4
==> EAX값을 확인하였더니.. FF가 아닌 0 이 들어있습니다..
1: kd> r eax
eax=00000000
음.. 왜그럴까요? 분명 우리가 처음 확인하였을땐 FF값이었는데
실제로 들어간 값은 0 입니다....-.-;;;
처음엔 이게 왜그런지 몰라서..한참 해맸습니다만,
결국.. FF 라는 값은 현재 디버거가 attach하였기 때문에
그에 대응하는 IRQL로 변경이 된것입니다.
그리고 디버거가 detach되면, 원래 IRQL로 원복이 되고 그때의 값이 0 이 되는 것이죠...
사실 FFFE0080 이 값은 APIC의 TPR(Task Priority Register)를 가르킨다고합니다..
APIC는 주소 FFFE0000과 매핑이되어있고 APIC중에 한 레지스터인 TPR은 FFFE0080에
매핑되어 있는 것이죠...
이 TPR은 인터럽트가 발생할때 현재 인터럽트에 대한 우선순위 값을 가지고 있는 것인데요
이 값은 운영체제가 설정을 해준다고 합니다...
즉 IRQL을 구한닫는 것은 APIC의 TPR의 값을 가지고 와서
HalpVectorToIRQL 라는 함수를 통해 IRQL을 획득하는 것이지요..
실제로 디버거가 붙어있을 때 TPR값은 !apic명령으로도 확인가능합니다.
1: kd> !apic
Apic @ fffe0000 ID:1 (50014) LogDesc:02000000 DestFmt:ffffffff TPR FF
TimeCnt: 09e8c610clk SpurVec:1f FaultVec:e3 error:0
Ipi Cmd: 000008e1 Vec:E1 FixedDel Lg:01000000 edg high
Timer..: 000300fd Vec:FD FixedDel Dest=Self edg high masked
Linti0.: 0001001f Vec:1F FixedDel Dest=Self edg high masked
Linti1.: 000004ff Vec:FF NMI Dest=Self edg high
TMR:
IRR:
ISR:
어째든.. 이번 경우엔
디버거가 attach되어있을때는 TPR값이 바뀌기 때문에 이와 같이
메모리(FFFE0080h)에서 확인한 값과 실제 레지스터(eax)가 다른 현상이 발생한 것이었습니다.
덤프를 받아보시면, 현재 IRQL이 FF라고 나와있는 경우를 종종 경험하셨을것입니다.
이걸 보시고 IRQL이 왜이리 높아졌지?.. 이런경우도있나?.. 그래서 죽었나?
이렇게 생각하신분들 계실것입니다.
사실 이것도 bugcheck가 발생하면서 윈도우즈가 APIC의 TPR을 FF로 바꾸었기 때문에
덤프에 그런 흔적이 남아있는 것으로 생각하면됩니다.
실제 IRQL은 얼마였는지는 알수가 없죠...^^...
좀더 자세한 내용은 APIC(Advanced Programmable Controller)의 TPR레지스터를
찾아보시면, 좀더 이해가 쉬울 것이라고 생각이 되네요...^^
저는 여기까지만 확인하고 더 깊숙히 공부하는 것은..남겨두었답니다...
# by | 2008/09/19 11:31 | WORK | 트랙백 | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]