看雪论坛
发新帖

[讨论] 已知密文和明文 如何快速有效的推出加解密算法

kimoh 2017-9-7 14:32 384

 明文 密文
 0000000 58E105C78856290B
 1111111 152D8639F768F7CE
 1111112 15DBBA5ED9085A0F
 111111 BC2107A18CA29D91
 11111111  F5BA0BD72243F02A6B6DA71AA6ACE7F7
 22222222 A9BA6E2E5CAA386BCE66FDE34DD0C5CD
 111111111111 F5BA0BD72243F02AB5A29C3BE102CF3C
 1111111111111 F5BA0BD72243F02AD921AA76E8DC23C5
 11111111111111 F5BA0BD72243F02A3198863A208F1D8A
 111111111111111 F5BA0BD72243F02AE133BDD49B682F21
 1111111111111111 F5BA0BD72243F02A09457372E3B2E978EF12C5B72A9EDE6A














初步推断加密过程:
1、第一段7位字符 转 二进制(56位)  然后每个字符间加1位变成64位  经过某种变化运算  再转成16进制
2、不满7位字符的补全7位  
3、第二段七位字符运算方式和第一段不一样
4、按照15位明文加密后的密文来看,我推断的第一条可能有误
5、根据16位明文加密后的密文来看,第二段可能是8位

以7个1为例
 
 15 2D 86 39 F7 68 F7 CE
 00010101 00101101 010000110 00111001 11110111 01101000 01111011111001110



 1
 00110001




大体思路应该没错,看了两三天没看出眉目,求助攻

稍微总结一下:
1、确定是可逆的加密算法,不是hash算法
     可逆的加密算法,长度肯定是随明文的长短变化的
     hash 一般不会随明文的长短变化
2、通过不同的明文长度,观察对应的密文长度,找出变化的临界点
    通过上面采集的样本, 就可以发现,我基本是逐位增加明文数量来观察密文长短变化的
3、通过对应的密文选取可能的加密算法
    这个需要一些经验,比如 yemoon 说的话,虽然短短一句,但是没有经验是无法具备这直觉的(题主欠缺啊...)
4、利用选取的加密算法,对先前样本中的明文进行加密,得到的密文与原有的密文进行综合比对
    既然有了有限的备全算法,就开始生成数据,可以验证想法了  


附:padding 的一些知识

常见的四种填充方式:

1) Zeros填充:全部填充为0的字节,结果如下:

      F1 F2 F3 F4 F5 F6 F7 F8//第一块

      F9 00 00 00 00 00 00 00 //第二块

2) X923 填充: 填充为0的字节序列,最后一个字节记录填充的总字节数,结果如下:

      F1 F2 F3 F4 F5 F6 F7 F8   //第一块

      F9 00 00 00 00 00 00 07 //第二块

2) PKCS7 填充: 每个填充的字节都记录了填充的总字节数,结果如下:

      F1 F2 F3 F4 F5 F6 F7 F8   //第一块

      F9 07 07 07 07 07 07 07 //第二块

3) ISO10126 填充: 填充随机字节序列,最后一个字节记录填充的总字节数,结果如下:

      F1 F2 F3 F4 F5 F6 F7 F8   //第一块

      F9 7D 2A 75 EF F8 EF 07 //第二块

参 http://laokaddk.blog.51cto.com/368606/461279/

PKCS#5以及PKCS#7的资料
参 http://blog.csdn.net/test1280/article/details/75268255





