Incorrect UserMessage structure on the wiki?

[mrexodia]

Today I was trying to get deliver_message to work properly for SmmServer and I ran into a strange issue.

Here is my log (I just added some debug prints):

[2022-08-20 15:42:38] INFO: MessageDeliveryServer.deliver_message()
[2022-08-20 15:42:38] INFO: DataHolder.decode, stream: 0e0042696e6172794d65737361676500a7000000a30000000000000000002a000000000000001a94357701000000000000000000000000000000000000000000000001000000010000010000006a0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000
[2022-08-20 15:42:38] INFO: DataHolder.decode, name: BinaryMessage, stream: a7000000a30000000000000000002a000000000000001a94357701000000000000000000000000000000000000000000000001000000010000010000006a0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000
[2022-08-20 15:42:38] INFO: DataHolder.decode, sub1: a30000000000000000002a000000000000001a94357701000000000000000000000000000000000000000000000001000000010000010000006a0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000, stream: 
[2022-08-20 15:42:38] INFO: DataHolder.decode, sub2: 0000000000002a000000000000001a94357701000000000000000000000000000000000000000000000001000000010000010000006a0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000, sub1: 
[2022-08-20 15:42:38] INFO: Structure.decode, hierarchy: [<class 'nintendo.nex.common.Data'>, <class '__main__.UserMessage'>, <class '__main__.BinaryMessage'>]
[2022-08-20 15:42:38] INFO: UserMessage.load stream: 000000001a94357701000000000000000000000000000000000000000000000001000000010000010000
[2022-08-20 15:42:38] INFO: BinaryMessage.load stream: 6800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000
[2022-08-20 15:42:38] INFO: message: {"binary_body": [0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 2, 84, 11, 228, 97, 0, 71, 0, 114, 0, 97, 0, 115, 0, 115, 0, 121, 0, 32, 0, 80, 0, 108, 0, 97, 0, 105, 0, 110, 0, 115, 0, 32, 0, 40, 0, 69, 0, 120, 0, 116, 0, 114, 0, 101, 0, 109, 0, 101, 0, 108, 0, 121, 0, 32, 0, 69, 0, 97, 0, 115, 0, 121, 0, 41, 0, 0, 0, 0, 0, 0, 48, 95, 48, 75, 48, 104, 0, 0, 35, 114, 227, 88, 14, 35, 90, 176, 2, 129, 142, 136, 0, 0], "flags": 0, "id": 0, "life_time": 0, "message_recipient": [1, 0, 0, 0, 1, 0, 0, 1, 0, 0], "parent_id": 2000000026, "pid_sender": 1, "reception_time": {"value": 0}, "sender": null, "subject": null}

Overall the structure makes sense. I figured out the following structure:

• AnyDataHolder (name: BinaryMessage, length, length, Structure data)
• Structure data: 00 00000000 00 2a000000 00000000 1a943577 01000000 0000000000000000 00000000 00000000 0000 0000 01000000 01000001 0000 006a 0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000

This is composed of:

• Data (has no members)
  • version: 00
  • length: 00000000
• UserMessage
  • version: 00
  • length: 2a000000
  • m_uiID: 00000000
  • m_uiParentID: 1a943577 (this number occurs earlier in the logs so it makes sense)
  • m_pidSender: 01000000
  • m_receptiontime: 0000000000000000
  • m_uiLifeTime: 00000000
  • m_uiFlags: 00000000
  • m_strSubject: 0000 (null)
  • m_strSender: 0000 (null)
  • m_uiRecipientType: 01000000
  • m_principalId: 01000001
  • m_gatheringId: 0000 (there isn't enough data)
• BinaryMessage
  • qbuffer: 006a 0000006800000000030000000000000002540be46100470072006100730073007900200050006c00610069006e00730020002800450078007400720065006d0065006c0079002000450061007300790029000000000000305f304b306800002372e3580e235ab002818e880000

It looks like there is something wrong with the MessageRecipient, perhaps the m_uiRecipientType is a Uint16?

That would make it:

0100 00000100 00010000

Which is type=1, principalId=65536, gatheringId=256 which seems more reasonable?