校电赛结束了,今年校内赛的题目大多都是前年的国电题目,有将近一个月的时间完成。可以拿来练练手,为后面的比赛做准备。下面介绍一下我们的选题以及对应方案。
选题
校电赛选的题目无非几类,传统电源题(做的人非常少),控制题,仪器仪表题以及最近新兴的视觉/智能题。高频/通信题因为知识水平的问题在校赛里不会出现。而我们队的选题是常规的仪器仪表题:放大器非线性失真研究装置。
当时选的具体理由不记得了,大概是选了一圈下来可能觉得信号处理的题目相对简单。
CISCN Android逆向题Writeup
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下的地址长度为8byte,而x86下为4byte
其次,x86中的read,write,system函数都是通过栈传递参数的,因此只要能在栈上写入参数即可。但是x64中则是通过rdx,rsi,rdi(edx,edi,esi)三个寄存器(或三个中的部分)传递参数,因此需要使用ROPgadget或pwntool中的ROP.find_gadget搜索pop相应寄存器的片段,通过栈上保存的参数写入寄存器再调用。
1 | read(fd:edi,*buf:rsi,len:edx) |
本文与 0xFFFF论坛:记录下折腾香橙派过程中踩过的坑 同步
几个月之前入手了一块Orange PI One Plus开发板,实际用途是想拿来做个机顶盒(玩的)
本文虽然主要讨论的是One Plus,但很多软件操作同样适用于Orange PI 3
简单说一下硬件资源,这块开发板CPU是全志H6,带4K硬件解码,开发板本身带HDMI,红外,麦克风以及一个千兆网口,详细资料看这里。 其实如果把这块开发板的硬件与树莓派3甚至4比,它的优势是很明显的,毕竟4K硬件解码也是到了4才有,但是软件开发支持不怎么友好。
通过导入电机的阶跃响应数据到Matlab进行系统辨识,并使用PID Tuner对辨识出的系统调节PID参数
目前已知机器人会在以下几种情况中由于CAN异常出现控制电机不稳定的现象
针对上述问题,在STM32通过CAN控制电机过程中应该:
在用遥控器控制或静止一段长时间后,哨兵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小,因此发送方不可能出现仲裁失败。