分类 默认分类 下的文章

"只是一个默认分类"


我太懒了。
吾懒惰胚。
I'm lazy.
私は怠け者です。

冒泡排序,选择排序,插入排序,快速排序,堆排序,归并排序,希尔排序,桶排序,基数排序新年帮您排忧解难。

有向图,无向图,有环图,无环图,完全图,稠密图,稀疏图,拓扑图祝您新年宏图大展。

最长路,最短路,单源路径,所有节点对路径祝您新年路路通畅。

二叉树,红黑树,van Emde Boas树,最小生成树祝您新年好运枝繁叶茂。

最大流,网络流,标准输入流,标准输出流,文件输入流,文件输出流祝您新年顺顺流流。

线性动规,区间动规,坐标动规,背包动规,树型动归为您的新年规划精彩。

散列表,哈希表,邻接表,双向链表,循环链表帮您在新年表达喜悦。

O(n!),O(2^n),O(n^3),O(n^2),O(nlog n),O(n),O(log n),O(1)祝大家新年渐进步步高。

KYOCERA/KYL22/4.2.2/103.0.2500/3.4.0/Mon Apr 7 03:30:16 JST 2014

Function NameStartLengthKill
kclsm_initC01D9F9024C0D19FB0
kclsm_path_chrootC02EE5A830C02EE5D0
kclsm_sb_pivotrootC02EE5E030C02EE608
kclsm_sb_mountC02EE618110C02EE720
kclsm_ptrace_tracemeC02EE73C4CC02EE780
kclsm_kernel_setup_load_infoC02EE7909CC02EE824
kclsm_path_mknodC02EE83C124C02EE958
kclsm_sb_umountC02EE96C120C02EEA80
kclsm_ptrace_access_checkC02EEAA478C02EEB14
kclsm_dentry_openC02EEB24170C02EEC8C
kclsm_bootmode_setupC0D19F3824/
kclsm_kbfm_setupC0D19F6424/
kclsm_sysfs_initC0D19FC05CC0D1A014

前言

日系机因为其畸形的运营商主导加拉帕戈斯制度,导致一般消费者要更新换代手机要付出的金钱并不是很多,很多二手手机流入日本本土中古市场以及回收商。又由于日本离我国很近,这些机子大多流入了国内。在x鱼上,因其良好的性价比,销量还算不错。但因为其差强人意的系统,很多人购买后都想root来提升易用度,可是日系机的防护一概很严格,有些人滥用方法,导致变砖。同时,也避免高谈阔论的伪大神的出现,所以作为倒腾过日系御三家各种平台的root的人类,必须得站出来解释一下!
不管怎么说,夏普京瓷富士通这三家公司都非常热衷于加强手机的安全性,这虽然对一般用户的确是好事,但是对于开发者以及爱倒腾的人来说,这便是个很严重以及很恶心的问题
直接关于日系设备的root的资料其实并不多,主要在2ch以及国内和东欧的付费维修商手上,但是可用的exploit其实有非常多(日系机更ASPL频率不算特别高),只要加以利用并且加上自己的改动,即可拿来使用
另外,在夏普京瓷富士通三家公司中,夏普的有效ROOT资料最多,同时夏普的LSM以及eMMC写保护也是御三家最复杂的,如果你可以自行ROOT掉夏普,则其他两家的ROOT也会变得简单,毕竟大同小异。

Root的基本概要

这个指南大概是给小白们看的普及文章,所以我尽可能从最基本的部分开始写起。Android设备的root,简单来说就是在/system/xbin目录下放一个叫做su的可执行文件,或者修改内核里面的init。就像在Windows中,改动C:\WINDOWS\System32一个道理。
当然你想普通的把文件复制进/system/xbin,那是不可能的,因为/system在正常情况下,是只读的。但是我们可以通过临时ROOT,来让System挂载为可写。
但是厂商的程序员也不是傻子,肯定老早想到了有人会用临时ROOT来往重要分区写数据,所以他们很早就在设备上有了应对方案。比如夏普的miyabi内核安全模块,富士通的fjsec内核安全模块,京瓷的kclsm和selinux_kc内核安全模块。更有甚者,直接在eMMC控制器做写保护,甚至加入厂商自定义的eMMC控制器解除写保护指令。
这样的话,一般的提权顶多给个#,接下来就没有任何操作可以执行了,由于不能写入System,现在的设备也都强制开启安全启动以及内核签名校验,也不能对bootloader或内核动手脚,重启后连#都会消失,这时候,你可能会感觉各种方面好像被完全给堵死了。接下来就来谈谈绕过以及各大LSM的坑。
在我个人的经验来说,御三家的ROOT难度依次为夏普(7.1之前)>富士通>京瓷(7.1之前)>京瓷(7.1之后)>夏普(7.1之后)

