morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4300] [Feature] Decode embedded provisioning profiles and compare them with signed entitlements #1703

New issue

Open

opened 2026-10-16 21:09:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:09:15 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4300

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

An app's embedded provisioning profile (Contents/embedded.provisionprofile on macOS, embedded.mobileprovision on other Apple platforms) records which devices and certificates the app was provisioned for, when that provisioning expires, and which entitlements it may claim. REA lists the file by path and hash, but every REA tool that could read it either refuses it or treats it as an opaque resource. This request asks REA to decode an embedded profile into Evidence, classify the profile only as far as Apple's documented keys allow, and compare the entitlements the code signature claims with the profile's allowlist.

An analyst examining an IPA or a Mac app asks: "Was this built for development, ad hoc, enterprise, Developer ID or App Store distribution?", "Which devices and signing certificates does it cover, and when does it expire?" and "Does the signature claim any entitlement the profile does not authorize?". REA cannot answer any of these today.

Observations use REA 6.5.0 (npm rea-agents@6.5.0, tag rea-agents-6.5.0, commit 3b79af28e80785afce9f5998d8f03289402a1847) on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a). The cited source files are unchanged on main at d52a488.

Self-built fixture: a CMS-signed profile payload using a throwaway self-signed certificate, embedded in a minimal app that claims one entitlement the profile does not list.

printf 'int main(void){return 0;}\n' > h.c && clang -o Fixture h.c
/usr/bin/openssl req -x509 -newkey rsa:2048 -nodes -keyout k.pem -out c.pem -days 2 -subj "/CN=REA Fixture Signer"
H='<?xml version="1.0" encoding="UTF-8"?><plist version="1.0">'
echo "$H<dict><key>Name</key><string>REA Fixture Profile</string><key>TeamIdentifier</key><array><string>ABCDE12345</string></array><key>ExpirationDate</key><date>2030-01-01T00:00:00Z</date><key>ProvisionedDevices</key><array><string>00000000-0000000000000000</string></array><key>Entitlements</key><dict><key>com.apple.application-identifier</key><string>ABCDE12345.com.example.fixture</string><key>keychain-access-groups</key><array><string>ABCDE12345.*</string></array><key>com.apple.security.get-task-allow</key><true/></dict><key>DeveloperCertificates</key><array><data>AAAA</data></array></dict></plist>" > payload.plist
/usr/bin/openssl cms -sign -nodetach -binary -in payload.plist -signer c.pem -inkey k.pem -outform DER -out profile.der
mkdir -p Fixture.app/Contents/MacOS && cp Fixture Fixture.app/Contents/MacOS/ && cp profile.der Fixture.app/Contents/embedded.provisionprofile
echo "$H<dict><key>CFBundleIdentifier</key><string>com.example.fixture</string><key>CFBundleExecutable</key><string>Fixture</string><key>CFBundlePackageType</key><string>APPL</string></dict></plist>" > Fixture.app/Contents/Info.plist
echo "$H<dict><key>com.apple.application-identifier</key><string>ABCDE12345.com.example.fixture</string><key>keychain-access-groups</key><array><string>ABCDE12345.shared</string></array><key>com.apple.developer.associated-domains</key><array><string>applinks:example.com</string></array></dict></plist>" > app.entitlements
codesign -f -s - --entitlements app.entitlements Fixture.app
security cms -D -i Fixture.app/Contents/embedded.provisionprofile | plutil -p -

security cms -D -i decodes the payload: Name, TeamIdentifier, ExpirationDate, ProvisionedDevices, Entitlements and DeveloperCertificates. The release build does not:

rea inspect-plist ./Fixture.app --relative-path Contents/embedded.provisionprofile --json fails with invalid_input: "plutil could not decode it as a property list".
rea inspect-artifact ./Fixture.app --json lists Contents/embedded.provisionprofile with artifact_kind: "resource" and artifact_format: "file". Path roles fall through to a generic resource (ArtifactGraphConstruction.ts L445-L467).
The Apple application projection puts both profile names in its signing paths (appleApplication.ts L285-L290) and always states the limitation "Bundle identifiers and signing claims require dedicated plist and CMS parsing; this projection reports only exact paths and hashes." (L449). No REA tool provides that CMS parsing.

Use cases

No response

Desired outcome and success criteria

When an analyst selects an embedded profile in a target (directly, or as the profile of an app bundle or IPA), REA returns Evidence that describes it. The entry point is left to the implementer, for example accepting the profile in inspect_plist or adding it to the Apple application projection.

