抬头仰望星空,是否能发现自己的渺小。

伪斜杠青年

人们总是混淆了欲望和理想

关于ROM修改-偶然的一次独辟蹊径

我大多数编程的本事都用在了实现自身的需求上了,正如置顶的ROM打包解包一样,我只想要一个符合需求的纯净的ROM

恰好几个月前,遇到了一种无法挂载的system.patch.dat,很多人都知道需要去配合system.transfer.list来进行解包后方能修改。记录下我的思考流程

首先,遇到的问题:

正常思维:使用sdat2img.py将system.new.dat转换为system.img,然后挂载进行修改

结果:修改失败

过程:使用fdisk -l查看转换后的img,显示正常

Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)

使用file命令检测生成的system.img检测,显示data正常,属于可挂载img

猜想:是不是因为转换后的system.img存在偏移量?(使用fdisk -l无法看到任何分区)

猜想:是不是因为system.transfer.list进行了修改导致无法转换正常?(和官方对比一模一样,刷机也不会异常)

猜想:update-script做了特殊处理?(查看并无两样)

思考(胡思乱想):难道ROM作者的水平以经到了如此地步,将文件格式玩到了出神入化的层次?(据我所知,这并不是一种简单事)

过去数月,再次尝试,结果是system.new.dat已经就是可挂载的img并不是新的new.dat格式。

出现这种问题的原因:1,对于这些的思考太过于流程化 2,思维不够天马行空 3,转换以及生成后的img挂载无任何错误提示(挂载后看不到任何文件(ls -a))

最后的解决方案仅仅是:

偶然发现 file system.new.dat 

system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)

本身也就是ext4,直接挂载解决。

不得不说,作者的障眼法,用的很好,今天偶然想起才做了这么一个思维转变。又涨经验了。

你苦苦追寻的真相,其实离你很近,只不过蒙着一层面纱。


本站由以下主机服务商提供服务支持:

0条评论

发表评论