适用于python3的AMF序列化

Question

I am trying to write a python3 encoder/decoder for AMF.

The reason I'm doing it is because I didn't find a suitable library that works on python3 (I'm looking for a non-obtrusive library - one that will provide me with the methods and let me handle the gateway myself)

Avaialble libraries I tested for python are amfast, pyamf and amfy. While the first 2 are for python2 (several forks of pyamf suggest that they support python3 but I coudn't get it to work), amfy was designed for python3 but lacks some features that I need (specifically object serialization).

Reading through the specification of AMF0 and AMF3, I was able to add a package encoder/decoder but I stumbled on object serialization and the available documentation was not enough (would love to see some examples). Existing libraries were of no help either.

Using remoteObject (in flex), I managed to send the following request to my parser:

b'\x00\x03\x00\x00\x00\x01\x00\x04null\x00\x02/1\x00\x00\x00\xe0\n\x00\x00\x00\x01\x11
\n\x81\x13Mflex.messaging.messages.CommandMessage\x13operation\x1bcorrelationId\x13
timestamp\x11clientId\x15timeToLive\tbody\x0fheaders\x17destination\x13messageId\x04\x05
\x06\x01\x04\x00\x01\x04\x00\n\x0b\x01\x01\n\x05\tDSId\x06\x07nil%DSMessagingVersion\x04
\x01\x01\x06\x01\x06I03ACB769-9733-6A6C-0923-79F667AE8249'

(notice that newlines were introduced to make the request more readable)

The headers are parsed OK but when I get to the first object (\\n near the end of the first line), it is marked as a reference (LSB = 0) while there is no other object it can reference to.

am I reading this wrong? Is this a malformed bytes request? Any help decoding these bytes will be welcomed.

Answer 1

From the AMF3 spec , section 4.1 NetConnection and AMF3 :

The format of this messaging structure is AMF 0 (See [AMF0]. A context header value or message body can switch to AMF 3 encoding using the special avmplus-object-marker type.

What this means is that by default, the message body must be parsed as AMF0. Only when encountering an avmplus-object-marker (0x11) should you switch to AMF3. As a result, the 0x0a type marker in your value is not actually an AMF3 object-marker, but an AMF0 strict-array-marker.

Looking at section 2.12 Strict Array Type in the AMF0 spec , we can see that this type is simply defined as an u32 array-count, followed that number of value-types.

In your data, the array-count is 0x00, 0x00, 0x00, 0x01 (ie 1), and the value following that has a type marker of 0x11 - which is the avmplus-object-marker mentioned above. Thus, only after starting to parse the AMF0 array contents should you actually switch to AMF3 to parse the following object.

In this case, the object then is an actual AMF3 object (type marker 0x0a ), followed by a non-dynamic U29O-traits with 9 sealed members. But I'm sure you can take it from here. :)