Java ULC厚客户端通信协议识别及流量篡改测试问询

首先，你遇到的通信协议是ULC Binary Protocol——这是Eclipse ULC（Ultra Light Client）框架专属的自定义二进制协议，它依托HTTP的GET/POST传输，但载荷格式是ULC团队自行设计的，并非标准Java序列化（所以没有传统Java序列化的\xac\xde起始魔数）。

关于协议文档与标准 #

这个协议没有对应的RFC文档，属于框架私有协议，只有ULC官方的开发者文档（内部或付费文档）会有详细说明，黑盒场景下只能通过逆向分析载荷结构来理解它的规则。

实时篡改流量做SQL注入的可行思路 #

既然你已经能完成解压、二进制转十六进制再转ASCII的解析，接下来可以按以下步骤实现篡改：

• 定位业务字段的位置与格式：先抓取几次正常登录请求，对比不同用户名对应的载荷差异，找到用户名在二进制流中的偏移位置、长度规则。那些空字节和不可打印字符大概率是协议的元数据（比如字段类型标记、长度值、分隔符），你需要区分开元数据和业务明文的边界。
• 构造适配的注入语句：如果用户名字段是固定长度，要确保注入语句的长度和原用户名一致，不足的部分用空格、空字节或者合法字符填充；如果是可变长度，记得同步修改载荷中对应的长度标记字段（通常是几个字节的数值，可能需要转成十六进制调整）。
• 重新打包载荷：把修改后的ASCII注入语句转回十六进制、再转二进制，用和原请求相同的压缩算法（比如GZIP）重新压缩，然后通过代理替换原请求的载荷后发送。
• 验证注入效果：利用服务器返回的“用户名或密码错误”作为基准，若返回包含数据库语法错误、权限异常等非标准错误信息，就说明注入触发了数据库层面的响应，存在注入风险。

最后提醒一下：ULC的二进制协议可能包含校验字段（比如简单的CRC校验），如果篡改后服务器无响应或返回解析错误，大概率是忽略了校验逻辑，需要进一步逆向找出校验规则并同步修改校验值。

内容的提问来源于stack exchange，提问作者poule