近日所接一个嵌入式相关的逆向单子，因为过程弯路走的太多加上一开始方向错误而浪费了不少时间与精力

所幸最后还是在一个下午加晚上的努力下完成了这单，于是此处写一篇笔记以做记录。

逆向诺基亚U-00160CP-P实现固件上传

首先，在路由器的前端页面上进行固件上传，同时通过putty连接终端查看后台反馈，

据报错可知tag部分校验出错，即根据经验判断，找到这个固件的tag应该就是通过固件校验的必要条件。
于是此时先通过usb备份提取出路由器的系统文件，并进行一些基础性判断。

通过uname得知该os为aarch64架构，同时常规包管理器不生效，推测shell所用为busybox。
后对上传固件的网页进行逆向

则可定位到网页的固件最终上传到了后台的cgi，并且在cgi中进行固件校验。因此只需要逆向相关的cgi内容便可定位校验逻辑。但最终因cgi较难反编译，便只能从中寻找出部分可疑字符串。

经分析得HDR5701可能为本机型号，但尝试失败
后根据系统文件再查

对可疑字符串进行以此尝试，报错却仍然相同。
再经过多次尝试查找后，便开始转换思路
既然无法直接寻找到验证逻辑，那便通过寻找报错提示来间接反向定位校验逻辑
此时通过编写python脚本来对整个os的所有文件进行遍历，以定位错误反馈代码所在

搜索结果得：

可知错误代码源来自/usr/local/lib/libinfra.so，对so文件进行逆向后查找InfoError可得

再进入函数中查看汇编代码

再顺着逻辑树反向溯源，可得最终验证逻辑对代码进行分析可知，在v5的类型为int，溯源可知v5实际上是fp的函数指针，经mmap分配内存空间后传递到该函数内，即在该函数中，该内容会对所传入文件的头部字节进行字符串对比，并在校验成功后进行下一次while，同时指针地址向后偏移64位，且校验字符串不分先后顺序，只需要连续偏移三次，通过四次校验后即可完成验证，同时返回result=0，代码如下：

此时，按照猜想先将文件的头部字符串改为MTD_BOOT_TAG，并进行尝试：

如图，此时的错误tag已经变成了VB25，而非文件开头的MTD，即验证了先前的猜想，固件在上传进行验证时会进行偏移多次验证。
此时再创建一个空白文件并按照规则编写16进制测试头

尝试进行固件上传后，后台反馈校验通过

最终，固件上传成功，路由器因空白固件而变砖，测试有效。再通过固件编程器进行二刷，成功上传所需固件。