14 posts tagged with "positive"

Source. June 30, 2026 weekly sync.
Ticket. CIV-94: FanDuel NJ — Remote screen control blocked (GeoComply).

What we tested​

The same Mac-to-Mac remote screen-sharing attack that succeeded on BetRivers PA / XPoint during the same test cycle:

• Tailscale — two Macs on the same private network over the internet.
• macOS screen sharing — out-of-state Mac drives an in-state Mac via Finder, with full remote control and no local presence required on the host.

Operator: FanDuel New Jersey, a GeoComply desktop (PLC) deployment.

What happened​

• ✓ Detection fired immediately. The session was blocked under the "Blocked Software" rule before any wager could be placed.
• ✓ No bets were possible through the remote session.

Why it matters​

This is a clean, same-week, same-method contrast:

Operator	Geo provider	Tailscale Mac RDP	Result
BetRivers PA	XPoint	Mac-to-Mac via Finder	✗ Undetected — 1-hour FaceTime + sustained Mac RDP (June 30)
FanDuel NJ	GeoComply (PLC)	Mac-to-Mac via Tailscale	✓ Blocked immediately — Blocked Software rule

The attack uses entirely off-the-shelf, legal tools. Catching it in real time on FanDuel NJ while XPoint misses the identical pattern on BetRivers PA is a concrete compliance advantage for GeoComply in operator conversations this week.

Cross-reference​

• BetRivers PA (XPoint) — CIV-88 retest: FaceTime 1 hour + Tailscale Mac RDP undetected (June 30) — competitor gap on the same vector.
• GeoComply / Bally Bet NJ — Tailscale remote control blocked at login + mid-session (June 2, CIV-82) — prior GeoComply win on the same attack class.

Detection matrix → · June 30 weekly sync →

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 2, 2026 weekly sync.
Ticket. CIV-82: Bally Bet NJ — Remote screen control blocked (GeoComply).

What we tested​

The remote-screen-control fraud pattern: one person physically in the permitted state (New Jersey) hands full control of their screen to someone in an entirely different location, who places all the bets. The person in-state does nothing themselves.

Stack used:

• macOS Native Screen Sharing — Apple's built-in remote-desktop feature, driving Mac #1 from Mac #2.
• Tailscale — a networking tool that puts both Macs on the same private network over the internet, so Screen Sharing works as if they were side by side.

Operator: Bally Bet NJ, a GeoComply-integrated deployment.

What happened​

• ✓ Blocked at login. The attempt was stopped before any wager, with the error Blocked_software.
• ✓ Blocked mid-session. Detection also fired during an active session — not only at startup — so a session that began clean could not be handed off to a remote controller later.

Why it matters​

This is a clean, real-time win on the exact vector that three competitor integrations missed in the same test cycle. Regulators require operators to prevent geolocation fraud; catching remote screen control in real time — at login and mid-session — reduces operator liability and is a concrete, demonstrable compliance advantage for the GeoComply value proposition. The attack used entirely off-the-shelf, legal tools, which is exactly what makes the competitor gaps below material.

Cross-reference​

• Radar / Underdog DFS — same Tailscale remote-control method undetected for 20+ minutes (CIV-81).
• OpenBet / Fanatics — Mac-to-Android remote control undetected, bets placed (CIV-79).
• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26, CIV-73) — the finding that prompted this expanded testing campaign.

Detection matrix → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-52: Ontario — mkodo / GeoLocs — Compliance Failures & Retest.

What we tested​

Whether the OLG iOS app (GeoLocs / mkodo geolocation) would correctly refuse to operate when device location services were turned off — i.e. the most basic compliance pre-condition (no location signal → no wager).

What happened​

• ✓ Session was terminated immediately on detection of disabled location services.

Why it matters​

The baseline check works. A platform that allows wagering with no location data is unambiguously non-compliant; this vendor correctly refuses, on iOS, at session start.

That said — pair this with the OLG / GeoLocs VPN gap recorded the same week: the vendor does enforce when the device claims to be unable to locate, but falls down when the device claims to be located somewhere it isn't. The two findings together describe the shape of the gap: GeoLocs trusts the device's location signal too uncritically when that signal is present.

Cross-reference​

• OLG ON (GeoLocs / mkodo) — VPN-from-Ontario allowed + Netherlands VPN late detection (May 26) — same vendor, same operator, opposite outcome.
• High Flyer Casino TN (GeoLocs / mkodo) — iOS + Android spoofing bypass (May 26) — vendor failure pattern on a second operator the same week.

