点击登录

米环7教程 小米手环7自定义固件制作/刷环教程(尚未验证成功)

Wangyd

Lv.6
社区会员
作者大佬 搞机玩家
注:本教程尚未被成功验证
我自己也没有刷成功
目前还是校验这一关过不去

不过这个方向大致是对的

希望各位大佬查找原因 批评指正

MENU
一、固件解析
二、固件制作
三、注意事项

一、固件解析


1684062968288.png
解包全量固件
META里放着固件主体资源
filehash存放着META里的所有文件的哈希值(后面会考)
下面一个不用管

1684063089880.png
打开META
其中"resources"就是需要替换掉的gt3图片文件
1684063152166.png
fonts存放字体文件
images存放图片文件
1684063196282.png
米环所有的图片资源都能在里面找到
想要达到资源包的效果
只需替换applist里的文件即可
如果想要深层次自定义固件
其它内容不妨看一看

二、固件制作
首先准备好文件
图片转换为GT3备用

以下为重点
手环的固件校验非常严格
想要顺利刷入固件(尤其是全量自定义固件)
必须保证手环有足够的空间

请重新解压一份全量固件
将制作好的图片转换为GT3,复制进去
千万只能复制进去
源文件的复制会导致哈希值全部更改


使用VSCode打开先前的filehash1684063690914.png
例如我要替换这七个文件其中的前六个

百度下载hashtool软件
全部选中后右键"hashtool校验" 并使用SHA256格式编码
1684063779438.png
将第七个文件与filehash中进行比对
1684063839472.png
确认无误后
将前六个文件的hash值一一替换原值


到这里就已经完成了一大半
最后压缩成zip 即可测试刷环了

三、注意事项
确保刷环时手环有足够的空间
刷环时保持gadgetbridge连接 不要退出进程或重新连接zepp life或小米运动健康
使用Gadgetbridge刷环贼慢 大约需要25分钟完成过程 耐心等待
 
最后编辑:
社区团队曾经研究过,在最后步骤压缩zip后,还要hex加文件尾,从位数看很有可能是sha256及crc32校验,但是与任何已知文件都无法对应,包括尝试保留尾部识别头的总固件本体。从更底层的bin固件分析来看,zeppos的校验算法很全,在fw,update等相关上下文的多是crc校验,也有key的迹象。但是很可惜就算确定了私钥,我们也无从得知这个算法,至于验证的应该是filehash那个文件,因为刷写在解压完后报错。米坛过桥米线开发组目前将该项目搁置,如果有大佬能接手那就是好事
 
社区团队曾经研究过,在最后步骤压缩zip后,还要hex加文件尾,从位数看很有可能是sha256及crc32校验,但是与任何已知文件都无法对应,包括尝试保留尾部识别头的总固件本体。从更底层的bin固件分析来看,zeppos的校验算法很全,在fw,update等相关上下文的多是crc校验,也有key的迹象。但是很可惜就算确定了私钥,我们也无从得知这个算法,至于验证的应该是filehash那个文件,因为刷写在解压完后报错。米坛过桥米线开发组目前将该项目搁置,如果有大佬能接手那就是好事
有没有这样一种可能
重新写一个fliehash副本让手环检验
既然update script里写的校验是filehash
不如将其改成filehash1的同时源文件不动
让其他检验机制验原来的filehash同时副本完成meta的检验
我不知道我也没有说清楚

实在不行硬删吧
把所有校验的东西通通删掉就好了嘛(doge)

另外“hex加文件尾”是什么
可以具体解释一下吗
 
最后编辑:
社区团队曾经研究过,在最后步骤压缩zip后,还要hex加文件尾,从位数看很有可能是sha256及crc32校验,但是与任何已知文件都无法对应,包括尝试保留尾部识别头的总固件本体。从更底层的bin固件分析来看,zeppos的校验算法很全,在fw,update等相关上下文的多是crc校验,也有key的迹象。但是很可惜就算确定了私钥,我们也无从得知这个算法,至于验证的应该是filehash那个文件,因为刷写在解压完后报错。米坛过桥米线开发组目前将该项目搁置,如果有大佬能接手那就是好事
社区团队曾经研究过,在最后步骤压缩zip后,还要hex加文件尾,从位数看很有可能是sha256及crc32校验,但是与任何已知文件都无法对应,包括尝试保留尾部识别头的总固件本体。从更底层的bin固件分析来看,zeppos的校验算法很全,在fw,update等相关上下文的多是crc校验,也有key的迹象。但是很可惜就算确定了私钥,我们也无从得知这个算法,至于验证的应该是filehash那个文件,因为刷写在解压完后报错。米坛过桥米线开发组目前将该项目搁置,如果有大佬能接手那就是好事
就是底包里有两个filehash(以下简称fh)
一个原fh 一个fh1
将update script里的校验文件改成fh1进行meta的校验
同时其他校验机制校验原先的fh保证通过
我没有测试过这个方法是否有效
也不知道修改updatescript里校验文件的地址会不会导致后续校验文件地址更改成fh1导致校验失败
烦请大佬研究
 
能不能从米环的recovery环境入手呢
就是那个restoring system
既然会从手机传输固件写进去
应该会绕过手环的检验机制吧
替换法 或者用gadgetbridge伪造一个zepp环境吧……
 
固件本来就是rec环境更新的,不行
小程序拿得到权限能修改系统文件吗
不行的话 也没招了

要不把手环里面存储芯片拿出来
有没有读芯器能读写内容的
或者…… 罢了吧
 
小程序拿得到权限能修改系统文件吗
不行的话 也没招了

要不把手环里面存储芯片拿出来
有没有读芯器能读写内容的
或者…… 罢了吧
这,属实是异想天开了
 
Screenshot_2023-05-21-15-28-57-258_com.android.chrome-edit.jpgScreenshot_2023-05-21-15-24-03-288_com.android.chrome-edit.jpg
翻一下专利可能有帮助
第一个就是校验问题的“算法”
第二个猜测应该就是filehash
我去翻一翻算法是什么 有没有描述
 

*这是一则由 Google AdSense 自动推荐的广告,与本站无关,不对其真实性与可靠性负责

相似主题

Home 首页
Home 资源
News 发现
Account 我的
顶部