本主题帖已收到 0 次赞赏,累计¥0.00
最新回复 (9)
losegames 2017-9-7 14:36
2
自己逆向跟一次代码
或者用知名的加密演算法的特征先搜搜看内存有没有使用
yemoon 2017-9-7 14:48
3
这个感觉是  DES,padding用的应该是PKCS5/PKCS7,至于模式,如果22222222加密后的最后16个字符跟11111111加密后的最后16个字符是一样的话,就是ECB了
kimoh 2017-9-7 15:02
4
yemoon 这个感觉是 DES,padding用的应该是PKCS5/PKCS7,至于模式,如果22222222加密后的最后16个字符跟11111111加密后的最后16个字符是一样的话,就是ECB了
感谢回复,  22222222  密文  A9BA6E2E5CAA386BCE66FDE34DD0C5CD  ,之前的思路没考虑padding的差异,我再琢磨琢磨
kimoh 2017-9-7 15:04
5
losegames 自己逆向跟一次代码 或者用知名的加密演算法的特征先搜搜看内存有没有使用
可惜没有代码  是服务器端加解密的
yegu 2017-9-7 15:35
6
0000000     58E105C78856290B                6C6D3B17542AF600
1111111     152D8639F768F7CE                DA94382BBDCF95FA
1111112     15DBBA5ED9085A0F                563025B5FA6B1814
111111     BC2107A18CA29D91                24C30A1014E9B643
11111111      F5BA0BD72243F02A6B6DA71AA6ACE7F7    8731789C28823E99-------8字节倍数不用补位
111111111111     F5BA0BD72243F02AB5A29C3BE102CF3C    8731789C28823E99AFFE5399AC2025D2
1111111111111     F5BA0BD72243F02AD921AA76E8DC23C5    8731789C28823E9977E0A0FFD3F12032
11111111111111     F5BA0BD72243F02A3198863A208F1D8A    8731789C28823E9924C30A1014E9B643
111111111111111     F5BA0BD72243F02AE133BDD49B682F21    8731789C28823E99DA94382BBDCF95FA
22222222     A9BA6E2E5CAA386BCE66FDE34DD0C5CD    E4F7475D78FEB695 ------- 8字节倍数不用补位
看着像3DES_ECB加密算法,但我做了一组数据对比,发现不太一样,碰到8字节倍数的待加密数据时应该是不补位的,应该做了一些修改,
可能是强制补位的方式,你可以再试一下1111111111111111加密出来的数据长度是否为48个字符 (我这边试了强制补位后再3DES_ECB的值是8731789C28823E998731789C28823E99CCC58C491889CB43)
kimoh 2017-9-7 16:54
7

非常感谢 @yegu 抽时间做数据比对,
1111111111111111 密文 F5BA0BD72243F02A09457372E3B2E978EF12C5B72A9EDE6A   确实是48位
嗯 我本地也做了对比,分别使用的是3DES中的ECB和 CBC 两种模式
以下是对比数据

 明文 密文 3DES_ECB3DES_CBC
 0000000 58E105C78856290B F1916F6BD0B98CCA 29A5026ED5DA30C7
 1111111 152D8639F768F7CE E7BDBF59C5C760CA 74AB414BC3999C9D
 1111112 15DBBA5ED9085A0F 82389B562CC207A9 FDD47534789C08A8
 111111 BC2107A18CA29D91 8EFDB41C9B6CDFA6 822DA0B1CF607479
 11111111  F5BA0BD72243F02A6B6DA71AA6ACE7F7  F37B2736677F1F2715408D6FE15805A3 D1CE4A6FDF3422484451AA30EB0210CB
 22222222 A9BA6E2E5CAA386BCE66FDE34DD0C5CD  7F75E896A88027D715408D6FE15805A3 228AD91B5D20E7B53177C006375B5881
 111111111111 F5BA0BD72243F02AB5A29C3BE102CF3C F37B2736677F1F27093C592A96A6F8BB D1CE4A6FDF3422482B1C5D0CE7F8F40F
 1111111111111 F5BA0BD72243F02AD921AA76E8DC23C5 F37B2736677F1F270C6F85C518C5CD56 D1CE4A6FDF34224849E812F4D1AA9CDB
 11111111111111 F5BA0BD72243F02A3198863A208F1D8A F37B2736677F1F278EFDB41C9B6CDFA6 D1CE4A6FDF342248426A89B6A7CD86C5
 111111111111111 F5BA0BD72243F02AE133BDD49B682F21 F37B2736677F1F27E7BDBF59C5C760CA D1CE4A6FDF3422484BDAE95275682D9A
 1111111111111111F5BA0BD72243F02A09457372E3B2E978E
F12C5B72A9EDE6A
F37B2736677F1F27F37B2736677F1F271
5408D6FE15805A3
D1CE4A6FDF342248A7ECA265A2AE4F7D
5338E4E2F38B517C
















从 11111111  和  22222222  的加密结果来看,根据 @yemoon 提示 应该排除3DES_ECB
从比对的密文来看,应该可以确定是 使用CBC模式的3DES   不知道这样推断是否存在不妥

再次感谢上面的回复,谢谢!

mudebug 2017-9-9 21:52
8
偶然发现一个和楼主算法很想的软件,游戏服务器里的一个程序,估计是改了密码表
上传的附件:
kimoh 6天前
9
mudebug 偶然发现一个和楼主算法很想的软件,游戏服务器里的一个程序,估计是改了密码表
看来都喜欢用这算法。。。
mudebug 6天前
10
看了一下这个东西的用途,是作为协议签名和配置文件密码用的,有自己的密匙。可以自己设置。
只能自己跑密匙了。  总共8位。
返回



©2000-2017 看雪学院 | Based on Xiuno BBS | 域名 加速乐 保护 | SSL证书 又拍云 提供 | 微信公众号:ikanxue
Time: 0.015, SQL: 10 / 京ICP备10040895号-17