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 ... |
