#1 has dealt with almost every edge-case that I can find, outside of the instance identity stuff, which is largely cryptographic data signing a given document. There are a few keys in /${api_version}/dynamic/instance-identity/*:
document: a JSON dictionary describing facts about the instance.rsa2048: an undocumented item which appears to be an RSA signature of document, which does embed the document data within itself.pkcs7: A PKCS#7 signature which embeds document within itself.signature: An unknown format of a signature over document without document embedded within it.
The most ideal thing to do would be to generate a valid set of signatures for our emended document such that, provided that clients use our cert, clients could successfully validate our data identically to the way that it normally works on EC2.
Unfortunately, this doesn't seem to be possible so I'm filing my findings here.
Next we will inspect the files and try to understand what's going on therein.
document
The actual document looks like this:
{
"accountId" : "012345678901",
"availabilityZone" : "us-west-2a",
"ramdiskId" : null,
"kernelId" : null,
"pendingTime" : "2019-07-16T22:04:00Z",
"architecture" : "x86_64",
"privateIp" : "10.0.0.1",
"devpayProductCodes" : null,
"marketplaceProductCodes" : null,
"version" : "2017-09-30",
"region" : "us-west-2",
"imageId" : "ami-deadbeefcafebabe",
"billingProducts" : null,
"instanceId" : "i-deadbeefcafebabe",
"instanceType" : "t2.micro"
}Pretty standard instance metadata, including region which isn't exposed elsewhere.
rsa2048
I am zero-indexing bytes.
Header
Bytes 0-53 (inclusive) appear to be a binary header of some format.
Python byte encoded:
b'0\x80\x06\t*\x86H\x86\xf7\r\x01\x07\x02\xa0\x800\x80\x02\x01\x011\x0b0\t\x06\x05+\x0e\x03\x02\x1a\x05\x000\x80\x06\t*\x86H\x86\xf7\r\x01\x07\x01\xa0\x80$\x80\x04\x82\x01\xde'
Hex encoding:
30 80 06 09 2A 86 48 86 F7 0D 01 07 02 A0 80 30 80 02 01 01 31 0B 30 09 06 05 2B 0E 03 02
1A 05 00 30 80 06 09 2A 86 48 86 F7 0D 01 07 01 A0 80 24 80 04 82 01 DE
This does not appear to be any ASCII data.
Document
After the header is the document in ASCII, in my case bytes 54 through 531 inclusive.
Footer
After the document, the footer begins at byte 532 and continues to the end of the document at byte 827.
Python byte encoded:
b'\x00\x00\x00\x00\x00\x001\x82\x01\x180\x82\x01\x14\x02\x01\x010i0\\1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x190\x17\x06\x03U\x04\x08\x13\x10Washington State1\x100\x0e\x06\x03U\x04\x07\x13\x07Seattle1 0\x1e\x06\x03U\x04\n\x13\x17Amazon Web Services LLC\x02\t\x00\x96\xbaH\xd9\xe5^\x1ag0\t\x06\x05+\x0e\x03\x02\x1a\x05\x00\xa0]0\x18\x06\t*\x86H\x86\xf7\r\x01\t\x031\x0b\x06\t*\x86H\x86\xf7\r\x01\x07\x010\x1c\x06\t*\x86H\x86\xf7\r\x01\t\x051\x0f\x17\r190716203739Z0#\x06\t*\x86H\x86\xf7\r\x01\t\x041\x16\x04\x14\xb3\xe4q\x1c><\xe3\x97\xe2\x9f*\xf3\x1c\xe9\xd94\x94\xc5%\x170\t\x06\x07*\x86H\xce8\x04\x03\x04/0-\x02\x148\xe8T\x8c\xc8\xa2@\xb2\xf2\x8e \x9f\xbf\xb8\xc9 ~\xd9\xba[\x02\x15\x00\x98}\x9bh\x99\xd8\xff_\xdc\xef\xf0;{S!4\x8ejI\x96\x00\x00\x00\x00\x00\x00'
Hex encoding:
00 00 00 00 00 00 31 82 01 18 30 82 01 14 02 01 01 30 69 30 5C 31 0B 30 09 06 03 55 04 06
13 02 55 53 31 19 30 17 06 03 55 04 08 13 10 57 61 73 68 69 6E 67 74 6F 6E 20 53 74 61 74
65 31 10 30 0E 06 03 55 04 07 13 07 53 65 61 74 74 6C 65 31 20 30 1E 06 03 55 04 0A 13 17
41 6D 61 7A 6F 6E 20 57 65 62 20 53 65 72 76 69 63 65 73 20 4C 4C 43 02 09 00 96 BA 48 D9
E5 5E 1A 67 30 09 06 05 2B 0E 03 02 1A 05 00 A0 5D 30 18 06 09 2A 86 48 86 F7 0D 01 09 03
31 0B 06 09 2A 86 48 86 F7 0D 01 07 01 30 1C 06 09 2A 86 48 86 F7 0D 01 09 05 31 0F 17 0D
31 39 30 37 31 36 32 30 33 37 33 39 5A 30 23 06 09 2A 86 48 86 F7 0D 01 09 04 31 16 04 14
B3 E4 71 1C 3E 3C E3 97 E2 9F 2A F3 1C E9 D9 34 94 C5 25 17 30 09 06 07 2A 86 48 CE 38 04
03 04 2F 30 2D 02 14 38 E8 54 8C C8 A2 40 B2 F2 8E 20 9F BF B8 C9 20 7E D9 BA 5B 02 15 00
98 7D 9B 68 99 D8 FF 5F DC EF F0 3B 7B 53 21 34 8E 6A 49 96 00 00 00 00 00 00
Hexedit's attempt to deserialize:
anceType" : "t2.micro".}......1.
..0......0i0\1.0...U....US1.0...
U....Washington State1.0...U....
Seattle1 0...U....Amazon Web Ser
vices LLC....K.Z..$.0...`.H.e...
....i0...*.H......1...*.H......0
...*.H......1...190716203739Z0/.
.*.H......1". m*...%......>.~.l.
...KbS.cQ.....0...*.H...........
.ib..-...`....y.z. Y..I.~=.8....
=JMR.......z...k.C.I.#.gm..G.G..
...$.w..>F.[...T].|%....2.fa.P..
c....:-..aZ..{..I6..n4.!.....z.@
...~....{ .K.".w.yz......IG...-.
md.c$.....3..?BP..&..,...Wu%.YOK
y..._....!...~..,C..r..4.-dxy`.F
`.T..Z....D.}ih....f...;....J.)o
.......
Notable are the strings "Amazon Web Services LLC", "Seattle", "Washington State", etc. This is probably DER encoded data, though I don't know that only a handful of bytes (296 bytes). I assume this is the signature portion with parts of the public key embedded.
pkcs7
Similar to rsa2048 above, this is composed of a header, body, and footer. The header is 54 bytes of binary data, the body is document, and the footer is 296 bytes long and includes some similar certificate-esque metadata.
signature
This file is 128 bytes long and appears to be a constant-size signature with no non-binary data.
#1 has dealt with almost every edge-case that I can find, outside of the instance identity stuff, which is largely cryptographic data signing a given document. There are a few keys in
/${api_version}/dynamic/instance-identity/*:document: a JSON dictionary describing facts about the instance.rsa2048: an undocumented item which appears to be an RSA signature ofdocument, which does embed thedocumentdata within itself.pkcs7: A PKCS#7 signature which embedsdocumentwithin itself.signature: An unknown format of a signature overdocumentwithoutdocumentembedded within it.The most ideal thing to do would be to generate a valid set of signatures for our emended
documentsuch that, provided that clients use our cert, clients could successfully validate our data identically to the way that it normally works on EC2.Unfortunately, this doesn't seem to be possible so I'm filing my findings here.
Next we will inspect the files and try to understand what's going on therein.
documentThe actual document looks like this:
{ "accountId" : "012345678901", "availabilityZone" : "us-west-2a", "ramdiskId" : null, "kernelId" : null, "pendingTime" : "2019-07-16T22:04:00Z", "architecture" : "x86_64", "privateIp" : "10.0.0.1", "devpayProductCodes" : null, "marketplaceProductCodes" : null, "version" : "2017-09-30", "region" : "us-west-2", "imageId" : "ami-deadbeefcafebabe", "billingProducts" : null, "instanceId" : "i-deadbeefcafebabe", "instanceType" : "t2.micro" }Pretty standard instance metadata, including
regionwhich isn't exposed elsewhere.rsa2048I am zero-indexing bytes.
Header
Bytes 0-53 (inclusive) appear to be a binary header of some format.
Python byte encoded:
Hex encoding:
This does not appear to be any ASCII data.
Document
After the header is the document in ASCII, in my case bytes 54 through 531 inclusive.
Footer
After the document, the footer begins at byte 532 and continues to the end of the document at byte 827.
Python byte encoded:
Hex encoding:
Hexedit's attempt to deserialize:
Notable are the strings "Amazon Web Services LLC", "Seattle", "Washington State", etc. This is probably DER encoded data, though I don't know that only a handful of bytes (296 bytes). I assume this is the signature portion with parts of the public key embedded.
pkcs7Similar to
rsa2048above, this is composed of a header, body, and footer. The header is 54 bytes of binary data, the body isdocument, and the footer is 296 bytes long and includes some similar certificate-esque metadata.signatureThis file is 128 bytes long and appears to be a constant-size signature with no non-binary data.