365天获取玄武实验室的工作

这是什么?

这是一份我给自己365天内获取腾讯玄武实验室工作定下的学习进度清单, 用于记录我在这一年时间里每天的学习收获.

因为知识积累的差异, 该清单并不适用于纯粹的新手, 但我常认为自己是一个愚笨的人, 所以即便是刚入行的小白, 在补足了一定的基础知识后, 该清单依然具有一定的参考价值.

学习进度

Day1: 学习CTF Wiki栈溢出基础和ROP基础

传送门: CTF Wiki: Linux Pwn

Stack Overflow Principle: 通过栈溢出覆盖掉函数栈帧的返回地址, 当函数返回时就会跳入攻击者覆写的地址继续执行代码.
1. 确认溢出的长度可以到达栈帧返回地址
2. 确认没有开启Stack Canary
3. 确认覆写的地址所在的段具有执行权限
- 编译选项-fno-stack-protector用于关闭Stack Canary
- 编译时需要加-no-pie确保不会生成位置无关文件
- 关闭ASLR: echo 0 > /proc/sys/kernel/randomize_va_space
Basic ROP: 在栈溢出的基础上, 通过利用文件本身的gadget来控制寄存器和变量来控制程序流程.
- ret2text: 跳转到程序已有的高危代码处(system("/bin/sh")), 直接触发高危操作.
- ret2shellcode: 栈溢出的同时布置shellcode(可以理解为预写好的高危功能性汇编代码), 在溢出时跳转到布置好的shellcode处继续执行.
  1. 因为有执行, 所以需要确保shellcode所在位置有可执行权限.
  2. gef的vmmap可以查看内存段的权限.
  3. pwntool获取shellcode: asm(shellcraft.sh())
- ret2syscall: 没有执行权限时, 可以通过系统调用来实现控制.
  1. 开启NX保护后, 再如何部署高危代码都没法执行. 所以需要转向利用内核的系统调用实现高危操作.
  2. 可以通过/usr/include/asm/unistd_32.h查看当前内核对应的系统调用号. 比如#define __NR_execve 11, 也就是execve的系统调用号为0xb
  3. 使用ROPgadget可用获取寄存器和字符串的gadget.
    - ROPgadget --binary rop --only 'pop|ret' | grep 'ebx' | grep 'ecx'
    - ROPgadget --binary rop --string '/bin/sh'
    - ROPgadget --binary rop --only 'int'
  4. 使用flat来直观地表示ROP链: flat(['A' * 112, pop_eax_ret, 0xb, pop_edx_ecx_ebx_ret, 0, 0, binsh, int_0x80])
    - 形式为: 溢出用的填充数据, gadget1(函数原本的返回地址), value1, gadget2, value2, ... , int 0x80
- ret2libc:
  - ret2libc1: 跳转到libc的高危代码(system)并模拟函数调用
    1. 注意跳转到libc的函数去执行, 需要模拟函数调用, 因此跟gadget在栈上的部署方式不一样, 正确的形式为PLT地址, 函数返回地址, 函数参数地址...
    2. 获取system()的plt地址方法: objdump -d ret2libc1 | grep system, 也就是地址是写在汇编里的.
  - ret2libc2: 如果缺少函数调用的条件(缺少函数参数字符串/bin/sh)
    1. 利用libc里的gets函数, 并手动输入相应的函数参数字符串即可弥补.
    2. ['a' * 112, gets_plt, pop_ebx, buf2, system_plt, 0xdeadbeef, buf2]需要注意的是pop_ebx作为gets的返回地址, 它还将buf2给弹出栈, 使得程序继续向下执行system函数部分.
  - ret2libc3: 既没有函数参数字符串(/bin/sh)也没有高危libc函数地址(system)
    1. libc之间函数偏移是固定的, 因此可以通过某个已知的libc函数偏移, 来获取任意其他libc函数地址.
    2. libc有延迟绑定机制, 只有执行过的函数它的GOT才是正确的.
    3. libc内自带有/bin/sh字符串.
    4. 可以利用__libc_start_main地址来泄露偏移.
    5. 利用思路就是 => 构造ROP链通过puts泄露__libc_start_main的got地址 => 使用LibcSearcher获取libc的基址从而获取system地址和/bin/sh地址 => 重载程序 => 构造payload控制.

Day2: 学习CTF Wiki中级ROP和格式化字符串漏洞

传送门: CTF Wiki: Linux Pwn

Intermediate ROP:
- ret2csu:
  - x64寄存器传参的顺序为rdi, rsi, rdx, rcx, r8, r9, 超出数量的参数根据函数调用约定压入栈中(比如从右向左压栈)
  - __libc_csu_init是__libc_start_main调用的用于初始化的函数. 参考: Linux X86 程序启动–main函数是如何被执行的？
  - 示例的level5应是ctf-challenges里的hitcon-level5, 而非蒸米提供的level5
  - 使用ROPgadget搜索可用的gadget是可以发现, 程序并没有直接的控制传参用的寄存器, 大多都是控制r12-r15, 这也就是分析__libc_csu_init的关键: 我们需要其中的mov语句, 通过r13-r15控制x64传参用的前三个寄存器.
  - 分析__libc_csu_init的目的是掌握可控制的寄存器, 也就是能控制rbx, rbp, r12, r13=>rdx, r14=>rsi, r15=>edi, 同时可控的r12和rbx以及call qword ptr [r12+rbx*8]能控制调用的函数地址(r12为函数地址, rbx直接为0). add rbx, 1; cmp rbx, rbp; jnz 400600则是约束条件rbx+1==rbp, 故而rbx=0则rbp=1. 这样来看这是一段非常优雅的gadget.
  - write (fd, &buf, count)中, linux下fd=0/1/2分别对应stdin/stdout/stderr.
  1. libc延迟绑定机制, 因此需要等待write输出Hello, World后泄露函数地址.
  2. 泄露函数地址后获取libc基址, 然后获取execve地址
  3. 利用csu执行read()向bss段写入execve地址和参数/bin/sh
  4. 利用csu执行execve(/bin/sh)
  Q1: 为什么要先read()写execve地址, 而不是直接调用execve函数呢?
  因为call qword ptr [r12+rbx*8]指令, 实际上我们通过csu控制的是一个地址, 而该地址指向的内容才是真正函数的调用地址. 而read()写到bss段的是execve的地址, 但csu调用的时候提供的是bss段的地址, 这样才能完成函数调用. 如果直接传execve地址, 那么是无法调用成功的.
  
  Q2: 为什么可以用写入的/bin/sh地址能成功, 而直接用libc内的/bin/sh地址就不能成功呢?
  我一个可能性比较高的推测是, 回顾我们的gadget, 对于x64传参的第一个寄存器rdi, 其实我们的gadget只能控制寄存器rdi的低32位(edi). 而对于bss段地址来说, 它实际上是一个32位的地址(高32位为0), 而libc内的/bin/sh是一个64位的地址(高32位不为0), 所以没有办法传递完整的地址进去. 所以只能通过bss上写入的/bin/sh地址进行传参.
  csu函数实现
