RT ,在线授权验证。。。 或者本地验证。。
不过分强调安全性(防破解性)。
找了一下相关资料,没有 python 这方面的内容。都是什么软件加密狗之类的。
请问有这方面的资料或者 demo 可看吗?
1
SlipStupig 2016-07-06 21:31:20 +08:00 9
这个我刚好开发完一整套验证,本地就不要想了( python 本身可以完全解密出来,当然可以考虑加密,但是可以进行断点没什么意义), python 做个服务端,然后协议全程是加密。
简单说一下交互流程(稍微有点复杂,目前服务端还没出现协议破解)。 1.本地需要一个公钥服务器存储的是一个私钥(这样可以做到一机一 key ),客户端发起请求给服务端一条指令然后发送公钥给服务端验证,如果验证成功进入 ( 2 ),如果失败就返回错误 2.服务端返回一条指令询问客户端版本和支持的加密算法列表,客户端回应成功后进入 ( 3 ), 否则断开 3.服务端返回一个 salt 、 key 和加密算法,客户端使用 salt+key 并用协商的加密算法进行发送,发送几个东西: MAC 地址+激活 ID (如果有硬狗的话,应当验证硬狗的证书和 UID ),客户端证书(防止中间人),如果服务端解密成功后,验证信息是否正确,返回一个秘钥给客户端去恢复关键部分代码(这个地方有点傻 X ,但是对协议没影响),如果正确就走到 ( 4 ) 4.验证成功后给客户端一个 SessionID 和 cookies ( cookies 的秘钥在服务端存储),然后每 10s 客户端发送一个心跳,如果心跳超时 30s 就直接销毁掉 SessionID 和 Cookies , 图解: 1. C ---请求私钥---> S S <-----------验证证书是否正确-----------> C 2. C ===[‘ query ’, RC4|MD5|RSA|AES...]======》 S <=== [加密算法, salt, key] ===>C 3. C--->密码算法( salt+key , 要发送的数据内容)----> Server 4 . !Server 验证成功 | | =====>发送解密 key =====>client 解密函数(内存起始地址,内存结束地址,内存加密算法, "key") ===>执行关键函数 |
2
verydxz 2016-07-06 21:33:40 +08:00
MARK
|
5
SlipStupig 2016-07-07 02:27:09 +08:00
@kingmo888 我做了软件逆向两年,遇到各种奇葩的破解方法,我这套算是能是能抗住一般破解者,强力的破解者可能会进行模拟服务端指令,证书欺骗,指令重放,弱密钥破解,总之破解这行只要能有人破一定扛不住
|
6
sallowdish 2016-07-07 03:53:54 +08:00
@SlipStupig 感覺 encryption key 考傳輸不大靠譜啊,之前有看過 blackhat 一個 talk 是講 bluetooth 的,大致就是 competing 然後讓 server 以爲要重新 pair ,然後就可以 sniffer cert ,後面所有所有的交流都可以 decrypt 了。。。之前做的項目 mgr 是選擇用 pre-shared key 的說, server 和 client 都有一份,這樣就不用交換 key 了。。一對多的話可以再 server 上個 table ,然後每一個 copy 的 SN 是 id ,然後 server 端自己從 db query 相對應的 key 。
|
7
sallowdish 2016-07-07 03:55:44 +08:00
@SlipStupig 沒有 security 的 background ,完全憑感覺亂說的哈,中文技術方面也說不溜,隨意看看就好
|
8
darkbill 2016-07-07 08:27:51 +08:00
Mark
|
9
alittletrain 2016-07-07 08:46:49 +08:00
讲真,没有不会被破解的软件。
|
10
sxd 2016-07-07 08:55:05 +08:00
其实 me 觉得 楼上 say 的都 very 对
|
11
missdeer 2016-07-07 09:09:11 +08:00
讲道理, 1 楼的方法虽然比较传统,但真应该好好断句
|
13
billwsy 2016-07-07 09:19:30 +08:00 via iPhone
@SlipStupig 所以你的安全性完全是靠那一个密钥来保护关键部分代码,那其实解密一次破解者就拿到关键代码了…
|
14
clino 2016-07-07 09:28:35 +08:00
|
15
crab 2016-07-07 09:33:56 +08:00
@SlipStupig 这方法不行了。早期的网络验证都是用这套,验证通过后传回来关键数据。
|
16
SlipStupig 2016-07-07 09:41:22 +08:00
@billwsy 还可以找到关键性 Call 直接脱机都行,关键是你能不能找到?这块我只是打个比方,其实我可以绕更大的圈,这个就更麻烦了
@sallowdish 前提是你的公钥和私钥要 match 啊,我的 key 是客户端发出去的时候,每次 key 都是随机的,协议本身安全性我认为还行,如果证书欺骗做一个 fake 的客户端可以强制认证 cert |
17
SlipStupig 2016-07-07 09:44:38 +08:00
@crab 这个争议可能比较大,我自己也觉得客户端 SMC 不好,但是可以进行绕圈,不一定是关键数据 SMC ,但是不影响协议安全
|
18
chinafeng 2016-07-07 09:46:23 +08:00 via iPhone
Mark
|
19
wmhx 2016-07-07 11:42:34 +08:00
参考 qq 的各种钻的验证.
|
20
alqaz 2016-07-07 16:51:50 +08:00
一楼说的是不是证书认证大概过程?
|