8level WRT 1200AC firmware tools
1.0.0
该设备使用大型MIPS指令集使用RTL8197DN芯片组。根据我的研究，内部实际的MIPS核心似乎是雷克萨（待验证）。
在启动输入引导加载器模式的同时按WPS并重置。 Bootloader通过UART提供了一个简单的命令接口，并允许通过TFTP上传更新（请参见./upload_update.sh ）。如果引导失败（也用作恢复模式），则自动输入引导加载程序。
当通过TFTP上传更新时，它将在地址0x80500000上加载到RAM中。如果文件是正确的更新文件，则闪烁会自动开始，否则该文件只是在RAM中始终开始，并且可以使用FLW命令手动闪烁。
确认的工作命令：
该设备将带有引导加载器消息和Linux Shell的UART标头曝光。 38400波特
用户名：root密码：任何配置为网络面板的管理员密码的内容（默认：admin）
一切都大的末日。有关解析更新文件的脚本，请参见./check_update.py 。
更新文件由以下块串联在一起：
| 抵消 | 尺寸 | 描述 |
|---|---|---|
| 0 | 4 | 文件类型 - 请参阅https：//github.com/jameshilliard/wecb-vz-gpl/blob/master/rtl819x/bootcode/boot/boot/init/rtk.h for有效类型。我们似乎只使用rootfs的内核和“ R6CR”的设备（可能是引导加载程序的“启动”？） |
| 4 | 4 | RAM中的负载地址（仅用于内核图像？） |
| 8 | 4 | 闪存中的地址 |
| 12 | 4 | 数据长度 |
| 16 | * | 数据 |
数据被检查 - 所有字节的16位大端总和必须为0x0000（除非您闪烁的Web文件分区，否则该设备没有该分区 - 在这种情况下，校验和为8位）。这通常是通过在末尾附加两个字节来实现的。
当Bootloader首先尝试加载〜4个硬编码地址时，然后继续搜索整个闪光灯以寻找签名，这似乎表明闪存布局在不同的设备上可能有所不同。数据对上面的更新文件具有相同的校验和检查。
请参阅./split_img.sh
| 开始地址 | 结束地址 | 标题 | 描述 |
|---|---|---|---|
| 0x00000000 | 0x00006000 | - | 引导加载器代码 |
| 0x00006000 | 0x00008000 | H601（？） | 硬件配置（MAC地址等） |
| 0x00008000 | 0x00010000 | compds（？） | 默认配置 |
| 0x00010000 | 0x00018000 | compcs（？） | 当前配置 |
| 0x00018000 | 0x00138000 | 更新CR6C的标题 | Linux内核，带有与更新标头格式相同的标头 |
| 0x00138000 | 0x00327002 | Squashfs文件系统标头，从HSQS开始 | 根文件系统。为校验和添加了最后两个字节。 |
| 0x00327002 | 0x00400000 | - | 0xff 0xff 0xff 0xff ... |
