-
-
[Anti Virus专题]1.2 - 2.kernel32基地址获得
-
发表于: 2009-4-10 15:09
-
|
|
|---|---|
|
|
 其实我主要并不是在强调这个“主线程”的严密概念，也许你误以为我是故意强调这个“主”字，是我表述不严密。我的意思是一般进入shellcode的一开始不是在线程初始化的环境，这和修改入口点的感染型病毒的环境不一样，shellcode的环境通常更具有随机性，因此一般不用这个方法。这才是我的回帖想强调的内容，即这个环境的差异。这里我表述的“主线程”，我其实想指的是进入shellcode时的那个线程环境，这当然不一定是进程的主线程，只是对于shellcode来说（这里可能有点“拟人”了，即shellcode它“置身”的那个环境），即是它原始“生命力”所依赖的环境，这与对于病毒而言的主线程有相似的地位，因此我随口用了“主线程”这个词，其实是shellcode自身意义上的“主线程”，这样的借用，应该比罗罗嗦嗦说上一堆话来解释简明得多吧，当然容易引起误解。我相信这个应该可以意会的，没想到还是出现彼此误解，是我表述的问题。 好了，在这种情况下，这时shellcode它身处的这个环境一般不是处于线程刚刚初始化的状态。 这里我想说的其实是，就是在这种环境下，我假设它不用其他方法取得CreaeThread的地址的情况下，它在这个它所初始依赖的线程环境中，就难以“首先”用这个方法来获取kernel32.dll的基址。 所以，实际上就我想表达的意思来讲，你根本没有“反驳”我，也不必“反驳”我。 当然严格来说，的确如你所说，在shellcode中先通过其他方法获取CreateThread地址，然后创建一个新线程，这个新线程的确就可以使用这种方法再去获取kernel32.dll的地址。 因此我提“先有蛋还是先有鸡”并不是说“技术上不可行”，而是因为已经有了CreateThread地址就可以不用这样的方法，所以在shellcode实际中使用这种方法的可能性比较小，所以我说“一般不用”并不是“技术上不能用”，而是有所取舍的情况下，相比之下感染型病毒就比较常用这个方法，而shellcode中就比较少用。 shellcode中现在普遍还是使用PEB的方法比较多。 我提这个的原因还有一点，就是希望楼主这篇文章能够再加入比较一下这三个方法的讨论内容。 比如我以上说的话题就是一个讨论内容，不局限于病毒，对于相像的shellcode来说，获取kernel32.dll基址也是具有同等甚至更高的重要性。 为什么说“重要性可能更高”，是因为更“别无选择”。病毒其实也可以在感染时把原程序中指向LoadLibraryA和GetProcAddress的IAT位置保存下来，或者自己在输入表中加上相应项目，感染后的程序一旦运行，这个IAT已经被系统填上了地址，病毒直接用就行了，现实中有些病毒就是这么做的，这就跟壳差不多了。病毒一般就是依靠修改原PE程序而获得其代码执行机会，而shellcode没有这样的条件，包括一般不能像病毒这样用原始IAT来获得API地址，所以对于shellcode来说，动态获取kernel32.dll的地址就显得更为重要。 上面又提到了壳，壳又怎么样呢？病毒和壳也是比较像的，有的病毒可以说是用壳的方式感染文件。 因此以上这些内容，其实不是完全无关的，楼主在讲的虽然是AntiVirus，但其实本质上涉及到PEDIY的方方面面，因此有必要拓宽了讲，让大家有个整体全局上的了解。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 楼主好强哦 学习。。。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
真不错，学习了！
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[QUOTE=hackerlx;630734].386
.model flat, stdcall option casemap :none include windows.inc .code start: mov edx, [esp] Next: dec edx ; xo...[/QUOTE] 楼上的，是你搞错了。再仔细想想在内存中的排布
|
|
|
|
