|
|
|
[讨论]RSA512大数分解速度GGNFS
猜想是 readyu 编译的,可向 readyu 或楼主寻求帮助;也可尝试自己编译。 |
|
[讨论]RSA512大数分解速度GGNFS
从#4楼的log看,大概是25天。这也只是个参考,具体的分解可能差异较大。 但请注意,楼主用了 readyu 的 AVX 版本,速度提高了1倍! Intel Core i7/i5/i3 的 Sandy Bridge (E), Ivy Bridge (E), Haswell (E),Broadwell (E) 支持 AVX 扩展。 Haswell (E),Broadwell (E) 还支持 AVX2。 |
|
[讨论]RSA512大数分解速度GGNFS
附件含 factmsieve.py 的两个版本: 1) version 0.83 2) use mpi for the Linear Algebra stage of msieve |
|
[原创]整数分解随笔(三)
不容易。谢谢分享! |
|
[求助]脱壳后,用OD无法调试程序,请教!
看了下,软件是几年前的。但小巧适用,功能也多。 脱壳 用我那个脚本“UPX完美脱壳脚本”就脱掉了,调试分析都没有问题。 注册算法 略显粗糙,简单地将用户名做一个RSA加密,再将加密结果编码为Base64,形成注册码。 不过这个Base64不是符合RFC 1521标准规范的字符集和序列。 所以会有黑名单比对,大概有几十个。 附件是替换RSA密钥后的主程序。从官方网站下载 Setup_MagicISO.exe 安装后,用附件的覆盖就可以用了。 [FONT="Courier"][COLOR="DarkOrange"]RegUserName[/COLOR]: bbs.pediy.com [COLOR="DarkOrange"]RegSerialKey[/COLOR]: uzNLn6Zx7SASnBeq6Kovz7y4EncRw5SyBFbi52ocMss9VkKq469AANRjD&PXwPkXqpgOW_rF5sIY9QamQWS&Bgiz2CfdF3McUVM0j9IsIiMVY1lfQ1HL9nCjeTF1wjwzwtpcDSuRLLzv7uydUDtBB_otQSZqaRt_79__uOX5Xa8[/FONT] |
|
求一加密算法,哪位大神能解决
不可能实现的。 这个帖的要求比楼主另一个帖“如何加密数字后让结果变短?”更加苛刻。 只需要记住一点,加密与解密中,输入与输出是一一对应的!或者说,输入数据空间与输出数据空间存在某种相互映射。 我们把问题简化一下:0~99共100个数,加密后只能用0~9这10个数来表示。 按“一一对应”的映射原则,可以设计一种算法来保证从100个数中按某种“规则”挑选10个数作为输入(明文),经过变换(加密)成为输出(密文);解密时走这个逆过程就好了。这肯定没有问题。 现在的命题是:这100个数全部都要用10个数来表示,这显然实现不了! 用个可能不太恰当的故事来讲这个问题,可能比空间映射更好理解。 在世界末日,地球即将毁灭,人类历经浩劫,仅存100个地球人。幸运的是,我们有“诺亚方舟”号飞船可以搭载10个人,到其他适于生命生存的星球重建家园。 我佛大慈大悲,欲普渡众生,希望100个人都能挤上飞船。但上帝造物,飞船仅允许10名乘客。 怎么办!?只能按上帝的意志从100个人中挑选出10个人,去为我们创造新世界。 |
|
[求助]如何加密数字后让结果变短?
非常不幸,我的结论过于武断,在开始写代码之前,就发现了这个错误:解密出问题了!。 就象4楼和6楼两位兄弟提到的,解密时出现一对多的情况。 加密和解密是一一对应的,或者说映射的。 就这个十进制的命题来说,可理解为:输出为15位数据集,不管你输入是多少位,也只能对应15位输入数据集,而现在明文数据集是16位,完整地包含了整个与密文数据集对应的输入数据集。 一对多成为必然,这是基本常识。所以楼主的命题恐怕无法实现! 下面分享一下我失败的教训,我认为也是有意义的,可以避免以后类似愚蠢的错误。 首先意识到,不能用对称加密算法,其结果长度无法控制。 我们知道,选取适当RSA的模N可以精准地控制输出的位数。 这个思路已经隐藏着错误,只是我还没意识到,依然继续着。如果谁能在这一时刻指出我的错误,那么他对RSA就有深刻的理解。 我从15位输出的最大值15个9开始,向下作分解(factoring)。这个最大值不能当作RSA的N来用,因为它不是两个质数的乘积。也不能向上分解,输出结果位数会超过15位。 找到离最大值最近的分解结果: [FONT="Courier"]P: 5 Q: 199999999999997 N: 999999999999985 E: 65537 D: 705506812945345[/FONT]在P和Q出来后,随便指定一个E,再计算D。E的选择对我们的实验结果没有影响。 然后用大数计算器作简单的验证。 先测试加密,完全没有问题,所有的16位输入必定是不超过15位的输出。 再测试解密,出问题了!怎么回不去呢?! 我们来看看RSA算法的公式,非常简单,比那些复杂的对称算法更容易理解。 [FONT="Courier"]加密: PT ^ E MOD N 解密: CT ^ D MOD N 这里:PT - PlainText 明文;CT - CipherText 密文[/FONT]很简单,是吧! 我忘记了最后是一个对N的取模运算!所以输出可以控制在15位之内。 下面是加密计算记录: [FONT="Courier"]Encrypting ========== Plaintext Ciphertext --------- ---------- 0 0 1 1 2 232688612375957 3 153875846496713 15 754708694258465 <- *** 149 451197539489329 <- *** 999999999999983 767311387624028 999999999999984 999999999999984 999999999999985 0 N*1+0 999999999999986 1 N*1+1 999999999999987 232688612375957 N*1+2 999999999999988 153875846496713 999999999999989 181304566607584 999999999999990 286328491331895 999999999999991 449231078721781 999999999999992 572836376551517 999999999999993 623394115778033 999999999999994 337601761830569 999999999999995 878876095224315 999999999999996 997814104863221 999999999999997 91685321778322 999999999999998 212292800531143 999999999999999 682231106350444 1000000000000000 754708694258465 N*1+15 1000000000000001 356296434408516 1000000000000002 348411433004192 ... 1999999999999985 754708694258465 N*2+15 2000000000000119 451197539489329 N*2+149 ... 2999999999999970 754708694258465 N*3+15 3999999999999955 754708694258465 N*4+15 4999999999999940 754708694258465 N*5+15 5999999999999925 754708694258465 N*6+15 6999999999999910 754708694258465 N*7+15 7999999999999895 754708694258465 N*8+15 8999999999999880 754708694258465 N*9+15 9999999999999865 754708694258465 N*10+15 ... 9999999999999999 451197539489329 N*10+149[/FONT]显然,输入在大于等于N后,输出开始重复了。对比一下数据集的关系: [FONT="Courier"]16位明文数据集: 0 ~ 9999999999999999 子集 A: 0 ~ 999999999999984 B: 999999999999985 ~ 1999999999999969 N*1 C: 1999999999999970 ~ 2999999999999954 N*2 D: 2999999999999955 ~ 3999999999999939 N*3 E: 3999999999999940 ~ 4999999999999924 N*4 F: 4999999999999925 ~ 5999999999999909 N*5 G: 5999999999999910 ~ 6999999999999894 N*6 H: 6999999999999895 ~ 7999999999999879 N*7 I: 7999999999999880 ~ 8999999999999864 N*8 J: 8999999999999865 ~ 9999999999999849 N*9 K: 9999999999999850 ~ 9999999999999999 N*10 15位密文数据集: 0 ~ 999999999999999[/FONT]也就是说15位内的密文可完整对应于16位输入中的A~J子集,部分对应K子集。大致是一对十的关系,凭常识也可以理解。 除非在解密时,特别指定要还原的子集A~J中的一个,否则解密不能完成。 实际上,在输入超过N后,应进行“分组加密”,即将输入分成n个N块,最后一个不足N位的块做必要的PADDING,再进行n次RSA加密;解密时就可以保证一一对应。 这种情况下十进制的密文可能将远远长于15位,大部分会是15的倍数。 十六进制时,我通常会意识到这点;十进制时怎么就糊涂了呢,惭愧惭愧。 所以,在这个命题中,无论是加密算法还是压缩算法,都会遇到一对多的问题,应该是无解。欢迎讨论、指正。 教训是,数字游戏中,没有扎实的基础知识,瞎折腾是不可取的,应设置一个“止损点”,力所能及,适可而止。 君不见,一个大数分解另无数英雄尽折腰。与诸君共勉! PS:php中要使用RSA算法,将 php.ini 文件里 "Dynamic Extensions" 节的 extension=php_gmp.dll 启用就可以了。 |
|
[求助]如何加密数字后让结果变短?
有意思! 题目的难点在第三条:1) 纯数字;2) 输入小于等于16位,输出最多15位。 一个16字节数字字符串对应于8字节十六进制的数据,按第二条要求,应该是用对称加密算法。64Bits的块最为常用,有多种Block Cipher算法可选。 但是结果是十六进制的,转换成十进制,长度又不能满足要求。 理论上,低进制向高进制转换,输出长度缩短;反之则增长。比如,这里在对称算法加密后,再做Base64的编码,长度肯定满足要求,但字符集是个问题。 所以加密后需要有个压缩。上面提到了哈夫曼编码(Huffman Coding),很多压缩算法都基于它,进行优化、形成分枝。 其基本原理,就是先扫描数据流,生成“字典”,再编码。 举个例子,这里限于“纯数字”的要求,不能使用二进制流。 例如,输入16位:1234567890123123, 可以压缩成15位:123456789009191。 编码解释: "123"在输入中出现三次,作为“字典”里的一个“单词”。这里,字典没有单独的存储区,直接保存在输出的最前面。单词也没有长度位,约定为3位。 编码结果中直到"90"都是原始输入,没有“压缩”发生。解压缩时,遇到"9",表明是一个压缩标志,"90"表示原始输入为"9";"91"表示取单词,进行替换。 例子是最理想的情况,而大多数情况下,受限于15位,结果中没办法保存单词的索引位、长度位、压缩标志位等等。 所以,压缩在这么短的位数要求下根本行不通,忘掉哈夫曼吧! 是不是无解了呢? 把楼主的三条要求,归纳为我一开始提到的两条,就有解! 需要写点小程序,再验证一下。数字游戏,“不疯魔不成活”,呵呵。 |
|
C++代码编译提示“_BYTE” : 未声明的标识符
_BYTE == unsigned char 参见 Visual Studio "Include\WinDef.h" [FONT="Courier"][COLOR="Blue"]typedef unsigned char[/COLOR] BYTE;[/FONT] |
|
请问这是什么什么加密算法?
是的,低级失误!signed 和 unsigned 是经常犯的错误。 算法是逆对了的,你对比一下 IDA F5 出来的结果。 简单看了下程序调用前面的代码,输入字符串前面的字母是固定的,数字部分是按 CPU 和 MAC 计算出来的。 不过,这个作者写代码存在很大的问题!一个简单的算法函数,几个设想都没实现。 致命的是,还存在一个缓冲区溢出的严重错误 - sprintf! 既然是用 Microsoft Visual C++ 9.0 - Visual Studio 2008 写的,为什么不用 snprintf 或更安全的 _snprintf_s 系列函数。 PS:查了一下,这个软件貌似以前某个数据恢复软件的翻版,不知是作者换了东家,还是自立门户了。 6楼附件已更新,就当送了个注册机。 |
|
请问这是什么什么加密算法?
就是一些自定义的变换,输出并不是固定长度的。 算法函数: [FONT=Courier]int Algo(char *pIn, char *pOut);[/FONT]输入字符串的长度 < 0x64,输出的buffer(含'\0')大小为0x64,否则函数返回false。 函数里有strlen,和两个API Calls: [FONT=Courier]0040346C Call MSVCRT.memset 00403567 Call MSVCRT.sprintf[/FONT]另外注意004034DE和00403512两处:某个常数imul/mul,shr/sar,这是Compiler将除法优化为乘法。 第一个接着还有个lea eax,dword ptr ds:[eax+eax*2],乘3,明显是取整!是这样子: [FONT=Courier]int i, j; j = i - i / 3 * 3;[/FONT]对比一下我附件里bin的代码: [FONT=Courier]00401143 |>\B8 56555555 |MOV EAX, 0x55555556 00401148 |. F7EB |IMUL EBX 0040114A |. 8BC2 |MOV EAX, EDX 0040114C |. C1E8 1F |SHR EAX, 0x1F 0040114F |. 03D0 |ADD EDX, EAX 00401151 |. 8BC3 |MOV EAX, EBX 00401153 |. 8D0C52 |LEA ECX, [EDX+EDX*2] 00401156 |. 2BC1 |SUB EAX, ECX 00401158 |. 83F8 02 |CMP EAX, 0x2 0040115B |. 75 13 |JNZ SHORT 00401170[/FONT]一模一样! 00403536处总是会跳,xor al,0xAB 成为摆设。 不要迷信IDA,你修改它反出来的代码,比理解后自己写,花的时间更多。 以下是其它测试结果: [FONT=Courier]Algo. for t200826 at bbs.pediy.com By MistHill, 26/05/2015 Input: ALFEIOEK1234567890 Output: 411228b8491345ec64243326355c9cb83995 Input: ALFEIOEK0000000000 Output: 411228b8491345eca003040300003040 Input: ALFEIOEK9999999999 Output: 411228b8491345ec443039ab397d8ad23914 Input: ABCDEFGH1111111111 Output: 41d75a22457b47661e90315d319fb4d431ae Input: 0123456789012345678901234567890123456789 Output: 30d060c0346036caac2c304032bc5090368038e0800321034c685038e03090e060342036cc00[/FONT]附件含Source和Bin。 Have fun! |
|
[讨论][求助]vmprotect小bug,如果是bug请帮反馈给作者
建议不要再浪费时间做这种无谓的实验了。 DllMain entry point (Windows) When the system starts or terminates a process or thread, it calls the entry-point function for each loaded DLL using the first thread of the process. The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions. 先不说被保护的Dll,就算是一个无壳Dll,设想下面这种最基本、普通的场景: Dll里的函数需要一块内存,保存这个Dll生命期间要用的数据。通常为方便,内存的请求和释放放在DllMain里。 LoadLibrary时,系统调用一次DllMain,这里你可以进行一些初始化的工作,比如申请内存,保存指针/句柄。 FreeLibrary时,系统再次调用DllMain,这次你得到清理的机会,释放内存、关闭句柄等等。 显然,FreeLibrary后,好多东西都不存在了,还要去访问,必定出问题。 对一个加壳的Dll,从DllEntry到DllMain/OEP之间的壳代码几乎可以肯定会有动态内存分配,用于保存VM运行时的数据,或者一些校验、标志信息,甚至VM的代码。 所以VMP的运行异常;SE的也时好时坏,不稳定,这个方案就没有实际意义了。 就好比一个婚姻,如果注定是要离的,那干吗要结呢!既然结了(LoadLibrary),就不要离(FreeLibrary),这样 Everybody Happy! 如果既想“在一起”,又不愿意“结”,就只能造成“事实”:自己实现LoadLibrary的过程。 无非就是把PE文件,展开成PE映像,应该可以找到现成的源代码,稳定性没什么好耽心的,而且与Dll是否加壳毫无关系。 |
|
[讨论][求助]vmprotect小bug,如果是bug请帮反馈给作者
你这种方法还真没试过。 如果要坚持这么做,可以把Dll里Form等GUI的东西移到Exe里,Dll只实现算法、资源等。 理论上,如果不FreeLibrary,肯定是可以的!你这个Dll又不是写的一个服务,可以用VMProtect自带的Delphi例子去确认。 模块都卸载了,仅恢复Dll Image Memory的代码和数据恐怕不行,这牵扯到系统的一些问题。 自己实现LoadLibrary就可以避免Dll卸载这一步,又达到“无模块”的目的。商用保护软件内部的Dll基本上都是这么处理的。 提醒一下,不知你“恢复”PE Header内存段没有!? 这个非常重要。一方面,运行时依赖里面的信息。另一方面,在任何一个VMP虚拟化的代码块内,都会进行随机内存校验,如果那张表里恰好包含这部分内容,而又没有“恢复”的话,随时会挂掉。 不清楚SE的保护机制,免费版可以,收费版也许就不行。 作为实验,还可试试Themida,用法很跟VMP一样的,map文件或marker都可以。 但是,你这种做法也只有CISC类型的VM可用,其它VM类型的代码和数据有部分不在Dll image的内存范围内,也需要保存、恢复,很麻烦的。 或者就用VMProtect的"DLL Box",Themida的XBundler功能,可能不符合你的期望。 |
|
[讨论][求助]vmprotect小bug,如果是bug请帮反馈给作者
MAP方式是首选,但问题似乎不在这里。 可能是Dll unload造成的,#13楼已经意识到这点。 设想一下,Dll载入时VMP在Process Heap申请一块空间,写入一些关键数据,比如Dll的Module Handle。 Dll卸载时,这块数据被释放掉了,回填的代码再去访问这些数据,必然出错,“无效指针”。可视为VMP的一种ANTI,而不是BUG! 以前在分析某个VMP保护Dll里的虚拟代码时,遇到过这种情况。 其实,“无模块”,你没必要兜这么大的圈子。 自己实现LoadLibrary: 按Dll的PE头+映像大小申请内存,再按PE头、各区段大小细分,复制头、各区段数据,重定位,Imports/Exports thunking,修改各区段内存属性,调用DllEntry。 大致过程就是这样,可以试试。 进一步,这些Project?.dll可全部放到xx.exe里。但是VMP保护的Dll有个文件校验,需要处理。 |
|
[讨论][求助]vmprotect小bug,如果是bug请帮反馈给作者
不明白“填回”的准确含义及为什么要这么做。 从原理上讲,Dll载入后,GetModuleHandle取基址,基址在这个进程中就是常量。 因为VMP在生成虚拟代时是基于PE文件头的"Image base",在模块载入后需要按实际地址进行修正。实际上,这就是“重定位”的含义,无论这个模块加密与否。 当VMP的虚拟代码执行,基址在VM初始化时放入某个VM寄存器。在这段VM代码要访问内存时,都要用保存在VM寄存器的基址进行“重定位”! 正常的模块,“重定位”在载入时只做一次;而VM后的代码,随时都要进行的!效率上肯定要作出牺牲,还有大量的垃圾虚拟代码。 这样看来,按理只要保证两次载入的基址相同就不会有问题。 “此时dll模块不存在的”,怀疑VMP取得的基址和现在的实际基址不同!你稍微跟一下就可以确认。 不知道你这个Dll是用那种方式载入的。通常,在Windows XP下Dll每次的基址是固定的;Windows 7以上,不作处理,每次肯定不同。 另外,还有IAT,显然与基址有关。 请检查报错的第3处代码,与前面2处成功的区别。我现在看到一个MessageBox,可能问题出在IAT上。 大家都知道,VMP的IAT是“加密”的,举个例子: [FONT="Courier"]; 模块基址:10000000。 ; 这个Call实际上是调用 7C80934A kernel32.GetTickCount(Windows XP),去除了垃圾指令。 1000EA74 E8 23CF4700 CALL 1048B99C ... 1046E66F B8 486C0110 MOV EAX, 10016C48 1046E674 FF7424 04 PUSH DWORD PTR [ESP+0x4] 1046E678 8B80 8C114400 MOV EAX, DWORD PTR [EAX+0x44118C] ; 10016C48+0044118C=10457DD4 [10457DD4] = 9D0186DE ... 1044021B 8D80 6C0C7FDF LEA EAX, DWORD PTR [EAX+0xDF7F0C6C] ; 9D0186DE+DF7F0C6C=7C80934A[/FONT] |
操作理由
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 }}
勋章
兑换勋章
证书
证书查询 >
能力值