RTMFP简介
Changming
Sun<me@sunchangming.com>
Brief
• RTMFP - "Real-Time Media Flow Protocol”
• 是Flash与Flash之间的基于UDP的点对点传输协
议
• Adobe的专有协议。
• 2008年在Flash 10.0中首次发布
• 现在...
A brief view(1)
Use it as rpc method:
var nc:NetConnection;
nc = new NetConnection()
nc.connect("rtmfp://127.0.0.1:1935/He...
A brief view(2)
Attach Streams to RTMFP Connection:
var nc:NetConnection;
nc = new NetConnection()
nc.connect("rtmfp://127...
主要内容
• History and Why we need it?
• How to analyze it?
• Layers
– UDP层的Multiplex与加密解密
– 会话建立、密钥协商、NAT穿透
– 类TCP的功能(flow、分片...
History
• 2004年,Matthew Kaufman 和 Michael Thornburgh
在美国加州Santa Cruz成立了Amicima公司,他们
设计了MFP
• 2005年8月1日,MFP开源
• 2006年,Amici...
Why we need it?
• “To securely deliver media flows over the
Internet”
• Peer to Peer video streaming
• 移动互联网环境下,延迟高,连接易断,I...
如何分析它?
方法比结论更重要。
Wireshark
Man in the Middle
• 密钥协商采用了Diffie–Hellman算法
• Diffie–Hellman 天生就有漏洞,容易受到中
间人攻击
• Cumulus 做了一个
https://github.com/OpenRTMFP...
反向工程(1)
反向工程(2)
Address Space Load Randomization
Address Space Load Randomization
Address Space Load Randomization
D:> dumpbin /headers flashplayer_11_sa_debug_32bit.exe
8140 DLL characteristics
Dynamic b...
Tamarin
• Adobe 主导的开源项目
• Flash Player的AVM的核心源码
• 包含GC、bytecode、AMF相关内容
D:flairpcf avmplus.lib avmplus.pat
avmplus.lib: sk...
RTTI
• 利用RTTI根据从object pointer获取class
name
• 可惜flash player在所有平台下都没有打开
RTTI
• 但是Server有!
• 不仅有RTTI信息,还有大量调试代码,用于
输出调试日志。
Server的调试日志
• 2012-06-12 17:32:07 8328 (d)0000000 rtmfp send message,
session: 08F2F008 flow: 08F22EA0 rel: (-2,-2) kMsgCm...
Hook DLL
• https://github.com/snnn/flash-rtmfp-hook
• 找到感兴趣的函数
• 制作DLL
• 注入它!
• Detours
缺点:只能适用于特定平台特定版本的flash
player
版本升级
分享分析结果
协议分层
协议分层
• Packet:Session标识、UDP层的Multiplex、
加密解密。
• Chunks:18种底层消息,用于Session建立、
密钥生成与交换、Keep-alive、NAT穿透、IP
移动、拥塞控制等
• Flow:Fr...
RTMFP Groups: 组播与P2P routing
Session multiplexing
• UDP Packet = scrambledSessionID + encPart
前4个字节是加扰后的session id
后面是AES加密后的数据
1. 加密是必须的而不是可选的
2. 用ses...
加密与HMAC
1. Enc(SSEQ+ body), 然后算HMAC
2. ENC(checksum + body)
代表了保障消息完整性的两种模式
承载Chunks
timestamp: 2字节。它的值是从1970-01-01 00:00:00 +0000 (UTC)到现在的毫秒数除以4,
然后取最低2个字节。
timestamp-echo: 2字节。what the timestamp ...
Chunks类型
session
• initiator hello
• responder hello
• initiator Ikeying
• responder Ikeying
• Redirected IHello
• Forward...
SESSION
会话建立
会话建立涉及的Chunks
• initiator hello
• responder hello
• initiator initial keying
• responder initial keying
• Redirected initi...
Endpoint Discriminator
• 每个Endpoint有一个EPD
• 每个EPD由1个或多个identity组成
• Identity分两种
– 0xf, peerid
– 0x0a,server url
• PeerID=S...
4次握手
密钥协商
• DH
• b = g^a (mod p)
• d= g^c (mod p)
• Shared = b^c = d^a = g^(a * c)
• 易受中间人攻击。
• g 和p的选择参考IPSec(rfc2412)和rfc3526
密钥协商
• byte[] sec; byte[] HMAC256(byte[] key,byte[] data);
• byte[] key1=HMAC256(sec,HMAC256(skrc,skic));
• byte[] key2=HM...
NAT穿透
发送时:3种NAT
• Cone: 将src ip映射到一个固定的IP,并且将
src port映射到一个固定的Port,无论dst ip
和dst port是什么。
• Single IP address, symmetric:将src ip...
接受时:3种
• Full Cone: 不对收到的包的IP端口做任何限
制. 这种NAT通常被称为static NAT,在外面
看就像是一个透明代理一样。
• Restricted Cone: Restricted Cone会对收到的
包的IP...
打洞
打洞
打洞
打洞
打洞
打洞
Control Chunks
• Ping
• Ping Reply
• Session Close Request
• Session Close Acknowledgement
FLOW
Flow简介
• Flow是单向的
• 每个Flow都有自己的名字
• 建立Flow不需要单独的Chunk。Flow的meta
data随第一个数据包一起发送
• 保障顺序(或不)
• 保障一定送达(或不)
• 每个Flow有自己的窗口控制
Chunks
• User Data
• Next User Data
• Buffer Probe
• ACK
• Flow Exception report
UserData
• uint8_t flags;
varint64 flowid;
varint64 seq;
varint64 fsnOffset;
optional Options options; //当flags & 0x80 !=0...
MessageTypes
• kMsgUserCtrl
• kMsgVirtualUserControl
• kMsgAudio
• kMsgVideo
• kMsgDataEx
• kMsgContainerEx
• kMsgCmdEx
• ...
ACK
• Data Acknowledgement Bitmap Chunk
– flowID
– bufAvail
– cumAck
– Bitmap (每一位对应一个seq number)
• Data Acknowledgement R...
参考资料:
• RFC草案: http://tools.ietf.org/html/draft-
thornburgh-adobe-rtmfp
• 2010年在IETF上的演讲:
http://www.ietf.org/proceedings/...
Upcoming SlideShare
Loading in …5
×

Analysis of Adobe's RTMFP Protocol

1,903 views

Published on

Analysis of Adobe's RTMFP Protocol

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,903
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Analysis of Adobe's RTMFP Protocol

  1. 1. RTMFP简介 Changming Sun<me@sunchangming.com>
  2. 2. Brief • RTMFP - "Real-Time Media Flow Protocol” • 是Flash与Flash之间的基于UDP的点对点传输协 议 • Adobe的专有协议。 • 2008年在Flash 10.0中首次发布 • 现在在我们每个人的浏览器中。 • 2012年12月提交RFC • 发明人认为它是An replacement of TCP。 类似协议: webrtc、DCCP、DTLS、ICE(rfc5245).
  3. 3. A brief view(1) Use it as rpc method: var nc:NetConnection; nc = new NetConnection() nc.connect("rtmfp://127.0.0.1:1935/HelloWorld/"); nc.call("serverFunc1", new Responder(onReply), ”hello”); function onReply(result:Object):void { dlog("onReply received value: " + result); }
  4. 4. A brief view(2) Attach Streams to RTMFP Connection: var nc:NetConnection; nc = new NetConnection() nc.connect("rtmfp://127.0.0.1:1935/HelloWorld/"); sendStream = new NetStream(nc,NetStream.DIRECT_CONNECTIONS); sendStream.publish("media");
  5. 5. 主要内容 • History and Why we need it? • How to analyze it? • Layers – UDP层的Multiplex与加密解密 – 会话建立、密钥协商、NAT穿透 – 类TCP的功能(flow、分片、ACK与重传、拥塞 控制)
  6. 6. History • 2004年,Matthew Kaufman 和 Michael Thornburgh 在美国加州Santa Cruz成立了Amicima公司,他们 设计了MFP • 2005年8月1日,MFP开源 • 2006年,Amicima被Adobe收购,MFP变RTMFP • 2008年,RTMFP在Adobe 10.0中发布 • 2010年6月,Matthew Kaufman跳槽去了Skype • 2012年12月,Michael Thornburgh代表Adobe公司 向IETF提交了RTMFP协议草案。
  7. 7. Why we need it? • “To securely deliver media flows over the Internet” • Peer to Peer video streaming • 移动互联网环境下,延迟高,连接易断,IP 易变 • 层次化的组合设计(如tcp+ssl+http)导致建立 连接所需的TTL太多。 —> 在UDP的基础上重新实现TCP+SSL,以及 NAT穿透。
  8. 8. 如何分析它? 方法比结论更重要。
  9. 9. Wireshark
  10. 10. Man in the Middle • 密钥协商采用了Diffie–Hellman算法 • Diffie–Hellman 天生就有漏洞,容易受到中 间人攻击 • Cumulus 做了一个 https://github.com/OpenRTMFP/Cumulus 缺点:使用麻烦 并非处理了所有情况
  11. 11. 反向工程(1)
  12. 12. 反向工程(2)
  13. 13. Address Space Load Randomization
  14. 14. Address Space Load Randomization
  15. 15. Address Space Load Randomization D:> dumpbin /headers flashplayer_11_sa_debug_32bit.exe 8140 DLL characteristics Dynamic base NX compatible Terminal Server Aware 如果它的值是8140,就说明打开了”Dynamic base”。用VC的 链接器禁用掉它即可。 D:> link /edit /dynamicbase:NO flashplayer_11_sa_debug_32bit.exe
  16. 16. Tamarin • Adobe 主导的开源项目 • Flash Player的AVM的核心源码 • 包含GC、bytecode、AMF相关内容 D:flairpcf avmplus.lib avmplus.pat avmplus.lib: skipped 1731, total 14180 D:flairsigmake avmplus.pat avmplus.sig avmplus.sig: modules/leaves: 8012/4207, COLLISIONS: 407
  17. 17. RTTI • 利用RTTI根据从object pointer获取class name • 可惜flash player在所有平台下都没有打开 RTTI • 但是Server有! • 不仅有RTTI信息,还有大量调试代码,用于 输出调试日志。
  18. 18. Server的调试日志 • 2012-06-12 17:32:07 8328 (d)0000000 rtmfp send message, session: 08F2F008 flow: 08F22EA0 rel: (-2,-2) kMsgCmd idByte=20 streamId=0 time=0 trxId=1 kEncodingAMF0 _result cmdData=( kObjectType ( fmsVer= kStringType “FMS/4,5,0,297”, capabilities= kNumberType 255, mode= kNumberType 1 ) ) arg0=( kObjectType ( level= kStringType “status”, code= kStringType “NetConnection.Connect.Success”, description= kStringType “Connection succeeded.”, objectEncoding= kNumberType 3, data= kArrayType ( version= kStringType “4,5,0,297” ) ) ) - • 2012-06-12 17:32:07 8328 (i)2581173 rtmfp recv message, session: 08F2F008 flow: 05624900 kMsgCmdEx idByte=17 streamId=0 time=724 trxId=0 kEncodingAMF0 setPeerInfo cmdData=( kNullType ) arg0=( kStringType “192.168.15.1:53804” ) arg1=( kStringType “192.168.146.1:53804” ) arg2=( kStringType “10.4.8.84:53804” ) -
  19. 19. Hook DLL • https://github.com/snnn/flash-rtmfp-hook • 找到感兴趣的函数 • 制作DLL • 注入它! • Detours 缺点:只能适用于特定平台特定版本的flash player
  20. 20. 版本升级
  21. 21. 分享分析结果
  22. 22. 协议分层
  23. 23. 协议分层 • Packet:Session标识、UDP层的Multiplex、 加密解密。 • Chunks:18种底层消息,用于Session建立、 密钥生成与交换、Keep-alive、NAT穿透、IP 移动、拥塞控制等 • Flow:Framing、Fragmentation、ACK、重传、 拥塞控制、优先级。 • 应用层: 分布式对象与RPC、音频流、视频 流、音视频编解码、Qos。
  24. 24. RTMFP Groups: 组播与P2P routing
  25. 25. Session multiplexing • UDP Packet = scrambledSessionID + encPart 前4个字节是加扰后的session id 后面是AES加密后的数据 1. 加密是必须的而不是可选的 2. 用session id来关联一个Endpoint,而不是ip address and port
  26. 26. 加密与HMAC 1. Enc(SSEQ+ body), 然后算HMAC 2. ENC(checksum + body) 代表了保障消息完整性的两种模式
  27. 27. 承载Chunks timestamp: 2字节。它的值是从1970-01-01 00:00:00 +0000 (UTC)到现在的毫秒数除以4, 然后取最低2个字节。 timestamp-echo: 2字节。what the timestamp field of a packet received from the other end would be at the time this packet was transmitted Padding: 0xFF. Chunk id never be 0xFF.
  28. 28. Chunks类型 session • initiator hello • responder hello • initiator Ikeying • responder Ikeying • Redirected IHello • Forwarded IHello • responder cookie change control • Ping • Ping Reply • Session Close Request • Session Close Ack Flow • User Data • Next User Data • Buffer Probe • ACK • Flow Exception report
  29. 29. SESSION
  30. 30. 会话建立
  31. 31. 会话建立涉及的Chunks • initiator hello • responder hello • initiator initial keying • responder initial keying • Redirected initiator Hello • Forwarded Initiator Hello • responder cookie change
  32. 32. Endpoint Discriminator • 每个Endpoint有一个EPD • 每个EPD由1个或多个identity组成 • Identity分两种 – 0xf, peerid – 0x0a,server url • PeerID=SHA256(Certificate) • Certficate: Option List (含公钥等)
  33. 33. 4次握手
  34. 34. 密钥协商 • DH • b = g^a (mod p) • d= g^c (mod p) • Shared = b^c = d^a = g^(a * c) • 易受中间人攻击。 • g 和p的选择参考IPSec(rfc2412)和rfc3526
  35. 35. 密钥协商 • byte[] sec; byte[] HMAC256(byte[] key,byte[] data); • byte[] key1=HMAC256(sec,HMAC256(skrc,skic)); • byte[] key2=HMAC256(sec,HMAC256(skic,skrc)); session.encodekey = new SecretKeySpec(Arrays.copyOf(key1, 16), "AES"); //initiator的加密密钥 • session.decodekey = new SecretKeySpec(Arrays.copyOf(key2, 16), "AES"); //responder的加密密钥
  36. 36. NAT穿透
  37. 37. 发送时:3种NAT • Cone: 将src ip映射到一个固定的IP,并且将 src port映射到一个固定的Port,无论dst ip 和dst port是什么。 • Single IP address, symmetric:将src ip映射到 一个固定的IP,将src port映射到一个随机的 port,但是保证对于相同的(dst ip,dst port), src port始终相同。 • Multiple IP address, symmetric:与上面类似, 但是src ip可能会被映射到多个IP中的一个。
  38. 38. 接受时:3种 • Full Cone: 不对收到的包的IP端口做任何限 制. 这种NAT通常被称为static NAT,在外面 看就像是一个透明代理一样。 • Restricted Cone: Restricted Cone会对收到的 包的IP做限制。 • Port Restricted Cone: 它就是在Restricted Cone的基础上对端口也做了限制。 • 连接性测试: http://cc.rtmfp.net/
  39. 39. 打洞
  40. 40. 打洞
  41. 41. 打洞
  42. 42. 打洞
  43. 43. 打洞
  44. 44. 打洞
  45. 45. Control Chunks • Ping • Ping Reply • Session Close Request • Session Close Acknowledgement
  46. 46. FLOW
  47. 47. Flow简介 • Flow是单向的 • 每个Flow都有自己的名字 • 建立Flow不需要单独的Chunk。Flow的meta data随第一个数据包一起发送 • 保障顺序(或不) • 保障一定送达(或不) • 每个Flow有自己的窗口控制
  48. 48. Chunks • User Data • Next User Data • Buffer Probe • ACK • Flow Exception report
  49. 49. UserData • uint8_t flags; varint64 flowid; varint64 seq; varint64 fsnOffset; optional Options options; //当flags & 0x80 !=0 uint8_t data[]; • forwardSequenceNumber = seq- fsnOffset
  50. 50. MessageTypes • kMsgUserCtrl • kMsgVirtualUserControl • kMsgAudio • kMsgVideo • kMsgDataEx • kMsgContainerEx • kMsgCmdEx • kMsgData • kMsgContainer • kMsgCmd • kMsgUDP • kMsgAggregate • kMsgPresent
  51. 51. ACK • Data Acknowledgement Bitmap Chunk – flowID – bufAvail – cumAck – Bitmap (每一位对应一个seq number) • Data Acknowledgement Ranges Chunk 与上面类似,但是把bitmap换成了rangs
  52. 52. 参考资料: • RFC草案: http://tools.ietf.org/html/draft- thornburgh-adobe-rtmfp • 2010年在IETF上的演讲: http://www.ietf.org/proceedings/10mar/slides/ts varea-1.pdf • 2013年对Michael Thornburgh的访谈: http://www.overdigital.com/2013/02/21/rtmfp- and-the-ietf-qa-with-co-creator-michael- thornburgh/ • http://www.sunchangming.com/docs/rtmfp.jsp

×