对某嵌入式设备声波配网的研究

IoT 11个月前 admin

142 0 0

一

前言

在一年前笔者研究过一款嵌入式设备，当时就对其声波配网的逻辑感到十分新奇，但后面专注于漏洞挖掘就没有深入研究。

最近在研究一些诸如sub-ghz、蓝牙、射频等无线通信的东西，于是通过声波传递信息的方式又激发了我研究的兴趣，所以就有了这篇文章，简要记录一下我的一些发现和心得。

二

硬件分析

将主控芯片上的散热片去除后，我们可以通过放大镜读取主控芯片上的丝印：

使用的是lngenic t20

芯片的官方网站：Ingenic-北京君正集成电路股份有限公司（http://www.ingenic.com.cn/）

音频功放为XPT4890：

具体的音频接收是通过设备上的咪头，咪头接收到声波后产生电信号，然后主控芯片对电信号进行处理。

三

音频分析

首先采集一段配网时候的音频进行分析。

通过aux公对公线，能直接从手机的耳机孔输出音频到电脑上，通过windows自带的录音软件或者OBS就可以采集。

音频处理

查阅资料发现声波配网和声音的频率有很大关系，所以这一步主要是通过脚本提取声波的频率特征。

这里使用librosa这个库，但是它不支持m4a，只支持对wav进行处理，所以首先需要将m4a转换为wav。

m4a转wav

转换使用的是pydub这个库，它对音频的转换要安装FFmpeg：

Windows 10系统下安装FFmpeg教程详解_ffmpeg window10-CSDN博客

（https://blog.csdn.net/qq_43803367/article/details/110308401）

下载链接：https://www.gyan.dev/ffmpeg/builds/ffmpeg-release-essentials.zip

把bin目录添加到环境变量就行了：

转换代码：

import librosa
from pydub import AudioSegment
import matplotlib.pyplot as plt
import numpy as np
input_file = './声波配网信息.m4a'
output_file = './声波配网信息.wav'

# 将M4A文件转换为WAV格式
audio = AudioSegment.from_file(input_file, format='m4a')
audio.export(output_file, format='wav')

频谱生成

代码：

audio_path = './声波配网信息.wav'
audio_data, sample_rate = librosa.load(audio_path)

spectrogram = librosa.stft(audio_data)

plt.figure(figsize=(12, 8))
plt.title('Spectrogram')
plt.xlabel('Time')
plt.ylabel('Frequency')
plt.imshow(librosa.amplitude_to_db(abs(spectrogram), ref=np.max),
           origin='lower', aspect='auto', cmap='coolwarm')
plt.colorbar(format='%+2.0f dB')
plt.tight_layout()
plt.show()

效果：

提取频率数组

代码：

# 使用librosa进行频谱分析，并将能量值转换为分贝单位
spectrogram = librosa.amplitude_to_db(librosa.stft(audio_data), ref=np.max)

# 设置阈值，只记录强度大于-10dB的频率
threshold = -10

# 初始化空的频率数组
frequencies = []

# 遍历每个时间帧
for i in range(spectrogram.shape[1]):
    # 获取当前时间帧的能量值
    frame = spectrogram[:, i]
    # 获取强度大于阈值的频率索引
    freq_indices = np.where(frame > threshold)[0]
    # 将符合条件的频率添加到频率数组中
    frequencies.extend(freq_indices)

# 去除重复的频率，并按升序排列
frequencies = sorted(set(frequencies))

print(frequencies)

效果：

尝试特殊的wifi和密码

当wifi的名称是8个1，密码是32个1的情况。

发现有一部分和上面的图片是重叠的，而且这张图片的频率分布确实更平整了，说明确实和频率是有关系的。

但仍然看不出什么东西，需要具体逆向分析一下通信过程中传输协议是什么样的。

四

通信细节分析

通信概要

整个通信大体可以概括为：

设备配套的app将wifi的ssid和passwd通过声波这种媒介传递到设备中，设备接收到信息后连接上对应的wifi并访问运营商的云端服务器，并给予用户连接成功/失败的反馈。

接收方

在固件中能看到一个名为”connect_wifi.sh”的sh脚本，脚本主要的作用是通过wpa_supplicant.conf中的内容去连接wifi。

wpa_supplicant.conf的格式如下：

搜索存在”wpa_supplicant.conf”的elf可以发现有如下调用：

在”ipcam”这个elf中可以看到如下内容：

那么可以确定是ipcam这个elf对声波进行识别，并把内容保存到”wpa_supplicant.conf”中，然后在”daemon”中执行”connect_wifi.sh”连接wifi。

该函数会被当作参数传递到”vr_setRecognizerListener”中进行处理：

然后就到了c++的魅力时刻：

这里应该是某个结构体的虚表跳转，那么想继续从固件里看出东西的话就很困难了。

但其实可以看出有很多地方都有调试的打印，而且这个设备是有UART调试串口的，所以应该可以通过调试打印的信息定位后续处理的位置。

遗憾的是，调试口被笔者焊坏掉了（QAQ）：

而且从板子上飞线出来也不是很好飞。

所以暂时放弃对接收方的研究，去逆向一下发送方（app）的逻辑。

发送方app的逆向分析

app脱壳

对app进行解压，确定不是flutter架构：

