昨天,今天,明天,每天的每天,你是否都多懂得一点点...

星期日, 三月 11, 2018

Sign update.zip for MiRecovery

小米盒子增强版成功降级后, 又可以Root了. Root了以后我便想安装其它的版本. 因为降级后的版本 1.3.112d是一个不可以升级的版本, 我怕1.3是不是有点太老, 升到1.4会不会好些?

于是我便从这里下载了一个被修改过的小米recovery. 


可是我却发现它并不能用, 因为我想用他刷一个石头论坛以前下的小米1.3.72的固件的时候,刷失败了. 显示签名错误. 我明明记得我是用那个固件从石头的系统恢复回小米系统的.

于是我从石头的刷机工具里面提取了recovery, 并成功的刷入了1.3.72的固件包. 所以我就开始以为那个mirecovery 跟本没用.

但是后来,我又在这个页面找到了可以用这个recovery 刷的固件包


于是我就纳闷了, 怎么这些包又可以刷了, 这些包也不是官方包呀! 后来我发现, 原来1.3.72那个固件没有签名, 所以刷不了. 而石头中提取的recovery好像只能刷没签名的包,签了名反而不能刷. 所以就是说, 只要把包签名了, 这个mirecovery 还是能用的.

今天正好想试试自己打包update.zip 文件. 

开始也没有查资料, 先用现有的知识做个签名.

先生成一个keystore
keytool -genkey -v -keystore recovery.keystore -alias feng_recovery -keyalg RSA -keysize 2048 -validity 10000

然后用jarsigner 签名
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore recovery.keystore update.zip feng_recovery
Enter Passphrase for keystore:
   adding: META-INF/MANIFEST.MF
   adding: META-INF/FENG_REC.SF
   adding: META-INF/FENG_REC.RSA
   adding: system/
  signing: system/test.txt
jar signed.

签完名得到一个这样的结构


拿去recovery试,  直接就废.

E:footer is wrong
E:signature verification failed


于是上网找到这个教程.




用openssl 来生成公私钥
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem
openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt

​​
用 signapk.jar 来签名, 而不是jarsigner

java -jar signapk.jar certificate.pem key.pk8 update.zip signed-update.zip


这次的结构对了, 因为CERT.RSA, CERT.SF 的文件名对了, 跟其它我用过的包一样, 说明 signapk.jar 用对了.

再拿去试, 还是一样的错误.

然后我查了一个可以用的update.zip包的签名, 用的是signapk.jar 自带的那个testkey.


Use jarsigner, I found out it's using the testkey come with SignApk.jar
jarsigner -verify -verbose -certs  update.zip

Key for signed_update_1.3.102.2024.zip

      X.509, EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
      [certificate is valid from 29/02/08 2:33 PM to 17/07/35 1:33 PM]
      [CertPath not validated: Path does not chain with any of the trust anchors]


好吧,我也用这个key 好了.
java -jar signapk.jar testkey.x509.pem testkey.pk8 update.zip signed-update.zip

然后查一下, 查出来的信息一模一样了.


X.509, EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
      [certificate is valid from 29/02/08 2:33 PM to 17/07/35 1:33 PM]
      [CertPath not validated: Path does not chain with any of the trust anchors]

去试试, 我X, 还是这个错误, 有没有搞错,我到底哪里没弄对....
Still got the following error.

E:footer is wrong
E:signature verification failed
Installation aborted.

然后有人说 footer is wrong 是因为 zip 文件没有comment. 不会吧....

Someone mentioned that footer is wrong is caused by the zip comment.

查一下可用的那个包, 还真有comment


fengnz@mac:~/Downloads > unzip -z signed_ota-fixer_1.3.102.2024
Archive:  signed_ota-fixer_1.3.102.2024.zip
signed by jBART (BurgerZ)
而我做的包没有


There is no comment for my zip file

fengnz@mac:~/Documents/recovery_learn > unzip -z signed-update.zip
Archive:  signed-update.zip

行, 小事,我也加comment