```
def csu(func_addr, arg3, arg2, arg1, ret_addr):
   rbx = 0
   rbp = 1
   r12 = func_addr
   r13 = arg3
   r14 = arg2
   r15 = arg1

   # pop rbx rbp r12 r13 r14 r15 retn
   csu_pop_gadget = 0x000000000040061A

   # r13=>rdx r14=>rsi r15=>edi 
   # call func
   # rbx+1 == rbp
   # add rsp, 8
   # csu_pop_gadget
   csu_mov_gadget = 0x0000000000400600

   # pop 6 registers and `add rsp, 8`
   stack_balance = b'\x90' * 0x8 * (6+1)

   payload = flat([
       b'\x90'*0x80, b'fake_rbp', p64(csu_pop_gadget),
       p64(rbx), p64(rbp), p64(r12), p64(r13), p64(r14), p64(r15),
       p64(csu_mov_gadget), stack_balance, p64(ret_addr)
   ])

   io.send(payload)
   sleep(1)
```
- BROP: 盲打的方式通过程序是否崩溃来推测信息. 适用于Nginx, MySQL, Apache, OpenSSH等服务器应用, 因此该攻击还有着一定的实际应用价值.
  
  理论知识主要参考 Blind Return Oriented Programming (BROP) Attack-攻击原理, 示例程序参考 HCTF2016-出题人失踪了(brop)
  - 实现攻击必需的2个条件:
    1. 存在栈溢出漏洞, 且攻击者可以通过输入轻松触发. (没有程序没有源码没有信息, 打也打不崩, 那还玩什么)
    2. 程序崩溃后会重新运行, 并且重新运行的进程地址不会再次随机化. (能稳定复现, 获取稳定地址, 包括Stack Canary也不能随机化)
  - 描述了4种gadget:
    1. stop gadget: 程序跳转到该gadget片段后, 程序并没有崩溃, 而是进入某种hang/loop状态, 能与攻击者保持连接.
    2. (potentially) useful gadget: 找到stop gadget后, 通过一定的内存布局而发现的更多的不会崩溃的gadget. (当然包括新发现的stop gadget)
    3. brop gadget: 一种特殊的useful gadget, 能帮助我们控制x64传参用的寄存器. 典型示例就是__libc_csu_init()尾部的rop链. gadget能通过指令错位(+7/+9)的方式得到单独控制rsi和rdi寄存器的新gadget.
    4. trap gadget: 就是会让程序崩溃的gadget.
  - 攻击思路:
    1. 通过爆破, 获取程序崩溃时的字符串填充长度.
    2. 通过单字节枚举, 逐字节地泄露出栈上保存的Canary. (当然也可以枚举出栈上保存的寄存器和原本的返回地址.)
    3. 寻找stop gadget: 早期能得到的信息只有程序崩溃和不崩溃, 所以我们需要获得第一个程序不会崩溃的stop gadget.
    4. 寻找useful gadget: 通过合理的布局栈上的内存, 我们可以利用stop gadget来发掘更多的useful gadget, 并且是能确认该useful gadget弹栈数量的.
      - 比如栈上的布局情况为: ...| buffer | gadget | trap x N | stop | trap|... 则表明该gadget有N个pop指令(N=0,1,...).
    5. 从useful gadget里筛选出真正有帮助的brop gadget. 这里就以__libc_csu_init()的尾部gadget为例, 该gadget能弹栈6次, 通常认为符合这种性质的gadget很少, 所以有一定把握去判断, 并且该gadget可以通过错位得到单独控制rsi和rdi的gadget, 也可以通过减去0x1a来获取其上的另一个gadget.
    6. 寻找PLT项. PLT在盲打时有这样的特征: 每一项都有3条指令共16个字节长. 偏移0字节处指向fast path, 偏移6字节处指向slow path. 如果盲打时发现有连续的16字节对齐的地址都不会造成程序崩溃, 这些地址加6后也不会崩溃. 那么就推断为PLT地址.
    7. 确定PLT项内的strcmp和write(也可以是put):
      - 确定strcmp的目的在于: 目前只能通过brop gadget控制传参用的前2个寄存器(rdi和rsi), 第3个寄存器rdx尚且没法用gadget控制. 因此转变思路通过strcmp和控制字符串长度来给rdx赋值, 变相控制第三个传参用的寄存器.
      - 确定write的目的在于: 需要通过write将内存代码都写回给攻击者. 通常是将fd设置为连接的socket描述符. 而write需要3个参数, 这也是为什么借用strcmp控制rdx的原因.
      - 确定strcmp的方法在于控制函数的两个地址: readable和bad(0x00)地址. 这样就有4种参数形式, 并且只有两个参数地址都是readable时函数才会正确执行, 其他情况都没有正确执行, 那么就推断这个plt项对应的是strcmp.
      - 确定write的方法在于确定写入的fd, 就只能尽量枚举文件描述符来测试了. 建议用较大的文件描述符数字.
      - 如果是寻找puts的话, 就比较容易确定. 因为我们只需要控制输出0x400000地址的内容, 该地址通常为ELF文件的头部, 内容为\x7fELF. 构造的payload形式为buffer |pop_rdi_ret | 0x400000 | puts_addr | stop.
    8. 有能力控制输出函数后, 攻击者可以输出更多的.text段代码. 也可以去寻找一些其他函数, 比如dup2或execve等:
      - 将socket输出重定向到stdin/stdout.
      - 寻找/bin/sh, 或者利用write写入到某块内存.
      - 执行execve或构造系统调用.
      - 泄露puts在内存的实际地址, 然后确认libc基址, 获取system地址并构造rop链.
Format String Vulnerability:
- 格式化字符串漏洞的本质在于信任了用户的输入, 攻击者通过输入构造好的格式化字符串来泄露栈上的内存数据.
  - %x或%p用于泄露栈内存数据.
  - %s用于泄露变量对应地址的内容, 存在\x00截断.
  - %n$x用于泄露输出函数的第n+1个参数. 这里的n是相对于格式化字符串而言的.
- 可以通过func@plt%N$s将内存中的func实际地址泄露出来. N表示其在栈上相对格式化字符串而言是第N个参数.
- 确定了偏移后, 使用...[overwrite addr]....%[overwrite offset]$n. %n写入的值可通过增加输出的字符数量进行调整.
- 覆写的地址没有位置的要求, 只需要找到对应偏移即可.
- 利用%hhn进行单字节写入, %hn进行双字节写入.

Day3: 回顾软件安全保护技术和学习ARM汇编基础

Day4: 学习ARM汇编基础和CTF Wiki的花式ROP

传送门: azeria-labs / ROP Tricks

ARM Assembly

ARM Instruction Set
- ARM模式亦或是Thumb模式跟所处的特权等级无关.
- 开发ARM Shellcode时需要尽量避免NULL空字节出现, 因此常用Thumb指令
- ARM版本之间会有略微差别, 需要根据对应版本查询官方文档
- Thumb有三个版本:
  1. Thumb-1: 16比特长, 用于ARMv6及早期版本
  2. Thumb-2: 16/32比特长, 扩展了Thumb-1, 支持更多的指令. 适用于ARMv6T2和ARMv7.
  3. ThumbEE: 包括一些对动态生成代码的变化.
- ARM和Thumb指令的区别:
  1. 条件执行: ARM所有指令都可以条件执行, Thumb只能通过IT指令允许部分指令有条件地执行.
  2. 32位表示: 32位的Thumb指令会多一个.w的后缀
  3. 桶式移位器(ARM独有特性): 能用于精简指令.
- 要切换处理器执行状态, 需要满足以下两者条件其一:
  1. 使用分支指令BX或BLX并将目标寄存器的最低有效位设置为1(通过+1实现)
  2. 状态寄存器置位T
