{ "items": [ { "type": [ "h-entry" ], "properties": { "name": [ "How DCI Movie Delivery and Encryption works" ], "category": [ "digital cinema", "projects", "reverse engineering", "security" ], "summary": [ "The Cinema Industry is using its own standards for creating and distributing movies in a secure way. The DCI (Digital Cinema Initiatives) specification defines everything from file formats and encryption to the projection systems itself." ], "url": [ "https://serverless.industries/2024/05/31/digital-cinema.en.html" ], "published": [ "2024-05-31" ], "content": [ { "html": "

The Cinema Industry is using its own standards for creating and distributing movies in a secure way. The DCI (Digital Cinema Initiatives) specification defines everything from file formats and encryption to the projection systems itself.

\n\n

The specification itself is publicly available but relies on various IEEE (Institute of Electrical and Electronics Engineers) and SMPTE (Society of Motion Picture and Television Engineers) standards, which have to be purchased.

\n\n

Scope

\n\n

This document will show a rough overview of the DCI workflow and describe in detail how the encryption of a DCI movie works. It will not show how to break any encryption and no encryption has been broken while writing this document. From our perspective, the DCI standard is safe.

\n\n

The author of this document has been operating a cinema since 2021, without any insight to the distribution or production side of the industry. Some information may be incomplete.

\n\n

How it\u2019s started

\n\n

End of 2023 the movie WONKA was released. Some cinemas reported, that they are unable to start this movie on their projector.

\n\n

The reason was, that a certificate used by the distributor was expired. This certificate was used to sign the DCP files.

\n\n

The distributor published new files, starting the movie worked again.

\n\n

Out of curiosity the author started to check how the validation process on the projector is working.

\n\n

Glossar

\n\n\n\n

Distribution Process

\n\n
graph TD\n    classDef red fill:#a91900\n    classDef green fill:#126500\n    classDef purple fill:#650072\n    legendprod[Producer]:::red\n    legenddist[Distributor]:::green\n    legendcine[Cinema]:::purple\n    legendvendors[Projector Manufacturer]\n
\n\n
graph LR\n    classDef red fill:#a91900\n    classDef green fill:#126500\n    classDef purple fill:#650072\n\n    dcpcreated([\"DCP\\ncreated\"]):::red --\"AES Key\"--> dkdmcreated\n    dkdmcreated([\"DKDM\\ncreated\"]):::red --\"encrypted\\nAES Key\"--> dkdmp\n    \n    dkdmp[DKDM]:::green --> verify([\"Projector\\nverified\"]):::green\n    dcpcreated --\"to Distributor\"--> dcp([\"DCP by\\nDownload or\\nHarddrive\"]):::green\n    distcert[\"Distributor\\nCertificate\"]:::green --\"to Producer\"--> dkdmcreated\n    \n    verify --\"to Cinema\"--> kdm[KDM]:::purple\n    dcp --\"to Cinema\"--> dcp2[\"DCP\"]:::purple\n    cinecert[\"Projector\\nCertificate\"]:::purple --\"to Distributor\"--> verify\n    trusted[\"Trusted Device List\"] --> verify\n    dcp2 --> projector[Projector]:::purple\n    kdm --> projector\n
\n\n

Projection Systems

\n\n

Most of the Projection Systems consists of Server, Audio Processor and Projector.

\n\n
graph LR\n  server[Server] --> mediablock[Media Block]\n  hdmi[HDMI Source] --> splitter[Audio Splitter]\n  splitter --\"Video\"--> projector\n  splitter --\"Audio\"--> sound\n  subgraph Projector\n   mediablock --\"Video\"--> projector[Projector]\n  end\n  \n  projector --> screen[Theatre Screen]\n  mediablock --\"Audio\"--> sound[Audio Processor]\n  sound --> speakers[Speakers]\n
\n\n

The Server stores the DCPs and KDMs, manages Playlists and controls the Projector and Audio Processor hardware.

\n\n

Many Cinemas also connect their Theatre Automation (light, curtains, etc.) to the projector. By setting time-based commands into the playlists, lights and screen curtain can be controlled automatically. The Projector Server provides 12V/24V relays for this.

\n\n

These time-based commands are also used to set the correct Aspect Ratio and Volume on the different DCPs in a Playlist.

\n\n

The Server can be controlled remotely by a PC or in larger cinemas by a Theatre Management System.

\n\n

The DCPs are imported from USB/CRU hard drives or by internet download to the server. They are stored encrypted at all times.

\n\n

The projector includes a so called \u201cMedia Block\u201d which handles DRM and decryption. It receives the DCP data and the KDM to decrypt each frame in real time.

\n\n

On DCP playback the Projector will send the decrypted PCM audio to the Audio Processor which will then send each processed Audio Channel to the respective Speakers.

\n\n

\"DCP

\n\n

DCP Format

\n\n

A DCP is a folder which contains XML metadata files and multiple MXF files for the actual movie.

\n\n

Folder Naming Pattern

\n\n
AwesomeMovie_FTR-2_S_DE-XX_DE-16_51_4K_20240119_SMPTE_OV\n
\n\n\n\n

Credits: http://static.kinofreund.com/dcnt/

\n\n

Mastering Process

\n\n

During the Mastering Process a static AES 128 bit key is generated and the original medium is converted into MXF files. One for picture and one for audio.

\n\n

For mastering the tool DCP-o-matic can be used. There are also some commercial products.

\n\n
graph LR\n    movie[\"Source\"] --> mastering{{\"Movie Mastering\"}}\n    mastering --> dcpkey[\"Static<br>AES-128 Key\"]\n    mastering --> dcp[\"Digital Cinema Package (DCP)\"]\n    dcp --> dcppics[\"Encrypted<br>Picture Data\"]\n    dcp --> dcpsound[\"Encrypted<br>Audio Data\"]\n    dcp --> dcpsub[\"Encrypted<br>Subtitle Data\"]\n
\n\n

The video stream is encoded as one single JPEG2000 picture per frame. Each frame is encrypted with the same static AES key.

\n\n

The audio stream is (most likely) chunked into one BWF (Broadcast Wave Format) stream per frame and also encrypted separately. (The author haven\u2019t found any information about this yet.)

\n\n

A DCP can have a size of 200 GB or more. Some newer releases can hit the Terabyte, if multiple versions (Languages, Subtitles, 2D/3D) are shipped on the same harddrive.

\n\n

The subtitles are provided in an XML file or are burned directly into the picture frames. If it is provided as an XML file, the projector will render the subtitles using a TTF font file.

\n\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<DCSubtitle Version=\"1.0\">\n    <SubtitleID>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</SubtitleID>\n    <MovieTitle>MovieTitle</MovieTitle>\n    <ReelNumber>1</ReelNumber>\n    <Language>de</Language>\n    <LoadFont Id=\"Font1\" URI=\"Arial.ttf\" />\n    <Font Id=\"Font1\" Color=\"ffffffff\" Effect=\"border\" EffectColor=\"ff000000\" Italic=\"no\" Script=\"normal\" Size=\"42\" Underlined=\"no\" Weight=\"normal\" AspectAdjust=\"1\" Spacing=\"0em\">\n        <Subtitle SpotNumber=\"1\" TimeIn=\"00:07:45:094\" TimeOut=\"00:07:48:000\" FadeUpTime=\"000\" FadeDownTime=\"000\">\n            <Text HPosition=\"0\" VAlign=\"bottom\" VPosition=\"7\">W\u00dcSTE VON NEVADA - HEUTE</Text>\n        </Subtitle>\n    </Font>\n</DCSubtitle>\n
\n\n

Supplemental DCP (VF, Version File)

\n\n

A supplemental DCP allows to reuse the Original DCP (OV, Original File) picture and replace audio or subtitle tracks. This makes it possible to support different languages without the need of shipping hundreds of gigabytes of duplicated picture data to the cinemas.

\n\n
graph TD\n    f[PaktDerWoelfe_FTR_S-235_FR-XX_DE_51_4K_SC_20230926_EGB_SMPTE_OV]\n    f --> a[PaktDerWoelBoC_FTR_S-235_DE-DE_DE_51_4K_SC_20231115_EGB_SMPTE_VF]\n    f --> b[PaktDerWoelBoC_FTR_S-235_FR-DE_DE_51_4K_SC_20231115_EGB_SMPTE_VF]\n
\n\n

Example: One version file for German with German subtitles and one for French with German subtitles.

\n\n

It is even possible to provide differnt cuts of a movie for different regions.

\n\n

Software

\n\n

Two Open Source C++ implementations, both in active development, one from the industry!

\n\n

cth103/libdcp, a C++ library written by the makers of DCP-o-matic:

\n\n\n\n

asdcplib, a C++ library written by companies active in the cinema industry:

\n\n
\n

The asdcplib project was originally exchanged by FTP. The project was on SourceForge between 2005 and 2008, when it moved to a release-only distribution via CineCert. As of late February 2019, its new home is on github.

\n\n

\u2013 https://github.com/cinecert/asdcplib

\n
\n\n

Almost all software, commercial or open source is using one of these libraries.

\n\n

Distribution

\n\n

The symmetric encryption key for the DCP has to be protected in some way. For this, the producer will create a DKDM XML file, containing the AES Key, which has been encrypted with the Certificate Public Key of the distributor.

\n\n

The distributor can then use the DKDM to create KDM XML files for cinemas. This means decrypting the DCP AES Key and encrypting it again with the Certificate Public Key of the target projection system.

\n\n

Certificate Chains

\n\n

Both projectors and distributors use SSL certificate chains to sign and encrypt/decrypt data.

\n\n

A chain always consists of a Root Certificate Authority (CA), Intermediate CA and a Leaf Certificate.

\n\n
graph TD\n    a[\"dnQualifier=ZwVjULQy61,CN=.smpte-430-2.root,OU=movies.serverless.industries,O=serverless.industries\"]\n    a --> b[\"dnQualifier=/JLF0JtscFuJahVNXfYu1w1u7SI=,CN=.smpte-430-2.intermediate,OU=movies.serverless.industries,O=serverless.industries\"]\n    b --> c[\"dnQualifier=TEqiLeRuVnkbNOUsPlbDHIdp1tM=,CN=CS.smpte-430-2.leaf,OU=movies.serverless.industries,O=serverless.industries\"]\n
\n\n

The field dnQualifier in the subject is the fingerprint of the public key of the generated certificate:

\n\n
cat leaf.pem | openssl x509 -pubkey -noout | \\\n    openssl base64 -d | dd bs=1 skip=24 2>/dev/null | \\\n    openssl sha1 -binary | openssl base64\n
\n\n

Script for creating a certificate chain: create-smpte-chain.sh

\n\n

Key Delivery Messages

\n\n

A KDM is a XML file which contains the AES key of the DCP encrypted with the projectors Public Key.

\n\n\n\n

Decrypt the <enc:CipherValue> with openssl:

\n\n
cat KDM_KaizoTrap_FTR-1_F_XX-XX_20_2K_20240119_SMPTE_OV_My_nonexistent_cinema_Nonexistent_Screen_1.xml | \\\n    xq -r '.DCinemaSecurityMessage.AuthenticatedPrivate.\"enc:EncryptedKey\"[0].\"enc:CipherData\".\"enc:CipherValue\"' | \\\n    base64 -d | \\\n    openssl pkeyutl -decrypt -inkey leaf.key -pkeyopt rsa_padding_mode:oaep > kdminfo.bin\n
\n\n

Output of hexdump -C kdminfo.bin:

\n\n
00000000  f1 dc 12 44 60 16 9a 0e  85 bc 30 06 42 f8 66 ab  |...D`.....0.B.f.|\n00000010  28 fd 80 bf a9 bb f1 dc  48 d9 87 e9 5c c9 a5 41  |(.......H...\\..A|\n00000020  ab 8e 14 82 88 40 c3 90  2a 0b 46 21 b4 10 49 6b  |.....@..*.F!..Ik|\n00000030  b8 a4 a9 4f 4d 44 41 4b  2e 2e 05 b5 bb ed 45 79  |...OMDAK......Ey|\n00000040  96 cc 9c d6 00 ed db 4c  32 30 32 34 2d 30 31 2d  |.......L2024-01-|\n00000050  32 38 54 31 39 3a 30 30  3a 30 30 2b 30 31 3a 30  |28T19:00:00+01:0|\n00000060  30 32 30 32 34 2d 30 32  2d 30 34 54 32 30 3a 30  |02024-02-04T20:0|\n00000070  30 3a 30 30 2b 30 31 3a  30 30 4c 3a b6 ed 71 eb  |0:00+01:00L:..q.|\n00000080  29 25 90 48 6b 4f 96 2f  44 f6                    |)%.HkO./D.|\n0000008a\n
\n\n

The file can now be sliced into single fields with dd:

\n\n
# fingerprint base64 encoded\ndd if=kdminfo.bin bs=1 skip=16 count=20 status=none | base64\n\n# AES key in hexadecimal\ndd if=kdminfo.bin bs=1 skip=122 count=16 status=none | hexdump -C\n\n# date string in plain text ASCII\ndd if=kdminfo.bin bs=1 skip=97 count=25 status=none; echo\n
\n\n

Format:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
StartLengthDescription
016Structure ID, binary, static 0xf1dc124460169a0e85bc300642f866ab\n
1620Signer certificate fingerprint, binary, KP2Av6m78dxI2YfpXMmlQauOFII=\n
3616Composition Playlist UUID, 8840c390-2a0b-4621-b410-496bb8a4a94f\n
524Key Type, ASCII, MDAK = Main Sound
5616Key UUID, 2e2e05b5-bbed-4579-96cc-9cd600eddb4c\n
7225Not valid before date string, ASCII, 2024-01-28T19:00:00+01:00\n
9725Not valid after date string, ASCII, 2024-02-04T20:00:00+01:00\n
12216AES decryption key, binary, 0x4c3ab6ed71eb292590486b4f962f44f6\n
\n\n\n\n
openssl asn1parse -in leaf.pem -noout -strparse 4 -out - | \\\n    openssl dgst -sha1 -binary | \\\n    openssl base64\n
\n\n\n\n

(This is a subset of checks documented in the DCI Compliance Test Plan)

\n\n

The projector itself has no trusted CA store for validating KDMs or DCPs. The whole process relies on the fingerprint stored in the <enc:CipherValue> and that the recipient cinema has no access to the Projectors Private Key.

\n\n

Trusted Device List

\n\n

Could one just build their own DCI/DCP projector?

\n\n

Yes and no.

\n\n

The software exists, in theory just a Linux PC and any projector / sound system is required.

\n\n

The distributors use a so called \u201cTrusted Device List\u201d provided by the DCI certified projection system manufacturers. Projectors which are not mentioned on these lists will not get a DCP/KDM from many distributors.

\n\n

Also a DCI certified projection system must be installed by an authorized company.

\n\n\n\n

If a cinema is not \u201cplaying by the rules\u201d, a 30k+ EUR projection system will become an expensive brick.

\n\n

MXF File Format

\n\n

MXF is used by the whole movie and broadcasting industry.

\n\n

The paper of the SMPTE standard is again purchase-only.

\n\n

Since the standard is quite complex, the Author used MXFInspect as a shortcut and only parsed a single Frame / Triplet.

\n\n

BER Encoding

\n\n

Basic Encoding Rules:

\n\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
BER IndicatorLengthContent
\n0x83 = 10000011b
= 3 bytes for length		\n0x004F0C
= 20236d\n		20236 bytes of data
\n\n

Triplet Format (Single Movie Frame)

\n\n

Frame Triplet Structure

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
StartTypeLengthDescription
0DAT16Encrypted triplet key
16BER1BER 0x83 = 10000011b = Next field is 3 bytes long
17LEN3\n0x004F0C = 20236d = Length of the data
20BER1BER 0x83 = 10000011b = Next field is 3 bytes long
21LEN3\n0x000010 = 16d = Length of the next field
24DAT16Cryptographic Context Link
40BER1BER 0x83 = 10000011b = Next field is 3 bytes long
41LEN3\n0x000008 = 8d = Length of the next field
44DAT8Plaintext offset
52BER1BER 0x83 = 10000011b = Next field is 3 bytes long
53LEN3\n0x000010 = 16d = Length of the next field
56DAT16Source Key
72BER1BER 0x83 = 10000011b = Next field is 3 bytes long
73LEN3\n0x000008 = 8d = Length of the next field
76DAT8Source Length
84BER1BER 0x83 = 10000011b = Next field is 3 bytes long
85LEN3\n0x004e90 = 20112d = Length of the next field
88DAT20112Encrypted Source Value
\n\n\n\n

Slice the data

\n\n
# slice the first frame from the MXF bodypartition\n# offsets from MXFInspect\ndd if=file.mxf bs=1 count=20256 skip=16524 of=block.bin\n\n# slice data from the frame\ndd if=block.bin skip=88 count=20112 bs=1 of=block-encrypted-data.bin\n
\n\n

Decrypt Frame Data

\n\n

The DCP encryption key: 4c3ab6ed71eb292590486b4f962f44f6

\n\n

The frame IV

\n\n

Every Frame is using a unique IV (Initialization Vector), which ensures that the AES Block Cipher generates always different cipher texts and makes brute force harder. This works similar to a Password Salt.

\n\n
# the data starts with 16 bytes of iv and 16 bytes of cv\n# AES iv bytes\ndd if=block-encrypted-data.bin bs=1 count=16 of=iv.bin\n
\n\n

Output of hexdump -C iv.bin:

\n\n
00000000  16 6e 7b d1 67 81 44 2e  7a ca de 3c 46 cc d7 39  |.n{.g.D.z..<F..9|\n00000010\n
\n\n

See also \u201cECB Penguin\u201d on $searchengine for more details why the IV is so important.

\n\n

Validate CV

\n\n

Since there is no way to know if a decryption was successful when the content of the data is unknown, a CV (Check Value) is used. The Check Value is encrypted with the same AES Key + IV, but the plain text value is known.

\n\n
# the data starts with 16 bytes of iv and 16 bytes of cv\n# AES cv bytes\ndd if=block-encrypted-data.bin bs=1 count=16 skip=16 of=cv.bin\n
\n\n
cat cv.bin | openssl enc -aes128 -d \\\n    -K 4c3ab6ed71eb292590486b4f962f44f6 \\\n    -iv 166e7bd16781442e7acade3c46ccd739 \\\n    -nosalt -nopad | hexdump -C\n
\n\n
00000000  43 48 55 4b 43 48 55 4b  43 48 55 4b 43 48 55 4b  |CHUKCHUKCHUKCHUK|\n00000010\n
\n\n

If the result matches 0x4348554B4348554B4348554B4348554B the key is correct.

\n\n

Decrypt data

\n\n
# Remove IV and CV from the encrypted data block\ndd bs=1 skip=32 \\\n    if=block-encrypted-data.bin \\\n    of=block-encrypted-data-nocryptinfo.bin\n
\n\n
# Decrypt data block\ncat block-encrypted-data-nocryptinfo.bin | \\\n    openssl enc -aes128 -d \\\n        -K 4c3ab6ed71eb292590486b4f962f44f6 \\\n        -iv 166e7bd16781442e7acade3c46ccd739 \\\n        -nosalt -nopad > block-decrypted-data.bin\n
\n\n

MXFs created by DCP-o-Matic contain libdcp in the hexdump, which indicates that the decryption was successful.

\n\n

Output of hexdump -C block-decrypted-data.bin | head:

\n\n
00000000  3a f0 b7 f5 53 49 eb b7  c0 c0 cb a5 c9 2f 35 19  |:...SI......./5.|\n00000010  00 00 00 00 00 00 00 00  00 00 07 ce 00 00 04 38  |...............8|\n00000020  00 00 00 00 00 00 00 00  00 03 0b 01 01 0b 01 01  |................|\n00000030  0b 01 01 ff 52 00 12 01  04 00 01 01 05 03 03 00  |....R...........|\n00000040  00 77 88 88 88 88 88 ff  5c 00 23 22 97 20 96 f0  |.w......\\.#\". ..|\n00000050  96 f0 96 c0 8f 00 8f 00  8e e0 87 50 87 50 87 68  |...........P.P.h|\n00000060  70 05 70 05 70 47 77 d3  77 d3 77 62 ff 55 00 13  |p.p.pGw.w.wb.U..|\n00000070  00 50 00 00 00 4d 40 00  00 00 00 49 00 00 00 00  |.P...M@....I....|\n00000080  49 ff 64 00 0a 00 01 6c  69 62 64 63 70 ff 90 00  |I.d....libdcp...|\n00000090  0a 00 00 00 00 4d 40 00  03 ff 93 ef fe 2c 71 ff  |.....M@......,q.|\n
\n\n

Magic Signatures

\n\n

At first, the decrypted Frame could not be opened in GIMP.

\n\n

To enable programs to open a file in the correct way, many files contain so called \u201cMagic Signatures\u201d at its beginning.

\n\n

This magic value in block-decrypted-data.bin is incorrect for unknown reasons. When extracting a JPEG2000 frame from an unencrypted MXF, the signature is correct. As a simple hack, the author just copied the signature from the unencrypted MXF frame to the decrypted one:

\n\n
# offset again from MXFInspect\ndd if=j2c_caa6b39e-bd57-4676-9797-112e96a6f0c3.mxf bs=1 skip=16524 count=20085 of=frame.bin\n\n# unencrypted frame does not contain crypto info\n# so we just have to slice the first BER header\ndd if=framedata.bin.j2k bs=1 skip=20 count=16 of=j2k_header.bin\n\n# now back to the decrypted mxf frame\n# replace signature\ncp j2k_header.bin frame.j2k\ndd if=block-decrypted-data.bin bs=1 skip=16 >> image.j2k\n
\n\n

It should now be possible to open the file in GIMP. GIMP will show the frame with wrong colors, as MXF files use a custom color space.

\n\n

\"Movie

\n\n

The original Frame with correct colors:

\n\n

\"Movie

\n\n

Credit: Kaizo Trap by Guy Collins Animation

\n\n

Why it\u2019s safe

\n\n

Everything relies on \u201cnever reusing AES Keys\u201d and \u201cprotected private keys\u201d.

\n\n\n\n

\"Encryption

\n\n

Source: xkcd.com/538/

\n\n

Just record it

\n\n

Encrypted DCPs use Forensic Watermarks which contain the serial number of the\nprojection system. So if a recorded copy of a movie appears online, the theatre will have to answer\nserious questions and may never get movies again.

\n\n

Pirated copies of movies have it\u2019s origin most likely from other sources.

\n\n

How it\u2019s going

\n\n

DCI has released version 1.4.4 of the specification, which now allows playback of DCPs with expired signer certificate.

\n\n

The manufacturers already started to work on a software update.

\n\n

Sources

\n\n\n\n

Credits

\n\n

Thanks for reading and feedback goes to: Pliskin, babel

\n\n

There are alot of comments on Hacker News.

", "value": "The Cinema Industry is using its own standards for creating and distributing movies in a secure way. The DCI (Digital Cinema Initiatives) specification defines everything from file formats and encryption to the projection systems itself.\nThe specification itself is publicly available but relies on various IEEE (Institute of Electrical and Electronics Engineers) and SMPTE (Society of Motion Picture and Television Engineers) standards, which have to be purchased. Scope\nThis document will show a rough overview of the DCI workflow and describe in detail how the encryption of a DCI movie works. It will not show how to break any encryption and no encryption has been broken while writing this document. From our perspective, the DCI standard is safe.\nThe author of this document has been operating a cinema since 2021, without any insight to the distribution or production side of the industry. Some information may be incomplete. How it\u2019s started\nEnd of 2023 the movie WONKA was released. Some cinemas reported, that they are unable to start this movie on their projector.\nThe reason was, that a certificate used by the distributor was expired. This certificate was used to sign the DCP files.\nThe distributor published new files, starting the movie worked again.\nOut of curiosity the author started to check how the validation process on the projector is working. Glossar DCP: Digital Cinema Package - A folder which contains all components of a movie. Metadata, Subtitles, Audio and Picture in seperate files CPL: Composition Playlist - A DCP can contain multiple audio and video streams which will combined in a CPL KDM: Key Delivery Message - A XML file which contains the cryptographical information to allow a movie playback on a specific DCI certified projection system DKDM: Distribution Key Delivery Message - Similar to a KDM, but for a remastering or distribution system, not for a projection system Distribution Process graph TD classDef red fill:#a91900 classDef green fill:#126500 classDef purple fill:#650072 legendprod[Producer]:::red legenddist[Distributor]:::green legendcine[Cinema]:::purple legendvendors[Projector Manufacturer] graph LR classDef red fill:#a91900 classDef green fill:#126500 classDef purple fill:#650072 dcpcreated([\"DCP\\ncreated\"]):::red --\"AES Key\"--> dkdmcreated dkdmcreated([\"DKDM\\ncreated\"]):::red --\"encrypted\\nAES Key\"--> dkdmp dkdmp[DKDM]:::green --> verify([\"Projector\\nverified\"]):::green dcpcreated --\"to Distributor\"--> dcp([\"DCP by\\nDownload or\\nHarddrive\"]):::green distcert[\"Distributor\\nCertificate\"]:::green --\"to Producer\"--> dkdmcreated verify --\"to Cinema\"--> kdm[KDM]:::purple dcp --\"to Cinema\"--> dcp2[\"DCP\"]:::purple cinecert[\"Projector\\nCertificate\"]:::purple --\"to Distributor\"--> verify trusted[\"Trusted Device List\"] --> verify dcp2 --> projector[Projector]:::purple kdm --> projector Projection Systems\nMost of the Projection Systems consists of Server, Audio Processor and Projector. graph LR server[Server] --> mediablock[Media Block] hdmi[HDMI Source] --> splitter[Audio Splitter] splitter --\"Video\"--> projector splitter --\"Audio\"--> sound subgraph Projector mediablock --\"Video\"--> projector[Projector] end projector --> screen[Theatre Screen] mediablock --\"Audio\"--> sound[Audio Processor] sound --> speakers[Speakers]\nThe Server stores the DCPs and KDMs, manages Playlists and controls the Projector and Audio Processor hardware.\nMany Cinemas also connect their Theatre Automation (light, curtains, etc.) to the projector. By setting time-based commands into the playlists, lights and screen curtain can be controlled automatically. The Projector Server provides 12V/24V relays for this.\nThese time-based commands are also used to set the correct Aspect Ratio and Volume on the different DCPs in a Playlist.\nThe Server can be controlled remotely by a PC or in larger cinemas by a Theatre Management System.\nThe DCPs are imported from USB/CRU hard drives or by internet download to the server. They are stored encrypted at all times.\nThe projector includes a so called \u201cMedia Block\u201d which handles DRM and decryption. It receives the DCP data and the KDM to decrypt each frame in real time.\nOn DCP playback the Projector will send the decrypted PCM audio to the Audio Processor which will then send each processed Audio Channel to the respective Speakers.\nDCP Disks DCP Format\nA DCP is a folder which contains XML metadata files and multiple MXF files for the actual movie. Folder Naming Pattern AwesomeMovie_FTR-2_S_DE-XX_DE-16_51_4K_20240119_SMPTE_OV AwesomeMovie: A short version of the movie title FTR: Media Type, in this case \u201cFeature\u201d 2: Version Number S: Aspect ratio, in this case 2.35:1 aka \u201cSope\u201d DE: Audio Language XX: Subtitle Language, in this case is no subtitle available DE: Territory 16: Age Rating 51: Audio channels, in this case 5.1 surround sound 4K: Movie resolution, in this case 4096x1716 pixels 20240119: Mastering timestamp SMPTE: DCP standard, there is also Interop OV: Package type, original version or VF for version file\nCredits: http://static.kinofreund.com/dcnt/ Mastering Process\nDuring the Mastering Process a static AES 128 bit key is generated and the original medium is converted into MXF files. One for picture and one for audio.\nFor mastering the tool DCP-o-matic can be used. There are also some commercial products. graph LR movie[\"Source\"] --> mastering{{\"Movie Mastering\"}} mastering --> dcpkey[\"Static
AES-128 Key\"] mastering --> dcp[\"Digital Cinema Package (DCP)\"] dcp --> dcppics[\"Encrypted
Picture Data\"] dcp --> dcpsound[\"Encrypted
Audio Data\"] dcp --> dcpsub[\"Encrypted
Subtitle Data\"]\nThe video stream is encoded as one single JPEG2000 picture per frame. Each frame is encrypted with the same static AES key.\nThe audio stream is (most likely) chunked into one BWF (Broadcast Wave Format) stream per frame and also encrypted separately. (The author haven\u2019t found any information about this yet.)\nA DCP can have a size of 200 GB or more. Some newer releases can hit the Terabyte, if multiple versions (Languages, Subtitles, 2D/3D) are shipped on the same harddrive.\nThe subtitles are provided in an XML file or are burned directly into the picture frames. If it is provided as an XML file, the projector will render the subtitles using a TTF font file. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx MovieTitle 1 de W\u00dcSTE VON NEVADA - HEUTE Supplemental DCP (VF, Version File)\nA supplemental DCP allows to reuse the Original DCP (OV, Original File) picture and replace audio or subtitle tracks. This makes it possible to support different languages without the need of shipping hundreds of gigabytes of duplicated picture data to the cinemas. graph TD f[PaktDerWoelfe_FTR_S-235_FR-XX_DE_51_4K_SC_20230926_EGB_SMPTE_OV] f --> a[PaktDerWoelBoC_FTR_S-235_DE-DE_DE_51_4K_SC_20231115_EGB_SMPTE_VF] f --> b[PaktDerWoelBoC_FTR_S-235_FR-DE_DE_51_4K_SC_20231115_EGB_SMPTE_VF]\nExample: One version file for German with German subtitles and one for French with German subtitles.\nIt is even possible to provide differnt cuts of a movie for different regions. Software\nTwo Open Source C++ implementations, both in active development, one from the industry!\ncth103/libdcp, a C++ library written by the makers of DCP-o-matic: https://git.carlh.net/gitweb/?p=dcpomatic.git;a=shortlog https://dcpomatic.com/ (source code)\nasdcplib, a C++ library written by companies active in the cinema industry:\nThe asdcplib project was originally exchanged by FTP. The project was on SourceForge between 2005 and 2008, when it moved to a release-only distribution via CineCert. As of late February 2019, its new home is on github.\n\u2013 https://github.com/cinecert/asdcplib\nAlmost all software, commercial or open source is using one of these libraries. Distribution\nThe symmetric encryption key for the DCP has to be protected in some way. For this, the producer will create a DKDM XML file, containing the AES Key, which has been encrypted with the Certificate Public Key of the distributor.\nThe distributor can then use the DKDM to create KDM XML files for cinemas. This means decrypting the DCP AES Key and encrypting it again with the Certificate Public Key of the target projection system. Certificate Chains\nBoth projectors and distributors use SSL certificate chains to sign and encrypt/decrypt data.\nA chain always consists of a Root Certificate Authority (CA), Intermediate CA and a Leaf Certificate. graph TD a[\"dnQualifier=ZwVjULQy61,CN=.smpte-430-2.root,OU=movies.serverless.industries,O=serverless.industries\"] a --> b[\"dnQualifier=/JLF0JtscFuJahVNXfYu1w1u7SI=,CN=.smpte-430-2.intermediate,OU=movies.serverless.industries,O=serverless.industries\"] b --> c[\"dnQualifier=TEqiLeRuVnkbNOUsPlbDHIdp1tM=,CN=CS.smpte-430-2.leaf,OU=movies.serverless.industries,O=serverless.industries\"]\nThe field dnQualifier in the subject is the fingerprint of the public key of the generated certificate: cat leaf.pem | openssl x509 -pubkey -noout | \\ openssl base64 -d | dd bs=1 skip=24 2>/dev/null | \\ openssl sha1 -binary | openssl base64\nScript for creating a certificate chain: create-smpte-chain.sh Key Delivery Messages\nA KDM is a XML file which contains the AES key of the DCP encrypted with the projectors Public Key. Various XML Schemas: SMPTE 430-1, SMPTE 430-3 Document signing with XML-DSig One or more elements contain the AES keys and some metadata for multiple DCP OV/VF, both encrypted\nDecrypt the with openssl: cat KDM_KaizoTrap_FTR-1_F_XX-XX_20_2K_20240119_SMPTE_OV_My_nonexistent_cinema_Nonexistent_Screen_1.xml | \\ xq -r '.DCinemaSecurityMessage.AuthenticatedPrivate.\"enc:EncryptedKey\"[0].\"enc:CipherData\".\"enc:CipherValue\"' | \\ base64 -d | \\ openssl pkeyutl -decrypt -inkey leaf.key -pkeyopt rsa_padding_mode:oaep > kdminfo.bin\nOutput of hexdump -C kdminfo.bin: 00000000 f1 dc 12 44 60 16 9a 0e 85 bc 30 06 42 f8 66 ab |...D`.....0.B.f.| 00000010 28 fd 80 bf a9 bb f1 dc 48 d9 87 e9 5c c9 a5 41 |(.......H...\\..A| 00000020 ab 8e 14 82 88 40 c3 90 2a 0b 46 21 b4 10 49 6b |.....@..*.F!..Ik| 00000030 b8 a4 a9 4f 4d 44 41 4b 2e 2e 05 b5 bb ed 45 79 |...OMDAK......Ey| 00000040 96 cc 9c d6 00 ed db 4c 32 30 32 34 2d 30 31 2d |.......L2024-01-| 00000050 32 38 54 31 39 3a 30 30 3a 30 30 2b 30 31 3a 30 |28T19:00:00+01:0| 00000060 30 32 30 32 34 2d 30 32 2d 30 34 54 32 30 3a 30 |02024-02-04T20:0| 00000070 30 3a 30 30 2b 30 31 3a 30 30 4c 3a b6 ed 71 eb |0:00+01:00L:..q.| 00000080 29 25 90 48 6b 4f 96 2f 44 f6 |)%.HkO./D.| 0000008a\nThe file can now be sliced into single fields with dd: # fingerprint base64 encoded dd if=kdminfo.bin bs=1 skip=16 count=20 status=none | base64 # AES key in hexadecimal dd if=kdminfo.bin bs=1 skip=122 count=16 status=none | hexdump -C # date string in plain text ASCII dd if=kdminfo.bin bs=1 skip=97 count=25 status=none; echo\nFormat: Start Length Description 0 16 Structure ID, binary, static 0xf1dc124460169a0e85bc300642f866ab 16 20 Signer certificate fingerprint, binary, KP2Av6m78dxI2YfpXMmlQauOFII= 36 16 Composition Playlist UUID, 8840c390-2a0b-4621-b410-496bb8a4a94f 52 4 Key Type, ASCII, MDAK = Main Sound 56 16 Key UUID, 2e2e05b5-bbed-4579-96cc-9cd600eddb4c 72 25 Not valid before date string, ASCII, 2024-01-28T19:00:00+01:00 97 25 Not valid after date string, ASCII, 2024-02-04T20:00:00+01:00 122 16 AES decryption key, binary, 0x4c3ab6ed71eb292590486b4f962f44f6 Validate signer certificate: Should match the fingerprint of the leaf certificate used to sign the KDM XML structure openssl asn1parse -in leaf.pem -noout -strparse 4 -out - | \\ openssl dgst -sha1 -binary | \\ openssl base64 Validate Composition Playlist UUID: Should appear in the KDM XML field Validate Key UUID: Should appear in the KDM XML field Validate Key Type: Should match the type for the respective Key UUID block Validate Dates: Should appear in the KDM XML fields and \n(This is a subset of checks documented in the DCI Compliance Test Plan)\nThe projector itself has no trusted CA store for validating KDMs or DCPs. The whole process relies on the fingerprint stored in the and that the recipient cinema has no access to the Projectors Private Key. Trusted Device List\nCould one just build their own DCI/DCP projector?\nYes and no.\nThe software exists, in theory just a Linux PC and any projector / sound system is required.\nThe distributors use a so called \u201cTrusted Device List\u201d provided by the DCI certified projection system manufacturers. Projectors which are not mentioned on these lists will not get a DCP/KDM from many distributors.\nAlso a DCI certified projection system must be installed by an authorized company. KDM Request by Serial Number: Many distributors just ask for projector model and serial number. They can query the actual projection system certificate in their distribution system KDM Request by Certificate: The cinema has to provide their projector certificate which is then validated against the projection systems manufacturer root certificate\nIf a cinema is not \u201cplaying by the rules\u201d, a 30k+ EUR projection system will become an expensive brick. MXF File Format\nMXF is used by the whole movie and broadcasting industry.\nThe paper of the SMPTE standard is again purchase-only.\nSince the standard is quite complex, the Author used MXFInspect as a shortcut and only parsed a single Frame / Triplet. BER Encoding\nBasic Encoding Rules: BER is indicated if the first bit of the byte is a 1 Bits 2-8 contain the number of bytes used for the length The length bytes contain the length of the data BER Indicator Length Content 0x83 = 10000011b\n= 3 bytes for length 0x004F0C\n= 20236d 20236 bytes of data Triplet Format (Single Movie Frame) Frame Triplet Structure Start Type Length Description 0 DAT 16 Encrypted triplet key 16 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 17 LEN 3 0x004F0C = 20236d = Length of the data 20 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 21 LEN 3 0x000010 = 16d = Length of the next field 24 DAT 16 Cryptographic Context Link 40 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 41 LEN 3 0x000008 = 8d = Length of the next field 44 DAT 8 Plaintext offset 52 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 53 LEN 3 0x000010 = 16d = Length of the next field 56 DAT 16 Source Key 72 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 73 LEN 3 0x000008 = 8d = Length of the next field 76 DAT 8 Source Length 84 BER 1 BER 0x83 = 10000011b = Next field is 3 bytes long 85 LEN 3 0x004e90 = 20112d = Length of the next field 88 DAT 20112 Encrypted Source Value Slice the data # slice the first frame from the MXF bodypartition # offsets from MXFInspect dd if=file.mxf bs=1 count=20256 skip=16524 of=block.bin # slice data from the frame dd if=block.bin skip=88 count=20112 bs=1 of=block-encrypted-data.bin Decrypt Frame Data\nThe DCP encryption key: 4c3ab6ed71eb292590486b4f962f44f6 The frame IV\nEvery Frame is using a unique IV (Initialization Vector), which ensures that the AES Block Cipher generates always different cipher texts and makes brute force harder. This works similar to a Password Salt. # the data starts with 16 bytes of iv and 16 bytes of cv # AES iv bytes dd if=block-encrypted-data.bin bs=1 count=16 of=iv.bin\nOutput of hexdump -C iv.bin: 00000000 16 6e 7b d1 67 81 44 2e 7a ca de 3c 46 cc d7 39 |.n{.g.D.z.. block-decrypted-data.bin\nMXFs created by DCP-o-Matic contain libdcp in the hexdump, which indicates that the decryption was successful.\nOutput of hexdump -C block-decrypted-data.bin | head: 00000000 3a f0 b7 f5 53 49 eb b7 c0 c0 cb a5 c9 2f 35 19 |:...SI......./5.| 00000010 00 00 00 00 00 00 00 00 00 00 07 ce 00 00 04 38 |...............8| 00000020 00 00 00 00 00 00 00 00 00 03 0b 01 01 0b 01 01 |................| 00000030 0b 01 01 ff 52 00 12 01 04 00 01 01 05 03 03 00 |....R...........| 00000040 00 77 88 88 88 88 88 ff 5c 00 23 22 97 20 96 f0 |.w......\\.#\". ..| 00000050 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 50 87 68 |...........P.P.h| 00000060 70 05 70 05 70 47 77 d3 77 d3 77 62 ff 55 00 13 |p.p.pGw.w.wb.U..| 00000070 00 50 00 00 00 4d 40 00 00 00 00 49 00 00 00 00 |.P...M@....I....| 00000080 49 ff 64 00 0a 00 01 6c 69 62 64 63 70 ff 90 00 |I.d....libdcp...| 00000090 0a 00 00 00 00 4d 40 00 03 ff 93 ef fe 2c 71 ff |.....M@......,q.| Magic Signatures\nAt first, the decrypted Frame could not be opened in GIMP.\nTo enable programs to open a file in the correct way, many files contain so called \u201cMagic Signatures\u201d at its beginning.\nThis magic value in block-decrypted-data.bin is incorrect for unknown reasons. When extracting a JPEG2000 frame from an unencrypted MXF, the signature is correct. As a simple hack, the author just copied the signature from the unencrypted MXF frame to the decrypted one: # offset again from MXFInspect dd if=j2c_caa6b39e-bd57-4676-9797-112e96a6f0c3.mxf bs=1 skip=16524 count=20085 of=frame.bin # unencrypted frame does not contain crypto info # so we just have to slice the first BER header dd if=framedata.bin.j2k bs=1 skip=20 count=16 of=j2k_header.bin # now back to the decrypted mxf frame # replace signature cp j2k_header.bin frame.j2k dd if=block-decrypted-data.bin bs=1 skip=16 >> image.j2k\nIt should now be possible to open the file in GIMP. GIMP will show the frame with wrong colors, as MXF files use a custom color space.\nMovie Screenshot with wrong color space\nThe original Frame with correct colors:\nMovie Screenshot with correct colors\nCredit: Kaizo Trap by Guy Collins Animation Why it\u2019s safe\nEverything relies on \u201cnever reusing AES Keys\u201d and \u201cprotected private keys\u201d. KDM data is encrypted with a 2048 bit RSA key MXF data is encrypted with AES-128 Decryption keys are always stored in TPM-like hardware Every DCP uses unique encryption keys Every projector uses unique certificates/keys A DCI certified projector is required Distributors can verify if a certificate belongs to a certified DCI projector\nEncryption Security\nSource: xkcd.com/538/ Just record it\nEncrypted DCPs use Forensic Watermarks which contain the serial number of the projection system. So if a recorded copy of a movie appears online, the theatre will have to answer serious questions and may never get movies again.\nPirated copies of movies have it\u2019s origin most likely from other sources. How it\u2019s going\nDCI has released version 1.4.4 of the specification, which now allows playback of DCPs with expired signer certificate.\nThe manufacturers already started to work on a software update. Sources DCI Specification DCI Compliance Test Plan OpenSSL Foo Key Types DC Tools by WolfgangW MXFInspect MXF Triplets SMPTE Standard MXF Triplet Encryption Showing jpeg2000 in Gimp / parsing jpeg2000 data from mxf List of magic signatures Forensic Watermarks in DCPs Credits\nThanks for reading and feedback goes to: Pliskin, babel\nThere are alot of comments on Hacker News.", "lang": "en" } ], "author": [ { "type": [ "h-card" ], "properties": { "name": [ "christian" ], "url": [ "https://serverless.industries/people/christian.html" ] }, "lang": "en", "value": "christian" } ] }, "lang": "en" }, { "type": [ "h-card" ], "properties": { "note": [ "Hi! \ud83d\udc4b My name is Christian. I am a software engineer with strong IT infra\u00adstructure skills. I help running the Cinema and Arthouse NEU-Deli in Einbeck in my freetime." ], "name": [ "Christian" ], "photo": [ { "value": "https://serverless.industries/christian.jpg", "alt": "Picture of Christian" } ], "url": [ "https://serverless.industries/people/christian.html" ], "uid": [ "https://serverless.industries/people/christian.html" ] }, "lang": "en" } ], "rels": { "stylesheet": [ "https://serverless.industries/css/main.css?commit=cc5a27a251b3c7815f33e676803e1803720b0e17", "https://serverless.industries/css/icons.css?commit=cc5a27a251b3c7815f33e676803e1803720b0e17" ], "webmention": [ "https://intercom.serverless.industries/webmentions/endpoint" ], "pingback": [ "https://intercom.serverless.industries/pingback/endpoint" ], "authorization_endpoint": [ "https://intercom.serverless.industries/auth/relme/auth" ], "token_endpoint": [ "https://intercom.serverless.industries/auth/relme/token" ], "indieauth-metadata": [ "https://intercom.serverless.industries/auth/relme/metadata" ], "micropub": [ "https://intercom.serverless.industries/micropub" ], "canonical": [ "https://serverless.industries/2024/05/31/digital-cinema.en.html" ], "alternate": [ "https://serverless.industries/feed/frontpage.xml" ], "search": [ "https://serverless.industries/opensearch.xml" ], "icon": [ "https://serverless.industries/favicon/favicon-96x96.png?commit=cc5a27a251b3c7815f33e676803e1803720b0e17", "https://serverless.industries/favicon/favicon.svg?commit=cc5a27a251b3c7815f33e676803e1803720b0e17", "https://serverless.industries/favicon.ico?commit=cc5a27a251b3c7815f33e676803e1803720b0e17" ], "shortcut": [ "https://serverless.industries/favicon.ico?commit=cc5a27a251b3c7815f33e676803e1803720b0e17" ], "apple-touch-icon": [ "https://serverless.industries/favicon/apple-touch-icon.png?commit=cc5a27a251b3c7815f33e676803e1803720b0e17" ], "manifest": [ "https://serverless.industries/site.webmanifest?commit=cc5a27a251b3c7815f33e676803e1803720b0e17" ], "me": [ "https://einbeck.social/@christian", "https://github.com/perryflynn", "https://chaos.social/@perryflynn", "https://git.brickburg.de/christian" ], "external": [ "https://einbeck.social/@christian", "https://github.com/perryflynn", "https://commons.wikimedia.org/wiki/File:Datacenter_Empty_Floor_(22166545884).jpg", "https://github.com/perryflynn/serverless.industries/commit/cc5a27a251b3c7815f33e676803e1803720b0e17" ], "nofollow": [ "https://einbeck.social/@christian", "https://github.com/perryflynn", "https://commons.wikimedia.org/wiki/File:Datacenter_Empty_Floor_(22166545884).jpg", "https://github.com/perryflynn/serverless.industries/commit/cc5a27a251b3c7815f33e676803e1803720b0e17" ], "noreferrer": [ "https://einbeck.social/@christian", "https://github.com/perryflynn", "https://commons.wikimedia.org/wiki/File:Datacenter_Empty_Floor_(22166545884).jpg" ], "noopener": [ "https://einbeck.social/@christian", "https://github.com/perryflynn", "https://commons.wikimedia.org/wiki/File:Datacenter_Empty_Floor_(22166545884).jpg" ], "license": [ "http://creativecommons.org/licenses/by-nc/4.0/" ] }, "rel-urls": { "https://serverless.industries/css/main.css?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "rels": [ "stylesheet" ] }, "https://serverless.industries/css/icons.css?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "rels": [ "stylesheet" ] }, "https://intercom.serverless.industries/webmentions/endpoint": { "rels": [ "webmention" ] }, "https://intercom.serverless.industries/pingback/endpoint": { "rels": [ "pingback" ] }, "https://intercom.serverless.industries/auth/relme/auth": { "rels": [ "authorization_endpoint" ] }, "https://intercom.serverless.industries/auth/relme/token": { "rels": [ "token_endpoint" ] }, "https://intercom.serverless.industries/auth/relme/metadata": { "rels": [ "indieauth-metadata" ] }, "https://intercom.serverless.industries/micropub": { "rels": [ "micropub" ] }, "https://serverless.industries/2024/05/31/digital-cinema.en.html": { "rels": [ "canonical" ] }, "https://serverless.industries/feed/frontpage.xml": { "title": "Serverless Industries Posts RSS", "type": "application/rss+xml", "rels": [ "alternate" ] }, "https://serverless.industries/opensearch.xml": { "title": "serverless.industries", "type": "application/opensearchdescription+xml", "rels": [ "search" ] }, "https://serverless.industries/favicon/favicon-96x96.png?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "type": "image/png", "rels": [ "icon" ] }, "https://serverless.industries/favicon/favicon.svg?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "type": "image/svg+xml", "rels": [ "icon" ] }, "https://serverless.industries/favicon.ico?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "rels": [ "icon", "shortcut" ] }, "https://serverless.industries/favicon/apple-touch-icon.png?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "rels": [ "apple-touch-icon" ] }, "https://serverless.industries/site.webmanifest?commit=cc5a27a251b3c7815f33e676803e1803720b0e17": { "rels": [ "manifest" ] }, "https://einbeck.social/@christian": { "text": "\n \n @christian@einbeck.social\n ", "rels": [ "external", "me", "nofollow", "noopener", "noreferrer" ] }, "https://github.com/perryflynn": { "text": "\n \n perryflynn\n ", "rels": [ "external", "me", "nofollow", "noopener", "noreferrer" ] }, "http://creativecommons.org/licenses/by-nc/4.0/": { "text": "\n \n ", "rels": [ "license" ] }, "https://commons.wikimedia.org/wiki/File:Datacenter_Empty_Floor_(22166545884).jpg": { "text": "Carl Lender (CC BY 2.0)", "rels": [ "external", "nofollow", "noopener", "noreferrer" ] }, "https://github.com/perryflynn/serverless.industries/commit/cc5a27a251b3c7815f33e676803e1803720b0e17": { "text": "cc5a27a2", "rels": [ "external", "nofollow" ] }, "https://chaos.social/@perryflynn": { "text": "Mastodon via chaos.social", "rels": [ "me" ] }, "https://git.brickburg.de/christian": { "text": "Brickburg GitLab Profile", "rels": [ "me" ] } }, "debug": { "package": "https://packagist.org/packages/mf2/mf2", "source": "https://github.com/indieweb/php-mf2", "version": "v0.5.0", "note": [ "This output was generated from the php-mf2 library available at https://github.com/indieweb/php-mf2", "Please file any issues with the parser at https://github.com/indieweb/php-mf2/issues", "Using the Masterminds HTML5 parser" ] } }