21 posts tagged with "radar"

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 happened. DraftKings has moved its web DFS product in New Jersey from GeoComply to Radar.

What stayed. The DraftKings Sportsbook and the DraftKings mobile apps remain on GeoComply. This is a partial-displacement, not a wholesale loss.

Open question being tested. Whether running two different geolocation providers side by side introduces compliance or security gaps — internal ticket CIV-65: DraftKings DFS - validate the competitor's integration.

Why it matters. This is Radar's first major US live-traffic win on a Tier-1 operator. The sales narrative is two-sided:

• Concerning: DK's procurement team has now signed off on Radar for a regulated US product. Other operators may treat this as permission.
• Constructive: The pattern "challenger gets the DFS web slice, GeoComply keeps everything else" is the new template for second-source attempts. Lead with "we keep the high-stakes stuff" in displacement conversations.

Counter-evidence. Radar's compliance gaps across other operators (rooted-hidden Android, resigned iOS, GPS simulator, jailbroken iOS at Sleeper/PrizePicks/Fliff, Chrome extension at Underdog) are independent of this migration and should be in every DK-adjacent conversation.

Radar profile →

Source. May 11, 2026 weekly sync.
Test evidence (internal Drive): PlayCover videos · FD WV: Spoofing Tests

What we tested​

Three distinct exploitation methods against the FanDuel WV (Radar) deployment, from Tennessee:

1. iOS app resigning — re-signed FanDuel iOS app with security controls bypassed.
2. Virtualised environment emulation via VMOS — Android device-farm environment running a cloned profile.
3. Sideloading via PlayCover on ARM-based macOS — iOS app loaded on Apple Silicon Mac via PlayCover.

What happened​

All three succeeded. Each technique facilitated out-of-state betting on the WV app. Critical and persistent failure to prevent unauthorized access or potential multi-accounting activities.

Cross-reference — same vectors, different results elsewhere​

• iOS app resigning was detected at Bet Saracen AR on April 7 — see Radar / Saracen AR: resigned iOS app detected. The gap is FD-WV-specific or build-specific.
• PlayCover was detected at Bet365 MI, Fanatics TN, and Bet Saracen AR on the same day — see cross-operator PlayCover blocked. FD WV is the outlier.
• VMOS is also undetected at Bet Saracen AR — see Bet Saracen AR: VMOS not detected. The Android device-farm gap is wider than just FD WV.

Radar profile → · May 11 weekly sync →

Source. May 11, 2026 weekly sync. Test video: BetSaracen VMOS Test.mov (internal Drive).

What we tested​

Three spoof vectors against Bet Saracen AR (Radar): VMOS Android device-farm, PlayCover sideloading on ARM-based macOS, resigned iOS app.

What happened​

• VMOS (Android) — NOT detected. Out-of-state bet placed from Tennessee.
• PlayCover (ARM macOS) — detected and restricted ✓
• Resigned iOS app — detected and blocked ✓

Why it matters​

The mixed result confirms Radar's posture is per-vector-uneven: catches the ARM-macOS hardware-abstraction vector and resigned iOS app integrity, but the Android VMOS device-farm slips through. This is also the second operator (after FanDuel WV) where the same VMOS gap shows up — a structural Android detector issue.

Radar profile → · FD WV three-method bypass → · May 11 weekly sync →

Source. May 5, 2026 weekly sync (monthly brief) — Radar Browser-Based Solution / Saracen AR section. Full recording: BetSaracenFullTestingSession.mov (21 min, internal Drive).

What we tested​

Distance-graded validation runs against Bet Saracen AR (Radar browser-based deployment) from inside the regulated jurisdiction, on Mac + Windows desktops.

What happened​

• 350m+ from the state line — success rates remained high. ✓
• 100m mark — Mac devices cleared only 44% of verifications.
• Windows users — hit a persistent lockout after a single failure, further complicated by an atypical fraud_jumped_single_device flag during betting attempts.

Why it matters​

100m is a city-block distance — well inside the state. A 44% pass rate at that range is direct booked-bet revenue loss for the operator. The Windows persistent-lockout behaviour is worse: a single retry triggers an account-level block with no clear self-service recovery path. Support ticket volume scales linearly.

The fraud_jumped_single_device flag is interesting — it suggests Radar's device-fingerprint logic is misidentifying repeat verification attempts as suspicious device-jumping behaviour. Pair with the Underdog DFS device-counting bug (every login = new device) — same architectural class of problem.

Radar profile → · Underdog device-counting bug → · May 5 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. May 5, 2026 weekly sync.

The finding​

The pre-loaded Windows Remote Desktop Connection app (labelled "Remote Screen Sharing" in the OS) triggers Radar account restrictions without notifying the user.

Why it matters​

This is a false-positive RDP flag: the app is present on virtually every Windows install, and is not running an active remote session. Triggering account restrictions silently from its mere presence is the worst case for support teams — the user has no idea what failed, no suggested resolution path, and no diagnostic message.

Cross-reference (same test cycle)​

