- 精华
- 阅读权限
- 60
- 好友
- 相册
- 分享
- 听众
- 收听
- 注册时间
- 2012-11-14
- 在线时间
- 小时
- 最后登录
- 1970-1-1
|
发表于 2013-11-19 10:45:31
|
显示全部楼层
我来简单翻译下，勿喷！
i'm using the client from the first post of the thread, but it's useless... too many differences we need the client for this specific version, it's taken this long just to get past the **ing login... when i log on an account with characters which exist, client crashes...
我试用了一下第一个提交的客户端，但是发现没什么用。这个客户端与我们需要的客户端之间有太多的不同点，当我用已存在的角色账户登录时，客户端崩溃了。。。
i'm done with this crap patching and hacking, i'll post what i've done to get this far for anyone interested;
我导出了崩溃的信息并进行分析，我将会把我已分析出来的东西共享给对这些有兴趣的人。
first login disconnect error after fixing client version is because the packet ids are wrong, client is sending requestauth server thinks it's sending something else
在修复了客户端版本后，出现的第一个登录连接不上的问题其根本原因是包的ids错误，客户端发送的是身份认证请求，而服务端不这么认为。
after fixing that the server thinks any account you try to login with doesn't exist, that's cuz the client is sending acc/pass in ANSI and the server wants it in unicode also the offset for the password is wrong, quick and dirty hack for this is to patch the sql query vwsprintf string to %S for our ANSI strings, and to fix the password offset ofc
在修复了那个问题后，碰到了另个问题，服务端认为任何试图登录的账户都是不存在的，这是因为客户度发送的账户、密码是以ansi格式发送，而服务端要求unicdoe，并且密码的位移不正确，简单暴力的修复方式是截取sql查询，将字符串改为unicdoe，并且修复密码位移。
Client version mismatch -> nop the checks at 0x14000E9D4 (lazy way but it works)
Disconnect login -> hook the function at 0x14000E7B0 if edx == 35 set edx to 39 and r9d to 1562
Next error is a bad login error -> write 0x51 to 0x14000EA8E and 0x14000EA93 then write 0x53 to 0x1400BCEAE and 0x1400BCEEE3
addresses from ida, work out the file offsets by subtracting base address i'm too lazy to
上面一段说的是使用工具修复相关问题的方式，里面涉及的知识太专业了，小白们还是等大神吧。。 |
|
楼主: My_Own_Step
[复制链接]
楼主
