skype的doc 文档读后感
原来没有注意，以为还是以前的我看过一个很肤浅的介绍，今天空闲下来，download下来发现，我靠，我这段时间作的
工作他全介绍了。
这个文档的作者，一看就是跟踪且分析过 skype的包，里面的
所有东西写出来都是正确的，因为那些东西，我也遇到了。
但看到会面的aes,public key 等我原来没有跟踪这方面的程序。
不敢枉下结论。
下面给出一些，他里面的说的对代码的校验部分程序。2。0。4。97里面的
007B63F9 33D2 XOR EDX,EDX
007B63FB 81C22C916300 ADD EDX,0063912C ;计算
007B6401 B9B84A0C00 MOV ECX,000C4AB8 ;出
007B6406 81F1BD8B9E00 XOR ECX,009E8BBD ;地址
007B640C 8BF1 MOV ESI,ECX ;
007B640E EB01 JMP 007B6411 ;
007B6410 50 PUSH EAX ;
007B6411 81C6D9406DFF ADD ESI,FF6D40D9 ;
007B6417 8B4210 MOV EAX,[EDX+10] ;校验
007B641A 83C300 ADD EBX,00 ;代码
007B641D 03C8 ADD ECX,EAX ;
007B641F 81EA02000000 SUB EDX,00000002 ;
007B6425 4E DEC ESI ;
007B6426 0BF6 OR ESI,ESI ;
007B6428 75ED JNZ 007B6417 ;
007B642A 81E923558595 SUB ECX,95855523 ;
007B6430 740D JZ 007B643F ;对转
007B6432 83C40C ADD ESP,0C ;
007B6435 6A00 PUSH 00 ;修改程序转
007B6437 51 PUSH ECX ;出错
007B6438 03D1 ADD EDX,ECX ;
007B643A E96D8AD1FF JMP 004CEEAC ;
007B643F B8CFFFFFFF MOV EAX,FFFFFFCF ;
============================================
007A70D9 33F6 |XOR ESI,ESI
007A70DB 81EED845A0FF |SUB ESI,FFA045D8
007A70E1 B80A3A2500 |MOV EAX,00253A0A
007A70E6 358A2E7500 |XOR EAX,00752E8A
007A70EB 8BD0 |MOV EDX,EAX
007A70ED EB01 |JMP 007A70F0
007A70EF 4C |DEC ESP
007A70F0 81C2847FB1FF |ADD EDX,FFB17F84
007A70F6 8B4EC0 |MOV ECX,[ESI-40]
007A70F9 EB01 |JMP 007A70FC
007A70FB E533 |IN EAX,33
007A70FD C181EE01000000 |ROL DWORD PTR [ECX+000001EE],00
007A7104 4A |DEC EDX
007A7105 0BD2 |OR EDX,EDX
007A7107 75ED |JNZ 007A70F6
007A7109 2D3DE289CA |SUB EAX,CA89E23D
007A710E 740F |JZ 007A711F
007A7110 83C40C |ADD ESP,0C
007A7113 6A00 |PUSH 00
007A7115 50 |PUSH EAX
007A7116 03F0 |ADD ESI,EAX
007A7118 8BF6 |MOV ESI,ESI
007A711A E918BDF3FF |JMP 006E2E37
007A711F B872FFFFFF MOV EAX,FFFFFF72
====================================
我从内存中抓出的 udp包 就是他说的nack如下：
00B243AC 89 92 57 7C D0 7F C6 23-36 4C 90
57是标志 7c d0 7f c6 是ip我的外网IP 后面的4个字节是他回应的时候加密用的
他回应UDP 包如下：可以看到 D1等于上面的四个字节
上面是原始部分，下面是加密后发送的部分
加密后发送的数据 25
D0 标志 D1 IP 地址 校验DWORD
---- -- -- ----------- ----------- ----------
0A49025A 89 92 63 01 23 36 4C 90-18 2E BC 3D 3E 93 98 98
89 92 63 01 23 36 4c 90 18 2e bc 3d 3e 93 98 98
0A49026A 12 DA 01 89 91 42 B8 27-D2 9B 29 2D FA 9B 29 2D
fd e6 34 b2 52 04 26 01 f7 d6 87 29 7b 2f 85 6a
0A49027A FA 9B 29 2D FA
a3 92 7f 1e 1d
说明：具体这个文档在老大哪个帖子里，自己去找 我请教个问题，下面这段，你碰上没有？
Hidden test : It checks if Softice is not in the Driver list.
call EnumDeviceDrivers
. . .
call GetDeviceDriverBaseNameA
. . .
cmp eax , ’ntic ’
jnz next
cmp ebx , ’e.sy ’
jnz next
cmp ecx , ’s\ x00\ x00\ x00 ’
jnz next
我现在远程SoftICE调Skype，巨不放心这个事，我拦了LoadLibraryExW等着它动态
加载psapi.dll，结果一直没触发。硬着头皮静态去搜:
:s -a 0 l 7fffffff 3d 6e 74 69 63
0000000000 occurances found
这两个函数都是psapi里的。虽然现在能调，但不放心。
下周我要出趟远门，九天后回来。 那个PDF的作者肯定是彻底搞清楚了的。不过他写这个文档的时候是藏了私的。比如\\.\\Siwvid没有显式出现在image中，而是加密存放成B49AACA6B9A3FD7C636E，解密函数在
005E5076 lea edx, [ebp+var_1C] ; DST
005E5079 mov eax, offset unk_5E517C ; SRC
005E507E call Transform ; 这是一个线性可逆变换
我的这个版本是主站上最新的那个Beta版。总共有四组设备名被检查了。 [quote]原帖由 [i]scz[/i] 于 2006-6-9 21:11 发表
我请教个问题，下面这段，你碰上没有？
Hidden test : It checks if Softice is not in the Driver list.
call EnumDeviceDrivers
. . .
call GetDeviceDriverBaseNameA
. . .
cmp eax , ’ntic ’
jnz ... [/quote]
我是在本机调试,没有远程调试过,再者根本没有这个问题.
现在可以 及时通讯, 可以语音,可以传文件.
在softice下都没有问题.
至少在2.0.4.97下没有问题
当时是在4月份开始的,网上只有这个版本,所以用softice分析都是
切很多子程序分析都是基于他,所以现在还没有升级. [quote]原帖由 [i]scz[/i] 于 2006-6-9 21:16 发表
那个PDF的作者肯定是彻底搞清楚了的。不过他写这个文档的时候是藏了私的。比如\\.\\Siwvid没有显式出现在image中，而是加密存放成B49AACA6B9A3FD7C636E，解密函数在
005E5076 lea edx, ; D ... [/quote]
是的,估计哪个作者,使用的版本问题.
作者2006.3出哪个东西分析的版本不知道是哪个 [quote]原帖由 [i]scz[/i] 于 2006-6-9 21:16 发表
那个PDF的作者肯定是彻底搞清楚了的。不过他写这个文档的时候是藏了私的。比如\\.\\Siwvid没有显式出现在image中，而是加密存放成B49AACA6B9A3FD7C636E，解密函数在
005E5076 lea edx, ; D ... [/quote]
搞明白是一会事,能把他的数据全部反回来,且能全能成明文,就是另一会事了.
对于他里面提到的哪个SEED其中涉及到的反汇编出来的程序就有2万多行.
要直接推导出来,重写一个也要费一翻工夫,我没有重写,在原来反汇编程序,修改的
用了两个礼拜多的时间.
再者他里面保留一个参数,你调试时是不会调用的,但哪个参数在 TCP 解密的时候可能激活
记得doc里面提到 tcp的 00 01 00 00 00 01 00 00 00 03
这个01是作为参数他可以是03我一直没有发现他使用. 我用skype2.0.4.107的版本没有问题 我也续一点吧。
那个PDF里有两处提到了CRC32算法。一处是出现在UDP数据区中的，这个CRC32是对Plain Data运算得来的。另一处不会出现在UDP数据区中，只会与IV异或后做为seed去生成RC4密钥，这一处CRC32的运算对象也在PDF里给出来了，就是源、目标、ID那个。然后这个RC4密钥用去加密Plain Data，发送到网上的是RC4 Encrypted Data。用IDA Pro逆的时候，很容易找到
dd 77073096h, 0EE0E612Ch, 990951BAh, 76DC419h, 706AF48Fh, 0E963A535h
这是那个所谓的CRC32算法的快表，然后在IDA Pro中查看引用关系。这个CRC算法参数是标准的:
Width : 32
Poly : 04C11DB7
Init : FFFFFFFF
RefIn : True
RefOut : True
在SoftICE中拦截sendto，设数据断点层层回溯，可找到构造UDP数据区的地方，设置ID、Func Code、IV、CRC32、RC4 Encrypted Data都在一起，没有分散。当然，最变态的是用一个32位的seed生成RC4密钥的算法，那个要扒的话比较费事。
一开始看这个文档的时候，以为两个CRC32是一回事，算来算去对不上，后来才发现是这样。
后面的RC4加密部分所用RC4密钥可从已知信息推算，PDF里写得很清楚了，因此可以单包解密。当然解密后的数据也是需要分析的，不过那就是纯粹的协议分析了。
ID、IV全部可以看作伪随机数。 整个讨论越看越有味道， 越俎代庖一下，设精 [quote]原帖由 [i]softice_debug[/i] 于 2006-6-9 16:05 发表
原来没有注意，以为还是以前的我看过一个很肤浅的介绍，
今天空闲下来，download下来发现，我靠，我这段时间作的
工作他全介绍了。
这个文档的作者，一看就是跟踪且分析过 skype的包，里面的
所有东西写出来 ... [/quote]
就以这个为例:
89 92
63
01
23 36 4C 90
18 2E BC 3D
3E 93 98 98
FD E6 34 B2 52 04 26 01
F7 D6 87 29 7B 2F 85 6A
A3 92 7F 1E 1D
这次用来生成seed的办法:
0x8992 ^ 0x23364C90
后面那个"3E 93 98 98"是对Plain Data的CRC32。再后面就是RC4 Encrypted Data。
由于seed已知，RC4密钥就算已知，因此可以单包RC4解密。
这些UDP请求包的构造大同小异，主要区别在seed如何生成，有了seed，就全搞定。 [quote]原帖由 [i]scz[/i] 于 2006-8-2 18:55 发表
我也续一点吧。
那个PDF里有两处提到了CRC32算法。一处是出现在UDP数据区中的，这个CRC32是对Plain Data运算得来的。另一处不会出现在UDP数据区中，只会与IV异或后做为seed去生成RC4密钥，这一处CRC32的运算对 ... [/quote]
在SoftICE中拦截sendto，设数据断点层层回溯，可找到构造UDP数据区的地方，设置ID、Func Code、IV、CRC32、RC4 Encrypted Data都在一起，没有分散。当然，最变态的是用一个32位的seed生成RC4密钥的算法，那个要扒的话比较费事。:L:victory:
这部分的程序的子程序调用的地址,都是计算得到的,调试起来很麻烦,涉及的反汇编代码大约2万多行.
但是,我把这部分整理出来之后,解密数据发现,有很多UDP包,根本就没有多少意义,它是一些随机数
它里面有一个随机数算法,估计这些随机数是用于测试的包,因为在程序里面发现是这种包,根本不做处理
的. [quote]原帖由 [i]scz[/i] 于 2006-8-4 18:50 发表
QUOTE:
原帖由 softice_debug 于 2006-6-9 16:05 发表
原来没有注意，以为还是以前的我看过一个很肤浅的介绍，
今天空闲下来，download下来发现，我靠，我这段时间作的
工作他全介绍了。
这个文档的作者，一看就是跟踪且分析过 skype的包，里面的
所有东西写出来 ...
就以这个为例:
89 92
63
01
23 36 4C 90
18 2E BC 3D
3E 93 98 98
FD E6 34 B2 52 04 26 01
F7 D6 87 29 7B 2F 85 6A
A3 92 7F 1E 1D
这次用来生成seed的办法:
0x8992 ^ 0x23364C90
后面那个"3E 93 98 98"是对Plain Data的CRC32。再后面就是RC4 Encrypted Data。
由于seed已知，RC4密钥就算已知，因此可以单包RC4解密。
这些UDP请求包的构造大同小异，主要区别在seed如何生成，有了seed，就全搞定。
偶有了SEED也没有全部搞定[可能偶比较笨],老大你会发现,最大的问题在于RSA 1024的密钥问题.
如果得不到密钥,下面的包就无法解开:语音包[UDP],传文件的包[UDP],即时消息包[UDP]
密钥部分,在你上网LOGIN时确定的.
因这段时间忙于其他事,已经中断快一个月,中断前主要再看,RSA1024的密钥反汇编
的代码,看看有没有漏洞. 我目前阶段的需要是对Skype做精确的协议识别。暂时不理会别的。我说有了seed就全搞定，是指只用RC4加密的报文就全搞定，不是说后续那些报文也全搞定。
> 解密数据发现,有很多UDP包,根本就没有多少意义,它是一些随机数
可以看成伪随机数。
这个就看Skype公司想怎么用了。它要是搞强自校验，你手工构造报文的话就得完全满足所有的自校验关系。
我现在手工构造报文是尽量满足这些自校验关系，省得现在偷懒到头来还得再辛苦。 等待下文。。。。 [quote]原帖由 [i]popsvc[/i] 于 2007-1-1 03:13 发表
等待下文。。。。 [/quote]
你等什么下文。他给了他反汇编的代码，在置顶中就有。看了再等，如何。 上面说：
“ 后面那个"3E 93 98 98"是对Plain Data的CRC32。再后面就是RC4 Encrypted Data。由于seed已知，RC4密钥就算已知，因此可以单包RC4解密,当然解密后的数据也是需要分析的，不过那就是纯粹的协议分析了。”
“偶有了SEED也没有全部搞定[可能偶比较笨],老大你会发现,最大的问题在于RSA 1024的密钥问题.
如果得不到密钥,下面的包就无法解开:语音包[UDP],传文件的包[UDP],即时消息包[UDP]
密钥部分,在你上网LOGIN时确定的。 ”
请教：单包RC4解密 与 得不到RSA密钥,就无法解开语音包[UDP],传文件的包[UDP] 有何不同？
同样是RC4加密，单包解密和语音UDP包解密有什么区别？谢谢！ 后面的UDP包用的对称密钥是在登录时RSA掩护下动态交换的，不是最前面所用的那个RC4密钥。这是两种加密。 刚开始看BH的pdf，一直没有算明白CRC32是怎么得来的，好像我怎么算都算不对。
按照文档说是和SourceIP, DestIP, ID有关，我就算文档上那个值好像都没有算出来。自己抓包的好像也算不过。
src: 172.16.72.131
dst: 24.98.66.80
id: 0x7f4e
crc32: 0xfc95755e
哪位达人算出来 过不？ 这个算法，建议你用调试器跟进去，只看文档、照搬成熟算法会漏掉一些变种。那个PDF是指导手册，指引你去用调试器跟踪的方向而已。具体到这个CRC32，与[PKZIP, AUTODIN II, Ethernet, FDDI]所用的标准参数有异，你用的成熟算法直接套上去当然不对。 太牛啦 学习中 有没有详细点的关于密匙的交换的过程的介绍?
我想有没有可能通过中间人攻击?
主要设想是劫持公匙,换成自己的公匙(假设我们有运营商级的资源,所有双方的数据包都能捕获!).以后用该公匙所作的加密都可以破解? 不是说公钥是固化在客户端的么 ？？怎么劫持？？？
页:
[1]