谷歌ai听译（逆向集成在谷歌语音程序中的OBi200固件）
谷歌ai听译（逆向集成在谷歌语音程序中的OBi200固件）通过文件系统，我能够更多地了解设备的底层实现。这里查看/etc/passwd文件，内容如下：通过扫描结果可以看到，该固件包含几个Squashfs文件镜像以及一个ARM文件镜像。看来一切都有希望进行进一步探索 因此我把他们导出到我本地文件系统里进行研究。由Obihai公司出品的OBi200是一个和谷歌语音集成在一起的家庭VoIP网关。它支持大多数标准VoIP功能，并且可以与几乎任何“便携式”SIP服务集成。我今年早些时候购买了一台，作为我家里的座机（无月租），到目前为止，运转的相当不错。但在完全安装之前，我决定深入了解它的工作原理。固件分析我插入设备并打开了Web界面。我做的第一件事是检查刷入的固件版本：
译者：hacker2017
预估稿费：100RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
由Obihai公司出品的OBi200是一个和谷歌语音集成在一起的家庭VoIP网关。它支持大多数标准VoIP功能，并且可以与几乎任何“便携式”SIP服务集成。我今年早些时候购买了一台，作为我家里的座机（无月租），到目前为止，运转的相当不错。但在完全安装之前，我决定深入了解它的工作原理。
固件分析
我插入设备并打开了Web界面。我做的第一件事是检查刷入的固件版本：
通过扫描结果可以看到，该固件包含几个Squashfs文件镜像以及一个ARM文件镜像。看来一切都有希望进行进一步探索 因此我把他们导出到我本地文件系统里进行研究。
通过文件系统，我能够更多地了解设备的底层实现。这里查看/etc/passwd文件，内容如下：
如上所示，root账户并没有被设置密码。启动脚本/etc/rc也包含一些有趣的信息，如下:
/bin/swcfg -pw 0 0 0 0x3800
hostname OBi202
#hostname FFxAV
mount -t proc proc /proc
# Create /var on RAM disk
mount -t ramfs none /var
mkdir /var/lib
mkdir /var/run
mkdir /var/log
mkdir /var/ppp
mkdir /var/tmp
cp -p /etc/ppp.ori/* /var/ppp
touch /var/tmp/resolv.conf
#
#mount -t squashfs /dev/mtdblock7 /obi
# Making the /etc directory point to MTD4
# mount -t jffs2 /dev/mtdblock4 /etc -o sync
# Making the /etc directory point to MTD4
# mount -t jffs2 /dev/mtdblock4 /scratch -o sync
# gateway begin
mount -t sysfs none /sys
mkdir /var/run/ppp -p # needed by pppd
mkdir /var/log/ppp -p
mkdir /var/lock # needed by wvdial
#echo "******** Start udev"
mount -n -t tmpfs -o mode=0755 udev /dev
cp -a -f /dev0/* /dev
# It's all over netlink now
if [ -e /proc/sys/kernel/hotplug ]; then
echo "" > /proc/sys/kernel/hotplug
fi
#udevd --daemon
#echo "start monitor"
#udevadm monitor -e >/dev/.udev.log &
#UDEV_MONITOR_PID=$!
#echo "start trigger"
#udevadm trigger
#echo "start settle"
#udevadm settle
#kill $UDEV_MONITOR_PID
mount -t tmpfs none /dev/shm -o size=512K
mount -t devpts none /dev/pts
#mknod -m 644 /dev/urandom c 1 9
#chown root /dev/urandom
echo "******** Start syslogd"
touch /var/log/messages
syslogd
# gateway end
# Start network device
cd /etc
#. ./rc.net &
. ./rc.net
cd /
echo "===> Obi <==="
cd /obi
#cd /usr/local/obi
./obi &
如上文件内容所示，被注释掉的一些调试/开发信息，泄露了设备的一些调试环境。在进行初始化设置后 脚本将目录切换到包含所有原始二进制文件的/obj/目录，并启动主obi脚本 (最终是obiapp二进制文件)。
弹出SHELL
通过搜索上面的文件名，我发现了去年有篇文章披露了Obihai公司OBi1000电话产品的一系列漏洞。由于在一个PoC中提到了obiapp二进制文件，并且在Obi200中找到了类似的URI结构，所以在两个产品中似乎有一些共同的代码。我测试了我的设备上的命令注入漏洞，并确认可以重新启动设备：
接下来，我尝试启动telnet守护程序，但是经过几次尝试，我发现端口23被设备专门阻止。我最终能够得到一个在另一个端口上运行telnetd的根shell：
其他的命令注入点
我很好奇是否还有其他类似的命令注入点，因此我决定继续深入探索一下。我用IDA反汇编了obiapp二进制文件，并找到了上述checkssid请求的关键点。在附近的地方，我发现了几个不同的请求：
然后得到其他的PoC如下:
请注意，上述第二个请求的格式略有不同，这是因为进程在把参数传递给system()函数前有解码操作。
继续Root
在新版固件中似乎修补了上面披露的漏洞 (后来我证实了) 不过我想在更新固件后继续研究，看是否能对设备进行Root。 我认为获得设备的控制台访问SHELL 是我最好的选择 因此我通过检索dmesg命令的返回数据来搜索串行接口:
如上图所示，有个串行接口/dev/ttyS0-------现在只需要在电路板上找到这个调试端口就可以了。
本文的第2部分 我将着重于描述识别和连接主板的UART引脚，以便通过控制台来访问设备。
