能否用 python 写一个软件授权工具？

这个我刚好开发完一整套验证，本地就不要想了（ 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"） ===>执行关键函数

MARK

@verydxz 话说好复杂的赶脚。完全云里雾里。

@verydxz 其实我只是要防君子不防小人那样。。。

@kingmo888 我做了软件逆向两年，遇到各种奇葩的破解方法，我这套算是能是能抗住一般破解者，强力的破解者可能会进行模拟服务端指令，证书欺骗，指令重放，弱密钥破解，总之破解这行只要能有人破一定扛不住

@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 。

@SlipStupig 沒有 security 的 background ，完全憑感覺亂說的哈，中文技術方面也說不溜，隨意看看就好

Mark

讲真，没有不会被破解的软件。

其实 me 觉得 楼上 say 的都 very 对

讲道理， 1 楼的方法虽然比较传统，但真应该好好断句

@missdeer 哈哈哈

@SlipStupig 所以你的安全性完全是靠那一个密钥来保护关键部分代码，那其实解密一次破解者就拿到关键代码了…

@SlipStupig
@alittletrain
https://zh.wikipedia.org/wiki/Denuvo
"她还称按照目前的加密技术趋势发展，两年后 PC 游戏将无法破解"

@SlipStupig 这方法不行了。早期的网络验证都是用这套，验证通过后传回来关键数据。

@billwsy 还可以找到关键性 Call 直接脱机都行，关键是你能不能找到？这块我只是打个比方，其实我可以绕更大的圈，这个就更麻烦了

@sallowdish 前提是你的公钥和私钥要 match 啊，我的 key 是客户端发出去的时候，每次 key 都是随机的，协议本身安全性我认为还行，如果证书欺骗做一个 fake 的客户端可以强制认证 cert

@crab 这个争议可能比较大，我自己也觉得客户端 SMC 不好，但是可以进行绕圈，不一定是关键数据 SMC ，但是不影响协议安全

Mark

参考 qq 的各种钻的验证.

一楼说的是不是证书认证大概过程？