据说LBE公开之后
250+110成了第一个免root的

这么碉堡啊 我更新去。。

LBE公开？它是开源的吗？

修改原始APK文件中的DEX或其他文件，然后利用文件名重复导致签名绕过 文件名重复这个在对新版本的系统没啥影响了都修复了

没有人分析过吗？还是没弄出来LBE是怎么利用master-key漏洞的

LBE应该用的是 http://www.saurik.com/id/18/ 这篇所说的方法。
我获得lbe_patch里确实没有重复的文件，但是这个lbe_patch的zip格式是有问题的：
CERT.RSA的Central Directory结构里，其file comment length为32768，根据http://www.saurik.com/id/18/所说，java用的是readShort()，这样读的长度是0，但是C++里读的仍然是32768。
所以java层的签名校验是，解析Central Directory的时候，会直接读取接下来的那个Central Directory, 接下来两个Central Directory结构的file name都是以"/"结尾的，如下图：


而在PackageParser.java
(/frameworks/base/core/java/android/content/pm/PackageParser.java)中：


isDirectory()函数如下：


所以遇到文件名以"/"结尾的就直接pass了。

这样LBE就在java层的校验上通过了，同时在C++层面，解析完CERT.RSA Central Directory 后是正确的AndroidManifest.xml和classes.dex， 46 + filename_length + filecomment_length(32768) + extra_field_length会正好跳到AndroidManifest.xml，这样代码加载没有问题，同时又绕过了签名校验。

不知道讲清楚没。

上传的附件：

• LBE Master Key Exploit.png （179.30kb，31次下载）
• PackageParser.png （11.93kb，19次下载）
• ZipEntry.png （5.80kb，17次下载）

LBE应该用的是 http://www.saurik.com/id/18/ 这篇所说的方法。
我获得lbe_patch里确实没有重复的文件，但是这个lbe_patch的zip格式是有问题的：
CERT.RSA的Central Directory结构里，其file comment length为32768，根据http://www.saurik.com/id/18/所说，java用的是readShort()，这样读的长度是0，但是C++里读的仍然是32768。
所以java层的签名校验是，解析Central Directory的时候，会直接读取接下来的那个Central Directory, 接下来两个Central Directory结构的file name都是以"/"结尾的，如下图：


而在PackageParser.java
(/frameworks/base/core/java/android/content/pm/PackageParser.java)中：


isDirectory()函数如下：


所以遇到文件名以"/"结尾的就直接pass了。

这样LBE就在java层的校验上通过了，同时在C++层面，解析完CERT.RSA Central Directory 后是正确的AndroidManifest.xml和classes.dex， 46 + filename_length + filecomment_length(32768) + extra_field_length会正好跳到AndroidManifest.xml，这样代码加载没有问题，同时又绕过了签名校验。

不知道讲清楚没。

上传的附件：

• LBE Master Key Exploit.png （179.30kb，9次下载）
• PackageParser.png （11.93kb，3次下载）
• ZipEntry.png （5.80kb，3次下载）

漏洞的原理，可以参考我的文章：
http://www.colordancer.net/blog/2013/08/26/android-%E7%AC%AC%E4%BA%8C%E4%B8%AA%E7%AD%BE%E5%90%8D%E6%BC%8F%E6%B4%9E-9695860-%E6%8F%AD%E7%A7%98/

leb怎么利用这个漏洞的，提示一下：patch

看了博主的文章，还有一些不明白的地方，求博主修改index绕过 签名的apk