Intro

现在网络上貌似没有，出于学习与兴趣，对某校园通信进行分析，仅供学习。

抓包工具

使用fiddler4，测试机使用代理连接并配置证书，此处不做讲解

登陆方式

某校园提供多种登陆方式，包括微信支付宝等。这里我们研究下密码登陆以及短信验证码登陆。

首先我们选择密码登陆，界面大概是这样子：

抓包分析

输入账号密码后，点击登陆，可以发现客户端发起了一个请求公钥的请求，并发送学校ID、设备ID、平台信息的webform的封装。然后服务端返回公钥与成功的json：

获取公钥后，客户端发起密码登陆的请求，内容包括账号信息(手机号)、经过加密后的密码、设备ID等。如果账号或密码错误，用户重新登陆客户端会重复发起公钥请求、登陆请求，并且公钥在一段时间内相同，超过有效时间会无效：

加密方式

此处的密码加密困扰了我一会。一开始将密码明文使用请求的公钥进行加密，发现不对(后来才知道RSA公钥加密会填充16位伪随机数)，怀疑加盐，尝试选择明文攻击，无果，于是对客户端APK进行逆向：

随后发现软件进行了加固与混淆，对于我这种逆向菜鸟来说太难了

还尝试了下网页工具反混淆，但是效果很差

密钥伪造

但是现在已知服务端响应的公钥为1024且为PKCS#1、PEM的格式，于是想到中间人的办法。先在

http://web.chacuo.net/netrsakeypair

生成一对自己的公钥，然后使用fiddler的bpu url命令对doLoginByPwd的请求下断点，点击登陆，请求就会停在有红色标记的session

因为fiddler是一个会话为一个单位的，所以点击之后赶紧选择释放到响应，再在下方的响应内容中将服务端返回的公钥替换成自己生成的公钥(客户端有几秒的超时)，然后释放响应

此时客户端就会发起密码登陆请求，且不出意外密码的密文应该是通过我们的公钥加密的。于是我尝试使用自己的密钥进行解密：

果然解密成功了！得到一串32位的哈希，大概率是MD5了，于是我对密码明文哈希，验证了我的猜想：

这个问题解决了，后面的就非常简单了

登陆方式变更

前面密码登陆请求后，服务端发现设备id更改，会响应设备已更换。此时APP切换到短信验证码登陆方式，然后会发起获取一个securityToken请求

获取成功后，客户端使用这个securityToken获取图片验证码的base64编码，并显示出来

用户输入图片验证码后，客户端再请求sendLoginVerificationCode，服务器返回操作成功。同时服务端发送短信到用户手机，用户输入短信验证码后请求doLoginByVerificationCode，成功后服务器会返回账户与个人信息，包括userID、uuToken等

至此登陆过程完毕

总结

如果不清楚数据处理过程，直接逆向或者其他方式可能成本太高，此时可以另辟蹊径，有几率能够大大减少工作量，或者让原本很难完成的工作变得非常简单，要学会猜测他人可能使用的技术，找到突破点