Identifying an algorithm used to sign iCloud payload

Question

I'm trying to decipher which algorithm was used to sign a specific chunk of data while reverse-engineering iCloud backups. Long story short: I'm trying to retrieve some old voicemails that I lost when switching mobile providers which were deleting after switching out my SIM cards. iCloud backups store old voicemails, so I figured this might be an easy way to retrieve them (I might have been a bit ambitious ;) ).

The data I'm looking at is sent in a request header and is base-64 encoded. It looks something like this:

AuN9pwI6lGPo4o/QRCHOx2AgLw0+ZYKa/EMrV3mgF3YGAAACsAYAAABRAAAAgODPA2YwKh3l2fLM3gW4Af9xPlv1/+EtbY4h9oARcUPQX4EdH+WAX8Ykm6OHVqd83R66QVIIBHI0tT25B1wFgXuGySqCaaSD0w
Y7gdW2k3D2BvD2nsG5id4t9baDysQJnjb6ZnjKDfcZFN8WtjQrHloMBqKFXo/kFyEcrMe2RRFuAAAByDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+CjwhRE9DVFlQRSBwbGlzdCBQVUJM
SUMgIi0vL0FwcGxlLy9EVEQgUExJU1QgMS4wLy9FTiIgImh0dHA6Ly93d3cuYXBwbGUuY29tL0RURHMvUHJvcGVydHlMaXN0LTEuMC5kdGQiPgo8cGxpc3QgdmVyc2lvbj0iMS4wIj4KPGRpY3Q+Cgk8a2V5Pn
Byb3RvY29sVmVyc2lvbjwva2V5PgoJPHN0cmluZz4xLjA8L3N0cmluZz4KCTxrZXk+dXNlckluZm88L2tleT4KCTxkaWN0PgoJCTxrZXk+Y2xpZW50LWlkPC9rZXk+CgkJPHN0cmluZz43QzU5NTk2NS1CRjVE
LTRFQUMtODU0Ni1ERjE3MURFODlFODk8L3N0cmluZz4KCQk8a2V5Pmxhbmd1YWdlPC9rZXk+CgkJPHN0cmluZz5lbjwvc3RyaW5nPgoJCTxrZXk+dGltZXpvbmU8L2tleT4KCQk8c3RyaW5nPkFtZXJpY2EvQ2
hpY2Fnbzwvc3RyaW5nPgoJPC9kaWN0Pgo8L2RpY3Q+CjwvcGxpc3Q+CgAAAE8BZcdgyW1geNb3ShFevEjAAQuaxtAAAAA2BwfNJW4CI1ecZzpRj+05iam1VDBu+v6s1vFV2yGsNid5yTyOLs8zP5cDfl9doFgA
ydAAAAAAAAAA=

Decoding, we get the following (with relevant Python code):