fengnz@mac:~/Documents/recovery_learn > zip -z signed-update.zip
enter new zip file comment (end with .):
Signed By YuFeng Deng.
.
fengnz@mac:~/Documents/recovery_learn > unzip -z signed-update.zip
Archive:  signed-update.zip
Signed By YuFeng Deng.

加完后...还是一样...


Still same error

好吧, 我注意到它是用jBART签的名, 所以下载个jBART来用



I found that the file it created is 2K bigger than my one

签好后, 查一下comment, 跟可用的那个包一样了

fengnz@mac:~/Documents/recovery_learn > unzip -z signed_update.zip
Archive:  signed_update.zip
signed by jBART (BurgerZ)

再查一下签名, 对, 用的就是 那个testkey

jarsigner -verify -verbose -certs signed_update.zip

   X.509, EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
      [certificate is valid from 29/02/08 2:33 PM to 17/07/35 1:33 PM]
      [CertPath not validated: Path does not chain with any of the trust anchors]

这回拿去试, 居然成功了!!!
Now Success

到底哪里不一样? 我也是这么签的呀? 为什么它签出来会大2K?
What's the difference between jBART sign and my own sign? The same keys are used?

我之前如果签名不对, 出的错误是"Fail to verify whole-file signature". 这回没有这么说, 所以说明whole-file signature是好的. 只是footer 错了. 那什么是footer?
It doesn't say "Fail to verify whole-file signature". Means the whole-file signature is Ok. The error is caused by the footer. What's the footer here?

然后我发现了这篇文章. 明白footer其实是在查这个zip 包的倒数第三个和第四个字节. 如果这个字节不对, 说明没有whole-file signature, 所以不是说whole-file signagure是好的, 而是跟本没有, 所以不查, footer 直接fail.

The recovery program check the footer to make sure the whole-file signature is existing. If not, it doesn't go future and throw signature failure.





然后发现其实签名还分两种, 一种是对压缩包里面的每个文件进行签名, 另一种是对整个压缩包签名, 就是所谓的whole-file signaure. 

signapk.jar 默认不做whole-file signature, 需要加 -w 参数. 

可是我的signapk.jar 不支持这个参数呀, 我早就查过了.


fengnz@mac:~/Downloads > java -jar signapk.jar
Usage: signapk publickey.x509[.pem] privatekey.pk8 input.jar output.jar

There is not -w option

然后我只好上网继续找支持 -w 的signapk.jar

The first version I found was a 7.2K signapk.jar

最后终于找到了...
I then searched hard on the internet and finally found a 9K signapk.jar which supports -w option


这个有 -w 参数耶
fengnz@mac:~/Documents/recovery_learn > java -jar signapk.jar
Usage: signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar

然后

 java -jar signapk.jar -w testkey.x509.pem testkey.pk8 update.zip signed-update.zip

成功了, 签名来的文件大小和 jBART 一样大. 试了一下, 可以用.

然后我试了下最开始自己用openssl 生成的key, 不行. 一定要用testkey.

好了...花了好几个小时, 终于解开了这个迷团. 上网查, 大家都说是因为你自签名的包不能用在stock recovery. 就没有人说到是因为忘了使用-w 参数而没有 whole-file signature. 



--
Feng

星期五, 三月 09, 2018

其实我做得还不错,3个月拿下一千订阅

对比一下其它人,我居然属于快的那一种。慢的人居然要花上两三年才能达到1000订阅。快的有六周的。

Youtube上不少视频教人1周达到1000订阅。。。都是骗人的,我看了也没啥用处。。。





--
Feng

一千订阅了,Mark






--
Feng

星期四, 三月 08, 2018

小米盒子增强版-两个Recovery界面清空数据的效果不一样

小米盒子增强版

两个Recovery界面清空数据的效果不一样

之前尝试卡刷Supersu, 卡刷结果是成功, 可是刷完重启后, supersu 没有出现,却出现了很多问题, 比如:

