AMF協議的數據封裝和文件解析
在前面我們已經對AMF協議的相關內容進行了講解。不知道大家是否已經掌握了,而且我們也強調了兩個版本的不同和差異?,F在我們將繼續闡述有關的知識。希望大家能從中得到幫助。那么接下來就要將一個完整的AMF協議文件的封裝格式了。AMF文件總體來說分為4部分:前言(Preamble)、AMF頭、AMF主體和主體的響應。前言的前2字節用于說明AMF的版本,目前AMF有2個版本AMF0和AMF3.如使用AMF0則是:00 00。第3和第4字節用16位整數表示AMF頭的數量。每一個AMF頭是由以下四部分組成:
◆UTF string 表示Header的名字
◆Boolean 表示該Header是否是必須的
◆Int32表示Header的長度,但是好像很多情況下該值為FF FF FF FF,似乎這個字段沒有意義。
◆Variable變量是某種AMF協議數據類型。
在Header表示完后,接下來是一個16位的整數用來表示AMF主體的數量,在這個數量之后才是AMF主體。
AMF主體主要由以下四部分組成:
◆UTF String - Response表示請求的類和方法或響應的結果。
◆UTF String - Target是一個標識,其作用就是為了實現請求和響應的對應,通過Target找到該響應對應的請求。一般使用自增整數。
◆Int32- 表示主體的長度,該字段一般沒有什么用
◆Variable變量表示主體的數據。
主體響應是客戶端向服務器發送一個AMF請求以后服務器做出的和請求的主體格式相同的AMF響應,但是主體響應中的內容有所不同:
◆Response: 被設置為字符串‘null'.
◆Target: 是請求的Target值再加上“/onStatus", “onResult", 或者 “/onDebugEvents"組成. “/onStatus" 是為運行時錯誤而準備的我們一般不關心這個. “/onResult" 表示該請求被正確調用. “/onDebugEvents" 是在調試時使用的,這里也不用關心. 如果請求的Target是‘/1', 那么被成功調用以后的主體響應應該是: ‘/1/onResult' 。
◆Data:就是響應后返回的AMF協議文件對象。
說了這么多估計還是感覺比較抽象,下面給出個實例:#p#
AMF協議16進制內容
00000000h: 00 00 00 00 00 01 00 1B 7A 68 2E 66 6C 65 65 74 ; ........zh.fleet
00000010h: 53 65 72 76 69 63 65 2E 67 65 74 46 6C 65 65 74 ; Service.getFleet
00000020h: 52 6F 77 00 03 2F 37 39 00 00 00 13 0A 00 00 00 ; Row../79........
00000030h: 03 02 00 01 35 02 00 03 38 34 35 02 00 01 35; ....5...845...5
以上是客戶端向服務器發送的一個AMF請求。我們可以按照前面說的封裝方式將該amf解析如下:
00 00(AMF0版本)00 00(Header個數為0)00 01(AMF主體有1個)
00 1B(請求的方法的字符串長度為27個字節)
7A ……77(這27個直接就是調用的類和方法:“zh.fleetService.getFleetRow")
00 03(請求的Target字符串長3字節) 2F 37 39(Target的內容:“/79")
00 00 00 13(主體的長度為19)
0A(傳入的變量是一個Array)00 00 00 03(該Array的長度為3)02 00 01 3***rray的***個值是字符串“5")02 00 03 38 34 3***rray的第二個值是字符串“845")02 00 01 3***rray的第三個值是字符串“5")
現在整個AMF協議對象都解析出來了,我們可以認為是客戶端調用了服務器的方法:zh.fleetService.getFleetRow("5", "845", "5")
服務器返回的AMF文件的內容的解析方式相同,這里我就不再重復了。
現在我們已經對AMF文件有了一個清晰的認識了。那么接下來就是要抓包,看某些在Flex上的操作對應的發送了什么AMF文件,服務器返回了什么AMF文件。將這些AMF協議文件解析出來然后就可以看到調用了API了。