On the same operator + same week, AnyDesk and TeamViewer were correctly restricted during active sessions (positive result). So the detector posture is: detects two real RDP tools, false-positives on one pre-installed Windows app it shouldn't flag. The RDP class is where Radar is most inconsistent.

Radar profile → · May 5 weekly sync →

What we tested. Underdog DFS, browser-based Radar geolocation deployment. Installed the free Location Guard Chrome extension and reported a spoofed location.

What happened. Undetected. Radar did not flag the browser-extension spoofing.

Adjacent gaps from the same test (April 28 weekly).

• Device-counting logic flaw — every login at Underdog is recorded as a new device, regardless of whether the device has been seen before. Inflates device counts and prevents multi-account detection — significantly weakening fraud detection.
• Border crossing — testing confirmed users can continue placing wagers for approximately 1 minute after entering a restricted zone before Radar intervenes. Regulatory compliance risk.
• Increased geolocation frequency + buffer-zone false positives — no single-license support; more frequent checks; unnecessary failures.
• Loss of meaningful error messaging — generic error messages for all geolocation failures post-GeoComply switch; ability to self-troubleshoot eliminated; support contact volume likely up.

Why it matters. A free Chrome extension that anyone can install defeating Radar's regulated-DFS deployment is the entry-level sophistication. The device-counting flaw makes multi-accounting effectively free. Bundle these into the Underdog talking points.

Radar profile →

What's new. Radar SDK iOS + Android v3.31.0 released April 24, 2026. The notable feature: when Radar's backend is unreachable, the SDK generates geofence entry/exit events directly on the device from cached data, tagged as offline.

It's a backend-toggled feature (Radar's backend enables it per integration), so we don't yet know whether it will be enabled for gaming markets. Tracking intensity also adjusts automatically based on geofence context — even mid-outage.

Why it matters. This is a meaningful step in Radar's strategic direction documented in the Apr 14 weekly: shifting from "where is the user?" to "can we continuously trust this location?" The 3-week-to-2-month release cadence is producing functionality that's interesting in retail / non- gaming contexts but unproven in regulated contexts.

Watch point. We need to validate whether offline-generated geofence events satisfy regulatory requirements (the regulator typically expects a server-side decision and full audit trail per transaction). If Radar enables offline events on a gaming integration, this is a finding worth escalating.

GitHub monitoring. As of Apr 14, we are subscribed to both XPoint and Radar GitHub repos to track new releases, SDK changes, and any publicly visible technical updates going forward.

Radar profile →

Source. April 14, 2026 weekly sync — Installation, Network, and Software Compatibility sections.

The findings​

• Mobile Hotspot Incompatibility — geolocation verification is unstable when connected via mobile hotspots on Mac + Windows; prevents legitimate wagering.
• Installation Workflow — access denial during web installation triggers persistent download prompts, regardless of whether the software is already on the system.
• Auto-Launch — Radar initiates automatically on system startup (Mac + Windows) without consent. Intrusive UX, support load.
• Desktop CPU — location checks trigger 4% CPU spikes every 10s at 600m from the border. Consistent resource drain — and the closer you get to the border, the more frequent the checks.
• Software Compatibility — inconsistent Radar performance across macOS Tahoe 26.0.1 vs 26.3.1 and Chrome 146 vs 147. Point releases break the integration.

Why it matters​

Three of these (auto-launch, install prompts, hotspot incompat) generate support tickets. The CPU pulses are not catastrophic but become noticeable on poker tables. The macOS / Chrome version sensitivity is the most concerning — Radar's desktop integration is fragile across the exact version range that most US users sit on.

For BetSaracen players this stacks on top of the existing generic "account security" error messaging (no diagnostic data, high self-troubleshoot friction).

Radar profile → · April 14 weekly sync →

Source. April 14, 2026 weekly sync — Border Performance Limitations.

What we tested. Approach to the OK state border from inside the regulated jurisdiction at varying distances, on iOS / Android / desktop (Mac+Windows over public Wi-Fi).

What happened.

• iOS — validation unsuccessful until 100m from the state line.
• Android — validation unsuccessful until 220m from the state line.
• Desktop (static, public Wi-Fi) — verification failed at 1,750m from the border on both Mac and Windows. Success threshold undetermined.

Why it matters. Legitimate users physically inside the licensed state — but close to the border — can't bet. The mobile case (100–220m windows) maps directly to lost revenue: 100m and 220m are city-block distances, not edge cases.

The 1,750m desktop failure is more severe — the user is nowhere near the border, and the system still can't verify. That's not a buffer zone, that's a broken validation flow.

Radar profile → · April 14 weekly sync →

Source. April 14, 2026 weekly research sync.
Coverage window. April 2025 → April 2026 (full Radar SDK changelog).

Cadence​

Radar ships every 3 weeks to a couple of months. We are now subscribed to both XPoint and Radar GitHub repositories to track new releases, SDK changes, and any publicly visible technical updates going forward.

Strategic direction​

