今天终于搞通了android to any voice。
其实android到gtalk，到msn，这些都不是问题，到qq这个不要想了，sigh！
主要是找到一家可靠的sip服务商，资费足够便宜，通话清晰。我用的LocalPhone，他到china的费率是0.12rmb，比市话便宜。在android上用fring做为sip的接入端。fring也支持msn，gtalk等。你要是在用个google voice就更好了。
顺便推荐一个美剧真爱如血，比较赞，（HBO出品，口味比较重）
vlc太恶心了
情况是这样的，使用helix做rtp relay服务器，后来发现在server2003下helix工作ok，在linux下，无法工作。
我抓狂啊！
好吧！我来查，会不会是操作系统的问题？ok，我装了rad hat 4，我装了centos，还是依旧。好吧，会不会是虚拟机的问题？我上服务器上测。still，我想跳楼了。。。。。
然后我怀疑sdp的问题，我直接把server2003下可以正常工作的文件拷过了，还是不行。。。
然后折腾了两天，终于发现vlc生成的sdp中，源使用windows机器名，放linux当然跑不起来。。。。。。
疯了。。。。。。。。。。。。
NAT Order of Operation
Introduction
This document illustrates that the order in which transactions are processed using Network Address Translation (NAT) is based on whether a packet is going from the inside network to the outside network, or from the outside network to the inside network.
Prerequisites
Requirements
Readers of this document should have knowledge of the following topic:
-
Network Address Translation (NAT). For more information on NAT, see How NAT Works.
Components Used
This document is not restricted to specific software and hardware versions.
Note: The information in this document is based on the Software Version, Cisco IOS® Software Release 12.2(27)
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
NAT/PAT中对于FTP的处理，以及PAT后的非标准21 FTP端口设置
这里先要对FTP的两种模式说一下：
引用一张Cisco上面的图：
about ip address
http://www.rfc-editor.org/rfc/rfc3330.txt
Address Block Present Use Reference
---------------------------------------------------------------------
0.0.0.0/8 "This" Network [RFC1700, page 4]
10.0.0.0/8 Private-Use Networks [RFC1918]
14.0.0.0/8 Public-Data Networks [RFC1700, page 181]
24.0.0.0/8 Cable Television Networks --
39.0.0.0/8 Reserved but subject
to allocation [RFC1797]
127.0.0.0/8 Loopback [RFC1700, page 5]
128.0.0.0/16 Reserved but subject
to allocation --
169.254.0.0/16 Link Local --
172.16.0.0/12 Private-Use Networks [RFC1918]
191.255.0.0/16 Reserved but subject
to allocation --
192.0.0.0/24 Reserved but subject
to allocation --
192.0.2.0/24 Test-Net
192.88.99.0/24 6to4 Relay Anycast [RFC3068]
192.168.0.0/16 Private-Use Networks [RFC1918]
198.18.0.0/15 Network Interconnect
Device Benchmark Testing [RFC2544]
223.255.255.0/24 Reserved but subject
to allocation --
224.0.0.0/4 Multicast [RFC3171]
240.0.0.0/4 Reserved for Future Use [RFC1700, page 4]
Understanding SVI Autostate Exclude
To be “up/up,” a router VLAN interface must fulfill the following general conditions:
•
The VLAN exists and is “active” on the VLAN database of the switch.
•The VLAN interface exists on the router and is not administratively down.
•At least one Layer 2 (access port or trunk) port exists, has a link “up” on this VLAN and is in spanning-tree forwarding state on the VLAN.
DNS缓存投毒细节泄露
昨天Mantasano上的一篇文章描述了Dan Kaminsky的DNS域名服务器攻击的细节。该文章发表了几分钟之后即被删掉了。
虽然Dan Kaminsky已经联合厂商发布了补丁，但是仍处于补丁推送阶段，目前仍有相当一部分域名服务器还没有打补丁。如果被恶意利用的话，对整个互联网还是很有威胁的。这也是为什么Dan 希望 “not speculate publicly”。
大概看了一下那篇hypothesis，基本上还是利用了”Cache 投毒”（cache poisoning）的方法，不过使用了一些新的技巧。
DNS查询是如何进行的？对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另一台DNS服务器（这台服务器通常是由 ISP或者公司提供），然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓存下来，从而提高查询效率并降低由 DNS带来的流量开销。
一台缓存DNS服务器（与权威DNS相对，这类系统提供的）下面的桌面系统可能有几百、几千、几万甚至几十万台桌面系统。
DNS缓存中毒攻击指的是更改了DNS服务器的DNS缓存中某项，这样缓存中与主机名相关的IP地址就不再指向正确的位置。例如，如果 www.example.com映射到IP地址192.168.0.1且DNS服务器的缓存中存在这个映射，则成功向这个服务器的DNS缓存投毒的攻击者就可以将www.example.com映射到10.0.0.1。在这种情况下，试图访问www.example.com的用户就可能与错误的Web服务器联络。
当攻击者试图请求查询某站点的域名时，DNS服务器首先会检查自己的DNS缓存中是否存在该域名，如果存在则将该域名所对应的IP地址返回给请求者，如果不存在则向上一级DNS或者权威DNS查询。这就会给攻击者带来一定的困难，如果是大一点的站点的话，攻击者发起DNS查询时，DNS服务器直接从缓存应答了，根本不会去请求权威域名服务器。怎么才能解决这个问题呢？云舒在他的DNS缓存中毒漏洞的一点推测中也提到过。
比如我们要攻击www.google.com.首先向目的DNS服务器查询根本不存在的二级域名，比如：aaa.google.com. DNS服务器在缓存中查找aaa.google.com,没有找到，则会向上级DNS或者权威DNS查询 。这时我们可以生成伪造的DNS Response数据包并发送这些的伪造DNS Response数据包给目的服务器。让目的DNS在上级DNS或者权威DNS服务器响应到达之前，接受到恶意的应答。
从表面上看这样只是截持了一个不存在的二级域名，只能用来钓钓鱼罢了。
其实DNS Response数据包可以不仅仅包含aaa.google.com的IP地址，还可以在DNS 数据包的Additional resource record中包含www.google.com的IP地址（当然该IP地址可以是伪造的）。当目的DNS收到该数据报时会将伪造的IP地址与 www.google.com关联起来并刷新到缓存上。这样就完成了主域名的截持。
通过emule做DDOS是否可行？
by 云舒
今天抽空看了下emule协议几个可能会出问题的地方，初步感觉是可能真的有问题。下了代码回来看了，不过代码太大，目前还没找到地方，没法对想法进行印证。我简单的说下，看哪位代码牛人能够在项目中找到对应的代码。
首先是在客户端连接到服务器之后，搜索文件时，服务器返回结果的报文。报文中返回的结果是一个集合，每个集合表示一条记录。但是每条记录中，并不包含拥有该文件的客户端的IP地址，而是返回的拥有该文件的客户端的ClientID和端口。这里我猜测ClientID的计算是可逆的，搜索发起者可以根据这个 ClientID计算出IP地址，然后连接，请求下载文件。具体报文结构如下：
| 名称 | 大小（字节） | 默认值 | 注释 |
| 协议类型 | 1 | 0xE3 | |
| 大小 | 4 | 不包含报文和大小域的报文大小 | |
| 类型 | 1 | 0×16 | 操作码 OP SEARCHRESULT 的值 |
| 结果数 | 4 | N/A | 此报文中包含的结果数目 |
| 结果列表 | 可变 | N/A | 一个结果的列表 |
搜索结果列表项格式：
| 名称 | 大小（字节） | 默认值 | 注释 |
| 文件HASH | 16 | N/A | 用于识别文件的 Hash 值 |
| 客户端 ID | 4 | N/A | eMule服务器分配给客户端的ID |
| 客户端端口 | 2 | N/A | 客户端的监听的TCP端口 |
| 标志数 | 4 | N/A | 其后的属性标志个数 |
| 标志列表 | 可变 | N/A | 标志列表 |
其次的第二个地方是下载文件的地方，客户端要求下载一个文件时，服务器会返回一个源查找结果报文。该报文也是只包含源的ClientID和端口，客户端应该是按照ClientID计算出IP地址，再去连接下载文件的。具体报文如下：
| 名称 | 大小（字节） | 默认值 | 注释 |
| 协议类型 | 1 | 0xE3 | |
| 大小 | 4 | N/A | 不包含报文头和大小域的报文大小 |
| 类型 | 1 | 0×42 | 操作码 OP FOUNDSOURCES 的值 |
| 文件HASH | 16 | N/A | 相关文件的 Hash 值 |
| 源数量 | 1 | N/A | 拥有该文件的机器的数量 |
| 源列表 | 可变 | N/A | 源列表内容，每一条是一个可用源 |
每一条源的报文格式如下：
| 名称 | 大小（字节） | 默认值 | 注释 |
| 客户端 ID | 4 | N/A | 共享该文件的客户端的 ID |
| 客户端端口 | 2 | N/A | 共享该文件的客户端端口 |
可以看到，搜索某个文件时，服务器返回的搜索列表中按照ClientID来区分不同的其它客户端。在开始下载一个文件时，服务器返回的可用源列表中，每个源也是以一个ClientID来表示的。也就是说，没一个ClientID就可以确定一个源，区分开彼此。而emule可以根据这个ClientID找到对应的客户端，去连接指定端口，请求文件。那么，现在的问题是这个ClientID是哪里来的？
原来这个ClientID在正常情况下，是我们连接到emule服务器时，服务器分配给我们的。但是注意到，在连接之后，我们可以像服务器提供我们所拥有的文件列表，报文格式如下：
| 名称 | 大小（字节） | 默认值 | 注释 |
| 协议类型 | 1 | 0xE3 | |
| 大小 | 4 | 不包含报文和大小域的报文大小 | |
| 类型 | 1 | 0×15 | 操作码 OP SEARCHRESULT 的值 |
| 文件数 | 4 | N/A | 共享列表中的文件数，这个数不超过 200 |
| 文件列表 | 可变 | N/A | 可选的文件列表,单个项的描述见下 |
单个文件条目描述我就不细写了，比较有用的字段是文件Hash码，ClientID，以及端口。这样看来，我们在连接到服务器之后，告诉它baidu的IP地址，TCP80端口，有赤壁下载，或者有XXX片下载，别人下载的时候，emule客户端会不会从服务器返回的可用源列表中，找到这条记录，并且去连接？
关键问题到了ClientID的计算，协议中这样描述的：假设 IP 地址为 X.Y.Z.W,则客户端 ID 按公式 X+28*Y+216*Z+24*W (Big Endian[6])计算。如果想法是正确的，那么我们可以先计算出百度的IP地址的ClientID，端口设置为80，然后通知服务器，这个 ClientID有高树的片子可以看……
Getting Started With JGAP
To use JGAP in an application, there are five basic things that you must do:
Through the course of this tutorial, we’ll build a simple example program that makes use of JGAP. The goal of our program will be to produce a user-specified amount of change in the fewest possible American coins (quarters, dimes, nickels, and pennies).
Windows XP的无线桥接
目前大部分的笔记本都是有两块网卡，一块是普通网卡，一块是无线网卡。一般有网口的地方会用普通网卡，通过网线连接上网，以获得较好的性能，没有网口的地方，会用无线上网。通常情况下，即使在同一个局域网里面，如果手工配置IP地址，必须为这两个不同的链接配置不同的IP地址，因为windows不允许为两个不同的适配器配置相同的IP地址。在特殊情况下，例如，使用电驴并在路由器上做了端口映射，于是需要在两种情况下都使用相同的IP地址，又不想每次都重新手工配置，这个时候可以用Windows自带的桥接模式来解决这个问题。
(全文…)
Recent Comments
@评论开启
@今天过生日
@国猪
@今天过生日
@今天过生日