搬砖笔记

CISCN Android逆向题Writeup

ROP基本思路

1.存在栈溢出（如gets,read）至少能写入到执行至retn时的栈顶处
2.获取shell的函数选择（system,execve,syscall）
3.获取对应函数的地址（看导入表中有无对应函数，如果无，需要通过write或puts等函数泄露相对地址），泄露地址可以通过DynELF实现
4.在栈上布置调用函数所需要的非指针参数（入寄存器的参数通过多次执行含pop寄存器的gadgets实现）
5.指针参数如字符串“/bin/sh”可以采用直接搜索（在ELF中，已知相对地址可在libc中），或者在程序可写的数据段(.bss)中写入。
6.写出若干payload（泄漏地址+布置参数调用起shell函数），注意架构的区别，不能确定调用指令用gcc -S汇编.c文件测试

x64与x86 ROP的区别

首先，x64下的地址长度为8byte，而x86下为4byte
其次，x86中的read,write,system函数都是通过栈传递参数的，因此只要能在栈上写入参数即可。但是x64中则是通过rdx,rsi,rdi(edx,edi,esi)三个寄存器（或三个中的部分）传递参数，因此需要使用ROPgadget或pwntool中的ROP.find_gadget搜索pop相应寄存器的片段，通过栈上保存的参数写入寄存器再调用。

1
2
3

read(fd:edi,*buf:rsi,len:edx)
write(fd:edi,*buf:rsi,len:edx)
puts(*buf:rdi)

本文与 0xFFFF论坛：记录下折腾香橙派过程中踩过的坑 同步

开始使用

几个月之前入手了一块Orange PI One Plus开发板，实际用途是想拿来做个机顶盒（玩的）

本文虽然主要讨论的是One Plus，但很多软件操作同样适用于Orange PI 3

简单说一下硬件资源，这块开发板CPU是全志H6，带4K硬件解码，开发板本身带HDMI，红外，麦克风以及一个千兆网口，详细资料看这里。 其实如果把这块开发板的硬件与树莓派3甚至4比，它的优势是很明显的，毕竟4K硬件解码也是到了4才有，但是软件开发支持不怎么友好。

通过导入电机的阶跃响应数据到Matlab进行系统辨识，并使用PID Tuner对辨识出的系统调节PID参数

RTOS中常用的调度方法

1. 抢占式调度：总是在任务切换时进入就绪态的最高优先级任务执行，若该任务挂起（延时，等待信号量）则进入仅次于该任务优先级的任务，直到该挂起任务等待完成。该调度方式要求每个任务都需要有自己的优先级，能够保证任务的高实时性，但是每次切换保存上下文增加了CPU和内存的负担。
2. 时间片调度：每各一段时间进行一次任务切换，每个任务在执行满一段指定的时间之后即切换到另一个任务（确定下一个任务的算法各异），如果任务挂起则提前切换。该调度方式可与抢占式一起使用，适用于不要求任务实时响应的情况。
3. 合作式调度：每次执行完一个任务后从任务列表（函数指针数组）中取出下一个任务执行，通过CPU在主循环里轮询完成。这种调度方式实时性低，并且当前执行任务不能被打断，但是调度算法简单，只需要使用一个Timer定时刷新任务状态，调度开销低。

以下配置均基于RoboMaster A板

GM6020电机控制

官方例程

在CubeMX里面配好CAN1, 详细配置按照例程来(其实只要Time Quantum一样即可)

PCB设计目标考虑项

1. 实现功能（电源管理，信号处理）
2. 硬件兼容性（接口是否广泛使用、容易获取，是否为现有线路板的接口，考虑Robomaster官方电气零件接口）
3. 机械结构兼容性（考虑机械安装位置，统一螺丝尺寸与孔位，考虑大型接口用螺丝紧固）
4. 硬件复用性，多功能（实现其他冗余功能，同一块板不同用途，可通过飞线或者不焊接元件改变功能）

PCB设计衡量指标

1. 稳定性（电源去耦，信号完整性，散热良好，接口可靠）
2. 选型合理（实际使用远低于极限指标，器件封装易手工焊，参考设计成熟，低成本）
3. 布局合理（走线最短，板面积最小，容易焊接）
4. 保护性（防反接，防过流，防静电，缓启动）

PCB设计规范

CAN通信稳定要求

目前已知机器人会在以下几种情况中由于CAN异常出现控制电机不稳定的现象

