Merge pull request #2477 from HackTricks-wiki/research_update_src_macos-hardening_macos-security-and-privilege-escalation_macos-files-folders-and-binaries_macos-memory-dumping_20260707_144959

Research Update Enhanced src/macos-hardening/macos-security-...

Author: carlospolop

src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/macos-memory-dumping.md

@@ -102,6 +102,28 @@ For more background on obtaining a task port and what can be done with it:
 ../macos-proces-abuse/macos-ipc-inter-process-communication/macos-thread-injection-via-task-port.md
 {{#endref}}
 
+### Fast pre-attach checks
+
+Before spending time on LLDB/Frida, quickly verify whether the target is realistically **dumpable**:
+
+```bash
+# Check entitlements that commonly decide whether an attach will work
+codesign -d --entitlements - /Applications/Target.app 2>/dev/null | \
+  egrep -A1 'get-task-allow|com.apple.security.cs.debugger'
+
+# Quick view of hardened runtime / code-signing flags
+codesign -dvvv /Applications/Target.app 2>&1 | egrep 'Runtime Version|flags='
+
+# Inspect memory layout before deciding between a full core and a selective dump
+vmmap <pid>
+```
+
+Operationally, this usually means:
+
+- A third-party app shipped with **`get-task-allow`** is often directly dumpable with LLDB, and the resulting dump may expose TCC-protected data that the app already accessed.
+- A **hardened** target without `get-task-allow` will commonly reject attaches, even as `root`, unless you control the relevant debugger entitlements / policy path.
+- Unhardened third-party processes are still the easiest place to use `lldb`, `vmmap`, Frida, or custom `task_for_pid`/`vm_read` readers.
+
 ## Selective dumps with Frida or userland readers
 
 When a full core is too noisy, dumping only **interesting readable ranges** is often faster. Frida is especially useful because it works well for **targeted extraction** once you can attach to the process.
@@ -134,6 +156,55 @@ This is useful when you want to avoid giant core files and only collect:
 
 Older userland tools such as [`readmem`](https://github.com/gdbinit/readmem) also exist, but they are mainly useful as **source references** for direct `task_for_pid`/`vm_read` style dumping and are not well-maintained for modern Apple Silicon workflows.
 
+## Heap / VM snapshots with `.memgraph`
+
+If you mainly care about **heap objects**, **allocation provenance**, or a snapshot that can be moved to another machine, a `.memgraph` is often more practical than a giant Mach-O core. The `leaks` tooling can generate one from a live process:
+
+```bash
+# Capture a memory graph from a live process
+leaks <pid> -outputGraph /tmp/target.memgraph
+
+# Include richer object content when you expect to inspect strings / heap data offline
+leaks <pid> -outputGraph /tmp/target-full.memgraph -fullContent
+```
+
+Then triage it offline with standard Apple tooling:
+
+```bash
+vmmap /tmp/target.memgraph
+heap /tmp/target.memgraph
+stringdups /tmp/target-full.memgraph
+malloc_history /tmp/target.memgraph 0xADDR
+```
+
+`stringdups` is the main reason to keep a `-fullContent` capture around, because the labels describing memory contents are omitted from a minimal `.memgraph`.
+
+This is especially useful when:
+
+- You want a **smaller, shareable snapshot** instead of a full core
+- `MallocStackLogging` was enabled and you want **allocation backtraces**
+- You already know an **interesting heap address** and want to pivot with `malloc_history`
+- You need a quick **VM/heap breakdown** before deciding whether a full dump is worth the noise
+
+## Swift-heavy targets: `swift-inspect`
+
+For applications that keep high-value data inside **Swift runtime objects**, `swift-inspect` can be a good complement to LLDB or Frida. Instead of dumping everything first, you can query specific Swift runtime structures from a live process:
+
+```bash
+# Usually available from the Xcode / Swift toolchain
+swift-inspect dump-raw-metadata <pid-or-name>
+swift-inspect dump-arrays <pid-or-name>
+swift-inspect dump-concurrency <pid-or-name> # Darwin-only
+```
+
+This is handy to identify:
+
+- Large Swift arrays buffering interesting data
+- Metadata allocations that reveal types loaded at runtime
+- Swift concurrency state (`Task`, actor, thread relationships) before doing a more targeted dump
+
+For more object-level runtime triage once you can already inspect the process, check [the dedicated page on objects in memory](../macos-apps-inspecting-debugging-and-fuzzing/objects-in-memory.md).
+
 ## Quick triage notes
 
 - `sysctl vm.swapusage` is still a quick way to check **swap usage** and whether swap is **encrypted**.