Embed Size (px)
DESCRIPTION
Analysis of Adobe's RTMFP Protocol
Citation preview
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).
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); }
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");
主要内容• History and Why we need it?• How to analyze it?• Layers– UDP 层的 Multiplex 与加密解密– 会话建立、密钥协商、 NAT 穿透– 类 TCP 的功能（ flow 、分片、 ACK 与重传、拥
塞控制）
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 协议草案。
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 穿透。
如何分析它 ?方法比结论更重要。
Wireshark
Man in the Middle
• 密钥协商采用了 Diffie–Hellman 算法• Diffie–Hellman 天生就有漏洞，容易受到中
间人攻击• Cumulus 做了一个 https://github.com/OpenRTMFP/Cumulus
缺点：使用麻烦 并非处理了所有情况
反向工程（ 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 base NX compatible Terminal Server Aware如果它的值是 8140 ，就说明打开了” Dynamic base” 。用 VC的链接器禁用掉它即可。
D:> link /edit /dynamicbase:NO flashplayer_11_sa_debug_32bit.exe
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
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) 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” ) -
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 ： Framing 、 Fragmentation 、 ACK 、重传、拥塞控制、优先级。
• 应用层 : 分布式对象与 RPC 、音频流、视频流、音视频编解码、 Qos 。
RTMFP Groups: 组播与 P2P routing
Session multiplexing
• UDP Packet = scrambledSessionID + encPart前 4 个字节是加扰后的 session id后面是 AES 加密后的数据1. 加密是必须的而不是可选的2. 用 session id来关联一个 Endpoint ，而不
是 ip address and port
加密与 HMAC
1. Enc(SSEQ+ body), 然后算 HMAC2. ENC(checksum + body)
代表了保障消息完整性的两种模式
承载 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 transmittedPadding: 0xFF. Chunk id never be 0xFF.
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
SESSION
会话建立
会话建立涉及的 Chunks
• initiator hello• responder hello• initiator initial keying• responder initial keying• Redirected initiator Hello• Forwarded Initiator Hello• responder cookie change
Endpoint Discriminator
• 每个 Endpoint 有一个 EPD • 每个 EPD由 1 个或多个 identity 组成• Identity 分两种– 0xf, peerid– 0x0a,server url
• PeerID=SHA256(Certificate)• Certficate: Option List （含公钥等）
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=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 的加密密钥
NAT穿透
发送时： 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 中的一个。
接受时： 3 种• Full Cone: 不对收到的包的 IP端口做任何限
制 . 这种 NAT通常被称为 static NAT ，在外面看就像是一个透明代理一样。
• Restricted Cone: Restricted Cone 会对收到的包的 IP 做限制。
• Port Restricted Cone: 它就是在 Restricted Cone 的基础上对端口也做了限制。
• 连接性测试： http://cc.rtmfp.net/
打洞
打洞
打洞
打洞
打洞
打洞
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 !=0uint8_t data[];
• forwardSequenceNumber = seq- fsnOffset
MessageTypes• kMsgUserCtrl• kMsgVirtualUserControl• kMsgAudio• kMsgVideo• kMsgDataEx• kMsgContainerEx• kMsgCmdEx• kMsgData• kMsgContainer• kMsgCmd• kMsgUDP• kMsgAggregate• kMsgPresent
ACK
• Data Acknowledgement Bitmap Chunk– flowID– bufAvail– cumAck– Bitmap ( 每一位对应一个 seq number)
• Data Acknowledgement Ranges Chunk 与上面类似，但是把 bitmap 换成了 rangs
参考资料：• RFC 草案： http://
tools.ietf.org/html/draft-thornburgh-adobe-rtmfp
• 2010 年在 IETF 上的演讲： http://www.ietf.org/proceedings/10mar/slides/tsvarea-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
