AMF learning 2 Remote Call Encapsulation

As the AMF data type has been learned in the previous article, we need to encapsulate a complete AMF file.

AMF files are divided into four parts: Preface (Preamble), AMF header, AMF subject, and response of the subject.

The first two bytes in the preface are used to describe the AMF version. Currently, AMF has two versions: AMF0 and AMF3. if AMF0 is used

3rd and 4th bytes use 16-bit Integers to indicate the number of AMF headers.

Each AMF header consists of the following four parts:

UTF string indicates the Header name

Boolean indicates whether the Header is required.

Int32 indicates the length of the Header, but it seems that the value is FF in many cases, it seems that this field is meaningless.

Variable is a certain AMF data type.

After the Header expression is complete, a 16-bit integer is followed to indicate the number of AMF subjects. After this number, it is the AMF entity.

AMF consists of the following four parts:

UTF String-Response indicates the request class and method or Response result.

UTF String-Target is an identifier used to implement the correspondence between requests and responses. You can use Target to find the corresponding request for the response. Generally, auto-incrementing integers are used.

Int32-indicates the length of the subject. This field is generally useless.

The Variable indicates the data of the subject.

The body response is an AMF response in the same format as the request body after the client sends an AMF request to the server. However, the content in the body response is different:

Response: The string 'null '.

Target: the Target value of the Request plus "/onStatus", "onResult", or "/onDebugEvents. "/onStatus" is prepared for runtime errors. We generally don't care about this. "/onResult" indicates that the request is called correctly. "/onDebugEvents" is used for debugging, and you do not need to worry about it here. if the Target of the request is '/1', the response of the body after successful call should be'/1/onresult '.

Data: The AMF object returned after the response.

After talking about so many estimates, I still feel abstract. The following is an example:

AMF hexadecimal content

00000000 h: 00 00 00 00 01 00 1B 7A 68 2E 66 6C 65 65 74; ...... zh. fleet
00000010 h: 53 65 72 76 69 63 65 2E 67 65 74 46 6C 65 65 74; Service. getFleet
00000020 h: 52 6F 77 00 03 2F 37 39 00 00 00 13 0A 00 00 00; Row.../79 ........
00000030 h: 03 02 00 01 35 02 00 03 38 34 35 02 00 01 35; ...... 5 ...... 845 ...... 5

The preceding is an AMF request sent from the client to the server. We can resolve the amf according to the encapsulation method described above:

00 00 (AMF0 version) 00 00 00 (number of headers is 0) 00 01 (one AMF subject)

00 1B (the string length of the Request Method is 27 bytes)

7A ...... 77 (these 27 are directly called classes and Methods: "zh. fleetService. getFleetRow ")

00 03 (the requested Target string is 3 bytes long) 2F 37 39 (Target content: "/79 ")

00 00 00 13 (subject length: 19)

0A (the input variable is an Array) 00 00 03 (the length of this Array is 3) 02 00 01 35 (the first value of Array is the string "5 ") 02 00 03 38 34 35 (the second value of Array is the string "845") 02 00 01 35 (the third value of Array is the string "5 ")

Now the entire AMF object has been parsed. We can think that the client has called the server method: zh. fleetService. getFleetRow ("5", "845", "5 ")

 

The contents of the AMF file returned by the server are parsed in the same way, so I will not repeat it here.

Now we have a clear understanding of the AMF file. The next step is to capture packets and check what AMF files are sent for some operations on Flex, And what AMF files are returned by the server. Parse these AMF files and then you can see that the API is called.