-
-
[原创]Wibu Codemeter 7.3学习笔记——Codemeter API调用及通信协议
-
发表于: 2022-12-2 22:59
-
看完了回个贴呗，你们的关注是我更新的动力
求一个Wibu AxProtector的license，或者是一个能用的AxProtector，后续研究需要
0x00前言
Wibu Codemeter 是一个非常优秀的加密壳，论坛上讨论、研究的较少，只有少数帖子能够参考bluefish的wibu证书初探 ，德国威步CodeMeter通信协议中的漏洞分析 我斗胆记录一下我的学习历程，望请抛砖引玉，不吝赐教。
PS:因为wibu codemeter一直没有泄露的源码或者pdb，所以我对函数的命名就很玄学，大家多多包涵
0x01样品
Codemeter SDK(Axprotector)7.3 [下载]CodeMeter5.22 AxProtector 9.12下载 4楼5楼
Ap**s
Gas****
建议使用IDA Pro搭配FindCrypt ScyllaHide，ScyllaHide。ScyllaHide调成下面的选项就能过掉所有的反调试反跟踪手段。
IDA调试前会报一大堆错，直接设置成No Suspend Pass to application静默处理即可，不要试图这时候调试，容易跑飞
EXCEPTION_ILLEGAL_INSTRUCTION No Application Silent
EXCEPTION_ACCESS_VIOLATION No Application Log
EXCEPTION_WX86_BREAKPOINT No Application Log
MS_VC_EXCEPTION No Application Silent
0x02初步分析
Codemeter整体架构类似flexlm,rlm，都为server-client式的授权系统但破解难度上来说前者是后者的十倍甚至九倍。
Server Codemeter.exe(主要负责CmContainer即license的授权管理，为重点研究对象) CodemeterCC.exe CmWebAdmin.exe(为Codemeter.exe的图形化交互界面不重要)
Client wibucm32.dll wibucm64.dll(负责架起未用AxProtector加密的用户软件与Server间的桥梁，能被aheadlib的方式破掉)
被Axprotector保护的用户软件(直接与Server通信)
对于java，.Net，python则是通过WibuCmNET.dll，CodeMeter.jar等间接调用wibucm32(64).dll,大同小异不再赘述
下面贴一段从Ap**s中扒下来进行授权的代码，Ap**s本体调用wibucm64.dll中的函数来实现授权
从这段代码以及wibu官方提供的指南可知，wibu codemeter checkout时只是去服务器上查找是否有对应授权，但在客户端上却不进行检查，有也是软件服务商的自建算法。因此，我们需要重点照顾的对象便是CmAccess和CmGetInfo这两个函数。
0x03向CmAccess进发
WibuCm32(64).dll没有加壳所以分析还是比较快乐的，导出的CmAccess通过几层皮套Api到了真正做事的地方(Codemeter Api中所有函数，类型，结构体等都能在Codemeter/Devkit/include/CodeMeter.h中找到，可以稍微减轻点工作量)
通过分析，可以一眼丁真的分析可以发现整个cm_access函数中基本上都是参数，版本检查，错误处理的鸡毛蒜皮的小事，而cmacc这个重要的参数最终传进了send_cm_socket_req这个函数。
看一眼send_cm_socket_req的交叉引用，发现这个函数跟基本上所有的Cm API有一腿
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
最后于 2023-1-27 00:35
被ericyudatou编辑
，原因： 2022年12月4日更新，修正拼写错误 2022年12月7日更新，修正代码，补图
赞赏记录
参与人
雪币
留言
时间
mb_fdzmkugw
为你点赞~
2023-9-23 17:55
CanineTooth
为你点赞~
2023-4-1 12:53
伟叔叔
为你点赞~
2023-3-18 00:20
PLEBFE
为你点赞~
2023-1-10 14:26
Kingh413
为你点赞~
2022-12-29 10:18
jiavjiav
为你点赞~
2022-12-17 10:25
AEVE
为你点赞~
2022-12-8 10:58
tomtory
为你点赞~
2022-12-3 09:56
|
|||||||||
|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
0x07 send_cm_socket_Req初探二——参数协议
显而易见，需要重点分析buf的结构，从wibucm32.dll中可以通过调用以及编译残留的字符串可以发现各个Cm api调用send_cm_socket_Req的参数。初步分析如下（完整版见附件）:
通过归类可知，这些Cm Api分为三大类 1.超短型:不需要传递太多的参数，如CmGetVersion CmGetInfoExt CmRelease CmGetBoxes等 2.本地实现型:通过调用其他Cm Api或者直接本地解决，如CmCryptEcies CmCalculateDigest等 3.超长型:1.传递巨量参数 2.buf[9]=0 3.buf[1]~buf[8]={-1,0,0,0,0,-1,0,0}这个特定的开头 如CmGetContainerInfo CmGetAccountInfo CmWriteSettings 等 (黄色标出)，不是研究的重点 4.一般型:1.传递一定参数 2.buf[9]≠0 3.buf[1]~buf[8]={-1,0,0,0,0,-1,0,0}这个特定的开头 如CmAccess CmAccess2 CmGetInfo等，为研究重点 通过分析我们可以发现一些未公开的Cm Api如CmControl CmCreateLicenseFile等，其中CmControl非常值得我们分析研究(挖坑) 0x08 send_cm_socket_Req初探三——我们需要再深入一些send_cm_req_encrypt
分析可知send_cm_socket_Req的主要功能是判断服务器状态以及错误处理，实际上转发给send_cm_req_encrypt
最后于 2022-12-24 23:18
被ericyudatou编辑
，原因：
|
||||||||
|
|
0x09 通信协议初探 Codemeter在通信上除了使用一个私有的算法进行加密并与系统时间挂钩以外并没有别的门槛,只是一个简单的winsock通信框架，Wireshark能抓包。这里观察一下通信上的行为。
可以发现端口50777的客户端与端口22350的Codemeter服务器间的通信行为:
客户端对服务端的通信行为可以概括如下
但服务端对客户端的通信行为却有点不同
服务器对客户端倒像一个高冷御姐，没有了单独的握手包，但是却把握手包与数据杂合到一块。 服务器返回的数据包前16字节是跟客户端handshake_package的结构一样，后面就是长度为length的加密后的数据。 0x10 send_cm_req_encrypt,func_10_send_message, func_6_recv_telegram
对Codemeter的逆向的感受有别于flexlm，最突出也是最蛋疼的就是codemeter运用了大量的虚函数，虚表。使得有很多程序逻辑不能直接了当的呈现出来，而是必须通过动态调试才能知悉。
因为这个send_cm_req_encrypt很长所以直接呈上分析结果，验证后发现func_10_send_message,func_6_recv_telegram的逻辑与wireshark抓包的结果相符，可以认为分析是正确的 0x11 伪造服务端 通过调试可知encrypt_telegram,decrypt_telegram,expand_plaintext等加解密函数在服务端也被复用，因此我们可以通过对wibucm32.dll的魔改，导出这些重要的函数以减少工作量，不用复现那些加解密算法
通过实践发现只需要这两个函数笑ψ(｀∇´)ψ
最后于 2022-12-28 15:33
被ericyudatou编辑
，原因：
|
||||||||
|
|
0x11 伪造服务端 帖子被加精了，新人第一回，有点受宠若惊(❁´◡`❁) 记于2022年12月28日: 经过几天摸爬滚打，Fake server已经初见雏形。已经能够解密客户端发送的加密数据包了
简单的记录一下过程中遇到的问题和发现 1.让人摸不着头脑的错误 一开始通过GetProcAddress获得函数的地址进行访问，但总是离奇出错，出错原因各不相同。后来排查发现
这样编译出来的和这么编译出来的
生成出的汇编代码不同，前一种报错而后一种则正常运行。也算是涨经验了。 2.客户端对服务端的请求格式
举个例子
之后需要做的就是
附件为更新过的各个API所对应的API Code |
||||||||
|
|
|||||||||
|
|
|||||||||
|
|
超强的耐心和耐力，钦佩楼主
|
||||||||
|
|
|||||||||
|
|
|||||||||
