apple-crash-symbolication — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited apple-crash-symbolication (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 7 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 7 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Resolves native backtrace frames from .NET MAUI and Mono app crashes on Apple platforms (iOS, tvOS, Mac Catalyst, macOS) to function names, source files, and line numbers using Mach-O UUIDs and dSYM debug symbol bundles.
Inputs: Crash log file (.ips JSON format, iOS 15+ / macOS 12+), atos (from Xcode), optionally a connected iOS device to pull crash logs from.
Do not use when: The crashing library is not a .NET component (e.g., pure Swift/UIKit), or the crash log is an Android tombstone.
Format check: Before proceeding, verify the file is .ips JSON format. The first line must be valid JSON. If the file is plain text (e.g., Android tombstone with #NN pc frame lines, or legacy Apple .crash text format), stop immediately — this workflow does not apply. Report the format mismatch to the user and do not attempt any symbolication.
The .ips file is two-part JSON: line 1 is a metadata header; the remaining lines are a separate JSON crash body. Parse them separately:
lines = open('crash.ips').readlines()
metadata = json.loads(lines[0]) # app_name, bundleID, os_version, slice_uuid
crash = json.loads(''.join(lines[1:])) # Full crash reportKey fields in the crash body:
usedImages[N] has name, base (load address), uuid, arch for each loaded binarythreads[N].frames[M] has imageOffset, imageIndex; frame address = usedImages[imageIndex].base + imageOffsetexception.type, exception.signal (e.g., EXC_CRASH / SIGABRT)asi (Application Specific Information) often contains the managed exception messagelastExceptionBacktrace has frames from the exception that triggered the crashfaultingThread is the index into the threads arrayParsing gotcha: Some .ips files have case-conflicting duplicate keys (vmRegionInfo / vmregioninfo). Pre-process the raw JSON to rename the lowercase duplicate before parsing. The asi field may be absent.
Filter usedImages to .NET runtime libraries:
| Library | Runtime |
|---|---|
libcoreclr | CoreCLR runtime |
libmonosgen-2.0 | Mono runtime |
libSystem.Native | .NET BCL native component |
libSystem.Globalization.Native | .NET BCL globalization |
libSystem.Security.Cryptography.Native.Apple | .NET BCL crypto |
libSystem.IO.Compression.Native | .NET BCL compression |
libSystem.Net.Security.Native | .NET BCL net security |
On Apple platforms these ship as .framework bundles, so image names may omit .dylib. Match using substring (e.g., libcoreclr not libcoreclr.dylib). The app binary may appear twice in usedImages with different UUIDs.
Key bridge functions in the app binary: xamarin_process_managed_exception (managed exception bridged to ObjC NSException), xamarin_main, mono_jit_exec, coreclr_execute_assembly.
NativeAOT: Runtime is statically linked into the app binary. libSystem.* BCL libraries remain separate. The app binary needs its own dSYM from the build output.
Skip libsystem_kernel.dylib, UIKitCore, and other Apple system frameworks unless specifically asked.
Start with `asi` (Application Specific Information) — for .NET crashes, it often contains the managed exception type and message (e.g., XamlParseException, NullReferenceException). The root cause may already be visible here.
Then examine the faulting thread (threads[faultingThread]). Explain what frames #0 and #1 mean before examining other threads. Cross-thread context (GC state, thread pool) is useful for validation but not evidence of causation.
Also check lastExceptionBacktrace for the managed exception path through bridge functions like xamarin_process_managed_exception.
Sometimes the .NET runtime version is visible in image paths in usedImages, particularly on macOS when using shared-framework installs or NuGet-pack-style layouts (e.g., .../Microsoft.NETCore.App/10.0.4/libcoreclr.dylib). On iOS, however, image paths are typically inside the app bundle (for example, .../Frameworks/libcoreclr.framework/libcoreclr) and do not embed the runtime version, so you usually need to infer it via the Mach-O UUID by matching against SDK packs or symbol-server downloads rather than relying on the path alone.
For each .NET library needing symbolication, locate a UUID-matched dSYM:
.dwarf via https://msdl.microsoft.com/download/symbols/_.dwarf/mach-uuid-sym-{UUID}/_.dwarf (UUID lowercase, no dashes). Convert to .dSYM bundle (use the image name from usedImages[].name, e.g., libcoreclr): mkdir -p libcoreclr.dSYM/Contents/Resources/DWARF
cp _.dwarf libcoreclr.dSYM/Contents/Resources/DWARF/libcoreclrbin/Debug/net*-ios/ios-arm64/<App>.app.dSYM/$DOTNET_ROOT/packs/Microsoft.NETCore.App.Runtime.<rid>/<version>/runtimes/<rid>/native/~/.nuget/packages/microsoft.netcore.app.runtime.<rid>/<version>/runtimes/<rid>/native/dotnet-symbol --symbols -o symbols-out <path-to-binary.dylib>Always verify: dwarfdump --uuid <dsym> must match the UUID from the crash log exactly.
atos -arch arm64 -o <path.dSYM/Contents/Resources/DWARF/binary_name> -l <load_address> <frame_addresses...>-o points to the DWARF binary inside the .dSYM bundle (Contents/Resources/DWARF/), not the bundle itself-l is the load address from usedImages[N].basearch from usedImages[N].arch (usually arm64, may be arm64e)# Example: symbolicate libcoreclr frames
atos -arch arm64 -o libcoreclr.dSYM/Contents/Resources/DWARF/libcoreclr -l 0x104000000 0x104522098 0x1043c0014Strip the /__w/1/s/ CI workspace prefix from output — meaningful paths start at src/runtime/, mapping to the dotnet/dotnet VMR.
scripts/Symbolicate-Crash.ps1 automates the full workflow (parsing, dSYM lookup, symbol download, and symbolication). Resolve the path relative to this SKILL.md file.
# $SKILL_DIR is the directory containing this SKILL.md
pwsh "$SKILL_DIR/scripts/Symbolicate-Crash.ps1" -CrashFile MyApp-2026-02-25.ipsStart with -ParseOnly for a fast overview without requiring atos. The script automatically downloads symbols from the Microsoft symbol server when local dSYMs are missing.
Flags: -CrashingThreadOnly, -OutputFile path, -ParseOnly, -SkipVersionLookup, -SkipSymbolDownload, -SymbolCacheDir path, -DsymSearchPaths path1,path2.
Pull crash logs from a connected iOS device using idevicecrashreport (from libimobiledevice):
idevicecrashreport -e /tmp/crashlogs/
find /tmp/crashlogs/ -iname '*MyApp*' -name '*.ips'Also available in Xcode > Window > Devices and Simulators > View Device Logs, or at ~/Library/Logs/CrashReporter/ (Mac Catalyst), ~/Library/Logs/DiagnosticReports/ (macOS).
dwarfdump --uuid <dsym> matches UUID from the crash logsrc/coreclr/, mono/metadata/, mono/mini/).ips JSON (e.g., Android tombstone with #NN pc stack frames, legacy .crash text format), stop immediately — report the format mismatch to the user and do not proceed with any symbolication. Do not attempt to symbolicate using other tools or workflows.atos commands for the user to run. Do not install Xcode. atos ships with Xcode Command Line Tools (xcode-select --install).~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.