17 posts tagged with "openbet"

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

What we tested​

A VMOS virtual Android environment against the Fanatics Michigan app (OpenBet Locator).

What happened​

• ✓ Access blocked. A generic error appeared immediately after login with no path to place a bet.
• ⚠️ Error messaging uninformative — no guidance on why access was denied or how to recover.

Why it matters​

OpenBet successfully blocked a device-farm vector that has bypassed other integrations in prior cycles. Contrast with undetected GPS simulator and TeamViewer paths on the same operator in the same month (June 8, CIV-89).

Cross-reference​

• Fanatics MI (OpenBet) — HopToDesk undetected on Android (June 2, CIV-64) — same ticket, opposite outcome on a different vector.

OpenBet profile → · June 23 weekly sync →

Source. June 8, 2026 weekly sync.
Ticket. CIV-89: Fanatics / OpenBet Locator — spoofing testing updates.

What we tested​

Follow-up testing this week extended our remote-access findings on Fanatics to additional methods and states. On the Fanatics MI app (OpenBet Locator) we exercised three vectors: an iOS resigned app, a GPS simulator, and TeamViewer screen mirroring of the iOS device — with the controlling operator located in Tennessee.

What happened​

• ✓ iOS Resigned App — detected. Geolocation failed as expected. However, the error message returned blank, making it difficult to identify the specific detection trigger.
• ✗ GPS Simulator — not detected. The tester logged into the Michigan app, placed bets, and launched and played casino games — all from Tennessee.
• ✗ TeamViewer screen mirroring (iOS, MI) — not detected. Full remote control of the iOS device was achieved via TeamViewer; real-money bets were placed on the Michigan app from Tennessee.

Why it matters​

Two independent vectors — a GPS simulator and TeamViewer screen mirroring — each let an out-of-state user place real-money bets on Fanatics MI from Tennessee. The resigned-app check fired, but the blank error message is itself a UX/diagnostic gap: it confirms a block without surfacing the reason, which makes triage and rule attribution harder. A sophisticated fraudster only needs one of the two undetected paths to wager from outside the licensed state.

Cross-reference​

• Fanatics TN (OpenBet) — HopToDesk remote session connects but the Place Bet button is hidden (CIV-89) — the Tennessee half of the same retest campaign.
• Fanatics MI (OpenBet) — GPS spoofing hardware detected ✓ (May 26, CIV-48) — direct contrast: a hardware GPS-spoofing accessory was caught on Fanatics MI in the prior cycle, but this software GPS simulator was not.
• Fanatics TN (OpenBet) — TeamViewer screen sharing bypass (May 19) — the same TeamViewer screen-mirroring gap previously seen in Tennessee, now confirmed in Michigan.

OpenBet profile → · June 8 weekly sync →

Source. June 8, 2026 weekly sync.
Ticket. CIV-89: Fanatics / OpenBet Locator — spoofing testing updates.

What we tested​

The Tennessee half of the Fanatics remote-access retest: HopToDesk remote control on Android against the Fanatics TN app (OpenBet Locator), with the remote operator driving the in-state device.

What happened​

• ⚠️ Remote-control session established. HopToDesk connected and the remote operator had full control of the Android device — the session itself was not blocked.
• ✓ Place Bet button hidden from the remote operator. Bets could not be placed remotely without local (in-person) interaction on the device.

Why it matters​

A partial outcome. The remote-access tool was not detected or blocked outright, but the wagering action was withheld from the remote session, so the fraud could not be completed remotely. The protection is not consistent across states and tools, though: on Fanatics MI this week, TeamViewer screen mirroring allowed full remote betting from Tennessee. An attacker who can supply even brief local interaction — or who finds a tool/state combination without the hidden-button behaviour — may still get through.

Cross-reference​

• Fanatics MI (OpenBet) — GPS simulator + TeamViewer screen mirroring undetected, bets placed from Tennessee (CIV-89) — the Michigan half of the same retest, where remote betting did succeed.
• Fanatics MI (OpenBet) — HopToDesk undetected on Android; TeamViewer + AnyDesk blocked (June 2, CIV-64) — HopToDesk on Android in Michigan a cycle earlier, where it slipped through at install and during an active session.

