9 posts tagged with "xpoint"

Source. May 11, 2026 weekly sync — "Unsuccessful Spoofing Methods" section.

What we tested​

PlayCover-based sideloading of iOS apps onto ARM-based macOS, attempted against three operators in three jurisdictions:

Operator	Geo provider	Result
Bet365 MI	Xpoint (web)	✓ Neutralized at authentication
Fanatics TN	OpenBet Locator	✓ Neutralized at authentication
Bet Saracen AR	Radar	✓ Identified at the betting stage

What happened​

No successful exploitations across the three tested jurisdictions. All three platforms have robust defense against this hardware- abstraction method.

Why it matters​

PlayCover is the most credible iOS-on-Mac sideload tool. Three different geo vendors blocking it on three different operators is a clean "compliant tier" signal — worth recording as parity context against the FD WV PlayCover bypass on the same day, which is the outlier.

FD WV PlayCover bypass (failure) → · May 11 weekly sync →

What we confirmed. Bet365's geolocation stack is split — XPoint on the web, Radar on mobile.

Why it matters. Bet365 is XPoint's flagship US reference, often quoted in displacement conversations. Confirming that even Bet365 needed a co-provider on the most important surface (mobile = the bulk of session volume) reframes the displacement narrative. The pitch becomes "Bet365 needed two challengers to do the job GeoComply does with one."

Adjacent signal. Bet365 (XPoint web) social signal continued through April: wrong-state detection (MD placed in NJ), endless XPoint Verify install loop, app freeze + bet slip erasure, delete-and-reinstall every session, 1-star reviews. Bet365 (Radar) Android also accumulated 1-star reviews ("location verification is trash", "Stuck on trying to find the location, very bad app, likely a scam").

Spoof posture, same operator. Reddit user publicly asked how to spoof XPoint Verify from Florida. Two users offered help via Magisk. Worth a dedicated Magisk + XPoint Verify investigation.

Xpoint profile → · Radar profile →

Source. Reddit thread on Bet365 / XPoint from a Florida user. April 7 weekly research sync.

The signal. A Florida-based user publicly asked how to spoof Bet365 XPoint Verify. According to two other users in the thread, there are ways — and one user said "I can help you spoof it through Magisk."

Why this matters. This is a regulated-market vulnerability being openly shared between players. Magisk is a hidden-root tool for Android, the same class we've already shown XPoint fails to detect in internal testing. The community is one step ahead of the operator.

Action. Magisk + XPoint Verify bypass is now in the test queue (May 5 monthly brief: "Magisk bypass on Bet365 / XPoint" added to the 15-ticket queue).

Xpoint profile →

Source. Google Play Store review of the RushStreet Android app (XPoint-powered). Surfaced in the April 7 weekly end-user-feedback section.

The quote.

"I've been playing poker and lately it's been freezing up, losing location, and I've got kicked off and lost money on tournaments."

Why this matters. RushStreet AZ was XPoint's flagship GeoComply displacement in January 2026, and RSI DE was added in April. This is a live customer of the live deployment describing the exact failure mode internal testing keeps surfacing — freezes, location loss, mid-session session termination. The lost-tournament-money detail is also a regulator-attention magnet.

Adjacent context. XPoint's Mac CPU spikes (0.5% → 16% at 1-min intervals during poker, RSI DE testing April 7) are consistent with the poker-specific symptom the player reports.

Xpoint profile →

What we confirmed. Splash Sports (DFS) is planning to offload XPoint in June 2026. Reported in the Apr 7 weekly research and reconfirmed Apr 14.

The reason. Splash Sports runs DFS game modes that have different state-by-state availability. XPoint requires the operator to build the multi-state handling themselves — there is no XPoint product equivalent of:

• GeoComply Multipass — one integration, many regulated jurisdictions.
• GeoComply Dynamic Boundaries — operator-configurable boundary logic per game / per state.

Why it matters. This is direct sales evidence that XPoint's developer-friendly auth model (clientKey per session, no expiry, JWT, auto re-geolocation, jurisdictionArea field in response) does not actually solve the multi-jurisdiction problem. Lead with this in any DFS RFP conversation.

