ChangeMe — GPS/FindMy spoofing

ChangeMe was an exploration into the lower-level architecture behind Apple’s Find My ecosystem, with a focus on understanding how location state, device identity, and the surrounding service infrastructure could be interacted with programmatically.

The project was less about building another conventional location application and more about investigating how a closed, consumer-facing platform actually behaves underneath its public interface. That meant approaching the system from a systems-engineering and reverse-engineering perspective: identifying communication boundaries, examining client behavior, understanding what data was exposed to the application layer, and determining which parts of the workflow were controlled locally versus enforced by Apple’s backend infrastructure.

A major part of the project involved trying to reason about the Find My stack from the outside rather than treating it as a black box.

Objective

The initial concept was to create a system capable of interacting with Find My–related functionality in a more programmatic and controllable manner than the normal consumer UI allows.

The project therefore required investigating several layers of the architecture:

• client application
• local device state
• Apple service interfaces
• authentication / authorization
• location and device state
• backend validation

The important engineering problem was identifying which parts of that chain could actually be controlled by software running locally and which were ultimately determined by Apple’s servers.

This pushed the project into areas such as protocol analysis, application behavior inspection, request/response analysis, state management, authentication flows, and client/server trust boundaries.

Version 1.0

Reverse engineering and API analysis

A significant portion of the work involved treating the Find My ecosystem as a reverse-engineering target.

Rather than assuming that a public-facing feature represented the complete system, I looked at the behavior surrounding requests, client state, identifiers, and the information exchanged between the application and remote services.

This meant thinking in terms of:

• API endpoints
• request construction
• response serialization
• authentication state
• device identifiers
• session state
• authorization boundaries
• client-side validation
• server-side validation
• replayability
• state synchronization

The objective was to understand the protocol surface and determine which assumptions the client was making about the backend.

This is an important distinction in systems analysis: something being accepted by a client does not necessarily mean it is trusted by the server.

Client-side trust boundaries

One of the areas I investigated was the separation between client-side behavior and backend authority.

Modern Apple services rely heavily on server-side state and authorization, meaning that modifying what a local client displays or submits is fundamentally different from modifying the authoritative state maintained by the service.

This led me to investigate the trust boundaries surrounding location information and device state.

The project involved exploring questions such as:

• What information does the client actually control?
• What information is derived locally?
• What information is merely presented by the client?
• What information has to be accepted by Apple’s backend?
• What validation occurs before a state transition is committed?

That distinction became one of the more valuable technical parts of the project because it shifted the work from simply “trying requests” into understanding distributed-system authority.

Supporting investigation views

Location state and device identity

Another major component was understanding the relationship between a device’s identity and its associated location state.

Location systems are not simply coordinate databases. They involve associations between:

• device identity
• account identity
• authorization
• location source
• timestamp
• backend state
• client presentation

Changing a coordinate is therefore only one small portion of the problem.

A legitimate location update has to exist inside a larger state machine in which the platform determines whether the device, account, session, and submitted state are consistent.

This required thinking about identity semantics, state transitions, synchronization, and server-side validation rather than simply manipulating latitude and longitude values.

Spoofing and state manipulation research

Part of the research involved investigating whether Find My’s location state could be influenced through client-side manipulation or spoofed state.

I explored the boundary between what could be represented locally and what the remote service would actually accept as authoritative.

This included examining whether manipulated values could survive the transition from local application state into the backend system and whether the service relied on additional signals beyond the obvious location payload.

The interesting engineering problem was not simply producing a fake coordinate; it was understanding the complete state-consistency model surrounding that coordinate.

In a distributed system, the client may be capable of generating arbitrary local state while the backend still rejects it because it cannot establish the required chain of trust.

That distinction became central to my understanding of the platform.

Security and authorization model

The work also required analyzing the security properties surrounding the service.

A consumer-facing API can expose a large amount of information without necessarily allowing arbitrary state modification. The existence of an endpoint or request format does not imply that the endpoint is an unrestricted mutation interface.

I therefore approached the system through concepts such as:

• authentication
• authorization
• session state
• request integrity
• device identity
• server-side validation
• state consistency
• trust boundaries
• replay resistance
• capability separation

These concepts became particularly important when examining whether client-side manipulation could actually result in an authoritative state transition.

Protocol-level investigation

Instead of treating the application as a monolithic piece of software, I approached it as a protocol stack.

At a high level, the investigation involved looking at the relationship between:

• application behavior
• serialized requests
• transport
• remote service
• serialized responses
• local state

This way of thinking required attention to data structures and state transitions rather than merely UI behavior.

The project consequently became an exercise in understanding how a proprietary ecosystem communicates internally and how much of that communication is actually under client control.

Version 2.0

Engineering approach

The project followed a fairly typical reverse-engineering loop:

• Observe
• Hypothesize
• Instrument
• Modify
• Test
• Compare
• Refine

Rather than assuming an observed behavior was caused by one particular mechanism, I used experimentation to isolate variables.

A change to the local client could produce three fundamentally different outcomes:

• The UI changes but backend state remains untouched.
• The request changes but is rejected or normalized remotely.
• The modified state is accepted and becomes authoritative.

Distinguishing between those outcomes is far more useful than simply observing that “something changed.”

This approach made the project closer to experimental systems engineering than ordinary application development.

Interaction with proprietary infrastructure

One of the technically interesting aspects was dealing with a platform where the important service logic is not available as a normal open API.

That forced me to reason about undocumented behavior, opaque service boundaries, and externally observable system behavior.

Instead of having source code, schemas, and documentation available, the system had to be treated experimentally.

That meant learning to infer architecture from behavior.

For example:

• A request produces a specific response.
• A state change appears locally but disappears after synchronization.
• A modified payload is accepted by the client but rejected remotely.
• A specific identifier changes downstream behavior.

Each of these observations becomes evidence about the architecture.

Systems-level lessons

ChangeMe taught me a lot about the difference between client control and system authority.

A program can have complete control over the state it generates locally while having essentially no control over the authoritative representation of that state on a remote platform.

That is a fundamental distributed-systems concept.

It also demonstrated why seemingly simple features can become extremely complex once authentication, device identity, synchronization, and backend validation are involved.

A location-sharing feature may appear to be nothing more than latitude + longitude, but a production implementation can actually depend on identity, authorization, device attestation/state, timestamps, server validation, and synchronization.

The project was therefore an exploration of the infrastructure surrounding the feature rather than merely the feature itself.

What I built and investigated

The work around ChangeMe involved experimentation with API behavior, protocol analysis, request/response inspection, client-side state, remote state synchronization, device identifiers, location state, authentication boundaries, authorization mechanisms, server-side validation, state-machine behavior, reverse engineering, instrumentation, debugging, security assumptions, and distributed-system architecture.

The project also required writing software to automate and reproduce portions of the investigation rather than relying entirely on manual interaction.

That made experimentation repeatable and allowed different hypotheses to be tested against the same conditions.

The public repository captures the native macOS side of that work: a utility for choosing map locations and driving developer location simulation against connected devices through Apple-supported Xcode tooling, including GPX generation for workflows that still require Xcode’s Simulate Location path.

The engineering perspective

What makes ChangeMe particularly valuable as a project is that it required me to think about software from the perspective of the entire system rather than just the application I was writing.

I had to consider the distinction between what the client can do and what the platform will actually trust.

That is a very different problem from building a standalone application.

It introduced me to concepts such as trust boundaries, authoritative state, protocol behavior, reverse engineering, authentication, authorization, distributed state, and backend enforcement.

It also reinforced something that has carried into my other projects: when documentation isn’t available, the system itself becomes the source of information.