现在的“ 伪基站” 一般是在Ubuntu系统环境下运行, 采用GSMS、OpenBTS、GNURadio和TeamViewer等多个基于Linux系统的开源软件项目来实现其主要功能, 并通过MySQL数据库来存储其短信发送任务。用户登录GSMS程序界面并设置显示号码、业务名称、发送计数、发送内容等参数后选择发送, “ 伪基站” 即可开始运行。对于“ 伪基站” 周边范围的手机而言, “ 伪基站” 信号强度远大于电信运营商的基站信号, 手机便会自动连入“ 伪基站” , 向“ 伪基站” 发送“ Location Updating Request” 信令, 并在收到“ Identity Request” 信令回复后, 自动上报自己的IMSI（international mobile subscriber identification number, 国际移动用户识别码）^[1]。“ 伪基站” 获取到周边手机的IMSI码后, 便可以向这些手机发送任意内容的短信息数据。

目前“ 伪基站” 的常规取证方法主要有以下三种途径：

1）进入MySQL数据库调取发送任务记录, 数据一般存储在一个名为“ GSMS” 的数据库的“ gsm_business” 表单中;

2）对系统中的文件“ send.data” 进行IMSI码统计, 文件一般存储在“ /var/usr/openbts” 或者“ /var/web/openbts” 文件夹下;

3）对OpenBTS的日志文件“ OpenBTS.log” 或“ syslog” 进行分析, 日志文件一般存储在“ /var/log” 文件夹下。

然而, 上述三种取证途径在现阶段经常会面临以下几个问题：

1）MySQL数据库的“ gsm_business” 表单已被清空, 通过MySQL命令行或者第三方软件查看, 均显示表单无数据;

2）文件“ send.data” 只有时间和IMSI码, 未存储发送内容, 在法庭诉讼时容易引起质疑。而且“ 伪基站” 的系统文件都是通过厂家的镜像文件还原生成, 在毫不相关的两个“ 伪基站” 中存在检出相同的“ send.data” 文件的现象;

3）在“ /var/log” 文件夹下未保存“ OpenBTS.log” 日志文件, “ syslog” 文件也只有极少量的记录信息。为了解决这些问题, 笔者对数据库文件进行大量实验测试和检验分析, 发现可以从其中提取出“ gsm_business” 表单中的发送任务, 包括未删除的所有数据和已删除的部分数据。

2.1 结构分析

前面介绍过“ 伪基站” 主要是通过MySQL数据库来存储短信发送任务, 数据库数据文件一般存储在“ /var/lib/mysql/gsms” 路径下的文件“ gsm_business.MYD” 中或者“ /var/lib/mysql” 路径下的文件“ ibdata1” 中, 这两种文件之间的数据结构稍有差别。另外, 部分“ 伪基站” 的“ /var/lib/mysql/gsms” 路径下会保存有BAK数据库备份文件, 文件名一般是“ gsm_business-############.BAK” （#代表数字, 通常为年月日时分秒）, 其数据存储结构与gsm_business.MYD文件大致相同, 本文将着重介绍gsm_business.MYD和“ ibdata1” 文件的数据区存储结构。

数据库文件的数据区主要由一个或者多个数据记录项组成, 每个数据记录项构成数据库的一条记录, 它主要包含以下8个字段：id（序号）、num（显示号码）、name（业务名称）、time（任务添加时间）、count（计数）、lasttime（实际发送计数）、content(发送内容)和status（发送状态）。注意, 实际发送计数不是字段count, 而是字段lasttime^[1]。

2.1.1 GSM_BUSINESS.MYD分析

以CPU采用Little-Edian字节存储机制的“ 伪基站” 为例, 在图1中所展示的是正常gsm_business.MYD的一个数据记录项内容, 现对它进行结构分析, 数据记录项的结构参数详细信息见表1。

图1

Fig.1

	Figure Option ViewDownloadNew Window
	图1 数据记录项（gsm_business MYD）Fig.1 Data-recorded items (gsm_business MYD)

表1

Table 1

表1(Table 1)

表1 GSM_BUSINESS.MYD数据记录项结构 Table 1 Structure of data-recorded items in gsm_business.MYD file 偏移量 例值 长度 含义 00H 0x0003 2B 数据头, 值为0003H 02H 0xA2 1B 下一个数据记录项起始位置的相对偏移, 值为162 03H 0x26 1B 暂未知 04H 0x04 1B 标识符, 值为00000100(二进制), Bit3和Bit2的值为01, 表示无count字段 05H 0x80 1B 标识符, 值为80H 06H 0x5623442D 4B id, 序号为1445151789 0AH 0x0B 1B 显示号码的长度, 值为11 0BH 0x3130363537353636363636 11B num, 显示号码, 值为10657566666 16H 0x02 1B 业务名称的长度, 值为2 17H 0x2E2E 2B name, 业务名称, UTF8编码内为：.. 19H 0x00001253C6843EBE 8B time, 任务添加时间, 值为20151022141 118 空 无 0B count值为0 21H 0x0000001E 4B lasttime, 实际发送计数, 值为30 25H 0x7C 1B 发送内容的长度124 26H 0xE68891E5BA97E995BFE69C9FE 587BAE594AEE8BFAAE5A5A5EFBC8C4C 56E7AD89E5A496E8B4B8E5A5A2E4BE88E59381E4B880E68A98E8B5B7EFBC8CE 8AFA6E68385E799BBE5BD95E7BD91E 7AB99EFBC9A7777772E6D706A39 39392E636F6D20E68896E58AA0E5BE AEE4BFA1EFBC9A6D706A3134313230E585B3E6B3A8 124B content, 发送内容, UTF8编码内容为： 我店长期出售迪奥, LV等外贸奢侈品一折起, 详情登录网站：www.mpj999.com 或加微信：mpj14120关注 A2H 03 1B status, 状态码, 值为3

