flashadobeamf

AMF message structure?


Adobe's documentation for the AMF format does not seem to actually specify the structure of an entire AMF message. It only specifies the format of individual data types. I've read the damn thing five times and either I'm just totally missing what an actual AMF message should contain, or it's not there. Does anyone know of any documentation of the actual whole-message structure?


Solution

  • The specification might be described as "terse."

    The AMF encoding uses bytes which are called "type-markers." The type-marker for an integer is the value 4. The integer data immediately follows this tag, and is 1-4 bytes long. The length varies because the integer type is "compressed" so that values 0-127 require only 1 byte, while larger values require more bytes. This integer format is called "U29" by the specification.

    As an example, if we were to simply pass the integer "5", a valid AMF packet would be these two bytes:
    04 05

    In applications found on the web, the AMF data is sometimes preceded by a length encoded as an unsigned long in network byte order. If you were observing such an application, you might see:
    00 00 00 02 04 05, where the 00 00 00 02 indicates that the following AMF data is 2 bytes long.

    Now, suppose we sent an object after it had the following constructor:

       this.ui = "button_press";
       this.param = 5;
    

    Then we might see the following in the AMF data:

    0A - the object tag
    2B - u29o-val: 2 sealed members, object with traits and data, possibly dynamic members
    01 - empty string -- anonymous object
    05 - string-by-value, string length: 2
    75 69 - 'ui'
    0B - string-by-value, string length: 5
    70 61 72 61 6D - 'param'
    19 - string-by-value, string length: 12
    62 75 74 74 6F 6E 5F 70 72 65 73 73 - 'button_press'
    04 - integer
    05 - value of integer: 5
    01 - empty name, terminates empty list of dynamic members this object

    Since that packet will take 28 bytes, it may be prefixed by: 00 00 00 1C when encountered in the wild.

    Another possibility to consider is that AMF communications may be compressed, typically using the "deflate" compression available in zlib.

    I hope this helps you sort out the specification, but if you have questions, I would try to answer them.