3 posts tagged with "rooted-android"

Source. June 23, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — advanced spoofing review.

What we tested​

Advanced spoofing checks on BetRivers Pennsylvania (XPoint), building on the June 16 compliance analysis.

What happened​

1. Tailscale + Mac RDP — undetected

Two Macs on the same Tailscale account. Mac1 (out of state) connects to Mac2 (in PA) using macOS built-in screen sharing via Finder. Mac2 user does not need to be present — the remote user gets full control.

2. Rooted Android + mocked location — undetected (retested on mobile network)

Same non-compliant result on mobile connection. Setup uses Magisk with a renamed manager to avoid detection, root partially hidden. Key nuance: the mock location app (FakeGPS) is technically visible to BetRivers, but a custom low-level module suppresses the mock-location flag before BetRivers can read it — which is why it gets through. A second rooted device lost its integrity status and needs troubleshooting.

3. FaceTime RDP — undetected after local auth

The in-state person must physically handle the phone to log in and enter the 2FA code. Once logged in, the remote user takes full control — requires brief cooperation from the in-state user at the start, but no presence after that.

Why it matters​

All three vectors succeeded in a follow-up cycle. The Magisk module path defeats the SDK's mock-location signal at the OS layer — not merely by hiding the spoofing app. The Tailscale + macOS pattern delivers fully unattended desktop control, which is the highest-risk RDP class on Pennsylvania deployments this month.

Cross-reference​

• BetRivers PA (XPoint) — initial compliance analysis (June 16, CIV-88).
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73).

Xpoint profile → · June 23 weekly sync →

Source. June 16, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — compliance analysis.

What we tested​

A compliance analysis of BetRivers Pennsylvania (XPoint) covering native iOS remote-control methods, Tailscale + macOS native screen sharing, rooted Android with mock-location concealment, and a baseline suite of standard remote-access tools, IP-change detection, Android fake location apps (FLA), and a resigned iOS app.

What happened​

Vector	Result	Notes
Native iOS RDP (FaceTime + iPhone Mirroring)	✗ Undetected	Remote operator in an out-of-state location placed bets on the in-state Pennsylvania iOS device.
Tailscale + macOS native RDP	✗ Undetected	Mesh VPN tunneling combined with built-in macOS screen sharing was not flagged.
Rooted Android + concealed mock location	✗ Undetected	Root state and hidden mocked coordinates both went unnoticed; bets and gameplay succeeded from an exclusion state.
TeamViewer, AnyDesk, HopToDesk	✓ Blocked	Standard commercial remote-access utilities were identified and suppressed.
IP change detection	✓ Blocked	IP-based relocation checks fired as expected.
Android fake location apps (FLA)	✓ Blocked	Geolocation manipulation frameworks were detected before wagering.
Resigned iOS app	✓ Blocked	Tampered iOS binary was rejected.

Why it matters​

Three high-impact vectors — iOS screen sharing, Tailscale-based macOS RDP, and root-concealed mock location — all succeeded on the same operator while the "standard toolkit" checks passed. That pattern suggests detection tuned to known commercial RDP signatures and common FLA tools, but blind to native OS remote-control channels and Magisk-level telemetry suppression. The iOS and Tailscale gaps are especially material given prior undetected Tailscale findings on other XPoint deployments.

Cross-reference​

• BetRivers PA (XPoint) — advanced spoofing review: Tailscale macOS RDP, Magisk mock-location suppression, FaceTime handoff (June 23, CIV-88) — follow-up cycle on the same operator and ticket.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73) — same Tailscale class of attack, different state.
• Bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64) — another XPoint desktop RDP gap in the same test window.

Xpoint profile → · June 16 weekly sync →

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) →