这几天看了一下Android下so文件的壳与脱壳,目前这一块应该还算是比较新的市场。个人感觉，受到调试器和计算资源的影响，虽然已经有多家厂商在做，但目前的总体强度和花样，远没有x86下的五花八门。
对于我们这种每天都在被各种病毒的变形外壳虐待的人，掌握了技巧，一般的Android壳还是很好脱的。其实，到目前为止我也只看了一个。
今天，鱼妹兔在看雪论坛上发表的《ApkProtect 分析》绝对是一个很好的研究资料。其中包括了完整逆向的壳代码，还有大量注释的idb，很好的呈现了Android壳的主要流程和必须的细节。掌握了其中的关键，别的壳也就是时间的问题。
这是上周面试管家时，让我写的漏洞分析报告。虽然最后没去管家，目前，还是不想离开成都:)。
分析环境：
Windows 8 Enterprise x86 (9200) Internet Explorer 10.0.9200.16384
受影响的文件：
前几天面试管家，让我分析一个IE10以上的漏洞并给出详细报告，我挑了个CVE-2014-0322。从前都是从崩溃点之后开始分析ShellCode，这次把前前后后的细节都看了一遍，受益匪浅。趁着有感觉，今天又看了一下CVE-2013-3897，发现出错的逻辑是一样的，均和AddRef有关。POC来自这里。
分析的目标是Windows XP Professional SP3下IE8的mshtml.dll文件，详细信息如下：
文件名：mshtml.dll 文件版本：8.00.6001.18702 MD5：D469A0EBA2EF5C6BEE8065B7E3196E5E SHA1：FD6CB9D197BB58C339DEFE6E2C3B03FB3B62B440
这里只记录一下崩溃点之前对象的LifeTime，这也是UAF的主要原因。
Code Splicing本质上是一种Anti-Dump机制。远离就是在加壳的时候抽取一部分代码，并在其中参杂些许垃圾指令。壳运行的时候申请一块内存，再把这些指令和原始的位置用jump连接起来。
大体流程如下：
1. VirtualAlloc申请足够大的内存空间。
2. 使用zlib解压被抽取的代码到该空间。
3. 解压一个表。该表的内存如下
+0 - 原始跳转jump offset的偏移。
+4 - 被抽代码相对于buffer的偏移。
+8 - 有效的Splicing Code的长度。
4. 解压完之后就可以利用这个信息把原始的代码和Splicing Code进行连接。 处理方法：因为加壳的时候处理比较多了在壳流程中能做手脚的地方不多。大体的解决思路是：
jjencode – Encode any JavaScript program using only symbols
这个东西能把Javascript加密成这样：
$=~[];$={___:++$,$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$:({}+"")[$],$_$:($[$]+"")[$],_$:++$,$$_:(!""+"")[$],$__:++$,$_$:++$,$__:({}+"")[$],$_:++$,$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$=($.$+"")[$.__$])+((!$)+"")[$._$]+($.__=$.$_[$.$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$=$.$+(!""+"")[$._$]+$.__+$._+$.$+$.$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$+"""+$.$_$_+(![]+"")[$._$_]+$.$$_+""+$.__$+$.$_+$._$_+$.__+"(""+$.__$+$.__$+$.___+$.$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+","+$.$__+$.___+""+$.__$+$.__$+$._$_+$.$_$_+""+$.__$+$.$_+$.$_+$.$_$_+""+$.__$+$._$_+$._$+$.$__+""+$.__$+$.$_+$._$_+""+$.__$+$.$_$+$.__$+""+$.__$+$.$_+$.___+$.__+"""+$.$__+$.___+")"+""")())();看起来很是蛋疼。第一次遇到这个东西是在那个该死的PDF里面。 经过一番观察，发现这个：
有人在pastebin上贴了个分析，原始地址：http://pastebin.com/64pBCgbw。
Some unnoticed facts about cve-2013-3906 1. Embedded in cve-2013-3906 exploit are Excel Russian files.View post on imgur.comMeans: fuzzing artifacts or intended decoy. 2. Embedded in cve-2013-3906 exploit Excel files are not required for triggering and exploitation of the vulnerability. Means: exploit acquired for hacking campaigns to be used 'as is', rather than produced in-lab. 3. All known samples of cve-2013-3906 from all hacking campaigns have same useless XLS embeddings inside. Means: one exploit seller, brainless tool usage. 4. First submission of cve-2013-3906 to VirusTotal was on 2013-07-07 (JoseMOlazagasti.docx, MY, NL, DK, other EU). http://cryptam.com/docsearch.php?sha256=2c48b4b75db16a32f2ea872454c5cb0fe281302d2d6a18d5bdc98c64f31dd2d6 https://www.virustotal.com/ru/file/2c48b4b75db16a32f2ea872454c5cb0fe281302d2d6a18d5bdc98c64f31dd2d6/analysis/1373962220/ Means: @fireeye research is missing at least one hacking group/campaign. 5. First appearance of cve-2013-3906 in the wild (2013-07-07) was mistaken by @avast_antivirus for cve-2012-0158. http://blog.avast.com/2013/07/22/multisystem-trojan-janicab-attacks-windows-and-macosx-via-scripts/ https://www.virustotal.com/ru/file/2c48b4b75db16a32f2ea872454c5cb0fe281302d2d6a18d5bdc98c64f31dd2d6/analysis/1373962220/ https://www.virustotal.com/ru/file/2c48b4b75db16a32f2ea872454c5cb0fe281302d2d6a18d5bdc98c64f31dd2d6/analysis/ Means: shame. 6. First submission of cve-2013-3906 internals (tiff, ActiveX) to VirusTotal was on September (TW,IN,IS). Not by previously attacked EU. Not reported until November. https://www.virustotal.com/ru/file/f9f82073a52aec988a14f19ffce79ed716a88fe9bf70b55919d47bc0464276ba/analysis/#additional-info https://www.virustotal.com/ru/file/2cfaf996f64ba5b370dd3a92e2e255474267bb4fe68933faa052625773d2da22/analysis/#additional-info (see Additional info section) Means: unqualified incident response or testing/analysis by 0day-interested parties. 7. In beginning of October, a few named and very single samples of cve-2013-3906 were submitted to VirusTotal (mostly US). 2013-10-01 21:01:52 Illegality_Supply details.docx https://www.virustotal.com/ru/file/c8367b47ade998dff759ee149ffa72276c8b71ccb45d4203a93dd7edafe14cbe/analysis/ 2013-10-07 18:27:25 Re-credit.docx_ https://www.virustotal.com/ru/file/b238d7d16fd0ccba6c15ea5670ed67c155469c36a3645b12d37f8e11ea153b9d/analysis/ 2013-10-07 20:28:38 Swift Message $288,550 USD.docx https://www.virustotal.com/ru/file/5ad4c6d89a847535fac398c431c3e4e247e2d5313e493ac72cc6c88e8db7b725/analysis/ …… Means: incident response of a campaign against one-shot targets or 0day exploit testing. Summary The cve-2013-3906 exploit was produced most likely by a Russian developer around March 2013 (ref:EXIF) and sold to multiple parties, beginning from July, 2013. The exploit was used in 3 (at least) distinct hacking campaigns: #1 in July 2013 and against Europe, #2 & #3 in October 2013 and against Middle East and Asia. The exploit remained unnoticed for 2 months, and was detected shortly after beginning of the 2nd/3rd campaigns (possibly due to their connection with known malware Citadel). Some parties involved in campaigns ordering and production may reside in Taiwan, India, Israel and the United States. Previous research http://blogs.technet.com/b/srd/archive/2013/11/05/cve-2013-3906-a-graphics-vulnerability-exploited-through-word-documents.aspx http://blogs.mcafee.com/mcafee-labs/mcafee-labs-detects-zero-day-exploit-targeting-microsoft-office-2 http://www.fireeye.com/blog/technical/cyber-exploits/2013/11/the-dual-use-exploit-cve-2013-3906-used-in-both-targeted-attacks-and-crimeware-campaigns.html#more-3703 http://www.securelist.com/ru/blog/207768960/Novyy_staryy_0day_dlya_Microsoft_Office_CVE_2013_3906 http://pastebin.ca/2474735 @alisaesage
这脸打得真是啪啪响。
如果不是McAfee的Advanced Exploit Detection System有所动静加上之后的详细分析和确认，很可能各大厂商会继续忽略。从他们的博客来看，AEDS应该还没投入到产品中。
没提交过漏洞，加之没仔细分析，故简单记录。
测试的版本是CFF Explorer，版本<=v8.0.0.0，x86和x64均存在该漏洞。
这个版本的CFF Explorer在解析资源文件中版本信息的时候处理不当，死在一个循环内，进而导致程序卡死，当然，该漏洞的危害不大。
Stud_PE不常用，昨天无意中发现Stud_PE有个溢出，确切的说是两个。当然，这种明显的问题早就有人发了：http://www.exploit-db.com/exploits/11911/。
其实这个函数里有两个地方可以溢出，但均由于wsprintfA使用不当导致。首先是Export里的Name处理不当，wspritnfA格式化“Module Name:%s”的时候溢出，另外就是exploit-db里的那个。超长的导出表原始DLL名称和超长的导出函数都能让导致溢出。
在利用上有些不同，超长导出函数的就不说了，很常见的栈溢出，链接里的PoC改改jmp esp地址还是有效的。超长原始DLL名称，只能用覆盖SEH的方式利用。因为超长字符串导致了某些局部变量被覆盖，在往后的某个函数中导致异常。只需要覆盖SEH的2个字节即可，在Stud_PE里找一个pop/pop/ret。