Action. Confirm Splash Sports as a GeoComply opportunity for the June 2026 offload window. Use the Splash Sports narrative in any operator conversation where XPoint is being evaluated for a multi-state product.

Xpoint profile →

What we tested. RSI Delaware deployment (newly live, April 2026), iOS device localised to DE, driven remotely via FaceTime RDP from a Michigan host. Both casino and sportsbook flows.

What happened. No RDP detection. The MI-based user successfully placed remote wagers on the DE platform across both products.

Cross-reference. The same gap was previously confirmed at the RSI AZ deployment (Jan 2026 migration from GeoComply). Two operators, two regions, same SDK gap — this is structural.

Related RSI DE findings (same test cycle).

• Account SUSPENDED on DE-MD border crossing before any spoofing attempt was made.
• Near-border pass/fail points inconsistent, erroneous failures even moving away from the boundary.
• Static/mobile toggling required at MD + DE borders — major UX friction vs GeoComply's seamless PA.
• macOS install requests access to documents folder (known security concern).
• AnyDesk installed (but not running) silently blocks betting — false positive RDP flag.
• Mac CPU spikes 0.5% → 16% at 1-minute intervals during poker.

Xpoint profile →

What we obtained. Raw iOS and Mac Xpoint SDKs (Mar 24 weekly sync). The iOS SDK is unsigned, the SDK module is findable, and the response payload returns raw coordinates + compliance decision in plaintext.

What it means. An attacker can patch the app to inject coordinates, placing the user inside a permitted jurisdiction before every compliance check. The trust boundary is on the client. This is not a bug — it's an architectural exposure.

Cross-reference. May 5 monthly brief documents "XPoint returns compliance decisions and raw coordinates in plaintext to the client with a public GPS injection method." Magisk bypass on Bet365 XPoint Verify is publicly discussed on Reddit (Apr 7 + Apr 14) — two users offering help.

Why it matters. SDK hardening (signed binaries, obfuscation, license-bound runtime) is a category-defining requirement for regulated gaming geo. Xpoint sells on developer-friendliness, but for a regulator-facing compliance product the same property is the structural problem.

Xpoint profile → · Xpoint document (internal)

Source. Reddit + X/Twitter public posts. Monitoring initiated March 2026.

Bet365 / XPoint is generating strong negative signal. Users report:

• Wrong-state detection — Maryland users placed in New Jersey
• Endless XPoint Verify install loop on desktop
• Multiple posts explicitly contrasting the broken Bet365 experience with GeoComply-powered books that "work fine"

Users are naming the provider switch as the root cause. This is a clean attribution — the geo layer is being identified by the community itself, not just by us.

Contrast. GeoComply complaints in the same monitoring window are vague and operator-attributed. Negative posts on FanDuel / DraftKings / Hard Rock exist, but frustration is directed at the operator experience, not the geo layer. No posts characterise GeoComply as fundamentally broken.

Xpoint profile →

Source. Xpoint Competitive Intelligence Brief (March 2026), internal testing log. Cross-referenced in the March 24 weekly sync and the Xpoint profile.

What we tested​

Rooted Android device (hidden root via Magisk-class tooling), production BetRivers Android app on the Xpoint integration. We re-ran the same account flow that had been blocked by GeoComply prior to the Xpoint migration.

What happened​

Xpoint did not detect the rooted device. The session cleared geolocation and proceeded to bet placement on the BetRivers Sportsbook

• Casino apps. The account that had previously been blocked by GeoComply was no longer blocked once Xpoint took over the integration.

Why it matters​

Rooted Android with hidden root is a regulator-attention compliance vector. The migration narrative — "Xpoint is a modern alternative to GeoComply" — is contradicted by the basic-tier detection gap: an account that was correctly blocked by GeoComply for being rooted is now accepted by Xpoint.

This is the internally-tested evidence behind the Xpoint / Jailbreak-Root matrix cell. Public Magisk-bypass discussions on Reddit (social finding) are a signal of the same underlying gap, but the matrix is graded against this tested result, not Reddit chatter.

Xpoint profile → · March 24 weekly sync → · Xpoint Competitive Intelligence Brief (Drive) →