proxypin-wloc-spoofer: Rewriting Apple WLOC Responses in an Authorized ProxyPin Test Setup

What proxypin-wloc-spoofer actually intercepts

Apple devices resolve position partly through a network location service, WLOC, reached at two hostnames this project names: gs-loc-cn.apple.com/clls/wloc and gs-loc.apple.com/clls/wloc. The script sits inside ProxyPin, the iOS and desktop capture tool by wanghongenpin, and rewrites the latitude and longitude fields inside the binary response body before it reaches the device.

The audience is narrow by design. The README states the project is for authorized testing, security research and QA reproduction. It is not an Apple CVE, not a remote exploit, and not an iOS permission bypass. Nothing happens unless a user installs and trusts the ProxyPin CA certificate on the test device and routes that device's traffic through ProxyPin. If you cannot arrange those two conditions on hardware you own or are cleared to test, this repository has nothing to offer you.

The README also draws a boundary that matters for expectations: the script modifies the network location response, not the GPS hardware reading. When GPS signal is strong, the README says iOS may prefer real GPS. That single sentence rules out the most common reason people search for a tool like this.

Why the script keeps the raw body instead of decoding it

The interesting design decision here is restraint. A naive response rewriter would parse the WLOC payload into an object, change a number, and re-serialize it. The README lists as a feature that the script preserves the original WLOC binary request body, specifically to avoid ProxyPin re-encoding the body and corrupting it. The same logic applies on the response side: latitude and longitude are replaced inside the original response packet structure rather than in a decoded copy.

That is the correct trade-off for a binary protocol you do not control. Any hand-written parser for an undocumented Apple payload is a liability the moment Apple changes a field offset, and re-serialization can alter bytes the server or client validates. Byte-level patching keeps the blast radius small, at the cost of being opaque: when a patch fails, the script cannot tell you which field moved, only that nothing matched.

The script also handles gzip-compressed WLOC responses, which the README lists as a supported case. Compression is where a lot of proxy scripts quietly break, because the body the script sees is not the body the client sent. The project cites pako, the JavaScript gzip library, in NOTICE as a third-party dependency, which is consistent with inflate and deflate happening inside the script.

Debugging is pushed into response headers rather than logs. The README documents four: X-WLOC-ProxyPin, X-WLOC-Origin-Status, X-WLOC-Patched-Locations and X-WLOC-Error. Putting state in headers means you read it in the same ProxyPin session view where you inspect the exchange, with no separate log file to correlate.

Installing the ProxyPin script and getting a first patched response

The repository is not an app, a proxy server or an iOS configuration profile. It is a JavaScript file for ProxyPin plus an importable script configuration. The README lists the files: proxypin_wloc_compat_v2.js holds the script, proxypin-scripts.json is the importable config that already contains the script and its match rules, and leaflet-test.html is a local browser page for the Leaflet map.

The prerequisites are a ProxyPin build that supports scripts, an iOS test device, the ProxyPin CA certificate installed and trusted on that device, and HTTPS capture enabled. The README recommends using the script locally rather than pointing ProxyPin at a remote URL.

The fast path is importing the bundled JSON. The README's steps are: open the script management page in ProxyPin, import proxypin-scripts.json, confirm the imported script is enabled, confirm HTTPS capture is on and the test device trusts the CA, then open a page on the proxied device.

# No install command. Import proxypin-scripts.json through the ProxyPin UI.
# The bundled match rules are:
#   www.baidu.com/*
#   gs-loc-cn.apple.com/clls/wloc
#   gs-loc.apple.com/clls/wloc

If you prefer not to import, the README's manual route is to open proxypin_wloc_compat_v2.js, copy the whole file, create a new local script in ProxyPin, and add the three URL matches above before pasting the script in.

With the script active, open https://www.baidu.com/ on the proxied device. That request is matched by the bundled rule and serves the Leaflet picker page. Pick a location on the map and press Save. The README states the coordinate is stored in ProxyPin's context.session, and later WLOC responses use it automatically. Then trigger iOS system location.

