2014年8月26日 星期二

SEH和VEH







先说结论吧:
VEH可以在修复问题后继续执行产生异常的代码 ,SEH不行
SEH比起VEH更方便简洁直观因为VEH一旦注册handler,任何位置的任何异常都会走到handler里。
VEH比SEH触发更早,VEH如果将问题处理完毕,可以阻止SEH的触发,如果VEH认为问题没法处理好也可以继续触发SEH。
VEH可以拿来做很多事,比如说内存修改器之类的

下面是两组实验代码:

int *pb = 0;

LONG CALLBACK VectoredHandler(
    _In_  PEXCEPTION_POINTERS ExceptionInfo
    )
{
    *pb = 1;//b = 1
   
    printf("veh\n");
    return EXCEPTION_CONTINUE_EXECUTION;
    return EXCEPTION_CONTINUE_SEARCH;
}

int _tmain(int argc, _TCHAR* argv[])
{
    AddVectoredExceptionHandler(1, VectoredHandler);
    __try
    {
        int b = 0;
        pb = &b;
        printf("before\n");
        int a = 1 / b;//exception
        printf("after\n");
    }
    __except (1)
    {
        printf("seh");
    }
    getchar();
    return 0;
}

-----------------------------------------------------------------------------------

DWORD offset_of_b = 0;

LONG CALLBACK VectoredHandler(
    _In_  PEXCEPTION_POINTERS ExceptionInfo
    )
{
    *(int*)(ExceptionInfo->ContextRecord->Ebp + offset_of_b) = 1;//b = 1
   
    printf("veh\n");
    return EXCEPTION_CONTINUE_EXECUTION;
    return EXCEPTION_CONTINUE_SEARCH;
}

int _tmain(int argc, _TCHAR* argv[])
{
    AddVectoredExceptionHandler(1, VectoredHandler);
    __try
    {
        int b = 0;
        offset_of_b = (DWORD)&b;
        __asm{
            sub offset_of_b,ebp
        }
        printf("before\n");
        int a = 1 / b;
        printf("after\n");
    }
    __except (1)
    {
        printf("seh");
    }
    getchar();
    return 0;
}

2014年8月20日 星期三

.net保护思路

本文是我从零开始学习.net保护一周多得出的结论,中间断续穿插了一些别的任务。
公司的.net壳已经做到了按方法加密的程度,如果想再提升,可以从两个方向着手:

1. 加强代码乱序、混淆
2. 按照DNGuard的思路搞

其实还有一点,就是修复反射漏洞,不过我不确定公司的壳有没有这个漏洞而且这也用不上啥大动作姑且不列。两个方向中第一个方向俺没有研究,第二个方向由于DNGuard的作者很大方说的挺清楚,所以比较明朗,这里简单说一下。
简单来讲,现在稍微好点.net壳和脱壳都走到了JIT层,普通的壳无非就是hook的更深然后检查一些其它hook点是不是被脱壳机搞过了,脱壳机也就是选择更深层的hook点截获JIT层编译的il代码并逃避或破坏壳的检测(反射漏洞又是另一条路,操作简单也比较好防,先放放),总的来讲还是脱壳方占优,公司的壳就在这个层次的初级(目测)。
还有一种路线是整体保护,类似飞信的vm,优点是自己做了.net framework该完成的事情,运行程序不再需要.net framework,所有JIT层的手段都失效了,结合成熟的PE保护方案可以保护的很好。同时缺点很多:

1. 程序的发行拖家带口带上了一整套运行环境必然会大幅度增加发行体积。
2. 被保护方可以使用的功能是有限的,兼容性还不好(就连mono都没把功能搞全)
3. 以我们公司现在的水平,就算抄monollvm,性能估计也达不到.net framework的水平。

其中12点对于公司的产品来讲是硬伤,所以我比较倾向于结合两条保护路线的DNGurad思路。
DNGuard的思路就是.net framework做的事情我包揽一部分。比如说我替换的伪il代码我来JIT编译,正常的il代码交给.net frameworkJIT编译。DNG的另一个独特功能也是这种部分包揽的思路。利用这样的思路DNG对两种保护取长补短,达到了强度、性能与兼容性的平衡,而且实现起来可参考的东西还很多比较可行,是我比较倾向的公司.net壳升级方向。

2014年8月6日 星期三

最近boss给俺安排的任务越来越杂了

前一阵子俺还在折腾Hook,然后穿插着给一些C#代码找错,后来让俺学.net程序加壳,然后是看看某个C#程序调用C++dll为啥出错,今天俺又在修改一个COM组件使之可以被PHP调用,我还顺便搭了个PHP开发环境,用上了久违的eclipse……
好在上述内容除了壳之外都还算常规开发的范畴内(hook在常规开发也不难看到),俺也不在乎多掌握一些编程语言和扩展组件开发方式,我比较赞成程序员不应在一个语言或者平台中固步自封的观点,接触这些可以拓宽我在程序设计与编写时的视野,这有助于俺能力的提升。
不过俺还是比较抵触壳这东西的,我确实希望有朝一日可以成为比优秀更好的安全方面的开发人员,同时,如果可能我希望我的能力并不局限于安全方面。壳这东西对我来说,一方面兴趣不大,另一方面太过偏门。如果只是短暂的接触,我会有机会思考如何解决这样一个问题,如何去设计代码,同时更加了解某些语言的底层机制,这会给我带来收获。但是如果是长期身陷其中,我不希望是这个领域。
这对于我之前所说的杂乱的‘常规开发’也是有效,短暂的接触可以拓宽视野,深入学习就要选择好方向了。俺希望在一方面深入钻研同时在其他方面拓宽视野,毕竟我不可能精通所有方面。
或许我应该趁年轻再更多的接触一些其他领域,或许当初刚毕业时我因为工作方向的不确定性拒绝了那份薪水不错的offer并不是非常正确。不过,我并没有那么多时间,在我某一个人生目标达成之前我并不打算结婚,而且我也不打算太晚结婚,所以时间就有些紧了。我已经在某事业单位浪费了毕业后的第一年,我不想继续浪费下去了……
等等,写到这里我发现我已经跑离最初写这篇博文的想法很远了,最初只是想发几句牢骚来着……
越说越乱,我捋一下,这是我真实的想法:我希望能掌握一个技能达到在某环境找工作不愁的程度,然后去到这个环境普通的工作,普通的结婚,然后度过我普通的一生。这也是我真实的想法:我希望有朝一日可以成为比优秀更好的(安全方面的研究人员||编程人员)。我的两个人生目标正在互相影响着,并产生了一定的冲突,这让我略有急躁,我不知道如何才能很好的解决这个冲突,以至于我正在通过写博客的方式来发泄这份情绪……
好吧,我明白自己是怎么回事了,写博文这办法有点效果,效果不太大,今天就到这吧,先洗洗睡了……