GeoLocs profile → · May 26 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-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-44.

What we tested​

A combination attack against Bet Saracen Arkansas (Radar):

• Oxylabs residential proxy — egress IP pointing to a residential address in Little Rock, AR.
• Location Guard browser extension — Chrome extension reporting a spoofed Little Rock, AR location to the Geolocation API.

Both layers were aligned to the same in-state Arkansas location, to test whether browser-level spoofing on top of network-level spoofing would defeat Radar's checks.

What happened​

Detected as out-of-state. The platform returned a STATE_NOT_ALLOWED error and refused the wager — despite both the IP and the browser's reported geolocation pointing to a permitted in-state address.

Why it matters​

This is a genuine Radar positive — worth recording for parity. The existence of a residential-proxy signal beyond just the egress IP, or of a corroborating signal (Wi-Fi BSSID, traceroute, accelerometer, something) that survives a Location-Guard override, is meaningful.

However, this finding does not rewrite the Radar weaknesses column:

• The Location Guard extension alone bypassed Underdog DFS on April 28 — so a Chrome extension on its own is still a known gap.
• Proxy betting is otherwise allowed at Radar — the system has historically asked the user to "wait additional time" if another login was seen from a different location (March 31).

The May 19 positive at Bet Saracen is therefore best read as "Radar can stack a state-line check on top of network spoofing in this particular operator integration" rather than "Radar handles proxies + browser extensions in general."

Cross-reference​

• Radar / Bet Saracen AR: resigned iOS bypassed this week — same operator, application-level vector slipped past.
• Radar / Underdog DFS: Chrome extension bypass (April 28) — same Location Guard tool, different result.

Radar 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. Bet Saracen Arkansas, Radar browser-based deployment. Driven sessions via AnyDesk and TeamViewer.

What happened. Radar effectively restricted both active sessions — wagering outside permitted borders was prevented during tool operation.

Why it matters. This is one of the few positive Radar results we have. Sales conversations should be honest: AnyDesk + TeamViewer are detected at Saracen AR. The narrative is "Radar catches the obvious ones but misses the adjacent ones."

Cross-reference (same test cycle, less positive).

• Pre-loaded Windows "Remote Screen Sharing" triggered account restriction silently — false-positive RDP flag, high support-ticket risk.
• Cross-Boundary Validation passed: attempts to wager from Oklahoma uniformly blocked across all test cases.
• 350m+ from border: high success rates. 100m: Mac 44% pass rate; Windows users hit persistent lockout after a single failure with atypical fraud_jumped_single_device flag.

Action. Add HopToDesk, iPhone screen mirroring, RustDesk, VNC, MS Teams remote-control to the Radar test scope per the May 11 Betting Hero plan — these are the adjacent tools that distinguish "catches the obvious" from "is a compliance product."

Radar profile →

Source. April 7, 2026 weekly sync.

What we tested. Re-signed iOS app on Bet Saracen Arkansas.

What happened. Radar successfully detected the resigned app and displayed appropriate error messaging — betting activity was prevented, and the account was not auto-blocked. Clean result.

Cross-reference. Contradicts the FD WV result from March 31, where the same attack class went undetected and bets were placed from TN. Two operators, two different outcomes for the same exploitation method — points to inconsistent / operator-specific detector behaviour in Radar's SDK. Follow-up validation scheduled pending the next iOS app release.

Radar profile → · March 31 FD WV failure → · April 7 weekly sync →

Source. March 31, 2026 weekly sync — Field Testing section.

What we tested. VMOS (virtual Android OS) device-farm scenario on the FanDuel WV Android app (Radar-instrumented). Spun up a virtualised device profile and attempted to wager.

What happened. Radar successfully identified the virtual OS environment used to manipulate device integrity. Detection fired.

Why it matters. This is a genuine positive Radar result — worth recording for parity. The sales narrative is honest: Radar catches some device-farm attacks but not all of them. Cross-reference the April 7 weekly: on the second attempt, VMOS was not detected, allowing bets from TN on the WV app — pointing to either a regression or a flaky/instrumentation-sensitive detector. Follow-up validation is scheduled pending the next Android app release.

Radar profile → · March 31 weekly sync → · April 7 weekly sync (regression) →