🏷️ Discussion Type

Bug

Body

Seeking Help: Persistent iOS System Identity Spoofing Across 2.5 Years — Need Guidance on Detection/Diagnosis Tools

Labels: Help Question iOS Security

Context

I'm a developer working on an iOS system diagnostics tool that collects detailed hardware and software telemetry from devices. For approximately 2.5 years, I've encountered a persistent and deeply confusing issue: one of my test devices consistently reports contradictory system information that I cannot explain through normal variation, data collection bugs, or known iOS behavior.

I'm not asking anyone to write code for me. I'm seeking:

• Guidance on debugging approaches for low-level system identity discrepancies
• Recommendations for open-source tools that can validate sysctl/IOKit values against ground truth
• Insight from anyone who's worked with iOS kernel internals, jailbreak detection, or hardware enumeration

The Problem

My diagnostic tool collects data via standard iOS APIs (sysctl, uname, IOKit, UIDevice, ProcessInfo). On this particular device, the collected data contains internally inconsistent hardware identification that has persisted across multiple iOS updates and tool revisions.

Key Discrepancies Observed

These values are collected in the same session, seconds apart. The contradictions are not intermittent — they're stable across multiple samples spanning minutes.

What I've Ruled Out

1. Data collection bug in my tool: I've instrumented every property fetch with raw sysctl output logging. The values are what the kernel returns. Different APIs (sysctl vs IOKit vs NSProcessInfo) return consistently contradictory values for the same session.

2. Single-sample glitch: I've collected three separate telemetry dumps at different timestamps (attached below). All three show identical discrepancies.

3. Known iOS version mapping issue: I've checked the iOS version build number (2194) against every public and beta release table I can find. It doesn't correspond to any known release. The "Latest available" field also reports 26.4.1, which is equally non-existent.

4. Simulator or VM: The device returns live, physically-plausible sensor data (accelerometer, gyroscope, magnetometer, GPS with 3m accuracy). The storage controller reports NVMe. The GPU renders normally. This is physical hardware.

My Current Hypotheses (Seeking Validation/Tools to Test)

Hypothesis A: Jailbreak with Deep sysctl Spoofing

The device may be jailbroken with tweaks that hook sysctl and IOKit to modify hardware identification values. This would explain why hw.model says iPhone15,4 while lower-level IOKit reveals D37AP.

What I need help with: Are there open-source tools or techniques to detect sysctl hooking on iOS? I'm aware of checking for MobileSubstrate dylibs and Substitute frameworks, but I'm looking for kernel-level detection methods or consistency checks that can't be easily hooked.

Hypothesis B: Modified Kernel with 16KB Page Support

The 16 KB page size is particularly puzzling. A16 supports 16 KB pages at the hardware level, but iOS uses 4 KB pages. 16 KB is the macOS standard. This suggests either:

• A custom kernel build
• A kernel patch that changes the page size configuration
• An ARM64_16K_PAGES compile flag being set somewhere it shouldn't be

What I need help with: Has anyone encountered 16 KB pages on iOS in the wild? Are there known jailbreak tools that modify page size? How can I programmatically verify the actual page size in use beyond what sysctl hw.pagesize returns?

Hypothesis C: Hardware-Modified or Refurbished Device

Could this be a repaired device where components from different models were combined? The D37AP board paired with a USB-C port mod?

What I need help with: Does Apple's activation server or MDM provide any API to verify a device's "true" model against its serial number? I'm not looking to bypass any security, just to validate identity.

What I'm Looking For

1. Diagnostic tooling recommendations: Open-source tools that can cross-validate iOS device identity through multiple independent code paths (IOKit, sysctl, Mach, boot args, etc.)

2. Kernel introspection techniques: Programmatic ways to detect sysctl hooking, IOKit personification, or other kernel-level spoofing on iOS.

3. Community knowledge: Has anyone else encountered iOS devices reporting non-existent version strings like "26.x"? Are there known jailbreak tweaks that produce this specific pattern?

4. 16 KB page size expertise: Anyone with experience on the ARM64_16K_PAGES configuration on Apple Silicon — is there a way this could end up on iOS?

5. Hardware validation approaches: Methods to programmatically distinguish an iPhone 14 Pro from a 15 Pro using properties that can't be easily spoofed (e.g., GPU feature set, specific sensor models, Neural Engine core count).

Sample Data

I've collected three telemetry dumps from this device. I can provide the raw JSON/markdown output if helpful, but here are the consistent anomalous values:

# These values are stable across all three samples:

sysctl hw.model:              iPhone15,4
sysctl hw.machine:            iPhone15,4  
IOKit HardwareModel:          D37AP
sysctl hw.cputype:            0x100000C
sysctl hw.cpufamily:          Unknown
sysctl hw.pagesize:           16384
sysctl hw.memsize:            5963169792
sysctl hw.l1icachesize:       131072
sysctl hw.l1dcachesize:       65536
sysctl hw.l2cachesize:        4194304
sysctl hw.l3cachesize:        0
kern.osversion:               26.2
kern.osbuild:                 2194
kern.boottime:                { sec = 1768853800, usec = 899000 }

The D37AP identifier is documented as corresponding to iPhone 14 Pro (Global). The iPhone15,4 identifier corresponds to iPhone 15 Pro. These two identifiers should never appear on the same device.

Why This Matters (Beyond This One Device)

I'm building this diagnostic tool to help developers understand device capabilities in the field. If kernel-level spoofing can produce self-consistent but entirely false hardware profiles, it undermines device capability detection for performance tuning, feature gating, and crash diagnostics. Understanding the scope and mechanism of this spoofing will help me build more robust validation into my tool.

Environment

• Tool: Custom iOS system diagnostics collector (Swift + C sysctl/IOKit calls)
• Device under test: Reports as iPhone15,4 (hardware D37AP)
• iOS version reported: 26.2 (Build 2194)
• Observed behavior duration: ~2.5 years across multiple OS updates
• Collection method: Standalone iOS app with standard entitlements (no jailbreak entitlements used)

Thank you for any pointers, tool recommendations, or shared experiences. I'm happy to provide additional raw data or answer questions about my collection methodology. I'll mark the discussion as solved once I can definitively identify the root cause, and I'll share my findings for anyone who encounters similar issues.

Edit: If this would be better suited for a different GitHub Discussion category or a specific security research community, I'm open to redirection. I'm posting here because the core problem is a software diagnostics/telemetry accuracy issue.

Guidelines

• I have read and understood this category's guidelines before making this post.