morluto/rea

Fork 0

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

[GH-ISSUE #4297] [Feature] Inspect Apple .ips crash reports as recorded-crash Evidence #1701

New issue

Open

opened 2026-10-16 21:09:14 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

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

REA cannot read the crash reports that macOS and iOS write. Accept a caller-selected Apple .ips crash report (the JSON format Apple has used since iOS 15 and macOS 12) as recorded-crash Evidence: report its metadata, exception and termination facts, threads and binary images; normalize every frame to an image build UUID, architecture and image offset; join frames to a caller-opened Mach-O or dSYM whose LC_UUID matches; and classify the crash deterministically from the fixed strings Apple documents. This would be the Apple child of roadmap #2357, whose recorded-crash children are the Linux AArch64 core profile (#2353, closed) and the Windows minidump request (#2355); neither covers Apple reports.

An analyst holding a crash report from ~/Library/Logs/DiagnosticReports or from a device wants to know which function in the binary faulted and why. REA cannot answer either question today. Measured with REA 6.5.0 (npx -y 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) and Node.js v26.10.0: a self-built fixture that writes to address 0x10 produced rea-crash-fixture-<date>.ips. Its first line is a metadata object with string bug_type "309"; the body reports EXC_BAD_ACCESS, SIGSEGV, subtype KERN_INVALID_ADDRESS at 0x0000000000000010, and frame 0 as imageIndex 0, imageOffset 824. Image 0's uuid equals the fixture's LC_UUID (lowercase in the report, uppercase from dwarfdump --uuid), and atos -arch arm64 -o ./rea-crash-fixture -l 0x100000000 0x100000338 resolves that offset to rea_fixture_fault (crashme.c:2). The release build's rea inspect-recorded-crash "$PWD/fixture.ips" --json returned capability_unavailable with "The initial real-verified pwntools artifact profile supports Linux x64 only."

The refusal is not only a host gate. The tool's input is "Absolute filesystem path to a supplied Linux ELF core" (recordedCrash.ts); its contract describes only Linux ELF64 amd64 and AArch64 cores on a Linux x64 host profile (binaryDiagnosticsToolContracts.ts); the host gate is fixed text (PwntoolsDecoder.ts); and the Evidence format is hard-coded to "elf" (RecordedCrashService.ts). A repository search of src, bridge and docs finds no handling of .ips, bug_type or usedImages. The analyst therefore leaves REA to symbolicate with atos or xcrun crashlog and then copies addresses back by hand.

Use cases

No response

Desired outcome and success criteria

Accept one caller-selected .ips file without an open target and without launching anything. The report is JSON, so the result should not depend on the host OS or on pwntools; a Linux host and a macOS host should return the same Evidence for the same file.
Parse the first line as the metadata object and report its fields, keeping bug_type as the string it is. Parse the remainder as the crash body only when bug_type is "309". Any other type, including "288" (stackshot), returns a typed unsupported outcome that names the type, with no partial crash result.
Report the documented body fields when present: process identity (procName, procPath as recorded, pid, parentProc, cpuType, translated), osVersion, exception (type, signal, subtype, codes, message), termination (namespace, code as both the recorded decimal and hexadecimal, indicator, and any further members retained as recorded), faultingThread, threads and usedImages. Keep keys the documentation does not list as raw recorded fields rather than dropping them.
Preserve every recorded integer exactly. Thread-state registers in an arm64e report carry signed pointers above 2^53.
For every frame, report the image index, the image's build UUID in canonical uppercase form, its arch, imageOffset in decimal and hexadecimal, the runtime address base + imageOffset, and whether the frame is the faulting instruction (frame 0) or a return address. Report each image's source letter with its documented meaning (P process, S shared cache, C shared cache library, K kernel, U kernel cache, T kernel text exec, A absolute). An image with an all-zero UUID or a null arch stays unknown and never joins.
When the caller has opened a Mach-O or supplies a dSYM, join each frame whose image UUID equals the LC_UUID of one of its slices: report the static address (__TEXT vmaddr plus imageOffset) and the containing function or symbol that REA's existing analysis already knows. Reject a join on UUID or architecture mismatch with an explicit reason. Symbol names printed inside the report are recorded as report claims and are not verified.
Add a classification block whose rules use only fixed strings and values from Apple's documentation, and report the rule name and the matched fields for each match: SIGKILL termination codes (for example 0x8badf00d watchdog, 0xdead10cc, 0xc00010ff); EXC_GUARD with GUARD_TYPE_FD and its violation message, and EXC_GUARD with GUARD_TYPE_MACH_PORT and one of the documented Mach IPC messages; EXC_BAD_ACCESS whose subtype ends in (possible pointer authentication failure), reported as possible with the signed and stripped addresses and Apple's caveat attached; and dyld missing-library terminations. A report that matches no rule is unclassified, never guessed.
Report coverage (threads, frames and images parsed versus recorded), limitations, and the file's SHA-256 as provenance, following the existing recorded-crash conventions. A malformed or truncated second object fails closed with a typed error.

Acceptance criteria

Fixture A, built with printf '__attribute__((noinline)) void rea_fixture_fault(volatile int *p){*p=42;}\nint main(void){rea_fixture_fault((volatile int *)0x10);return 0;}\n' > crashme.c && clang -g -O0 -o rea-crash-fixture crashme.c && ./rea-crash-fixture (the system writes ~/Library/Logs/DiagnosticReports/rea-crash-fixture-<date>.ips): the result reports bug_type "309", EXC_BAD_ACCESS, SIGSEGV, the faulting thread, and frame 0's image UUID equal to dwarfdump --uuid ./rea-crash-fixture.
With fixture A opened, frame 0 joins to rea_fixture_fault and frame 1 to main, at the static addresses atos -arch arm64 -o ./rea-crash-fixture -l 0x100000000 <address> resolves to the same functions.
After rebuilding fixture A with a source change, so its UUID differs, the old report does not join and states the UUID mismatch.
Fixture B, the same program built with clang -arch arm64e: register values above 2^53 in threadState (one observed was 0x8527000193ed4944) are returned exactly, in decimal and hexadecimal.
Fixture C, built with printf 'int f(void){return 1;}\n' > lib.c && clang -dynamiclib -install_name @rpath/libreamissing.dylib -o libreamissing.dylib lib.c && printf 'int f(void);\nint main(void){return f();}\n' > usem.c && clang -o rea-dyld-fixture usem.c -L. -lreamissing -Wl,-rpath,@executable_path/nolib && rm libreamissing.dylib && ./rea-dyld-fixture: the dyld rule matches and names @rpath/libreamissing.dylib.
Copies of fixture A edited to carry the documented strings (termination code 2343432205; EXC_GUARD with GUARD_TYPE_FD; a subtype ending in (possible pointer authentication failure)) match the watchdog, guarded-descriptor and possible-pointer-authentication rules; an unedited fixture A matches none of them and is not mislabelled.
A copy whose first-line bug_type is "288" returns the typed unsupported outcome, and a copy truncated inside the body returns a typed parse error; neither returns a partial crash result.
CLI and MCP return the same Evidence, and the same file gives the same result on a Linux x64 host.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Affected area

inspect_recorded_crash or a sibling recorded-crash operation, its CLI command, MCP schema and docs/recorded-crashes.md, and the join to inspect_macho slice identity (LC_UUID) and existing function or symbol lookup for an opened target.

Non-goals

Legacy .crash text reports, MetricKit payloads (MXCallStackTree and the 27.x DiagnosticReport types), App Store Connect diagnostic logs and jetsam event reports. Each has its own grammar and is a candidate follow-up.
Discovering dSYMs on its own, Spotlight (mdfind) searches, or network symbol servers. Joins use only binaries or dSYMs the caller selected; matching dSYM support for Ghidra is tracked in #1193 and PR #2025.
Running atos, xcrun crashlog, LLDB or CrashSymbolicator.py, or symbolizing images that live in the dyld shared cache (source S or C).
Collecting reports from devices or simulators, or attaching to live processes; that needs a maintainer scope decision.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

No response

Alternatives considered

xcrun crashlog and CrashSymbolicator.py symbolicate a report against dSYMs, and atos resolves single addresses. They need Xcode, run outside REA's session, and produce text that is not Evidence linked to the opened binary.
Converting the .ips to a Linux core so the existing tool accepts it is not meaningful: the report holds no memory segments or ELF notes.

Possible direction

No response

References

Interpreting the JSON format of a crash report: "Starting with iOS 15 and macOS 12, apps that generate crash reports store the data as JSON in files with an .ips extension." "The IPS file for a crash report contains two JSON objects ... extract the JSON for the metadata object from the first line. If the bug_type property of the metadata object is 309 ... you can extract the JSON for the crash report data from the remainder of the text." bug_type is typed String, and "Type 288, for instance, is a stackshot." imageOffset: "If you add this value to the base value from the binary images list, you'll get the runtime memory address". uuid: "A build UUID that uniquely identifies the binary image". translated marks "a process with X86-64 instructions running translated under Rosetta". "JSON stores numeric values as decimal numbers."
SIGKILL lists the termination codes, for example "0x8badf00d (2343432205)": "The operating system's watchdog terminated the app."
EXC_GUARD: "most guarded resource crashes are from guarded file descriptors, which have the GUARD_TYPE_FD value in the Exception Subtype field." Conforming to Mach IPC security restrictions: "The crash report has an exception type of EXC_GUARD, and exception subtype of GUARD_TYPE_MACH_PORT", followed by the list of message values such as THREAD_SET_STATE.
Investigating memory access crashes: "A crash due to a possible pointer authentication failure uses the KERN_INVALID_ADDRESS exception subtype with an additional message on the end", and "An invalid memory access, where high-order bits are erroneously set, can look like a pointer authentication failure".
Addressing missing framework crashes shows the dyld text ("dependent dylib ... not found", "tried but didn't find", or "Library not loaded") and warns "The exact message depends on the operating system and operating system version."
Observed in the macOS 27.0.1 fixture reports but absent from Apple's JSON key tables: fixture C records the dyld failure as termination.namespace "DYLD", indicator "Library missing" and a reasons array whose first entry is Library not loaded: @rpath/libreamissing.dylib; the bodies also carry keys such as sharedCache, codeSigningID and instructionByteStream; and fixture A's image list contains an entry with an all-zero UUID, null arch and source "A". The parser must therefore tolerate unlisted keys, and the dyld rule cannot rely only on the translated-text wording.
Adding identifiable symbol names to a crash report documents atos, xcrun crashlog and CrashSymbolicator.py.
Scope: static format inspection is in scope (CONTRIBUTING.md). The current recorded-crash guide covers Linux ELF cores only (docs/recorded-crashes.md).
Main at d52a488 changes only Evidence completion in RecordedCrashService.ts (the cited source files are otherwise unchanged); the format stays "elf", and main has no .ips handling.
Related: roadmap #2357 and its children #2353 and #2355; #1193 and PR #2025 (matching dSYMs for Ghidra). GitHub searches for "ips crash report", "Apple crash report", "crash report macOS", "symbolication" and "dSYM UUID" found no existing request for Apple crash reports.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4297 ### 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 REA cannot read the crash reports that macOS and iOS write. Accept a caller-selected Apple `.ips` crash report (the JSON format Apple has used since iOS 15 and macOS 12) as recorded-crash Evidence: report its metadata, exception and termination facts, threads and binary images; normalize every frame to an image build UUID, architecture and image offset; join frames to a caller-opened Mach-O or dSYM whose `LC_UUID` matches; and classify the crash deterministically from the fixed strings Apple documents. This would be the Apple child of roadmap #2357, whose recorded-crash children are the Linux AArch64 core profile (#2353, closed) and the Windows minidump request (#2355); neither covers Apple reports. An analyst holding a crash report from `~/Library/Logs/DiagnosticReports` or from a device wants to know which function in the binary faulted and why. REA cannot answer either question today. Measured with REA 6.5.0 (`npx -y 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) and Node.js v26.10.0: a self-built fixture that writes to address `0x10` produced `rea-crash-fixture-<date>.ips`. Its first line is a metadata object with string `bug_type` `"309"`; the body reports `EXC_BAD_ACCESS`, `SIGSEGV`, subtype `KERN_INVALID_ADDRESS at 0x0000000000000010`, and frame 0 as `imageIndex` 0, `imageOffset` 824. Image 0's `uuid` equals the fixture's `LC_UUID` (lowercase in the report, uppercase from `dwarfdump --uuid`), and `atos -arch arm64 -o ./rea-crash-fixture -l 0x100000000 0x100000338` resolves that offset to `rea_fixture_fault (crashme.c:2)`. The release build's `rea inspect-recorded-crash "$PWD/fixture.ips" --json` returned `capability_unavailable` with "The initial real-verified pwntools artifact profile supports Linux x64 only." The refusal is not only a host gate. The tool's input is "Absolute filesystem path to a supplied Linux ELF core" ([recordedCrash.ts](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/native/recordedCrash.ts#L141-L152)); its contract describes only Linux ELF64 amd64 and AArch64 cores on a Linux x64 host profile ([binaryDiagnosticsToolContracts.ts](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/contracts/native/binaryDiagnosticsToolContracts.ts#L66-L72)); the host gate is fixed text ([PwntoolsDecoder.ts](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/pwntools/PwntoolsDecoder.ts#L56-L57)); and the Evidence format is hard-coded to `"elf"` ([RecordedCrashService.ts](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/binaryDiagnostics/RecordedCrashService.ts#L100-L106)). A repository search of `src`, `bridge` and `docs` finds no handling of `.ips`, `bug_type` or `usedImages`. The analyst therefore leaves REA to symbolicate with `atos` or `xcrun crashlog` and then copies addresses back by hand. ### Use cases _No response_ ### Desired outcome and success criteria - Accept one caller-selected `.ips` file without an open target and without launching anything. The report is JSON, so the result should not depend on the host OS or on pwntools; a Linux host and a macOS host should return the same Evidence for the same file. - Parse the first line as the metadata object and report its fields, keeping `bug_type` as the string it is. Parse the remainder as the crash body only when `bug_type` is `"309"`. Any other type, including `"288"` (stackshot), returns a typed unsupported outcome that names the type, with no partial crash result. - Report the documented body fields when present: process identity (`procName`, `procPath` as recorded, `pid`, `parentProc`, `cpuType`, `translated`), `osVersion`, `exception` (`type`, `signal`, `subtype`, `codes`, `message`), `termination` (`namespace`, `code` as both the recorded decimal and hexadecimal, `indicator`, and any further members retained as recorded), `faultingThread`, `threads` and `usedImages`. Keep keys the documentation does not list as raw recorded fields rather than dropping them. - Preserve every recorded integer exactly. Thread-state registers in an arm64e report carry signed pointers above 2^53. - For every frame, report the image index, the image's build UUID in canonical uppercase form, its `arch`, `imageOffset` in decimal and hexadecimal, the runtime address `base + imageOffset`, and whether the frame is the faulting instruction (frame 0) or a return address. Report each image's `source` letter with its documented meaning (`P` process, `S` shared cache, `C` shared cache library, `K` kernel, `U` kernel cache, `T` kernel text exec, `A` absolute). An image with an all-zero UUID or a null `arch` stays unknown and never joins. - When the caller has opened a Mach-O or supplies a dSYM, join each frame whose image UUID equals the `LC_UUID` of one of its slices: report the static address (`__TEXT` vmaddr plus `imageOffset`) and the containing function or symbol that REA's existing analysis already knows. Reject a join on UUID or architecture mismatch with an explicit reason. Symbol names printed inside the report are recorded as report claims and are not verified. - Add a classification block whose rules use only fixed strings and values from Apple's documentation, and report the rule name and the matched fields for each match: SIGKILL termination codes (for example `0x8badf00d` watchdog, `0xdead10cc`, `0xc00010ff`); `EXC_GUARD` with `GUARD_TYPE_FD` and its violation message, and `EXC_GUARD` with `GUARD_TYPE_MACH_PORT` and one of the documented Mach IPC messages; `EXC_BAD_ACCESS` whose subtype ends in `(possible pointer authentication failure)`, reported as possible with the signed and stripped addresses and Apple's caveat attached; and dyld missing-library terminations. A report that matches no rule is `unclassified`, never guessed. - Report coverage (threads, frames and images parsed versus recorded), limitations, and the file's SHA-256 as provenance, following the existing recorded-crash conventions. A malformed or truncated second object fails closed with a typed error. **Acceptance criteria** - Fixture A, built with `printf '__attribute__((noinline)) void rea_fixture_fault(volatile int *p){*p=42;}\nint main(void){rea_fixture_fault((volatile int *)0x10);return 0;}\n' > crashme.c && clang -g -O0 -o rea-crash-fixture crashme.c && ./rea-crash-fixture` (the system writes `~/Library/Logs/DiagnosticReports/rea-crash-fixture-<date>.ips`): the result reports `bug_type` `"309"`, `EXC_BAD_ACCESS`, `SIGSEGV`, the faulting thread, and frame 0's image UUID equal to `dwarfdump --uuid ./rea-crash-fixture`. - With fixture A opened, frame 0 joins to `rea_fixture_fault` and frame 1 to `main`, at the static addresses `atos -arch arm64 -o ./rea-crash-fixture -l 0x100000000 <address>` resolves to the same functions. - After rebuilding fixture A with a source change, so its UUID differs, the old report does not join and states the UUID mismatch. - Fixture B, the same program built with `clang -arch arm64e`: register values above 2^53 in `threadState` (one observed was `0x8527000193ed4944`) are returned exactly, in decimal and hexadecimal. - Fixture C, built with `printf 'int f(void){return 1;}\n' > lib.c && clang -dynamiclib -install_name @rpath/libreamissing.dylib -o libreamissing.dylib lib.c && printf 'int f(void);\nint main(void){return f();}\n' > usem.c && clang -o rea-dyld-fixture usem.c -L. -lreamissing -Wl,-rpath,@executable_path/nolib && rm libreamissing.dylib && ./rea-dyld-fixture`: the dyld rule matches and names `@rpath/libreamissing.dylib`. - Copies of fixture A edited to carry the documented strings (termination code `2343432205`; `EXC_GUARD` with `GUARD_TYPE_FD`; a subtype ending in `(possible pointer authentication failure)`) match the watchdog, guarded-descriptor and possible-pointer-authentication rules; an unedited fixture A matches none of them and is not mislabelled. - A copy whose first-line `bug_type` is `"288"` returns the typed unsupported outcome, and a copy truncated inside the body returns a typed parse error; neither returns a partial crash result. - CLI and MCP return the same Evidence, and the same file gives the same result on a Linux x64 host. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) **Affected area** `inspect_recorded_crash` or a sibling recorded-crash operation, its CLI command, MCP schema and `docs/recorded-crashes.md`, and the join to `inspect_macho` slice identity (`LC_UUID`) and existing function or symbol lookup for an opened target. **Non-goals** - Legacy `.crash` text reports, MetricKit payloads (`MXCallStackTree` and the 27.x `DiagnosticReport` types), App Store Connect diagnostic logs and jetsam event reports. Each has its own grammar and is a candidate follow-up. - Discovering dSYMs on its own, Spotlight (`mdfind`) searches, or network symbol servers. Joins use only binaries or dSYMs the caller selected; matching dSYM support for Ghidra is tracked in #1193 and PR #2025. - Running `atos`, `xcrun crashlog`, LLDB or `CrashSymbolicator.py`, or symbolizing images that live in the dyld shared cache (`source` `S` or `C`). - Collecting reports from devices or simulators, or attaching to live processes; that needs a maintainer scope decision. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) _No response_ ### Alternatives considered - `xcrun crashlog` and `CrashSymbolicator.py` symbolicate a report against dSYMs, and `atos` resolves single addresses. They need Xcode, run outside REA's session, and produce text that is not Evidence linked to the opened binary. - Converting the `.ips` to a Linux core so the existing tool accepts it is not meaningful: the report holds no memory segments or ELF notes. ### Possible direction _No response_ ### References - [Interpreting the JSON format of a crash report](https://developer.apple.com/documentation/xcode/interpreting-the-json-format-of-a-crash-report): "Starting with iOS 15 and macOS 12, apps that generate crash reports store the data as JSON in files with an `.ips` extension." "The IPS file for a crash report contains two JSON objects ... extract the JSON for the metadata object from the first line. If the `bug_type` property of the metadata object is `309` ... you can extract the JSON for the crash report data from the remainder of the text." `bug_type` is typed String, and "Type `288`, for instance, is a stackshot." `imageOffset`: "If you add this value to the `base` value from the binary images list, you'll get the runtime memory address". `uuid`: "A build UUID that uniquely identifies the binary image". `translated` marks "a process with X86-64 instructions running translated under Rosetta". "JSON stores numeric values as decimal numbers." - [SIGKILL](https://developer.apple.com/documentation/xcode/sigkill) lists the termination codes, for example "`0x8badf00d` (`2343432205`)": "The operating system's watchdog terminated the app." - [EXC_GUARD](https://developer.apple.com/documentation/xcode/exc_guard): "most guarded resource crashes are from guarded file descriptors, which have the `GUARD_TYPE_FD` value in the `Exception Subtype` field." [Conforming to Mach IPC security restrictions](https://developer.apple.com/documentation/xcode/conforming-to-mach-ipc-security-restrictions): "The crash report has an exception type of `EXC_GUARD`, and exception subtype of `GUARD_TYPE_MACH_PORT`", followed by the list of message values such as `THREAD_SET_STATE`. - [Investigating memory access crashes](https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes): "A crash due to a possible pointer authentication failure uses the `KERN_INVALID_ADDRESS` exception subtype with an additional message on the end", and "An invalid memory access, where high-order bits are erroneously set, can look like a pointer authentication failure". - [Addressing missing framework crashes](https://developer.apple.com/documentation/xcode/addressing-missing-framework-crashes) shows the dyld text ("dependent dylib ... not found", "tried but didn't find", or "Library not loaded") and warns "The exact message depends on the operating system and operating system version." - Observed in the macOS 27.0.1 fixture reports but absent from Apple's JSON key tables: fixture C records the dyld failure as `termination.namespace` `"DYLD"`, `indicator` `"Library missing"` and a `reasons` array whose first entry is `Library not loaded: @rpath/libreamissing.dylib`; the bodies also carry keys such as `sharedCache`, `codeSigningID` and `instructionByteStream`; and fixture A's image list contains an entry with an all-zero UUID, null `arch` and `source` `"A"`. The parser must therefore tolerate unlisted keys, and the dyld rule cannot rely only on the translated-text wording. - [Adding identifiable symbol names to a crash report](https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report) documents `atos`, `xcrun crashlog` and `CrashSymbolicator.py`. - Scope: static format inspection is in scope ([CONTRIBUTING.md](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/CONTRIBUTING.md#L111-L115)). The current recorded-crash guide covers Linux ELF cores only ([docs/recorded-crashes.md](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/docs/recorded-crashes.md#L1-L7)). - Main at `d52a488` changes only Evidence completion in `RecordedCrashService.ts` (the cited source files are otherwise unchanged); the format stays `"elf"`, and main has no `.ips` handling. - Related: roadmap #2357 and its children #2353 and #2355; #1193 and PR #2025 (matching dSYMs for Ghidra). GitHub searches for "ips crash report", "Apple crash report", "crash report macOS", "symbolication" and "dSYM UUID" found no existing request for Apple crash reports.

bsakaguchi referenced this issue

2026-10-17 21:01:35 +00:00

[GH-ISSUE #3111] [Windows] Native controls self-check blocks static Android APK analysis on Win11 build 26300 (rea-agents 6.4.0) #1083

bsakaguchi referenced this issue

2026-10-17 21:01:55 +00:00

[GH-ISSUE #3537] [Tracker] Audit and subsystem index of active bug reports (October 2026) #1313

bsakaguchi referenced this issue

2026-10-17 21:04:56 +00:00

[GH-ISSUE #4707] [Bug] Windows: rea analyze rejects backslash absolute paths with "Ambiguous Windows path component is unsupported" (Win32 50) #2455

bsakaguchi referenced this issue

2026-10-31 00:29:18 +00:00

[GH-ISSUE #1701] [Bug] Windows native authority self-test fails on real Windows: "Delete owned object by handle failed" (Win32 5), and leaves probe directories behind #568

bsakaguchi commented

2026-10-31 00:32:15 +00:00

Author

Owner

@morluto commented on GitHub (Oct 26, 2026):

Thank you for the detailed report and fixture criteria. #6511 has landed inspect_apple_ips with lossless crash-report facts and classification, so it covers the offline inspection portion. I am keeping this request open because the requested UUID/architecture join to a caller-selected Mach-O or dSYM and function/symbol resolution were explicitly outside that PR; its validation also did not qualify live OS capture or symbolication. This assessment is from the issue and merged PR descriptions; no new provider run was performed.

@morluto commented on GitHub (Oct 26, 2026): Thank you for the detailed report and fixture criteria. #6511 has landed `inspect_apple_ips` with lossless crash-report facts and classification, so it covers the offline inspection portion. I am keeping this request open because the requested UUID/architecture join to a caller-selected Mach-O or dSYM and function/symbol resolution were explicitly outside that PR; its validation also did not qualify live OS capture or symbolication. This assessment is from the issue and merged PR descriptions; no new provider run was performed.

bsakaguchi referenced this issue

2026-10-31 00:32:19 +00:00

[GH-ISSUE #4330] [Tracker] Audit and consolidation index of duplicate issues and reports (October 2026) #1722

bsakaguchi referenced this issue

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

[GH-ISSUE #5237] [Windows native] Private DACL contains unexpected trustees (Win32 5) blocks Android inspection before JADX #3202

bsakaguchi referenced this issue

2026-10-31 00:55:51 +00:00

[PR #1826] [MERGED] fix(windows): retain failed native inspection ownership #4841

bsakaguchi referenced this issue

2026-10-31 00:59:30 +00:00

[PR #2108] [CLOSED] fix(windows): classify native readiness failures by stage #5034