Pkid查壳发现是《梆梆》加固：

用jadx直接打开也能看到比较明显的加固特征。

通过frida dexdump脱壳试试：

frida-dexdump -FU

能成功dump下来59个dex，并且每一个dex都可以通过JEB进行查看了：

定位关键dex

首先需要从59个dex中定位到哪些是我们需要的。

我们可以让app运行到声波配网的页面：

然后通过adb shell执行”dumpsys activity top | grep ACTIVITY”这行命令

就可以列出顶层的activity，也就是需要尤为关注的内容：

通过”Everthing”或者其它字符串搜索工具搜索”SoundWaveGuideActivity”，能够定位到如下dex。

用JEB对该dex进行简单的逆向可以知道整个流程应该是在”soundWaveGuide.control”中进行的。

首先输入的SSID和passwd会被分别存入this.F和this.G:

然后到下面这个地方会对传入的SSID和passwd进行处理然后通过”play”方法进行播放。

“play”和”encodeString”方法都不是在这个dex实现的，同样可以通过搜关键字符串的形式进行查找，最后在16.dex里找到了”play”方法的具体实现：

并且可以发现这里用的是一个原生库的函数：

直接检索”play”发现有很多的原生库都能匹配：

好在这个app在运行的时候会有一些关键的log，能够通过”adb logcat”进行打印获取：

通过搜索”play text”最终定位了具体的原生库文件：

对原生库文件进行分析

原生库文件一样是用c++写的，直接逆向分析也会遇到虚表跳转。

好在对于安卓有frida这种神器，可以打印具体的内存信息获取虚表跳转的地址。

但是要hook的地方实在是太多了，基本上是一步一hook非常麻烦。

好在app的开发者偷懒了，通过在github上搜原生库中的一个函数名”slg_gen”就能直接搜到一个名为”SmartBoy”的项目：

和原生库中的一模一样，而且其相关调用链也高度一致，也能在项目中搜到adb logcat的打印字符串：

项目地址：https://github.com/npnet/SmartBoy/tree/af0403fc7151f22381b0d0da7df3812f64ea5b3a

更为夸张的是，笔者在项目的”main.c”里发现了如下内容：

好家伙，直接不演了，黑盒测试变成白盒了。

CSDN链接：http://blog.csdn.net/softlgh

通过CSDN的链接我们能下载下来linux、windows、macos、android这几个主流平台的声波配网的全部demo，这里面显然就包括了android的源码

在源码里我们能看到熟悉的原生库，以及熟悉的代码。

只不过demo的baseFreq是16000，而app里的是4000：

至此，我们的逆向工作其实已经可以结束了，因为我们完成了逆向的最高境界——逆出源码（笑）。

后续的工作更多的就是对传输的协议（对ssid+passwd字符串的处理）的分析了。

五

协议分析

分析协议主要是分析”play”的字符串长啥样。

官方app提供了设备的日志，从日志里能看见对传入声波的解析后的内容：

主要是ssid psd phone这三个东西，猜测”play”的字符串就和这三个东西有关

在JEB反编译的java代码中可以看见这三个内容经过了两次处理：

第一次处理是对三个字符串的拼接，这里就不赘述。

第二次处理是对第一次拼接的字符串进行编码：

hexChar是一个数组：

在encodeData里会把传入的字符串分为8类：

在encodeType里对字符串的每一位分为4类：

其中is64Char其实是对前三个的汇总，然后多了”-“(45)和”“(95)，其实就是把”+/”换成”-“的base64字符串。

仔细分析encodeType可以做出如下归纳：

type0:全是数字(1111)
type1:前面是小写后面是数字（aa11）
type2:前面是除数字外的base64后面全是数字的(_A11)
type3:含有非base64的(@#$%)
type4:前面全是数字然后出现不是数字的base64的(11_a)
type5:全是小写(aaaa)
type6:只要是由base64组成的(a-_b)
type7:全是大写(AAAA)

看上去有些重叠，比如type6涵盖了除type3的所有。这是因为它返回的时候也是有先后顺序的：

对于8种不同的type的详细encode，感兴趣的师傅可以查阅一下csdn上的源码，这里挑两个比较有意思的。

首先是ssid和passwd全是数字的情况，通过下面这个js脚本可以打印encode前后的字符串（这里是对csdn上demo的hook）：

function hook_java(){
    
    Java.perform(function(){
        
        Java.use("voice.encoder.DataEncoder").encodeSSIDWiFi.implementation = function(ssid,wifi){
            console.log("java hooked");
            console.log(ssid);
            console.log(wifi);
            var enc = this.encodeSSIDWiFi(ssid,wifi);
            return enc;
        }
        Java.use("voice.encoder.DataEncoder").encodeData.implementation = function(a1,a2,a3){
            //console.log("encode hooked");
            let str = String.fromCharCode.apply(null, a1);
            console.log("string before encode:"+str);
            var enc = this.encodeData(a1,a2,a3);
            return enc;
        }
        
        Java.use("voice.encoder.VoicePlayer").play.overload('java.lang.String', 'int', 'int').implementation = function(a1,a2,a3){
            //console.log("play hooked");
            console.log("string after encode:"+a1);
            //console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new()));
            this.play(a1,a2,a3);
            return;
        }   
    });
}
hook_java();