Dump 파일을 더블 클릭하면 Windbg랑 연결하는 방법 입니다.
windbg -IA
굉장히 쉽죠 .. 생각보다 편리한데 모르시는 분들이 의외로 꾀 있는거 같아서 올립니다.
간혹 ( 정말 간혹 ) 무한 Loop 코드가 CPU를 모두 선점하여 시스템이 먹통이 되는 경우가 종종 발생합니다. 예를 들면 일정 시간동안 시스템이 멈췄다가 다시 원래대로 돌아오는 것과 같은 현상이 대표적인 경우가 아닐까 생각됩니다.
일단 키보드를 이용해서 Hang 발생시점에 Dump를 발생 시킵니다. 그 덤프를 통해서 분석을 해보도록 하죠.
1: kd> !running -i -t
System Processors 3 (affinity mask)
Idle Processors 0
Prcbs Current Next
0 ffdff120 88afcda8 …………….
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
a2eba5a4 a2fb05a9 lockDrv+0×12154
a2eba5c0 a2fb0731 lockDrv+0×15a9
a2eba5f4 a2fb3aab lockDrv+0×1731
a2eba628 a2fb3bcc lockDrv+0×4aab
a2eba680 a467e18f lockDrv+0×4bcc
a2eba6a4 a467e80e mfehidk+0×718f
a2eba73c a468c367 mfehidk+0×780e
a2eba74c a468c3b7 mfehidk+0×15367
a2eba774 804e33eb mfehidk!DEVICEDISPATCH::DispatchPassThrough+0×48
a2eba784 a4623ace nt!IopfCallDriver+0×31
a2eba7e8 a4623f70 UDSecDrvXP+0×1ace
a2eba804 804e33eb UDSecDrvXP+0×1f70
a2eba814 8057dbed nt!IopfCallDriver+0×31
a2eba8f4 8056f03b nt!IopParseDevice+0xa12
a2eba96c 80572358 nt!ObpLookupObjectName+0×53c
a2eba9c0 8057e246 nt!ObOpenObjectByName+0xea
a2ebaa3c 8057e315 nt!IopCreateFile+0×407
a2ebaa98 8057e358 nt!IoCreateFile+0×8e
a2ebaad8 f79e7564 nt!NtCreateFile+0×30
a2ebad30 804df99f fhdrv+0×564
1 f7717120 88b06498 …………….
ChildEBP RetAddr
a2ef6460 f75897fb nt!KeBugCheckEx+0×1b
a2ef647c f7589033 i8042prt!I8xProcessCrashDump+0×237
a2ef64c4 804dd90f i8042prt!I8042KeyboardInterruptService+0×21c
a2ef64c4 a2fc1154 nt!KiInterruptDispatch+0×45
WARNING: Stack unwind information not available. Following frames may be wrong.
a2ef65a4 a2fb05a9 lockDrv+0×12154
a2ef65c0 a2fb0731 lockDrv+0×15a9
a2ef65f4 a2fb3aab lockDrv+0×1731
a2ef6628 a2fb3bcc lockDrv+0×4aab
a2ef6680 a467e18f lockDrv+0×4bcc
a2ef66a4 a467e80e mfehidk+0×718f
a2ef673c a468c367 mfehidk+0×780e
a2ef674c a468c3b7 mfehidk+0×15367
a2ef6774 804e33eb mfehidk!DEVICEDISPATCH::DispatchPassThrough+0×48
a2ef6784 a4623ace nt!IopfCallDriver+0×31
a2ef67e8 a4623f70 UDSecDrvXP+0×1ace
a2ef6804 804e33eb UDSecDrvXP+0×1f70
a2ef6814 8057dbed nt!IopfCallDriver+0×31
a2ef68f4 8056f03b nt!IopParseDevice+0xa12
a2ef696c 80572358 nt!ObpLookupObjectName+0×53c
a2ef69c0 8057e246 nt!ObOpenObjectByName+0xea
1: kd> u IofCallDriver
nt!IofCallDriver:
804e33b9 ff2580d75580 jmp dword ptr [nt!pIofCallDriver (8055d780)]
804e33bf 90 nop
804e33c0 90 nop
804e33c1 90 nop
804e33c2 90 nop
804e33c3 90 nop
nt!IopfCallDriver:
804e33c4 fe4a23 dec byte ptr [edx+23h]
804e33c7 8a4223 mov al,byte ptr [edx+23h]
1: kd> dd 8055d780
8055d780 a2fb3bc0 804e37da 804ecd58 804eceb1
8055d790 00000000 00000000 00000000 00000000
8055d7a0 00000000 00000000 00000000 00000000
8055d7b0 00000000 00000000 00000000 00000000
8055d7c0 00000000 00000000 00000000 00000000
8055d7d0 00000000 00000000 00000000 00000000
8055d7e0 00000000 00000000 00000000 00000000
8055d7f0 00000000 00000000 00000000 00000000
1: kd> u a2fb3bc0
lockDrv+0×4bc0:
a2fb3bc0 8bc4 mov eax,esp
a2fb3bc2 60 pushad
a2fb3bc3 52 push edx
a2fb3bc4 51 push ecx
a2fb3bc5 ff30 push dword ptr [eax]
a2fb3bc7 e80efeffff call lockDrv+0×49da (a2fb39da)
a2fb3bcc 83f800 cmp eax,0
a2fb3bcf 7407 je lockDrv+0×4bd8 (a2fb3bd8)
일단 2개의 비슷한 모양의 Stack이 CPU를 선점하고 있는것을 확인 할 수 있습니다. 일단 마지막 동작을 확인 하기 위해서 Trap Frame을 이용합니다. Register 값과 디스어셈코드를 보고 마지막 동작을 추정할 수 있습니다.
1: kd> kvn
# ChildEBP RetAddr Args to Child
00 a2ef6460 f75897fb 000000e2 00000000 00000000 nt!KeBugCheckEx+0×1b (FPO: [5,0,0])
01 a2ef647c f7589033 00f29d40 016498c6 00000000 i8042prt!I8xProcessCrashDump+0×237 (FPO: [3,0,0])
02 a2ef64c4 804dd90f 8a1496d0 89f29c88 01010009 i8042prt!I8042KeyboardInterruptService+0×21c (FPO: [Non-Fpo])
03 a2ef64c4 a2fc1154 8a1496d0 89f29c88 01010009 nt!KiInterruptDispatch+0×45 (FPO: [0,2] TrapFrame @ a2ef64e8)
WARNING: Stack unwind information not available. Following frames may be wrong.
04 a2ef65a4 a2fb05a9 8a12c720 89fbe4f8 8a12c720 lockDrv+0×12154
05 a2ef65c0 a2fb0731 8a12c238 00000001 88b62204 lockDrv+0×15a9
06 a2ef65f4 a2fb3aab 8a12c238 a468d12b 88b62204 lockDrv+0×1731
07 a2ef6628 a2fb3bcc a468d12b 8a12c238 88b62008 lockDrv+0×4aab
08 a2ef6680 a467e18f 88b62008 a2ef6734 88b62008 lockDrv+0×4bcc
09 a2ef66a4 a467e80e 88b62008 01b62204 88f2eb40 mfehidk+0×718f
0a a2ef673c a468c367 88f2eb40 88b62008 a2ef6774 mfehidk+0×780e
0b a2ef674c a468c3b7 a2ef675c 89f89220 893fe020 mfehidk+0×15367
0c a2ef6774 804e33eb 893fe020 88b62008 8a0b6470 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0×48
0d a2ef6784 a4623ace 88b62018 8a0b6470 00000000 nt!IopfCallDriver+0×31 (FPO: [0,0,0])
0e a2ef67e8 a4623f70 893b6020 88b62008 00000001 UDSecDrvXP+0×1ace
0f a2ef6804 804e33eb 893b6020 88b62008 88b62008 UDSecDrvXP+0×1f70
10 a2ef6814 8057dbed 8a30f8e8 8901958c a2ef69ac nt!IopfCallDriver+0×31 (FPO: [0,0,0])
11 a2ef68f4 8056f03b 8a30f900 00000000 890194e8 nt!IopParseDevice+0xa12 (FPO: [Non-Fpo])
12 a2ef696c 80572358 00000000 a2ef69ac 00000042 nt!ObpLookupObjectName+0×53c (FPO: [11,15,4])
13 a2ef69c0 8057e246 00000000 00000000 08a67001 nt!ObOpenObjectByName+0xea (FPO: [7,5,4])
1: kd> .trap a2ef64e8
ErrCode = 00000000
eax=00000001 ebx=1001829b ecx=00000001 edx=8a12c720 esi=a2fc729b edi=a2fc0e00
eip=a2fc1154 esp=a2ef655c ebp=a2ef65a4 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=55f8 es=0000 fs=71f0 gs=32fa efl=00000297
lockDrv+0×12154:
a2fc1154 75f7 jne lockDrv+0×1214d (a2fc114d) [br=1]
1: kd> ub lockDrv+0×12154
lockDrv+0×1213b:
a2fc113b 833e00 cmp dword ptr [esi],0
a2fc113e 75f2 jne lockDrv+0×12132 (a2fc1132)
a2fc1140 8b742424 mov esi,dword ptr [esp+24h]
a2fc1144 8bde mov ebx,esi
a2fc1146 03f0 add esi,eax
a2fc1148 b901000000 mov ecx,1
a2fc114d 33c0 xor eax,eax
a2fc114f f00fb14f30 lock cmpxchg dword ptr [edi+30h],ecx
1: kd> u lockDrv+0×12154
lockDrv+0×12154:
a2fc1154 75f7 jne lockDrv+0×1214d (a2fc114d)
a2fc1156 ac lods byte ptr [esi]
a2fc1157 6652 push dx
a2fc1159 b2e9 mov dl,0E9h
a2fc115b e9c90a0000 jmp lockDrv+0×12c29 (a2fc1c29)
a2fc1160 81e67b4fd45d and esi,5DD44F7Bh
a2fc1166 e9ad100000 jmp lockDrv+0×13218 (a2fc2218)
a2fc116b 660fb6c8 movzx cx,al
CPU를 선점함 코드를 보면 특정 조건이 맞지 않으면 무한 Loop로 빠지는 경우가 있다는것을 알 수 있습니다.
- eax 와 edi+30h가 동일한 값을 경우 루프를 빠져 나오고 edi+30h에 ecx를 넣어 준다.
- eax 와 edi+30h가 동일한 값이 아닐 경우 eax에 edi+30h의 값을 넣어주고 루프를 반복하여 돌게 된다. ( eax는 edi+30h의 값을 대입하지만 바로 위에서 다시 0으로 세팅함 )
그럼 각 Register및 메모리의 주소를 확인해 보면 진짜 무한 loop으로 빠져 있는지를 확인 할 수 있습니다.
lock cmpxchg를 수행 후의 Register와 메모리값을 확인하면 아래와 같이 정리가 되죠 .
- eax : 0×00000001
- edi+30h : 0×00000001
- EFlags : 0×00000297 ( Zero Flag : 0 )
여기서 몇가지 가능성을 추정해 볼 수 있습니다.
- Lock cmpxchg를 수행후 Register의 값을 통해( eax가 최초 0에서 edi+30h과 값이 다르기 때문에 eax에 edi+30h의 값이 들어가고 zero flag가 0으로 세팅된것임 ) CPU를 선점한 Thread는 특정 Flag가 0으로 세팅될 때 까지 지속적으로 루프를 수행하고 있음을 확인 할 수 있다.
- 만약 Flag가 최초 0이었다고 가정하면 최초에 위의 코드에 진입한 Thread가 Flag를 1로 변경하게 되므로 Flag를 1로 변경 후 그 이후 동작을 수행하고 있는 Thread가 존재 한다는 것을 알 수 있다.
- 위의 코드는 IofCallDriver를 후킹한 코드에서 수행 되므로 많은 수의 Thread가 위와 같은 형태의 대기 상태일 것이라는 것을 알 수 있다. ( 실재로 존재 하는데 너무 많아서 올리지 않음 )
- 위의 Flag ( edi+20h 값 )은 후킹 코드 상의 동기화를 위해서 사용된 동기화 Flag로 추정해 볼 수 있다.
그럼 이제 문제의 원인이라 할 수 있는 lockDrv+0×12154 이후 코드를 수행하는 Thread를 찾아 보면 될꺼 같습니다. 왜냐하면 이 녀석이 CPU를 다시 선점하여 완전히 로직을 수행해야 다른 녀석들도 무한 Loop에서 벗어 날 수 있기 때문입니다.
1: kd> !thread 88f09b98
THREAD 88f09b98 Cid 1200.1270 Teb: 7ff94000 Win32Thread: e31d5a48 READY
IRP List:
88b00008: (0006,0220) Flags: 00000884 Mdl: 00000000
Not impersonating
DeviceMap e10f0448
Owning Process 88fca020 Image: iexplore.exe
Attached Process N/A Image: N/A
Wait Start TickCount 50449 Ticks: 187 (0:00:00:02.921)
Context Switch Count 109392 LargeStack
UserTime 00:00:00.625
KernelTime 00:00:00.781
Win32 Start Address iertutil!CIsoScope::RegisterThread (0×3fa3407f)
Start Address kernel32!BaseThreadStartThunk (0×7c7e06f9)
Stack Init a343e000 Current a343d3e0 Base a343e000 Limit a3439000 Call 0
Priority 7 BasePriority 7 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
a343d3f4 80703f63 00000000 a343d4b8 80703106 nt!KiDispatchInterrupt+0xa7 (FPO: [Uses EBP] [0,0,3])
a343d400 80703106 00000000 000000e1 a343d4b8 hal!HalEndSystemInterrupt+0×57 (FPO: [2,2,0])
a343d400 a2fc59fc 00000000 000000e1 a343d4b8 hal!HalpIpiHandler+0xbe (FPO: [0,2] TrapFrame @ a343d410)
WARNING: Stack unwind information not available. Following frames may be wrong.
a343d4b8 a2fb05a9 8a12c720 89fbe4f8 8a12c720 lockDrv+0×169fc
a343d4d4 a2fb0731 8a12c238 00000001 00000000 lockDrv+0×15a9
a343d508 a2fb3aab 8a12c238 a467bdda 00000000 lockDrv+0×1731
a343d53c a2fb3bcc a467bdda 8a12c238 88fbb008 lockDrv+0×4aab
a343d618 a467c401 8a238a08 889da5a0 889da580 lockDrv+0×4bcc
a343d630 a463f444 a343d658 00000000 a343d6cc mfehidk+0×5401
.. 생략
lockDrv+0×12154 이후 실행 코드를 아래와 같이 살펴보면 88f09b98 Thread의 마지막 Stack에 위치한 코드는 lockDrv+0×12154 이후에 수행되는 코드임을 알 수 있습니다.. ( 코드가 가상화되어 수동으로 순서를 조합한 것임 )
lockDrv+0×12156:
a2fc1156 ac lods byte ptr [esi]
a2fc1157 6652 push dx
a2fc1159 b2e9 mov dl,0E9h
a2fc115b e9c90a0000 jmp lockDrv+0×12c29 (a2fc1c29)
lockDrv+0×12c29:
a2fc1c29 28d0 sub al,dl
a2fc1c2b 665a pop dx
a2fc1c2d 00d8 add al,bl
a2fc1c2f 52 push edx
a2fc1c30 b6e1 mov dh,0E1h
a2fc1c32 f6de neg dh
a2fc1c34 80f653 xor dh,53h
a2fc1c37 c0ee07 shr dh,7
a2fc1c3a 6800000000 push 0
a2fc1c3f 283424 sub byte ptr [esp],dh
a2fc1c42 e90d310000 jmp lockDrv+0×15d54 (a2fc4d54)
lockDrv+0×15d54:
a2fc4d54 8a3424 mov dh,byte ptr [esp]
a2fc4d57 83c404 add esp,4
a2fc4d5a 80f6e9 xor dh,0E9h
a2fc4d5d 00f0 add al,dh
a2fc4d5f 5a pop edx
a2fc4d60 51 push ecx
a2fc4d61 52 push edx
a2fc4d62 b6f6 mov dh,0F6h
a2fc4d64 80f65a xor dh,5Ah
a2fc4d67 0f897a010000 jns lockDrv+0×15ee7 (a2fc4ee7))
lockDrv+0×15d6d:
a2fc4d6d fec6 inc dh
a2fc4d6f e94fd6ffff jmp lockDrv+0×133c3 (a2fc23c3)
lockDrv+0×133c3:
a2fc23c3 80e68e and dh,8Eh
a2fc23c6 0f82033f0000 jb lockDrv+0×172cf (a2fc62cf)
lockDrv+0×133cc:
a2fc23cc 80c6f6 add dh,0F6h
a2fc23cf 53 push ebx
a2fc23d0 e917360000 jmp lockDrv+0×169ec (a2fc59ec)
lockDrv+0×169ec:
a2fc59ec b7d7 mov bh,0D7h
a2fc59ee fecf dec bh
a2fc59f0 e9f3c0ffff jmp lockDrv+0×12ae8 (a2fc1ae8)
lockDrv+0×12ae8:
a2fc1ae8 fecf dec bh
a2fc1aea f6df neg bh
a2fc1aec 80efdb sub bh,0DBh
a2fc1aef e9063f0000 jmp lockDrv+0×169fa (a2fc59fa)
lockDrv+0×169fa:
a2fc59fa 00fe add dh,bh
a2fc59fc 5b pop ebx
a2fc59fd 88f5 mov ch,dh
a2fc59ff 5a pop edx
a2fc5a00 30e8 xor al,ch
a2fc5a02 e9d5000000 jmp lockDrv+0×16adc (a2fc5adc)
lockDrv+0×16adc: <== 현재 실행 중이 었던 블록
a2fc5adc 8b0c24 mov ecx,dword ptr [esp]
a2fc5adf 81c404000000 add esp,4
a2fc5ae5 52 push edx
a2fc5ae6 89e2 mov edx,esp
a2fc5ae8 81c204000000 add edx,4
a2fc5aee e962cdffff jmp lockDrv+0×13855 (a2fc2855)
이제 이 문제의 결론이 어느 정도 보이죠 .
즉 Thread 88f09b98 가 동기화 Flag를 1로 바꾼 상태이며 Flag를 원복 하지 않은 상태에서 CPU상의 테스크가 변경되어 다른 Thread는 무한 Loop를 돌게 된 것으로 볼 수 있다. 실제 Flag를 선점한 Thread는 Priority가 낮기 때문에 다음 CPU 선점까지의 시간이 지연되어 PC의 Lock 현상이 발생하는 것으로 보입니다.
그럼 시나리오 정리를 하면 .
- Priority가 낮은 Thread가 동기화 Flag를 1로 변경 후 원복하지 않은 상태에서 테스크 스위칭이 발생
- 추후 CPU를 선점한 Thread가 같은 Flag를 통해서 동기화를 이루고 있는 Hooking 로직이면 Lock 현상이 발생
- 이 후 다시 Flag를 1로 변경한 Thread가 CPU를 선점하여 Flag를 0으로 변경하면 Lcok 현상이 사라짐
그럼 이제 그 동기화 부분을 찾아서 수정할 방법을 고민해 보면 될꺼 같습니다. 머 Kernel Level에서 사용되는 동기화 Object를 사용하는 방법을 쓰면 좋을꺼 같내요.
Enjoy Debugging
머리가 예전 같지 않아 잘 안돌아 가는거 같습니다. 한 2달 쉬었더니 완전 굳어버린거 같다는 생각이 ..
간혼 !running -i -t를 통해서 강제 덤프를 열어 보면 실제 CPU를 선점하고 있는 놈을 찾을 때가 있습니다. 꽤나 유용하죠 . ( 보통은 idle이 선점을 하고 있다는 .. ^^ ) 근데 2개의 CPU 모두를 선점하는 process가 나오는 경우도 있군요.대략 희귀한 경우라 올려보니다.
근데 이넘은 어떻게 분석해야할까요 ??
제약 사항
1. 심볼 없음
2. Pack 되어 있는 부분( Virtualize )이 있어서 리버싱이 오래걸림
이럴때는 그냥 웃지요 …ㅎㅎㅎ
낼은 덤프를 여러개 떠서 좀더 다양하게 확인해 봐야겠내요 ..
1: kd> !running -i -t
System Processors 3 (affinity mask)
Idle Processors 0
Prcbs Current Next
0 ffdff120 88a2c4e8 …………….
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
b4845478 b34a05a9 xxxx+0×1214d
b4845494 b34a0731 xxxx+0×15a9
b48454c8 b34a3aab xxxx+0×1731
b48454fc b34a3bcc xxxx+0×4aab
b4845590 b466df70 xxxx+0×4bcc
b48455ac 804e33eb UDSecDrvXP+0×1f70
b48455bc b468d22e nt!IopfCallDriver+0×31
b4845608 b468f6f1 mfehidk+0×522e
b484569c b469d367 mfehidk+0×76f1
b48456ac b469d3b7 mfehidk+0×15367
b48456d4 804e33eb mfehidk!DEVICEDISPATCH::DispatchPassThrough+0×48
b48456e4 8057dbed nt!IopfCallDriver+0×31
b48457c4 8056f03b nt!IopParseDevice+0xa12
b484583c 80572358 nt!ObpLookupObjectName+0×53c
b4845890 8057e246 nt!ObOpenObjectByName+0xea
b484590c 80586cc8 nt!IopCreateFile+0×407
b4845954 b4692e3a nt!IoCreateFileSpecifyDeviceObjectHint+0×52
b48459f0 b4692a72 mfehidk+0xae3a
b4845a48 b4637046 mfehidk+0xaa72
b4845a98 b463785e mfeavfk+0×4046
1 f771f120 88aebda8 …………….
ChildEBP RetAddr
b4941334 ba7127fb nt!KeBugCheckEx+0×1b
b4941350 ba712033 i8042prt!I8xProcessCrashDump+0×237
b4941398 804dd90f i8042prt!I8042KeyboardInterruptService+0×21c
b4941398 b34b1154 nt!KiInterruptDispatch+0×45
WARNING: Stack unwind information not available. Following frames may be wrong.
b4941478 b34a05a9 xxxx+0×12154
b4941494 b34a0731 xxxx+0×15a9
b49414c8 b34a3aab xxxx+0×1731
b49414fc b34a3bcc xxxx+0×4aab
b4941590 b466df70 xxxx+0×4bcc
b49415ac 804e33eb UDSecDrvXP+0×1f70
b49415bc b468d22e nt!IopfCallDriver+0×31
b4941608 b468f6f1 mfehidk+0×522e
b494169c b469d367 mfehidk+0×76f1
b49416ac b469d3b7 mfehidk+0×15367
b49416d4 804e33eb mfehidk!DEVICEDISPATCH::DispatchPassThrough+0×48
b49416e4 8057dbed nt!IopfCallDriver+0×31
b49417c4 8056f03b nt!IopParseDevice+0xa12
b494183c 80572358 nt!ObpLookupObjectName+0×53c
b4941890 8057e246 nt!ObOpenObjectByName+0xea
b494190c 80586cc8 nt!IopCreateFile+0×407
1: kd> u iofcalldriver
nt!IofCallDriver:
804e33b9 ff2580d75580 jmp dword ptr [nt!pIofCallDriver (8055d780)]
804e33bf 90 nop
804e33c0 90 nop
804e33c1 90 nop
804e33c2 90 nop
804e33c3 90 nop
nt!IopfCallDriver:
804e33c4 fe4a23 dec byte ptr [edx+23h]
804e33c7 8a4223 mov al,byte ptr [edx+23h]
1: kd> dd 8055d780
8055d780 b34a3bc0 804e37da 804ecd58 804eceb1
8055d790 00000000 00000000 00000000 00000000
8055d7a0 00000000 00000000 00000000 00000000
8055d7b0 00000000 00000000 00000000 00000000
8055d7c0 00000000 00000000 00000000 00000000
8055d7d0 00000000 00000000 00000000 00000000
8055d7e0 00000000 00000000 00000000 00000000
8055d7f0 00000000 00000000 00000000 00000000
1: kd> u b34a3bc0
xxxx+0×4bc0:
b34a3bc0 8bc4 mov eax,esp
b34a3bc2 60 pushad
b34a3bc3 52 push edx
b34a3bc4 51 push ecx
b34a3bc5 ff30 push dword ptr [eax]
b34a3bc7 e80efeffff call xxxx+0×49da (b34a39da)
b34a3bcc 83f800 cmp eax,0
b34a3bcf 7407 je xxxx+0×4bd8 (b34a3bd8)
원래 이러한 잡다한 글을 쓰지는 않습니다만 오늘은 몇자 적고 싶어지더군요. 얼마전 까지 저는 이름만 대면 알만한 회사에서 보안 제품을 개발했었습니다. ( 물론 개발하던 제품중 키보드 보안도 있습니다. ) 한동안 잠잠했었는데 최근 들어 다시 인증서와 아이폰, 키보드 보안 얘기 들이 나오고 있더군요. 글을 읽다보니 참 어이 없기도 하고 왜들 저렇게 서로를 못잡아 먹어서 그럴까 하는 생각도 듭니다.
1. 인증서에 대해서..
개인적으로 인터넷 뱅킹을 주로 인터넷으로 물건 살때만 사용하지만 굉장히 편리하게 잘사용하고 있습니다. 인증서와 보안 카드만 잘 관리하면 보안상으로 없는거 보다는 낳다고 생각합니다. 오픈웹쪽의 글을 읽다보면 기존 방식은 어떠 어떠해서 나쁘다 , 안전하지 않다는 얘기들이 많이 있습니다. 그리고 결론은 항상 플러그인 ( ActiveX )를 판매하기 위한 상술이다로 끝나더군요. (” 보안개발자 + 기관 담당자 + 금감원 == 바보” 라는 결론을 내니 참 어이 없습니다. ) 오픈웹에서 주장하고 있는 내용들을 보면 정말 재미 있습니다. 사실 개인적으로 몇가지 문구가 맘에 안드는건 사실입니다.
http://openweb.or.kr/?p=2284
” 서버가 악의적이면, 가입자 개인키는 물론 가입자의 컴퓨터까지 장악할 수 있음(플러그인을 통하여) “
기존 방식이 어떻게 가입자 컴퓨터를 장악하는지 모르겠습니다. 일단 조금 말도 안된다는 생각이 듭니다. 가령 인터넷 뱅킹할때 악성코드 설치하시는분 계시면 리플 부탁드립니다.( 은행 보안 담당자 분들은 은행 페이지를 통해서 악성코드를 배포한다는 건가요 ?? ) . 오픈웹 주장대로라면 저는 지금까지 악성코드 개발을 위해서 20대를 바쳐서 일했던거 같습니다.
http://openweb.or.kr/?p=2284
“SSL 서버인증서 시장은 거의 형성되지 않음(외국 인증기업의 국내 진입 봉쇄) “
어떤 인증 방법을 사용하던지 상관없지 않을까 하는 생각이 듭니다. 오픈웹에서 지금까지 계속 주장한 “선택의 자유”.. 근데 반드시 SSL서버 인증서를 써야하는것 처럼 보이는군요.
http://openweb.or.kr/?p=2284
“플러그인을 설치해야 하므로 user들에게 보안경고창이 뜨면 “반드시 예를 누르라”고 안내할 수밖에 없음.”
“전반적으로 위험한 인터넷 환경 조성 “
몇몇 글들을 보면 사용자는 바보가 아니다라고 주장하고 있는 글들이 있습니다.
http://openweb.or.kr/?p=2500 ( 한국 이용자가 유독 저능아라고 전제할 근거는 없다. )
사용자는 바보가 아닙니다. 당연한 얘기 입니다. 그렇기에 사용자도 플러그인을 보고 확인해서 설치할 수 있습니다. 보안 프로그램인지 아닌지.. 그 정도는 누구나 확인이 가능하죠. 아래 글을 보면 사용자는 바보가 아니라고 합니다.
최소한 파폭이나 사파리를 사용하는 정도가 되면 누구나 그정도는 분별합니다.
정말 오픈웹의 기술이 그렇게 뛰어나고 멋진기술이라면 구지 제약이 많은 우리나라 보다는 세계속에서 우뚝서는게 어떨까하는 생각이 듭니다. 하다 못해 일본만 하더라도 은행권에서 보안 소프트웨어를 채택하는데 우리나라와 같은 제한은 없습니다. 오픈웹에서 진행하는 일들이 우리나라와 맞지 않으면 세계를 평정하고 기술의우월함을 보여주면 될것이라 생각됩니다. 똑똑한 교수님들도 많으니 언어가 장벽이 되서 다른나라에 기술을 소개 못할꺼라 생각이 되지는 않습니다.
“오픈웹도 말로만 좋은 기술이라고 떠들지 말고 다른 보안 업체들 처럼 제품과 기술로 승부해서 고객으로 부터 높은 평가를 얻었으면합니다.”
2. “보안”에 대한 생각… 그리고 오픈웹
보안은 무엇인가를 지키는 것입니다. 하지만 최근 인터넷에 떠덜고 있는 글들을 보면 ‘보안’이라는 큰 명제 보다는 편가르기에 바쁘다는 생각이 많이 듭니다. 이제 그만 편가르기 하고 각자 생각하는 방법으로 고객에서 어필하면 될꺼라 생각하는데 그게 그리 쉽지않은거 같습니다. 오픈웹에 올라오는 글들 볼때마다 화가 납니다. ( 예전 회사에서는 더 심했습니다. ) 좋은 기술을 가졌으면 좀더 효과적인 방법으로 어필이 가능할꺼라 생각하는데 구지 말빨만 세워서 항상 고생하고 계시는 보안 개발자들 가슴에 대못을 박을 필요가 있을까요 ??
“비교 분석 보다는 장점을 좀더 보여주고 실제 적용 사례를 보여주면 더 좋을꺼 같은데…”
왜 그렇게 하지 않는지 모르겠습니다.
보안 개발일을 한지 이제 4년차쯤 됩니다 . (그전에는 하드웨어 드라이버 개발하는 땜쟁이 였습니다. ) 나름 보안 개발자로서 자부심도 있고 가능성도 많은 분야라고 생각합니다. 무엇보다 보안 분야는 자유롭게 생각할 수 있다는 점이 가장 매력적입니다.
똑똑한 교수님들 덕분에 여론 몰이로 지금 시작하는 보안개발자 분들이 한가지 생각만 강요 받지 않았으면 합니다.
똑똑한 교수님들 덕분에 좋은 개발자 분들이 되도 않는 여론 몰이에 욕바가지로 먹고 보안 바닦 띄지 않았으면 좋겠습니다.
“보안은 과정입니다. 좀더 좋은 해결책을 가지고 안전한 IT 환경을 만들어 가는 과정입니다.”
과정이기 때문에 조금 어설플 수도 있고 조금 부족할 수도 있는겁니다. “좋다 나쁘다”의 개념이 아니라 “조금 부족하다 조금 덜 부족하다”의 개념이라 생각합니다. 그리고 실제 제품의 판단은 고객이 해줄꺼라 생각합니다. 오픈웹 주장도 맞고 키사나 금감원 주장도 맞다고 생각합니다. 실제 보안성은 시장에서 확인되는거니까 알 수 는 없습니다. 전혀 취약해 보이지 않아도 해커들 눈에는 취약점 덩어리일 수도 있으니까 .
두서없는 글을 나름 업무시간에 땡땡히 치면서 열라게 썼습니다. 오픈웹 글을 보고 조금 화가 난것도 사실입니다.
제발 이제 그만 하고 제품으로 보여주십시요!! 그래서 세계에서 가장 좋은 보안 제품이라는 평을 들었으면 좋겠습니다.!!
ps 제가 글쟁이가 아니라서 글을 잘 못씁니다. 본의 아니게 이글로 오해를 하시는 분들이 있으시면 리플달아 주십시요.
의외로 간단합니다.
일단 http://feedburner.google.com 에 접속해서 Blog Feed를 등록합니다.
등록 절차는 굉장히 간단합니다. 자신의 Blog의 Feed를 복사해서 Next만 눌러주면 됩니다.
일단 설정이 완료 되면 실제 Twitter와 연결을 해주어야 합니다.
Publicize > Socialize 텝으로 가시면 Twitter와 연결이 가능합니다. 여기서 반드시 해주어야하는 건 Twitter Account를 Add해줘야 한다는 거죠.
아래 옵션들은 Twitter에서 어떻게 보여줄지를 결정하는건데요. 자기의 취향에 맞게 결정하시면 됩니다.
모든 설정이 완료 되시면 이제 Blog에서 올라온 글들 이제 트위터에서 확인해 보시면 됩니다.
최근 답글