各大厂商的坑

SHARP
内核安全模块:
1.MIYABI保护mount/umount/pivotroot/symlink/chmod/chroot/setuid等内核函数
2.MIYABI保护sock通信部分,直接导致2017-8890类的Exploit无法使用
4.MIYABI除非编译内核时于defconfig内取消,否则无法完全关闭(即不具备SetEnforce功能)

于Android 8后移除了以上LSM

4.SELinux被硬编码为Enforcing
Kallsyms保护:
1.于运行时移除/proc/kallsyms导致无法查看符号表

于Android 6后移除了该功能

eMMC保护:
1.使用eMMC固件内模块保护了各个系统分区
2.CLEAR_WRITE_PROT标准解除写保护指令不可用,需使用CMD56(GEN_CMD)发送前置指令才可调用

使用UFS的机型目前暂无法确定,但依据内核开源,针对UFS的写保护依旧存在

FUJITSU
内核安全模块:
1.FJSEC保护Insmod/Rmmod以及对ko的白名单检查
2.FJSEC保护ptrace导致不可用
3.FJSEC保证所有系统进程安全(于编译时的白名单定义)
4.FJSEC拥有读写保护检测
5.FJSEC保护mount/umount/rmdir/mkdir/chown/chmod/rename/link/symlink/mknod/unlink/chroot等内核函数
6.FJSEC除非编译内核时于defconfig内取消,否则无法完全关闭(即不具备SetEnforce功能)
7.SELinux被硬编码为Enforcing
Bootloader:
1.OS如检测到Bootloader被解锁则开机后直接重启,无法进入系统

于F-04H DVT机测试

KYOCERA
内核安全模块:
1.SELinux合入KC改动,不具备SetEnforce功能
2.需在开机时候修改bootmode,才可Permissive

于Android 8后恢复原版SELinux

3.KCPDSM存在系统进程白名单

eMMC保护:
1.于Bootloader实现写保护重要分区,每次启动都会被复保护,但CLEAR_WRITE_PROT可用

2021重新整理版
午诺F3这个机器尚且还行,但是没有第三方Recovery还是十分令人不适。
一开始我先尝试给它适配TWRP,却因为ilitek的屏走的是SPI,并且没有开源,使用预编译无法驱动显示而作罢
所以想到修改官方Recovery的做法
以下是记录
首先使用QFIL和8909的firehose进行回读Recovery分区的操作,此设备未熔断SecureBoot,所以任意设备之firehose均可启动
1.获得到recovery.img后,使用任意工具执行解压镜像
UNNO_F3_Recovery_Unpack.png
2.获取RAMDISK/sbin/recovery可执行文件,放入IDA(32位)版
3.IDA将会自动处理好之前的一切
IDA_Main.png
4.由于Android是开源项目,此时我们直接阅读源码
寻找到platform/bootable/recovery/verifier.cpp于KitKat分支
找着找着,在此处寻找到了RSA相关!
Source_Verifier.png
5.在此使用字符串特征"whole-file"于IDA使用Alt+T使用Text方式搜索该字符串
IDA_Decompile_Result.png
在红线处可以见到很明显的一个返回值分支(即MOVS R0,#1)
6.继续阅读源码,一路追踪发现此处隶属于verify_file这个函数
Source_Verify_File.png
如图可知,如果#0则代表宏VERIFY_SUCCESS,反之则代表VERIFY_FAILURE
7.此时则思路完全清晰,使用KeyPatch等Patch工具对MOVS R0,#1此处汇编Patch为MOVS R0,#0
直接实现了暴力破解签名(因为任何情况下签名验证结果都为真)
After_Patch.png
8.替换修改后的可执行文件至RAMDISK/sbin/recovery,再重新执行打包
9(可选).对背景PNG添加提示,避免混淆Patch后版本和原版
Add_Watermark.png
10.使用fastboot flash写入设备的Recovery分区