Home键不工作了
不能安装应用 
不能删除应用
不能投屏神器



在可以卡刷的界面里 (使用 xiaomi_update 文件进入),无法彻底清楚用户数据, 之前刷supersu 引起的问题不能解决
在默认recovery界面里则可以



--
Feng

星期日, 三月 04, 2018

Dump and read system image from mibox2



// To get all the partition names:

root@dredd:/dev/block/platform/aml_sdio.0 # ls -l
lrwxrwxrwx root     root              2023-05-15 15:28 boot -> /dev/block/boot
lrwxrwxrwx root     root              2023-05-15 15:28 boot1 -> /dev/block/boot1
lrwxrwxrwx root     root              2023-05-15 15:28 bootloader -> /dev/block/bootloader
drwxr-xr-x root     root              2023-05-15 15:28 by-num
lrwxrwxrwx root     root              2023-05-15 15:28 cache -> /dev/block/cache
lrwxrwxrwx root     root              2023-05-15 15:28 data -> /dev/block/data
lrwxrwxrwx root     root              2023-05-15 15:28 env -> /dev/block/env
lrwxrwxrwx root     root              2023-05-15 15:28 logo -> /dev/block/logo
lrwxrwxrwx root     root              2023-05-15 15:28 misc -> /dev/block/misc
lrwxrwxrwx root     root              2023-05-15 15:28 mmcblk0 -> /dev/block/mmcblk0
lrwxrwxrwx root     root              2023-05-15 15:28 mmcblk0p1 -> /dev/block/mmcblk0p1
lrwxrwxrwx root     root              2023-05-15 15:28 mmcblk1 -> /dev/block/mmcblk1
lrwxrwxrwx root     root              2023-05-15 15:28 mmcblk1boot0 -> /dev/block/mmcblk1boot0
lrwxrwxrwx root     root              2023-05-15 15:28 mmcblk1boot1 -> /dev/block/mmcblk1boot1
lrwxrwxrwx root     root              2023-05-15 15:28 panic -> /dev/block/panic
lrwxrwxrwx root     root              2023-05-15 15:28 persist -> /dev/block/persist
lrwxrwxrwx root     root              2023-05-15 15:28 recovery -> /dev/block/recovery
lrwxrwxrwx root     root              2023-05-15 15:28 reserved -> /dev/block/reserved
lrwxrwxrwx root     root              2023-05-15 15:28 system -> /dev/block/system
lrwxrwxrwx root     root              2023-05-15 15:28 system1 -> /dev/block/system1



// To dump the system partition to a image file
root@dredd:dd if=/dev/block/system of=/storage/sdcard1/system.img                                                 
1310720+0 records in
1310720+0 records out
671088640 bytes transferred in 419.644 secs (1599185 bytes/sec)
root@dredd:/dev/block/platform/aml_sdio.0 #

// Now you can use the USB Drive to copy the system image file to a computer 

// And you can also view the content of the image. The following method is on mac os.

// To attach image file as disk partition

fengnz@mac:/Volumes/SONY_8M1/root > hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount system.img
/dev/disk6


// To mount the partition to a mount point

fengnz@mac:/Volumes/SONY_8M1/root > mkdir /Volumes/ext4
fengnz@mac:/Volumes/SONY_8M1/root > sudo mount -t fuse-ext2 /dev/disk6 /Volumes/ext4
fengnz@mac:/Volumes/SONY_8M1/root > sudo ext4fuse -o allow_other /dev/disk6 /Volumes/ext4/

Now you can access the file




​// To detach the image ​

fengnz@mac:/Volumes/SONY_8M1/root > hdiutil detach disk6
"disk6" unmounted.
"disk6" ejected.


--
Feng

订阅达到888

这么吉利的数字, mark一下.




--
Feng

星期六, 三月 03, 2018

Putty MAC OS 中文乱码解决

用PUTTY连到MAC OS上的时候,中文会乱码
这时候直接输入以下命令,再ls 就正常了,立即生效。
 export LANG=zh_CN.UTF-8




