请大佬科普一下API调用时apphelp.dll代{过}{滤}理关键API的机制
本帖最后由 datochan 于 2021-7-13 11:01 编辑最近在分析一款软件的通信协议，调试之后才发现软件加了保护，查壳后发现是 VMProtect v3.00 - 3.3.4。
本能想放弃的我，又迷之自信的感觉带壳调试的时候保护强度并没有多高(至少IAT没改，代码没变形)。所以想着是不是能一劳永逸直接将壳脱掉，也省的每次都patch它的anti-debug了。
脱壳的过程比我预想的还要简单，找OEP，dump都异常顺利，直到修复IAT这一步，有一个API的调用无法修复，如下图:
此时，我的内心慌的一批，就在迷之自信之神将要离我而去之际，我理了一下思路，感觉可能的情况有如下两种:
[*]VMP在解密并回填IAT表的时候，对apphelp.dll做了hook来增加脱壳难度。
[*]此应用程序调用了apphelp中未公开的API。
论坛上找了好多资料，没见过VMP有第一种场景的骚操作(hook这种共用api的代价应该很大)。感觉第二种的可能性比较大。所以就跟踪apphelp.dll，看到底是啥未开放的API。
以为自己写一个dll来hook一下，间接到将此未公开的API导出，然后将主程序的导入表中引入我写的dll，将此IAT修复到我自己dll的导出函数上就可以万事大吉。
奈何我看到了下面的代码:
查询调用，看一下 EAX+9C 到底是个啥，于是来到了这里:
具体offset = 0x9C的位置，指向的是user32.dll的CallNextHookEx这个API，如下图:
因此未识别的IAT项修复为 user32.dll.CallNextHookEx，脱壳完毕，软件完美运行。
正在我洋洋得意的想怎么炫耀才能满足我变态的虚荣心之时，突然发现我这事儿它超出了我的认知范畴。因为这行为怎么看都不像是使用未公开的API，更不像是壳的行为。
所以好奇心驱使之下，我就重新加载了我修复好了的应用程序继续看这个IAT,如下图:
https://attach.52pojie.cn/forum/202107/13/101356j7bttirlbii7irlz.png
仍然不是直接调用的user32.dll下的CallNextHookEx，而是通过apphelp.dll代{过}{滤}理了一下。
这到底是为啥咧？是微软win系统新的什么保护机制吗？不知道哪位大神了解，能给我等小菜科普一下~
万分感谢~ 可以请教一个问题吗？就是rsa加密的参数，不懂解密的key能否通过什么思路进行解密吗？因为公密key我拿到了！现在私密是在服务器上的！不懂如何还原解密参数 tendy5800 发表于 2021-8-3 03:38
可以请教一个问题吗？就是rsa加密的参数，不懂解密的key能否通过什么思路进行解密吗？因为公密key我拿到了 ...
您好，我看您发帖数量不是新人了呀。问问题应该新起主题，直接在这个帖子底下问与主题不相关的问题很容易被人忽略掉的。毕竟看到的人太少了~
RSA加解密的原理网上有不少科普文章，您搜一下这类文章应该不难发现，这类对512位甚至2048位大整数做因式分解其计算量有多大。要想对这类数据解密，在数学上就已经可以被否定掉了。
因此这类加解密，一般不会单纯的从数据加解密的角度入手，而是看软件的整个验证流程是否有不完善的地方，是否能自己生成公私钥将软件总的公钥替换掉。是否能通过修改软件的验证通讯，用自己的私钥对数据加解密，从而绕过软件的整个验证流程。
以上只是我个人的思路，我的破解经验也不多。您可以发一篇主题出来，大家集思广益，说不定有更多的奇巧淫技呢。 datochan 发表于 2021-8-3 09:43
您好，我看您发帖数量不是新人了呀。问问题应该新起主题，直接在这个帖子底下问与主题不相关的问题很容易 ...
感谢你的回帖，谢谢，因为菜鸟，没有办法，看看能不能需求帮助！我现在是要一个软件试着跑半个月看看！能不能运气好！至于这个我不懂能不能解密出来！
页:
[1]