>>> payload = """AuN9pwI6lGPo4o/QRCHOx2AgLw0+ZYKa/EMrV3mgF3YGAAACsAYAAABRAAAAgODPA2YwKh3l2fLM3gW4Af9xPlv1/+EtbY4h9oARcUPQX4EdH+WAX8Ykm6OHVqd83R66QVIIBHI0tT25B1wFgXuGySqCaaSD0w
Y7gdW2k3D2BvD2nsG5id4t9baDysQJnjb6ZnjKDfcZFN8WtjQrHloMBqKFXo/kFyEcrMe2RRFuAAAByDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+CjwhRE9DVFlQRSBwbGlzdCBQVUJM
SUMgIi0vL0FwcGxlLy9EVEQgUExJU1QgMS4wLy9FTiIgImh0dHA6Ly93d3cuYXBwbGUuY29tL0RURHMvUHJvcGVydHlMaXN0LTEuMC5kdGQiPgo8cGxpc3QgdmVyc2lvbj0iMS4wIj4KPGRpY3Q+Cgk8a2V5Pn
Byb3RvY29sVmVyc2lvbjwva2V5PgoJPHN0cmluZz4xLjA8L3N0cmluZz4KCTxrZXk+dXNlckluZm88L2tleT4KCTxkaWN0PgoJCTxrZXk+Y2xpZW50LWlkPC9rZXk+CgkJPHN0cmluZz43QzU5NTk2NS1CRjVE
LTRFQUMtODU0Ni1ERjE3MURFODlFODk8L3N0cmluZz4KCQk8a2V5Pmxhbmd1YWdlPC9rZXk+CgkJPHN0cmluZz5lbjwvc3RyaW5nPgoJCTxrZXk+dGltZXpvbmU8L2tleT4KCQk8c3RyaW5nPkFtZXJpY2EvQ2
hpY2Fnbzwvc3RyaW5nPgoJPC9kaWN0Pgo8L2RpY3Q+CjwvcGxpc3Q+CgAAAE8BZcdgyW1geNb3ShFevEjAAQuaxtAAAAA2BwfNJW4CI1ecZzpRj+05iam1VDBu+v6s1vFV2yGsNid5yTyOLs8zP5cDfl9doFgA
ydAAAAAAAAAA="""
>>> decoded_data = payload.decode("base-64")
>>> decoded_data
\x02\xe3}\xa7\x02:\x94c\xe8\xe2\x8f\xd0D!\xce\xc7` /\r>e\x82\x9a\xfcC+Wy\xa0\x17v\x06\x00\x00\x02\xb0\x06\x00\x00\x00Q\x00\x00\x00\x80\xe0\xcf\x03f0*\x1d\xe5\xd9\xf2\xcc\xde\x05\xb8\x01\xffq>[\xf5\xff\xe1-m\x8e!\xf6\x80\x11qC\xd0_\x81\x1d\x1f\xe5\x80_\xc6$\x9b\xa3\x87V\xa7|\xdd\x1e\xbaAR\x08\x04r4\xb5=\xb9\x07\\\x05\x81{\x86\xc9*\x82i\xa4\x83\xd3\x06;\x81\xd5\xb6\x93p\xf6\x06\xf0\xf6\x9e\xc1\xb9\x89\xde-\xf5\xb6\x83\xca\xc4\t\x9e6\xfafx\xca\r\xf7\x19\x14\xdf\x16\xb64+\x1eZ\x0c\x06\xa2\x85^\x8f\xe4\x17!\x1c\xac\xc7\xb6E\x11n\x00\x00\x01\xc8<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n\t<key>protocolVersion</key>\n\t<string>1.0</string>\n\t<key>userInfo</key>\n\t<dict>\n\t\t<key>client-id</key>\n\t\t<string>7C595965-BF5D-4EAC-8546-DF171DE89E89</string>\n\t\t<key>language</key>\n\t\t<string>en</string>\n\t\t<key>timezone</key>\n\t\t<string>America/Chicago</string>\n\t</dict>\n</dict>\n</plist>\n\x00\x00\x00O\x01e\xc7`\xc9m`x\xd6\xf7J\x11^\xbcH\xc0\x01\x0b\x9a\xc6\xd0\x00\x00\x006\x07\x07\xcd%n\x02#W\x9cg:Q\x8f\xed9\x89\xa9\xb5T0n\xfa\xfe\xac\xd6\xf1U\xdb!\xac6\'y\xc9<\x8e.\xcf3?\x97\x03~_]\xa0X\x00\xc9\xd0\x00\x00\x00\x00\x00\x00\x00

After pretty-printing, it looks like this:

>>> print decoded_data
���4+Z+Wy�v�Q���f0*�������q>[���-m�!�qC�_��_�$���V�|��Ar4�=�\�{��*�i���;�ն�p������-��� �6�fx�
      ��^��!�ǶEn�<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>protocolVersion</key>
    <string>1.0</string>
    <key>userInfo</key>
    <dict>
        <key>client-id</key>
        <string>7C595965-BF5D-4EAC-8546-DF171DE89E89</string>
        <key>language</key>
        <string>en</string>
        <key>timezone</key>
        <string>America/Chicago</string>
    </dict>
</dict>
</plist>
Oe�`�m`x��J^�H�
               ���6�%n#W�g:Q��9���T0n�����U�!�6'y�<�.�3?�~_]�X��

Since the data isn't encrypted, I'm assuming (maybe incorrectly?) that the data chunks before and after the data represent a signature.

Is there any way to identify which algorithm might have been used to generate this signature?

Answer 1

Generally in case of binary data, the first thing you have to check, whether it contains any length field. Since you know the full length of the data an know at least one structure (the XML part), you can use these information pieces to take the first guesses.

In the following picture I marked the guessed length values as yellow. Right before the XML part, there is a small number (0x1c8) in big-endian, which exactly the size of the text area. Before the XML, there is a high entropy part (marked as green), which is 0x80 bytes long. Based on the area length, it is probably the signature encrypting with an 1024-bit RSA key.