表1 GSM_BUSINESS.MYD数据记录项结构 Table 1 Structure of data-recorded items in gsm_business.MYD file

我们通过Mysql数据库的“ Select * from gsm_business” 命令行进行查询, 可以证明上述数据解析的正确性, 查询结果见图2。

图2

Fig.2

	Figure Option ViewDownloadNew Window
	图2 查询结果（gsm_business MYD）Fig.2 Result from inquiry (gsm_business.MYD)

2.1.2 ibdata1文件分析

ibdata1文件的数据记录项结构与gsm_business.MYD不同。以CPU采用Big-Edian字节存储机制的“ 伪基站” 为例, 在图3中所展示的是正常ibdata1文件的一个数据记录项内容, 现对它进行结构分析, 详细信息见表2。

图3

Fig.3

	Figure Option ViewDownloadNew Window
	图3 数据记录项（ibdata1）Fig.3 Data-recorded items (ibdata1)

表2

Table 2

表2(Table 2)

表2 ibdata1文件数据记录项结构 Table 2 Structure of data-recorded items in ibdata1 file 偏移量 例值 长度 含义 00H 0xAE 1B 发送内容的长度, 值为174 01H 0x80 1B 字段标识符, 值为80H 02H 0x04 1B 业务名称的长度, 值为4 03H 0x0B 1B 显示号码的长度, 值为11 04H 0x00000018 4B 暂未知 08H 0x00EC 2B 下一段数据记录项起始位置的相对偏移值, 值为236 0AH 0x5697C706 4B id, 序号, 值为1452787462 0EH 0x0000000C4814000000003202C6 13B 暂未知 1BH 0x3130363933383934383539 11B num, 显示号码, 值为10693894859 26H 0x30313134 4B name, 业务名称, 值为0114 2AH 0x80 1B 字段标识符, 值为80H 2BH 0x001255E47E4466 7B time, 任务添加时间, 值为20160115000422 32H 0x80 1B 字段标识符, 值为80H 33H 0x022681 3B count, 计数, 值为140929 36H 0x80 1B 字段标识符, 值为80H 37H 0x0043EF 3B lasttime, 实际发送计数, 值为17391 3AH 5BE6BEB3E997A8E98791E6 B299E5A8B1E4B990E59F8E5DE6899 3E980A0E6BEB3E997A8E7B D91E4B88AE69C80E5A4A7E8B58CE59F8E777777 2E6B3030342E6363E6B3A8E5 868CE980813338E58583E4BD93E9AA8CE98791EFBC8CE799BE E7A78DE6B8B8E6888FE58C85E 68BACE79C9FE4BABAE799BEE5AEB6E4B990EFBC8CE79 4B5E5AD90E6B8B8E889BAEFBC8CE5BDA9E7A5 A8E6B8B8E6888FEFBC8CE4BD93E8 82B2E8B59BE4BA8BE7AD89E38082 174B content, 发送内容, 采用UTF8编码内容为：[澳门金沙娱乐城] 打造澳门网上最大赌城www.k004.cc注册送38元体验金, 百种游戏包括真人百家乐, 电子游艺, 彩票游戏, 体育赛事等。 E8H 0x80 1B 字段标识符, 值为80H E9H 0x000000 3B status, 状态码, 值为0

表2 ibdata1文件数据记录项结构 Table 2 Structure of data-recorded items in ibdata1 file

通过Mysql数据库“ Select * from gsm_business” 命令行查询可以证明上述数据解析的正确性, 查询结果见图4。

图4

Fig.4

	Figure Option ViewDownloadNew Window
	图4 查询结果（ibdata1）Fig.4 Result by inquiry (ibdata1)

2.2 删除原理

当数据库文件的一条记录被系统删除时, 该记录对应的数据记录项不会被全部清零或更改, 系统只会更改其对应数据记录项的前面少数字节。下面本文将通过删除前后的比对实验来展示其删除原理。

2.2.1 GSM_BUSINESS.MYD删除比对

当通过数据库命令删除这条记录后, 其对应的数据记录项更改如图5所示。数据记录项的前20个字节大部分已经被“ 00” 或者“ FF” 填充, 但是主要的字段仍未更改, 如：发送内容、发送计数、任务添加时间等。

