Yuu 发布的文章

日系机CleanKERNEL企画 402SH

作者: Yuu
时间: 2021-03-13
分类: 日系机CleanKERNEL企画
评论

最近收到了一些古早的日系机，稍稍优化了一下它们的内核，重新编译了一下。在此分享出来

设备信息

品牌:SHARP
型号:402SH(代号:LA26)
设备名:AQUOS CRYSTAL X
Android版本:4.4.4
源码版本:S0030
对应版本:S0032(兼容S0006/0018/0022/0024/0026/0030)
测试通过版本:S0032/S0030
编译链:gcc version 4.9.4 (Linaro GCC 4.9-2017.01)

移除功能

MIYABI内核安全模块
Kallsyms保护模块
eMMC读写保护

还原功能

原版SELinux

更新日志

1.0->1.1(2021-03-15):使用GCC4.9.4编译/更新截图
1.0(2021-03-13):首次发布

截图

Kernel_402SH

下载

内核下载

LAZY

作者: Yuu
时间: 2021-02-25
分类: 有意思的东西
评论

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

KC-KYL22 LSM Offsets

作者: Yuu
时间: 2020-11-18
分类: ROOT
评论

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

Function Name	Start	NOP
kclsm_init	C01D9F90	C0D19FB0
kclsm_path_chroot	C02EE5A8	C02EE5D0
kclsm_sb_pivotroot	C02EE5E0	C02EE608
kclsm_sb_mount	C02EE618	C02EE720
kclsm_ptrace_traceme	C02EE73C	C02EE780
kclsm_kernel_setup_load_info	C02EE790	C02EE824
kclsm_path_mknod	C02EE83C	C02EE958
kclsm_sb_umount	C02EE96C	C02EEA80
kclsm_ptrace_access_check	C02EEAA4	C02EEB14
kclsm_dentry_open	C02EEB24	C02EEC8C
kclsm_sysfs_init	C0D19FC0	C0D1A014

日系机因为其畸形的运营商主导加拉帕戈斯制度，导致一般消费者要更新换代手机要付出的金钱并不是很多，很多二手手机流入日本本土中古市场以及回收商。又由于日本离我国很近，这些机子大多流入了国内。在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可用

Qualcomm MSM8k平台的SBL相关分析

作者: Yuu
时间: 2020-02-02
分类: 开发随笔
评论

Qualcomm的MSM8k以及SDM平台的启动过程其实比较复杂，但是如果想改动其实并不能改很多，有一部分高通甚至只给了BIN并没有SRC。所以今天就选继PBL后最重要也是能改动的最底层部分，即SBL来做一些分析以及介绍。由于NDA的缘故，其中仅能挑选公开部分代码片段。可能有疏漏，请尽情指正！

启动过程

由于我并不涉及到BP部分的开发，那全程就只从AP的角度做分析以及介绍。
MSM_BootProgress

SBL的功能

初始化DDR/硬件/加载RPM/加载TrustZone/加载ABL以继续引导

SBL入口

此部分源码位于boot_images/core/boot/secboot3/hw/<Part_Number>/sbl1/sbl1.s

IMPORT |Image$$SBL1_SVC_STACK$$ZI$$Limit|
IMPORT |Image$$SBL1_UND_STACK$$ZI$$Limit|
IMPORT |Image$$SBL1_ABT_STACK$$ZI$$Limit|
IMPORT boot_undefined_instruction_c_handler ;导入了外部Symbol
IMPORT boot_swi_c_handler
IMPORT boot_prefetch_abort_c_handler
IMPORT boot_data_abort_c_handler
IMPORT boot_reserved_c_handler
IMPORT boot_irq_c_handler ;PBL传递来的中断请求参数
IMPORT boot_fiq_c_handler ;PBL传递来的快速中断请求参数
IMPORT boot_nested_exception_c_handler
IMPORT sbl1_main_ctl ;!注意此处!此处导入SBL1主要功能
IMPORT boot_crash_dump_regs_ptr

SBL1_MAIN_CTL

此部分主要做初始化DDR的工作
此部分源码位于boot_images/core/boot/secboot3/hw/<Part_Number>/sbl1/sbl1_mc.c

/* 初始化DDR部分 */
static boot_ram_init_data_type sbl1_ram_init_data_ddr =
{
  NULL,   //load_rw_base;
  NULL,  //image_rw_base;
  0,        //image_rw_len;
  (uint8*)&Image$$SBL1_DDR_ZI$$Base,  //image_zi_base;
  &Image$$SBL1_DDR_ZI$$ZI$$Length     //image_zi_len;
};

/* 初始化Logger部分，数据传送到SERIAL */
static uint32 sbl_start_time = 0;
static boot_log_init_data boot_log_data =
{
  (void *)SBL1_LOG_BUF_START,
  SBL1_LOG_BUF_SIZE,
  (void *)SBL1_LOG_META_INFO_START,
  SBL1_LOG_META_INFO_SIZE,
  NULL
};

/* 加载SBL1_Config_Table */
#define CPSR_EA_BIT     (1<<8)

extern boot_configuration_table_entry sbl1_config_table[];

SBL1_CONFIG_TABLE

此部分存储了ABL\TrustZone\RPM等Image的相关参数
此部分源码位于boot_images/core/boot/secboot3/hw/<Part_Number>/sbl1/sbl1_config.c

extern uint8 qsee_partition_id[]; //QSEE分区ID
extern uint8 rpm_partition_id[]; //Resource Power Manager分区ID
extern uint8 appsbl_partition_id[]; //Application Secondaty BootLoader分区ID
extern uint8 apdp_partition_id[]; //Debug Policy分区ID
extern uint8 devcfg_partition_id[]; //Trust Zone Config分区ID

boot_configuration_table_entry sbl1_config_table[];

此文就是一篇概览，也就是大概阅读了一下源码写下的随笔，同时由于惧怕高通的NDA，源码也不能放出太多，到此为止吧！