Nexus one OTA之路.

  某天为了刷Nexus one 的OTA,折腾了许久.
  
  本来如果没去刷root的话,这会是件很简单容易的事情.
  但无奈有签名机制在.
  root过的boot.img签名对不上,于是总是卡在签名验证失败那个环节.
 
  尝试把脚本里的签名验证去掉,却发现脚本本身的签名不正确了.
  无奈.

  google了一下,似乎有人放出来用来签名的东西,于是download之.
  打个包,签名一下,reboot,recovery.
  依然失败.

  翻了翻开发文档,惆怅地发现这套机制是基于RSA的.
  查了查网上零碎的资料之后,也终于明白为什么这个OTA包会带sign这个字眼来.

  因为RSA的私钥似乎是硬编码进去的.
  也就是说,你想自己打包,然后妄图通过验证.
  那应该是不可能的.

  为什么说应该,因为其实我也没认真看它如何验证签名的.
  
  因为即使不能绕过签名,也能够通过手工的方法把OTAupdate过去.
  毕竟已经对bootloader解锁了,可以用fastboot写rom.

  问题在于,出签名错误的东西叫boot.img.
  
  可以把所有东西都flash进去,但是结果可能是boot不起来了.
  因为boot.img没刷.
  谁知道不同的boot.img会造成什么影响.
  
  如果到时连fastboot都不work了,那Nexus one就成纸片了.
  
  称呼砖头或许不确切.

  于是,先考虑下有没把握搞定boot.img.
  
  OTA下面有个boot.img.p.
  
  从名字上看应该就是boot.img了.
  即使不是,也应该相差不远.

  但是它真的是boot.img么?
  
  不知道.

  于是看源代码去.

  刷机的过程是从recovery进去了,于是就找了recovery来看.
  也于是,终于有打开了千年未启动过的visual studio.

  简单Ctrl+c,Ctrl+v完事.
  毕竟只是读,不用考虑编译什么的问题.
  error和warning都不用管,只管找到main就好了.

  浏览一遍,明显看到install_package和maybe_install_firmware_update这两个函数.
  
  在install_package里,主要做了RSA的签名验证,以及读取update.zip.

  签名的东西就不去管它了.
  一个安全机制方面的东西,无伤大雅.

  看看handle_update_package.
  里面短短几行.
  
  说几行其实还说说多了.
  出去容错处理之类的,有内容的也就try_update_binary这个函数的调用.

  在这个函数里,首先会把zip文件里的 META-INF/com/google/android/update-binary复制到/tmp/update-binary下面.
  这些东西都是硬编码进去的.
  也就是说,其实如果你要自己打包更新的话,也必须有这个update-binary,并且放在同样的目录结构里.

  然后会pipe和fork一下.
  
  重点关注下子线程里的execv.
  因为此时原线程所做的只不过是接子线程的一些手尾罢了.

  execv执行的就是update-binary.
  到这里,线索似乎又断了.

  因为你不做到updater-binary做了什么.
  尤其是,你不做到update-binary到底是android的标准呢,还是依赖于厂商各自的实现.

  幸好,下面有个目录叫updater.
  又是直接main.

  终于看到updater-script的影子了.
  
  一番读文件和parse,regist之后,简化为一个邪恶的Evaluate.
  
  有时候设计模式很好,因为减少了很多重复代码.
  有时候设计模式也不是很好,因为看代码变成了找代码.

  于是只能向当年本科论文读mysql时一样,大部分靠直觉和函数名确定了.
   
  有时候,良好的命名规范还是有点用处的.

  看脚本里,除了check签名,剩下的基本就是apply_check了.
  于是,直接锁定ApplyPatchFn.

  十几二十行下来,有意义的也就大概是applypatch.
  一个extern生命又让人无奈了.

  所幸这还是可以找到的.

  一眼扫过,又见到RSA字眼,惆怅.
  跳过继续.

  结果一番对文件的处理封装之后,终于到了确定patch类型的时候.
  
  由于开始关注的是boot.img,所以很自然地直接跳到处理MTD那段.
  
  此处会检验一下patch文件,也就是哪个image.img.p文件的文件头.
  打开看了下,那个otp的文件头是IMGDIFF.
  所以patch的方式是ApplyImagePatch.

  jump into看一下.
  依然会做一个类似文件类型检测的东西,读一下头部,确定后面内容的意义.
  又打开文件看了下,十六进制里,明显是CHUNK_NORMAL.
  
  这就省事了,因为处理它的只有短短几行.
  实际上是ApplyBSDiffPatch和ApplyBSDiffPatchMem.
  到这里,原理上说,已经能够把boot.img.p变成boot.img了.
  
  但转念一想,发觉,只是不可能的.

  因为自从刷了root之后,boot.img就已经不一样了.
  也因此才导致SHA RSA等的签名错误,不能OTP升级.
  所以,即便在最后找到了patch的实现,但是到底还是依赖于原来的boot.img.

  无奈,只好放弃.
  
  本还在考虑时候要看下如何编译个boot.img的.
  于是找nexus one的源码.
 
  而恰好在XDA上有人放出了自称是N1原版镜像.
   
  当然,这个所谓"原版"还得打个问号.
  事实上,HTC似乎并没有放出来.

  鉴于XDA的权威性,也就当是原版了.
  下回来fastboot flash boot boot.img.
  刷回原来的boot.img.
 
  再按照在场的otp升级流程.
  看到verfiy过了之后的那一段,终于释然了.
  
  看来确实是原版的img.
  刷完之后看下信息,依然是android 2.1 update1.

  试了下,浏览器,map,gallary等都支持多点触摸了.
  还有就是设置里多了个关于底座的设置.
  不过这都是没多大意义的.
  毕竟没有底座.

  至于google声称的修复3G通话的问题,因为还是2G网络,也无从验证.

  不过至少,通过这个OTA,多少了解了下Android的一点东西.