Analysis of Apple FairPlay DRM: Architecture, Obfuscation Techniques, and Weaknesses

This article investigates Apple’s FairPlay DRM, focusing on its authorization and encryption mechanisms, the design of its obfuscation system, and the weaknesses that enable reverse‑engineering.

FairPlay protects iOS and macOS applications by encrypting the Mach‑O binary. The encryption is described by the LC_ENCRYPTION_INFO load command, where cryptoff, cryptsize and cryptid indicate the offset, size and method (1 for FairPlay). Decryption is performed by a kernel driver ( FairPlayIOKit) and a user‑space daemon ( fairplayd).

The core entry point in the kernel driver is:

com_apple_driver_FairPlayIOKit::xhU6d1(const char *executable_path, long long cpu_type, long long cpu_subtype, rp6S0jzg **out_handle)

Communication between the driver and fairplayd uses MIG messages defined as:

struct FPRequest { mach_msg_header_t header; mach_msg_body_t body; mach_msg_ool_descriptor_t ool; NDR_record_t ndr; uint32_t size; uint64_t cpu_type; uint64_t cpu_subtype; };

struct FPResponse { mach_msg_header_t header; mach_msg_body_t body; mach_msg_ool_descriptor_t ool1; mach_msg_ool_descriptor_t ool2; uint64_t unk1; uint8_t unk2[136]; uint8_t unk3[84]; uint32_t size1; uint32_t size2; uint64_t unk5; };

During decryption the driver receives a handle ( rp6S0jzg*) that is later used by the bvqhJ function to decrypt individual pages (4096‑byte units):

com_apple_driver_FairPlayIOKit::bvqhJ(rp6S0jzg *handle, unsigned long long offset, const unsigned char *src, unsigned char *dst)

FairPlay stores per‑user licensing data in the SINF file and the encrypted key material in the SUPF file, both located in the app’s SC_Info directory. The SINF file follows an LTV+KV format (e.g., sinf.frma: game, sinf.schi.user: 0xdeadbeef), while SUPF contains key segments, a FairPlay certificate, and an RSA signature.

The obfuscation applied to the FairPlay code is implemented at the LLVM IR level. Typical techniques include:

LLVM passes that insert opaque predicates and opaque constants.

MakeOpaque transformations that replace straightforward expressions with equivalent but harder‑to‑analyze forms, e.g., Expression* makeOpaque(Expression *in); Opaque predicates such as bool y = ((x*x%4)==0 || (x*x%4)==1); which are always true but prevent dead‑code elimination.

Control‑flow flattening that replaces direct branches with a state‑machine driven by a lookup table (LUT).

Indirect branches where basic‑block addresses are stored in a global LUT and jumped to via jmp/call LUT[makeOpaque(i)].

Cross‑function calling‑convention obfuscation that passes arguments through heap‑allocated structures and applies XOR masking.

These techniques generate MBA (Mixed Boolean‑Arithmetic) expressions, for example:

//OperationSet(+, -, *, &, |, ~)
x - c = (x ^ ~c) + ((2 * x) & ~ (2 * c + 1)) + 1;

Despite the heavy obfuscation, several weaknesses were identified:

Function‑boundary identification is possible because all basic blocks of a function share the same PAC (Pointer Authentication Code) context on arm64e devices.

Indirect jumps can be resolved by tracing the LUT entries and reconstructing the original branch conditions.

Data‑flow obfuscation often relies on a single MBA rewrite pattern, which can be detected by pattern‑matching tools such as D810.

By combining static analysis, dynamic tracing, and tools like KeyPatch, the authors were able to recover most of FairPlay’s control flow and extract the AES keys used to decrypt Mach‑O sections, paving the way for DRM research that does not depend on Apple hardware.