本帖最后由 數(shù)碼小天才 于 2023-2-22 20:12 編輯
圖片1.png (85.45 KB, 下載次數(shù): 151)
下載附件
保存到相冊(cè)
2023-2-22 13:24 上傳
這個(gè)刷機(jī)包就是把安卓系統(tǒng)的所有的文件數(shù)據(jù)塊,在每個(gè)數(shù)據(jù)庫(kù)前面加上標(biāo)識(shí)符(4字節(jié))和校驗(yàn)位(4字節(jié))后按照順序捏到一塊去,當(dāng)然了,最前面加了個(gè)數(shù)據(jù)頭。用UE打開bin格式的刷機(jī)包,其數(shù)據(jù)頭部的第8-11個(gè)字節(jié)指定了數(shù)據(jù)頭的長(zhǎng)度:0x234就是7093這個(gè)刷機(jī)包頭部的長(zhǎng)度,從第0x234個(gè)字節(jié)開始就是安卓的文件了,比如第一個(gè)應(yīng)該是fastboot.bin文件。7093的系統(tǒng)文件格式應(yīng)該是:(blkdevparts=mmcblk0:1M(fastboot),1M(bootargs),18M(panelparam),2M(deviceinfo),1M(tpvnVRam),25M(recovery),40M(logo),30M(kernel),1M(dtb),2M(atf),25M(trustedcore),10M(securestore),1M(versioninfo),1M(misc),10M(bootmusic),10M(bootmusicsec),3072M(system),20M(atv),100M(cache),8M(factorydata),100M(fastplay),-(userdata) mmz=ddr,0,0,100M)。當(dāng)然不一定全部都能找到對(duì)應(yīng)的塊,它有可能含會(huì)在system.img文件里面。比如,2M(deviceinfo),1M(tpvnvram),這兩個(gè)可能就沒有。這些有的、沒有的都在數(shù)據(jù)頭里面有定義,包括每一個(gè)數(shù)據(jù)塊的啟示地址,數(shù)據(jù)長(zhǎng)度都有定義。只不過它的數(shù)據(jù)長(zhǎng)度里面不包含標(biāo)識(shí)符(4字節(jié))和校驗(yàn)位(4字節(jié))。然后最大的那個(gè)個(gè)數(shù)據(jù)塊就是system.img,提取數(shù)據(jù)的是從0x047a2817+8開始,不要包含8字節(jié)頭,長(zhǎng)度就是0x57A323E8,這個(gè)數(shù)據(jù)塊就是完整的system.img,提取出來后可以被ROM編輯工具認(rèn)出來,比如蘑菇ROM助手。然后就可以通過rom助手編輯了。
圖片2.png (116.3 KB, 下載次數(shù): 145)
下載附件
保存到相冊(cè)
2023-2-22 13:24 上傳
老實(shí)說,數(shù)據(jù)頭里面的信息還有很多,我也沒搞清楚作用。頭四個(gè)字節(jié)是頭部標(biāo)志(LOAD)接下來的是CRC32校驗(yàn)碼,應(yīng)該不是整個(gè)rom包的校驗(yàn)碼。因?yàn)槲乙婚_始替換了system.img后,刷機(jī)開始沒保持,到80%的時(shí)候卡住了,因?yàn)槲覄h了好寫東西,實(shí)際長(zhǎng)度差不多就80% ,然后我沒改頭部的數(shù)據(jù)長(zhǎng)度,所以它一支在讀文件,但是文件已經(jīng)讀完了,就卡在哪里了,然后我改了第16字節(jié)開始的數(shù)據(jù)長(zhǎng)度,一開始刷機(jī)就報(bào)錯(cuò)了,肯定是頭部校驗(yàn)沒通過嗎。后續(xù)我在system.img里面補(bǔ)零,補(bǔ)足數(shù)據(jù),然后改數(shù)據(jù)庫(kù)的校驗(yàn)碼,刷機(jī)進(jìn)度到100% ,但是破壞了數(shù)據(jù)了,也是失敗變磚。 做一個(gè)假的專門湊長(zhǎng)度用的apk加到system.img里保證長(zhǎng)度不變,是可行的。所以,這個(gè)數(shù)據(jù)包是分塊校正的。頭部的的校驗(yàn)就是這0x234個(gè)字節(jié)的校驗(yàn),后面數(shù)據(jù)塊的CRC校驗(yàn)采用32位(CRC32/MPEG-2)校驗(yàn)。前面應(yīng)該也是,但是對(duì)不上。 拋磚引玉吧。
|