|
[原创]放个能用的 OD2.01_PLUG_SDK
http://bbs.pediy.com/showthread.php?t=141044 文章在这里。 |
|
[招聘]金山网络招反病毒技术研究员(珠海)(2012-12-13跟新)
吱个声。。干嘛要做分析。苦逼的职位。。 |
|
[建议]360做的太牛了,但还是哟个缺点!
杀软和病毒,就是在对抗中成长的,必然有能过杀软的病毒,也必然有被杀的毒。就看响应速度了。 |
|
[讨论]对秒杀360和QQ管家(等)的驱动代码的疑惑
ID 吧。。 HANDLE PsGetCurrentProcessId( VOID ); 内核的ProcessId都用HANDLE表示了。。。不清楚为啥。。 HANDLE 在x86,也是一个DWORD大小。 |
|
[讨论]对秒杀360和QQ管家(等)的驱动代码的疑惑
ring3能杀才有价值啊。。ring0能杀,很正常~ |
|
请问如何用od给类方法比如CWnd::Create下断点?
上IDA,能识别大部分的函数。然后导出map,用OD加载MAP,就清晰了。 或者OD也能加载lib,你弄个对于版本的mfc的lib进OD的LIB目录,就能解析出对应函数了。 |
|
[求助]想过掉patchguard,现在还有什么方法吗?
据说基本没戏,老实走微软的流程吧。你出来了,肯定微软就上补丁了。不适合用在产品里面~ |
|
[求助]关于KeServiceDescriptorTable的疑惑
KeServiceDescriptorTable 系统导出的一个变量。 |
|
|
|
[求助]求大牛编程一个大学选课辅助工具
抓包分析,然后发包就行了。一般简单了。。 |
|
[原创]量子计算机出现之前,越快越密就是对称加密王者(限磁盘数据)
最后,我看问题,都归结在,用户密钥存在弱口令,这个必须是个短板,所以不管你生成随机数,去扩充,还是使用HASH算法进行扩充,都没很少的解决这个问题。就像RAR的加密,已经很完善,但是如果你就输入个123当密码,也就是还会被破解。解决的方法,可以是在设定用户密码的时候,强制的要求密码的长度,要求最少是数字+字母。这个样的话,可以从源头解决问题。 |
|
[原创]量子计算机出现之前,越快越密就是对称加密王者(限磁盘数据)
拜读了楼主的文章,觉得楼主实在有些自大了。想了一下,还是觉得应该指出一些错误的地方。以下只是对技术做出评论: 1. 楼主说“原来AES加密膝上中箭”,先说下AES的密钥长度,AES分为(128bit|192bit|256bit)三种的密钥,如果需要更长的,可以扩充。就现在已经的攻击方法来说,仅仅能减少算法一半的强度,如果说以前的AES的最低强度是2^128的话,现在是2^127。不知道楼主说的是不是这个。 2. “现在流行的各种对称加密方法如:AES加密等等在加密磁盘数据时其源头密码就是用户输入的密码。”对于这句,我觉得楼主对密码学还不够了解,楼主有听说密钥分级管理体系么,有听过会话密钥么。AES只是一种加密算法,一定要使用用户输入的原始密码去做AES的密钥吗?我觉得一个成熟的产品是不会这么干的。一个成熟的产品,一定会有一个良好的密钥管理体系,会尽量的减少原始密钥的使用次数。一个简单的方法就是,每次加密用户的数据文件,都会生成一个会话密码,而用户输入的密码,只会用来对生成的会话密码进行加密。 3. “由于AES密文中验证密钥的信息是最后加密保存的,因此AES加密的强度(即破解计算量)与密文的长度接近正比关系”。这句话,更有着明显的漏洞。众所周知的,对于密码算法的攻击,有一种叫做“已知明文攻击”,简单的说,就是对于同一个密钥,存在很多的明密文对。所以要尽量的避免使用同一个密码去加密过多的数据,而应该使用会话密钥。对于用户输入的原始密码,应该尽量的少使用,尽量的加密更少的数据。而密文中,也没需要存放密钥的校验信息,任何对原始密码的记录,都是不应该的,不管是用HASH算法,还是加密存储,都应该避免。比较好的做法是对原始数据进行HASH,获得一个校验值,每次用输入的密码进行解密密文,得到明文后,再次进行hash,最后比较两个hash值。 4. “实际上经常会出现用户要加密保存非常短但极其重要的秘密例如银行账号和密码等,如果用AES直接加密这种信息,则生成的密文的加密强度非常低。。。(ps:略去若干字,去看原文吧)。。。由此可见采用AES来加密硬盘数据时是非常危险的做法”。不知道楼主,怎么得出的这个结论。我这里设想一个做法,我的银行卡密码比如是str1(6个数字),使用AES进行加密,使用的密码是key1,key1有大写+小写+数字+特殊字符构成。AES密码选最低强度128bit,也就是每轮加密数据128bit,因为AES是块加密算法,如果明文的长度不足一个块,需要补足128bit之后,才能加密。首先生成10随机数,对str1进行扩展,得到一个128bit的明文str2,SHA256(str2)得到hash1明文保存,计算str1长度len1,用输入的用户密钥加密str2得到en_hex。根据AES的描述,en_hex应该是128bit。解密的时候,得到用户密钥,解密en_hex得到str3,计算HASH256(str3)得到hash2,比较hash1和hash2,如果相同,根据len1去掉随机数,取得str1。根据楼主的思路,穷举密文,也就是需要穷举128bit的空间,大气点,我给你假设,我解密的步骤只要一条指令,给你i7处理器,楼主可以试试,能穷举出来么。后面一点,楼主好像想直接穷举明文,对于上面的例子,我对明文加了随机数,然后进行hash,虽然明文是纯数字,只有6位,但是因为没办法进行直接的校验,想穷举,相当于遍历128bit的str2。显然楼主也可以去试试。对于楼主说的弱口令问题,我还是比较认同的,纯小写,纯数字的密码,显然是不安全的,数字+字母,长度大于8,才能保证安全,如果能大写+小写+数字+特殊字符,我相信就足够强大了。而弱口令的问题,显然和加密算法本身是没有关联的。这个不能说明AES是不安全的。 5. “历来微软加密总是浮云” 。显然楼主有些不喜欢微软,其实微软的加密,走的肯定是标准的流程,而标准的流程,都是长时间的验证的。一般来说是安全的,排除弱口令的问题。而数据的安全,只会依赖密码和加密算法,和操作系统本身的防护是没多少关系的。 6. 最后,再说楼主发明的“越快越密”,下面是几个特点,我提取了下: 产生密钥的方式:“不仅采用用户输入的密码作为源头密码,还根据用户设置的加密强度,产生合适长度的随机密码添加到源头密码中,这样就增加了源头密码的长度,当用户设置的密钥解密时间设定时,预设解密机器的速度越快,添加到源头密码中的随机密码强度也越高。” 算法类型:分组加密(一大堆专利的东西) 密钥长度:密钥长度达到2048比特 说说密码产生方式吧,用户输入+随机数。这里的随机数,我没理解错的话,需要解密的时候再次生成一次。而且是相同的,这样才能解密。如果能再现的话,能称随机数么,只能称伪随机吧。等等,这里肯定是通过某种算法产生的。而产生算法,就在你的程序里面。我用AES,一般的做法是对密码进行一次MD5,正好满足AES 128bit的需求,然后设置AES的密钥,之后销毁MD5值。显然还有更好的方式,你可以参考RAR的密钥处理部分。再说说你的算法类型吧,AES结构已经证明是安全的了。你可以说你的算法比他安全(ps:现在还没证明,你能抵御多少种攻击)。但是我要说的是,AES目前来说,强度已经够了。再强,也只是浪费计算而已。所以AES的计算步骤,比起des来说复杂程度降低的不少(des的短板在于只有56bit的密钥长度)。越快越密密钥的长度,2048,显然比AES长很多,当穷举128成为不可能的时候,为啥要浪费去设计2048的算法呢?而且AES能扩充密钥长度。 最后,我只想说,楼主是来炫耀的,而不是来交流技术的。 |
操作理由
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 }}
勋章
兑换勋章
证书
证书查询 >
能力值