http://www.fortiguard.com/analysis/pdfanalysis.html

比较详细，有兴趣的可以看看。

白天打点滴回来，看到论坛里面有朋友提到PDFiD可以检测这个0day：
http://blog.didierstevens.com/2009/10/13/update-pdfid-version-0-0-9-to-detect-another-adobe-0day/

抽空看了一下还是PDF本身的问题，漏洞原理是因为/Colors 跟随大整数会导致某个static的内存指针的值+1，这样本来读的是0内存地址，+1后最高字节有值了，就会变成一个比较高的内存地址，然后直接call这个地址，所以需要配合heapspray来获得利用。

http://blogs.adobe.com/psirt/2009/10/adobe_reader_and_acrobat_issue_1.html

report给adobe的来自台湾，很容易让人浮想联翩啊……

http://blog.metasploit.com/2009/10/smb2-351-packets-from-trampoline.html 提到metasploit 中目前利用的方法不是很稳定，对真实的机器成功率比较低，并且提供了另外一个比较通用的利用方法，把一段小的跳转代码写入到一个稳定的地址中去(只需要发送351个报文)，而不是找内核内存中的跳转代码，下午抽空根据blog的思路改了一个利用，贴0x557论坛了。

另外metasploit的blog上貌似有一个笔误，push esi 应该是 0x56才对。

update: 刚才看了一下canvas的利用，也是用同一个技巧。

http://trac.metasploit.com/browser/framework3/trunk/modules/exploits/windows/smb/smb2_negotiate_func_index.rb

和vrt提到的方法不一样。

http://vrt-sourcefire.blogspot.com/2009/09/smbv2-quotes-dos-quotes.html
VRT提到的方法是覆盖srvnet.sys里面的一个全局变量（SrvNetStatistics），这个全局变量是用于保存请求包的数量，他提到了用一个undocument的SMB 命令（GET_PRINT_QUEUE）可以安全的控制这个全局的变量变成我们想要执行的指令，比如0x56c3个包就是push esi -> ret（假设esi指向我们控制的内容，shellcode）。 而且srvnet.sys是继srv2.sys后立即加载的，所以不用去猜测ValidateRoutines的基址，只

似乎能够比较容易的被利用，按理来说solaris也应该有这个漏洞啊，http://risesecurity.org/advisories/RISE-2009001.txt。

http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/03/20/exposing-flash-application-vulnerabilities-with-swfscan.aspx

这个漏洞和MS09-002很相似，哪位大牛share一个PoC啊？