--
Feng

Fix Package Installer missing from Android Mibox2 MDZ-09-AA

也不知道什么原因, 可能是我用Recovery 刷SuperSu失败, 然后我的小米盒子不能安装APK了... 就是打开高清播放器里面的U盘APK, 点击没有反应. 

还好还能用ADB安装软件.

我把盒子降级也没用, 降级再用系统自带的升级升完后也一样, 这太不科学!!!

我用ADB安装了一些软件, 用SManger 安装APK的时候, 会出现找不到打开方式的错误.

然后我用LINK2SD看了一下, 居然没有找到 Package Installer. 太不科学了. 按理来说刷机后, 什么都应该被还原了呀. 

我打开小米盒子3增强版, 然后发现里面是有MiPackageInstaller的, 在 /system/pri-app/ 里面.

然后我打开小米盒子增强版的升级包, 翻了一下, 发现有 PackageInstaller.apk, 但位置不一样, 在/system/app, 里面.


于是adb shell 进盒子里, 看到里面的确有 PackageInstaller.apk, 但却不能用. 

于是我用adb pull 把这个包抓出来, 马上用adb install 装回去. 再回到 Link2Sd, 出来了!!!!

我再用Link2Sd 把这个应用转成系统应用, 重启盒子. 我可爱的APK安装程序回来了!!!




--
Feng

星期五, 三月 02, 2018

A interesting finding of mibox 2 recovery

I used stock rom to downgrade my mibox 2 to 1.3.112d (to system 1) then rooted it with 360 root.


On MDZ-09-AA, I flashed a modified mirecovery:

MiRecovery_5.5.29.1567.zip

Then I entered recovery and can see that my recovery has been reduced from version 6 to version 5.

Then I reboot to system 2. (black screen)

Then I cut the power and reentered recovery, I then saw the recovery was back to 6.

Then I reboot to system 2 again, now this time, I can enter system2. And the system 2 is 1.5.8

Then I reboot to system 1, system 1 is still 1.3.112d.



--
Feng

A Rough log of android recovery img

Adb shell 

// To check the current system mount

root@endeavoru:/proc # cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,seclabel,relatime,user_xattr,acl,barrier=0,data=ordered 0 0

root@endeavoru:/ # mount | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,seclabel,relatime,user_xattr,acl,barrier=0,data=ordered 0 0


root@endeavoru:/system # busybox mount | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP on /system type ext4 (ro,seclabel,relatime,user_xattr,acl,barrier=0,data=ordered)


What's the difference between busybox mount and mount?

// To make root folder writable

127|root@endeavoru:/ # mkdir a
mkdir failed for a, Read-only file system
255|root@endeavoru:/ # mount -o remount,rw /
root@endeavoru:/ # mkdir a
root@endeavoru:/ # ls
root@endeavoru:/ # mount -o remount,ro /
root@endeavoru:/ # mkdir b
mkdir failed for b, Read-only file system
255|root@endeavoru:/ # mount -o remount,rw /
root@endeavoru:/ # rmdir a

// To find out which partition is recovery 

root@endeavoru:/ # cat /cache/recovery/last_log |grep recovery
Starting recovery on Fri Feb 23 13:00:26 2018
recovery filesystem table
  1 /recovery emmc /dev/block/mmcblk0p5 (null) 0

root@endeavoru:/ # cat /cache/recovery/last_log | more
Starting recovery on Fri Feb 23 13:00:26 2018
can't open /dev/tty0: No such file or directory
framebuffer: fd 3 (720 x 1280)
recovery filesystem table
=========================
  0 /tmp ramdisk (null) (null) 0
  1 /recovery emmc /dev/block/mmcblk0p5 (null) 0
  2 /boot emmc /dev/block/mmcblk0p4 (null) 0
  3 /cache ext4 /dev/block/mmcblk0p13 (null) 0
  4 /data ext4 /dev/block/mmcblk0p15 (null) 0
  5 /sdcard vfat /dev/block/mmcblk0p14 (null) 0
  6 /system ext4 /dev/block/mmcblk0p12 (null) 0
  7 /misc emmc /dev/block/mmcblk0p17 (null) 0