Wrapper. Whether the file is a CMS signed-data message with an attached payload, the CMS signer certificates' identities (subject common name, organizational unit, issuer common name, serial number, validity dates and SHA-256 fingerprint), and the payload's SHA-256. The signer is reported, not trusted: no chain or trust evaluation.
Documented payload keys. Decoded values for the keys TN3125 documents: DeveloperCertificates (each certificate's identity as above; an entry that is not a parseable certificate is reported as undecodable, not dropped), Entitlements, ProvisionedDevices (count and values), ProvisionsAllDevices, ExpirationDate (ISO 8601 with offset, and whether it is past at the recorded observation time) and DER-Encoded-Profile (present or absent).
Other payload keys. Any other keys (for example Name or TeamIdentifier, which the fixture carries but TN3125 does not document) keep their raw values and are marked undocumented. REA does not attach meaning to them.
DER form. When DER-Encoded-Profile is present, its own CMS wrapper is decoded and its payload compared with the property-list view, so that disagreements are reported. TN3125 says the DER form is the source of truth and that its DeveloperCertificates holds SHA-256 checksums. When the DER payload cannot be decoded, the comparison is unknown with a reason.
Classification. Classification uses only documented signals and reports a candidate set, not a guess. ProvisionsAllDevices true means "Developer ID or In-House (Enterprise)". A ProvisionedDevices list means "device-limited (development or ad hoc)". Neither key means "consistent with App Store distribution", stated as consistent, not proven. The basis keys are listed. Anything else is unknown.
Entitlement comparison. Each entitlement claimed by the code signature is reported as one of: allowed by an exact allowlist entry; allowed by a wildcard entry (naming the pattern, for example ABCDE12345.*); unrestricted on macOS and needing no profile authorization (TN3125's list); or not in the allowlist. Allowlist entries the signature does not claim are listed as unused and are not treated as an error. The signature's entitlements come from the same source inspect_signature uses, and the comparison is unknown when they are unavailable (for example mixed per-slice signing).
Absence. An app with no embedded profile reports absent (TN3125: App Store downloads never contain one). A file that is not a decodable CMS message fails closed with a typed error that names the reason.
Untrusted content. All decoded strings are marked as target content.

Acceptance criteria

On the fixture above, the profile is reported as a CMS message signed by REA Fixture Signer, with ExpirationDate 2030-01-01T00:00:00Z, one provisioned device, DER-Encoded-Profile absent, and the DeveloperCertificates entry reported as undecodable rather than dropped.
On the fixture, Name and TeamIdentifier appear with their raw values and are marked undocumented.
On the fixture, classification is "device-limited (development or ad hoc)" with basis ProvisionedDevices.
On the fixture, the comparison reports com.apple.application-identifier as an exact match, keychain-access-groups ABCDE12345.shared as allowed by wildcard ABCDE12345.*, com.apple.developer.associated-domains as not in the allowlist, and com.apple.security.get-task-allow as unused.
A variant whose payload replaces ProvisionedDevices with <key>ProvisionsAllDevices</key><true/> is classified as "Developer ID or In-House (Enterprise)". A variant with neither key is "consistent with App Store distribution".
The same signed profile placed at Payload/Fixture.app/embedded.mobileprovision inside a zipped IPA decodes to the same fields.
/System/Applications/Stickies.app, which has no embedded profile, reports the profile as absent. A plain text file named embedded.provisionprofile fails closed with a typed error.
On an Xcode-generated development profile the verifier owns, DER-Encoded-Profile is decoded, and its keys and DeveloperCertificates checksums agree with the property-list view and with the SHA-256 of each certificate there.
No result contacts the network or evaluates certificate trust; provenance lists only local decoding.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Affected area

Apple bundle analysis: the tool that accepts the selected profile (for example inspect_plist or the Apple application projection), the result schema, the signature-entitlement source shared with inspect_signature, generated tool documentation, and tests with self-built CMS fixtures.

Non-goals

Certificate chain building, trust evaluation, revocation checks, or verifying that Apple issued the profile.
Contacting Apple services or the developer portal.
Installing, re-signing or editing profiles, or replacing a profile in a bundle.
Embedded launch constraints, CodeDirectory posture, entitlement semantics and notarization (requested separately).
Profiles installed system-wide outside the target.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

No response

Alternatives considered

Shell out to security cms -D -i. This is macOS-only and returns only the payload, not the signer certificates or the nested DER form, but it is the ground truth for the payload and suits tests.
Decode CMS in-process. This works off macOS, which suits IPA analysis on other hosts, but it needs a bounded ASN.1/CMS parser. The request leaves this choice open.

Possible direction

No response

References

Apple documentation:

TN3125: Inside Code Signing: Provisioning Profiles:
- "A provisioning profile is a property list wrapped within a Cryptographic Message Syntax (CMS) signature." It shows security cms -D -i to remove the wrapper.
- "The exact format of provisioning profiles isn't documented and could change at any time."
- "Every profile has a DeveloperCertificates property holding the certificates of each developer who can sign code covered by the profile."
- "App Store distribution profiles have no ProvisionedDevices property"; "Developer ID and In-House (Enterprise) distribution profiles have the ProvisionsAllDevices property"; "Every profile has an ExpirationDate property".
- "The entitlements in the profile act as an allowlist." "Every entitlement claimed by the app must be in the profile's allowlist but the reverse isn't true." "Wildcards don't make sense in the app's code signature."
- It lists the macOS unrestricted entitlements (com.apple.security.get-task-allow, com.apple.security.application-groups, and the App Sandbox and Hardened Runtime entitlements).
- Locations: "macOS expects to find the profile at MyApp.app/Contents/embedded.provisionprofile." "Other Apple platforms expect to find the profile at MyApp.app/embedded.mobileprovision." "Apps that you download from the App Store don't contain an embedded provisioning profile".
- "Modern systems no longer treat the profile's property list as the source of truth. Rather, they use the binary form of the profile stored in the profile's DER-Encoded-Profile property". In that form, DeveloperCertificates "doesn't contain a full copy of each certificate, but rather a SHA-256 checksum of the certificate."

REA history: duplicate searches for "provisioning profile", "mobileprovision" and "provisionprofile" found only #451 (the IPA static provider, merged, which does not decode profiles) and #1486 (bundle-anatomy case policy, closed). No issue or PR requests profile decoding.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4300 ### Before submitting - [X] I searched the open and closed issues and pull requests for a related proposal. - [X] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [X] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation An app's embedded provisioning profile (`Contents/embedded.provisionprofile` on macOS, `embedded.mobileprovision` on other Apple platforms) records which devices and certificates the app was provisioned for, when that provisioning expires, and which entitlements it may claim. REA lists the file by path and hash, but every REA tool that could read it either refuses it or treats it as an opaque resource. This request asks REA to decode an embedded profile into Evidence, classify the profile only as far as Apple's documented keys allow, and compare the entitlements the code signature claims with the profile's allowlist. An analyst examining an IPA or a Mac app asks: "Was this built for development, ad hoc, enterprise, Developer ID or App Store distribution?", "Which devices and signing certificates does it cover, and when does it expire?" and "Does the signature claim any entitlement the profile does not authorize?". REA cannot answer any of these today. Observations use REA 6.5.0 (npm `rea-agents@6.5.0`, tag `rea-agents-6.5.0`, commit `3b79af28e80785afce9f5998d8f03289402a1847`) on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a). The cited source files are unchanged on main at `d52a488`. Self-built fixture: a CMS-signed profile payload using a throwaway self-signed certificate, embedded in a minimal app that claims one entitlement the profile does not list. ```sh printf 'int main(void){return 0;}\n' > h.c && clang -o Fixture h.c /usr/bin/openssl req -x509 -newkey rsa:2048 -nodes -keyout k.pem -out c.pem -days 2 -subj "/CN=REA Fixture Signer" H='<?xml version="1.0" encoding="UTF-8"?><plist version="1.0">' echo "$H<dict><key>Name</key><string>REA Fixture Profile</string><key>TeamIdentifier</key><array><string>ABCDE12345</string></array><key>ExpirationDate</key><date>2030-01-01T00:00:00Z</date><key>ProvisionedDevices</key><array><string>00000000-0000000000000000</string></array><key>Entitlements</key><dict><key>com.apple.application-identifier</key><string>ABCDE12345.com.example.fixture</string><key>keychain-access-groups</key><array><string>ABCDE12345.*</string></array><key>com.apple.security.get-task-allow</key><true/></dict><key>DeveloperCertificates</key><array><data>AAAA</data></array></dict></plist>" > payload.plist /usr/bin/openssl cms -sign -nodetach -binary -in payload.plist -signer c.pem -inkey k.pem -outform DER -out profile.der mkdir -p Fixture.app/Contents/MacOS && cp Fixture Fixture.app/Contents/MacOS/ && cp profile.der Fixture.app/Contents/embedded.provisionprofile echo "$H<dict><key>CFBundleIdentifier</key><string>com.example.fixture</string><key>CFBundleExecutable</key><string>Fixture</string><key>CFBundlePackageType</key><string>APPL</string></dict></plist>" > Fixture.app/Contents/Info.plist echo "$H<dict><key>com.apple.application-identifier</key><string>ABCDE12345.com.example.fixture</string><key>keychain-access-groups</key><array><string>ABCDE12345.shared</string></array><key>com.apple.developer.associated-domains</key><array><string>applinks:example.com</string></array></dict></plist>" > app.entitlements codesign -f -s - --entitlements app.entitlements Fixture.app security cms -D -i Fixture.app/Contents/embedded.provisionprofile | plutil -p - ``` `security cms -D -i` decodes the payload: `Name`, `TeamIdentifier`, `ExpirationDate`, `ProvisionedDevices`, `Entitlements` and `DeveloperCertificates`. The release build does not: - `rea inspect-plist ./Fixture.app --relative-path Contents/embedded.provisionprofile --json` fails with `invalid_input`: "plutil could not decode it as a property list". - `rea inspect-artifact ./Fixture.app --json` lists `Contents/embedded.provisionprofile` with `artifact_kind: "resource"` and `artifact_format: "file"`. Path roles fall through to a generic resource ([ArtifactGraphConstruction.ts L445-L467](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/artifacts/inventory/ArtifactGraphConstruction.ts#L445-L467)). - The Apple application projection puts both profile names in its `signing` paths ([appleApplication.ts L285-L290](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/apple/appleApplication.ts#L285-L290)) and always states the limitation "Bundle identifiers and signing claims require dedicated plist and CMS parsing; this projection reports only exact paths and hashes." ([L449](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/apple/appleApplication.ts#L449)). No REA tool provides that CMS parsing. ### Use cases _No response_ ### Desired outcome and success criteria When an analyst selects an embedded profile in a target (directly, or as the profile of an app bundle or IPA), REA returns Evidence that describes it. The entry point is left to the implementer, for example accepting the profile in `inspect_plist` or adding it to the Apple application projection. - **Wrapper.** Whether the file is a CMS signed-data message with an attached payload, the CMS signer certificates' identities (subject common name, organizational unit, issuer common name, serial number, validity dates and SHA-256 fingerprint), and the payload's SHA-256. The signer is reported, not trusted: no chain or trust evaluation. - **Documented payload keys.** Decoded values for the keys TN3125 documents: `DeveloperCertificates` (each certificate's identity as above; an entry that is not a parseable certificate is reported as undecodable, not dropped), `Entitlements`, `ProvisionedDevices` (count and values), `ProvisionsAllDevices`, `ExpirationDate` (ISO 8601 with offset, and whether it is past at the recorded observation time) and `DER-Encoded-Profile` (present or absent). - **Other payload keys.** Any other keys (for example `Name` or `TeamIdentifier`, which the fixture carries but TN3125 does not document) keep their raw values and are marked undocumented. REA does not attach meaning to them. - **DER form.** When `DER-Encoded-Profile` is present, its own CMS wrapper is decoded and its payload compared with the property-list view, so that disagreements are reported. TN3125 says the DER form is the source of truth and that its `DeveloperCertificates` holds SHA-256 checksums. When the DER payload cannot be decoded, the comparison is `unknown` with a reason. - **Classification.** Classification uses only documented signals and reports a candidate set, not a guess. `ProvisionsAllDevices` true means "Developer ID or In-House (Enterprise)". A `ProvisionedDevices` list means "device-limited (development or ad hoc)". Neither key means "consistent with App Store distribution", stated as consistent, not proven. The basis keys are listed. Anything else is `unknown`. - **Entitlement comparison.** Each entitlement claimed by the code signature is reported as one of: allowed by an exact allowlist entry; allowed by a wildcard entry (naming the pattern, for example `ABCDE12345.*`); unrestricted on macOS and needing no profile authorization (TN3125's list); or not in the allowlist. Allowlist entries the signature does not claim are listed as unused and are not treated as an error. The signature's entitlements come from the same source `inspect_signature` uses, and the comparison is `unknown` when they are unavailable (for example mixed per-slice signing). - **Absence.** An app with no embedded profile reports `absent` (TN3125: App Store downloads never contain one). A file that is not a decodable CMS message fails closed with a typed error that names the reason. - **Untrusted content.** All decoded strings are marked as target content. **Acceptance criteria** - [ ] On the fixture above, the profile is reported as a CMS message signed by `REA Fixture Signer`, with `ExpirationDate` `2030-01-01T00:00:00Z`, one provisioned device, `DER-Encoded-Profile` absent, and the `DeveloperCertificates` entry reported as undecodable rather than dropped. - [ ] On the fixture, `Name` and `TeamIdentifier` appear with their raw values and are marked undocumented. - [ ] On the fixture, classification is "device-limited (development or ad hoc)" with basis `ProvisionedDevices`. - [ ] On the fixture, the comparison reports `com.apple.application-identifier` as an exact match, `keychain-access-groups` `ABCDE12345.shared` as allowed by wildcard `ABCDE12345.*`, `com.apple.developer.associated-domains` as not in the allowlist, and `com.apple.security.get-task-allow` as unused. - [ ] A variant whose payload replaces `ProvisionedDevices` with `<key>ProvisionsAllDevices</key><true/>` is classified as "Developer ID or In-House (Enterprise)". A variant with neither key is "consistent with App Store distribution". - [ ] The same signed profile placed at `Payload/Fixture.app/embedded.mobileprovision` inside a zipped IPA decodes to the same fields. - [ ] `/System/Applications/Stickies.app`, which has no embedded profile, reports the profile as absent. A plain text file named `embedded.provisionprofile` fails closed with a typed error. - [ ] On an Xcode-generated development profile the verifier owns, `DER-Encoded-Profile` is decoded, and its keys and `DeveloperCertificates` checksums agree with the property-list view and with the SHA-256 of each certificate there. - [ ] No result contacts the network or evaluates certificate trust; provenance lists only local decoding. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) **Affected area** Apple bundle analysis: the tool that accepts the selected profile (for example `inspect_plist` or the Apple application projection), the result schema, the signature-entitlement source shared with `inspect_signature`, generated tool documentation, and tests with self-built CMS fixtures. **Non-goals** - Certificate chain building, trust evaluation, revocation checks, or verifying that Apple issued the profile. - Contacting Apple services or the developer portal. - Installing, re-signing or editing profiles, or replacing a profile in a bundle. - Embedded launch constraints, CodeDirectory posture, entitlement semantics and notarization (requested separately). - Profiles installed system-wide outside the target. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) _No response_ ### Alternatives considered - **Shell out to `security cms -D -i`.** This is macOS-only and returns only the payload, not the signer certificates or the nested DER form, but it is the ground truth for the payload and suits tests. - **Decode CMS in-process.** This works off macOS, which suits IPA analysis on other hosts, but it needs a bounded ASN.1/CMS parser. The request leaves this choice open. ### Possible direction _No response_ ### References Apple documentation: - [TN3125: Inside Code Signing: Provisioning Profiles](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles): - "A provisioning profile is a property list wrapped within a Cryptographic Message Syntax (CMS) signature." It shows `security cms -D -i` to remove the wrapper. - "The exact format of provisioning profiles isn't documented and could change at any time." - "Every profile has a `DeveloperCertificates` property holding the certificates of each developer who can sign code covered by the profile." - "App Store distribution profiles have no `ProvisionedDevices` property"; "Developer ID and In-House (Enterprise) distribution profiles have the `ProvisionsAllDevices` property"; "Every profile has an `ExpirationDate` property". - "The entitlements in the profile act as an allowlist." "Every entitlement claimed by the app must be in the profile's allowlist but the reverse isn't true." "Wildcards don't make sense in the app's code signature." - It lists the macOS unrestricted entitlements (`com.apple.security.get-task-allow`, `com.apple.security.application-groups`, and the App Sandbox and Hardened Runtime entitlements). - Locations: "macOS expects to find the profile at `MyApp.app/Contents/embedded.provisionprofile`." "Other Apple platforms expect to find the profile at `MyApp.app/embedded.mobileprovision`." "Apps that you download from the App Store don't contain an embedded provisioning profile". - "Modern systems no longer treat the profile's property list as the source of truth. Rather, they use the binary form of the profile stored in the profile's `DER-Encoded-Profile` property". In that form, `DeveloperCertificates` "doesn't contain a full copy of each certificate, but rather a SHA-256 checksum of the certificate." REA history: duplicate searches for "provisioning profile", "mobileprovision" and "provisionprofile" found only #451 (the IPA static provider, merged, which does not decode profiles) and #1486 (bundle-anatomy case policy, closed). No issue or PR requests profile decoding.

bsakaguchi referenced this issue

2026-10-31 00:54:48 +00:00

[PR #1703] [MERGED] fix(native): raise default PE resource entry budget to 16384 #4765

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1703

No description provided.

Rows
Columns