原来没有注意，以为还是以前的我看过一个很肤浅的介绍，
今天空闲下来，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版。总共有四组设备名被检查了。

引用:

原帖由 scz 于 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  ...

我是在本机调试,没有远程调试过,再者根本没有这个问题.
现在可以 及时通讯, 可以语音,可以传文件.
在softice下都没有问题.

至少在2.0.4.97下没有问题
当时是在4月份开始的,网上只有这个版本,所以用softice分析都是
切很多子程序分析都是基于他,所以现在还没有升级.

引用:

原帖由 scz 于 2006-6-9 21:16 发表
那个PDF的作者肯定是彻底搞清楚了的。不过他写这个文档的时候是藏了私的。比如\\.\\Siwvid没有显式出现在image中，而是加密存放成B49AACA6B9A3FD7C636E，解密函数在

005E5076     lea edx,                ; D ...

是的,估计哪个作者,使用的版本问题.
作者2006.3出哪个东西分析的版本不知道是哪个

引用:

原帖由 scz 于 2006-6-9 21:16 发表
那个PDF的作者肯定是彻底搞清楚了的。不过他写这个文档的时候是藏了私的。比如\\.\\Siwvid没有显式出现在image中，而是加密存放成B49AACA6B9A3FD7C636E，解密函数在

005E5076     lea edx,                ; D ...

搞明白是一会事,能把他的数据全部反回来,且能全能成明文,就是另一会事了.
对于他里面提到的哪个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全部可以看作伪随机数。

整个讨论越看越有味道， 越俎代庖一下，设精

引用:

原帖由 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，就全搞定。

引用:

原帖由 scz 于 2006-8-2 18:55 发表
我也续一点吧。

那个PDF里有两处提到了CRC32算法。一处是出现在UDP数据区中的，这个CRC32是对Plain Data运算得来的。另一处不会出现在UDP数据区中，只会与IV异或后做为seed去生成RC4密钥，这一处CRC32的运算对 ...

在SoftICE中拦截sendto，设数据断点层层回溯，可找到构造UDP数据区的地方，设置ID、Func Code、IV、CRC32、RC4 Encrypted Data都在一起，没有分散。当然，最变态的是用一个32位的seed生成RC4密钥的算法，那个要扒的话比较费事。

这部分的程序的子程序调用的地址,都是计算得到的,调试起来很麻烦,涉及的反汇编代码大约2万多行.
但是,我把这部分整理出来之后,解密数据发现,有很多UDP包,根本就没有多少意义,它是一些随机数
它里面有一个随机数算法,估计这些随机数是用于测试的包,因为在程序里面发现是这种包,根本不做处理
的.

[quote]原帖由 scz 于 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公司想怎么用了。它要是搞强自校验，你手工构造报文的话就得完全满足所有的自校验关系。
我现在手工构造报文是尽量满足这些自校验关系，省得现在偷懒到头来还得再辛苦。

等待下文。。。。

引用:

原帖由 popsvc 于 2007-1-1 03:13 发表
等待下文。。。。

你等什么下文。他给了他反汇编的代码，在置顶中就有。看了再等，如何。

上面说：
“ 后面那个"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]所用的标准参数有异，你用的成熟算法直接套上去当然不对。

太牛啦 学习中