二次开发

大约 6 分钟

二次开发

本章节列举希望对sekiro框架进行二次开发的指导和相关资源

源码列表

Sekio是一个半开源项目,其核心功能在github开源,同时有一个带有高级功能的收费分支是闭源发展。你可以根据本章节的引导了解Sekiro的所有组成部分。以及考量选择商业版还是开源版本。

源码仓库列表:

客户端sdk开发

Sekiro已经为多种语言提供了sdk,这些语言包括:Frida、Java(Xposed)、Objective-c(IOS)、js(web)、python、go、c#, 如果您的需求场景并不是上诉语言,则可能需要自行完成sekiro的sdk开发,才能进行sekiro服务接入。

sekiro核心是一个socket的网络程序,他运行sekiro定义的一个私有协议结构,并且依靠包结构编码使得单一tcp隧道可以并行传输多个业务负载session,你需要了解sekiro的二进制协议才能进行对应的sdk开发。

当你开发自己的sdk的时候,建议选择上述任何一门您熟悉的语言作为参考

报文结构

SekiroProtocol

magic

长度 8 byte; 魔数,固定值sekiro01,其中 01 代表协议版本号,目前是 01 版本。

total_leng(total_length)

长度 4 byte; total_leng 的值为数据包从 type 开始直到该数据包结束占用的字节数,不包括魔数占用字节数和 total_leng 占用字节数,即 total_leng 的值为整体数据包总长度减去 12。

type

长度 1 byte; 代表该数据包的类型

- 0x00 心跳包数据包
- 0x10 客户端向服务端注册 group 数据包
- 0x11 客户端向服务端响应数据包
- 0x20 服务端调用客户端数据包

seq_id

长度 4 byte; 该数据包序列号,唯一标示该次请求;由服务端下发请求时设置,客户端在响应该次请求时设置为相同值

header_size

长度 1 byte; 代表该次数据包中有多少个消息头,当前协议要求最大值不能超过127

key_len

长度 1 byte; 该消息头 key 的内容长度,

key

长度不固定,由 key_len 的值决定,该消息头的 key,当前协议要求最长不能超过 127 个字节;

value_len

长度 1 byte; 该消息头 value 的长度

value

长度不固定,由 value_len 的值决定;该消息头的 value,当前协议要求最长不能超过 127 个字节;

data

长度不固定,由 total_leng 的值减去从 type 开始到 data 之前占用的字节数决定;该次数据报的负载数据

注:1.消息头可以出现零个或多个,但最多不能超过 127 个消息头 2.消息头 key 和 value 的长度均不能超过 127 个字节

整体调用流程

为了方便描述,后续报文内容按照结构体的方式展示,具体实现时需要按照规则进行编码

心跳

客户端连接上 sekiro 服务器之后如果超过一定时间未进行读写,服务器会发送心跳包给该客户端,客户端在接受到心跳包时必须回应服务端一个数据包, 否则服务端将主动断开该连接。当前版本服务端发送的心跳包与客户端响应的心跳包一致,报文结构大致如下:

struct{
    magic: sekiro01
    total_leng: 6
    type: 0x00
    seq_id: -1
    header_size: 0 
}

该结构按照规则编码后就是一个心跳包,客户端在实现时如果发现 type 为 0x00,可将该包原样返回给服务端。

注册 group

客户端在连接上服务端后的第一件事向服务端注册 group,这样服务端才能下发相应 group 的请求。客户端注册 group 报文结构大致如下:

    magic: sekiro01
    total_leng: 50
    type: 0x10
    seq_id: -1
    header_size: 2
    SEKIRO_CLIENT_ID:12345678
    SEKIRO_GROUP: test

50(total_leng) = 1(type)+ 4(seq_id) + 1(header_size) + 1(key_length)+16("SEKIRO_CLIENT_ID")+1(value_length)+8("1234567") +1(key_length)+12("SEKIRO_GROUP")+1(value_length)+4("test") + 0(data) 上面展示了该数据报 total_leng 字段值的计算方式。这个数据包发送给服务端之后就标示该客户端的 clientId 为 12345678,group 为 test, 当服务器接受到 group 为 test 的请求任务时将会下发给该客户端

接受服务器请求

注册完成之后服务端在接受到任务之后会下发请求,请求报文格式大致如下:

    magic: sekiro01
    total_leng: ?
    type: 0x20
    seq_id: 1
    data: "{"action":"test","a":""b","c":"d"}"

https://sekiro.iinti.cn/business/invoke?group=test&action=test&a=b&c=d

在浏览器请求该地址,sekiro 客户端就会接收到上面的报文内容。tatal_leng ?代替,并非实际值。该次请求报文的 seq_id 为 1,那么接受到该请求后对该请求的响应报文 seq_id 也需要设置为 1。

响应 Json 格式

sekiro 商业版响应 Json 时为了服务器不做 Json 解析但需要感知业务是否成功,数据包中的负载数据 data 内容并不是简单的 Json 字符串,有自己的编码规则; 编码格式如下:

SekiroProtocol

  • status: 状态,占4个字节;0 代表成功,1 代表失败
  • msgLength: 占 4 字节,值表示附带信息字符串占用的字节数,为 0 代表没有 msg
  • msg:附带信息
  • stringLength, 占 4 字节,值表示后续字符串占用的字节数
  • json string: 需要返回给业务的 json 字符串

接受到请求后需要进行响应,响应报文结构大致如下:

    magic: sekiro01
    total_leng: ?
    type: 0x20
    seq_id: 1
    PAYLOAD_CONTENT_TYPE:CONTENT_TYPE_SEKIRO_FAST_JSON
    data: 按规则编码

响应 Json 需要加入 PAYLOAD_CONTENT_TYPE:CONTENT_TYPE_SEKIRO_FAST_JSON 消息头表明负载数据格式。

答问:netty的lib为什么会重新修改包名,然后源码引入

这是因为netty是一个很底层的、API表面积过大、API多版本一致性较差的lib库,从这个方向来说netty不是一个优良的lib设计,然而netty在网络编程上的深度和沉淀方面又是非常强悍的, 他也算是世界顶级的项目。

这导致存在大量的其他sdk或者中间件服务会依赖netty,此时我们很容易发现多个lib共同依赖了netty,但是又是依赖的不同的netty版本。 这会导致有很大可能存在依赖冲突(选择任何一个版本的netty,会导致另一个lib报错)。这是因为不同netty版本提供的api不兼容。

这是在工程实践上遇到过多次的现象,实际上在遇到这个问题的时候需要很有经验调整各种lib库的版本,或者做一些源码hack操作。

而sekiro的场景一般运行在受限环境,比如Xposed环境下可能出现代码和宿主环境的netty不一致,但是受限环境我们无法调整netty版本。此时可能是一个无解的现状, 故Sekiro在sdk设计的时候,变将netty的源码copy了一份出来,然后修改了其包结构。这样sekiro使用的netty就是一个私有的netty发行版本,他永远不会导致依赖冲突

上次编辑于:
贡献者: liguobao