• 电机已经离线，PID进程仍然在继续，当电机恢复在线时出现失控
• CAN完全离线，但是仍然在中断里执行有阻塞的发送进程，导致中断系统卡死
• CAN总线上没有一个可应答的电机时，持续向CAN总线上发送数据会使STM32中的CAN模块由于发送应答错误过多而进入离线(Bus-off)，目前已知该状态即使在自动离线管理模式(ABOM)打开的情况下也不能可靠地自动恢复
• CAN总线控制数据发送ID过大，在仲裁优先级里面排最低，在没有自动重传的情况下会出现连续掉帧的情况
• STM32 一个CAN缓冲区只有三个位置，当高速接收时可能会出现Overrun

针对上述问题，在STM32通过CAN控制电机过程中应该：

• 在CAN的配置中打开自动重传(NART清0，注意NART意思是禁用自动重传，清0代表关闭禁用自动重传，在CubeMX图形界面配置时应该要区分开)以及自动离线管理(ABOM)
• 在分配CAN的ID时尽量不使用GM6020中0x2FF的反馈ID
• 在没有收到电机反馈数据不要往CAN总线上发任何数据，即使是没有用PID控制的电机
• 确保使用的HAL库的CAN发送函数不带阻塞（已知目前最新版HAL不存在这个问题）
• 在main函数的主循环内用HAL_CAN_GetState不断检测CAN是否处于离线模式(BOF)，如果是，则重新启动CAN
• 打开CAN的过滤器，将不同ID的包分开到两个缓冲区

现象

在用遥控器控制或静止一段长时间后，哨兵6020电机云台自发地抖动。用手拧云台发现控制过程中的力矩时常不均匀，甚至出现一定角度范围内云台电机无力的情况。这种情况同时出现在Pitch和Yaw轴电机上。

原因分析

由于CAN总线上可能出现多个设备同时发送数据的情况，而同一时刻CAN总线只能被一个设备占用，因此会出现总线争夺的问题。CAN为了解决这一问题，在总线上有一套规则决定哪一方拥有占用总线的权利，我们称它为总线仲裁。控制电机发送频率越高，CAN总线越容易出现冲突。当CAN的带宽不够用的时候仲裁失败必定有一方出现仲裁失败（CAN一帧为111bit，在1Mbps总线上的带宽约为9帧/毫秒，经过计算目前暂时没有发现有机器人出现这个问题，但是对于较多电机的机器人来说把控制频率改高可能会超过总线带宽，使某些帧总是丢失）。仲裁的结果并不是随机的，CAN发送用的ID越小其优先级越高。当小ID与大ID发送冲突时，仲裁的结果是小ID发送成功，大ID发送失败。而在STM32里面仲裁失败不算发送错误，当出现仲裁失败时ALST位将置1（图1），因此在STM32的错误寄存器里看不到有问题。测试时也去确实发现ALST0出现为1的情况

在哨兵电机ID配置中，云台电机被配置为5和6，发送包的ID为0x2FF刚好比所有电机反馈数据的ID都大（见C620和GM6020文档，电机反馈的ID在0x201~0x20B之间），因此出现仲裁情况时第一个失败的是这一帧。偶尔出现丢失不会引起致命的问题，但是控制方4ms发送一帧，当两者发送频率出现同步时，由于4ms电机反馈周期1ms的整数倍，两者冲突的时间会极长，而每次都是STM32发送方仲裁失败，一段时间之后两者发送时刻错开，STM32又能够在总线空闲时发送，因此能明显发现电机出现无力，但又能恢复的情况。而其他机器人如步兵没有使用以0x2FF为ID的帧做控制，其他的ID如0x1FF和0x200都比电机ID小，因此发送方不可能出现仲裁失败。

STM32中的SVC_Handler

SVC：Supervisor Call，指令用于产生一个SVC异常。它是用户模式代码中的主进程，用于创造对特权操作系统代码的调用。SVC是用于呼叫操作系统所提供API的正道。用户程序只需知道传递给操作系统的参数，而不必知道各API函数的地址。
用途：

1. 用于在Unprivileged模式下执行Privileged的代码
2. 中断优先级较高，用于执行一些不能被中断打断的代码（也可以用CPSIE，CPSID指令完成）

参考：https://blog.stratifylabs.co/device/2013-10-12-Effective-Use-of-ARM-Cortex-M3-SVCall/
实例：http://www.keil.com/download/files/stm32_svc.zip

STM32中的PendSV