|
[原创]DLL生成头文件以及lib,开源
多一个成功的例子,ArmaGeddon的作者CondZero曾在"ArmaGeddon v1.0 – Conceptual overview on tool for unpacking Armadillo"里提到过。 附件:ArmaGeddon技术内幕 |
|
|
|
[原创]DLL生成头文件以及lib,开源
不好意思,泼冷水了:还是没有解决关键问题。 要成功调用第三方DLL里的导出函数,需要自己构建一个头文件(.h)和一个导入库文件(.lib)。 (A) 头文件 这个貌视没什么捷径,需要自己手工写。 分析dll各导出函数的输入参数和返回数据类型。视dll是由何种编程语言生成的,选择相应的分析工具效果较好,比如Delphi的用IDR。 通常利用IDA+Hex-Rays可生成C源码,再对比反汇编代码进行确认,那些不能确定的最好实际跟一下。 基本上IDA会猜错数据类型,特别是其为结构或类指针时。 (B) 导入库文件 有两个关键问题:导出符号(symbols,包括函数和数据)和调用约定(calling convention)。分两种情况来处理。 (a) 调用程序和dll使用相同的调用约定。 通常是两者都用同一编程语言和缺省调用约定时。 比如调用程序使用"__declspec(dllimport)"原形(prototype)和声明(declaration),dll使用"__declspec(dllexport)时,很简单。 在VC环境下,需要用到DUMPBIN.EXE和LIB.EXE。 写一个命令行批处理脚本,由DLL自动生成.def文件和.lib文件。forgot有个帖子dll2lib,我没法直接用,修改了一下(Dll2Lib.cmd)。.def文件很重要,情况(b)还会用到。 批处理脚本里生成.lib文件是这样的:
(b) 调用程序和dll使用不同的调用约定。 比如用C来写调用程序,而dll是用Delphi写的,我们知道Windef.h是将PASCAL定义为__stdcall的。直接用(a)的.lib就有问题,首先要解决符号问题,其次压栈参数不能得到清理(stack clean up),调用者必然崩溃。 解决办法说穿了很简单:根据(A)的头文件写一个同名Dummy DLL(DllFile.c)。 其函数声明部分用"__declspec(dllexport) return_type __stdcall funcname(...);"的形式; 为每一个导出函数写一个对应的Dummy Function,这些函数什么都不用做,只要保证传入参数的个数和类型、返回参数类型与.h头文件一致即可。 用以下命令:
即可创建DllFile.dll和DllFile.lib。使用命令之前,请注意备份或重命名你的原dll,如果同名存在会被覆盖! 新生成的Dummy DLL(DllFile.dll)是没用的,删掉。DllFile.lib才是我们需要的,它保证了导出符号和调用约定的正确。这里.def文件保证了.lib文件的ordinal与原dll一致,非常重要。 总之,楼主只解决了(B)(a)的问题,makeexport用批处理就搞定了。艰苦的工作在(A)! 谬误之处请指正! |
|
[求助]破解一个文件中的数据如何最快找到加密算法?
小主啊,看看你自己提的几个问题。 太笼统了,“高手”们无所适从,难以回答! 你已经把自己获得帮助的机会拒绝了。 不客气的说,是在浪费自己和其它人的时间、论坛资源。 发现这种帖子还不少,不吐不快。 请看《提问的智慧》,这会提高你帖子的回复率 |
|
[转帖]Armadillo Key Tool
v0.23 Alpha 24 We (Sigma and I) updated the tool to v0.23 Alpha 24 |
|
[原创]如何中断Themida的MessageBox对话框
偶然翻到这帖子,为了帮助那些不理解的人,忍不住废话几句。 我想楼主的本意是讲为什么在系统DLL的API地址处断不到想断的函数。 因为Themida/WinLicense对kernel32.dll、user32.dll和advapi32.dll进行了特别处理,所以断不下来。在其他保护软件中也可以看到类似方法。 至于示例代码就不要追究了,并不严谨!说穿了就是File Offset和VA的转换问题。 楼主用了:CreateFileA, VirtualAlloc, ReadFile;而YangCoCol更是“偷懒”:VirtualAlloc, memcpy。大家最关心的问题是:重定位,IAT等都没有处理,为什么它能跑起来? 那你需要想一想“重定位”到底发生了没有、IAT到底是Thunk还是Bind,就不难理解了。 Themida/WinLicense作为一个成熟的产品,可不能这样简单处理。 它用了三个API来载入文件映像:CreateFile,CreateFileMapping和MapViewOfFile,接下来完成必须做的初始化工作。剩下的各种转换等函数借用了"Matt Pietrek"的PEDUMP代码。 因为GetProcAddress不能用了,那么TMD/WL是怎么取得这三个系统DLL里API的地址呢?大概象这样(借用一下楼主的原型): FARPROC GetApiAddr(LPVOID lpFileImageBase, DWORD FuncNameHash, CHAR FuncNameFirstChar); 其中lpFileImageBase是DLL文件映像基址,在一个目标中可以断VirtualAlloc配合ImageSize得到,或者等目标跑起来后在"Memory Map"中按ImageSize很容易地找到。 FuncNameHash是它根据各API函数名计算的一个Hash,计算方法在各版本中基本相同。 FuncNameFirstChar是API函数名的第一个字符,用于限制搜索范围,缩短时间。 这样你可以自己生成一张对照表:FuncName, APIAddr, FuncNameHash 。断到你想断的任何一个API。我在以前关于WinLicense的帖子中曾经提过。 |
|
[原创]一道真正难倒亿人的智力题,这是微软的面试题
也就一Puzzle/Riddle,不知怎么转去转来变成“微软的面试题”了。“75道逻辑思维题”/“超难的75道逻辑思维题”满天飞。 wu :: forums - who is most possible to survive Posted: Jul 28th, 2004, 3:11pm I heard of this riddle from a friend. It's interesting. 这是我能找到的最早的出处,也许还可以追溯更早的。 提示的第二条其实很重要:每个人首先肯定是要先保证自己的性命,然后还要履行一项“义务”:想办法尽可能多地将其它人干掉! 囚徒们可能是数学家、逻辑学家,甚至是机器人、计算机,但必须严格遵守游戏规则。 |
|
[原创]关于rar密码破解的一点看法
一个菜鸟关于winrar密码无法秒破的研究结果 将明文的密码与Salt一起,通过HASH算法,生成两个16字节的密钥。(一个是KEY(AES算法的参数),一个是initVector) 看来楼主不太了解分组加密(Block Cipher)的工作原理。 从最后一组下手毫无意义:每一组的输入是前一组的输出。最后一组不是Block Size的倍数时有Padding,方法至少有5种。但这和破解一点关系也没有。 Hash就不用去管它了,如果知道Key和IV,就可以进行加密/解密,完全不需要“明文的密码”。 因此对winrar密码的攻击可视为对AES算法的攻击。 AES能够替代DES作为标准,说明至少它现在还是足够安全的。 如果说winrar密码能破,也只能说明WinRAR自身的漏洞或者用户密码太过简单。 |
|
PE文件获取原始为什么会是0??
加壳软件搞的鬼!典型的如VMP等。 它们被“挖”走了,放在壳的几个区段里,文件原来的位置就没有内容了,“原始大小”和“原始偏移”必然为0! 壳运行过程中,再“填”回去,解密/解压到对应的VA处。 注意PSFD00节(Executable),.axZ节(Readable&Writeable),.axL节和..idata节(Readable, Writeable&Executable)。 |
|
|
|
[建议]挑错
也报告一个Bug。 应该是vBulletin的bbcode转html的问题。 我习惯将源码或反汇编代码设置成"Courier New"字体,它与"宋体"一样都是等宽字符,这样可保证显示出来的文本对齐,不会乱。 编辑帖子时,正好有"Courier New"字体可选,但帖子发出来后显示的并不是这个字体。 这次才搞清楚了! 比如bbcode: [noparse]Courier New字体[/noparse] html变成: [noparse]<font face="Courier New">Courier New字体</font>[/noparse] 显然字体[noparse]"Courier New"[/noparse]是不存在的,浏览器只好用缺省字体来替代。(空格符号故意少一个“;”,否则这里显示不出来。) 下一句显示正确: [noparse]Courier 字体[/noparse] 为“vB 代码列表”页面的例子。可能后来有人改过反而出问题了。 估计含空格的字体名都有这个问题。 |
|
[求助]DES算法求助
当然测试过,只要算法正确,结果必然一致。 Keydll.dll可视为一个第三方DLL(a third-party .DLL)。正常情况下,Keydll.dll的开发者应该还提供一个头文件(.h)和一个导入库文件(.lib)给调用它的开发人员使用。 这样开发人员会方便一些,只需载入时动态连接(load-time dynamic linking)。同时也可很容易地修改为其他编程语言所用。 在没有.h和.lib的情况下,只能进行运行时动态连接(run-time dynamic linking)。上面的CallKeyDLL.exe就是使用这种方式,其实很简单,就三个API:LoadLibraryA,GetProcAddress和FreeLibrary。 前面说过,Keydll.dll没有解密函数,其他标准DES库又不能用。我得根据它的特定算法重写,事实上它也是遵循DES标准的,但没具体去研究到底是哪一步的差异导致与标准库的结果不同。 改写项目的结果:DesDll.dll,DesDll.h和DesDll.lib。但是DesDll.dll里面只有两个导出函数:DataEncrypt和DataDecrypt,如果楼主要调用原来Keydll.dll里的其他导出函数就有问题了。 进一步地,我在原来Keydll.dll导出函数DataEncrypt的基础上,为其手工增加了一个导出函数DataDecrypt。这个方案比较完美。 根据DES标准,"With DES it is possible to use the same function to encrypt or decrypt a block.",即原则上可用同一函数来加密和解密数据组,但需要少量修改。 经过程序"DLL Caller"第二版CallKeyDLLv2.c(运行时动态连接)测试加密/解密,修改后的Keydll.dll完全正常。 剩下的工作是需要为修改后的Keydll.dll生成Keydll.h和Keydll.lib。 打算写个帖子讲怎么在不增加区段/节(Section)的情况下,为Keydll.dll手工添加导出函数DataDecrypt的过程,这里面有些东西很有意思,应该对需要熟悉PE结构的人或新手有帮助。 但不清楚楼主这个东西的状况,需要沟通得到许可才能发。 |
|
[求助]word中rc4算法中的秒破?
希望这篇文章对你有用:关于微软公布的office二进制文档格式 在KSSD或这里 虽然是旧帖,但我相信从中不仅可了解到需要的知识,更可以学习当时会员们讨论问题的态度。 |
|
|
|
[求助]关于RC4算法的暴力破解问题
折腾数日,“独上高楼”,望不尽的“天涯路”。而“蓦然回首”,叹“却在灯火阑珊处”。 不是运气,也非偶然,乃缘于近在咫尺的必然。 密钥:"12345" (0x31, 0x32, 0x33, 0x34, 0x35) |
|
[下载]Exeinfo PE - ver 0.0.3.3 680 sign 测试版[多语言支持]
ver.0.0.3.4 Beta compiled , now I adding new signatures. New version detect Total Commander plugins and IE plugins Visual changes on new version : Information Only! 暂无下载。 已提醒作者"DFM - Delphi Form Scanner"应避免文章“eXeScope, XNResourceEditor & IDR 之Form中文显示补丁”里描述的问题。 |
|
[求助]关于RC4算法的暴力破解问题
RC4的算法虽然简单,但Ron Rivest的设计确实精巧。作为一种Stream Cipher,由本例最长的一组原文+密文很容易得到它的keystream: 原文(ANSI String): "你你你你" 原文(Hex): C4 E3 C4 E3 C4 E3 C4 E3 密文(Hex): 94 D6 FC 81 E8 FD C8 8C Keystream(Hex): 50 35 38 62 2C 1E 0C 6F Keystream是与原文无关的,由Key经KSA(key-scheduling algorithm)算法生成一个256字节的"State Array"(char S[256]),然后从中按PRGA(pseudo-random generation algorithm)算法挑选出特定字节构成加密/解密时的序列。 对一个特定的Key,S是确定的,PRGA产生的Keystream也就固定了。也就是说Key与S是一一对应的,从一个给定的S可以逆出Key。所以实践中要求每个Key只能使用一次,否则被认为是不安全的。 比如,就算不知道本例的Key,我们也可直接用Keystream来正确加密/解密字节数≤8的序列: 原文(ANSI String): "我我我我" 原文(Hex): CE D2 CE D2 CE D2 CE D2 密文(Hex): 9E E7 F6 B0 E2 CC C2 BD 显然这是危险的! 现在的问题在于Keystream太短,只有8字节,约束条件太少,很可能是多解。即很可能穷举出某个Key,但仅Keystream的前8个字节符合本例。 以一个RC4算法的具体实例来说明。 图中:Key="Secret",原文="Attack at dawn"。(取自http://en.wikipedia.org/wiki/RC4页面的"Test vectors"节。) Key对应的Keystream为: Keystream(Hex): 04 D4 6B 05 3C A8 7B 59 41 72 30 2A EC 9B ... 现在我们只知道"State Array"中的8个值,剩下的值不确定,同时还不能确定这些值在数组中的位置(idx)。那么Key就有相当的不确定性。 或许可以假定一个或几个值的位置而推算出其它值的位置,这个“假定”就已经带来了不确定性。 |
|
[求助]DES算法求助
楼主悬赏都卍了,竟然没人理!看来还需要提高赏金。 决定看看究竟是什么玩艺儿。 Keydll.dll是很古老的东西了,不知楼主从哪里翻出来的。 DES作为标准因为不够安全,已经被撤销。作为算法,DEA还是可以玩的。 DES的源码可以一抓一大把,从封装了又封装的到纯粹的Raw Source Code。 算法并不复杂,但要满足楼主的要求却不容易,虽说都遵循DES标准,但算法的具体实现却各显神通:用楼主的输入却得不到相同的输出。 不得不逆向它,进行仔细研究。结果是: 1) 用VC写了一个DLL Caller: CallKeyDLL.exe。它需要在相同文件夹下存在第一个附件"Keydll.rar"里的“原版”Keydll.dll。 2) 但是dll没有Decryption函数,又重写了个小东西,包含Encrypt/Decrypt两个函数。 PS: 楼主第二个附件"算法调用.rar"里的dll被人修改过。输出函数DataEncrypt里的LStrAddRef和LStrArrayClr调用被NOP掉了。 其中dyong.exe是用E写的,显然编写者不明白AnsiString在内存中的结构。不NOP掉,Caller会Crash。 CallKeyDLL.exe.7z |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值