2 posts tagged with "ciV-63"

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