OpenBet profile → · June 8 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-79: Fanatics — Mac-to-Android remote control (OpenBet).

What we tested​

A cross-platform variant of the remote-control fraud pattern: a tool allowing a Mac laptop to remotely control an Android phone from a different network was used to place bets on Fanatics (OpenBet). The phone sat inside the permitted state; the controlling Mac did not.

What happened​

• ✗ OpenBet did not detect the remote-control session during a sustained test.
• ✗ Bets were placed on Fanatics through the remotely-controlled Android device.

Why it matters​

This extends the week's remote-control gap beyond macOS↔macOS to a desktop→mobile path. The same "proxy device inside the state" risk applies: a user outside a licensed state bets through a device that is physically in-state. Confirming the gap on a third integration (after Radar/Underdog and XPoint/Bet365 NJ) makes it a campaign-level concern rather than a single-vendor quirk.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — the origin finding for this campaign.
• Radar / Underdog DFS — remote screen control via Tailscale undetected for 20+ minutes (CIV-81).
• GeoComply / Bally Bet NJ — the same class of remote-control attack blocked ✓ (CIV-82) — direct contrast.

OpenBet profile → · June 2 weekly sync →

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

What we tested​

During advanced spoofing retests near the Michigan–Canada border, the team tested several remote-control applications on Android against the Fanatics MI app (OpenBet), plus iOS screen sharing for comparison.

What happened​

• ✗ HopToDesk — NOT detected at installation or during an active remote session on Android. Bets were placed consistently while a remote user was in control.
• ✓ TeamViewer — detected and blocked.
• ✓ AnyDesk — detected and blocked.
• ✓ iOS FaceTime screen sharing — detected near the border.

Why it matters​

This is a known detection gap for a specific tool, not a blanket failure: the two most common remote-access apps (TeamViewer, AnyDesk) are caught, and FaceTime screen sharing is caught on iOS — but HopToDesk slips through entirely on Android. A sophisticated fraudster who identifies this specific gap can use it to circumvent geolocation checks on Fanatics in Michigan while the obvious tools stay blocked.

Cross-reference​

• XPoint / bet365 MI — RustDesk evades detection when launched after the geolocation client (CIV-64) — the desktop half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full validation: iOS FaceTime + Windows RDP undetected (May 26) — direct contrast: FaceTime screen sharing is caught here on Fanatics, but went undetected on Bet365 MI.

OpenBet profile → · June 2 weekly sync →

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

What we tested​

A hardware GPS-spoofing accessory was used against Fanatics Michigan (OpenBet Locator) — a market not previously exercised on this vector. The TN result from the prior cycle was the benchmark to compare against.

What happened​

• ✓ Real-time location-anomaly warning surfaced as soon as the spoofed position diverged from the device's plausible motion model.
• ✓ Session prevented from continuing — wagering blocked.

Why it matters​

Two-market confirmation of OpenBet's GPS-simulator handling. The prior Tennessee result is no longer a single-data-point; Fanatics MI now provides an independent replication of the same defensive behaviour against the same hardware vector. This raises confidence that the detection is integration-level rather than a quirk of one operator deployment.

Cross-reference​

• Fanatics TN (OpenBet) — GPS simulator detected with specific UX (May 19) — the original market test that this finding replicates.
• Bet365 MI (Radar) — GPS simulator bypass, restriction not re-applied on re-entry (May 19) — direct contrast: same vector, different vendor + operator, opposite outcome.

OpenBet profile → · May 26 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-59: Fanatics — OpenBet Locator | advanced spoofing.

What we tested​

Whether FaceTime screen sharing — Apple's built-in feature for mirroring one device's screen to another over the network — would be detected when initiated at the start of a wagering session on Fanatics West Virginia (OpenBet Locator).

What happened​

• ✓ Detection fired immediately at session start.
• ✓ Result: account or device was blocked, preventing the wagering session from continuing.

Why it matters​

iOS FaceTime is a credible remote-control vector: it ships on the device, requires no third-party tools, and gives the remote party a real-time view of the screen with light interaction. OpenBet catching it at session start is exactly the moment where this defence is cheapest and least disruptive — before any bets, before any state changes.

This is the same week as the Bet365 MI validation where iOS FaceTime RDP went undetected while a user in Massachusetts placed bets on a device in Michigan. Same vector, two operators, opposite outcomes — clear evidence that FaceTime detection is a vendor / integration choice and is implementable today.

Cross-reference​

• Bet365 MI (Radar / XPoint) — iOS FaceTime + Windows RDP undetected (May 26) — direct counter-example on the same vector this same week.
• Fanatics NJ (OpenBet) — droidVNC-NG RDP blocked and named (May 19) — adjacent positive case on the Android side of the same vendor.

OpenBet profile → · May 26 weekly sync →

Source. May 19, 2026 weekly sync.
Tickets. CIV-48 · CIV-61: iOS — spoofing testing with PlayCover tool.

What we tested​

Desktop-based emulation of iOS apps via PlayCover on ARM-based macOS, attempted against two operators in two jurisdictions:

Operator	Geo provider	Result
Bet365 MI	Radar (mobile) / XPoint (web)	✓ Blocked at login stage
Fanatics TN	OpenBet Locator	✓ Blocked at login stage

What happened​

No geolocation bypass possible. Both platforms neutralised the PlayCover environment before any compliance check ran — the apps refused to authenticate at all when running under PlayCover.

Why it matters​

PlayCover is the most credible iOS-on-Mac sideloading tool. Two different geo vendors blocking it on two different operators in the same test cycle is a clean "compliant tier" signal — and consistent with the cross-operator PlayCover block we recorded on May 11.

The standing outlier remains FanDuel WV (Radar), where PlayCover bypassed the platform on May 11. PlayCover is therefore a vendor-handled vector when the operator integration is fully wired up, and an operator-integration gap when it isn't.

Cross-reference​

• Cross-operator PlayCover blocked (May 11) — Bet365 MI + Fanatics TN + Bet Saracen AR.
• FanDuel WV PlayCover bypass (May 11) — outlier on the same vector.

Radar profile → · OpenBet profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-70: BetFanatics — RDP Testing on Android via DroidVNC.

What we tested​

Remote desktop access against the Fanatics New Jersey (OpenBet Locator) deployment, configured as:

• droidVNC-NG running on the controlled Android device.
• RealVNC Viewer on the controlling device.
• Tailscale mesh-VPN linking the two over the public internet.

This is the same kind of setup that bypassed Bet365 NJ (Radar) and RSI BetRivers NJ (XPoint) earlier this week — Tailscale + a VNC tool.

What happened​

• Immediately blocked. The session was refused at the compliance check.
• Error message named the app. The error explicitly identified droidVNC-NG as the remote-control application in use, rather than surfacing a generic "session blocked" string.

Why it matters​

This is the cleanest compliance-UX outcome we recorded this week. Two things matter:

1. The detection worked. A real RDP-style attack on Android was identified and refused at session start — no bets placed, no prolonged exposure window.
2. The error message did something useful. Naming the specific remote-control application means:
   • The player knows what to uninstall to get back into compliance.
   • The operator's support team gets a clear signal in the logs.
   • The compliance audit trail is self-documenting.

Contrast with Radar's generic "Account Locked" string on DraftKings DFS NJ this week, which says nothing about what triggered the block or how to recover.

Cross-reference — RDP this week​

OpenBet is the only provider with an unambiguous RDP positive this cycle:

Operator	Provider	Tool	Result
Fanatics NJ	OpenBet	droidVNC-NG	✓ Blocked + named (this finding)
Fanatics TN	OpenBet	FaceTime	✓ Blocked
Fanatics TN	OpenBet	TeamViewer	✗ Undetected
Bet365 NJ	Radar	Tailscale + RealVNC	✗ Undetected
RSI BetRivers NJ	XPoint	Tailscale	✗ Inconsistent
DraftKings DFS NJ	Radar	Zoom / AnyDesk / TeamViewer	✗ Inconsistent

