harlogger is a pure-Python utility that taps undocumented Apple CFNetwork diagnostics to display decrypted HTTP/HTTPS traffic from macOS and iOS devices, intended for authorized debugging and research.
| Tool | doronz88/harlogger — pure-Python sniffer for decrypted HTTP/HTTPS traffic via undocumented Apple CFNetwork HAR-capture APIs |
| Category | Network traffic capture and mobile device instrumentation |
| Primary Use | Observing plaintext HTTP/HTTPS requests and responses from processes using Apple's CFNetwork framework, on macOS hosts, non-jailbroken iOS devices, and jailbroken iOS devices, during authorized debugging and assessments |
| Safe Use | Use only on devices you own or are explicitly authorized to test — lab devices, corporate macOS fleets under agreement, or penetration tests with written scope; the tool is equally valuable to defenders auditing what their own apps and devices transmit |
| Telemetry Note | Use leaves clear traces: installed .mobileconfig profiles in the device's profile list, a modified com.apple.CFNetwork plist in /var/mobile/Library/Preferences/, and console-style diagnostic output on the host; on iOS 15+ HAR capture additionally requires special entitlements or debug builds, making silent use difficult |
harlogger, maintained by doronz88, is a deceptively simple piece of tooling that exploits one of Apple's quietly shipped but barely documented debugging facilities. Rather than performing a traditional man-in-the-middle attack with a proxy and a custom CA certificate, it reads from the CFNetwork framework's own built-in traffic-capture path — the same machinery Apple engineers presumably use internally for network diagnostics. The result is decrypted HTTP/HTTPS traffic printed straight to your terminal, with no certificates to install on the wire side and no proxy configuration. At roughly 186 stars and written in pure Python under GPL-3.0, it is a small, focused instrument from the same author as the well-known pymobiledevice3 project.
The README is unusually instructive because it enumerates four distinct capture modes, each corresponding to a different trust posture on the target device. The first is the profile method on a macOS host: you install Apple's own CFNetwork debugging profile (a NetworkDiagnostic.mobileconfig available from Apple's developer downloads), after which python3 -m harlogger profile starts streaming traffic from processes using CFNetwork. The README is candid about the limitation — this mode does not include request or response bodies, so you get headers, URLs, and methods, but not payloads. That is still enough for a great deal of reconnaissance on what an application is talking to and how.
The second mode extends the same profile technique to non-jailbroken iOS devices, which is where the tool becomes genuinely interesting for authorized mobile assessments. You install CFNetworkDiagnostics.mobileconfig on the device — the README demonstrates this via pymobiledevice3 profile install CFNetworkDiagnostics.mobileconfig — and then run python3 -m harlogger mobile profile. The key architectural point is that instrumentation happens inside the OS network stack, not on the network itself, so TLS is already decrypted by the time the diagnostic events are emitted. For researchers analyzing devices they own, this sidesteps the classic pain of certificate pinning, since pinning happens above the layer where capture occurs.
The third mode is the most powerful and the most restricted: the secret preference method for jailbroken devices. On iOS 14.x, the system contains a hidden feature that dumps decrypted traffic from all CFNetwork-using processes into HAR format. Activating it involves placing a bundled com.apple.CFNetwork.plist into /var/mobile/Library/Preferences/, rebooting, and running python3 -m harlogger preference. Unlike the profile modes, this variant includes request and response bodies, as the README's sample output shows with full POST payloads from a bing.com telemetry endpoint rendered inline. The README is explicit that iOS 13.x and below lack this feature entirely, so version targeting matters here.
The fourth mode documents how iOS 15.0 changed the game. Apple tightened the feature so the target process must carry specific entitlements — com.apple.private.cfnetwork.har-capture-delegation, get-task-allow, or com.apple.security.get-task-allow — or the OS build must be in debug mode. To bridge this, the README shows enabling HAR logging through the same author's pymobiledevice3 with python3 -m pymobiledevice3 developer dvt har, then capturing via the preference method. This dependency chain is a nice example of how harlogger sits atop a broader device-instrumentation ecosystem rather than reinventing transport protocols itself.
From a defensive and research perspective, the value of this tool is considerable. Blue teams and privacy researchers can use it on owned hardware to audit exactly what first-party and third-party applications exfiltrate — the README's own output captures bing.com telemetry POSTs with session cookies, a vivid illustration of how much identifiable signal ordinary apps emit. Because the output format includes full headers, Cookie values, User-Agent strings, and Referer chains, it doubles as a teaching aid for demonstrating why HTTPS alone is not privacy. Incident responders examining a suspect iOS app in a sandbox can also use it to characterize command traffic without setting up Burp or mitmproxy and fighting pinning.
Operationally, the footprint of the tool is worth understanding in both directions. On the capture side, the profile methods leave a visible .mobileconfig in the device's settings, and the jailbreak method writes a preference plist and requires a reboot — hardly stealthy. On the data side, output lands in plaintext on the operator's terminal, including session tokens and cookies, so analysts should treat captures as sensitive artifacts. The iOS 15 entitlement requirement is itself a mitigating control defenders should appreciate: stock devices running release builds resist capture of third-party processes unless the app was compiled with debug allowances.
Installation is minimal by design: python3 -m pip install -U harlogger pulls the package, with pymobiledevice3 as an optional companion for profile installation and developer-mode instrumentation. There is no daemon, no persistence mechanism, and no network service — the tool is a passive consumer of diagnostic events the OS already emits once configured. That purity is part of why it works: it never touches the traffic path, it simply listens where Apple left a diagnostic tap.
In an authorized workflow, harlogger fills a niche between full MITM proxies and on-device Frida hooking. It is faster to stand up than a proxy, less invasive than runtime instrumentation, and uniquely capable of showing traffic from processes that aggressively pin certificates. Its limitations are equally clear: it only sees CFNetwork-based traffic (missing raw sockets and alternative networking stacks), body capture depends on the device state, and newer iOS versions constrain it further. For professionals working on Apple platforms they are authorized to examine, it remains one of the most elegant demonstrations of how vendor debugging facilities can be repurposed into a first-class traffic-analysis instrument.
doronz88/harlogger.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.