Clear shift from "where is the user?" to "can we continuously trust this location?" — via four axes:

1. IP-triggered re-validation — location re-checked on network / IP change.
2. Multi-signal decisioning — motion, device context, network alongside GPS.
3. Indoor / vertical accuracy — floor-level detection on mobile plus BLE beacons.
4. Modular fraud architecture — plugin-based, allows rapid new detection logic.

Why it matters​

This is the architectural pitch Radar is making to non-gaming customers (retail, mobility) — and the same plumbing is what lets them say "we're adding compliance signals quickly." Worth watching whether the v3.31.0 offline geolocation events (April 24) are enabled on any gaming integration — that would be a notable regulator-attention moment.

Radar profile → · April 14 weekly sync → · v3.31.0 offline events →

What we confirmed. Bet365's geolocation stack is split — XPoint on the web, Radar on mobile.

Why it matters. Bet365 is XPoint's flagship US reference, often quoted in displacement conversations. Confirming that even Bet365 needed a co-provider on the most important surface (mobile = the bulk of session volume) reframes the displacement narrative. The pitch becomes "Bet365 needed two challengers to do the job GeoComply does with one."

Adjacent signal. Bet365 (XPoint web) social signal continued through April: wrong-state detection (MD placed in NJ), endless XPoint Verify install loop, app freeze + bet slip erasure, delete-and-reinstall every session, 1-star reviews. Bet365 (Radar) Android also accumulated 1-star reviews ("location verification is trash", "Stuck on trying to find the location, very bad app, likely a scam").

Spoof posture, same operator. Reddit user publicly asked how to spoof XPoint Verify from Florida. Two users offered help via Magisk. Worth a dedicated Magisk + XPoint Verify investigation.

Xpoint profile → · Radar profile →

Source. April 7, 2026 weekly sync — Field Testing section.

What we tested. Jailbroken iOS device with root hiding enabled. Attempted to wager from a prohibited location on three operators in sequence: Sleeper Sports, PrizePicks, Fliff.

What happened. All three allowed the wager through. Radar did not detect the jailbroken / root-hidden state on any of the three.

Why it matters. This is a structural Radar SDK gap that surfaces at every operator, not an operator-specific bug. The same compliance hole appears in three different deployments (DFS, sweepstakes, social gaming) within a single week of testing.

Radar profile → · April 7 weekly sync →

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. April 7, 2026 weekly sync.

What we tested. Repeat of the March 31 VMOS Android device-farm test on FanDuel WV.

What happened. VMOS usage was not detected this time. The tester placed bets from Tennessee on the West Virginia app.

Why it matters. Two consecutive weeks, opposite results on the same vector + operator combination. Either:

• Radar's device-farm detector has regressed between the two Android build releases the tests targeted, or
• The detector is flaky / instrumentation-sensitive — which is worse, because operators can't rely on what'll happen on any given session.

Cross-reference: VMOS also went undetected at Bet Saracen AR on May 11. The pattern is "VMOS Android catches some sessions, misses others" — not a stable detection posture.

Radar profile → · March 31 positive result → · April 7 weekly sync →

Source. March 31, 2026 weekly sync.

What we observed. Radar is allowing proxy betting and just asks the user to wait some additional time if someone else used the account in another location.

Why it matters. Two problems here:

1. Reactive, not preventive. A proxy-routed session gets through; the only consequence is a delay before the next session.
2. Misleading error messaging. Subsequent enforcement provides "account sharing" messaging instead of clear regulatory restrictions — which risks encouraging illegal workarounds like proxy usage (the user thinks they got flagged for sharing, not for masking location).

Combined with the FanDuel WV state-selector vulnerability (TN user initially verified on the WV platform — reactive rather than proactive validation), this is the same architectural problem expressed two ways: Radar's compliance posture is reactive.

Radar profile → · March 31 weekly sync →

What we tested. Re-signed iOS FanDuel app, modified to bypass security controls. Tester located in Tennessee, targeting the FanDuel WV platform.

What happened. The modified build successfully placed bets from out-of-state. Radar failed to detect the modification.

Cross-reference. Contradicts the Apr 7 result at Bet Saracen AR, where Radar DID detect a re-signed iOS app with appropriate error messaging. Re-signed iOS detection is inconsistent across operators — fix one, the other still fails.

Why it matters. App-resigning is a well-known attack class. A regulator audit that includes a tampered-app test will not accept an inconsistent result.

Radar profile →

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

What we tested. FanDuel West Virginia, Radar-instrumented mobile app, real device with a hardware GPS-simulator attached. Tester's actual location was Vietnam.

What happened. Radar accepted the spoofed coordinates and allowed geolocation verification to succeed. A hardware GPS simulator should be the most obvious off-the-shelf attack and is exactly what the regulator expects a compliance product to catch.

Why it matters. This is the entry-level attack class. If a hardware GPS simulator clears Radar in a regulated US sportsbook deployment, every sophistication-tier attack we've subsequently tested has an obvious predecessor.

Radar profile → · Test matrix →