// To List all partitions

root@endeavoru:/ # cat /proc/partitions
major minor  #blocks  name

 179        0   30535680 mmcblk0
 179        1       6144 mmcblk0p1
 179        2       2048 mmcblk0p2
 179        3       6144 mmcblk0p3


// To backup recovery 
root@endeavoru:/ # cat /dev/block/mmcblk0p5 > /mnt/sdcard/recovery.img
root@endeavoru:/ # ls -l /mnt/sdcard/recovery.img
-rwxrwx--- root     sdcard_r  8388608 2018-03-01 11:03 recovery.img

// Use adb pull to download the backup recovery.img file
fengnz@mac:~/HTC_One > adb pull /mnt/sdcard/recovery.img .
/mnt/sdcard/recovery.img: 1 file pulled. 0.6 MB/s (8388608 bytes in 13.321s)


// To download unmkbootimg go to


// To show image info (docker usage is off topic here)

docker cp unmkbootimg ubuntu:/root/
docker cp recovery.img ubuntu:/root/
docker exec -it ubuntu bash
cd root

root@072407a24838:~# ./unmkbootimg recovery.img
unmkbootimg version 1.2 - Mikael Q Kuisma <kuisma@ping.se>
Kernel size 5197608
Kernel address 0x10008000
Ramdisk size 2171498
Ramdisk address 0x11000000
Secondary size 0
Secondary address 0x10f00000
Kernel tags address 0x10000100
Flash page size 2048
Board name is ""
Command line ""
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
  mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz -o new_boot.img
---------------


// To copy the ramdisk file out

fengnz@mac:~/HTC_One > docker cp ubuntu:/root/initramfs.cpio.gz .

// You can unzip this file and check the content




You can't mount a recovery image as it's not a regular file system. Read this for more info.



Check the res/images folder, you will see a bunch of images which may tell you where this recovery comes from.



// To unzip it in ubuntu docker
root@072407a24838:~# mkdir ramdisk
root@072407a24838:~# cd ramdisk/
root@072407a24838:~/ramdisk# apt-get install cpio
root@072407a24838:~/ramdisk# gunzip -c ../initramfs.cpio.gz | cpio -i
6419 blocks
root@072407a24838:~/ramdisk# ls
data           init                        res             system
default.prop   init.rc                     sbin            tmp
dev            init.recovery.endeavoru.rc  seapp_contexts  ueventd.goldfish.rc
etc            proc                        sepolicy        ueventd.rc
file_contexts  property_contexts           sys


You can modify the ramdisk files and repack it with the following command. 

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

root@072407a24838:~/ramdisk# find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
6419 blocks
root@072407a24838:~/ramdisk# cd ..
root@072407a24838:~# ls
initramfs.cpio.gz   ramdisk  recovery.img  zImage
newramdisk.cpio.gz  rec      unmkbootimg
root@072407a24838:~# ls -l
total 18100
-rw-r--r--  1 root root    2171498 Mar  1 23:06 initramfs.cpio.gz
-rw-r--r--  1 root root    2180261 Mar  1 23:48 newramdisk.cpio.gz


// Use this docker container for mkbootimg

// Run mkbootimg docker container

docker run -it -d --name mkbootimg --privileged=true --volume $(pwd)/kernel:/kernel dvitali/android-build-tools


// Move file from ubuntu container to this one

docker cp ubuntu:/root/ temp
fengnz@mac:~/HTC_One > docker cp temp/root mkbootimg:/
fengnz@mac:~/HTC_One > docker exec -it mkbootimg bash

cd root
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage --ramdisk newramdisk.cpio.gz -o mynewimage.img

root@2008c25fe133:~# ls -l
total 25308
-rw-r--r--  1  501 dialout 2171498 Mar  1 23:06 initramfs.cpio.gz
-rw-r--r--  1 root root    7380992 Mar  2 00:31 mynewimage.img
-rw-r--r--  1  501 dialout 2180261 Mar  1 23:48 newramdisk.cpio.gz
drwxr-xr-x 11  501 dialout    4096 Mar  1 23:48 ramdisk
drwxr-xr-x  2  501 dialout    4096 Mar  1 22:24 rec
-rw-r--r--  1  501 dialout 8388608 Mar  1 22:06 recovery.img

A new image is created, but it's smaller than original. I am not sure whether it's correct.


--
Feng

Just a record of my home fibre network speed




--
Feng

Register 4pda.ru

I was trying to download an attachment from 4pa.ru site.

when I downloaded, I got the following error:




I thought that this file was too old and had been removed and tried to find this file from other resources. But then I found out from other site saying that I just need to login to download.


But when I tried to register, I was stuck with the verification code.



This is a four digit number written in Russian.

I found a page to look at its meaning.


Even with this page, I spent more than 20 minutes to figure out a correct number. I have tried many times...


But finally, I got it registered and downloaded what I need.


--
Feng

星期四, 三月 01, 2018

A wield mongodb serialization issue caused by hidden property

This line throw exception.


Here is the exception detail



The problem is caused by 


The reason to use the new keyword is to hide the Name property in the base calss which has a required attribute. The new keyword will override the require attribute so that Name will not be validated.

The name in base class is hidden, but when mongo does serialization, it will found two names, so it causes the problem. The error message is confusing anyway. It's nothing to do with Id.


--
Feng

小米盒子1G增强版(MDZ-09-aa)卡刷降级到1.3.112d




小米盒子1G增强版,经过几次升级,不管系统1还是系统2,都是最新的1.5.8稳定版。我便想要卡刷降级。

不得不说, 这是一件很简单的事, 但我确走了不少弯路,花了好几天的时间才找到方法.
这一切,都是一根OTG线引起的。

因为小米盒 子1G增强版有OTG接口,但也有标准USB接口,而且还有TF卡插槽。所以我卡刷的时候,第一个想到的是USB口,方便嘛。 于是我把刷机包放在U盘里面,插入USB口, 可是无论怎么样,Recovery 都无法侦测到刷机包。 我换了好几个刷机包,又把xiaomi_update里面的内容改了又改,都没有用。 然后我想是不是一定要用TF卡,卡刷嘛,要用卡。 可是TF卡也没有用。捣鼓了两天以后,我基本上就放弃了。我猜测是不是因为Recovery经过几次升级,已经不认以前旧的ROM了,如果是这样,我就没啥好捣鼓的了。


有一天我在研究小米盒子3增强版 (18-AA)的ADB模式的时候,发现只有其中一个USB口有用,另一个USB口是不能用的。 于是我灵光一闪,1G增强版是不是也是这样,只有OTG那个口才有用。

于是,我就试了,拿了一根OTG数据线,还是那个U盘,我靠, 直接就进去开刷了。


当然,刷机失败,签名效验失败了。但至少,刷机包被侦测到了。

于是我又换了几个刷机包,全都是签名失败。

我的心又凉了,我想,怎么回事,我用的明明是官方的刷机包,其中有一个包我之前还刷过。我之前刷过石头ROM,由于石头团队解散了,再也不升级了,于是我又刷回了官方包。 这个官方包自动升级,后来升到1.5.8超多广告,超卡版。。。

所以我坚信我用的那个包没有问题。所以我认为是因为随着小米盒子的几次升级,Recovery也被升级了,而且私钥也被换了,所以不能降级。如果是这样的话,那一却又没戏了。

但我还是试了几个ROM,都失败。 有一个更可笑,明明网页上说是增强版的降级,我下载下来的包却是新小米盒子的,也就是06-AA的版本。刷的时候,出来Assert fail, 因为增强版的内部代码是 Dredd,而新小米盒子的内部代码是 Casablanca 。 

当我看到屏幕上出现 Casablanca 的时候,我都无奈了。可是,可是,我突然发现,我不应该看到 Casablanca , 因为如果签名验证没过的话,我跟本走不到这一步,我再认真的在屏幕上一看,发现这个ROM的签名其实没有出错,签名过了,出错在ROM的版本不对。而这个ROM是比增强版更旧的ROM,如果它能过,那私钥肯定没有换,那我原来刷过的那个ROM不过就太没有道理了。 

我打开 Casablanca那个ROM,看了一下,的确是06-AA的ROM。

The certificate used to sign Casablanca for 06-AA, which pass my  mibox2 signature validation

ro.board.platform=meson6
# ro.build.product is obsolete; use ro.product.device
ro.build.product=casablanca
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=casablanca_icntv-userdebug 4.2.2 CADEV 1262 release-keys
ro.build.fingerprint=MI/casablanca_icntv/casablanca:4.2.2/CADEV/1262:userdebug/release-keys

用 jarsigner 看了一下,查到以下私钥信息


 X.509, L=Mountain, ST=California, C=US
      [certificate is valid from 1/04/13 4:08 PM to 17/08/40 3:08 PM]



后再用jarsigner 看了一下我没有通过验证的那几个ROM, 发现这几个ROM根本没有签名,并不是我一直认为是的官方ROM。 之前石头ROM能刷回来是因为石头ROM的Recovery 不会验证签名. 这个ROM的内容的确是官方ROM,但是却是被人重新打包过的没签名版。
​​
​​
​​

The 09-aa Rom I downloaded from somewhere


fengnz@mac:/Volumes/1/MY/xiaomi/09-AA-ROM > jarsigner -verify -verbose -certs update.zip
jarsigner: java.lang.SecurityException: SHA1 digest error for system/etc/install-recovery.sh

我再用jarsigner  看了一下小米盒子3增强版的官方ROM,用的是同一个私钥


fengnz@mac:/Volumes/1/MY/xiaomi/18-AA-1.4.6_ROM2 > jarsigner -verify -verbose -certs update.zip



X.509, L=Mountain, ST=California, C=US
      [certificate is valid from 1/04/13 4:08 PM to 17/08/40 3:08 PM]


至此,我确定我之前下的所有的所谓"官方ROM" 全他妈都不是官方的。

于是我又在茫茫互联网开始寻找官方ROM。没有在中文的网站上找到,终于在这里找到。

finally, downloaded the right one from here



验证一下,私钥正确
​​


fengnz@mac:/Volumes/KINGSTON > jarsigner -verify -verbose -certs update.zip

X.509, L=Mountain, ST=California, C=US
      [certificate is valid from 1/04/13 4:08 PM to 17/08/40 3:08 PM]



后, 复制到U盘,进入Recovery,就自动开始刷了。一次成功!!!

刷完是1.3.112d, 应该可以再下载两个升级包更新的稳定版
​​
​​
(我没试)

download the update from


用360超级ROOT手机版可以ROOT

Root完可以刷第三方Recovery, 然后一切皆有可能。

Mi recovery

​哎,不得不说,要感谢那些把资源整在一起的作者,找对了资源后,会少走很多弯路,下错版本,是致命的。


--
Feng

星期一, 二月 26, 2018

Download blocked attachment from Gmail

Gmail has an awesome feature of scanning attachment before downloading.  But sometimes, it gives a false negative result. 


If you have an attachment which you know that it is safe to download, but Gmail doesn't allow it, what can you do?


Go to the upright corner of Gmail body and click the triangle icon then click "Show original"



Then click "Download Original"




The file you downloaded will be a txt file

rename the downloaded file to original_msg.eml

then double click it to open with outlook (you must have outlook installed).



Now you can then download it from outlook.


If you have a small file and don't have security concern

you can open the txt file and past the base64 code to online base64 converter such as 


then download the binary from there.

This way, you don't need to have outlook.




--
Feng

其它博客地址

此博客的同步博客地址: http://fengnz.wordpress.com
这里进入我的MSN SPACE.