OpenBet's coverage is not uniformly good — TeamViewer slipped past at Fanatics TN — but where it triggers, it triggers cleanly.

OpenBet profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-59: Fanatics — OpenBet Locator | adv spoofing.

What we tested​

Close-to-border testing of the Fanatics (OpenBet Locator) deployment on iOS. The tester opened a West Virginia casino game session inside WV, then physically crossed into Virginia while keeping the session active.

What happened​

• Session maintained. The active WV casino-game session was held open consistently while the tester stood 10 meters inside the Virginia border — a state where the operator is not licensed.
• iOS only. The issue was not reproduced on Android in the same conditions.

Why it matters​

A 10m post-border allowance is meaningful in real-world geographies where homes, hotels, parking lots, and businesses sit directly on the state line. A player who lives or works on the line can sustain an active gaming session while physically on the wrong side of it. This is the exact compliance scenario near-border buffer zones exist to prevent.

The iOS/Android asymmetry suggests the regression is in the iOS-side boundary handling specifically, not in the underlying geofence geometry.

Cross-reference​

• OpenBet near-border has been a documented gap since May 5 — see Fanatics TN border-jumping + zero buffer (May 5). The May 19 finding gives us a precise, reproducible measurement (10m, iOS) to anchor that.
• Compare with the DraftKings DFS NJ post-border lag of 100–150m on Radar this week — different problem (session-state lag vs no buffer), same UX outcome (active session past the line).

OpenBet profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-48.

What we tested​

The same hardware GPS simulator accessory used against Bet365 MI (Radar) and RSI BetRivers TN (XPoint) this week — applied to the Fanatics Tennessee (OpenBet Locator) deployment.

What happened​

Detected and named. The GPS simulator triggered a clear, specific error message:

"Your location has abruptly changed. Please disable apps that alter your device's location and retry."

This is notably more informative than the generic messaging seen at the other operators in the same test cycle — it tells the player exactly what kind of tampering was detected and what to do.

Why it matters​

Two things are worth recording here:

1. OpenBet handles GPS-simulator hardware. This is the third spoofing vector this week where OpenBet's detection held while Radar / XPoint's did not (alongside droidVNC-NG RDP blocked at Fanatics NJ and PlayCover blocked at Fanatics TN).
2. The UX is materially better. Compare with Radar's generic "Account Locked" messaging on DraftKings DFS NJ this week — same kind of compliance event, two very different player experiences. Specific, actionable error messaging reduces support load and shortens the recovery path for legitimate users.

Cross-reference (GPS simulator across providers this week)​

Operator	Provider	Result
Bet365 MI	Radar	✗ Bypassed via re-entry
RSI BetRivers TN	XPoint	✗ Fully undetected
Fanatics TN	OpenBet Locator	✓ Detected with specific error (this finding)

OpenBet was the only provider to handle this vector cleanly this cycle.

OpenBet profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-59: Fanatics — OpenBet Locator | adv spoofing.

What we tested​

Remote-control testing against the Fanatics Tennessee (OpenBet Locator) deployment, comparing two screen-mirroring tools:

1. TeamViewer — desktop remote control, tester in NY driving a device located in TN.
2. FaceTime — same setup, Apple's native screen-sharing.

What happened​

• TeamViewer: not detected. The NY tester placed bets on the TN platform via TeamViewer screen mirroring with no error, restriction, or session interruption.
• FaceTime: detected and blocked correctly. Same operator, same jurisdiction, same testing setup — but the FaceTime session was identified and blocked.

Why it matters​

OpenBet Locator's RDP coverage is inconsistent by tool, not by operator or by platform. Some screen-mirroring tools are caught (FaceTime, droidVNC-NG at Fanatics NJ this week), others are not (TeamViewer here, HopToDesk + iPhone mirroring from May 5).

This is the same structural pattern we documented in earlier weeks: the remedial-action classes claim screen-share detection, but the detection runs against a fixed list of known signatures rather than generalising. Any RDP tool not in that list sails through.

