前言
最近学习android 方面的东西，正好手上有一台买屏幕送其他零件的android设备拿来练手，该设备android版本是4.4.2，开机提示 “本机已经拆机自毁，即将关闭，请联系售后人员”，2秒后系统就会自动关闭，幸好这2秒内可以触摸可以用，快速的触摸返回按钮可以把这个窗口关掉。并且系统自带了 ES文件浏览器。
获取维护人员密码，打开USB调试
设置界面被修改过，看到的菜单项有限
尝试找一下维修人员登录密码，看看有什么东西。网上搜索了一番，设置界面里增加选项是修改的 Settings.apk
通过ES文件浏览器把 /system/priv-app/Settings.apk 复制出来，用jadx-gui先查看String.xml找到
再搜索 maintain 找到如下代码
发现密码是一个固定首部+序列号后3位。用密码登陆后，菜单项变多了
获取root，去掉开机2秒自动关闭
连上数据线，尝试了几款root工具，KingRoot可以获取root权限。root后在系统核心应用里找到 destroy.apk，删除后重启发现已经没有开机2秒的提示了
destroy.apk 比较简单，就是读取一个属性进行判断，大约是设备拆机以后触发某种机关机制的，会把芯片里的信息改掉吧
修改Services.jar，绕过安装app时的签名验证
root完，也不自动关机了，发现用常规方式安装app都无法安装，提示“应用未安装”，网上搜索了下android系统 apk 安装流程，最后确定是在 Services.jar 的 PackageManagerService-->installPackageLI 里有签名验证
根据设备里系统属性不同，有3个不同的签名，根据属性值分别校验，校验不通过就返回，app安装失败。想绕过当然是反编译修改上面的默认值false为true再回编，想法很简单，但是第一次修改Services.jar 还是碰到了一些问题
第一，baksmali 生成 smali文件的时候，老提示少一个依赖的jar包，但是并没有这个包
第二，有的文章说要先合并odex，再反编译修改。后来想应该是不同的android版本吧
第三，只改Services.jar的话，把对应的odex 删除以后会不会根据 jar 自动生成，根据网上找到的资料，好像系统核心的这些包odex是在系统编译的时候生成的，自己安装的apk安装的过程中产生（对android了解还少，不一定对）
找资料找的一头雾水，但也有一些发现，了解到有一个 dexopt-wrapper 可以根据 jar 包生成 对应的odex，有一个帖子提到用IDA反编译jar包里的classes.dex，然后定位到字符串用winhex修改了里面的文字，还有一篇帖子其中说了一句有个工具可以修改 Services.jar (BatchApkTool)
根据 IDA+winhex 的那篇文章想到，如果反编译不出 smali，直接修改 classes.dex 文件把 false 改成 true 呢，于是用IDA找到对应的位置
winhex 中把 0F 改为 1F， 0A 改成 1A
为什么这么改？我也是猜的，虽然查了java字节码的操作码，但是没找到很详细的资料，只知道12指令对应Idc
改完保存，然后用 jar 命令打包回 jar包。把新的jar包拖进反编译工具，反编译没报错，找到对应代码，还真就变成了true
一切看起来很正常，但是测试用 dexopt-wrapper 生成对应的 odex却失败了，也不清楚是这么修改文件不行，还是dexopt-wrapper有问题
手里没有刷机包，为了尽量避免变砖，决定用另外一个帖子提到能修改jar包的工具试试，解压后目录如下
启动后，是一个工具集，看起来很厉害，（使用起来发现真的很厉害）
把Services.jar放到_INPUT_JAR 下面，选 06，简简单单的反编译成功了，找到对应的smali文件，修改后再选 07，新的 Services.jar 就出来了，但是对比原版的Services.jar，个头小了不少。尝试用 dexopt-wrapper生成odex，很顺利就成功了。这么看来用winhex修改的文件可能还是有问题。
用新生成的jar和odex覆盖系统原来的文件，并设置好权限和所有者后，可以正常安装app当普通平板用了。
总结一下Services.jar修改步骤就是（android4.4.2）
(1) 反编译Services.jar
(2) 修改后回编
(3) 用dexopt-wrapper生成对应的odex文件
(4)覆盖回去并设定好权限
[复制链接]
发表于 2020-3-20 11:19
|
发表于 2020-3-21 10:12
