这几天抽点时间内容整理了一下，一个月前拿来了一家安全厂商的SDP产品玩了一段时间，基本都是抽空玩一玩，因为最近的事情多了放了一段时间，后来想了想没挖到什么高危漏洞感觉又挺没劲，这周又抽几天时间看了一下挖了个命令注入还算有个交代，文中如晚辈有错误的地方不吝赐教。

    逆向分析是花了个把月时间，断断续续的抽时间和周末把客户端程序和服务端基本分析的差不多了，这里摘出流程性的东西，涉及商密的马赛克了毕竟是商业软件，遵守一下职业操守。

    下面客户端和服务端我用C-S来表示，C端主要的功能都在动态库里头，导出表大概45个函数，中间都是主程序通过loadlibrary和GetProcAddress得到动态链接库函数地址来调用函数

1、第一这里会抽取【userid(用户名);uuid(用户id);devtype(设备类型);authcod(验证码);devid(设备id);password(密码)】这6个条件进行加密。

2、第二步抽取系统环境信息，这里直接贴汇编把敏感字做了批量替换处理，懒得截图打马了。

    获取【cpu；bios；harddisk；os_version；ie_core；graphic_driver_version；sound_driver_version；run_memory；run_process_list；nic_mac；systemharddisk；ip_address；hostname；Vmware】通过UDP协议发送到S端，方便之后定时发现里头的数据发生改变后，就对用户进行重新身份验证。后面的就是S端处理是个linux系统，有个C++底层负责对C端的交互和日志记录，还有把传过来的UDP数据包转换成HTTP请求发送给java处理，业务层这块采用的是微服务架构spring cloud eureka，S端得话导出函数相对比较多了，1300多个(包括系统导出函数)。

    这里直接把认证auth写死在了HTTP当中，那控制器对网关的交互不需要校验了......

如果知道网关的地址任何一台机器可以都直接对网关操作了？

   解密的实现操作在jni里头，后续业务逻辑的操作在java端，jar的话用jd-gui就全部反编译出来了密钥啥的都在里头- -，java端采用了微服务架构就是先通过网关的端口转发到注册服务函数处理。

再跟到处理校验认证的类，看看实现。

经过securityTokenDecode函数，发现在另一个jar包。

通过jni调用了C，实现还是在C里，找到System.loadLibrary("xxx") 并反汇编：

调用了registerNativeMethods

函数原型：

JNI_Onload：

注册jni函数

通过注册函数和对应类解密函数：

jni函数表

之后解密后进数据库(使用了#{}来防SQL注入)：

根据逻辑返回相对应的status给C端，以上就是第一步身份验证的流程。

身份校验通过后进入第二流程，得到控制器IP和端口开始登陆。

请求数据包如下：

调试器附加进程:内容依旧带上了上面的用户名密码验证码信息外加了一个json ext字段包含了两个内容：codetoken,pubkey。

看看S端得处理逻辑，这里简单说一下流程，不贴代码了。

S端底层获取到数据后发送到相应得注册服务，服务函数里逻辑为：解密数据包、检测用户是否存在、检测codetoken是否为空、检查手机号、检查pubkey是否为空(key客户端生成，服务端不会去校验它的真实性)，一顿的逻辑检查通过后【uuid,userid,时间,设备类型,pubkey,clientype】入库，最后获取隧道的相关配置信息返还给C端.

隧道配置内容：

生成一个配置文件后创建隧道服务:

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