0%

问题

写了一个TUN设备适配以太网的小程序,大概就是应答ARP/NDP、IP路由、对传出包插入以太头、对传入到帧摘掉以太头,用到libpcap来捕包和注入包。粗略实现后发现带宽上不去,Speedtest只有可怜的2Mbps。抓包后发现有大量TCP重传,且libpcap从以太网接口捕获的包中,有部分长度远大于接口MTU,将这部分包直接摘掉以太头塞进TUN会造成丢包。

这个国庆最大收获是完成了家里的IPv6部署,但问题随之而来。

由于家里的网络划分了多个VLAN,每个VLAN有自己的IPv6前缀,需要在各自网段配置路由通告(Router Advertisement,RA)。

偶然发现Trunk口上的虚拟机(VM)会获取到来自其他VLAN的RA包,SLAAC会出现其他网段的IPv6地址,这下乱套了。

小时候用ADSL宽带的时候依旧是公网IP,动态域名、端口映射之类的小玩意玩得不亦乐乎。但随着IPv4地址枯竭,ISPs纷纷把用户拨号后分配的IP地址转为内网地址,通过Carrier-grade NAT的方式实现互联网访问。虽然解决了世界性的难题,但作为不折腾不舒服斯基,没有公网IP就意味着互联是不可能互联的,这辈子都不可能互联的…
此时,神器n2n的出现带来了希望之光 :-))) 真香!(逃)

新版天翼校园为了防破解可谓是煞费苦心…pc端主程序vmp加壳、apk用加固宝保护,连通信协议也换了,内容从明文变成了加密(编码)后的十六进制串…不过还是成功解决掉了~并且根据协议写了一个客户端(登陆器)
EsDialer:https://github.com/claw6148/EsDialerGD
本文主要描述通信协议的登陆部分。

项目地址:https://github.com/claw6148/macos-inline-hook

与x86架构相比,x64架构提供了更广的寻址范围。但在X64中,JMP/CALL<相对地址>也只能跳转到RIP前后2GB的地址中,因此在实现X64 Inline Hook时,直接套用x86的相对地址转移并非完全适用。因为若被Hook函数(TargetFunc)与自己的函数(MyFunc)地址相隔小于2GB,则相对地址转移仍然可用,而且只需改写TargetFunc头部5字节;若大于2GB,那么相对地址转移便不再适用。使用绝对地址转移则可以无视4GB寻址范围限制,但需要改写TargetFunc头部12字节以上,这要求函数的长度必须大于等于12字节,存在局限。