首页
社区
课程
招聘
对某嵌入式设备声波配网的研究
发表于: 2023-12-5 00:05 11989

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

2023-12-5 00:05
11989

img

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

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

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

img

使用的是lngenic t20

芯片的官方网站:Ingenic-北京君正集成电路股份有限公司

音频功放为XPT4890:

img

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

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

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

img

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

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

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

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

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

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

img

转换代码:

代码:

效果:

img

代码:

效果:

img

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

img

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

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

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

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

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

img

wpa_supplicant.conf的格式如下:

img

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

img

在"ipcam"这个elf中可以看到如下内容:

img

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

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

img

img

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

img

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

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

遗憾的是,调试口被笔者焊坏掉了(QAQ):

img

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

所以暂时放弃对接收方的研究,去逆向一下发送方(app)的逻辑

对app进行解压,确定不是flutter架构:

img

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

img

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

img

通过frida dexdump脱壳试试:

img

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

img

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

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

img

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

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

img

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

img

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

img

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

img

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

img

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

img

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

img

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

img

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

img

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

img

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

img

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

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

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

img

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

img

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

更为夸张的是,笔者在项目的"main.c"里发现了如下内容:

img

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

img

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

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

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

img

img

只不过demo的baseFreq是16000,而app里的是4000:

img

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

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

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

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

img

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

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

img

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

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

img

hexChar是一个数组:

img

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

img


[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

最后于 2023-12-5 00:05 被Nameless_a编辑 ,原因:
收藏
免费 13
支持
分享
最新回复 (4)
雪    币: 3380
活跃值: (30966)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
2
感谢分享
2023-12-5 11:13
1
雪    币: 2395
活跃值: (5434)
能力值: ( LV10,RANK:160 )
在线值:
发帖
回帖
粉丝
3
感谢分享
2023-12-5 16:02
0
雪    币: 284
活跃值: (3649)
能力值: ( LV5,RANK:75 )
在线值:
发帖
回帖
粉丝
4
感谢分享
2023-12-6 09:54
0
雪    币: 26
能力值: ( LV1,RANK:0 )
在线值:
发帖
回帖
粉丝
5
感谢分享
2024-2-20 11:23
0
游客
登录 | 注册 方可回帖
返回
//