Archaeology
Supported Binary Formats
Looking for something specific? The User Guide, Formats, Reversing Topics and FAQ are indexed within the app — open Archaeology, click on the Help menu (Command-?), and type in the Search field. Results listed under Help Topics link directly to the appropriate section here.
BER-encoded ASN.1
| Format Name | BER-encoded ASN.1 |
|---|---|
| Format Type | An ITU Standard |
| Format Specification | |
| API Used By Archaeology | macOS version of libcrypto (part of LibreSSL) |
| Other APIs and Tools |
|
| Searchable | No |
| Examples |
|
ASN.1 is a language for defining a data structure, along with rules for how to serialize that data to a binary format — BER is the most basic binary encoding, and DER is a subset of BER (so everything that is DER-encoded is also BER-encoded).
Among many other things, ASN.1 is used to define the format of X.509 certificates, and of the Crytpographic Message Syntax (CMS) that packages a signature with the certificate that created it and related metadata. X.509 and CMS are IETF standards, but you'll also find custom ASN.1 formats used on macOS — some that are documented (like App Store receipts) and some that are not (like the DER-encoded version of entitlements in a code signature).
There are various tools that deal with these specific formats, of course. Certificate Assistant — or the openssl(1)
x509 command — can show information about a X.509 certificate file. The security(1) cms
command can show information about an arbitrary CMS file. The Profiles pref pane can some specific information about
configuration profiles. Or Quick Look can show some specific information about provisioning profiles.
Archaeology shows the ASN.1 at a lower-level, without assuming (or knowing) anything about the specific data structure definition. This can be useful when you don't have an ASN.1 definition for a file, when the domain-specific tool (like Certificate Assistant) abstracts away the details you want to see, or where there are simply no specific tools available (as for App Store receipts).
For example, we can open the CMS from a macOS code signature, and see attributes such as the
(self-declared) Signing Time:
On the right, the info pane shows details about the selected item, using ASN.1 terminology. The Offset shows where this item was found within the containing file (or the containing chunk of data). The Length is given as two numbers: the first is the size of the ASN.1 tag and length header, and the second is the size of the value. (If you copy or export the data, only the value part will be extracted.)
Often, an ASN.1 item will contain another chunk of data in another format, and you can use Archaeology to decode that.
For example, we can open a provisioning profile (another kind of CMS), and find the “payload”:
At this level, the selected OCTET STRING is arbitrary binary data, but we can try to decode it and see
what we get. In this case, using Go > Decode Item (Cmd-Down Arrow) gives us the property list inside:
In turn, a provisioning profile property list typically contains one or more
DeveloperCertificates, which we can decode again to get the ASN.1 for an X.509 certificate:
If we select the root of an X.509 certificate structure (the top-level SEQUENCE in this example),
Archaeology will recognize it as such, and we can click Go > Show As Certificate (Cmd-Option-V) to
examine the certificate using the standard macOS certificate view:
Verifying a CMS Signature
For any CMS-format signature, Archaeology can show how macOS would evaluate the validity of the signature and the trust of the signing certificate. For example, this works with code signatures, and with configuration or provisioning profiles.
Select the root of a CMS structure — probably the top-level SEQUENCE in the ASN.1 view —
and choose Go > Verify CMS Signature (Cmd-Option-V):
Here, you can configure the verification, and see the result at the bottom:
- The applicable trust settings policy is an Apple-defined collection of requirements for trusting a certificate for a specific purpose. Apple X.509 Basic Policy is the most generic, and is generally fulfilled as long as the certificate chain leads to a trusted “anchor,” e.g. in the System Root keychain. Use the pop-up menu to see other common trust policies, or to enter a custom trust policy OID. Some trust policies add more stringent root certificate requirements (mostly, that it be an Apple Root CA), or more specific pinning requirements. Trust policies might also require specific extensions to be present on a certificate, indicating that Apple issued it for a specific purpose — such as Developer ID signing, or App Store signing.
- The certificate revocation checking options allow you to control what type of revocation checks are or are not allowed. Allowing OCSP and CRL (but only “best attempt”) is the typical default when macOS is checking certificate trust.
- In order to verify the actual signature, Archaeology must be able to find the signed data to verify against.
This is the “thing” that was actually signed — usually a small bit of data (like a
cryptographic digest, such as SHA-256) that uniquely identifies that “thing.”
For some CMS signatures, the signed thing is the payload actually embedded in the CMS. For example, with a configuration profile, the payload is the contained property list. In such cases, Archaeology will say that the “CMS message encapsulates the signed data,” and nothing more is required here.
For other types of CMS signatures, the signed thing is external. This is the case for a code signature, where the code signing digest or cdhash is the signed thing, and lives outside of the CMS, as the Code Directory. If you decoded the CMS from another file or from a Security::SuperBlob, Archaeology might be able to automatically find the Code Directory to use, shown as “retrieved X bytes from Code Signature > Code Directory” or some such.
If Archaeology doesn't automatically find the right thing, you can use Read From File to get the thing from a file, or Paste From Clipboard to get it from the clipboard (whether copied from elsewhere in Archaeology, or as a hex-encoded string from another app).
As you change these parameters, Archaeology will re-evaluate the signature and certificate trust, and
show the result at the bottom. Click Show Details to get more information
about any verification errors, and to see the certificate chain and trust information:
Annotating ASN.1 With Comments
Even when you have the ASN.1 definition for a particular file — such as the IETF RFC for CMS files — it can still be challenging to keep track of what item of data means what. For this reason, Archaeology allows you to annotate comments onto individual items as you puzzle out the pieces of the ASN.1.
To add or change a comment, click in the Comments column — or press
Return to edit the comment for the selected item:
In the above example, we've annotated the pieces of the CMS that identify the signed payload (or “encapsulated content”), using the ASN.1 definition from RFC 5652:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- i.e. Data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
Archaeology saves the comments you add this way, and will restore them when you decode the identical ASN.1 data again. (The comments are sideband data, and are linked to the ASN.1 data by a hash. So, they will be restored only when the ASN.1 data is 100% identical to one that was annotated.)
Cocoa Keyed Archive
| Format Name | Cocoa Keyed Archive |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology uses NSPropertyListSerialization to get a property list, and interprets from there |
| Other APIs and Tools | None |
| Searchable | Yes, by class name, instance UID, key, or value |
| Examples |
|
Apps and macOS services often persist their in-memory object models using a Cocoa Keyed Archive, which is the
serialized data created by the Foundation NSKeyedArchiver
class. While you can't reconstruct the actual object model without the app-specific code that created it, you
can often tell quite a bit from class and key names, and by asking Archaeology to further decode any chunks of data.
As explained here, a Cocoa Keyed Archive is a binary-serialized property list, but it has some special types, and tracing more than one or two object references is extremely tedious.
Archaeology interprets this property list as an object graph, and presents it in a column-based browser view
(an NSBrowser), which makes it much easier to traverse relationships:
Each column represents an instance of the named CLASS, which might be either app-specific or an Apple framework class. The UID is a unique integer that identifies that instance.
When you select a key, Archaeology shows the associated value, which might be another instance, or it might be a primitive type.
Primitives will show their TYPE as a Cocoa class name. (This is often some private Core Foundation subclass
of the one you'd expect — for example, __NSCFString is a private subclass of NSString.) When the
VALUE is an integer, you can click on the displayed number to change the radix that Archaeology uses, cycling between
decimal, hexadecimal and octal.
An object archive will often have back-references: the graph is not necessarily acyclic. So, as you navigate the objects, you may well loop back to where you've been. Archaeology doesn't try to detect or flag this (yet). If things are looking familiar, you can always check the UID to see if two instances are actually the same object.
Simplification of Foundation Collections
Cocoa Keyed Archives typically include standard Foundation collections, such as NSArray or
NSDictionary. The way that these are archived can be a chore to interpret, so by default, Archaeology
tries to simplify them for easier navigation.
An NSArray is archived as an NS.objects key that leads to a
list of the actual objects. Unless you're interested in the structure of the NSArray itself,
this just adds an extra click, so Archaeology pulls the actual objects to be directly
inside the array.
Likewise, an NSDictionary is archived as two parallel lists, as NS.keys
and NS.objects: the key and value at the same index constitute a pair. That's efficient
for archiving, but makes navigating the dictionary tedious. Here, Archaeology pulls each
key up to the NSDictionary itself, and associates it to the corresponding value. This makes the keys
of the dictionary behave more like the properties of an object, and is usually easier to navigate.
For this simplification of anNSDictionary, all of the keys must be strings. If a dictionary has non-string keys, you may still seeNS.keysandNS.objects.
If you want to see the actual archived representation, you can disable this simplification by unchecking File > Re-open With Options > Simplify collections in archives. You can also change this option directly from the File > Open dialog.
Alternate String Formatting of Primitives
Some standard Foundation types have an obvious representation in a Cocoa Keyed Archive, but others are quite opaque, or just not in the most convenient form. For a few common-but-obscurely-encoded types, Archaeology will create a sibling key with a more readable representation.
For example, an NSDate is encoded with an NS.time key, which is the number of
seconds since January 1, 2001. Archaeology adds a sibling key — with the
“➔ formatted date” suffix — containing a nicely-formatted date and time.
Even more obscurely, an NSIndexPath is encoded as a chunk of data, containing a series of
variable-length integers (each index encoded using 7 bits per byte, in Little Endian order, with the high bit
cleared in the most significant byte). Here, Archaeology adds a sibling key
— with the “➔ indexes” suffix — containing a nicely-formatted series of indexes.
The original keys are always left intact, so you can see what the archive actually contains.
You can disable these alternate representations by unchecking File > Re-open With Options > Format strings and dates in archives. You can also change this option directly from the File > Open dialog.
Searching Cocoa Keyed Archives
Since a Cocoa Keyed Archive can be quite complex, Archaeology allows you to search the object graph.
Click in the search field (or use Cmd-F), enter text and press Return. The search results appear at
the bottom of the window. Select a search result to show the matching object:
By default, Archaeology searches all of the string-type primitive values for the given text. But you can also
search on other aspects of the object graph, such as keys or class names. Click the search button
UIKit NIB Archive
| Format Name | UIKit NIB Archive |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology interprets raw data stream |
| Other APIs and Tools | None |
| Searchable | Yes, by class name, instance UID, key, or value |
| Examples | Compiled NIB files (as built with Xcode 13 or later, and targeting macOS 10.13 or later) |
As it says in the Xcode 13 Release Notes,
“Storyboards and XIBs for macOS compile using UINibEncoder to reduce file sizes and improve runtime performance. When deploying an App before macOS 10.13, Xcode generates a backward compatible nib for the older OSes.”
This alternate compiled NIB format — which clearly comes from iOS — serves the same purpose as a Cocoa Keyed Archive: to serialize an object graph. Archaeology decodes it and presents the object model in a browser, exactly as described above for a Cocoa Keyed Archive.
Some of the details of how specific types are archived will differ, but navigating the model is pretty much identical.
Note that, when Xcode decides it must create a “backward compatible nib,” this means a NIB Package, which you can also open with Archaeology, and then decode the different representations inside.
URL Bookmark
| Format Name | URL Bookmark |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology interprets raw data stream |
| Other APIs and Tools | None |
| Searchable | No |
| Examples | Rarely exist as standalone files, but often embedded in preference property lists, or in Cocoa Keyed Archives |
Applications commonly store paths in the form of URL bookmarks, both to make them more resilient against moving and renaming of the file (especially when the app is not running) and to maintain access that would otherwise be prevented by sandboxing.
A detailed discussion of the different kinds of URL bookmarks is here.
Bookmarks are mostly a collection of key-value pairs, and most significantly contain volume
and inode information for the target file path:
A bookmark can be security-scoped, which allows an app with access to a specific file to save and regain that access later. This type of bookmark will resolve only for the app and user that originally created it, which is the “security scope” of the bookmark. (See a very detailed explanation of security-scoped bookmarks here.)
In the above example, the bookmark is security-scoped, and you can ask Archaeology to verify that
scope. Choose Go > Verify Security Scope (Cmd-Option-V):
Here, you can configure the verification, and see the result at the bottom:
- Choose the type of security scope used by this bookmark. (This information is not encoded in the bookmark data itself, so Archaeology can't help here.) You will probably want application scope, meaning a specific app and user; document scope is uncommon.
- For application scope, click Choose Application to select the actual application, which fetches the code signing identifier.
- Also for application scope, click Find in Keychain to fetch the user-specific secret key for scoped bookmarks. This is a 32-byte key randomly chosen by the macOS ScopedBookmarkAgent: it is used to bind the security-scoped bookmark to the current user. macOS will prompt that “Archaeology wants to use your confidential information stored in ‘com.apple.scopedbookmarksagent.xpc’ in your keychain.”
Once all of the parameters are configured, Archaeology will evaluate the security scope, and show the result at the bottom.
If you choose document scope in step 1, you'll instead need to click
Choose Document to locate the document itself. This will attempt to fetch
the document-specific secret from an extended attribute on the document, which is what demonstrates
access to the scope. However, we've seen inconsistencies with Archaeology being able to read this xattr,
so you may get an “operation not permitted” error. If you can get the contents of the
com.apple.security.private.scoped-bookmark-key xattr into a file in some other way,
you can then Option-click the Choose Document button and select that file,
and Archaeology will read the key that way.
Security::SuperBlob
| Format Name | Security::SuperBlob |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, although the relevant Security.framework code is available; also, see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology interprets raw data stream |
| Other APIs and Tools | The SecStaticCode API from Security.framework shows data from the Security::SuperBlob where
appropriate, but doesn't provide visibility into the actual structure |
| Searchable | No |
| Examples | Rarely exist as standalone files, but usually embedded in Mach-O binaries, as well as in signed disk images |
The Security::SuperBlob is used to store code signature data in Mach-O binaries (as well as in disk images).
Archaeology allows you to open these — or more commonly, decode them from a Mach-O binary
or a bundle — so you can inspect the different pieces of the code signature:
Archaeology shows all of the components of the code signature, which are explained in much depth here. The Code Directory is not decodable by Archaeology, but it does show the SHA-256 digest, which is also known as the code signing identity or the cdhash.
The keyhole icon
Notarization Ticket
| Format Name | Notarization Ticket |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology interprets raw data stream |
| Other APIs and Tools | None. The spctl(8) tool can check notarization status, but tickets are abstracted away |
| Searchable | No |
| Examples |
|
A notarization ticket is an Apple-signed file that communicates the notarization state of an app. It can be “stapled” (i.e. attached) to apps or other containers, but this is not strictly required, since macOS is able to query notarization status from Apple servers.
Notarization tickets primarily contain digests that identify notarized components, along with an Apple signature:
If you open a bare ticket, Archaeology won't be able to show how each digest corresponds to a component. But if you open a stapled app bundle, and then decode the ticket from there, Archaeology will attempt to match each digest to a component of the app, as shown above. (It's not uncommon for there to be a single unidentified digest in the ticket, probably corresponding the disk image that the developer used to submit the app to Apple's notarization service.)
Click the Show Details button to see information about the Apple certificate that was used to sign the actual ticket.
See much more about notarization tickets here.
We assume that, in the absence of a stapled notarization ticket, macOS fetches an actual ticket from Apple servers. But these aren't stored on your system in ticket form. Instead, the notarization information (digests mostly) are stored in /var/db/SystemPolicyConfiguration/Tickets, a SQLite database used bysyspolicyd(8)to make execution policy decisions. For this reason, stapled tickets may be the only ones you ever encounter — unless you're stapling your own:stapler(1)will leave the ticket in a temporary directory, but you'll see the path in its verbose output.
macOS Property List
| Format Name | macOS Property List |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | Property List Programming Topics |
| API Used By Archaeology | NSPropertyListSerialization |
| Other APIs and Tools | Numerous first- and third-party tools and apps, including Xcode, plutil(1) and PlistBuddy(8) |
| Searchable | Yes, by key or value |
Property lists are, of course, a well-established and well-supported format.
Archaeology supports property lists primarily because they often contain chunks of data in one of the other (less well-supported) formats — such as Cocoa Keyed Archives or URL Bookmarks. Also, they often are contained within one of those other formats — such as BER-encoded ASN.1 that is used for a configuration or provisioning profile.
JSON
| Format Name | JSON (JavaScript Object Notation) |
|---|---|
| Format Type | An industry standard |
| Format Specification | e.g. RFC 7159 |
| API Used By Archaeology | NSJSONSerialization |
| Other APIs and Tools | Legion |
| Searchable | Yes, by key or value |
As with Property Lists, Arcaheology can open JSON files primarily because they can contain — or be contained in — various of the other supported formats.
File Table of Contents
In addition to the primary formats described above, Archaeology can directly open a number of other file and directory formats, largely because they often contain data in one of the primary formats. Archaeology calls these file tables-of-contents or file TOCs, because they act somewhat like lists of decodable chunks of data.
Mach-O Binary
| Format Name | File Table of Contents — Mach-O Binary |
|---|---|
| Format Type | A mostly Apple-specific executable format, originating from the Mach kernel and NeXTSTEP |
| Format Specification | Apple has long since abandoned such documentation, but there are many other explainers on the Internet |
| API Used By Archaeology | <mach-o/loader.h> |
| Searchable | No |
Archaeology can open standalone Mach-O binaries — executables, dylibs and so on — because they typically contain other chunks of decodable data. Most significantly, a Mach-O binary will usually contain a code signature, in the form of a Security::SuperBlob for each processor architecture.
Mach-O binaries might also contain embedded Info.plist files and/or launchd configuration files, and Archaeology will show these where present (and of course, decode them as Property Lists).
Archaeology also shows some general information from the Mach-O headers and load commands for each architecture,
including things like deployment targets and linked libraries. This is information that you'd typically need to
get from otool(1) (with its hard-to-remember option syntax) or the more modern objdump(1) (with its
even harder-to-remember option syntax).
Bundle
| Format Name | File Table of Contents — Bundle |
|---|---|
| Format Type | An Apple-defined directory structure |
| Format Specification | Bundle Programming Guide |
| API Used By Archaeology | NSBundle |
| Searchable | No |
As with Mach-O binaries, Archaeology opens bundles because they contain many other interesting bits of decodable data. Archaeology shows information about the main executable of the bundle: this includes the code signature and other pieces, just as for standalone Mach-O binaries described above.
Archaeology also shows any compiled NIBs or storyboards (decodable as either Cocoa Keyed Archives or UIKit NIB Archives), the Info.plist file, any App Store receipt and/or provisioning profile (both decodable as BER-encoded ASN.1), any stapled notarization ticket, and the _CodeSignature/CodeResources property list that seals resources into the code signature.
Archaeology also looks inside the bundle for any nested bundles, as well as standalone Mach-O binaries (such as dylibs), and shows these hierarchically.
For an app bundle, you can get a higher-level view of this information by using Apparency. If you already have it installed, choose File > Open With Apparency.
NIB and Storyboard Packages
| Format Name | File Table of Contents — Compiled IB Package |
|---|---|
| Format Type | An Apple-defined directory structure |
| Format Specification | None |
| API Used By Archaeology | None |
| Searchable | No |
When Xcode compiles a XIB file, it usually produces a single NIB file — in modern times, a file using the UIKit NIB Archive format. However, depending on the macOS deployment target, it might also produce a package of multiple NIB files in different formats, with names like keyedobjects-####.nib.
Likewise, when Xcode compiles a Storyboard, it produces a package with multiple NIB files, along with an Info.plist file.
You can open either of these types of packages in Archaeology — or access them when opening a bundle that contains them. Archaeology will show each of the individual NIB files as data, and you can recursively decode these. You can also decode the Info.plist to see how the pieces of the Storyboard are tied together.
UDIF Disk Image
| Format Name | File Table of Contents — UDIF Disk Image |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None |
| Searchable | No |
Archaeology can open UDIF-format disk images, mostly so you can get at the code signature inside. If there's a Disk Image Code Signature item, you can decode that to get a Security::SuperBlob, and see the code signature components.
There might also be a notarization ticket stapled to the disk image, which will also be found inside the superblob.
xar Archive — e.g. macOS Installer Package
| Format Name | File Table of Contents — xar Archive |
|---|---|
| Format Type | An Apple-originated archive format, open-sourced long ago and mostly deprecated now |
| Format Specification | None canonical, although the xar code is available; also see the old Google Code project. |
| API Used By Archaeology | macOS version of libxar |
| Searchable | No |
Archaeology can open xar archives — includes modern macOS Installer Packages — so you can see the signature-related details.
A xar will often have two different “styles” of signature: an older “RSA” style is a bare RSA signature of the xar TOC (or a digest thereof). The newer “CMS” style is a CMS signature in BER-encoded ASN.1 format. (The macOS Installer uses the latter if it's present; the former exists mostly for older versions of macOS.)
For either style, you can decode the (claimed) certificate chain that created the signature, and if you select the signature data, you can choose Go > Verify Signature (Cmd-Option-V) to evaluate the validity and trust of the signature.
There might also be be a notarization ticket stapled to the xar (which, unlike with a disk image, is stored separately from the signature).
Archaeology won't show the actual archive contents, which isn't what it is trying to do. If the xar is a macOS Installer Package, you can get much more — and higher-level — information by using Suspicious Package. If you already have it installed, choose File > Open With Suspicious Package.
Saved Application State
| Format Name | File Table of Contents — Saved Application State |
|---|---|
| Format Type | An Apple-proprietary format |
| Format Specification | None, but see our reverse-engineering notes |
| API Used By Archaeology | None. Archaeology interprets files directly |
| Searchable | No |
For Archaeology to properly interpret the files in a savedState directory, you must open the directory itself, not the individual files inside. The files are all inter-related, and since Archaeology is sandboxed, it can't read them all unless you open the actual directory. This can be a bit confusing, since macOS treats the savedState directory as a folder (not as a “package”). From the File > Open dialog, select the directory itself and click Open.
These directories, with the savedState extension, are found under your home folder at Library/Saved Application State — or for a sandboxed application, under the app's “container” at under Library/Containers/com.example.bundle-identifier/Data/Library/Saved Application State.
The savedState directories are where macOS stores information for the “Resume” feature — that is, the preservation of state when quitting an app (i.e. System Settings > Desktop & Dock > Windows & Apps > Close windows when quitting an application is disabled; or on macOS 12, System Preferences > General > Close windows when quitting an app) or when restarting your computer (i.e. in the restart confirmation dialog, Reopen windows when logging back in is checked).
Among other information, these directories contain the state data saved by both Cocoa and by the
application itself, in the form of Cocoa Keyed Archives. macOS stores individual
chunks of state data under NSUserInterfaceItemIdentifiers, such as _NSDocument
and _NSWindow. Application-specific data is usually stored under other identifiers (although
some app data may also live in the _NSDocument chunk).
Archaeology lists all of the encoded data chunks under Decrypted Object Archives, because they live in the data.data file in encrypted form — for mysterious reasons, because the encryption keys are right next door, in the windows.plist file. Anyway, Archaeology extracts and decrypts the chunks, and then you can decode them as needed.
The savedState directory might also contain a “snapshot” for the app window: this
is actually a screenshot of the window as it last existed, which is sometimes used after restart to
“fake” immediate restoration while the real work takes place. These screenshots live in the
window_#.data files, but in a rather arcane form: they are raw CGImage data that is
zlib-compressed and then AES-128-CBC-encrypted, using a key that is randomly chosen by talagent(8)
and stored in your keychain. If you select the Window Snapshot item and use
Go > Quick Look Item, Archaeology will undo all of that business and show you the
actual image; you'll be prompted to Allow access to the keychain item, which is
required for the decryption step.
At this point, you might be asking yourself “why the $%^& did you implement that?” To which the answer is because it was there. Some people play video games. ¯\_(ツ)_/¯
Apple Wallet Package
| Format Name | File Table of Contents — Apple Wallet Package |
|---|---|
| Format Type | An Apple-defined directory structure |
| Format Specification | Wallet Passes |
| API Used By Archaeology | None |
| Searchable | No |
These directories, with the pkpass extension, represents the “passes” shown by Apple Wallet. You'll probably find a bunch of them under your home folder at Library/Library/Mobile Documents/com~apple~shoebox/UbiquitousCards (although macOS likes to hide this folder and its contents, such as in Finder and Open dialogs).
Archaelogy can open a pkpass directory — although you may need to use the trowel tool from the Terminal — and show the JSON and other files inside. Perhaps most interestingly, you can select the signature and choose Go > Verify Signature (Cmd-Option-V) to get information about the certificate that signed the pass.