Cross-reference​

• HopToDesk + iPhone screen mirroring at Fanatics TN (May 5) — earlier finding, same operator, same kind of gap.
• droidVNC-NG blocked and named at Fanatics NJ (this week) — positive counter-example, same operator footprint.
• Bet365 NJ (Radar) Tailscale + RealVNC undetected for 25 minutes (this week) — comparable bypass on a different provider.

OpenBet profile → · May 19 weekly sync →

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 tested. Fanatics Sportsbook TN deployment (full OpenBet Locator Protect Suite, live since Dec 2025). Drove remote sessions via HopToDesk on Android and iPhone screen mirroring on iOS, from outside Tennessee.

What happened. Both tools bypassed Locator's RDP detection. Out-of-state wagering succeeded on both platforms.

Three more gaps from the same test cycle (May 5 weekly).

• No state border buffer zones — players within 50m of the boundary experience frequent state-switching, persistent page refreshes, and inability to finalise cash-out.
• No IP-change monitoring — IP address changes during active sessions are not flagged. A critical spoofing indicator is missed.
• VPN restriction false positives — aggressive VPN blocks fire on legitimate corporate-network users, increasing support overhead.

Why it matters. Four distinct compliance gaps in a single Fanatics TN test, all in the flagship US deployment. This is the single strongest sales asset against a bundled-OpenBet platform pitch. Pair with the prior border- jumping finding and the TQJ-churn data point.

OpenBet profile → · SDK comparison →

Source. April 28 weekly end-user-feedback section.

The signals.

• Fanatics users report selfie / ID scans failing repeatedly on sign-up.
• A separate account suspension immediately following a winning streak — with funds held and bank statements submitted but no resolution.

Consistent with the pattern of negative Fanatics / OpenBet sentiment tracked since February.

Why this matters. The "post-winning-streak suspension" is a specific fraud-investigation playbook problem that operators run into when their KYC + geo + risk stack is uncoordinated. Locator's lack of IP-change monitoring (May 5 test) and the absence of state-line buffer zones (50m state-switching at Fanatics TN) compound the post-win review pile.

Bigger pattern (May 5 monthly brief). KYC friction is now 23% of all end-user complaints in monitoring. Not a geo issue but creates halo damage: users conflate geo lockouts and KYC holds into a single "the app won't let me play" complaint.

OpenBet profile →

What happened. TQJ (Todos Querem Jogar / Bet do Milhão), backed by Grupo Silvio Santos, had been part of OpenBet's Brazil launch cohort. Reported in two consecutive weekly syncs (Apr 7 + Apr 14): TQJ switched OpenBet off, citing "worked poorly and caused UX issues."

Current state. TQJ is now running on IP-only as their primary geolocation. No proper geo-enforcement in a regulated market.

Why it matters. A paid OpenBet customer chose IP-only over OpenBet Locator. That's the strongest possible product-quality signal we get from the market — and it's a sales-ready data point for any Brazil operator conversation. The May 5 monthly brief confirms TQJ remains off the product.

Adjacent narrative. BandBet (the other Brazil launch client) and 200+ non-geo OpenBet platform clients are still on the platform — the threat is not OpenBet leaving Brazil, it's OpenBet bundling Locator into platform deals where the operator doesn't know what they're getting.

OpenBet profile →

Source. Reddit + X/Twitter public posts. Monitoring initiated March 2026. March 24 weekly research sync.

The signal. Fanatics / OpenBet sentiment is highly negative — and openly pro-GeoComply. Players report:

• Multi-week geolocation verification failures
• Customer-service dead ends
• One user discovered they couldn't even withdraw funds without passing geo

A community post put it plainly:

"Why they didn't go with GeoComply like everyone else is beyond me."

Why this matters for sales. This is a directly-quotable peer endorsement in an operator conversation. Pair with the OpenBet HopToDesk + iPhone-mirror RDP findings (May 5) for a complete narrative on Fanatics's geo posture.

OpenBet profile →