7 posts tagged with "saracen"

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 →

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 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 24, 2026 weekly sync — Field Testing section.
Internal reference. CIV-20: Saracen Arkansas – Radar: conduct full competitor validation

What we tested.

1. Installed Radar Verify on a Windows laptop and on a Mac, attempted to start a betting session via Chrome on both.
2. Attempted bet placement from within ~1 km of the Arkansas state line, on a Windows laptop tethered to a mobile hotspot.

What happened.

• Radar Verify does not work in Chrome — confirmed on both Windows and Mac.
• No successful bet could be placed within 1 km of the AR border. Radar bounced between "State not Allowed" and "Buffer Zone" errors as the tester moved.

Why it matters. Chrome is the most common desktop browser in the US. Combined with the near-border accuracy gap (no bet within 1 km), this is a double UX + compliance failure on Radar's flagship regulated-sportsbook reference (BetSaracen).

Radar profile → · March 24 weekly sync →