教程网站非常厚道，提供了各种所需物料的链接，三星几乎所有机型的驱动清单页面为 https://www.skyneel.com/download-latest-samsung-usb-drivers。其中 S6 的驱动程序的各版本都可以在页面 https://www.skyneel.com/samsung-driver 上找到，我下载的是当前最新的 1.7.11，目标链接为 https://drive.google.com/file/d/1YReLOU-crLt0Mr1ii9VzTUNmJh08d-7j/view。在教程页面里接着要下载的就是自动 root 的工具包，根据机型选择即可。

准备工作完毕，开始。
1. 安装驱动程序，工具包解压待用；
2. 把手机的开发者选项中的 USB 调试模式开启；
3. 与电脑连接后关机；同时按下音量减、Home 并保持，再按下电源键持续一会儿直到开机，按音量加，进入 Download 模式；
4. 电脑自动安装 Download 模式的驱动完毕后，运行工具包中解出的 odin-xxx.exe，点击出现的界面上右下部的 AP 按钮，在文件选择对话框里选中解压出的 .tar.md5 文件；
5. 点击 start，直到左上表示所连接的手机的长方块变成绿色，则 root 过程完毕。

接下来安装 Xposed Framework。到 https://www.xda-developers.com/xposed-framework-hub/ 处，根据指引，导航进入 https://forum.xda-developers.com/showthread.php?t=3034811 下载 3.1.5 的 apk（这是一个安装器应用），复制到手机的 Download 目录下。到手机上找到并安装之。打开装好的安装器，在界面上选择框架版本（Version 89 吧，应该也不会变了）进行安装。安装时会需要 root 权限，同意即可。安装完毕重启，大功告成。

更新：下午到晚上，一直不甘心自己的 S6 为什么总是 root 失败，将以上步骤在家里的电脑上不停尝试。出现的问题是，手机启动到 Download 模式连接电脑后，Odin 检测不到，但在设备管理器里相应的 USB 串口已经出现。在百撕不得骑姐之际，突然想起一件重要的事情：不管是上次在单位的电脑上反复 root 失败，还是这次在家里反复 root 失败，跟上午的 root 成功有一个灯下黑方面的差异：成功的电脑是 Windows 7，而失败的都是 Windows 10。临睡前把收藏的 T60 搬出来，进入 Windows 7 再次尝试，果然成功！

看着这个名为 1FF-olympus_hktw-user-2.3.4-4.5.2A-74_OLH-25-release-keys-signed-Retail-05.sbf 的 1.5GB 的大文件，当务之急是要找个工具能对它进行分析，对其中的部分进行提取。迅速到网上做了检索，百度经验里有一篇文章进行了讲解，《怎样解包和打包摩托罗拉的 sbf 文件》，里面提到的工具叫做 MotoAndroidDepacker。三太爷看着文章里的插图就乐开了花，Recovery 映像对应哪个文件清清楚楚。兴冲冲地按这个名字搜索并下载了工具，让它打开文件的时候竟然无耻地说打开失败！还好我老人家脑速飞快，瞬间想到工具的版本可能有问题，一看信息，是个 1.2 alpha 的版本，感觉就有点不靠谱。手动把版本号加到 1.3 再搜，竟然真有（http://bbs.mfunz.com/thread-186627-1-1.html），这次下载下来，果然就能打开了。

老天爷的考验无处不在。工具确实可以把 sbf 拆解为若干文件，但是信息表里却并没有说哪个文件是 Recovery 分区的映像文件。只好想招，从大小上着手。先去看了看 CWM Recovery 文件的大小，大概是 3MB 多，于是在分拆出来的一堆文件里找和这个尺寸相近的，发现了两个 3MB 左右的文件（此处三太爷犯了个错误，后文再说）。用 HxD 打开观察，挑中了一个感觉更像是 Recovery 映像的，依据是在里面找到了“Recovery”的字串。用 adb push 把它传到了手机上，命名为 recovery.img，然后 adb shell，su 切换到 root 身份，谋划到底该把它刷到哪个分区里。既然文件是按大小选出来的，那何不选定分区也按大小来呢？使用 cat /proc/partitions 命令，发现 mmcblk0p1 恰好在 3MB 与 4MB 之间。为了确认不会刷坏，还特意先 dd 它之前的内容到一个文件里进行了查看，所有字节都是 0。这种情况有两个可能，一是这个分区并非 Recovery 分区，二是固件管理器当初信誓旦旦说的刷入成功其实是个假象。我选择了相信后者，与其说是相信，不如说是宁可相信。其实心里还有另一重考虑，一个全部内容为零的分区，即使刷错了，也不应该有太大的恶劣后果。用 dd 命令把从电脑上传来的 recovery.img 刷到了 mmcblk0p1 分区，成功；重启手机，试图进入 Recovery 模式，失败，错误没变。很显然，那个分区不对。

又经过一些试验，突然想到可以用内容比对的方式来确定。一边是固件管理器下载下来的 CWM Recovery 映像文件（按照常理推测，软件不会自动把下载的此类文件删除，而事实上也很轻松就找到了），一边是依次检索各个分区当前的内容，哪个分区对上了，哪个就是 Recovery 分区。首先还是根据大小，选了 3 个分区来做比较，最后终于确定到了 mmcblk0p10。把 recovery.img 刷到 mmcblk0p10 分区，重启，在菜单里选择进入 Recovery 模式，Failed to boot 2 字样消失，成了 starting RSD protocol support。我老人家瞬间明白：1、分区找对了，2、recovery 映像文件找错了。上文说到三太爷曾犯了个错误，其实就在这个地方。如果稍微再仔细一点，从 cat /proc/partitions 命令的输出结果中就应该能看到并联想到，从底包中提取出来的映像文件的大小，和它对应的分区的大小应该是一致的。那么，当时看到 CWM Recovery 的映像文件大小接近 4MB，那么原始 Recovery 的映像文件很显然就不会是更小的文件。

从底包中拆解出来的文件中，大小与 mmcblk0p10 分区匹配的有两个，一个名为 CG58.smg，一个是 CG59.smg，那么哪个才是 Recovery？现在就好办了，既然有两个大小一样的文件，显然手机上就还会有一个和 mmcblk0p10 大小一样的分区（事实上是 mmcblk0p11），把 mmcblk0p11 的内容 dd 转储出来，发现与 CG59.smg 的内容完全匹配，从而得出 CG58.smg 就是原装的 Recovery 映像。再次用 adb 将之传送，并 dd 到 mmcblk0p10 上，重启尝试进入 Recovery 模式，那个摆了个三角架的小机器人终于又出现了。所有这些情况，表明 MB860 的 bootloader 很强悍，对系统做了非常严格的控制，常规方法无法更改，强行更改则无法运行。

兜兜转转，回到原点。高人说：1、这是折腾的真意；2、这是盘旋上升。顺便说一句，最开始刷错的那个分区，我老人家也在第一时间纠正了：dd if=/dev/zero of=/dev/block/mmcblk0p1。

中间其实还了解到一些别的知识，例如 CWM Recovery 究竟是如何满足大家的补丁需求的。既然刷自定义的 Recovery 受阻，三太爷将挑战一下如何把需要 Recovery 完成的工作在 root 下完成。

目前只是了解了些皮毛，接下来需要一些实践。三太爷到底能不能仅靠有 root 就把 Debian 部署到 MB860 上且与 WebTop 和平共处呢？欲知后事如何，且听下回分解。