我来吐个槽

其实只要加密狗公司提供了接口，那么，所谓的通讯加密算法就应该存在于动态库接口中呀，就好比上位机发：是你吗？被加密成XXX，（我们通过监听器看到的XXX，靠这是啥东西，不是你妈我还真不认识）下位机通过端口读到XXX，一定要解成是你码？才会认识，要不下位机不是要傻眼？？？能否被XXOO，得看加密狗公司的对手是谁？谁更有运气和耐心了。
分析通讯算法的手段我认为就是：自己写一个调用DLL的EXE（别用官方的静态版，有些使用了多线程，麻烦的要死），只执行简单的几个加密锁API，看看DLL中发向USB设备的数据都被怎么处理了。也就是在有输入值的API上下断，看看输入值在内存中怎么被蹂躏了（AV看多了）
也许加密锁的返回值解码算法和输入值加密算法不同，那么，需要中断CreateFileA先确定是要对锁进行操作，然后再中断ReadFile(使用USB中断端口进行读写），确定ReadFile操作的是CreateFileA中返回的锁句柄，这时的ReadFile的返回buff就是锁返回的密文，同样对这个buff进行内存中断……，如果加密锁动态库调用的是HID.DLL来与狗通讯，并采用的是特征报告方式（控制端口），那就在hid.dll的get_report中断，其实就是deviceIocontrol的inbuff和inbuffsize为0时的操作。看deviceIoControl有outbuff被怎么处理了。
同理，我们也可以采用先在锁API处中断，然后一路单步到WriteFile或deviceIoControl的outbuffsize为0时的地址，看看锁API的输入值是怎么变成这二个API的输入值的：）