惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
博客园_首页
H
Help Net Security
WordPress大学
WordPress大学
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
B
Blog
I
InfoQ
SecWiki News
SecWiki News
T
Tailwind CSS Blog
Spread Privacy
Spread Privacy
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Vulnerabilities – Threatpost
N
Netflix TechBlog - Medium
P
Palo Alto Networks Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Vercel News
Vercel News
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
K
Kaspersky official blog
M
MIT News - Artificial intelligence
S
Schneier on Security
T
Threat Research - Cisco Blogs
F
Fortinet All Blogs
Cyberwarzone
Cyberwarzone
Scott Helme
Scott Helme
aimingoo的专栏
aimingoo的专栏
Martin Fowler
Martin Fowler
MyScale Blog
MyScale Blog
The Cloudflare Blog
Recent Announcements
Recent Announcements
Security Latest
Security Latest
G
GRAHAM CLULEY
IT之家
IT之家
Y
Y Combinator Blog
The Last Watchdog
The Last Watchdog
腾讯CDC
Google DeepMind News
Google DeepMind News
V
V2EX
S
Securelist
TaoSecurity Blog
TaoSecurity Blog
B
Blog RSS Feed
S
SegmentFault 最新的问题
博客园 - 叶小钗
P
Proofpoint News Feed
云风的 BLOG
云风的 BLOG
Project Zero
Project Zero
G
Google Developers Blog
Google DeepMind News
Google DeepMind News
F
Full Disclosure

博客园 - Enhydraboy

[ZT]MSN Messenger的口令获取源代码, MSNMessenger的口令是经过DPAPI加密后保存在注册表中 ADO Connection Strings[转贴] 农民造“飞碟”后记 Tomcat's Thread Pool Source(BT) - Enhydraboy 使用 jakata DBCP package 作 DB Connection pooling[ZT] 数据类型的不匹配可能会导致索引失效 msnlib中的MimeMessage.parse代码需要修改 我的MSN机器人终于有了自己的头像 Field6的类型说明 搞懂了MSN协议中的client id是怎么得到的 Java正则表达式详解[转载] MSN P2P资料转载 MSN协议中的msnobj浅析 MSNP10中修改自己的FRIENDLY NAME改成了RPR命令 msp10协议中的SYN好像发生了变化 准备让MSN机器人可以显示头像 jMSN开发指南 我自己的msn机器人诞生了 中国足球进步了
MSN协议中关于Send DP的研究
Enhydraboy · 2004-06-29 · via 博客园 - Enhydraboy

MSN6中,可以定义自己的头像。那么自己做的机器人其实也可以显示头像。jmsn没有提供这个特性。
只能自己修改代码了。
关键是协议。我跟踪了msn的通讯协议,发现,首先,你要向服务器申明你的头像信息。这个信息是在<msnobj>实体内实现的。

对方的msn messenger会发现你有头像信息,会通过SS向你发送msn p2p的invite msnmsng请求。然后你回应,传送头像二进制流。就是一个p2p通讯的过程。
目前,还在研究中。发现,每个p2p消息中,都包含了一个48字节的一个头。至于是什么内容,今天刚刚得到一位朋友的指点。
1.  This is a DWORD and contains the SessionID, which is zero when the Clients are negotiating  about the session. This field is only used when actually sending data (DP’s, CE’s etc). The  value of this field in Ink messages is always 64!

2.  This field is again a DWord, which identifies the message (the so called Base Identifier). In  Ink this field has the same value in all messages. In other transfers this value will range  from BaseID - 3 to BaseID + 3. The number can range between 4 and 4,25 billion
(4 ~ 4 250 000 000).

3. This field is a QWord, and contains the offset of the data you are sending, if the size is over  1202 bytes. For example, if you send 2404 bytes, the first message would contain the value  zero (seeing you haven’t send something yet), and the second message would have the value  1202, because you just send 1202 bytes.

4. This field is once again a QWord, and contains the size of total data being send in this total. If there is no data you can leave this to zero and often the Flag field (field 6) should be set to the value of 2.

5. This field is a DWord and contains the size of the data being send in this message. Note that “data” does NOT include the headers, only the data send between the Header and the Footer! For example, when sending a 5000 bytes file, field four would contain the value of 5000, and this field would contain only 1202, because you can’t transfer more than 1202 bytes in one message. This field and the fourth field are equal to each other when you aren’t sending actually file data (or Ink data in our case).

6. The sixth field, DWord, is the Flag field. The value of this field is 0 when no Flags are  specified. It will be 2 when the message is a reply to another message, 8 if there’s an error in  the binary fields of the received packet. The Flag will contain the value 32 if you are sending  DP or CE data, and the value 16777264 when it’s data of a file transfer.

7. This DWord contains the BaseID of the previous received message, *if* the SessionID is not  included in the binary headers, nor in the data sent in this message. Seeing the SessionID is  specified when sending Ink you can just put a random number here (1 ~ 1 000 000 000  would be good enough).

8. This field (A DWord) contains the value of the seventh field of the previous received message.

9. The ninth field is a QWord, and contains the value of the fourth field of the previous received  message.

10. This DWord comes AFTER the data, and therefore it’s the Footer. This DWord contains the  value zero when there is no actual file data (DP’s, CE’s etc) being send. It has the value 1  hen you send DP’s, CE’s or other data, and it has the value 3 when sending Ink.