内容简介
本书由国内创刊的网络安全类媒体之一《黑客防线》编纂。全书秉承“在攻与防的对立统一中寻求突破”的核心理念,以3 0多个漏洞机理分析,触发机制,发掘过程,调试过程,ExPloit编写,核心ShellCode调试,实战构造为例,深入分析漏洞发掘的整个过程,详细解析Exploit的编写步骤。
 本书分为“初级篇”、“分析篇”、“Sh ellC ode篇”三篇,由浅入深地进行系统全面的缓冲区溢出攻击与防范的技术探讨,适合各层次的网络安全技术爱好者阅读。
目录
 初级篇
  初探缓冲区溢出攻击
  Windows下堆溢出初步
  Windows堆栈溢出全面解析
  经典WIN32堆栈溢出保护+突破技术
  菜鸟版Exp Loit编写指南
  简单分析IFame漏洞
  免费才是我们的叫eaI Server远程溢出漏洞分析
  Isasrvdll远程溢出
  Serv-U FTP漏洞IEl饭重炒
  Hacker4-Cracker4-Sniffer的综合利用
  在Windows下对比学习Linux堆栈溢出
  采众家之长分析及改进CMail漏洞
  从MS03-049漏洞利用看调试系统进程
  我来写ShellCode生成器
  Windows整数溢出初步
  溢出漏洞扫描技术
  新手溢出TFTPD
  初探堆栈溢出
分析篇
  堆栈溢出点定位原理分析
  巧妙分析JPEG处理漏洞
  从分析MS06-040谈metasploit攻击代码提取
  分析和利用W32Dasm溢出漏洞
  玩转Winamp漏洞
  RealPlayer溢出分析+利用
  Realplaysmil文件溢出漏洞分析
  PNP溢出漏洞分析+利用
  Word溢出漏洞分析与利用
  Excel溢出漏洞分析+利用
  亲密接触MS06—055
  WinZip溢出漏洞分析+利用
  迅雷5远程拒绝服务漏i同ODay分析
  MS07-004分析和利用
  IPMs9溢出的简单分析
  WinRAR 7z文件名溢出分析和利用
  ShelICode到洞悉溢出漏洞原理
  Fuzzing in Word溢出分析和利用
  重温MDB File文件漏洞
  OllyDbg Format String ODay分析与利用
  WinRAR栈溢出分析和利用
  从卡巴漏洞管窥内核模式ShelICode的编写
  Windows CE缓冲区溢出利用技术
  隔山打牛之RealPlayer栈溢出
ShellCode篇
  定制特殊的ShelICode
  定制自己的ShelICode之二
  ShelICode编码变形大法
  编写变形的ShelICode实战篇
  打造Windows下自己的ShelICode
  让Shel ICode突破系统版本限制
  《射雕》之突破WindowS个人防火墙
  穿墙ShelICode的编写+应用
  突破溢出数据包长度限制——编写分段传送的ShelICode(上)
  突破溢出数据包长度限制——编写分段传送的ShelICode(下)
  突破防火墙的非管道ShelICode
  ShelICodel刍动化提取的设计与实现
  能够生成木马的ShelICode
  编写Word木马的ShellCode
  不死的ShellCode
  打造自己的ShelICode综合分析工具
  编写全数字字母的,ShelICode
  再谈全字母数字的ShelICode的编写
  The短erthe better——精简你的数字字母ShelICode
  打造200字节的通用ShelICode
  编写Unicode有效的ShellCode
  编写绕过卡巴主动防御的ShellCode
  SP2下利用TEB执行ShelICode
  安全搜索进程内存空间
  再谈绕过卡巴斯基主动防御系统
摘要与插图
system32\services意外终止关闭提示框.根据以往的经验,我们可以看出该漏洞是存在于services进程中,这一点和work Station服务一样,因此归为后一类。2.服务进程接收缓冲区长度
这个问题集中体现在用于接收请求的函数(如recv、recvf rom等)第3个参数Ten上。如果指定的Ten很小.我们是无法一次性传送功能复杂的很长的shell Code的.这时就必须采用其他传送的方式.例如把shell Code分段传送,这在10期一篇溢出文章((编写分段传送的shell Code))中有介绍。接收缓冲区长度问题一般在服务进程自身绑定了端口的溢出漏洞中出现,因此PNP服务中可以暂不考虑。
3.异常发生的位置
这个问题是指我们向服务程序提交超长的请求后,会覆盖问题函数的返回地址EIP等指针。当函数返回的时候,跳转到我们覆盖数据指定的地址的时候可能发生异常:另外一种情况就是在该函数返回之前,由于我们覆盖了局部变量中其他指针,导致对其进行引用的时候发生异常。简而言之,就是rel前与rel后发生异常的区别。对于ret后的异常,我们可能需要通过KiUse rExceptionDispatcher和监视点的方法来联合定位溢出点.并且漏洞利用的方式有两种改写EIP为jmp esp地址或改写SEH指针而对于ret前的异常.我们一般通过KiUserExceptionDispatcher来定位溢出点就够了,利用的时候也只能改写SEH指针。我们预先并不知道PNP溢出漏洞属于哪一类.不过等下面进一步调试后就明确了。
4.判断ret函数的调用约定
这个问题是易被忽略的。如果我们能够采用jmp esp的利用方式的话,可能很多人会在覆盖jmp esp位置的紧接4个字节开始的地方连接shell Code.问题就出在这里。



   VIP会员