You confirm success by reading the WLOC response headers. The README gives this expected shape:

X-WLOC-ProxyPin: v5.4.2
X-WLOC-Origin-Status: 200
X-WLOC-Patched-Locations: greater than 0

If X-WLOC-Origin-Status reads 400, the README's interpretation is that Apple's server rejected the original request, so the script never had a valid response to edit. That is a server-side rejection, not a script bug, and it is the first thing to check before debugging anything else.

The default coordinate and what happens before you save one

If no coordinate has been saved into the session, the script falls back to constants embedded in the source. The README quotes them directly:

var TARGET_LONGITUDE = 113.94114;
var TARGET_LATITUDE = 22.544577;
var TARGET_ACCURACY = 25;

Those values sit in southern China, and accuracy is expressed in the same units the WLOC payload uses rather than metres, so do not read 25 as a 25-metre radius. The practical consequence is that a fresh install with no saved point will report a fixed location you did not choose. If your test asserts a specific coordinate, save one through the picker first, and treat the constants as a fallback rather than a configured default. The README does not document a way to edit those values other than editing the script source, and it does not describe any persistence of the saved coordinate beyond context.session, so assume the saved point does not survive a ProxyPin restart.

Where this approach fails, and when to pick something else

The clearest failure mode is already in the README: strong GPS beats the patched network response, because the script never touches the GPS hardware reading. A device outdoors with a clear sky view may ignore your coordinate entirely. If your test needs the location to hold under those conditions, this is the wrong tool and no configuration will fix it.

The second failure mode is upstream. When Apple returns 400 for the original WLOC request, there is no valid response to rewrite. The script reports this through X-WLOC-Origin-Status rather than repairing it. Causes the README does not enumerate, so treat a 400 as an environment problem to investigate in the capture view.

The third is scope. This is a ProxyPin script, so it inherits every ProxyPin requirement: CA trust on the device, HTTPS capture enabled, traffic routed through the proxy. Certificate pinning in a target app, or a device that refuses the CA, ends the exercise before the script runs.

For a different approach, consider the iOS Simulator's location simulation, which sets the location at the platform level rather than rewriting a network response, and therefore does not depend on GPS or on a proxy. The difference is fundamental: the simulator only runs apps built for it, so it cannot reproduce behaviour in a third-party App Store build on real hardware, which is exactly the case a proxy-based rewrite can reach. Conversely, if your target is a simulator-compatible build, the simulator gives you a deterministic location with no certificate work at all. Choose based on whether your test subject is a real device running a real app.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-07-14, which is recent enough that the project is not abandoned. The most recent release in the repository's release list is v5.4.2, dated 2026-06-29 and titled Leaflet Picker Import Workflow, and the script reports that same version string in the X-WLOC-ProxyPin header, so the header doubles as a quick way to confirm which script build is loaded.

The upgrade cost is low but not zero. Because the script patches a binary payload at fixed positions, an Apple-side change to the WLOC response layout is the main breakage risk, and the symptom would be X-WLOC-Patched-Locations at zero rather than an error. Upgrading means replacing the script or re-importing proxypin-scripts.json and re-confirming the three match rules; there is no migration step documented, and the README does not document rollback, so keep the previous script text if you need to revert.

Licensing is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. The NOTICE file records the pako third-party library, so if you redistribute the script, keep NOTICE with it. This is a description of the licence text, not legal advice; the disclaimer in the README places responsibility for lawful, authorized use on the operator.

Editorial conclusion

Adopt it if you are doing authorized QA on location-dependent iOS behaviour and already run ProxyPin with a trusted CA on the test device. Do not adopt it if you want a general location changer: it edits one network location response, and strong GPS can win over it. Before relying on it, confirm that the WLOC response headers show X-WLOC-Origin-Status: 200 and X-WLOC-Patched-Locations greater than 0, and verify the saved coordinate in the Leaflet picker rather than assuming the default 113.94114, 22.544577 is in use.

Frequently asked questions

Official sources

1. FFF686868/proxypin-wloc-spoofer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases