某图像处理软件带狗时正常运行效果如下。

无狗时显示异常。

查阅了相关HASP狗的资料，其解决思路主要有：

1.模拟狗（采用已有成熟的虚拟狗软件）；
2.破解系统时间；
3.模拟通信（自己Hook狗的相关函数，然后一一回应）；
4.破解狗的代码（难度大，工作量大）；

对此进行了一一测试：

Step 1： 第一次破解狗，通过资料查找下载各个软件测试皆失败，可能狗已经更新升级，以前的破解方法已被检测失效；
Step 2： 狗为测试狗，具有时效性，所以猜想可能通过获取系统时间进行判断是否失效，于是通过Hook时间函数来返回不失效时间，依然失败。
Step 3： Hook狗驱动的相关函数（CreateFile， WriteFile ， ReadFile ）。首先是打印这些函数的数据流，然后多次启动后，分析这些数据，然后尝试将数据一一会喂给ReadFile函数，依然失败，分析具体原因为每次启动软件，其通信的数据存在变化；
Step 4：此时，尚未分析程序内部代码，当然内部汇编代码依然非常复杂；最后尝试通过在汇编代码进行修改。通过PEID工具查看程序情况：exe文件及dll文件大部分为AKS加密，用OD加载发现伪OEP位置如下：

说明：开始以为程序的狗保护功能与使用的功能是一体的，必须要破解了狗才能使用，后来发现，狗保护只是一个外壳要破解，就必须完成OEP查找和IAT修复，后边所有的工作都是围绕此处展开。

1.寻找OEP。

插入狗运行，运行程序后，断下，查看主线程堆栈情况，可大致了解一些调用情况，然后重新运行，进行二次断点法断，找到了OPE。

后来查阅资料，发现有很多寻找OEP的方法，如：ESP定律、二次断点法、关键系统函数法等等，这些都是非常有意思的方法，但有时候会失效。

2.IAT修复
直接Dump，Dump后是无法直接运行的，由于dump的部分IAT未能指向正确，需要脚本修复，然后再手动修复（可以通过“ImportREC.exe”来修复），部分函数可以直接修复。

然而，并不是所有的函数都可以通过它直接修复，IAT指向有可能是未知的系统动态库空间或者指向的是一段动态分配内存代码空间，执行该代码才完成对系统函数的调用。

第一种情况，需要手动分析该函数，一般可以在内存地址向上回几行便可看见调用的系统函数，这主要前边push ebp 可能在之前就调用了；

第二种情况，需要手动分析该函数，可以对照分析猜测等方法。该软件在去壳的调用中我发现其为QT软件，通过对比对应版本的QT程序，完成部分未知函数的猜测修复，IAT修复后，程序就去掉了狗的保护壳，可不需要狗运行；

3.动态库修复

之后发现依然存在无法运行的问题，调试发现其存在了动态库中，这说明动态库也存在狗壳的保护。

dll破解与exe差不多，问题在于基地址定向问题。

找OEP(运行搜索 OEP / 查找关键跳转点断点 ) 硬件执行断电 -> Dump bin -> Fix Iat -> fix code (9090)，中间根据需要重定向。

C1 E8 1F F7 D0 83 E0 01 C7 45 FC FE FF FF FF EB 20

F7 D0 替换为nop nop（存在即修改）。

这个是QT运算的一个保护，通过测试修改后运行正常。

使用LoadLib 首先加载这些加壳对应动态库以防止重定向，下一步思路，通过对比2个不同基地址，的CODE找到重定向表制定通用型。

至此程序破解完成，可正常运行。

由于此为破解之后写的回忆录，无法截取部分过程图片，仅作为破解思路参考！