- ARM汇编指令格式MNEMONIC{S}{condition} {Rd}, Operand1, Operand2. 注意Operand2的使用稍有灵活, 并且有些指令中Operand1是隐含的.
Memory Instructions: Loading and Storing Data
- [pc, #12]表示pc相对寻址. 不过要注意, ARM里的pc指的是当前指令的下2条指令位置, 也就是ARM模式下+8, Thumb模式下+4
- 地址模式: offset / pre-indexed / post-indexed
  - 以立即数作为偏移的情况:
    - str r2, [r1, #2]: 地址模式: offset. 直接将r2寄存器中的值存到r1+2所表示的地址处. r1没有变化
    - str r2, [r1, #4]!: 地址模式: pre-indexed(!是一个标识的特征). 类似offset寻址模式, 寻址r1+4, 寻址存储完执行r1=r1+4
    - ldr r3, [r1], #4: 地址模式: post-indexed. 寻址r1, 寻址完执行r1=r1+4
  - 以寄存器作为偏移的情况: 类似立即数作偏移的情况, 很好理解.
  - 以移位寄存器作为偏移的情况: 类似立即数作偏移的情况, 不过移位的优先级是最高的, 比如str r2, [r1, r2, LSL#2]就是将r2内的值保存到r1+r2<<2的地址处.
- ARM使用立即数: ARM使用立即数的方式很不灵活, 格式为v = n ror 2*r 其中n in [0-255], r in [0-30]. 对于不能合规的立即数, 考虑拆分成两个更小的数加起来, 或者使用LDR指令比如LDR r1, =511
Load and Store Multiple
- 多次加载/存储可以使用LDM和STM指令
- LDM和LDR的方向是相反的, 同样STM和STR方向也相反
- 扩展-IA (increase after), -IB (increase before), -DA (decrease after), -DB (decrease before)
- PUSH和POP和x86汇编基本一致.
- PUSH等价于STMDB sp! reglist
- POP等价于LDMIA sp! reglist

Conditional Execution and Branching

分支条件在标志寄存器中会相应地置位, 这点跟x86一致, 区别主要在标志寄存器各个位的含义略有不同. ARM的分支通过在指令后加相应的条件码来实现.

Condition Code	Meaning (for cmp or subs)	Status of Flags
CS or HS	Unsigned Higher or Same (or Carry Set)	C==1
CC or LO	Unsigned Lower (or Carry Clear)	C==0
MI	Negative (or Minus)	N==1
PL	Positive (or Plus)	N==0
AL	Always executed	-
NV	Never executed	-
VS	Signed Overflow	V==1
VC	No signed Overflow	V==0
HI	Unsigned Higher	(C==1) && (Z==0)
LS	Unsigned Lower or same	(C==0)

IT是IF-Then-(Else)的缩写.
IT指令格式: IT{x{y{z}}} cond, 也就是最多可以有条件地执行4条指令
- cond指定IT块中第1条指令的条件
- x指定第2条指令的条件, y指定第3条, z指定第4条
IT块里T的条件要跟I保持一致, E的条件要跟I和T相反. (这也很好理解, 就是ARM划分分支的一种形式)
条件码的反义就不硬背了, 直接看ITE就可以判断IT块里的情况.
branch指令跟x86的类似, 只是助记符不一致, 理解还是很好理解的.
- B: 单纯跳转分支
- BL: 将PC+4保存到LR然后跳转分支
- BX/BLX: 相比多了一个Exchange, 也就是切换指令集(ARM <-> Thumb)
- BX/BLX通常会使用类似add r2, pc, #1; bx r2的方法先取pc然后+1的方法使最低有效位置为1(0转ARM，1转Thumb), 然后用BX/BLX切换指令集. (这里不用担心内存块对齐4的问题, CPU会自动屏蔽没有对齐的那个bit1/0).

Stack and Functions
- 栈的部分不必多说
- 函数部分熟悉Prologue, Body和Epilogue
  - prologue: push {r11, lr}; add r11, sp, #0; sub sp, sp, #16
  - body: mov r0, #1; mov r1, #2; bl max
  - epilogue: sub sp, r11, #0; pop {r11, pc}

ROP Tricks
- stack pivoting
  - 直接劫持栈指针指向攻击者的内存, 可以以较少的指令达成攻击, 对于开启PIE保护的程序也可以适用.
  - 利用的gadget为pop rsp/esp, 也可以通过libc_csu_init的gadget经过错位获得.
  - 有办法控制到esp后, 还需要想办法将esp的值指向写入的shellcode部分. 可以加\x90垫.
- Stack smash
  - Canary检查到溢出后, 程序会执行__stack_chk_fail函数打印argv[0]指针. 而攻击思路就是借栈溢出覆盖argv[0]实现信息泄露.
  - 攻击需要确定溢出到argv[0]所需要的字节数, 以及需要溢出的地址.

Day5: 学习CTF Wiki整数溢出和堆管理机制

在此前需要了解glibc的堆内存管理器的机制. 主要参考 glibc内存管理ptmalloc源代码分析. Seebug有一个堆资料的归档也可以省下找资料的功夫.

Day6: ptmalloc2内存管理机制(分配和释放)

Day7: 软件破解技术

Day8: Linux内核及其内在机理

传送门: linux-insides

从引导加载内核:
1. 按下电源开关主板供电备妥后, CPU会复位寄存器的所有数据, 并设置每个寄存器的预定值. CPU复位后, 寄存器的预设数据如下: IP=0xfff0, CS=0xffff. 实模式下内存寻址时通过段寄存器偏移(实模式CPU只能用16位寄存器)得到, 也即CS:IP=(0xffff)<<4+0xfff0=0xfffffff0. 而实模式下CPU是无法访问0xfffffff0这个地址的, 所以0xfffffff0被映射到了ROM而非RAM.
2. 0xfffffff0是4GB-16B, 也就是复位向量所在位置, 也就是CPU在重置后期望执行的内存地址入口. 通常为一个jump指令, 用于跳往BIOS入口
3. BIOS在初始化和检查硬件后, 需要找到一个可引导设备. BIOS会根据BIOS配置里的可引导设备列表顺序, 依次尝试寻找引导程序, 对硬盘而言就会去MBR分区, 该分区存储在磁盘第一个扇区(512字节)的头446字节, 引导扇区的最后必须为0x55和0xaa(这是引导程序的magic标识).
4. MBR分区代码只能占用一个扇区, 因此非常简单, 只做了一些初始化, 然后就跳转到GRUB2的core image去继续执行. core image的初始化代码会把整个core image(包括GRUB2的内核代码和文件系统驱动)引导到内存中. 引导完成后, 调用grub_main
5. grub_main初始化控制台, 计算模块基地址, 设置root设备, 读取grub配置文件, 加载模块. 最后将grub置于normal模式, 调用grub_nomal_execute完成最后的准备工作, 然后显示菜单列出所有可用的操作系统.
6. 选择操作系统之后, 执行grub_menu_execute_entry, 它会调用grub的boot命令, 来引导选择的系统.
7. 引导会根据kernel boot protocol的描述, 填充kernel setup header里的字段, 将内核引导入内存后, 交由Kernel继续执行. Kernel的代码从0x1000 + X + sizeof(KernelBootSector) + 1开始执行(X是kernel bootsector被载入内存的基址)
内核引导和设置
1. 首先需要正确设置内核, 内核设置代码的运行起点为arch/x86/boot/header.S的_start函数. 在_start之前还有一些kernel自带的bootloader代码, 主要是兼容UEFI.
2. _start第一句就是jmp语句, 跳转到其后的相对地址(start_of_setup-1f), 也就是_start后第一个标号为1的代码, 该部分包含了剩下的setup header结构. 而1之后就是start_of_setup的代码, 该部分开始会完成段寄存器设置, 堆栈设置, bss段设置, 跳转到main.c开始执行代码的工作
3. 段寄存器设置: 将ds和es寄存器的内容设置为一样, 通过利用lretw将ds寄存器的值放入cs寄存器
4. 堆栈设置: 检查ss寄存器的内容, 如果内容不对则进行更正
5. 设置BSS段: 检查magic签名setup_sig, 如果签名不对直接跳转到setup_bad执行相应代码. 如果签名正确, 就设置好BSS段将其全部清零.
6. 跳转到main函数: calll main. main()定义在arch/x86/boot/main.c
保护模式
- 保护模式相比实模式, 有32位地址线能访问4GB的地址空间并且引入了内存分页的功能.
- 保护模式提供了2中完全不同的内存管理机制: 段式内存管理和内存分页.
- 实模式下物理地址由内存段的基地址和基地址开始的偏移组成, 也即segement << 4 + offset. 但在保护模式下, 每个内存段不再是64K大小, 段的大小和起始位置通过段描述符描述, 所有内存段的段描述符存储在全局描述符表(GDT)结构里.
- 全局描述符表(GDT)在内存位置并不固定, 它的地址保存在特殊寄存器GDTR里. 使用指令lgdt gdt将GDT的基地址和大小保存到GDTR寄存器中. GDTR是一个48位寄存器, 该寄存器保存2部分内容: GDT的大小16位和GDT的基址32位.
- 而保护模式下, 段寄存器保存的不再是内存段的基地址而是称为段选择子的结构. 段选择子对应了相应的段描述符. 段选择子是一个16位的数据结构, 包含了对应段描述符的索引号, 选择是在GDT还是LDT查找段描述符, 和请求优先级.
- 保护模式下, CPU通过以下步骤找到寻址:
  1. 将相应段选择子载入段寄存器
  2. 根据段选择子从GDT中找到匹配的段描述符, 然后将段描述符放入段寄存器的隐藏部分.
  3. 在没有向下扩展段的时候, 内存段的基地址, 就是段描述符中的基地址.
- 代码从实模式切换到保护模式的步骤:
  1. 禁止中断发生
  2. lgdt gdt
  3. 设置CR0寄存器的PE位为1, 使CPU进入保护模式
  4. 跳转执行保护模式代码.
main函数操作:
1. 将启动参数拷贝到zeropage: 调用copy_boot_params(void), 该函数将内核设置信息拷贝到boot_params结构的相应字段.
2. 控制台初始化: 调用console_init.
  1. 该函数先查看命令行参数是否包含earlyprintk选项.
  2. 如果包含, 函数将分析这个选项的内容, 得到控制台将使用的串口信息并进行串口初始化.
  3. 串口初始化成功后, 如果命令行参数带有debug选项, 可以看到一行输出early console in setup code
3. 堆初始化: 内核需要初始化全局堆, 通过init_heap实现
  1. 首先检查内核设置头的loadflags是否设置CAN_USE_HEAP标志. 如果设置了该标志, 代码会计算栈的结束地址和堆的结束地址
  2. 栈的结束地址计算: stack_end = esp - STACK_SIZE
  3. 堆的结束地址: heap_end = head_end_ptr + 0x200
  4. 判断heap_end是否大于stack_end. 如果大于, 那么就把stack_end设置为heap_end(栈和堆的生长方向相反, 这里设置让堆和栈相邻, 增大了栈的底部空间, 不影响栈逆向生长)
  5. 这样就完成了全局堆的初始化, 全局堆初始化之后, 就可以使用GET_HEAP方法了.
4. 检查CPU类型: 调用validate_cpu检查CPU是否可用. validate_cpu会调用check_cpu得到当前系统的cpu_level并和系统要求的最低cpu_level比较, 如果不满足就不允许系统运行.
5. 内存分布侦测: 调用detect_memory进行内存侦测, 得到系统当前内存的使用分布. 以下是detect_memory_e820(该方法的多种接口之一, 用于获取全部内存分配)原理:
  1. 调用initregs方法初始化biosregs数据结构, 然后向该数据结构填入e820接口所要求的参数.
  2. 通过循环收集内存信息. 循环结束后整个内存分配信息被写入到e820entry数组, 数组元素包含三个信息: 内存段起始地址, 内存段大小, 内存段类型. 可以使用dmesg查看到这个数组的内容
6. 键盘初始化: 调用keyboard_init()方法进行键盘初始化. 首先调用initregs初始化寄存器结构, 然后调用0x16中断获取键盘状态, 获取状态后再次调用0x16中断来设置键盘的按键检测频率.
7. 系统参数查询: 内核进行一系列的参数查询, 依次是:
  1. query_mac调用0x15中断来获取机器的型号, bios版本和其他硬件相关信息.
  2. query_ist获取Intel SpeedStep信息, 首先检查CPU类型, 然后用0x15中断获取该信息并填入boot_params中
  3. query_apm_bios从BIOS获取电源管理信息.
  4. query_edd从BIOS查询硬盘信息.

Day9: Android安全里的攻防和分析知识

Android安全部分参考《Android安全攻防实战》

APK结构:
- 证书签名
  - 证书文件在APK解压后的META-INF文件夹内.
    - CERT.RSA是公钥证书的自签名.
      - 使用keytool进行检查: keytool -printcert -file CERT.RSA, 其中有声明公钥的持有者.
      - 使用openssl进行检查: openssl pcks7– inform DER –in META- INF/ CERT. RSA –noout –print_ certs –text 它指定了以下5个信息
      - Owner: 公钥持有者, 包含与该个体相关的国家组织信息
      - Issuer: 声明该证书的颁发机构.
      - Serial number: 证书的标识符
      - Valid from...until: 指定证书有效期, 其关联属性可以由颁发者验证
      - Certificate fingerprints: 记录证书的数字校验和, 用来验证证书是否经过村阿盖
    - CERT.SF包含了APK中各个资源文件的SHA-1哈希. 使用jarsigner验证apk内容时就会比对该文件.
    - MANIFEST.MF: 声明资源文件
  - 如何对App签名?
    1. 创建keystore, 用于存放签名app所使用的私钥: keytool –genkey –v -keystore [keystore名称] –alias [私钥别名] –keyalg RSA –keysize 2048 –validity [有效天数]
    2. 使用keystore通过jarsigner对app签名: jarsigner –verbose –sigalg MD5withRSA –digestalg SHA1 –keystore [keystore文件] [你的.apk文件] [私钥别名]
  - 如何验证app签名? jarsigner –verify –verbose [apk文件]
- AndroidManifest.xml: 声明app的权限和组件信息
  - 如何提取AndroidManifest.xml? apktool d -f -s [apk文件] [解压目录]
- adb命令:
  - adb logcat: 显示调试日志
  - adb shell pm list packages: 列出设备中所有package
  - am start [Activity名]: 启动指定activity.
    - 对于intent可以使用-e key value传递字符串键值
    - 对于service可以使用am startservice启动
APP中的漏洞:
- logcat信息泄露: logcat里泄露了一些网址信息(http(s))或者cookie信息
- 检查网络流量:
  1. 在设备上使用tcpdump和nc捕获流量: tcpdump -w - | nc -l -p 31337
  2. 使用adb命令将设备的流量转发到本地端口: adb forward tcp:12345 tcp:31337
  3. 本地nc连接转发端口: nc 127.0.0.1 12345
  4. wireshark连接管道获取流量: nc 127.0.0.1 12345 | wireshark -k -S -i -
- 通过am被动嗅探intent: TODO 需要使用drozer
- 攻击service:
  1. 搜索哪些service是exported
  2. 尝试运行这些service. 运行的同时使用logcat来查看它是否会在运行时泄露一些敏感信息
  3. 如果想通过intent向service发送数据, 你需要去了解它的intent filter.
  4. 某些service可能作为原生库的接口, 将intent接受的数据转换成类似基于堆/栈的数据结构, 这可能会造成内存溢出漏洞
- 攻击broadcast receiver:
  - 发掘receiver的漏洞需要确定输入是否可信以及该输入的破坏性如何.
  - 需要阅读源码, 弄清楚receiver的intent filter
保护APP:
- 保护APP组件: 正确使用AndroidManifest.xml以及在代码级别上强制进行权限检查
  - 尽量减少android:exported属性的使用, 尽可能地减少暴露的组件
  - android 4.2之前, 或者sdk版本17以下, 定义的intent-filter元素默认是导出的.
- 定制权限: 指定组件的android:permission和定义permission-group
- 保护provider组件:
  - 设置权限android:permission
  - 设置读相关权限(query): android:writePermission
  - 设置写相关权限: android:readPermission
  - 使用path-permission元素为单独的路径(比如/[path])设置不同的权限, path的权限设置优先级更高
- 防御SQL注入: 确保攻击者不能注入恶意构造的SQL语句
  - 避免使用SQLiteDatabase.rawQuery(), 而是改用一个参数化的语句(参数化的意思就是指定一个语句的格式, 并非指定参数, 而是描述性的表达语句, 可以类比为格式化字符串, 比如insert into TABLE_NAME (content, link, title) values (?,?,?)).
  - 使用一个预先编译好的语句, 比如SQLiteStatement, 提供对参数的绑定(binding)和转义(escaping).
  - 使用SQLiteDatabase提供的query, insert, update和delete方法.
- 验证app的签名: 根据事先计算好的签名哈希, 在代码运行时进行比对来判断文件是否被篡改
- 反逆向工程方式:
  - 检测安装程序: 比如检查安装程序是否为谷歌商店
  - 检查是否出于模拟器中: 获取相应的系统特征字符串进行判断
  - 检查app的调试标志是否启用: 启用调试标志意味着app可能连上了adb进行调试
  - 利用JAVA的反射API能在运行时检查类, 方法及成员变量, 这使得能够绕过访问控制修饰符(access modifier)的限制, 调用正常情况下无法使用的东西.
- 使用ProGuard: ProGuard是Android SDK自带的开源java代码混淆器.
  - ProGuard会把程序执行时不需要的信息都删除掉, 比如代码中不使用的方法, 域, 属性和调试信息
  - 它会把一些代码优化成更短更难以阅读的混淆代码
- 使用DexGuard进行高级代码混淆
  - 相比ProGuard不仅能混淆Java代码, 还能保护资源文件和Dalvik字节码
  - API隐藏: 使用API反射机制隐藏对敏感API和代码的调用
  - 字符串加密: 对源代码的字符串进行加密
  - 反射调用会把类名和方法名包存为字符串, 而字符串加密可以结合起来将这些反射字符串加密起来.
逆向app
- java源码编译成dex:
  1. javac -source 1.6 -target 1.6 example.java
  2. dx --dex --output=example.dex example.class
- dex文件格式: 可以使用dexdump example.dex进行解析
  - magic(8bytes): dex\n035
  - checksum(4B): 表示dex文件的Adler32校验和, 用于验证dex文件头是否被篡改.
  - SHA签名(20B)
  - fileSize(4B): 表示整个dex文件的长度
  - headerSize(4B): 表示整个DexHeader结构的长度, 单位为byte
  - endianTag(4B): 存放的是固定值, 在所有dex文件中都意义. 为0x12345678, 根据这个值在内存的排列顺序来判断是大端序还是小端序.
  - linkSize和linkOff: 多个.class被编译到一个dex时会哟感到
  - mapOff
  - stringIdsSize: 存放StringIds区段大小.
  - stringIdsOff: 存放stringIds区段的实际偏移, 帮助Dalvik编译器和虚拟机直接跳转到该区段而不用计算偏移.
  - StringIds区段实际上保存的是各个字符串的地址
  - TypeIds区段则是存放了各个类型描述符在stringIds列表的索引号.
  - ProtoIds区段存放一系列用来描述方法的prototype id, 其中含有关于各个方法的返回类型和参数信息
  - FieldIds区段由一些stringIds和typeIds区段中数据的索引号组成, 用于描述类中各个成员
  - MethodIds区段用于描述方法, ClassDefs区段用于描述类
  - 除开用dexdump对dex解析, 还可以使用dx, 不过你得有相应的class文件: dx -dex -verbose-dump -dump-to=[output].txt [input].class
- 反汇编/反编译/gdb调试操作:
  - 将dex反汇编得到smali代码: baksmali example.dex
  - 将dex反编译得到.class文件: dex2jar example.dex
  - 将.class反编译得到java代码: 使用jd-gui
  - 反汇编native so文件: 使用android ndk的toolchain提供的arm版本objdump. arm-linux-androideabi-objdump -D [native library].so
  - gdb调试正在运行的android进程:
    - mount会输出每个块设备都是怎么mount的一些信息
    1. mount -o rw,remount [device] /system
    2. adb push [NDK-path]/prebuilt/android-arm/gdbserver/gdbserver /system/bin
    3. 使用ps确定要调试的进程PID, 使用gdbserver进行attach: gdbserver :[tcp-port] --attach [PID]
    4. 转发android设备的TCP端口: adb forward tcp:[remote_port] tcp:[local_port]
    5. 本地运行交叉编译好的arm-linux-androideabi-gdb然后输入target remote :[local_port]来连接端口
SSL安全: 验证SSL签名证书: 利用OpenSSL
1. 对于网络上的自签名证书, 使用openssl s_client -showcerts -connect server.domain:443 < /dev/null显示该证书的详细信息, BEGIN CERTIFICATE到END CERTIFICATE部分为证书内容, 将其保存为mycert.crt
- 使用openssl创建自签名证书: openssl genrsa -out my_private_key.pem 2048生成.pem的私钥文件, 然后用该私钥生成证书: openssl req -new -x509 -key my_private_key.pem -out mycert.crt -days 365
1. 得到mycert.crt后, 我们要将证书打包到app中, 就需要创建证书并将其导入到.keystore文件中, 该文件会被视为truststore.
2. 使用Bouncy Castle库创建并导入证书到truststore:
3. 设置CLASSPATH环境变量: $ export CLASSPATH=libs/bcprov-jdk15on-149.jar
4. 使用keytool创建并导入公钥证书
```
$ keytool -import -v -trustcacerts -alias 0 / 
  -file < ( openssl x509 -in mycert.crt) / 
  -keystore customtruststore.bks / 
  -storetype BKS / 
  -providerclassorg.bouncycastle.jce.provider.BouncyCastleProvider /
  -providerpath libs/bcprov-jdk15on-149.jar \
  -storepass androidcookbook
```
5. 输出文件是添加了公钥证书的customtruststore.bks(bks为Bouncy Castle Keystore). 保护口令为androidcockbook
6. 复制customtruststore.bks到app的raw文件夹去.
7. 在app代码里从raw文件夹中加载本地truststore到一个KeyStore对象里去. ? 书里将保护口令硬编码了出来, 但是该口令只是用于验证truststore的完整性, 不是用来保护其安全性. 而且truststore是服务器的公钥证书
Android原生代码的漏洞分析
- 检查文件权限: 寻找权限设置不正确或存在问题的文件
  - 列出"所有用户均可读取的文件": find [path-to-search] -perm 0444 -exec ls -al {} \;
  - 列出"所有用户均可写的文件": find [path-to-search] -perm 0222 -exec ls -al {} \;
  - 列出"所有用户均可执行的文件": find [path-to-search] -perm 0111 -exec ls -al {} \;
  - 列出"setuid位设为1的可执行文件": find [path-to-search] -perm -4111 -exec ls -al {} \;
  - 列出所有属于"root"用户的文件: find [path-to-search] -user 0 -exec ls -al {} \
- 交叉编译原生可执行程序: 创建Android.mk文件和JNI文件夹, 利用NDK提供的ndk-build进行编译.
- 条件竞争漏洞. 攻击者利用条件竞争漏洞需要满足以下条件:
  1. 能访问和恶意修改存在漏洞的进程所要竞争访问的资源: 如果攻击者无法访问到竞争的资源, 那么是不能引发漏洞的. 当有访问能力时, 进程内所有不适用互斥的独占式访问就都可以利用, 而且进程不检查信号量或自旋锁就直接使用某个指针指向数据的情况发生的非常频繁
  2. 使用时间/检查时间(TOU/TOC)的窗口大小: 本质上是应用程序请求访问一个资源和实际访问到该资源之间的时间差. 竞争条件漏洞利用非常依赖于该时间差, 因为利用的本质就是在这个时间差内竞争到资源的访问权, 以恶意地影响资源.
- fuzzing: 使用Radamsa进行模糊测试

Day10: 阅读软件供应链安全相关论文

Day11: 阅读软件供应链安全相关论文

Towards Measuring and Mitigating Social Engineering Software Download Attacks
- 社工攻击主要分为两类, 一类是重打包良性软件(捆绑软件或其他潜在恶意程序), 一类是警告用户正在使用的Adobe Flash或Java以及过时或不安全, 而要求用户下载伪造的更新.
软件供应链污染机理与防御研究
- 污染技术研究
  - 开发环境污染
    1. 源代码污染: 以CCleaner为例, 攻击者入侵公司服务器, 在开发环境里的CRT静态库函数内植入了恶意代码. 并且植入的代码并非开发人员编写的源代码, 因此难以被发现
    2. 开发工具污染: 以XCode为例, 从非官方渠道下发植入恶意代码的Xcode工具.
    3. 第三方开发包污染: 以pypi为例, 主要是通过名称的相似来迷惑受害者.
  - 软件捆绑污染
    - 众多未授权的第三方下载站点, 云服务, 共享资源, 破解版软件等共同组成了灰色软件供应链. 而通过灰色软件供应链获取的软件极易被攻击者植入恶意代码.
    - 而一些正规下载站也会因审核不严格而被攻击者上传恶意软件
    - Android的应用通过二次打包生成篡改后的app, 并且用户容易将罪名怪罪给app的开发者.
  - 网络劫持污染
    - 软件下载时劫持污染: 用户到软件下载服务器之间形成一条数据链路, 攻击者通过中间人的方式进行攻击, 影响传输的数据, 进而对用户下载的软件造成污染
    - 软件升级时劫持污染: 攻击者在中间网络中, 通过URL劫持的放啊, 对多款软件升级时的下载URL进行劫持, 跳转到攻击者的服务器上, 进而导致下载了恶意如那件.
  - 运行环境污染
    - 污染软件运行环境, 比如python, java, php
程序逆向分析在软件供应链污染检测中的应用研究综述
- 程序逆向分析
  - 传统恶意代码分析技术使用的特征主要分为语法特征和语义特征两大类.
    - 语法特征需要通过解析程序的二进制指令, 并转换成高级语言(反汇编, 反编译)
    - 语义特征包括API调用和执行过程中系统状态改变情况
  - 动态分析的瓶颈在于覆盖率邮箱, 很容易受到干扰. 对此提出了路径探索和透明分析技术
    - 路径探索时应用最广泛的提高动态分析覆盖率的方法. 该技术通过求解不同路径约束的程序输入, 引导程序控制流向更高覆盖率方向转移
    - 透明分析着力于构建被分析样本无法感知的分析系统, 防止被分析程序因为检测到分析环境而不再执行恶意行为.
- 供应链安全中的挑战:
  - 程序分析需要能处理多样化的软件发布形式, 并从这个提取相应的城固县进行分析
  - 分析系统需要能自动执行或解压安装包, 成功释放程序可执行文件, 并监控整个安装和程序执行过程.
  - 输入形式的多样化, 比如配置文件, UI交互, 网络通信, 与操作系统交互等. 这些致使动态分析方法很难自动发现并提供有效输入. 而且异步处理时常用的编程技术, 尚未有静态分析方法能理解各种异步编程模型并准确还原程序逻辑或控制流转移关系
  - 现有工作多出于语法分析层面, 少有工作能自动准确理解程序语义.

Day12: 学习知识图谱知识, 掌握ES和Neo4j的使用

ElasticSearch
- ES里可以将index理解为数据库(index的名称必须小写), index里的单条记录称为Document, Document可以分组(Type), 分组实际上是一种过滤的手段.
- 使用elasticsearch和elasticsearch_dsl进行操作
知识图谱
- 在信息的基础上, 建立实体之间的联系, 就能形成知识
- 每条知识用一个三元组表示(subject-predicate-object)
- 知识图谱的架构:
  - 逻辑结构
  - 分为模式层和数据层
    - 数据层主要由一系列事实组成, 而知识将以事实为单位进行存储.
    - 模式层构建在数据层智商, 通过本体库来规范数据层的一系列事实表达
  - 体系架构
- 知识抽取: 从公开的半结构化, 非结构化数据中提取处实体, 关系, 属性等知识要素
  - 面向开放的链接数据, 通过自动化技术抽取出可用的知识单元
  - 知识单元主要包括实体, 关系和属性
    - 实体抽取: 从原始语料中自动识别出命名实体.
    - 关系抽取: 结局实体间语义链接的问题.
    - 属性抽取: 通过属性形成对实体的完整勾画
- 知识融合: 消除实体, 关系, 属性等指称项与事实对象之间的其一, 形成高质量的知识库
  - 由于知识来源广泛, 存在知识质量良莠不齐, 来自不同数据源的知识重复, 知识间的关联不够明确等问题, 所以需要进行知识的融合.
  - 将不同源的知识进行异构数据整合, 消歧, 加工, 推理严重, 更新等步骤达成融合
- 知识推理: 在已有的知识库基础上进一步挖掘隐含的知识, 从而丰富, 扩展知识库
- 技术上, 知识图谱的难点在于NLP, 因为需要机器理解海量的文字信息. 但工程上, 难点在于知识的获取和融合.
Neo4j
- 使用py2neo进行操作
- 连接图: graph = Graph('bolt://localhost:7687', username='neo4j', password='neo4j')
- 创建节点: a = Node('label', name='a'), 进行绘制graph.create(a)
- 建立关系: r1 = Relationship(a, 'to', b, name='goto')

Day13: 学习Neo4j的CQL语法以及使用python操作es

传送门: Neo4j教程

Neo4j:
- 优点: 容易表示连接的数据, 检索/遍历/导航连接数据容易且快速, 容易表示半结构化数据
- 构建模块:
  - 节点: 节点是图表的基本单位, 包含具有键值对的属性
  - 属性: 用于描述图节点和关系的键值对
  - 关系: 用于连接两个节点, 具有方向, 关系也有属性
  - 标签: 用于描述节点和关系, 是一个分类
- CQL:
  - CREATE: 用于创建节点, 关系和标签, 要注意, CREATE始终都会创建新的节点
    - 创建没有属性的节点: CREATE (<node-name>:<label-name>)
    - 创建具有属性的节点: CREATE (<node-name>:<label-name>{<Property1-name>:<Property1-Value>})
    - 还可以用于创建关系和标签
  - MATCH: 用于获取匹配到的数据
    - MATCH (<node-name>:<label-name>)
    - 不过MATCH不能单独使用, 需要进行配合
  - RETURN: 用于节点的属性, 关系的属性
    - RETURN <node-name>.<property1-name>
    - 同MATCH意义不能单独使用
  - MATCH+RETURN: MATCH可以和RETURN组合使用: MATCH Command \n RETURN Command
  - 创建关系: CREATE (p1:Profile1)-[r1:LIKES]->(p2:Profile2)
    - CREATE (<node1-name>:<label1-name>)-[(<relationship-name>:<relationship-label-name>)]->(<node2-name>:<label2-name>)
  - WHERE: 用于过滤MATCH的结果, WHERE <condition> <boolean-operator> <condition>, condition的格式为<property-name> <comparison-operator> <value>
  - DELETE: 用于删除节点和关系, DELETE <node-name-list> 这里的list是用MATCH返回得到的, 也可以是用,分隔的多个节点名
  - SET: 用于设置或修改属性, 用法与DELETE类似
  - REMOVE: 用于删除属性和标签: 用法与DELETE类似
  - ORDER BY: 用于对MATCH结果进行排序, ORDER BY <property-name-list> [DESC]
  - UNION: 用于将结果合并, 要求结果的名称/数据类型都必须匹配, <MATCH Command1> UNION <MATCH Command2>
  - LIMIT: 用于限制MATCH返回结果的行数, 它修剪CQL查询结果集底部的结果, LIMIT <number>
  - SKIP: 同LIMIT, 不过是修剪了结果集顶部的结果
  - MERGE: MERGE = CREATE + MATCH, MERGE会在创建节点前进行查重, 如果重复了就不会插入新节点.
  - NULL值: CQL里将NULL视作为缺失值或未定义值, 很多没有指定的地方都会用NULL进行缺省
  - IN: IN[<Collection-of-values>], 类似python的in, 用于确定范围
  - 函数:
    - String函数: UPPER/LOWER/SUBSTRING/REPLACE
    - AGGREGATION函数: COUNT/MAX/MIN/SUM/AVG
    - 关系函数: STARTNODE/ENDNODE/ID/TYPE
  - 索引: CREATE INDEX ON :<label_name> (<property_name>)
  - UNIQUE约束: CREATE CONSTRAINT ON (<label_name>) ASSERT <property_name> IS UNIQUE

Day14: 学习知识图谱构建技术和阅读两篇应用知识图谱于安全分析的论文

传送门: 自底向上——知识图谱构建技术初探

知识图谱构建技术:
- 知识图谱: 是结构化的语义知识库, 用于描述概念及相互关系, 实现知识的推理
- 构建方式:
  - 自顶向下: 借助已有的结构化数据源(比如百科类), 从高质量数据中提取本体和模式信息, 加入到知识库
  - 自底向上: 从公开采集的数据中提取出资源模式, 选取其中置信度高的信息加入到知识库
- 逻辑架构:
  - 数据层: 存储真实具体的数据
  - 模式层: 在数据层之上, 存储经过提炼的知识.
- 技术架构: 构建知识图谱是一个迭代更新的过程, 每轮迭代包括三个阶段
  - 信息抽取: 从多源异构数据源中提取出实体, 属性及相互关系
  - 知识融合: 在获得新知识后, 需要进行整合, 以消除矛盾和歧义.
  - 知识加工: 对于融合后的新知识, 需要进行质量评估, 将合格的部分加入到知识库中, 确保知识库的质量
一种基于知识图谱的工业互联网安全漏洞研究方法
- 从ISVD这样的半结构化信息源里提取了漏洞信息条目.
- 信息提取引擎将漏洞信息, 事件信息和产品信息从原始信息中提取出来, 以下是提取规则
  - 通过正则表达式, 提取描述中的时间
  - 模糊匹配提取产品的相关描述
- 关联分析: 建立事件到漏洞的关系, 再建立产品到漏洞的关系, 推导处事件到产品的关系.
数据驱动的物联网安全威胁检测与建模
- 知识融合: 将表示相同内涵但是名称不一致的实体统一成一个名称表示.
  - 实体层融合首先生成候选物联网安全实体, 主要有基于名称词典, 基于搜索引擎的方法
  - 其次, 候选实体排序. 主要为有监督和无监督的排序方法
  - 最后, 无链接指称项预测, 当知识库里没有相关的候选实体项时, 需要给出近似的实体
- 知识推理: 包含基于符号的推理和基于统计的推理
  - 基于符号: 通过指定规则, 从已有关系中归纳出新的规则
  - 基于统计: 利用机器学习方法, 通过统计规律从知识图谱中可以有效发现一些网络异常和攻击, 挖掘安全威胁的隐藏关系和路径, 并对攻击进行预测, 从而感知并展示网络的安全态势. 主要包括实体关系学习方法, 类型推理方法和模式归纳方法.

Day15: 阅读模糊测试资料和掌握Radare2用法

传送门: The Fuzzing Book, A journey into Radare 2

Fuzzing: Breaking Things with Random Inputs: 讲述了简单的随机数生成Fuzzer及其构造, 并通过简单的代码示例介绍了比如内存溢出, 信息泄露的问题, 还有一些内存检查ASAN和assert来帮助检查错误的方法.
Radare2
- 一些常用的选项:
  - -a arch 指定架构
  - -A 运行aaa命令用以进行完整的分析
  - -b bits 指定比特数
  - -B baddr 指定载入基地址
  - -c cmd 指定要执行的radare命令
  - -d 进入调试模式
  - -i file 运行指定的脚本
  - -k os 指定os (linux, macos, w32, netbsd, ...)
  - -l lib 载入插件
  - -p project 使用指定工程
  - -w 以write模式打开文件
- rabin2: 可以从二进制中提取Sections, Headers, Imports, Strings, Entrypoints信息, 支持多种文件格式ELF, PE, Mach-O, Java CLASS
  - rabin2 -I file: 显示二进制的基本信息
- radare2命令:
  - ie: 显示程序入口点信息(info entrypoint)
  - fs: 显示可用的标记, fs symbols; f可以打印相应标记空间里的信息
  - iz: 显示data段里的字符串, izz可以打印整个二进制内的字符串
  - axt: 找到引用该地址的地方, axf则是找到该地址引用的目的地址. 注意现在需要指定fs进行搜索了. fs strings; axt @@ str.*
  - @@: 可以理解为for-each
  - afl: analyze function list, 显示分析处的函数列表
  - s: seek, 可以进入到相应的函数或地址, 函数名可以用上面的afl给出
  - pdf: print diasm function, 显示函数的汇编指令
    - pdf @ sym.beet可以用于显示指定函数的汇编
  - V: 进入Visual Mode, 使用p/P切换模式,
  - Visual Mode下的操作:
    - k和j: 跟vim一样进行上下移动
    - Enter: 在jump和call指令的时候, 可以用于进入到目的地址
    - u: 返回上一个地址
    - x/X: 显示交叉引用, x表示到达该指令的引用, X表示该指令所引用的地方
    - : command用来执行shell命令
    - ;[-]comment: 用来增加/移除注释
    - m<key>: 用来标记某个具体的偏移并用某个按键来绑定
    - q: 退出visual mode
  - VV: 进入Visual Graph模式, 就是直接看控制流图
  - Visual Graph下的操作:
    - hjkl进行移动
    - g进入函数, 在graph里很多函数后面都有一个按键的标记, 按下就能进入该函数
  - ahi: 用于做数据的类型转换, 比如将某个地址的数据转换成字符串类型ahi s @ <addr>
  - ood: 重新以Debugger模式打开文件, 可以带参数, 比如ood args1
  - dc: debug模式下执行, 类似continue命令, 会继续执行

Day16: 了解代码覆盖率和程序分析研究进展

Code Coverage
- 黑盒测试用于测试特定条件的结果. 优势是能够针对特定输入检查错误, 劣势是无法达到很好的覆盖率.
- 白盒测试则会尽量满足覆盖率, 起码满足语句和分支的覆盖. 优势是能针对已实现的行为进行测试, 而劣势就是无法满足未能实现的行为.
- py通过trace的方式将执行的代码行信息汇总起来得到覆盖率. 而c代码可以通过gcov获取覆盖率情况
程序分析研究进展
- 抽象解释: 通过对程序语义进行不同程度的抽象以在分析精度和计算效率之间取得权衡.
- 数据流分析: 通过分析程序状态信息在控制流图的传播来计算每个静态程序点(语句)在运行时可能出现的状态
  - IFDS/IDE 数据流分析框架: IFDS将数据流分析问题转换为图可达问题, 从而有效进行上下文敏感的过程间分析.
    - IFDS基于程序过程检控制流图定义了一个超级流图, 其中每个节点对应在一个程序点的抽象域中的一个元素, 而节点间的边表示该元素在过程间控制流图的传播, 对应着数据流分析中的转移函数.
    - 通过求解是否存在从程序入口到每个程序点的可达路径, 我们可以得到该程序点的状态信息.
  - 基于值流图的稀疏数据流分析方法
    - 传统数据流分析在cfg上将所需计算的状态信息在每个程序点传播得到最终分析结果, 这个过程中通常存在较多冗余操作. 为了提高效率, 提出了多种稀疏的分析方法从而不需计算状态信息在每个程序点的传播而得到和数据流分析相同的结果.
    - 该技术通过一个稀疏的值流图直接表示程序变量的依赖关系, 从而使得状态信息可以有效地在该稀疏的值流图上传播. 值流图保证了状态信息有效传播到其需要使用该信息的程序点, 并避免了无效程序点的冗余传播, 可大幅提高效率.
- 移动应用软件
  - 污点分析: 动态污点分析TaintDroid通过修改的Dalvik虚拟机, 在应用的java字节码解释执行过程中进行动态插装以实现对敏感数据的跟踪分析
- 二进制代码
  - 递归遍历反汇编: 无法准确识别间接跳转指令的跳转目标
    - 提出基于程序切片技术将间接跳转表进行规范化表示, 根据启发式特征识别间接跳转语句的目标
    - 提出通过在CFG上进行数据流分析, 进而完善CFG, 再迭代式进行数据流分析, 逐步完善CFG.
    - 提出通过动态分析识别间接跳转的目标, 并采用强制执行的方式驱动程序探索所有路径, 从而构建相对完整的控制流图.
    - 提出通过RNN识别二进制程序中的函数便捷
  - 高级语义恢复: 二进制程序大量信息确实.
    - 提出采用NLP类似技术识别二进制程序汇总的函数特征(参数类型和个数)
    - 提出通过切片, 提取函数调用指令的操作数的规范化表示, 根据启发式特征识别虚函数调用点
    - 提出识别程序中静态已知的全局地址, 栈偏移等识别全局变量和栈变量, 通过数据流分析识别间接内存读操作的返回结果等. 实现对二进制程序中的内存访问操作语义的识别.
    - 提出通过数据流分析, 跟踪this指针的流向, 识别候选的类成员函数及变量, 从而恢复c++对象
  - 代码插装/改写
    - 在原始二进制程序中静态修改: 挑战是反汇编的准确率, 不正确的反汇编会使得插装后程序执行异常
    - 将二进制程序提升到IR再修改: 插装在IR上完成, 与二进制的指令集无关
    - 在代码执行过程中动态修改: 通过受控的执行环境, 在目标基本块, 函数执行前进行插装
  - 匹配漏洞模式
    - 静态分析组件间调用关系, 与恶意代码特征进行匹配, 从而识别安卓恶意代码
- 面向智能合约的程序分析
  - 符号执行被用于字节码层面检测智能合约中的已知类型的潜在漏洞
  - 相比传统软件, 智能合约的体量较小, 使得对其使用形式化技术称为可能.
  - 有的工作甚至直接将智能合约代码转换已有的验证系统所支持的形式, 借助已有验证系统快速形成分析, 比如将智能合约代码转换为LLVM字节码
- 面向深度学习软件的程序分析
  - 由于广泛存在的概率模型, 多层传播的复杂网络结构, 黑盒形式的用户借口等特性, 深度学习工具的质量难以度量, 现有的软件分析技术难以直接应用.
  - 提出了面向深度学习的动态符号执行方法, 该方法将测试需求表示为量化线性运算, 以神经元覆盖为目标测试深度神经网络的鲁棒性.

Day17: 了解基于变异的模糊测试技术和Python的代码简洁之道

Mutation-Based Fuzzing
- 基于变异的模糊测试: 通过微小的变异, 使得输入能够有效地触发新的行为
- 完全的随机生成有效输入需要的运行次数极其巨大, 因此思路转变为从有效输入中进行变异获取输入
- 每次变异都是微小的改动, 比如插入一个字符, 删除一个字符, 翻转比特等等
- 我们需要去引导有价值的变异, 抛弃无效的变异, 所以这里引入覆盖率作为模糊测试的指标进行判断哪个变异更好
clean-code-python:
- 使用有意义且可发音的变量名.
- 对于同一个类型的变量尽量统一使用相同的词汇来描述: 主要是避免多种说法带来的不一致和混淆, 增加维护的成本. 如有必要, 还可以进一步封装成类通过getter和setter使用
- 尽量不要使用硬编码: 或者类似魔数, 因为这样的硬编码数据很难进行管理, 并且也失去了它的表征含义.
- 尽可能多的使用带有信息的变量, 少用索引表示. 因为索引很难体现出它的涵义, 如有可能尽量用字符串索引.
- 减少不必要的上下文信息: 在我已经知道这是个什么东西的时候, 它的属性或成员就没有必要再重复这个信息. 不用犹豫直接把它去掉, 不要带来信息的冗余.
- 使用默认参数(缺省值)来替代短路或条件.
- 尽量减少函数的参数个数, 2个或更少为宜, 如果超出了, 那么可以考虑将函数代码进行拆分.
  - 使用from typing import NamedTuple和from dataclasses import astuple, dataclass在类构造的时候非常优雅!
- 一个函数, 一个功能: 尽量保持一个函数只实现一个功能, 这样能方便维护和重构
- 使用生成器能让代码在简洁的同时减少内存占用
- 不要将标志(flags)/模式(mode)作为函数参数: 将其作为函数参数说明你在该函数内实现了多个功能, 请保持一个函数一个功能的原则, 将其拆分开来.
- SRP: Single Responsibility Principle: 单一职责原则. 将不同的职责分离到单独的类中, 当需求变化时, 这个变化可以通过更改职责相关的类来实现. 如果一个类拥有多于一个的职责, 这些职责就耦合在了一起, 那么就会有多于一个原因来导致这个类的变化. 对于某一职责的更改可能会损害类满足其他耦合职责的能力, 这样的耦合会导致设计的脆弱, 以致于职责发生改动时产生无法预期的变化.
- OCP: Open/Closed Principle: 开闭原则. 一个软件实体如类, 模块和函数应该对扩展开放, 对修改关闭. 当修改需求时, 应该尽量通过扩展来实现变化, 而不是通过修改已有代码来实现变化.
- LSP: Liskov Substitution Principle: 里氏替换原则. 任何父类可以出现的地方, 子类一定可以出现.
- ISP: Interface Segregation Principe: 接口隔离原则: 使用多个隔离的接口, 优于使用单个接口, 这可以降低类之间的耦合度
- DIP: Dependence Inversion Principle: 依赖倒转原则: 高层模块不应依赖低层模块, 两者都应该依赖其抽象, 抽象不应该依赖细节, 细节应该依赖抽象.

Day18: 了解灰盒模糊测试技术和阅读二进制重写的论文

Greybox Fuzzing:
- AFL通过轻量级的插装来获取输入的分支覆盖情况. 如果某个输入提高了覆盖率, 那么就将它扔回种子池做更多变异.
- AFL的插装是通过在每一个跳转指令处插入一小段代码, 执行时会为执行的分支分配一个唯一的标识符, 并递增该分支的计数器. 出于性能考虑值统计粗略的分支名字次数.
- 插装在程序编译阶段完成, 同样对于无法插装的代码(黑盒)也能通过QEMU或Intel Pin来运行AFL
- Power Schedules: 能量调度. 用于为有趣的种子分配更多的能量.
Binary Rewriting without Control Flow Recovery
- 二进制重写需要恢复控制流主要是因为可能会移动指令, 所以需要控制流信息.
- 论文提出了E9Patch, 它可以在不需要移动指令的情况下将跳转指令插入到函数蹦床(trampoline)去, 实现了在无需控制流信息的情况下静态重写x86_64的二进制文件.
- 传统二进制重写工具的步骤:
  1. 使用一个反汇编器前端解析二进制文件的机器码指令.
  2. 恢复控制流信息.
  3. 对插入/删除/替换/重定位后的二进制代码进行转换
  4. 输出修改后二进制的后端.
- 实际情况下二进制很难恢复控制流信息, 传统方法仅能针对小且简单的文件
- instruction punning(指令修补): 一种轻量级的动态插装方法.
- 现有的x86_64补丁技术
  1. Signal Handlers: 用单字节int3指令替换每个patch处的指令. int3会触发中断, 信号处理程序接受到该中断进行patch. 但是中断需要内核/用户模式的上下文切换, 性能极差.
  2. Jumps: 用跳转指令代替patch位置的指令, 跳转指令会跳向实现该patch的蹦床. 蹦床执行完转回主程序, 这种方法比中断要快很多. 在x86_64上可以使用jumpq rel32来实现, 该指令长度为5, 1个字节是跳转指令的操作码, 4个字节则是rel32. 因此patch位置的指令大于等于5个字节时就可以之间进行替换. 而小于5个字节的时候就难以适用.
  3. Instruction Punning: 找到一个与任何重叠指令共享相同字节表示形式的相对偏移值rel32, 然后用此特殊的rel32值将补丁指令安全地替换为相对近跳转.
    - 例如: mov %rax,(%rbx) add $32,%rax
    - original: 48 89 03 48 83 c0 20
    - patched: e9 xx xx 48 83 c0 20
    - 假设我们需要修补的是这个3字节长的mov指令. 我们就可以修改前3个字节, 同时利用重叠的48 83进行跳转, 也就是jmpq 0x8348xxxx, 这样我们就实现了修改3个字节的同时的得到了5字节的跳转指令.
    - 同样蹦床的位置(rel32)也就被限制在了0x8348xxxx的范围. 同时0x8348xxxx也不一定是有效的地址范围, 如果指向了无效的地址范围, 那么就不能用作蹦床位置. 因此这也就是该技术遇到的关键问题.
  - 论文的方法: 结合Jumps和Instruction Punning方法, 如果这两个方法都失败了, 那么就根据策略T1/T2/T3组合进行指令的padding/punning/eviction(填充/修改/逐出).
- Patch策略:
  - 基于以下指令序列进行解释
```
Ins1: mov %rax,(%rbx)  
Ins2: add $32,%rax 
Ins3: xor %rax,%rcx
Ins4: cmpl $77,-4(%rbx)
```
  - T1(Padded Jumps): 使用冗余的指令前缀来填充跳转指令. 如图所示, T1(a)的冗余前缀是48, T2(a)的冗余前缀是48 26. 使用冗余前缀的缺点就是会限制可操控的范围, 比如B2的范围是0x8348xxxx, 但T1(a)的范围只有0xc08348xx, T1(b)则是一个具体的值了.
    - T1的适用性取决于补丁指令的长度, 长度越大, 能右移尝试的次数也就越多. 同时也意味着T1不适用于单字节指令. 同时右移会受到越多的范围约束.
  - T2(Successor Eviction): 使用后一个指令(ins2)的pacth冗余来填充跳转指令(ins1). 比如利用T1策略将ins2填充为e9 YY YY YY, 那么可以再次应用T1策略让ins1利用ins2的冗余e9 YY, 那么可以控制的范围就成了0xYYe9XXXX. 而这个策略不仅能提高覆盖的范围, 也能适用于单字节指令(直接覆盖为e9)
  - T3(Neighbour Eviction): 通过短跳转(-128~127)来跳转到附近的可用指令, 到达后结合T1和T2使用得到更大的覆盖范围.
- Reserve Order Patching: 按照反向顺序修补指令, 比如先补丁Ins2指令, 然后补丁Ins1指令.

Day19: 对Python代码进行数据流前向切片

romanofski/programslice
- 仅实现了前向切片
- 程序的切片函数入口是slice_string. 它接受5个参数, 前3个是用于指定你要跟踪数据流的变量名以及该变量所在位置(行和偏移). 然后给定程序代码片段.
```
node = ast.parse(source, filename)
visitor = programslice.visitor.LineDependencyVisitor()
visitor.visit(node)
graph = visitor.graph
if graph:
    start = programslice.graph.Edge(varname, currentline, offset)
    result = programslice.graph.Slice(graph)(start)
return formatter(result, source)()
```
- 分析和遍历是借助模块ast来实现的. 通过继承ast.NodeVisitor实现LineDependencyVisitor类, 并重写了visit_FunctionDef和visit_Name方法.
  - 重写visit_FunctionDef只是单纯清空了保存的writes和reads字典. 这是避免函数之间的结果冲突. (也就是还不支持跨函数的分析)
  - visit_Name则是关联的重要步骤. 因为通过ast我们可以遍历语法树里的节点, 对于数据流分析, 如果仅仅是关注某个变量的数据流向, 那么只需要关注read和write. 同时表现也就是ast.Load和ast.Store. 那么在遍历到这样的情况后, 就可以进行关联.
- 关联后得到graph. 然后根据给定的起始变量varname和它所在行和偏移, 进行前向切片得到result
- 因为边的关联都在graph里关联好了, 所以在指定好变量后, 前向切片也不过是从指定的边开始, 匹配所有相关的边而已. 这里使用了深度优先的方法进行遍历.
```
visited = [edge]
children = deque(self.graph.get(edge))
if not children:
    return []

while children:
    edge = children.popleft()
    if isinstance(edge, Graph) and edge not in visited:
        slice = Slice(edge)
        visited.extend(slice(edge.first))
    elif edge not in visited:
        children.extend(deque(self.graph.get(edge)))
        visited.append(edge)

return visited
```

Day20: 详细阅读并总结e9patch的论文内容

项目地址: e9patch: A Powerful Static Binary Rewriter

论文总结的PDF

Day21: 阅读逆向工程参考手册和阅读IDA插件源码

reverse-engineering-reference-manual
- 内存中的值存储是小端序, 但是移入寄存器时就是大端序.
- 调试寄存器(DR0-7): DR0-3用于存储硬件断点信息, DR4-5保留, DR6是状态寄存器, 其中包含发生调试时间的信息, DR7存储DR0-3的断点条件和长度.
- CPU尝试执行指令前会检查当前是否触发硬件断点, 如果该地址存储在DR0-3中, 且满足读/写/执行条件, 就会触发INT1并暂停进程
- IDA会显示程序的本地函数, 静态链接函数和动态链接函数
- IDA函数窗口的的一些字段信息:
  - sagment: 该函数所属的段
  - locals: 局部变量和保存的寄存器长度(字节)
  - arguments: 该函数的参数长度(字节)
  - R: 该函数会返回给调用它的函数
  - F: far function
  - L: 库函数
  - S: 静态函数
  - B: BP based frame. IDA会自动将所有的栈帧指针转变为栈变量
  - T: 该函数包含类型信息
  - =: 栈帧指针是最初的栈指针. 也就是指向栈帧底部.
- GDB的设置: set disable-randomization off和set disassembly-flavor intel
- apropos <arg>可以搜索gdb里有关arg的命令/文档
- Microsoft Visual C++编译的程序, this指针保存在ecx, 有时保存在esi, g++编译的程序, this作为函数第一个参数传入.
findcrypt-yara: 实际上YARA规则来自于另一个开源项目Yara-Rules里的crypto规则. 插件只是进行了yara匹配把结果显示出来.
ida_yara: 利用了yara, 需要手动提供要匹配的字符串或十六进制值, 或者也可以正则, 作者用来搜索IDB里的数据, 但是没有很好的规则只能手动写匹配的话, 适用性有点差. 还不如不要做成IDA插件, 单独利用yara写一个脚本来做通用性的更好些.
ALLirt: libc转换为FLIRT特征是通过flair工具来实现的, 主要是pelf和sigmake. 另外有一个py库patoolib支持多种格式文件的解压还蛮不错.
- 创建.pat文件: ./pelf -p64 /usr/lib/x86_64-linux-gnu/libc.a libc.pat
- 创建.sig文件: ./sigmake -n <libname> libc.pat libc.sig
IDAFuzzy: IDA的模糊搜索插件. 模糊搜索功能由fuzzywuzzy库实现, 这个库的使用也很简单, 可以进行字符串之间的模糊匹配评分, 也可以根据一个字符串从一堆字符串中选出相似的结果.

Day22: 学习熊英飞老师的软件分析技术课程

熊老师的Software Analysis课程主页: 传送门

课程介绍:
- 哥德尔不完备定理: 对任意能表示自然数的系统, 一定有定理不能被证明
- 主流程序语言的语法+语义 = 能表示自然数的形式系统
- 停机问题, 内存泄露判定问题, 实质上也是不可判定问题, 也就是不能针对该问题的每一个实例都给出是/否的答案, 也就是说, 计算机没有能力去完全判断一段代码的好坏.
- 莱斯定理: 将程序视作一个从输入到输出的函数, 关于该函数的任何非平凡属性, 都不存在检查该属性的通用算法.
  - 平凡属性: 要么对全体程序都为真, 要么都为假的属性
  - 非平凡属性: 不是平凡的所有属性(可以理解为存在差异性)
- 检查停机问题的算法:
  - 当前系统的状态为内存和寄存器中所有bit的值
  - 给定任意状态, 系统的下一状态是确定的
  - 令系统所有可能的状态为节点, 状态之间的转换作为有向边. 形成一个有向图(有限状态自动机)
  - 如果从任意初始状态出发的路径都无环, 那么系统一定停机, 否则可能死机.
  - 因为状态数量有穷, 所以该算法一定终止.
- 近似求解判定, 除开回答"是"和"否", 还可以表示一个模糊的判断"不知道".
  - 上近似: 只输出"否"和"不知道", 因为这里作为下的"否"是精确的, 所以是上近似
  - 下近似: 只输出"是"和"不知道", 同样, 这里作为上的"是"是精确的, 所以是下近似
  - 好的结果当然是尽量回答精确的"是"和"否", 少回答模糊的"不知道"
- 假设正确答案是集合S:
  - must分析: 返回集合总是S的子集
  - may分析: 返回集合总是S的超集
  - 更全面的分析: 返回S的子集(must), 超集(may), 不相交集(never)
- 求近似解的另一种方法搜索(上一个方法是抽象): 穷举所有的组合来回答是或否, 如果超时则认为"不知道"
- 基于抽象解释的程序分析: 数据流分析, 过程间分析, 指针分析, 抽象解释, 抽象解释的自动化.
- 基于约束求解的程序分析: SAT, SMT, 霍尔逻辑, 符号执行
- 参考资料: 龙书, Lecture notes on static analysis, https://cs.au.dk/~amoeller/spa/, Principle of Program Analysis, Decision Procedures An Algorithmic Point of View

Day23: 学习高级二进制代码反混淆资料和阅读混淆技术论文

腾讯玄武实验室

招聘情报

2020/4/8 实习生招募

来自玄武实验室微信公众号当日推送

基本要求:

在任意系统环境(Android/Linux/MacOS/iOS/Win)下有丰富逆向调试经验, 并熟悉安全机制和底层架构.
熟练使用一种编译型语言和一种脚本语言

加分项:

现实漏洞研究分析经验, 实际挖掘过漏洞, 写过利用代码.
掌握漏洞研究所需的各种能力, 包括IDA插件开发, Fuzzer开发, 代码脱壳加密, 网络协议分析等.

优劣势分析:

我有足量时间的Android/Linux/Win的逆向调试经验, 对于Linux/Win的安全机制和底层架构有一定了解, 不了解Android的安全机制和底层架构.
编译型语言(C/C++)我的掌握程度一般, 脚本语言(Python)掌握良好.
漏洞研究分析经验是工作的必要内容, IDA插件开发部分, 我曾学习过IDAPython的内容, 对于7.0以上版本还需要了解. Fuzzer开发部分是我欠缺的, 我仅详细阅读过FuzzIL和AFL的源码实现, 并未有实际的开发经验. 有着一定的代码脱壳加密经验, 不过仍需多加练习. 网络协议分析我不擅长也不喜欢, 可以忽略.

关于X-Man夏令营

非常感谢赛宁网安, 诸葛建伟老师和陈启安教授的帮助才让我有幸成为第一期X-Man夏令营的成员. 我也是在X-Man夏令营里认识了A7um, iromise, 40huo等一众大佬. 就我同期的X-Man夏令营学员们, 几乎都投身于国内的安全事业, 如今学员们遍地开花, 也是诸葛老师非常欣慰看见的吧.

关于作者

从初入社会到如今的这半年多时间里, 我找到了生活工作和学习的节奏, 我并没有选择急于去钻研技术, 而是阅读了更多的非技术类书籍, 这教导了我为人处世的经验, 在北京站稳了脚跟, 顺利从刚毕业的懵懂小生过渡到现在略有成熟的青年. 而如今我要展开脚步, 去追求梦想的工作了, 所以我创建了该项目, 既是对自我的激励监督, 也是向分享我的学习历程.

玄武实验室对于国内安全从业人员的吸引力, 就如同谷歌对广大程序员的吸引一般, 我渴望着得到玄武实验室的工作. 而我认识的A7um也在玄武实验室, A7um是我初学安全时仰慕的偶像之一, 我期待着能与玄武实验室里才华横溢的大佬们一起共事研究.

9iang22 / 365-days-get-xuanwulab-job Goto Github PK

365-days-get-xuanwulab-job's Introduction

365天获取玄武实验室的工作

这是什么?

学习进度

相关资源

腾讯玄武实验室

招聘情报

关于X-Man夏令营

关于作者

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent