爱卡汽车_中国领先的汽车主题社区、汽车资讯、汽车论坛中心哪里有187a刷机包_百度知道
哪里有187a刷机包
我有更好的答案
因此我们不建议您自行刷机。若手机因系统故障无法正常使用或自行刷机后导致手机出现问题，建议您将机器送到三星售后服务中心，由工程师帮助检查处理。由于刷机存在风险，如因自行刷机后导致的手机问题，还有可能会影响包修三星官网没有提供刷机软件
三星产品问答服务
主营：电子产品
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。正在加载验证码......
请先拖动验证码到相应位置正在加载验证码......
请先拖动验证码到相应位置自从去年买了车，对汽车电子系统的兴趣就上来了。这不，前一阵子逛汽车论坛，发现了有网友将老版本的天宝车机被刷上了2017新帕萨特车机的系统，支持超级蓝牙和苹果CarPlay，百度CarLife等功能。
没错，这台车机就是最近很火的天宝187A，据说被刷上去的新系统是属于天宝187B，而天宝187B是为在当时并未上市的2017款新帕萨特配备的。
我瞧了一眼我车上的车机型号，和天宝187A零件型号一样，都是6RD035187A，但是我这台却是德赛的。一样的型号，却有两个制造商，这很有意思，就好比有一汽大众和上汽大众一样…
在网上查了一些相关资料，得知德赛187A运行WINCE系统，没有CarPlay功能和百度Life。天宝187A运行Linux系统，也没有CarPlay功能和百度Life。但是天宝187A可以刷187B的系统，天宝187A和187B的区别仅仅是DRAM内存大小和面板按键不一样。187A是256MB 内存，而187B是512MB内存。
这就产生了一个问题，有些网友刷了系统后启动时死机，但是换了512MB内存后就正常了。由于本人对硬件也有研究，因此决定买一台天宝187A来研究一下，至于德赛……先好好地在车上服役，暂时不去虐他了…
关于天宝这个公司，也许是我才接触汽车不久，之前没有听说过。德赛倒是听说过，专门做汽车导航机器的，也给大众代工车机。江苏天宝汽车电子有限公司()，公司很低调，网站很简陋…看一下职位招聘，都招什么工程师，嗯，CAE工程师、项目工程师、电子工程师、制造工程师，就是没有软件系统工程师，那这机器软件哪来的？大众给的？外包的？此处留下疑问……
接下来我准备详细分析天宝187A的硬件系统。我从咸鱼平台上买了一台没有刷过系统的天宝187A。拆机后看到了主板。
主板正面有很多芯片，首先看电源部分。电源由汽车蓄电池直接供电，汽车启动后就是发电机供电，因此输入电压应是12-14V大概这个范围。
首先电源经过了一个STPS41H100CGY，这是一个肖特基二极管，整流作用，不关心。然后有一些大电容，大电感，背面有一个SOT23-5封装的IC，难道是DCDC？由于这部分电路靠近功放IC，不想继续追究他，无非就是一些给功放IC供电的滤波电路或者开关电路。毕竟车机接的是蓄电池，功放IC是不可能一直工作的。
接下来会看到很多电源IC，小电感，还有很多1206封装的电容，这肯定是给CPU或其他芯片供电的部分。首先负责12V转5V供电的有两个芯片。TI德州仪器SSOP-10封装的TPS54260-Q1，IC丝印是5426Q。MAXIM美信QFN-28封装的MAX16984，IC丝印是16984RA。
TPS54260是一颗宽电压输入(3.5V-60V)，2.5A电流的DCDC降压IC，在这里设计12V输入，5V输出，由于电感体积很大，大过其他几个电感，应该是主要供电。美信的MAX16984是设计给USB供电的，电流是2.5A，很高啊，看来是可以满足iPad2.1A充电的，设计的比较有良心……
往上看还有3颗电源IC，分别是两颗德州仪器QFN-16封装的TPS54388Q1，丝印5438Q，一颗安森美DFN-10封装的NCV896530，丝印是完整型号。
TPS5.95V-6V输入，3A输出。NCV.7V-5.5V输入，两路1A输出。其中一颗TPS54388-Q1负责5V转1.5V给DDR3内存供电，另一颗TPS54388-Q1负责5V转1.375V给CPU核心供电。NCV896530负责5V转1.8V和3.3V，应该是IO供电和外设供电。
靠近大插座附近有一个CAN PHY芯片，附近还有一颗电源芯片，丝印是BLW N EO，查不到具体型号，但是他附近没有电感，应该是一颗LDO降压芯片，测量结果是12V转3.3V，是给旁边这颗MCU供电的，这样大的压差使用LDO供电非常不明智…唯一的解释就是这个MCU功耗非常低，使用LDO设计上合理，成本上也合理…
分析了这么多硬件电源部分，感觉好无聊。其实在我看来分析一个系统是否成功，首先就要看他的供电设计，这部分是核心，供电设计的好不好，关乎整个系统工作是否稳定。另外，我没有看到高级电源管理IC，此处也是一个疑问，不过后面的分析可以解答这个问题。
接下来登场的是系统主要芯片。CPU是飞思卡尔（已被NXP恩智浦收购）公司的i.MX6DL，型号是MCIMX6S6AVM08AC。双核Cortex-A9，最高1G工作频率，内置2D/3D图形处理单元，具有1080p图像处理能力，支持丰富外设。看起来很强大的样子…
DRAM是南亚的NT5CB128M16FP-D1H，16位，256MB，DDR3，1.5V。
闪存使用的是Spansion的ML02G100BHA00，256Mx8 NANDFLASH，3.3V。
还有一颗QFP-100封装的芯片R7F7010253，直接搜索这个型号其实只能得知他是一颗瑞萨设计的芯片，其实他有个代号是RH850，搜这个代号能找到更多的资料，还有开发工具，但是就是找不到datasheet。
瑞萨这家公司主要设计生产MCU微控制器，汽车领域是其主要业务。
经过后面结合软件部分的一番分析得知，这个MCU的作用其实是CAN通信、硬件身份信息（零件号，序列号）、电源管理。没错，电源管理，因为汽车通信网是CAN总线，因此这款机器的电源其实也是受CAN总线管理的。
由于缺乏这颗MCU更详细的datasheet资料，不能找到具体哪些引脚对应哪些功能，不过后来我还是找到了控制每个电源IC使能引脚(EN)，以及CPU复位引脚(POR_B)所对应的引脚，这些后面结合软件部分再说。
主板背面还有2个芯片，一个是ANALOG亚德诺的ADV7182，负责倒车影像摄像头信号转换（AV转数字信号）。还有一个丝印是2313，查不到具体型号，看旁边的测试点，和I2C总线相关，作用不明…
硬件就先讲到这，大家是不是以为我是一个硬件工程师？其实我只是个业余的…硬件不是我的本职工作，不过我给公司客串过硬件设计，做过一个小产品，从硬件电路设计，到PCB Layout，从MCU固件，到产测软件，都被我包了，公司小，又是做软件的，请个硬件工程师没必要，就让我上了…还好这个项目比较小，不然我真要累死…
了解了天宝187A的硬件组成，就方便了接下来开展Hack行动！
0×02调试串口
Hack一台硬件和软件公开资料并不多的主板，最好的入口点就是寻找他的调试接口。很多产品的主板在设计时都会将TTL串口，JTAG这种关键的接口在主板上以插针或测试点(TestPad)的方式引出来，这种方式很普遍，比如说常用的路由器，大部分路由器都引出了TTL串口，少部分还引出了JTAG调试接口；3.5寸/2.5寸硬盘主板背面是不是有2排测试点？没错，这也是串口和JTAG。
其实不局限于常见的这些产品，绝大多数产品，都会引出TTL或JTAG，这主要是为了方便生产和测试，一颗CPU或MCU芯片、或者FLASH芯片，在工厂SMT贴在主板上后，里面是没有程序的，程序怎么烧进去？这就需要TTL或JTAG接口来实现了，有些带USB接口的还可以从USB引导烧入。
串口和JTAG是生产测试所必须的接口，我想应该很少有人会把烧程序这个阶段放在SMT工艺前面，再说还有测试环节怎么办，盲测？不可能嘛……比如下面这张是从网上找到的硬盘主板和很常见的路由主板，上面都有TTL接口或JTAG接口。
有些人没做过硬件开发，我在这里简单解释下什么是TTL和JTAG。
TTL串口他就是一个串口，TTL电平，基本都是3线，TX，RX，GND，相比RS232来说，控制引脚、状态引脚基本都是不使用的。这其实简化了串口的使用难度，方便了开发，一般开发人员仅使用一个USB转串口的小板就能完成与目标板的通讯。
串口主要用途就是打印日志，方便开发人员确定程序状态，或对目标板进行控制。例如可以查看引导程序日志，打断引导，执行烧写固件指令，上传临时程序到RAM等等。另外使用串口还可以登录Linux系统的终端shell进行操作等等。
JTAG接口是CPU调试接口，通常由TDITDO TCK TMS这4个主要信号组成，一些系统还有TRST信号，用于复位JTAG状态机，还有nSRST用于复位CPU等等。使用这个接口需要与CPU搭配使用的硬件调试工具，每个CPU厂商所使用的工具是有一些区别的。
JTAG接口用途广泛，他可以在CPU上电后就打断CPU的运行，并直接操作CPU寄存器。如果开发Bootloader，或者相关底层的工作，也需要用到JTAG。
在生产测试环节，JTAG还可以测试CPU是否正常工作，读写DRAM，判断DRAM是否正常工作，还可以将程序烧写入Flash。
由于JTAG调试接口过于强大，大部分情况下为了避免自己的产品被山寨，制造商都会在产测结束后禁用掉这个JTAG接口，方法是烧掉CPU里面的熔丝，这个接口就不起作用了。
接下来开始在主板上找TTL和JTAG，JTAG很好找，就在主板背面，有几个较大的测试点，标明了TDI TDO TCK TMS等字样，这些应该就是CPU的JTAG接口了。
但是JTAG熔丝很可能被烧掉了，JTAG接口估计是废的。主要还是要找到调试串口。虽然有找到一些标注了TXD RXD丝印的测试点，但是很遗憾，经过连接测试后，这些并不是CPU的TTL调试串口，系统上电后根本没有任何字符串输出。
难道这个主板在设计时没有引出TTL串口吗？这怎么可能，太愚蠢了吧…
由于这个主板测试点非常多，密密麻麻很多小测试点，根本没有丝印标注，难道TTL串口就隐藏在这些没有丝印标注的小测试点吗？在这么多测试点里找到串口TX和RX信号，这看起来像是不可能完成的任务！
主板正面有两个没有焊接排线插座的焊盘，这两个排线插座都是18pin的，其中一个走线靠近瑞萨MCU，有可能是瑞萨MCU的产测接口。另一个排线插座顶层走线既不靠近CPU也不靠近MCU，但这并不意味着他没有在内层电路与CPU相连，这很有可能主CPU的产测接口。
但是很遗憾当时我并没有意识到这一点，我已经被密密麻麻的小测试点逼得抓狂了。接下来我甚至做了一系列现在想想觉得很愚蠢的事情，在此分享出来吧。
我在咸鱼上联系一位网友花废品价买了他一个报废的主板，为的就是拆CPU，寻找TXD，RXD的走线。我把主板上了热风枪拆焊台，把CPU吹了下来。
寻找NXP的SDK开发资料，找到了一个参考板的电路图，得知调试串口极有可能是UART4，TXD是Pin_W5，RXD是Pin_V6。我根据Datasheet上的引脚图去找W5和V6，然后通过BGA过孔找到背面的过孔焊盘，把焊盘的阻焊漆刮了，飞线，连接USB串口，上电发现并没有任何信息。
难道厂商的UBOOT没有启用串口？或者配置了额外的引脚作为调试串口？因为找不到正确的调试串口Pin，我的研究一度陷入了停滞。
接下来，我从网上找来网友分享的187A升级包，里面有Uboot镜像文件，我上了IDA，对比SDK中的Uboot源代码，找到了配置调试串口的数据。
通过分析uboot头文件mx6dl_pins.h中的宏定义，得出这就是头文件中定义的
MX6_PAD_DECL(KEY_COL0__KEY_COL0,
0x062C, 0xx)
MX6_PAD_DECL(KEY_ROW0__UART4_RX_DATA, 0x8, 4, 0x)
对比datasheet，确定了串口4使用的确实是W5和V6。这就奇怪了，难道调试串口不是串口4？后来我又定位到了puts函数，然后进入putchar函数，发现写入的确实是串口4的寄存器……
现在已经可以从代码上确定，串口4就是调试串口，使用的引脚也确实是CPU的W5和V6，那为什么我在串口上看不到任何信息？
此刻我已经被密密麻麻的测试点、BGA过孔、没有任何符号的UbootIDA反汇编，折磨的想要放弃了。
过了几天，我觉得不服，钱不能白花，决定再战。我检查了Datasheet是否是这个型号CPU的Datasheet，仔细研究了BGA焊盘，过孔，走线，引脚图……等下，我看到datasheet引脚图上面写的是Bottom View！HOLYCRAP！我把这个图当作Top View来看了！
怪不得，我之前找的引脚是错！的！我把图垂直翻转，然后右转，右转，对齐了PinA1，找到W5V6的过孔，刮背面过孔焊盘，飞线，上电……串口终于找到了！此刻成功激动的心情简直无以言表……
后来我意识到那个18pin的排线插座极有可能引出了UART4，用表测了下，发现果然如此，那我之前的一系列行为岂不是很愚蠢……不过我又研究了这个18pin，发现他还引出了JTAG，USB Host。
接下来的研究，其实并不是按我文章的章节顺序展开的，我的研究流程比较混乱，因为涉及的内容繁杂，相互纠缠。因此本文接下来的内容并不是严格按时间顺序展开的……
0×03 UBoot Hack
他的这个UBoot并不是SDK里面的Uboot，毕竟硬件设计上与参考板设计不同，Uboot代码有所改动是理所应当的。但这个Uboot不能被打断引导，令我很头疼。万一我折腾折腾着，把Kernel搞死了，这块主板就变成了一块砖。由于我没有NAND编程器，没办法对Flash烧写恢复，一旦成砖我还怎么研究下去？
我需要准备一个PlanB……
首先我要想办法打断Uboot的引导，进入uboot提示符，然后使用uboot指令，用命令传输数据，就有可能对砖机进行修复。
我首先查看了他的Flash布局：cat/proc/mtd
I have no name!@(none) /$ cat /proc/mtd
"bootloader"
mtd1: 00c00000
"nand.kernel"
mtd2: 0d000000
"nand.rootfs"
mtd3: 00a00000
mtd4: 00a00000
mtd5: 00c00000
可以发现并没有uboot环境变量分区，那么环境变量可能是固定写死在uboot固件里面的，WinHex确实找到了这部分区域。
有一个变量叫bootdelay，值为0。
怪不得不能被打断引导，我把这个值改为3，想着把他刷进去试一下看看。接下来怎么把uboot刷进去又成了一个问题。
最简单暴力的办法是用dd命令直接从/dev/mtd0或者/dev/mtdblock0写进去，那万一写成砖怎么办？这个方法太危险，NAND Flash的操作与SPIFlash可能不同，因为NAND是有OOB区域的，里面有ECC校验，我不能冒险。
接下来我分析了这个系统的更新程序，/opt/sysupdate。这个程序虽然去掉了一些符号表，私有函数在IDA里面看来都是sub_XXXX，但是由于他使用了一套日志接口，log_optional，里面打印了源文件名，函数名，行号等信息，一些函数可能被编译器整合优化成一个函数，但还是可以猜出绝大多数函数的功能。
经过一番分析，确定了他更新uboot使用了外部命令kobs-nginit -v ./uboot.bin。这个命令可能来源于NXP i.MX6 SDK，不管了，先把uboot复制到优盘，插入车机，输命令更新uboot。完成重启，发现bootdelay没生效，并没有出现等待用户3秒输入打断引导的环节……
我X，厂商竟然把bootdelay这部分代码注释掉了吗？这不科学啊！
不过我又想到了一个办法，把bootcmd这个变量擦掉，这样uboot没有了启动命令，自然就无法引导了吧。于是上WinHex，找到bootcmd=，修改成aootcmd=。刷机，重启，发现确实中断了引导。
但是这种办法带来的后果就是，每次启动，都需要手动输入命令才能引导系统，不是什么大问题，准备记事本每次复制粘贴启动命令就可以了…
nand read0x1xx300000;
bootm0x10007FC0
现在可以在uboot提示符下操作了，help查看帮助，看看支持哪些命令，没有网络相关的，因为这主板上没有导出以太网IC……那用什么命令恢复变砖的主板呢。
MX6SOLO STDPLUS U-Boot& help
- alias for 'help'
autoscr - DEPRECATED - use "source" command instead
- print or set address offset
- print Board Info structure
- boot default, i.e., run 'bootcmd'
- boot default, i.e., run 'bootcmd'
- boot application image from memory
- Clock sub system
- memory compare
coninfo - print console devices and information
- memory copy
- checksum calculation
destroyenv- destroy enviroment variables stored in medium
- echo args to console
- erase FLASH memory
- print FLASH memory information
- start application at address 'addr'
- print online help
- I2C sub-system
- print header information for application image
- One-Time Programable sub-system
imxtract- extract a part of a multi-image
- return true/false on integer compare
- load binary file over serial line (kermit mode)
- load S-Record file over serial line
- load binary file over serial line (ymodem mode)
- infinite loop on address range
- memory display
- memory modify (auto-incrementing address)
- simple RAM read/write test
- memory write (fill)
- NAND sub-system
- boot from NAND device
- memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
- Regulator sub system
- Perform RESET of the CPU
- run commands in an environment variable
saveenv - save environment variables to persistent storage
saveenv_wjs- print saveenv info
- memory transfer using the i.MX SDMA Engine &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&------
- set environment variables
- delay execution for some time
- run script from memory
version - print monitor version
有一个sdma命令，好像是从sd卡传输数据？
找了下NXP官方uboot，并没有这个命令，网上也找不到这个命令的详细用法，但是我随便敲了下，想要测试下这个命令看看出现什么结果，却发现这个命令是无效的。因为给出的提示是这样的
MX6SOLO STDPLUS U-Boot& sdma 1
sdma - memory transfer using the i.MX SDMA Engine
MX6SOLO STDPLUS U-Boot& sdma 1 1
sdma - memory transfer using the i.MX SDMA Engine
MX6SOLO STDPLUS U-Boot& sdma 1 1 1
SDMA initialization failed.
MX6SOLO STDPLUS U-Boot& sdma 1 1 1 1
sdma - memory transfer using the i.MX SDMA Engine
MX6SOLO STDPLUS U-Boot& sdma 1 1 1 1 1
sdma - memory transfer using the i.MX SDMA Engine
可以看到这个命令应该是3个参数的命令，但是这一行SDMA initialization failed表示命令失败了。看来没戏，按照之前对开发者的理解，他一定是在uboot发行版本中，把这个功能阉割掉了，或者是根本没实现。
那还有哪些命令可以从外部传输数据呢？
- load binary file over serial line (kermit mode)
- load binary file over serial line (ymodem mode)
从串口传输数据，协议是kermit和ymodem，这俩我很熟悉，以前救路由砖的时候用过，WinXP的超级终端就支持这种文件传输协议。其中一个比另一个传输速率稍快一些。但是快能快到哪？理想状态下 = 14.4KB/s，实际上达到10KB/s就烧高香了。
虽然速度奇慢，这毕竟是一个救砖的PlanB，在缺少NAND编程器的情况下，也许这两条命令就是最后的救命稻草了。或许我可以从固件升级包提取文件，制作一个最简的rootfs，加上内核，估计也就5MB左右……先通过这个内核引导，然后有了USB支持，就可以用USB传输了。
接下来我还思考了下，通常情况下，制造商如何烧入镜像。我查询了NXP的开发资料，可以配置CPU的BOOTMODE，让CPU从USB引导，然后使用一个叫mfgtools的工具，传输bootstrap镜像到RAM，然后再通过USB或以太网传输文件，写入Flash。这个bootstrap镜像其实就是我刚才所想到的，kernel和精简的rootfs。
这种方法的关键在于如何将CPU配置从USB引导，这其实也是一个问题，因为这个配置是可以被制造商通过烧eFuse区域写死的（或者说OTP区域，One Time Programmable），也就是说，这个USB引导，在工厂生产阶段能用，用完之后把这个配置区域写死，就没人能改变CPU的引导方式了。
在uboot提示符使用md命令查看看了eFuse区域寄存器，确实已经被写死了。除非买一片新的CPU换上去，但是新CPU没有eFuse配置，需要从外部引脚配置BOOTMODE，电路改动难度非常大，几乎不可能完成。所以通过改变BOOTMODE，从USB引导，利用mfgtools烧固件救砖这个思路，没戏了。
我想，我已经有了一个PlanB，就是有提示符的uboot，就算搞成砖，也有办法修复，但是事情事实上远没有这么简单……我发现UBOOT中断引导后，系统每隔60秒就重启。那如果我用串口猫协议传输文件，60秒能传输多少数据！况且还有后面的kernel引导！60秒什么都做不了！
这种情况一定是有看门狗。
看门狗是什么？看门狗是一种预防机制，可以防止CPU或程序异常，导致产品失去正常功能。原理其实很简单，做一个定时器，定时器溢出了，就给CPU发送复位信号。为了防止定时器溢出，就必须有一个程序负责清空定时器，这个环节就叫做“喂狗”。如果因为CPU或程序异常因素，导致这段喂狗程序无法正常运行，那么CPU就会被看门狗无情的复位！
一开始，我觉得可能就是CPU内部集成的看门狗吧，反汇编uboot，把放狗的代码屏蔽掉就好了……用IDA确实找到了一处写看门狗寄存器的代码：
CODE XREF: sub_+14
sub_1780229C+1C
R3, =0x20BC000
&&&&&&&&&&&看门狗1的控制寄存器
ROM:178037FC
寄存器0x20BC000在datasheet上就是 WatchdogControl Register (WDOG1_WCR)（这CPU有两个狗），uboot写了狗1的寄存器，写入的4恰好是WDE(Watchdog Enable)，没错，跑不了，这个函数绝对叫EnableWatchdog！
可惜当我HACK掉这个函数，把第一句改为BX LR，让其直接返回。实验结果是狗并没有被关闭！后来研究代码发现这段代码根本就没有在启动流程被调用……这段代码的作用其实是ResetCPU(uboot reset命令)。
0×04看门狗
没想到费劲研究出的uboot救砖方案，竟被一只疯狗给破坏了！既然不是CPU内部的狗，那就一定是外部的狗！
这回没错，跑不了，肯定是瑞萨那个MCU干的！
首先我想弄清楚他是怎么复位CPU的。这个CPU没有RST引脚，只有一个POR_B引脚，其实就是个低电平的PowerOn Reset，POR引脚通常不是设计用来复位CPU的。系统在刚开始上电时，供电电路电压还不稳定，CPU不能正常启动。这一般就需要由供电芯片的PG(Power Good)引脚输出，来通知CPU的POR引脚。大致可以理解为是电源IC给CPU说：“大哥，我的电压稳定了，你可以正常工作了！”不过，一旦电压失稳，PG电平改变，CPU一样是会复位的！
我自信满满的认为是瑞萨的MCU通过拉低POR_B引脚来复位CPU的，于是用表开始找，找了小半天，竟然没找到，这个POR_B没有与MCU直接相连。
在这里分享个寻线小窍门，数字表调整到欧姆档，SELECT启用短路告警，这样一旦探测到短路的位置，表的蜂鸣器就会哔~~，于是寻找的方法就变成了，一个表笔按在POR_B的测试点上，一个表笔在MCU引脚上划来划去。
可惜没找到！难道不是通过拉低POR_B来实现复位的？
后来我发现，在复位的时候，机器的按钮背光灯，短暂的熄灭了零点几秒，难道复位的方法是关掉整机电源然后再打开！没错，这个MCU一定兼职了电源管理芯片的功能！
于是我开始找那几个电源IC的Datasheet，找到他们的EN使能引脚，然后找这些引脚与MCU的哪些引脚直接相连。
可惜又没找到！这不科学！难道不是直接相连，难道中间串了MOS管或三极管什么的？这没必要啊！难道中间串了电阻，电阻拉高，MCU开漏输出？查了下，使能引脚是高电平有效，那电阻是拉低，MCU输出高电平呗！在MCU附近寻找，果然发现了一些布局类似的电阻，然后你猜怎么着，我真的找到了与所有电源IC的EN引脚相连的MCU引脚！
现在事情清晰了，整套系统的供电都受MCU控制，MCU内部还实现了一只看门狗，来复位整套系统，并且复位的方式是控制所有供电IC的EN引脚。
我想，可以直接把这些供电IC的EN引脚全都改一下，全都拉高，不过这很麻烦。CPU的上电其实是有时序要求的，哪个电压先来哪个电压后来，都是有讲究的。除非是在CPU上电之后再去HACK EN引脚。不过这么一堆EN引脚，贸然去改动硬件来bypass看门狗，说不定还有其他什么我没发现的坑，有一定失败风险，直接在硬件上做改动，难度较高。
除非搞到喂狗指令，不然这个狗是很难绕过去了，我决定先放弃寻找关狗的方案。
0×05软件系统
接下来我主要研究的内容就是分析整套软件。分析其软件构成，软件包，库，驱动，内核模块。
看看挂载点
I have no name!@(none) ~$ df -k
Filesystem
Used Available Use% Mounted on
ubi0:rootfs
0% /dev/shm
46% /mnt/rwfs
Ubi0:rootfs是根文件系统，他的文件系统是ubifs，这是一套专门为NAND Flash设计的文件系统，具有坏块管理功能。
pss1和pss2里面文件不多，结构一样，估计2是1的备份。
I have no name!@(none) ~$ ls -li /pss1
看文件名猜测应该是与软件配置相关的一些东西。
再看看/dev目录，都有什么设备。
I have no name!@(none) ~$ ls /dev
cpu_dma_latency
network_latency
network_throughput
tuner_knob
fb(framebuffer)是显存。
event0和event1可能是键盘和触摸板。
3个i2c接口，用途不明，可能是配置功放芯片，摄像头芯片或者触摸板，收音机等用途。
一个spi接口，通过分析/opt/libHAL.so发现是与MCU通信用的。
tuner_knob，可能与前面板两个旋钮相关。
v850srq，这个看名称就知道肯定也和MCU相关，因为那个瑞萨的MCU代号是RH850，而这个MCU的指令集就是NECV850，IDA恰好支持这个指令集。
video设备可能就是倒车摄像头芯片ADV7182的接口。
再看看etc/rc.d目录，有一些系统引导脚本，文件不多，很好分析。
I have no name!@(none) ~$ ls /etc/rc.d/
rc.modules
I have no name!@(none) ~$ ls /etc/rc.d/init.d
filesystems
mount-proc-sys
I have no name!@(none) ~$
我可以修改其中的rcS脚本，在里面插入一个read-t 指令，这样我就可以打断Linux系统的引导，来制造一个failsafe模式。这个模式有什么用呢？其实就是为了防止后面的修改出错，导致系统直接崩溃掉了。有这个failsafe模式，我就可以回退修改。例如还没进入终端系统就崩溃了，我只能在uboot模式恢复系统了，会很麻烦的。
但是暂时这个修改没有用，因为需要喂狗程序，这个程序在哪，是哪个程序，我都不能确定……先算是一个思路吧。
看看/opt目录
I have no name!@(none) ~$ ls /opt
AndroidAuto
g_ether.ko
aoa_adapter
g_file_storage.ko
net_windows.sh
nw_vmf_ctrl.dat
audio_proc
g_iap_ncm_audio.ko
nw_vmf_trace.dat
g_iap_ncm_eap.ko
carlife_daemon
carplay_App
carplay_testmode.sh
screenshot
hmi_autotest.ini
sourceme.sh
cdc_ncm.ko
start_carlife.sh
clear-cache.sh
start_carplay.sh
start_mdnsd.sh
connect_mgr
stdplus.ini
launch_aa.sh
libcidb_sdk.so
eol_test.wav
md_adapter
feature_config.ini
ftpdup2.sh
这里面都是车机的应用程序，有库，配置，图片字体资源文件，各种脚本……
先看看正在跑的都有哪些程序吧。ps -ef
I have no name!@(none) ~$ ps -ef
0:00 [kthreadd]
0:00 [ksoftirqd/0]
0:00 [kworker/0:0]
0:00 [kworker/u:0]
0:00 [migration/0]
0:00 [khelper]
0:00 [kworker/u:1]
0:00 [sync_supers]
0:00 [bdi-default]
0:00 [kblockd]
0:00 [imx6q-ecspi.0]
0:00 [imx6q-ecspi.1]
0:00 [khubd]
0:00 [ipu1_task]
0:00 [ipu1_task]
0:00 [usb_wakeup thre]
0:00 [otg_switch]
0:00 [kswapd0]
0:00 [fsnotify_mark]
0:00 [crypto]
0:00 [kapmd]
0:00 [mtdblock0]
0:00 [mtdblock1]
0:00 [mtdblock2]
0:00 [mtdblock3]
0:00 [mtdblock4]
0:00 [mtdblock5]
0:00 [ubi_bgt0d]
0:00 [vpu_wq]
0:00 [galcore workque]
0:00 [kworker/0:1]
0:00 [galcore daemon ]
0:00 [galcore daemon ]
0:00 [scsi_eh_0]
0:00 [usb-storage]
0:00 [kworker/u:2]
0:00 [kworker/0:2]
0:00 race_daemon sda true /devices/platform/fsl-ehci.0/usb1/1-
0:00 [ubi_bgt1d]
0:00 [ubi_bgt2d]
0:00 [ubifs_bgt1_0]
0:00 [ubifs_bgt2_0]
0:00 ./vmf
0:00 ./pwr_agent -o -v
0:00 ./sysupdate
0:00 ./mfid
0:00 ./vgw
0:00 [irq/283-atmel_m]
0:02 ./hmi
0:03 ./media
0:00 ./pss
0:00 ./audio_proc
0:00 ./exlap
0:02 /usr/bin/devicemanager 5 0 /usr/bin 239
0:00 [race_daemon]
0:00 ./diag
0:00 ./diag_eol
0:00 ./screenshot
0:00 [flush-ubifs_1_0]
0:00 [flush-ubifs_2_0]
0:00 ./mdnsd -debug
0:00 ./connect_mgr
0:00 ./carplay_App
0:00 ./iap2d
0:00 ./carlife_daemon
0:00 ./carplayd
0:00 {clear-cache.sh} /bin/sh ./clear-cache.sh
0:00 [flush-8:0]
0:00 sleep 2
0:00 ps -ef
发现有很多进程，由于名字都是缩写，很难直接猜出这些程序的用途。例如vmf、mfid、vgw、hmi、exlap、diag等等这些都是鬼？他们大多没有-h –help 之类能显示信息的参数可用，想知道他们的用途，估计是要上IDA逆向一下……
经过了几天的研究，我终于知道了部分核心程序的用途。
他这套软件，大部分都是在后台工作的，只有少部分是QT编写的，有界面的。例如hmi和sysupdate。其中hmi体积最大，他就是界面主程序，他包含了所有的图形资源，多国语言字符串。
其他程序基本都没有界面，界面其实都是在hmi中。UI进程和逻辑进程之间使用类似IPC的消息机制，这个机制在这套系统中称为vmf。
那个vmf程序，起到一个消息中转站的作用，vmf可能是Virtual Message Function的缩写？他有Usage信息，显示的是vmffor linux version DOMAIN-SOCKET。
/opt/lib/libvmf_client.so这个就是vmf客户端支持库，很多程序通过调用libvmf_client.so的nw_vmf_send/receive函数来实现跨进程的IPC消息传递，这套消息机制是基于socket。在/tmp/目录有很多127.X.X.X文件，可能与此相关。在文章后面，我将详细分析这套API的原型和消息数据结构。
I have no name!@(none) ~$ ls /tmp
127.3.215.1
allgorpccomm1
127.3.104.1
127.3.219.1
127.3.106.1
127.3.241.1
devmgr_debug.txt
127.3.106.2
127.3.246.1
diag_enter_main
127.3.106.3
127.3.246.2
diag_initialize_OK
127.3.106.4
127.3.40.1
eol_enter_main
127.3.106.5
127.3.40.2
127.3.106.6
127.3.40.4
icr_device_process.txt
127.3.106.7
127.3.43.1
keyGenerationFile
127.3.106.8
127.3.44.1
127.3.106.9
127.3.74.1
race_key_gen_file.txt
127.3.108.1
127.3.74.2
shm_key_gen.txt
127.3.112.1
shm_key_index.txt
127.3.112.2
vaf_comm_mirrorlink
127.3.151.1
DevMgrRunning.txt
127.3.153.1
vmf_trace_startup
127.3.153.2
RPCClient1026
127.3.213.1
pwr_agent，从名字看，显然是电源管理相关，我一直认为就是这个进程，在不断地与MCU通信，喂狗。
我用IDA把他逆了个遍，他确实有这个动作，但是他只是构造了个消息包，包发给了谁并不知道……他其实不光是电源管理，在/opt/launch.sh脚本中可以发现，脚本执行了vmf hal_init pwr_agent sysupdate mfid，就没有了。其实大多数进程，都是由pwr_agent带起来的，这在IDA逆向中能发现。
DCD a_Diag+8 ""
DCD a_VgwDevNull21 "./vgw & /dev/null 2&&1 &"
.rodata:0001118C
DCD a_PssDevNull21 "./pss
& /dev/null 2&&1 &"
DCD a_MediaDevNull2 "./media
& /dev/null 2&&1 &"
DCD a_Diag+8 ""
DCD a_Audio_procD "./audio_proc
& /dev/null 2&&1 &"
.rodata:0001119C
DCD a_BtDevNull21 "./bt
& /dev/null 2&&1 &"
DCD a_Diag+8 ""
DCD a_HmiDevNull21 "./hmi
& /dev/null 2&&1 &"
DCD a_WifiDevNull21 "./wifi
& /dev/null 2&&1 &"
.rodata:000111AC
DCD aCatProcD "cat /proc/deferred_initcalls"
DCD a_Diag_eolDevN "./diag_eol
& /dev/null 2&&1 &"
DCD a_Audio_procD "./audio_proc
& /dev/null 2&&1 &"
DCD a_DiagDevNull21 "./diag
& /dev/null 2&&1 &"
.rodata:000111BC
DCD a_ScreenshotD "./screenshot
& /dev/null 2&&1 &"
DCD a_Start_ " ./start_carplay.sh & /dev/null 2&&1 & "
DCD a_Connect_mgrD "./connect_mgr
& /dev/null 2&&1 &"
DCD a_Carlife_ "./carlife_daemon
& /dev/null 2&&1 &"
.rodata:000111CC
DCD a_ExlapDevNull2 "./exlap & /dev/null 2&&1 &"
DCD a_Launch_aa_shD "./launch_aa.sh & /dev/null 2&&1 &"
DCD a_Net_windows_ "./net_windows.sh & /dev/null 2&&1 &"
DCD a_ClearCache_ "./clear-cache.sh & /dev/null 2&&1 &"
.rodata:000111DC
DCD a_Start_mdnsd_ "./start_mdnsd.sh
& /dev/null 2&&1 &"
hal_init，这个进程很简单，只是调用了libHAL.so库中的一些初始化函数就结束了。
int __cdecl main(int argc, const char **argv, const char **envp)
vgw，这是关键进程，我发现把他杀了，系统过一会就重启，所以他是喂狗嫌疑对象。通过逆向，发现他调用了libHAL.so里面的spi_ipcl_read、spi_ipcl_write等函数，通过Search And Replace搜索整个opt目录也证实，只有vgw程序调用了上面的spi_ipcl_read/write接口。这个vgw是什么缩写，我没找到，可能是Vehicle Gateway或者VIP Gateway？感觉这种解释不太靠谱……
/opt/lib目录就是这套程序的库文件了。
I have no name!@(none) ~$ ls /opt/lib
libOSAL.so
libAirPlay.so
libOSAL.so.1
libAirPlaySupport.so
libOSAL.so.1.0
libCarPlayAudio.so
libOSAL.so.1.0.0
libCarPlayClient.so
libdns_sd.so
libCarPlayDevice.so
libiap2.so
libCarPlayPlatform.so
libCarPlayPlatformDevice.so
libprotobuf-c.so
libCarPlayPlatformMFI.so
libprotobuf-c.so.1
libCarPlayPlatformScreen.so
libvmf_client.so
libCarPlayPlatformSystem.so
libvmf_trace.so
libximage.so
libHAL.so.1
libximage.so.1
libHAL.so.1.0
libximage.so.1.0
libHAL.so.1.0.0
libximage.so.1.0.0
libHAL.so.1.0.0.bak
libHAL.so.1.0.0.read
mirrorlink
libHAL.so.1.0.0.write
screenshot
重点关注其中的2个，libOSAL.so和libHAL.so，前者是操作系统支持库，可能是为了方便跨平台开发，将一些系统级API重新封装了一下，例如线程，定时器，互斥锁等。后者是硬件层面的接口，包括uart，spi，gpio，i2c等接口的读写函数封装。其他都是carplay carlifemirrorlink等程序的支持库。
/opt里面很多程序都被strip掉了符号表。在IDA分析时没有符号帮助，很难搞懂一些函数的作用，还好这些程序都调用了日志接口log_optional来打印日志，因此能获知一些函数的真实名字，以及他们的用途。比如下面这个例子：
显然，得知这个函数名字叫pwr_agent_vmf_rcv_handle_round_comm，日志类别是radio_updown。
log_optional的消息打印是受配置文件控制的，这些配置文件以进程名作为区分，位于/opt/config或/pss1/config
例如下面这个pwr_agent的config
I have no name!@(none) ~$ cat /pss1/config/pwr_agent.conf
&&&&&&&&&&注意这里
PROCNAME=0
SEC_DIGIT=2
TIME_FMTSTR=%M:%S
&&&&&&&&&&注意这个小节
start_trap=1
radio_updown=1
&&&&&&&&&&注意这里的名字radio_updown
radio_updown=39
start_trap=39
[BACKGROUD]
radio_updown=49
start_trap=49
[ATTRIBUTE]
radio_updown=-1
start_trap=-1
可见有很多开关，控制了哪些debug消息需要打印，哪些不打印。把一些需要的开关打开，可以方便逆向分析工作。主要开关就是ENABLE=1，OUTPUT是类别控制，控制对应的类别的日志要打印出来。
/opt/ftpdup2.sh这个脚本很有意思，他insmod了asix.ko，然后用ifconfig配置了ip地址，还启动了ftp服务。看来是开发人员为了方便网络传输文件留下来的。这个asix.ko是ASIX的usb转以太网芯片的驱动，很多常见的USB转网口的产品都是用ASIX芯片方案，例如绿联的USB百兆网卡。
I have no name!@(none) ~$ cat /opt/ftpdup2.sh
我试着运行了一下，确实把网卡带起来了……
/opt还有一些usbgadget驱动程序，例如g_ether.ko和g_file_storage.ko，由于这台机器前面板的USB接口实际上是CPU的USB_OTG接口，因此我怀疑开发人员用这个驱动，直接把USBOTG虚拟成MassStorage或者网卡，与开发机用USB线连起来就能传文件了，是不是很有意思……
另外我还在/opt/tools发现了两个小程序
I have no name!@(none) ~$ ls -li /opt/tools/
16350 -rwxr-xr-x
1 messageb messageb
7555 Nov 23
2016 vmf_rcv
16349 -rwxr-xr-x
1 messageb messageb
7038 Nov 23
2016 vmf_send
Search AndReplace搜索后发现，这两个程序并没有被任何程序或脚本使用，应该是开发人员在开发或调试时留下的，有意思……这个vmf_send很有用，后面会用到。
0×06升级包分析
不知道网友有什么渠道，拿到了还没有发布的187B的升级包，上传到了网上，可以在百度网盘、或QQ群，找到这些升级包。用升级包给187A升级后，可以比原系统多出许多高级功能。比如苹果CarPlay，百度CarLife，还有什么超级蓝牙，我也没用过，不知道具体是怎么个超级法…
网友放出来的这些升级包，事实上可能都是开发阶段的测试包，有很多bug。有一个固件要求运行内存是512M，在256M的机器上刷了会变砖。另一个固件包支持256M内存，但也是Bug最多的版本。所以很多网友把天宝187A的机器换了内存，还有一些商家提供此类换内存服务，或者售卖已经换好内存的车机。
另外有少数商家有5314版本的升级包，这个版本与上市后的187B系统版本相同，估计算是正式版。但是这个升级包在网上找不到，貌似只掌握在少数以刷机为盈利目的的商家手上，且不外卖，在咸鱼上卖的5314据说都是假包。
接下来研究一下升级包的构造，升级包其实就是一个tar包，没有签名。
例如这个版本的包用7z打开是这样
用户名组名是wangshi，王石？看来制作升级包的系统，有是一个叫wangshi的用户，也许这个也是那位工程师的真实姓名……
看一下根目录的config.txt文件
kernel_update:1
bootloader_update:1
vip_update:1
bt_update:1
middleware_update:1
[file]:[opt]
[file]:[etc]
[file]:[usr]
[file]:[mirrorlink]
[file]:[lib/firmware]
好简单的设计，一目了然啊……
其中的vip_update其实指向的是vipImage.bin，大小1MB，文件末尾有哈希。这正好是瑞萨MCU的Flash大小，那么这个MCU在软件内部就是被叫做VIP咯，VIP是什么呢？Very Important Processor？Vehicle InformationProcessor？
其实如果知道了这个MCU的地址空间布局，完全可以拖进IDA逆向一下，看看里面的具体实现……不过经过后来一番分析，已经知道了VIP的大致作用：CAN总线通讯，身份信息，电源管理等等。身份信息包括零件号，平台(PQ/MQB)，序列号，车型(VW/SKODA)等。
现在知道这个MCU的代号其实就是VIP了，而且在分析软件程序的过程中，有很多字符串提到了VIP，那么我在后面文章就以VIP来称呼吧。
bt_update就是蓝牙了，这个机器的蓝牙模块是ALPS的一款模块，网上找不到任何资料。与CPU的通讯是通过UART串口。升级包bt_ac_firm目录里面的文件就是蓝牙控制芯片的固件了。
middleware就是中间件了，也就是opt那些目录，想覆盖哪个目录，写进config.txt就可以了。
升级包还有一个配置文件/opt/stdplus.ini。
AP_VER=5.4.1.1
CUSTM_PQ=Y307
CUSTM_MQB=Y307
UBOOT_VER=uboot_1.3.2
UIMAGE_VER=uImage_5.0.11
KERNL_VER=3.0.35
BT_VER = C150
VIPAP_VER=5.4.1.1
VIPBL_VER=2.0.2
PACK_TYPE=VW_PQ_PSS
里面有两个字段是必须的，Version小节的AP_VER字段，不能与主机/opt/stdplus.ini一致，否则sysupdate升级时会提示变量冲突。有Upgrade小节的PACK_TYPE，必须与主机/opt/stdplus.ini保持一致，否则不能升级。
其他字段都是可选的，根据升级需要设定即可。
另外升级包里面有一个script目录，里面有两个脚本。
看名字很容易猜得出，一个脚本是更新前执行，一个是更新后执行。
另外还有一个有意思的地方，用7z解压缩那个kernelImage，记事本打开，搜Linuxversion，可以看到编译人员的机器名和用户名，如图。
看，机器名是HP-640，用户名是changchun，难道内核编译人员来自长春？
升级包的结构清楚了，再通过逆向/opt/sysupdate，就对更新过程有了进一步了解。
0×07更新流程分析
通过逆向/opt/sysupdate可以对更新流程有个大致了解，具体的逆向分析流程我不多说了，他这个程序是qt写的，在log_optional这个日志打印函数的帮助下，很容易逆向/跟踪出具体流程。流程大致就是：验证包合法性，设置/sysupdate/flag.ini更新标志，保存包文件名，重启系统，重启后rcS脚本检查flag.ini文件，得知需要更新系统，然后走更新系统流程，启动sysupdate。sysupdate执行run_before_app_update_sh，刷内核（访问/dev/mtd，不是通过dd），替换中间件(hostapp)，刷bootloader(调用kobs-ng命令)，执行run_after_app_update_sh，刷蓝牙(uart传输)，刷VIP(spi传输)。
这个更新流程中的重启，很有意思，不是调用的reboot命令，而是硬重启！
我打开了sysupdate的log日志功能，通过日志输出，可以大致确定他是通过调用SendUpdateStatus(this, 1)来实现重启的，因为打印了这个日志就就没有日志了。
SendUpdateStatus这个函数发出了一个vmf消息，可能被vgw接收了，然后被vgw转手发给了VIP，由VIP触发了重启动作。这个函数的名字是SendUpdateStatus，发送更新状态。估计VIP还关注了更新的状态，能够根据更新状态来产生不同的动作，而这个状态1，就对应着复位CPU。
另外我还发现，一旦这个命令发出去重启了CPU，狗就被关起来了！电源不会每隔60秒被重置一次，这是一个很有意思的发现！
0×08破解通讯协议
现在知道的情况就是，pwr_agent肯定有一个定时器，每隔一段时间喂狗，sysupdate能通知VIP更新状态，当状态为1时，VIP就关掉了狗。
现在就有了两种办法关狗，一个是利用喂狗协议，一个利用升级状态协议。都是通过协议，现在没有协议，怎么办呢，想办法抓到通讯协议就好办了。
与VIP通讯的是vgw进程，IDA看看他里面的函数，有几个spi_ipcl_xxx的函数引起了我的注意，看来是通过调用libHAL.so的spi_ipcl_xxx读写函数实现通讯。前后找了下，没有可以利用的log打印。
再看看libHAL.so的spi_ipcl_write，竟然有日志打印，这太好了……
spi_ipcl_read也调用了这个IPCL_Print_Msg，第三个参数控制了是否输出日志，可惜被传了0，估计是一个宏开关，被编译时指定的。这难不住我，用WinHex把对应的指令字节码改掉。
有两种改法，改IPCL_Print_Msg外部call的传参，也就是0改成1，把MOV R2指令改成 MOV R2,#0就可以了；还可以进入IPCL_Print_Msg内部去改，去掉对第三个参数的判断，也就是将前面的LDMEQFD指令改成NOP。
由于IPCL_Print_Msg并不能打印出这个消息是read还是write，因此我使用前一种改法，改出2个文件，libHAL.so.read和libHAL.so.write，并备份原机文件为libHAL.so.bak。另外这个printf的fmt是“ %x ”，输出内容会很不友好，我改成了 “%02x ”。
有了这样3个文件，我就随时可以根据一条shell命令来更换libHAL文件。
恢复libHAL
mount -o remount rw / && cd /opt/lib && cp libHAL.so.1.0.0.bak libHAL.so.1.0.0
设置IPCL read
mount -o remount rw / && cd /opt/lib && cp libHAL.so.1.0.0.read libHAL.so.1.0.0
设置IPCL write
mount -o remount rw / && cd /opt/lib && cp libHAL.so.1.0.0.write libHAL.so.1.0.0
由于我替换的是系统关键库，为了避免错误发生，我修改了启动脚本rcS，加入了一个failsafe安全模式功能。改法是这样的
这样修改后，在系统启动时，我有一秒时间来输入y回车来进入安全模式，防止修改/opt/lib库文件导致系统关键进程无法启动、系统崩溃。不过因为没有喂狗，这个安全模式是有时间限制的，复制粘贴上面的指令能迅速帮我还原备份文件。
首先我替换了libHAL.so.write文件，重启后串口终端确实打印了大量通信报文。我发现每隔1秒都有一个8字节的报文送出，且有类似递增序号的字节，没错这一定是在喂狗！
另外我也抓到了sysupdate在调用SendUpdateStatus(xxx,1)关狗并重启时的8字节报文。也在上面的图片中
这些报文都是vgw进程通过spi_ipcl_write向VIP写入的。而这些报文的实际发起者其实并不是vgw。喂狗是pwr_agent发起的。关狗重启是sysupdate发起的。
虽然我可以通过调用libHAL.so的spi_ipcl_write来实现我想要的喂狗和关狗功能了，但是这要编译一个小程序，编译程序需要准备交叉编译环境，还要把这个程序放进去……呀，好麻烦……
为了体现我的高端，我还进一步研究了进程间的通讯，也就是那个vmf消息。比如这个喂狗流程应该是这样的：pwr_agent定时器，构造了一个包，发给了vmf，vmf转给了vgw，vgw通过spi喂狗。
是不是很复杂？没错，厂商确实是这样设计的，这套消息也确实是这样工作的……因为我把vmf杀掉，vgw就收不到消息，不再喂狗了。
首先我想用sysupdate来展开分析工作，我感觉我对这个程序了解的更多一些。我先用IDA定位到SendUpdateStatus(int this, int arg_status)。这个函数第二个参数就是状态值，有1、2、3、4、5、6、7……之类的，在这里关狗重启status值为1。他构造了一个5字节的包，传给了UpdateSendVmfMsg。
构造的包其实就是5个字节， 8F 19 00 01[StatusByte]
UpdateSendVmfMsg(_BYTE*arg_databuf, int arg_datalen)函数又将收到的包调用PackVmfMsg重构了一下，然后把重构的包调用libvmf_client.so!nw_vmf_send_basic发出去了。先看看包是怎么被PackVmfMsg重构的。
char __fastcallPackVmfMsg(_BYTE arg_databuf, unsigned int arg_datalen)
目前只是知道了数据包的布局，但是具体的字段含义还不清楚，例如那个8F是什么，19是什么，00 01有可能是BigEndian的包长？不过通过交叉引用vmf的消息处理接收函数nw_vmf_receive(inthandle, char *buf, int bufsize)不难得出，这个8F其实是groupid，19是eventid。
例如下面是对pwr_agent程序的nw_vmf_receive交叉引用分析出来的log_optional。
从这个log_optional的上下文代码中，我得出了这个vmf的数据包结构：
payload_len
看起来很简单，只要按照这个数据结构把包发出去就可以了。这时就可以利用前面分析文件系统时发现的/opt/tools/vmf_send。
这个文件很小只有7K，拖进IDA，虽然没有usage消息，但是很轻松就逆出了他的用法：
由上面main函数得出vmf_send的用法
有了这个命令，理论上我只需要知道groupid和eventid，就可以用vmf_send发送vmf消息给相应的进程，控制其产生相应的动作。例如上面分析到的关狗重启vmf消息，我可以调用vmf_send命令：
/opt/tools/vmf_send143 25 1
这样vgw就会收到vmf消息，然后发送8个字节的SPI报文给VIP，触发VIP的关狗重启动作。
有了vmf的相关函数原型以及vmf消息结构，我又逆向了pwr_agent，找到了他的喂狗程序。
然后分析出了喂狗的vmf消息结构
groupid = 143
eventid = 3
payload_len = 4
变量VipEnabled的值，由argv参数-v指定
现在终于可以调用tools/vmf_send来发送喂狗消息，我写了一个脚本来实现后台喂狗：
while true
for seqnum in $(seq 0 255)
echo $seqnum
/opt/tools/vmf_send 143 3 2 $seqnum 1 1
为了验证这个脚本是否有效，我重启进入failsafe模式，顺序启动vmf，启动hal_init，启动vgw，然后再运行这个脚本，过了1分多钟，狗确实被喂的很舒服，没有出来乱咬！哈哈！
现在就可以完善这个failsafe模式了，修改rcS脚本：
read -t 1 -p "Safemode[y/N]:" safemode
echo -e "\n"
if [ "$safemode" = "y" ];
echo "safemode"
/opt/vmf &
/opt/hal_init
/opt/vgw &
/opt/keepalive.sh & /dev/null
这样系统就有了具有喂狗功能的failsafe模式，是不是很厉害！
0×09 后记
至此，我已经有了一堆PlanB，我可以放心大胆的折腾这台机器了……
接下来的研究就轻松的多了。我又研究了很多有意思的东西，例如：
a)导出187A原厂文件系统
b)做了个升级包能把rootfs导出来。但是不包括蓝牙和VIP固件…
c)Hack了512M版本的固件，让他在256M内存上完美的跑起来了。
d)由于升级后，车机前面板键位错乱，是187B的键位，因此我Hack了hmi修改了键位。
e)写了个小程序生成BITMAP并计算哈希，做了个升级包可以替换开机Logo。
f)做了个升级包能进入一次failsafe模式，并加载网卡驱动，启动ftp…
g)做个原机备份固件。
h)有网友提供了编程器固件，从编程器固件提取uboot、kernel、rootfs。
等有时间我准备把上面的abcdefgh，和新研究出来的东西发在这里，作为续集。希望这篇文章，能给同样爱好折腾硬件折腾软件的人带来一些帮助……
阅读(...) 评论()}