图5

Fig.5

	Figure Option ViewDownloadNew Window
	图5 数据记录项删除比对（gsm_business.MYD）Fig.5 Comparison of the deleted data-recorded items

2.2.2 ibdata1文件删除比对

ibdata1文件的删除原理与GSM_BUSINESS.MYD大体相同, 只是更改的数据位置不同而已, 主要的字段内容未被更改, 见图6。

图6

Fig.6

	Figure Option ViewDownloadNew Window
	图6 数据记录项删除比对（ibdata1）Fig.6 Comparison of the deleted data-recorded items (ibdata1)

2016年, 某市一起电信诈骗案, 办案民警将一台“ 伪基站” 送检。通过采用传统的取证手段进行检验, 发现检材的“ send.data” 的IMSI数较少, 仅有27 621个, 而且任务添加时间都为2013年期间（见图7）, 检材数据库查询结果则显示“ gsm_business” 表单数据任务仅2个（见图8）。然而, 经进一步检验, 笔者发现检材CPU为Big-Edian字节存储机制, 发送记录数据存储在ibdata1文件中。采用上面介绍的ibdata1数据恢复方法对其进行恢复, 检出大量未覆盖的已删除发送任务记录。下面选取其中一段数据（见图9）, 对它进行结构分析：

图7

Fig.7

	Figure Option ViewDownloadNew Window
	图7 send.data文件内容Fig.7 Content of the send.data file

图8

Fig.8

	Figure Option ViewDownloadNew Window
	图8 查询结果（实例）Fig.8 Result by inquiry (example)

图9

Fig.9

	Figure Option ViewDownloadNew Window
	图9 已删除的数据记录项Fig.9 Deleted data-recorded items

1) 发送内容长度, 未更改, 值为“ 0x83” , 转换成十进制为“ 131” ;

2) 业务名称长度, 未更改, 值为“ 0x03” , 转换成十进制为“ 3” ;

3) 显示号码长度, 未更改, 值为“ 0x0B” , 转换成十进制为“ 11” ;

4) 字段id, 未更改, 值为“ 0x00000022” , 转换成十进制为“ 34” ;

5)字段num, 未更改, 值为“ 0x3138393733383535333138” , 采用UTF8编码转换后为“ 18973855318” ;

6) 字段name, 未更改, 值为“ 0x757974” , 采用UTF8编码转换后为“ uyt” ;

7) 字段time, 未更改, 值为“ 0x00001253D1A9156D” , 转换成十进制为“ 20151209104749” , 即2015年12月09日10时47分49秒;

8) 字段count, 未更改, 值为“ 0x0009AC” , 转换成十进制为“ 2476” ;

9) 字段lasttime, 未更改, 值为“ 0x04FB31” , 转换成十进制为“ 326449” ;

10) 字段content, 未更改, 长度131个字节, 值为“ 0xE58F8CE5B3B0E5BE80E8BF94E995BFE6B299EFBC8C2E2EE
59F8EE58CBAE5858DE8B4B9E68EA5E980812CE5B08FE4BBB6E5B
FABE98092EFBC8CE696B9E4BEBFE5BFABE68DB7EFBC8CE8
B68AE9878E7375762CE8AF9AE4BFA1E69C8DE58
AA13133333337333831323232203138393733383535
3331385BE585A8E585B4E8BDA6E9989F5D” , 采用UTF8编码转换后为“ 双峰往返长沙, ..城区免费接送, 小件快递, 方便快捷, 越野suv, 诚信服务13337381222 18973855318[全兴车队]” ;

11) 字段status, 未更改, 值为“ 0x000001” , 即1。

至此, 一个已删除的数据记录项被成功恢复, 其他数据记录项的提取和恢复步骤同上, 这里不再一一赘述, 恢复结果见图10。最终笔者在检材中恢复13个发送任务, 共计3 721 614条发送记录, 远远多于数据库查询得到的结果。我们可以通过time参数对系统镜像的原始数据和犯罪嫌疑人实际发送的数据加以区分。

图10

Fig.10

	Figure Option ViewDownloadNew Window
	图10 恢复结果Fig.10 Recovered result

通过取证实践表明, 本文介绍的方法可以成功恢复提取未覆盖的删除发送任务, 在“ 伪基站” 取证工作中有着较强的实用性和适用性。而且在对于使用MySQL数据库来存储数据的其他软件系统的取证分析工作中, 此方法可以举一反三, 通用性较强。但是, 由于删除原理不同, 此方法对于GSM_BUSINESS.MYD的数据库恢复效果不如对ibdata1文件的数据库恢复。另外, 需要注意的是, 在MySQL数据库中存储的发送任务并不包含群发号码的IMSI信息, IMSI一般存储在“ send.data” “ OpenBTS.log” 和“ TMSI.db” 三个文件中。对“ 伪基站” 取证工作应该将提取发送任务和IMSI信息相结合, 才能得到更全面的检验结果。