克莱's profile克莱沃曼PhotosBlogListsMore Tools Help

Blog


    October 21

    步入安全测试(兼谈个人测试技术发展轨迹)

    进入测试领域已经满四年了,最近感觉自己可能有点里程碑似的改变了,因此回顾一下四年的测试技术发展轨迹供大家分享。

    有个网友说的很好,从测试的难度上来讲应该是自动化测试<性能测试<安全测试。我从来都是忽略性能测试的,原因也很简单,因为我基本没有从事过跟性能测试相关的工作,谈不上什么理解与感受。但是,我还是能感觉到性能测试的难度确实要大于自动化测试。一两年前还在热烈地跟大家讨论自动化测试的重要性,如何自动化测试等等,现在已经觉得没什么意思了。手工测试,自动化测试,黑盒测试,白盒测试,等等不过都是一种种测试方法而已,我们的目标很简单,就是要发现bug。而在发现bug的过程中,你是不可避免的要用到任何可能的测试方法和测试工具,包括自己编写测试工具。单纯地讨论他们孰优孰劣,哪个更高级并没有根本的意义。下面回顾一下自己的四年测试发展路径。

    • 第一个半年忙于手工黑盒测试 (很枯燥)
    • 第二个半年开始考虑自动化测试 (很迷惘和无奈)
    • 一年之后有一些自动化的ideas, 学习C#, .NET, TestComplete 等等,把自己设计的自动化平台实现 (自己对自动化有一些自己的理解和实践)
    • 一年半之后在以前的基础之上开始寻找更高端的测试职位,实际就是寻找专门的自动化测试的职位 (选择面很小,适合自己的也没几家公司,尤其是在国内,被迫出国发展)
    • 将近两年的时候如愿以偿,入职自动化测试的职位 (开始把自己对自动化的理解和新的公司和同事交流,发现还是match的)
    • 入职之后的一年内,也就是进入测试的第三年,在自动化测试方面有了大量的工作经验 (觉得自动化测试还是比较简单的工作)
    • 进入测试的第四年开始按照老板的要求进行debugging 和 code review 的工作 (在自己的feature上做到了测试支柱)
    • 四年之后也就是现在忽然发现自己有了比较大的进步,把以前零零散散的东西都能够联系起来了,感觉自己真正的走入了right path。最近一两个月的提升好像顶以前半年的,debugging技术已经比较熟练,code review也觉得比较轻松,并且在debuging和code review的过程中任何不明白的东西都会尽力去搞明白,这样在C语言,Win32,Windows Kernal,汇编,编译,还有Security方面都有了一个突然提升,在脑海里这些东西变得立体起来。也是最近才明白为什么以前director给我的建议是“短期学好C语言,长期也是学好C语言了”。

    以前也曾经hack过一个网站,并且在与那个网站的developer的较量中明显占据了上风。以前也曾经发现过security的bug,但是基本属于瞎猫碰倒死耗子的情况。周六晚上突然有点idea,由于太晚就没有回公司。周日早上5点多睡醒脸也没洗就去了公司,一直工作到12点多,file上了bug。其实大概工作了一两个小时就攻击成功,可以远程把一个server crash掉。但是为了弄明白里边的一些情况以及这个漏洞的范围和黑客攻击的难易程度,又花了大量的时间。

    终于有了一些安全测试的感觉了,而回想起来也完全是由于前几年测试工作中知识,技术和经验的积累所成就的。以前一直觉得没有多年开发经验的不太可能做到安全测试,现在自己证明也未必,虽然确实不容易。最近两年由于英文的障碍使得自己的发展慢了不少,虽然也是average的速度,有些遗憾。更大的遗憾在于我30岁之前浪费了太多的光阴了,不说大学之前,就是大学之后到30岁的这段工作时间也基本上是浪费,没有真正地去深入过任何领域。30岁之后才寻找到了自己正确的道路,是有些悲哀,但总比没有找到强。我知道很多测试同行都像我以前那样迷惑,迷惘。希望大家在黄金年龄的朋友不要让青春太快的流走,抓紧时间去寻找自己的道路吧。

    October 15

    Kernel stack not resident (Using .pagein)

    You might find yourself debugging an issue and a thread you are interested in is paged out.  Here's the steps to use to page in the stack for the kernel side and user side...   Be careful when doing this on a live machine that you want to release after debugging as paging in certain section of memory can cause it to bugcheck... 

    2: kd> !thread fffffa8004415460
    THREAD fffffa8004415460  Cid 087c.0acc  Teb: 000007fffffd5000 Win32Thread: 0000000000000000 WAIT: (WrLpcReply) UserMode Non-Alertable
        fffffa80044157f0  Semaphore Limit 0x1
    Waiting for reply to ALPC Message fffff88018c943f0
    Impersonation token:  fffff8801d302060 (Level Impersonation)
    Owning Process            fffffa80046e5610       Image:         snmp.exe
    Wait Start TickCount      367059906      Ticks: 15906005 (2:20:55:35.268) //Been waiting a while.
    Context Switch Count      13819416
    UserTime                  00:00:38.173
    KernelTime                00:02:33.972
    Win32 Start Address 0x000007fefa7724bc
    Stack Init fffffa600440ddb0 Current fffffa600440d6e0
    Base fffffa600440e000 Limit fffffa6004408000 Call 0
    Priority 11 BasePriority 8 PriorityDecrement 1 IoPriority 2 PagePriority 5
    Kernel stack not resident. // We can't see what the stack looks like as it been waiting so long its been paged out.

    2: kd> .pagein fffffa600440d6e0  //Grab Current from above...  This will get us the kernel side...
    You need to continue execution (press 'g' <enter>) for the pagein to be brought in.  When the debugger breaks in again, the page will be present.
    2: kd> g
    Break instruction exception - code 80000003 (first chance)
    nt!DbgBreakPointWithStatus:
    fffff800`0163e1d0 cc              int     3
    1: kd> !thread fffffa8004415460
    THREAD fffffa8004415460  Cid 087c.0acc  Teb: 000007fffffd5000 Win32Thread: 0000000000000000 WAIT: (WrLpcReply) UserMode Non-Alertable
        fffffa80044157f0  Semaphore Limit 0x1
    Waiting for reply to ALPC Message fffff88018c943f0
    Impersonation token:  fffff8801d302060 (Level Impersonation)
    Owning Process            fffffa80046e5610       Image:         snmp.exe
    Wait Start TickCount      367059906      Ticks: 15906070 (2:20:55:36.282)
    Context Switch Count      13819416
    UserTime                  00:00:38.173
    KernelTime                00:02:33.972
    Win32 Start Address 0x000007fefa7724bc
    Stack Init fffffa600440ddb0 Current fffffa600440d6e0
    Base fffffa600440e000 Limit fffffa6004408000 Call 0
    Priority 11 BasePriority 8 PriorityDecrement 1 IoPriority 2 PagePriority 5
    Kernel stack not resident.
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    fffffa60`0440d720 fffff800`01647abe : fffffa60`0440da88 fffff880`18c943f0 fffffa60`0440da88 fffff880`18c943f0 : nt!KiSwapContext+0x7f
    fffffa60`0440d860 fffff800`016484c5 : 00000000`00303cb0 fffffa60`0440da88 00000000`00000009 00000000`00000001 : nt!KiSwapThread+0x12e
    fffffa60`0440d8c0 fffff800`01681067 : 00000000`00000000 00000000`00000011 00000000`00000001 00000000`00000000 : nt!KeWaitForSingleObject+0x5f5
    fffffa60`0440d940 fffff800`018be424 : fffffa60`0440da88 00000000`00303cb0 fffffa80`04415460 00000000`00000000 : nt!AlpcpSignalAndWait+0x97
    fffffa60`0440d980 fffff800`018be868 : 00000000`00000000 00000000`00000000 00000000`00303cb0 00000000`00300318 : nt!AlpcpReceiveSynchronousReply+0x44
    fffffa60`0440d9e0 fffff800`018a834f : fffffa80`04352e60 fffffa80`00020000 00000000`00303cb0 00000000`00300318 : nt!AlpcpProcessSynchronousRequest+0x251
    fffffa60`0440db00 fffff800`016437b3 : fffffa80`04415460 fffffa60`0440dca0 00000000`00000280 fffff800`0189c654 : nt!NtAlpcSendWaitReceivePort+0x19f
    fffffa60`0440dbb0 00000000`77af4dca : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffffa60`0440dc20)
    00000000`016aebc8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77af4dca

    1: kd> .pagein /p fffffa80046e5610 00000000`016aebc8 //We take the process ID of the thread and the usermode address at the bottom of the stack.
    You need to continue execution (press 'g' <enter>) for the pagein to be brought in.  When the debugger breaks in again, the page will be present.
    1: kd> g
    Break instruction exception - code 80000003 (first chance)
    nt!DbgBreakPointWithStatus:
    fffff800`0163e1d0 cc              int     3
    1: kd> !thread fffffa8004415460 //Viola!  Now we have the whole stack, you might need to do a .reload for symbols.
    THREAD fffffa8004415460  Cid 087c.0acc  Teb: 000007fffffd5000 Win32Thread: 0000000000000000 WAIT: (WrLpcReply) UserMode Non-Alertable
        fffffa80044157f0  Semaphore Limit 0x1
    Waiting for reply to ALPC Message fffff88018c943f0
    Impersonation token:  fffff8801d302060 (Level Impersonation)
    Owning Process            fffffa80046e5610       Image:         snmp.exe
    Wait Start TickCount      367059906      Ticks: 15906135 (2:20:55:37.296)
    Context Switch Count      13819416
    UserTime                  00:00:38.173
    KernelTime                00:02:33.972
    Win32 Start Address 0x000007fefa7724bc
    Stack Init fffffa600440ddb0 Current fffffa600440d6e0
    Base fffffa600440e000 Limit fffffa6004408000 Call 0
    Priority 11 BasePriority 8 PriorityDecrement 1 IoPriority 2 PagePriority 5
    Kernel stack not resident.
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    fffffa60`0440d720 fffff800`01647abe : fffffa60`0440da88 fffff880`18c943f0 fffffa60`0440da88 fffff880`18c943f0 : nt!KiSwapContext+0x7f
    fffffa60`0440d860 fffff800`016484c5 : 00000000`00303cb0 fffffa60`0440da88 00000000`00000009 00000000`00000001 : nt!KiSwapThread+0x12e
    fffffa60`0440d8c0 fffff800`01681067 : 00000000`00000000 00000000`00000011 00000000`00000001 00000000`00000000 : nt!KeWaitForSingleObject+0x5f5
    fffffa60`0440d940 fffff800`018be424 : fffffa60`0440da88 00000000`00303cb0 fffffa80`04415460 00000000`00000000 : nt!AlpcpSignalAndWait+0x97
    fffffa60`0440d980 fffff800`018be868 : 00000000`00000000 00000000`00000000 00000000`00303cb0 00000000`00300318 : nt!AlpcpReceiveSynchronousReply+0x44
    fffffa60`0440d9e0 fffff800`018a834f : fffffa80`04352e60 fffffa80`00020000 00000000`00303cb0 00000000`00300318 : nt!AlpcpProcessSynchronousRequest+0x251
    fffffa60`0440db00 fffff800`016437b3 : fffffa80`04415460 fffffa60`0440dca0 00000000`00000280 fffff800`0189c654 : nt!NtAlpcSendWaitReceivePort+0x19f
    fffffa60`0440dbb0 00000000`77af4dca : 000007fe`fea5c72b 00000000`00001000 00000000`016aee90 00000000`01460058 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffffa60`0440dc20)
    00000000`016aebc8 000007fe`fea5c72b : 00000000`00001000 00000000`016aee90 00000000`01460058 00000000`0030ed80 : ntdll!NtAlpcSendWaitReceivePort+0xa
    00000000`016aebd0 000007fe`fea6c592 : 00000000`00302b50 00000000`016aef30 000007fe`fe95c8b8 00000000`00001000 : RPCRT4!LRPC_CCALL::SendReceive+0xbb
    00000000`016aec50 000007fe`fea6c5e2 : 00000000`016aed00 00000000`00000000 00000000`00000000 00000000`01460058 : RPCRT4!I_RpcSendReceive+0x42
    00000000`016aec80 000007fe`feafad2c : 00000000`016aef30 00000000`00000000 00000000`00000000 00000000`0030ed80 : RPCRT4!NdrSendReceive+0x32
    00000000`016aecb0 000007fe`feafaef0 : 00000000`00000000 000007fe`fe95d090 00000000`00000011 00000000`016aece0 : RPCRT4!NdrpClientCall3+0x11c
    00000000`016aef00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : RPCRT4!NdrClientCall3+0x7c

    1: kd>

    From http://blogs.technet.com/brad_rutkowski/archive/2007/08/30/kernel-stack-not-resident-using-pagein.aspx