看大神是怎么破解MIB-大众车机天宝187A Hack笔记
原文在在这里 http://www.tuicool.com/articles/nYbu2ey
如果感觉不错，记得回来顶一下
0×00前言
自从去年买了车，对汽车电子系统的兴趣就上来了。这不，前一阵子逛汽车论坛，发现了有网友将老版本的天宝车机被刷上了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来研究一下，至于德赛……先好好地在车上服役，暂时不去虐他了…
关于天宝这个公司，也许是我才接触汽车不久，之前没有听说过。德赛倒是听说过，专门做汽车导航机器的，也给大众代工车机。江苏天宝汽车电子有限公司( http://www.toppower.com )，公司很低调，网站很简陋…看一下职位招聘，都招什么工程师，嗯，CAE工程师、项目工程师、电子工程师、制造工程师，就是没有软件系统工程师，那这机器软件哪来的？大众给的？外包的？此处留下疑问……
0×01硬件
接下来我准备详细分析天宝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，丝印是完整型号。
TPS54388-Q1，2.95V-6V输入，3A输出。NCV896530，2.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源代码，找到了配置调试串口的数据。
ROM:178013AC dword_178013AC DCD 0x62C244 ; DATA XREF: sub_17801278+C8
ROM:178013B0 dword_178013B0 DCD 0x10000100 ; DATA XREF: sub_17801278+D4
ROM:178013BC dword_178013BC DCD 0x14640258 ; DATA XREF: sub_17801278+ECr
ROM:178013C0 dword_178013C0 DCD 0x3716348 ; DATA XREF: sub_17801278+F4r
通过分析uboot头文件mx6dl_pins.h中的宏定义，得出这就是头文件中定义的
MX6_PAD_DECL(KEY_COL0__KEY_COL0, 0x062C, 0x0244, 3, 0x0000, 0, 0)
MX6_PAD_DECL(KEY_ROW0__UART4_RX_DATA, 0x0640, 0x0258, 4, 0x0914, 3, 0)
对比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
dev: size erasesize name
mtd0: 00400000 00020000 "bootloader"
mtd1: 00c00000 00020000 "nand.kernel"
mtd2: 0d000000 00020000 "nand.rootfs"
mtd3: 00a00000 00020000 "pss1"
mtd4: 00a00000 00020000 "pss2"
mtd5: 00c00000 00020000 "logo"
可以发现并没有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 read0x10007FC0 0x400000 0x300000; bootm0x10007FC0
现在可以在uboot提示符下操作了，help查看帮助，看看支持哪些命令，没有网络相关的，因为这主板上没有导出以太网IC……那用什么命令恢复变砖的主板呢。
MX6SOLO STDPLUS U-Boot> help
? - alias for 'help'
autoscr - DEPRECATED - use "source" command instead
base - print or set address offset
bdinfo - print Board Info structure
bld_his -
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
clk - Clock sub system
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
destroyenv- destroy enviroment variables stored in medium
echo - echo args to console
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print online help
i2c - I2C sub-system
iminfo - print header information for application image
imxotp - One-Time Programable sub-system
imxtract- extract a part of a multi-image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nm - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
regul - Regulator sub system
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saveenv_wjs- print saveenv info
sdma - memory transfer using the i.MX SDMA Engine <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<------
setenv - set environment variables
sleep - delay execution for some time
source - 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发行版本中，把这个功能阉割掉了，或者是根本没实现。
那还有哪些命令可以从外部传输数据呢？
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
从串口传输数据，协议是kermit和ymodem，这俩我很熟悉，以前救路由砖的时候用过，WinXP的超级终端就支持这种文件传输协议。其中一个比另一个传输速率稍快一些。但是快能快到哪？理想状态下115200/8 = 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确实找到了一处写看门狗寄存器的代码：
ROM:178037F0 sub_178037F0 ; CODE XREF: sub_17802044+14
ROM:178037F0 ; sub_1780229C+1C
ROM:178037F0 LDR R3, =0x20BC000 <<<<<<<<<<<看门狗1的控制寄存器
ROM:178037F4 MOV R2, #4
ROM:178037F8 STRH R2, [R3]
ROM:178037FC BX LR
寄存器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 1K-blocks Used Available Use% Mounted on
ubi0:rootfs 182808 155908 22064 88% /
mdev 86372 0 86372 0% /dev
none 5120 12 5108 0% /tmp
shm 86372 8 86364 0% /dev/shm
rwfs 512 236 276 46% /mnt/rwfs
rwfs 512 236 276 46% /var
ubi1:pss1 5960 64 5556 1% /pss1
ubi2:pss2 5960 32 5588 1% /pss2
Ubi0:rootfs是根文件系统，他的文件系统是ubifs，这是一套专门为NAND Flash设计的文件系统，具有坏块管理功能。
pss1和pss2里面文件不多，结构一样，估计2是1的备份。
I have no name!@(none) ~$ ls -li /pss1
total 52
65 -rwx------ 1 root root 33 Jan 1 00:00 DIAG_PSS_CODING.pss
66 -rwx------ 1 root root 33 Jan 1 00:00 FEATURE_MANAGER_PSS_BLK.pss
67 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_A2DP_ONOFF_STATUS_PSS_BLK.pss
68 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_ONOFF_STATUS_PSS_BLK.pss
69 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_VISIBLE_ONOFF_STATUS_PSS_BLK.pss
119 -rwx------ 1 root root 9 Jan 1 00:00 HMI_EXLAP_SERVER_ONOFF_PSS_BLK.pss
150 -rwx------ 1 root root 2298 Jan 1 00:01 HMI_SYSTEM_APP_CONNECTION_PLIST_PSS_BLK.pss
118 -rwx------ 1 root root 10 Jan 1 00:00 HMI_SYSTEM_SAFECODE_ASSEMBLY_UNLOCK_PSS_BLK.pss
117 -rwx------ 1 root root 9 Jan 1 00:00 HMI_SYSTEM_SAFECODE_REMAINING_ATTEMPT_PSS_BLK.pss
70 -rwx------ 1 root root 28 Jan 1 00:00 HMI_SYSTEM_SETUP_PSS_NEWBLK.pss
71 -rwx------ 1 root root 78 Jan 1 00:00 TM_PSS_BT_FRIENDLY_NAME_PSS_BLK.pss
75 drwx--x--x 2 messageb messageb 1408 Jan 1 00:00 config
90 -rwxr-xr-x 1 messageb messageb 22 Nov 23 2016 hmi_autotest.ini
146 -rw-r--r-- 1 root root 393 Jan 1 00:00 stdplus.ini
I have no name!@(none) ~$ ls -li /pss2
total 52
65 -rwx------ 1 root root 33 Jan 1 00:00 DIAG_PSS_CODING.pss
66 -rwx------ 1 root root 33 Jan 1 00:00 FEATURE_MANAGER_PSS_BLK.pss
67 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_A2DP_ONOFF_STATUS_PSS_BLK.pss
68 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_ONOFF_STATUS_PSS_BLK.pss
69 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_VISIBLE_ONOFF_STATUS_PSS_BLK.pss
70 -rwx------ 1 root root 9 Jan 1 00:00 HMI_EXLAP_SERVER_ONOFF_PSS_BLK.pss
71 -rwx------ 1 root root 2298 Jan 1 00:00 HMI_SYSTEM_APP_CONNECTION_PLIST_PSS_BLK.pss
72 -rwx------ 1 root root 10 Jan 1 00:00 HMI_SYSTEM_SAFECODE_ASSEMBLY_UNLOCK_PSS_BLK.pss
73 -rwx------ 1 root root 9 Jan 1 00:00 HMI_SYSTEM_SAFECODE_REMAINING_ATTEMPT_PSS_BLK.pss
74 -rwx------ 1 root root 28 Jan 1 00:00 HMI_SYSTEM_SETUP_PSS_NEWBLK.pss
75 -rwx------ 1 root root 78 Jan 1 00:00 TM_PSS_BT_FRIENDLY_NAME_PSS_BLK.pss
78 drwxr-xr-x 2 root root 304 Jan 1 00:00 app_data
76 -rwxr-xr-x 1 root root 22 Jan 1 00:00 hmi_autotest.ini
77 -rw-r--r-- 1 root root 393 Jan 1 00:00 stdplus.ini
I have no name!@(none) ~$
看文件名猜测应该是与软件配置相关的一些东西。
再看看/dev目录，都有什么设备。
I have no name!@(none) ~$ ls /dev
apm_bios loop7 mxc_vpu ttymxc3
console mem mxs_viim ttymxc4
cpu_dma_latency mtd0 network_latency ttyp0
crypto mtd0ro network_throughput ttyp1
event0 mtd1 null tuner_knob
event1 mtd1ro pts ubi0
fb mtd2 ptyp0 ubi0_0
fb0 mtd2ro ptyp1 ubi1
fb1 mtd3 ram0 ubi1_0
full mtd3ro ram1 ubi2
galcore mtd4 ram2 ubi2_0
i2c-0 mtd4ro ram3 ubi_ctrl
i2c-2 mtd5 random uinput
i2c-3 mtd5ro sda urandom
kmem mtdblock0 sda1 usbdev1.1
kmsg mtdblock1 shm usbdev1.2
loop0 mtdblock2 snd v850srq
loop1 mtdblock3 spidev0.0 video
loop2 mtdblock4 tracebuf video0
loop3 mtdblock5 tty video1
loop4 mxc_asrc ttymxc0 video16
loop5 mxc_ipu ttymxc1 video17
loop6 mxc_mem ttymxc2 zero
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/
init.d rc.local rc.serial rcS rc_gpu.S
rc.conf rc.modules rc.ts rc_mxc.S
I have no name!@(none) ~$ ls /etc/rc.d/init.d
boa dropbear mdev portmap udev
depmod filesystems mdev_bak settime
devfsd hostname modules smb
dhcp hotplug mount-proc-sys sshd
dhcpd inetd network syslog
I have no name!@(none) ~$
我可以修改其中的rcS脚本，在里面插入一个read-t 指令，这样我就可以打断Linux系统的引导，来制造一个failsafe模式。这个模式有什么用呢？其实就是为了防止后面的修改出错，导致系统直接崩溃掉了。有这个failsafe模式，我就可以回退修改。例如还没进入终端系统就崩溃了，我只能在uboot模式恢复系统了，会很麻烦的。
但是暂时这个修改没有用，因为需要喂狗程序，这个程序在哪，是哪个程序，我都不能确定……先算是一个思路吧。
看看/opt目录
I have no name!@(none) ~$ ls /opt
AndroidAuto g_ether.ko mfid
aoa_adapter g_file_storage.ko net_windows.sh
asix.ko g_hid.ko nw_vmf_ctrl.dat
audio_proc g_iap_ncm_audio.ko nw_vmf_trace.dat
bt g_iap_ncm_eap.ko pss
camera gresfiles pwr_agent
carlife_daemon hal_init ringtone
carplay_App hmi sc_db.db
carplay_testmode.sh hmi.bak screenshot
carplayd hmi_autotest.ini sourceme.sh
cdc_ncm.ko i2cdetect start_carlife.sh
clear-cache.sh iap2d start_carplay.sh
config iperf start_mdnsd.sh
connect_mgr launch.sh stdplus.ini
data launch_aa.sh sysupdate
diag lib test.sh
diag_eol libcidb_sdk.so tools
eol_test.wav md_adapter usbnet.ko
exlap mdnsd vgw
feature_config.ini media vmf
ftpdup2.sh memtool
这里面都是车机的应用程序，有库，配置，图片字体资源文件，各种脚本……
先看看正在跑的都有哪些程序吧。ps -ef
I have no name!@(none) ~$ ps -ef
PID USER TIME COMMAND
1 root 0:00 init
2 root 0:00 [kthreadd]
3 root 0:00 [ksoftirqd/0]
4 root 0:00 [kworker/0:0]
5 root 0:00 [kworker/u:0]
6 root 0:00 [migration/0]
7 root 0:00 [khelper]
8 root 0:00 [kworker/u:1]
235 root 0:00 [sync_supers]
237 root 0:00 [bdi-default]
239 root 0:00 [kblockd]
271 root 0:00 [imx6q-ecspi.0]
274 root 0:00 [imx6q-ecspi.1]
281 root 0:00 [khubd]
298 root 0:00 [ipu1_task]
299 root 0:00 [ipu1_task]
327 root 0:00 [usb_wakeup thre]
329 root 0:00 [otg_switch]
341 root 0:00 [kswapd0]
402 root 0:00 [fsnotify_mark]
411 root 0:00 [crypto]
467 root 0:00 [kapmd]
507 root 0:00 [mtdblock0]
512 root 0:00 [mtdblock1]
517 root 0:00 [mtdblock2]
522 root 0:00 [mtdblock3]
527 root 0:00 [mtdblock4]
532 root 0:00 [mtdblock5]
540 root 0:00 [ubi_bgt0d]
572 root 0:00 [vpu_wq]
577 root 0:00 [galcore workque]
578 root 0:00 [kworker/0:1]
579 root 0:00 [galcore daemon ]
580 root 0:00 [galcore daemon ]
646 root 0:00 [scsi_eh_0]
647 root 0:00 [usb-storage]
723 root 0:00 [kworker/u:2]
725 root 0:00 [kworker/0:2]
756 root 0:00 race_daemon sda true /devices/platform/fsl-ehci.0/usb1/1-
788 root 0:00 [ubi_bgt1d]
792 root 0:00 [ubi_bgt2d]
如果感觉不错，记得回来顶一下
0×00前言
自从去年买了车，对汽车电子系统的兴趣就上来了。这不，前一阵子逛汽车论坛，发现了有网友将老版本的天宝车机被刷上了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来研究一下，至于德赛……先好好地在车上服役，暂时不去虐他了…
关于天宝这个公司，也许是我才接触汽车不久，之前没有听说过。德赛倒是听说过，专门做汽车导航机器的，也给大众代工车机。江苏天宝汽车电子有限公司( http://www.toppower.com )，公司很低调，网站很简陋…看一下职位招聘，都招什么工程师，嗯，CAE工程师、项目工程师、电子工程师、制造工程师，就是没有软件系统工程师，那这机器软件哪来的？大众给的？外包的？此处留下疑问……
0×01硬件
接下来我准备详细分析天宝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，丝印是完整型号。
TPS54388-Q1，2.95V-6V输入，3A输出。NCV896530，2.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源代码，找到了配置调试串口的数据。
ROM:178013AC dword_178013AC DCD 0x62C244 ; DATA XREF: sub_17801278+C8
ROM:178013B0 dword_178013B0 DCD 0x10000100 ; DATA XREF: sub_17801278+D4
ROM:178013BC dword_178013BC DCD 0x14640258 ; DATA XREF: sub_17801278+ECr
ROM:178013C0 dword_178013C0 DCD 0x3716348 ; DATA XREF: sub_17801278+F4r
通过分析uboot头文件mx6dl_pins.h中的宏定义，得出这就是头文件中定义的
MX6_PAD_DECL(KEY_COL0__KEY_COL0, 0x062C, 0x0244, 3, 0x0000, 0, 0)
MX6_PAD_DECL(KEY_ROW0__UART4_RX_DATA, 0x0640, 0x0258, 4, 0x0914, 3, 0)
对比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
dev: size erasesize name
mtd0: 00400000 00020000 "bootloader"
mtd1: 00c00000 00020000 "nand.kernel"
mtd2: 0d000000 00020000 "nand.rootfs"
mtd3: 00a00000 00020000 "pss1"
mtd4: 00a00000 00020000 "pss2"
mtd5: 00c00000 00020000 "logo"
可以发现并没有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 read0x10007FC0 0x400000 0x300000; bootm0x10007FC0
现在可以在uboot提示符下操作了，help查看帮助，看看支持哪些命令，没有网络相关的，因为这主板上没有导出以太网IC……那用什么命令恢复变砖的主板呢。
MX6SOLO STDPLUS U-Boot> help
? - alias for 'help'
autoscr - DEPRECATED - use "source" command instead
base - print or set address offset
bdinfo - print Board Info structure
bld_his -
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
clk - Clock sub system
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
destroyenv- destroy enviroment variables stored in medium
echo - echo args to console
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print online help
i2c - I2C sub-system
iminfo - print header information for application image
imxotp - One-Time Programable sub-system
imxtract- extract a part of a multi-image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nm - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
regul - Regulator sub system
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saveenv_wjs- print saveenv info
sdma - memory transfer using the i.MX SDMA Engine <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<------
setenv - set environment variables
sleep - delay execution for some time
source - 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发行版本中，把这个功能阉割掉了，或者是根本没实现。
那还有哪些命令可以从外部传输数据呢？
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
从串口传输数据，协议是kermit和ymodem，这俩我很熟悉，以前救路由砖的时候用过，WinXP的超级终端就支持这种文件传输协议。其中一个比另一个传输速率稍快一些。但是快能快到哪？理想状态下115200/8 = 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确实找到了一处写看门狗寄存器的代码：
ROM:178037F0 sub_178037F0 ; CODE XREF: sub_17802044+14
ROM:178037F0 ; sub_1780229C+1C
ROM:178037F0 LDR R3, =0x20BC000 <<<<<<<<<<<看门狗1的控制寄存器
ROM:178037F4 MOV R2, #4
ROM:178037F8 STRH R2, [R3]
ROM:178037FC BX LR
寄存器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 1K-blocks Used Available Use% Mounted on
ubi0:rootfs 182808 155908 22064 88% /
mdev 86372 0 86372 0% /dev
none 5120 12 5108 0% /tmp
shm 86372 8 86364 0% /dev/shm
rwfs 512 236 276 46% /mnt/rwfs
rwfs 512 236 276 46% /var
ubi1:pss1 5960 64 5556 1% /pss1
ubi2:pss2 5960 32 5588 1% /pss2
Ubi0:rootfs是根文件系统，他的文件系统是ubifs，这是一套专门为NAND Flash设计的文件系统，具有坏块管理功能。
pss1和pss2里面文件不多，结构一样，估计2是1的备份。
I have no name!@(none) ~$ ls -li /pss1
total 52
65 -rwx------ 1 root root 33 Jan 1 00:00 DIAG_PSS_CODING.pss
66 -rwx------ 1 root root 33 Jan 1 00:00 FEATURE_MANAGER_PSS_BLK.pss
67 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_A2DP_ONOFF_STATUS_PSS_BLK.pss
68 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_ONOFF_STATUS_PSS_BLK.pss
69 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_VISIBLE_ONOFF_STATUS_PSS_BLK.pss
119 -rwx------ 1 root root 9 Jan 1 00:00 HMI_EXLAP_SERVER_ONOFF_PSS_BLK.pss
150 -rwx------ 1 root root 2298 Jan 1 00:01 HMI_SYSTEM_APP_CONNECTION_PLIST_PSS_BLK.pss
118 -rwx------ 1 root root 10 Jan 1 00:00 HMI_SYSTEM_SAFECODE_ASSEMBLY_UNLOCK_PSS_BLK.pss
117 -rwx------ 1 root root 9 Jan 1 00:00 HMI_SYSTEM_SAFECODE_REMAINING_ATTEMPT_PSS_BLK.pss
70 -rwx------ 1 root root 28 Jan 1 00:00 HMI_SYSTEM_SETUP_PSS_NEWBLK.pss
71 -rwx------ 1 root root 78 Jan 1 00:00 TM_PSS_BT_FRIENDLY_NAME_PSS_BLK.pss
75 drwx--x--x 2 messageb messageb 1408 Jan 1 00:00 config
90 -rwxr-xr-x 1 messageb messageb 22 Nov 23 2016 hmi_autotest.ini
146 -rw-r--r-- 1 root root 393 Jan 1 00:00 stdplus.ini
I have no name!@(none) ~$ ls -li /pss2
total 52
65 -rwx------ 1 root root 33 Jan 1 00:00 DIAG_PSS_CODING.pss
66 -rwx------ 1 root root 33 Jan 1 00:00 FEATURE_MANAGER_PSS_BLK.pss
67 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_A2DP_ONOFF_STATUS_PSS_BLK.pss
68 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_ONOFF_STATUS_PSS_BLK.pss
69 -rwx------ 1 root root 9 Jan 1 00:00 HMI_BT_VISIBLE_ONOFF_STATUS_PSS_BLK.pss
70 -rwx------ 1 root root 9 Jan 1 00:00 HMI_EXLAP_SERVER_ONOFF_PSS_BLK.pss
71 -rwx------ 1 root root 2298 Jan 1 00:00 HMI_SYSTEM_APP_CONNECTION_PLIST_PSS_BLK.pss
72 -rwx------ 1 root root 10 Jan 1 00:00 HMI_SYSTEM_SAFECODE_ASSEMBLY_UNLOCK_PSS_BLK.pss
73 -rwx------ 1 root root 9 Jan 1 00:00 HMI_SYSTEM_SAFECODE_REMAINING_ATTEMPT_PSS_BLK.pss
74 -rwx------ 1 root root 28 Jan 1 00:00 HMI_SYSTEM_SETUP_PSS_NEWBLK.pss
75 -rwx------ 1 root root 78 Jan 1 00:00 TM_PSS_BT_FRIENDLY_NAME_PSS_BLK.pss
78 drwxr-xr-x 2 root root 304 Jan 1 00:00 app_data
76 -rwxr-xr-x 1 root root 22 Jan 1 00:00 hmi_autotest.ini
77 -rw-r--r-- 1 root root 393 Jan 1 00:00 stdplus.ini
I have no name!@(none) ~$
看文件名猜测应该是与软件配置相关的一些东西。
再看看/dev目录，都有什么设备。
I have no name!@(none) ~$ ls /dev
apm_bios loop7 mxc_vpu ttymxc3
console mem mxs_viim ttymxc4
cpu_dma_latency mtd0 network_latency ttyp0
crypto mtd0ro network_throughput ttyp1
event0 mtd1 null tuner_knob
event1 mtd1ro pts ubi0
fb mtd2 ptyp0 ubi0_0
fb0 mtd2ro ptyp1 ubi1
fb1 mtd3 ram0 ubi1_0
full mtd3ro ram1 ubi2
galcore mtd4 ram2 ubi2_0
i2c-0 mtd4ro ram3 ubi_ctrl
i2c-2 mtd5 random uinput
i2c-3 mtd5ro sda urandom
kmem mtdblock0 sda1 usbdev1.1
kmsg mtdblock1 shm usbdev1.2
loop0 mtdblock2 snd v850srq
loop1 mtdblock3 spidev0.0 video
loop2 mtdblock4 tracebuf video0
loop3 mtdblock5 tty video1
loop4 mxc_asrc ttymxc0 video16
loop5 mxc_ipu ttymxc1 video17
loop6 mxc_mem ttymxc2 zero
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/
init.d rc.local rc.serial rcS rc_gpu.S
rc.conf rc.modules rc.ts rc_mxc.S
I have no name!@(none) ~$ ls /etc/rc.d/init.d
boa dropbear mdev portmap udev
depmod filesystems mdev_bak settime
devfsd hostname modules smb
dhcp hotplug mount-proc-sys sshd
dhcpd inetd network syslog
I have no name!@(none) ~$
我可以修改其中的rcS脚本，在里面插入一个read-t 指令，这样我就可以打断Linux系统的引导，来制造一个failsafe模式。这个模式有什么用呢？其实就是为了防止后面的修改出错，导致系统直接崩溃掉了。有这个failsafe模式，我就可以回退修改。例如还没进入终端系统就崩溃了，我只能在uboot模式恢复系统了，会很麻烦的。
但是暂时这个修改没有用，因为需要喂狗程序，这个程序在哪，是哪个程序，我都不能确定……先算是一个思路吧。
看看/opt目录
I have no name!@(none) ~$ ls /opt
AndroidAuto g_ether.ko mfid
aoa_adapter g_file_storage.ko net_windows.sh
asix.ko g_hid.ko nw_vmf_ctrl.dat
audio_proc g_iap_ncm_audio.ko nw_vmf_trace.dat
bt g_iap_ncm_eap.ko pss
camera gresfiles pwr_agent
carlife_daemon hal_init ringtone
carplay_App hmi sc_db.db
carplay_testmode.sh hmi.bak screenshot
carplayd hmi_autotest.ini sourceme.sh
cdc_ncm.ko i2cdetect start_carlife.sh
clear-cache.sh iap2d start_carplay.sh
config iperf start_mdnsd.sh
connect_mgr launch.sh stdplus.ini
data launch_aa.sh sysupdate
diag lib test.sh
diag_eol libcidb_sdk.so tools
eol_test.wav md_adapter usbnet.ko
exlap mdnsd vgw
feature_config.ini media vmf
ftpdup2.sh memtool
这里面都是车机的应用程序，有库，配置，图片字体资源文件，各种脚本……
先看看正在跑的都有哪些程序吧。ps -ef
I have no name!@(none) ~$ ps -ef
PID USER TIME COMMAND
1 root 0:00 init
2 root 0:00 [kthreadd]
3 root 0:00 [ksoftirqd/0]
4 root 0:00 [kworker/0:0]
5 root 0:00 [kworker/u:0]
6 root 0:00 [migration/0]
7 root 0:00 [khelper]
8 root 0:00 [kworker/u:1]
235 root 0:00 [sync_supers]
237 root 0:00 [bdi-default]
239 root 0:00 [kblockd]
271 root 0:00 [imx6q-ecspi.0]
274 root 0:00 [imx6q-ecspi.1]
281 root 0:00 [khubd]
298 root 0:00 [ipu1_task]
299 root 0:00 [ipu1_task]
327 root 0:00 [usb_wakeup thre]
329 root 0:00 [otg_switch]
341 root 0:00 [kswapd0]
402 root 0:00 [fsnotify_mark]
411 root 0:00 [crypto]
467 root 0:00 [kapmd]
507 root 0:00 [mtdblock0]
512 root 0:00 [mtdblock1]
517 root 0:00 [mtdblock2]
522 root 0:00 [mtdblock3]
527 root 0:00 [mtdblock4]
532 root 0:00 [mtdblock5]
540 root 0:00 [ubi_bgt0d]
572 root 0:00 [vpu_wq]
577 root 0:00 [galcore workque]
578 root 0:00 [kworker/0:1]
579 root 0:00 [galcore daemon ]
580 root 0:00 [galcore daemon ]
646 root 0:00 [scsi_eh_0]
647 root 0:00 [usb-storage]
723 root 0:00 [kworker/u:2]
725 root 0:00 [kworker/0:2]
756 root 0:00 race_daemon sda true /devices/platform/fsl-ehci.0/usb1/1-
788 root 0:00 [ubi_bgt1d]
792 root 0:00 [ubi_bgt2d]
最后编辑于2017-04-05 11:57:30
很抱歉，该主帖尚未满足精华帖15张图片要求，不能予以精华，更多精华标准点击此处查看
修改主帖
内容系网友发布，涉及安全和抄袭问题属于网友个人行为，不代表汽车之家观点，可联系客服删除。
举报
回复
-
-
什么时候放出德赛的我就服
-
游客
