手游之u3d之dll文件加密之手动修复

时间:2024-03-13 20:08:59


文章标题不知道怎么取。。。 所需工具:010editor.NET Reflector 一款国外破解版的游戏,u3d引擎,想看修改了啥,但是无奈打开后是这样的

dll加密了,首先想到的是从内存中去抠出来,于是经过一番操作后从内存中扣出来,具体怎么从内存中,这里略过,不是本文重点,网上可以自己找找。使用反编译工具打开后还是这样

这么牛逼,不用解密就能执行的吗,
好吧,那对比下,

纳尼???内存中抠出来的和加密后的文件对比是一模一样的,说明它可能不需要解密就能执行,那就是可能是破坏了某些段导致反编译工具无法正确反编译,pe格式是这样的,某些段可以修改后不影响执行。如果dll文件被反编译修改后,和源文件是有差别的,文件大小,pe格式里面的各种段是会改变的,这就导致无法和原版做对比。
祭出文件万能打开工具010editor,还有pe格式模板下载:https://www.sweetscape.com/010editor/repository/templates/搜索:EXE.bt打开后:

明显缺了好多个段

下面就开始本文的重点了手动修复试试映入眼帘,一眼看出pe格式头部被破坏,pe格式标准头部:50 45 00 00每次改后,就重新执行一下模板,再使用.NET Reflector打开试试,如果能正确反编译就证明修改完成

解析错误证明有些段的偏移被破坏过了,导致模板无法正常跑通

指向OPTIONAL_HEADER32的大小是0xE0,但是这里只解析到0xA0,很明显就是错的。 接下来我们看OPTIONAL_HEADER32结构体,有几个很重要的信息

这里我们要验证下那个指向程序入口的地址,0x34484E,计算公式是0x34484E – 0x2000 +0x200 = 0x342A4E跳过去看一下,是对的,一般入口都是 FF 25开头
再来看下面几个段信息,都是错的有一点要知道,就是3个段都会是紧挨着的,也就是说一个段结束后,另一个段就接下去,比如text段是0 – 0x100,那下一个段就是0x100 – 0xxxxx,基于这点, 康康IMAGE_SECTION_HEADER段
上面的真实text段就是从0x200 – 0x342854这个区间0x342854 - 0x342A00区间用00补足,遵循对齐所以下一个区段真实地址就是0x342A00 + 0x200 = 0x342C00 下一个区段虚拟地址就是0x342A00 + 0x2000 = 0x344A00,这里的虚拟地址这样加过之后还不行,因为内存中的对齐值是0x2000,所以0x344A00还要再加,也是用00补足,加到0x2000的整数倍,最终下一个区段的虚拟地址就是0x346000
所以把下一个区段的VirtualAddress和PointerToRawData改过来,

再看看下一个段,是正确的 在运行一下模板,还是报错,那就肯定还有哪里有错,我们上面修复了段的指向问题了,再回去看看OPTIONAL_HEADER32结构体,这个结构体太重要了,包含了很多信息

上面导入表需要计算多次,跳转多次,是个指针就加加减减这里就不错描述了,因为这个地方我算过了,是没错的主要看Resource结构体,我们在上面已经修复过.rsrc结构体,这个就是对应Resource结构体,改成一样的

再执行一下模板,ok,成功跑通,没有报错,再使用.NET Reflector打开康康

成功,接下去再去导出所有cs文件和原版的对比,就能找出修改了哪里 文中使用到样本