|
【摘要】 战争的残酷属性不会因为我们的不足而有丝毫改变，仅以此文祭奠我们在第二届网鼎杯丢失的455高地。 【关键词】 汽车通讯协议、汽车ECU、ARM
一、455高地 Misc类目Teslaaaaa，3人攻破，分值455，全场失守阵地中分值最高的领地；若能拿下，仅凭一题就能在初赛中位列青龙组前50，更不用说160名的半决赛投名状了。
如图，我们觉得它可以归类为攻击汽车系统演化而来的逆向题。
上图中，提示使用的是CAN协议，协议参考标准为【ISO 15765-2】和【ISO 14229-1】 【点击打开图片】，应该注意到这是汽车ECU单元，芯片为嵌入式ARM；
如图，题目附件teslaaaaa.zip（参考附件）解压出来就一个CAN通讯记录文件
文件内容胜利如下，是CAN bus汽车通讯协议的标准通讯帧 [pre]date Thu Apr 2 10:37:15.950 am 2020
base hex timestamps absolute
internal events logged
// version 8.2.1
0.005921 CAN 1 Status:chip status error active
1.005921 CAN 1 Status:chip status error active
2.005922 CAN 1 Status:chip status error active
3.005922 CAN 1 Status:chip status error active
4.000621 1 7DF Tx d 8 02 3E 80 00 00 00 00 00 Length = 0 BitCount = 124 ID = 2015 // 1 OTP(01) Atom 7DF->7DF : SF Length: 02 [ 3E 80 ]
4.005922 CAN 1 Status:chip status error active
5.005922 CAN 1 Status:chip status error active
6.005923 CAN 1 Status:chip status error active
7.005923 CAN 1 Status:chip status error active
8.000537 1 7DF Tx d 8 02 3E 80 00 00 00 00 00 Length = 0 BitCount = 124 ID = 2015 // 1 OTP(02) Atom 7DF->7DF : SF Length: 02 [ 3E 80 ]
8.005923 CAN 1 Status:chip status error active
9.005924 CAN 1 Status:chip status error active
9.498709 1 7DF Tx d 8 02 10 02 AA AA AA AA AA Length = 0 BitCount = 116 ID = 2015 // 1 OTP(03) Atom 7DF->7DF : SF Length: 02 [ 10 02 ]
9.499693 1 7B0 Rx d 8 06 50 02 00 32 01 F4 00 Length = 235910 BitCount = 122 ID = 1968
...略...
10.314499 1 730 Tx d 8 02 37 01 AA AA AA AA AA Length = 222259 BitCount = 114 ID = 1840
10.315695 1 7B0 Rx d 8 06 77 01 C6 B6 5E 10 00 Length = 225910 BitCount = 117 ID = 1968
10.318529 1 730 Tx d 8 04 31 01 DF FF AA AA AA Length = 226244 BitCount = 116 ID = 1840
10.319707 1 7B0 Rx d 8 03 7F 31 78 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
10.320695 1 7B0 Rx d 8 05 71 01 DF FF 00 00 00 Length = 233910 BitCount = 121 ID = 1968
10.322633 1 730 Tx d 8 04 31 01 FF 01 AA AA AA Length = 226244 BitCount = 116 ID = 1840
10.323695 1 7B0 Rx d 8 05 71 01 FF 01 00 00 00 Length = 233910 BitCount = 121 ID = 1968
10.325697 1 7DF Tx d 8 02 11 01 AA AA AA AA AA Length = 0 BitCount = 115 ID = 2015 // 1 OTP(04) Atom 7DF->7DF : SF Length: 02 [ 11 01 ]
10.326689 1 7B0 Rx d 8 03 7F 11 78 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
11.005924 CAN 1 Status:chip status error active
11.326752 1 7B0 Rx d 8 02 51 01 00 00 00 00 00 Length = 235910 BitCount = 122 ID = 1968
12.000742 1 7DF Tx d 8 02 3E 80 00 00 00 00 00 Length = 0 BitCount = 124 ID = 2015 // 1 OTP(05) Atom 7DF->7DF : SF Length: 02 [ 3E 80 ]
12.005925 CAN 1 Status:chip status error active
13.005925 CAN 1 Status:chip status error active
14.005925 CAN 1 Status:chip status error active
15.005926 CAN 1 Status:chip status error active
16.000532 1 7DF Tx d 8 02 3E 80 00 00 00 00 00 Length = 0 BitCount = 124 ID = 2015 // 1 OTP(06) Atom 7DF->7DF : SF Length: 02 [ 3E 80 ]
16.005926 CAN 1 Status:chip status error active[/pre]二、CAN协议的标准帧
在CAN协议的网络层，结点之间通讯的基本网络协议数据单元构为 N_PDU(Protoco Data Unit), N_PDU由三部分构成，如图
[pre]N_PDU : N_AI,N_PCI,N_Data //The protocol data unit (N_PDU)
N_AI : N_SA,N_TA,N_TAtype[,N_AE] //Address information (N_AI)
N_PCI : //Protocol control information (N_PCI)
N_Data : //Data Field (N_Data)[/pre]1、N_PDU结构，截图源自【ISO-15765-2-2004】
2、N_PCI结构，截图源自【ISO-15765-2-2004】
3、CAN的标准帧结构 （3.1）11字节的标准通讯帧 [pre]（A）CAN的标准帧固定为11个字节,我们依次定义为 Byte1,...,Byte11
（B）每个字节8位从高到低，依次定义位 ByteN.bit7,...,ByteN.bit0;其中N为1到11
（C）则CAN标准帧的基本格式为
Byte1.bit7,Byte1,bit6,x,x,Byte1.bit3~0
Byte2.bit7~0 //as CanID.10~3
Byte3.bit7~6,x,x,x,x,x // as CanID.2~0
Byte4~Byte11 // as N_PCI，N_Data
其中
Byte1.bit7=0 指示通讯帧为CAN标准帧
Byte1,bit6=0 指示通讯帧为数据帧，此时 N_PCI 部分才有效
Byte1.bit3~0 指示 N_PCI 和 N_Data 的长度
Byte2.bit7~0和Byte3.bit7~6 构成11位的报文ID
N_PCI 的格式参考上面截图
N_Data 的的定义参考【ISO-14229-1】[/pre]（3.2）实例 [pre]如下
9.498709 1 7DF Tx d 8 02 10 02 AA AA AA AA AA Length = 0 BitCount = 116 ID = 2015
9.499693 1 7B0 Rx d 8 06 50 02 00 32 01 F4 00 Length = 235910 BitCount = 122 ID = 1968[/pre][pre]说明：
（A）其中的 ID = 2015 即 7DF就是11位的报文ID，所以有
Byte2=0x7DF>>3 = 0xFB
Byte3=(0x7DF&7)<<5 = 0xE0
（B）即上述【7DF Tx d 8 02 10 02 AA AA AA AA AA】在CAN通讯线路上监控得到的CAN标准帧是
【08 FB E0 02 10 02 AA AA AA AA AA】
其中08指示 Byte1.bit7=0，Byte1,bit6=0，Byte1.bit3~0=8即N_PCI 和 N_Data的总长度，
CAN标准数据帧的N_PCI 和 N_Data长度固定为8字节，有效字节由帧内指定，冗余字节收发双方自动截断丢弃。[/pre]（3.3）N_PCI 和 N_Data
如前面的N_PCI结构图 [pre]（A）N_PCI高四位 N_PCIType 指示了N_PCI的类型
0x0*为单帧SF
0x1*为多帧中的首
0x2*为多帧中的后续帧
0x3*为流控制
（B）如以下通讯对话
7DF Tx d 8 02 10 02 AA AA AA AA AA
7B0 Rx d 8 06 50 02 00 32 01 F4 00
表示给汽车ECU单元发送Tx单帧0x02&0xF0=0=SF,单帧中的有效内容为0x02&0x0F=2字节 10 02;后面的AA AA AA AA AA为多余被丢弃的数据
而接收Tx到来自汽车ECU单元反馈的单帧0x06&0xF0=0=SF,单帧中有效内容为0x06&0x0F=6字节 50 02 00 32 01 F4；后面的00为多余被丢弃的数据[/pre]三、Tester 与 汽车ECU的会话内容 每个单帧或多帧通讯的有效内容，就是通讯双方的真实对话，下面我们结合【ISO-14229-1-2013】解读日志记录了双方进行了什么类型的通讯对话。 1、通讯内容 （1）【7DF Tx d 8 02 3E 80 00 00 00 00 00】 说明：实现链路保持，即告诉作为服务端的汽车ECU，作为客户端的Tester还在线；若长时间没有告知，服务端就会关闭会话。 [pre]TesterPresent (0x3E) service
实际题目中的汽车ECU并不需要进行链路保持，这算是测试者Tester作为客户端有备无患的策略，甭管服务端是否需要链路保持，总不定时发送链路保持。
如果服务端有需要链路保持，其Tester端会收到服务端的链路保持正响应。如
【02 7E 80】[/pre]
（2）【10 02】开启编程会话 [pre]这里通知ECU开启编程会话，得到了服务器的正响应【50 02】并返回了部分编程会话参数，
正响应都是请求的服务ID（这里SID=0x10)与0x40或运算为0x50;会话出错或拒绝的否定响应都是7F SID +错误代码等内容;
9.498709 1 7DF Tx d 8 02 10 02 AA AA AA AA AA Length = 0 BitCount = 116 ID = 2015
| |programmingSession enables all diagnostic services required to support the memory programming of a server.
|DiagnosticSessionControl (10 hex) service:used to enable different diagnostic sessions in the server(s).
9.499693 1 7B0 Rx d 8 06 50 02 00 32 01 F4 00 Length = 235910 BitCount = 122 ID = 1968
| | | |
| | | |P2*Server_max = 0x01F4*10ms = 5000ms
| | |P2Server_max = 0x0032*1ms = 50ms
| | |
| | |sessionParameterRecord[]
| |diagnosticSessionType
|DiagnosticSessionControl Response Service Id[/pre]（3）【27 05】【07 06】安全校验 [pre]（3.1）因为是编程会话，可以刷写汽车上的ECU单元，安全等级较高，需要进行安全验证
安全验证的基本过程：
(A) Tester 发送[27 05]请求安全验证，汽车ECU正响应返回 seed=0x11223344
(B) Tester 根据接收的seed=0x11223344，使用双方协定的安全算法函数algo_op，计算得到 key = algo_op(seed)
(C) Tester 发送[27 06 key]给汽车ECU，若与汽车ECU使用algo_op计算的结果匹配，则通过验证，返回正响应【67 06】
（3.2）关于这个安全算法algo_op，
(A)汽车厂商及其授权的合作商会知道；
(B)第三者通过逆向汽车ECU可以知道，这种方法比较局限，只能都特定汽车ECU特定会话有效，且工作量较大；
(C)第三者更多通过逆向汽车厂商的诊断设备来获取，这种方法简单，并可以获取汽车厂商所有支持的车系的所有ECU所有功能的校验算法；
9.740585 1 730 Tx d 8 02 27 05 AA AA AA AA AA Length = 222015 BitCount = 114 ID = 1840
9.741697 1 7B0 Rx d 8 06 67 05 11 22 33 44 00 Length = 223910 BitCount = 116 ID = 1968
如果这里Tester发送的key=EE DD CC BB AA不是使用与汽车ECU相同的algo_op计算的，汽车ECU将匹配失败，拒绝后续会话
9.782739 1 730 Tx d 8 06 27 06 EE DD CC BB AA Length = 226244 BitCount = 116 ID = 1840
9.783703 1 7B0 Rx d 8 02 67 06 00 00 00 00 00 Length = 235910 BitCount = 122 ID = 1968
[/pre]（4）【31 01 FF 00 44 08 00 00 00 00 00 20 00】 [pre]Tester请求汽车ECU执行擦除eraseMemory过程，参数是，内存开始地址，和内存大小
其中44分别标记后面的地址和大小的字宽都是4字节，即要擦除 0x08000000 处 大小 0x00002000 的存储
9.788131 1 730 Tx d 8 10 0D 31 01 FF 00 44 08 Length = 232000 BitCount = 119 ID = 1840
9.788431 1 7B0 Rx d 8 30 08 00 00 00 00 00 00 Length = 239910 BitCount = 124 ID = 1968
9.788947 1 730 Tx d 8 21 00 00 00 00 00 20 00 Length = 244244 BitCount = 125 ID = 1840
9.789707 1 7B0 Rx d 8 05 71 01 FF 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
31 01 FF 00 44 08 00 00 00 00 00 20 00
| | | |
| | | |
| | | |routineControlOptionRecord[] // defined by the vehicle manufacturer.
| | |routineIdentifier:=0xFF00 eraseMemory >> used to start the server's memory erase routine
| |routineControlType RoutineControl Request SID := startRoutine
|RoutineControl (0x31) service:used by the client to execute a defined sequence of steps and obtain any relevant results.
71 01 FF 00 00
|routineInfo //is vehicle manufacuter specific and provides a mechanism[/pre]
（5）【34 00 44 08 00 00 00 00 00 20 00】
[pre]Tester请求下载数据RequestDownload，这个概念跟我们进行嵌入式开发时，最终需要把内容下载烧写到片上flash类似。
这里的44与上面的意思相同，指示后面参数字宽；下载数据到汽车ECU的0x08000000位置，数据大小为 0x00002000
这里的正响应告诉Tester，每次接收的数据大小最大可为 maxNumberOfBlockLength:=0x0102字节。
9.791765 1 730 Tx d 8 10 0B 34 00 44 08 00 00 Length = 236244 BitCount = 121 ID = 1840
9.792061 1 7B0 Rx d 8 30 08 00 00 00 00 00 00 Length = 239910 BitCount = 124 ID = 1968
9.792625 1 730 Tx d 8 21 00 00 00 20 00 AA AA Length = 234244 BitCount = 120 ID = 1840
9.793715 1 7B0 Rx d 8 04 74 20 01 02 00 00 00 Length = 233910 BitCount = 121 ID = 1968
34 00 44 08 00 00 00 00 00 20 00
| | | | |
| | | | |memorySize:=0x00002000
| | | |memoryAddress:=0x08000000 is the starting address of the server memory where the data is to be written to
| | |addressAndLengthFormatIdentifier
| | |bit 7 - 4: Length (number of bytes) of the memorySize parameter
| | |bit 3 - 0: Length (number of bytes) of the memoryAddress parameter
| |dataFormatIdentifier:0x00 compressionMethod-encryptingMethod
| |0x00 specifies that neither compressionMethod nor encryptingMethod is used
|RequestDownload (34 hex) service:used by the client to initiate a data transfer from the client to the server (download)
74 20 01 02
| | |
| | |maxNumberOfBlockLength:=0x0102
| |bit 3 - 0: reserved by document, to be set to '0'.
| |bit 7 - 4: Length (number of bytes) of the maxNumberOfBlockLength parameter.
| |lengthFormatIdentifier
|RequestDownload Response SID[/pre]（6s）【36 xx data】[pre]Tester 开始给汽车ECU传送刷写的数据，如上所提
maxNumberOfBlockLength为0x0102，除去[36 xx],有效的数据每次最多可以发送0x102-2=256个字节。
但Tester在这里每次只发送一半，有所保留，即0x80=128个字节；
(A)其中【7F 36 78】是错误响应，错误代码为78，厂家自定义，这里没影响，因为最终有个肯定响应（B）
(B)【76 xx】，表明汽车ECU已经正确接收这部分发送的数据并存储处理
(C) 其中 xx 为数据块编号，从1开始自动加1，一直到【36 40】，即总共成功发送了0x80*0x40=0x2000大小的数据，这些就是刷写到0x08000000地址的内容。
9.795696 1 730 Tx d 8 10 82 36 01 28 04 00 20 Length = 232244 BitCount = 119 ID = 1840
9.795987 1 7B0 Rx d 8 30 08 00 00 00 00 00 00 Length = 239910 BitCount = 124 ID = 1968
9.796548 1 730 Tx d 8 21 45 01 00 08 21 03 00 Length = 236244 BitCount = 121 ID = 1840
9.796790 1 730 Tx d 8 22 08 23 03 00 08 27 03 Length = 236244 BitCount = 121 ID = 1840
9.797030 1 730 Tx d 8 23 00 08 2B 03 00 08 2F Length = 234000 BitCount = 120 ID = 1840
9.797278 1 730 Tx d 8 24 03 00 08 00 00 00 00 Length = 242000 BitCount = 124 ID = 1840
9.797526 1 730 Tx d 8 25 00 00 00 00 00 00 00 Length = 242000 BitCount = 124 ID = 1840
9.797770 1 730 Tx d 8 26 00 00 00 00 00 33 03 Length = 238000 BitCount = 122 ID = 1840
9.798012 1 730 Tx d 8 27 00 08 35 03 00 08 00 Length = 236000 BitCount = 121 ID = 1840
9.798256 1 730 Tx d 8 28 00 00 00 37 03 00 08 Length = 238000 BitCount = 122 ID = 1840
9.798556 1 7B0 Rx d 8 30 08 00 00 00 00 00 00 Length = 239910 BitCount = 124 ID = 1968
9.799088 1 730 Tx d 8 29 39 03 00 08 5F 01 00 Length = 232259 BitCount = 119 ID = 1840
9.799329 1 730 Tx d 8 2A 08 5F 01 00 08 5F 01 Length = 234259 BitCount = 120 ID = 1840
9.799569 1 730 Tx d 8 2B 00 08 5F 01 00 08 5F Length = 234015 BitCount = 120 ID = 1840
9.799809 1 730 Tx d 8 2C 01 00 08 5F 01 00 08 Length = 234015 BitCount = 120 ID = 1840
9.800049 1 730 Tx d 8 2D 5F 01 00 08 5F 01 00 Length = 234015 BitCount = 120 ID = 1840
9.800291 1 730 Tx d 8 2E 08 5F 01 00 08 5F 01 Length = 236015 BitCount = 121 ID = 1840
9.800531 1 730 Tx d 8 2F 00 08 5F 01 00 08 5F Length = 234015 BitCount = 120 ID = 1840
9.800773 1 730 Tx d 8 20 01 00 08 5F 01 00 08 Length = 236015 BitCount = 121 ID = 1840
9.801077 1 7B0 Rx d 8 30 08 00 00 00 00 00 00 Length = 239910 BitCount = 124 ID = 1968
9.801509 1 730 Tx d 8 21 5F 01 00 08 5F 01 00 Length = 234244 BitCount = 120 ID = 1840
9.801745 1 730 Tx d 8 22 08 5F 01 00 08 AA AA Length = 230244 BitCount = 118 ID = 1840
|TransferData (36 hex) service
36 01 28 04 00 20 45 01 00 08 21 03 00 .. 08 5F 01 00 08
| | |transferRequestParameterRecord[] //For a download, the transferRequestParameterRecord include the data to be transferred
| |blockSequenceCounter
|TransferData (0x36) service
9.802687 1 7B0 Rx d 8 03 7F 36 78 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
9.802931 1 7B0 Rx d 8 02 76 01 00 00 00 00 00 Length = 235910 BitCount = 122 ID = 1968[/pre]（7）【37 01】下载完成，退出下载环节
[pre] 10.314499 1 730 Tx d 8 02 37 01 AA AA AA AA AA Length = 222259 BitCount = 114 ID = 1840
|
|RequestTransferExit (0x37) service
10.315695 1 7B0 Rx d 8 06 77 01 C6 B6 5E 10 00 Length = 225910 BitCount = 117 ID = 1968[/pre]（8）【31 01 DF FF】请求执行0xDFFF标志的过程，这里为厂家定义，估计是自校验或正式写入flash一类过程。
[pre] 10.318529 1 730 Tx d 8 04 31 01 DF FF AA AA AA Length = 226244 BitCount = 116 ID = 1840
10.319707 1 7B0 Rx d 8 03 7F 31 78 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
10.320695 1 7B0 Rx d 8 05 71 01 DF FF 00 00 00 Length = 233910 BitCount = 121 ID = 1968
|startRoutine
| 0xDFFF This range of values is reserved for vehicle manufacturer specific use
[/pre]（9）【31 01 FF 01】请求执行0xFF01标志的过程，过程名称为checkProgrammingDependencies，检查编程相关项。
[pre] 10.322633 1 730 Tx d 8 04 31 01 FF 01 AA AA AA Length = 226244 BitCount = 116 ID = 1840
10.323695 1 7B0 Rx d 8 05 71 01 FF 01 00 00 00 Length = 233910 BitCount = 121 ID = 1968
| 0xFF01 checkProgrammingDependencies[/pre]（10）【11 01】请求重启汽车ECU
[pre] 10.325697 1 7DF Tx d 8 02 11 01 AA AA AA AA AA Length = 0 BitCount = 115 ID = 2015 // 1 OTP(04) Atom 7DF->7DF : SF Length: 02 [ 11 01 ]
10.326689 1 7B0 Rx d 8 03 7F 11 78 00 00 00 00 Length = 233910 BitCount = 121 ID = 1968
11.005924 CAN 1 Status:chip status error active
11.326752 1 7B0 Rx d 8 02 51 01 00 00 00 00 00 Length = 235910 BitCount = 122 ID = 1968
| ECUReset (0x11) service[/pre]2、我们整理下Tester与汽车ECU的通话的核心内容
[pre]（A）Tester请求编程会话
（B）Tester通过编程会话安全校验，得到许可
（C）Tester往汽车ECU的0x08000000写入了0x2000长的数据
（D）Tester请求重启汽车ECU[/pre] 说明：我们前面知道，汽车的ECU为ARM，其中0x08000000地址一般作为第二BootLoader地址，即Tester让汽车ECU执行自己写入的内容。
四、代码数据提取与逆向 现在我们将注意力集中在Tester写入汽车ECU的0x08000000位置，大小为0x2000的代码数据内容上。 1、代码数据内容提取 [pre]我们通过编辑器正则替换，删除与下载数据【36 xx】无关的通讯帧，得到附件中的0x08000000_0x2000.binstr
其中每19行发送完一个大小为0x80的有效数据块[/pre]
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
[pre]通过下述python代码，我们将0x08000000_0x2000.binstr提取出刷写的内容0x08000000_0x2000.bin（参考附件）
with open(r'.0x08000000_0x2000.binstr','rb') as fin:
fs = fin.read()
lns = fs.split('\n')
import re
fp = re.compile(r'(?sm)730 Tx d 8 10 82 36 (.. .. .. .. ..)')
dp = re.compile(r'(?sm)730 Tx d 8 2. (.. .. .. .. .. .. ..)')
hexstr = ''
for i in range(64):
sl = i*19
ff = [fp.match(lns[sl]).groups()[0][3:]]
for j in range(1,18):
ff.append(dp.match(lns[sl+j]).groups()[0])
ff.append(dp.match(lns[sl+18]).groups()[0][:-6])
hexstr+=' '.join(ff).replace(' ','').decode('hex')
with open(r'.\0x08000000_0x2000.bin','wb') as fout:
fout.write(hexstr)[/pre]2、反编译
我们用IDA将0x08000000_0x2000.bin加载到0x08000000位置，使用小端ARM，通过快捷键【Alt+g】设置【T】值为1选择Thumb后，再对0x08000000处快捷键C反编译。如图 （2.1）起始函数Hi_start_8000000
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
(2.2) 由start函数到Hi_to_main_8001268函数
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
（2.3）由to_main函数进入主函数 Hi_main_8000138
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
（2.4）主函数main中获取flag的函数Hi_fetch_decrypt_flag_8000168 （A）获取flag的业务逻辑比较简单，对"flag{canoecr7-zd9h-1emi-or8m-f8vm2od81nfk}"简单运算
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
（B）fetch_flag函数伪码
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
（C）我们也可以通过unicorn简单模拟执行得到解密的flag [pre]from unicorn import *
from unicorn.arm_const import *
import sark
import idc
segs = list(sark.segments())
elf_base = segs[0].ea
elf_size = segs[-1].ea+segs[-1].size
elf_size = 0x1000*((elf_size+0x0FFF)/0x1000)
stack_size = 4*1024*1024
mem_size = 4*1024*1024
mem_ptr = elf_base + elf_size + stack_size
all_size = elf_size + stack_size + mem_size
stack_init = elf_base + elf_size + stack_size/2
mu = Uc(UC_ARCH_ARM, UC_MODE_ARM)
mu.mem_map(elf_base, all_size)
print("Init Module: base:= {:06X} size:= {:04X}".format(elf_base,all_size))
for seg in segs:
segdata = idc.get_bytes(seg.ea,seg.size)
mu.mem_write(seg.ea, segdata)
print("Init Seg: base:= {:06X} size:= {:04X}".format(seg.ea,seg.size))
mu.reg_write(UC_ARM_REG_SP,stack_init)
mu.reg_write(UC_ARM_REG_R4, 0x80002C8)
mu.emu_start(0x08000180+1, 0x800028C)
mu.mem_read(0x080002C8,0x2c)[/pre]
wdb网鼎杯_2020_misc_ 青龙组Teslaaaaa-100
即【flag{3dad13db-cb48-495d-b023-3231d80f1713}】为我们鲜红的旗帜。 | 
发表于 2020-5-16 22:16:23
|
查看: 3182|
回复: 0
窥视卡
雷达卡
提升卡
置顶卡
关闭卡
开启卡
变色卡
千斤顶
照妖镜