Apple FairPlay SC_Info File Formats

Documentation and ImHex pattern files for the Apple FairPlay protection files that ship in every iOS app bundle's SC_Info/ directory: .supx, .supp, .supf, .v4.supp, .v5.supf, .sinf, and Manifest.plist. Together these carry the per-page content keys, the signing certificate, and the DRM scheme info that let iOS decrypt and validate each Mach-O binary in the app.

Motivation

This research was inspired by the recent change to the new FairPlay file formats. Apple introduced the .v4.supp (0x04) and .v5.supf (0x05) variants and stops shipping the legacy .supp (0x01) / drops the legacy .supf (0x03) to 0 bytes. We set out to document both generations and understand exactly what differs between them.

Apps where this shows up include:

• com.microsoft.rdc.ios 11.3.2 - main binary
• com.gopro.GoPro 13.34.1 - ReelSteady.framework

In both, the legacy .supp is missing and .supf is 0 bytes, while the current .v4.supp / .v5.supf / .supx are present, and the binaries run normally.

Format overview

A fully populated SC_Info contains:

File	ver byte	role	class	generation
<Name>.supx	-	tagged index of key fingerprints	x	-
<Name>.supp	0x01	per-page keys + cert + signature	p	old
<Name>.supf	0x03	per-page keys + cert + signature	f	old
<Name>.v4.supp	0x04	per-page keys + cert + signature	p	new
<Name>.v5.supf	0x05	per-page keys + cert + signature	f	new
<Name>.sinf	-	DRM scheme info (account/rights + AES IV)	-	-
Manifest.plist	-	.sinf source + replication paths	-	-

• Two classes, two generations. .supp/.v4.supp are the p-class and .supf/.v5.supf the f-class - two different containers around the same per-page keys. This architectural shift is orthogonal to the format generations: the only structural difference is that older variants include a SHA-1 hash, which the newer files omit.
• Per-page keys. Each key file holds a table of 32-byte (256-bit) keys, one per 4 KB page. The f-class covers only the FairPlay-encrypted pages (npages = cryptsize/4096); the p-class covers every page from offset 0 (header + encrypted), so the f-class table is the encrypted-page tail of the p-class table.
• The 20-byte block distinguishing the pre-26 files is a SHA-1 of the binary's Mach-O code-signature blob (the LC_CODE_SIGNATURE / 0xfade0cc0 superblob) - a content-integrity hash.
• Cert + signature. Both classes end with a 708-byte X.509 RSA-1024 FairPlay leaf certificate (drawn from a reused pool of 13 signing identities) and a 128-byte RSA-1024 signature bound to the file.
• .supx is a self-describing (TLV) index and a per-app constant. .sinf is an MP4/iTunes atom tree (authored once and replicated per binary) carrying the account/rights dictionary and a 16-byte AES IV.
• Magic. The version byte is followed by a 3-byte tag, 36 31 32 ("612") for our sample; earlier research by pwn0rz reported 507.

Container layouts

f-class (.supf / .v5.supf) - a length-value container:

0x00  u8      version            0x03 or 0x05
0x01  3       magic
0x04  KeyPairSegments
        u32   length             total length of nseg + all segments
        u32   nseg               segment count (1 per architecture; >1 for fat)
        Segment[nseg]
          u32      length        length of the fields below
          u32      cpu_type      0x0100000c = ARM64, 0x0000000c = ARM32
          u32      cpu_subtype   0/1 arm64, 2 arm64e, ...
          u8[20]   sha1_hash     SHA-1(Mach-O code signature) - v03 ONLY (omitted in v05)
          u32      npages        number of 4 KB encrypted pages
          u8[*]    key_data      npages × 32 bytes
      CertificateLV   u32 length (708) + DER cert
      SignatureLV     u32 length (128) + RSA-1024 signature

p-class (.supp / .v4.supp) - a page-indexed key table:

0x00  u8      version            0x01 or 0x04
0x01  3       magic
0x04  u8[20]  sha1_hash          SHA-1(Mach-O code signature) - v01 ONLY (omitted in v04)
0x..  u32     count              total pages = (cryptoff + cryptsize) / 4096
0x..  PageKey page_keys[count]   32 bytes per page, from file offset 0:
                                   [0 .. cryptoff/4096)  header pages (4)
                                   [cryptoff/4096 .. )   encrypted pages == f-class key_data
0x..  CertificateLV              u32 length (708) + DER cert
0x..  u8[128] signature          RSA-1024 signature (raw, no length prefix)

Certificate + signature trailer

The trailer begins at the marker 00 00 02 C4 30 82 02 C0 (certLen 708 + DER Certificate SEQUENCE), present in every key file:

certLen       4 B   = 00 00 02 C4 (708)
certificate 708 B   X.509 RSA-1024 leaf cert (from a reused pool of 13)
signature           p-class: 128 B raw RSA-1024
                    f-class: 00 00 00 80 (len) + 128 B RSA-1024

.sinf (DRM scheme info)

An MP4/iTunes atom tree - be u32 size (incl. the 8-byte header) + 4-char type + payload, nested:

sinf
  frma  <4cc>                       original data format
  schm  00000000 "itun" 00000000    scheme = iTunes FairPlay
  schi                              scheme info:
    user / crdt / asdt / key  u32   account id / dates / key index
    iviv  u8[16]                    16-byte AES IV
    righ  { 4cc -> u32 }*           rights dictionary (veID, plat, aver, tran, tool, ...)
    name  cstring                   account name
    priv  u8[*]                     encrypted private data
  sign  u8[*]                       signature

.supx index

Self-describing via its length fields:

0x00  u32  formatTag      1
0x04  u32  trailerOffset  0x40 -> offset of the trailer below (one-entry TOC)
0x08  u32  entry0.count   1
0x0C  u32  entry0.length  0x10 (16)
0x10  16B  entry0.data    key fingerprint
0x20  u32  entry1.type    2
0x24  u32  entry1.length  0x10 (16)
0x28  16B  entry1.data    key fingerprint
0x38  8B   padding        zero (aligns trailer to 0x40)
0x40  16B  trailer        MAC / integrity digest over the index

Contents

Path	Description
patterns/supx.hexpat	The .supx index
patterns/supp.hexpat	p-class key files (.supp / .v4.supp)
patterns/supf.hexpat	f-class key files (.supf / .v5.supf)
patterns/sinf.hexpat	.sinf DRM scheme info (MP4 atom tree, incl. the rights dictionary)

Using the ImHex patterns

Open a target file in ImHex and load the matching pattern (File → Import → Pattern File, or paste it into the pattern editor).

Sample files

This repository does not provide any concrete SC_Info files. To obtain these, you can use ipatool.

Related work

Complementary to pwn0rz's FairPlay research, which documents the same family from a different angle: https://github.com/pwn0rz/fairplay_research

Prior efforts regarding .sinf modification: https://github.com/roothide/FairFree

Scope

This research documents file formats. It does not circumvent FairPlay: the per-page keys are wrapped, and the certificate + RSA-1024 signature are bound to a private key held only by the signer.