4 posts tagged with "bet365-mi"

Source. June 23, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

Remote desktop detection retest on bet365 Michigan and BetRivers Michigan (both XPoint) — RustDesk and the commercial RDP stack (HopToDesk, AnyDesk, TeamViewer).

What happened​

• ✓ HopToDesk, AnyDesk, TeamViewer — detected and blocked before a bet could be placed on both Michigan integrations. This is a key difference from prior cycles — XPoint did improve commercial RDP detection.
• ⚠️ RustDesk — blocked, but with timing and install nuance.
  • The prior launch-order identification lag (June 2 finding) was not reproduced under rigorous retest.
  • Session was blocked at the first interval check — approximately 290 seconds (~4.5 minutes) later.
  • RustDesk is detected only while actively running — not when merely installed. A player can have RustDesk on their device without triggering an alert until a session starts.

Why it matters​

Commercial RDP detection on Michigan deployments is materially better than historical baselines — worth citing in competitive conversations. The RustDesk result is improved but not clean: a ~4.5-minute active- session window and silent tolerance of a installed-but-idle copy still leave residual exposure, especially vs GeoComply's real-time mid-session blocks on comparable vectors.

Pennsylvania BetRivers deployments still show undetected native iOS and Tailscale paths in the same test window (June 23 advanced spoofing review, CIV-88).

Cross-reference​

• bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64).
• Bet365 MI (Radar / XPoint) — full validation (May 26, CIV-63).

Xpoint profile → · June 23 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-64: MI advanced spoofing retest.

What we tested​

RustDesk remote access against bet365 MI (XPoint) on both Windows and macOS, varying the launch order of RustDesk relative to the XPoint geolocation client.

What happened​

• ✓ RustDesk launched before XPoint → flagged immediately.
• ✗ RustDesk opened after XPoint was already active → undetected on both Windows and macOS. Over 50 consecutive location checks passed with the remote tool running.
• Detection only resumed once the XPoint client was manually rebooted.

Why it matters​

The behaviour points to a one-time startup scan for prohibited software rather than real-time monitoring. The vulnerability stems from a predictable initialization sequence: an adversary who recognises the pattern can bypass desktop geolocation on bet365 MI simply by activating remote access after launch — a repeatable, low-effort gap that leaves a notable regulatory exposure open for the duration of a session.

Cross-reference​

• OpenBet / Fanatics MI — HopToDesk undetected on Android (CIV-64) — the mobile half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full integration validation (May 26) — prior multi-issue cycle on the same operator.
• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — second XPoint remote-access gap, different mechanism.

Xpoint profile → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

A full integration validation of Bet365 Michigan — Radar for the mobile app, XPoint for the web client. Covered: near-border behaviour, cross-state jurisdiction handling, two RDP attack paths (iOS, Windows), and post-failure UX.

What happened​

Area	Result	Notes
Near Canadian border (Belle Isle)	✗ Inconsistent at 200–1,000 m from the border. Betting slip continued to load but functioned unreliably — suggests an insufficient buffer zone.
Detroit ↔ Canada cross-border	✗ An erroneous jurisdiction alert fired on the betting slip, incorrectly telling the user wagering is restricted to New Jersey residents while on Bet365 MI.
iOS FaceTime RDP	✗ Undetected. A tester in Massachusetts placed bets remotely on a device located in Michigan with no issues.
Windows RDP	✗ Undetected. A tester in Massachusetts placed wagers on both the sportsbook and casino via a Windows device located in Michigan.
UX — post-VPN-detection recovery	✗ Persistent application glitches after a VPN-detection event. Tester unable to resume wagering; forced restart of the app required to restore functionality.

Why it matters​

This validation lands five separate issues on a single operator in a single test cycle:

1. Two compliance failures on the same border — buffer-zone unreliability + a flatly wrong jurisdiction message. Either could be cited as a regulator-facing defect.
2. Two undetected RDP paths — iOS (FaceTime) and Windows — both spanning multi-state remote sessions. RDP is the textbook remote-betting fraud vector and both paths went uncaught.
3. The UX recovery loop is broken even when detection does fire. A user who triggers a VPN block cannot recover without restarting the app, and receives no guidance on how to do so.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26) — third undetected RDP path on Bet365 in two weeks (NJ and MI, two geo providers).
• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes (May 19).
• Bet365 MI (Radar) — GPS simulator bypass, restriction not re-applied on re-entry (May 19) — distinct prior gap on the same operator.

Radar profile → · Xpoint profile → · May 26 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-48: Test Fake Location using GPS Simulator Accessory on Competitor Apps.

What we tested​

A hardware GPS simulator accessory was used to spoof the tester's physical location while connecting to Bet365 Michigan (Radar deployment) from Tennessee.

What happened​

• First login attempt — an error was returned (location restriction triggered).
• Second login attempt — succeeded with no further location checks enforced. The tester opened a casino game and placed real-money bets from Tennessee.
• The restriction that appeared on the first login was not re-applied on re-entry — the bypass is repeatable.

Why it matters​

This is a structural detection failure, not a one-off bug: the GPS simulator was identified once, then the operator's session state effectively whitelisted the device. Anyone who has triggered a restriction once can simply log out and back in to bypass it.

Combined with the Bet365 NJ Tailscale RDP gap confirmed in the same week, Bet365's Radar integration is producing two distinct, easily-reproducible spoof methods across two different states.

Cross-reference​

• GPS simulator at FanDuel WV (Radar) — previously bypassed from Vietnam (March 24, 2026). The GPS-simulator gap is not new and not WV-specific.
• PlayCover at Bet365 MI — blocked the same week. Bet365 catches the iOS-on-Mac vector but misses the hardware-GPS vector.
• GPS simulator at Fanatics TN (OpenBet) — detected with a clear, specific error message. OpenBet handles this vector; Radar does not.

Radar profile → · May 19 weekly sync →