某控车app的测试记录

序言

近期，在一项测试任务中遇到了一个控车app，想着能不能逆向一波实现远程控车的效果。由于涉及客户的保密信息，相关内容已打码。

测试过程

初探

首先，使用客户提供的账号密码登录app，查看app具体功能，抓取正常数据包简单进行数据分析。

app能使用账号密码进行登录，没有图形验证码，按道理应该可以进行账号密码爆破，但可惜账号和密码在发送到云端时会做加密处理，这个攻击点只能暂缓，需要逆向看看相关加密的逻辑。登录成功后，云端会返回一串JWT的身份令牌，为啥是JWT呢，因为它看起来就是JWT，相关内容我们放到下文详细介绍。现在我们可以进行控车尝试了，在控车界面先点击“鸣笛”，抓取数据包查看一下数据包构成。

nice，又是一个加密的参数，目前type类型指的应该是控车功能类型，serixxx目测可能是token令牌或者用于签名的数据，sign就不说了，目前看不出签名的生成方式，vehicleId应该是车辆标识。登录和控车的数据包里，关键参数都是经过加密处理的，需要使用JEB或者JADX对app进行逆向分析。两个工具都挺好，使用教程网上一搜那是直接的nice，任选其一就行。

逆向分析

控车数据包中，serixxx是由云端返回的数据，数据包和代码如下图所示。

上图中，云端返回的响应中，serixxx数据也是加密的，即图中的data字段。通过搜索请求的url，可以定位到这条响应的处理流程，即上图中的success函数，显然这里需要使用RSA私钥进行解密。要获取这个私钥，最简单的方式是Frida直接挂hook。我们的上一篇文章中已经介绍了不少基于Frida实现的功能，但是Frida的能力远远不限于此。Frida 可以通过在目标应用程序的函数上设置 hook 来实现对应用程序行为的监控和修改，这对于查找敏感信息、绕过安全措施或者修改应用程序逻辑非常有用。

回到主题，既然decrypt方法接受privateKey作为参数输入，那我们就hook该方法，在触发该方法后输出privateKey以及解密后的serixxx数据。

以上脚本不仅hook了decrypt方法，将之前的getSerixxx方法以及它的处理函数success一并hook，这样当app触发这个方法的同时我不仅能得到privateKey，还能得到云端返回的原始数据，方便于后续验证私钥的正确性。

运行app后，从Frida打印的信息中，可以看到原始数据、privateKey、serixxx，已经成功被我们获取。此外我们还可以编写一个python脚本，使用privateKey来解密云端响应的数据，方便后续直接发包实现控车功能。

除了serixxx数据外，远控数据包中还剩sign签名没有搞定，继续在源代码里搜寻，同样利用url的请求，可以快速定位到sign的计算方法。

doSign 方法接受三个参数：content（待签名内容）、charset（字符集，可选）、privateKey（私钥）。此时我们还是使用hook大法，看看到底是对什么内容进行签名，签名的密钥是什么。

通过输出的结果可以知道，该签名方法仅仅是对Serixxx和vehicleId进行签名，并且签名的privateKey和解密数据的privateKey是同一个（干得漂亮(⊙ω⊙)）。这里我们同样可以编写python脚本实现签名算法。

至此，所有参数的逻辑已经理清，我们便可以尝试伪造控车指令了。此时，肯定有大佬要问，即便是发送了伪造的控车指令，但是你的身份信息怎么伪造，身份信息伪造不了这个控车有啥意义呢，难不成让用户自己给你账号密码登录再进行控车。。。。。。。其实最开始我们登录的时候就发现该app进行登录的时候没有通过图形验证码进行校验，那就存在账号密码爆破的风险，虽然数据进行了加密，但是没有问题是逆向分析解决不了的~~~同样利用登录的url，可以定位到相关代码。

同样的套路，使用Frida hook关键函数拿到加密密钥进行爆破，这不就来了嘛，能不能成功就看运气！

JWT

抓取登录数据包时我们就发现云端返回的令牌是JWT了。JWT(JSON Web Tokens)是一个应用层消息保护开放标准(RFC 7519)，规定了一种Token实现方式，采用JSON格式。它在近年来被广泛应用于各种认证机制中，但也存在被误用的风险及由此产生的安全问题。JWT本质上是一个字符串，分为三个部分:

（1）Header: 存放Token类型和加密的方法

（2）Payload: 包含一些用户身份信息.

（3）Signature: 签名是将前面的Header,Payload信息以及一个密钥组合起来并使用Header中的算法进行加密

JWT是一种非常复杂的机制，包含JWT、JWS、JWE、JWK、多种密码算法、两种不同的编码方式（或者说序列化）、压缩、可能采用不止一种签名、对多个收件人的加密······其中各个部分出问题都可能导致漏洞产生。

（1）Header部分

是否支持修改算法为none/对称加密算法

是否可以删除签名

插入错误信息

kid字段是否有SQL注入/命令注入/目录遍历

jwk元素是否可信是否强制使用白名单上的加密算法

（2）Payload部分

是否存在敏感信息检查过期策略，比如 exp, iat

（3）Signature部分

检查是否强制检查签名

密钥是否可以爆破（如HMAC)

是否可以通过其他方式拿到密钥

采用了自身存在脆弱性的算法（如ECDH-ES）签名方法之间是否存在冲突

（4）其他

重放

通过匹配校验的时间做时间攻击

修改算法非对称算法为对称算法（如修改RS256为HS256）

弱密钥破解不安全的配置所导致的敏感信息泄露（如在报错信息中泄露签名）

所以说能实现控车的攻击路径是很多的，当然本次就不一一展示了。

总结

在当前智能网联汽车领域，随着网络技术的不断演进，安全环境的复杂性也在不断提升。网络连接的便利性使得攻击威胁面日益扩大，从个体移动终端的安全性到更广泛的信号干扰、拦截和伪基站等威胁，都对汽车安全构成潜在威胁。因此，我们迫切需要共同努力，不断创新，以共同打造一个更加安全可靠的智能汽车环境。这需要全体同仁的不懈奋斗，共同为构建安全的汽车网络生态贡献力量。