Embedded Files
Devilray: A Reconfigurable Adversarial Baseline for Revealing Blind Spots
The Problem
The Problem
Fake Base Station (FBS) detection has been studied for more than two decades, but a fundamental question remains:
"How do we know whether a detector can detect the diverse behaviors that a realistic FBS may exhibit?"
Limited visibility into real FBS operations. Commercial FBS devices are difficult for researchers to access because of financial and regulatory barriers.
Assumption-bound evaluation. Existing detectors are often designed and evaluated against a small number of self-built FBS prototypes with limited signaling and radio configurations.
Unknown coverage of the adversarial space. A detector may work well against the attacker used in its evaluation while missing other realistic behaviors permitted by cellular protocols and operational choices.
We refer to these uncovered regions of realistic adversarial behavior as adversarial blind spots.
Our Approach: Devilray
Our Approach: Devilray
Devilray provides a reconfigurable adversarial baseline for systematically exploring these blind spots.
Empirical anchor. We analyze a commercial FBS to understand how a real system operates and to identify gaps between research assumptions and observed behavior.
Unified operational model. We organize FBS behavior into a four-phase pipeline: network scanning → cell launching → connection hijacking → attack application.
Specification-driven expansion. We extend the observed behavior with operational variants derived from prior work and 3GPP specifications, covering seven feature dimensions.
Reconfigurable implementation. A dependency-aware implementation filters incompatible combinations and instantiates feasible configurations as reusable profiles.
Devilray is not intended to enumerate every possible FBS. Instead, it provides an extensible, empirically grounded adversarial baseline for evaluating what FBS detectors do—and do not—cover.
Read left to right, the figure shows Devilray scanning nearby networks, launching a cell, hijacking a UE, and running an application such as IMSI-catching. Spec-driven seven variant dimensions (V1–V7) vary each phase, and a dependency among configurations are handled by dependency checker with 21 rules to exclude incompatible combinations. This leaves 2,592 validated FBS configurations, each run to confirm its protocol sequence completes without deadlock.
For the detailed methodology, feature dimensions, dependency checker, implementation, and experimental setup, please see our ACSAC 2026 paper.
What We Found
What We Found
We experimentally validated all 2,592 Devilray configurations end-to-end with UEs to confirm their operational feasibility.
Using targeted configurations from this space, we evaluated seven accessible FBS detection systems and identified blind spots in all seven.
The blind spots arise from different assumptions about protocol behavior, operational strategies, and physical-layer characteristics; there is no claim that one configuration universally evades every detector.
Our experiments also show an important detection trade-off: broadening coverage can increase false positives.
The goal of Devilray is therefore not simply to produce many FBS configurations, but to provide a common adversarial baseline for asking a more fundamental question: how much of realistic FBS behavior does a detector actually cover?
For detailed detector results and primitive-level analysis, see the paper and the Primitive Analysis tab.
How Devilray Can Be Used
How Devilray Can Be Used
Devilray is intended as a shared adversarial baseline for researchers and practitioners who need to evaluate FBS detection beyond a small number of fixed attack prototypes.
Detector developers can test detection assumptions against diverse FBS behaviors, identify blind spots, and evaluate improved rules or learned models. For example, Devilray has been shared with the Electronic Frontier Foundation (EFF) to evaluate and improve Rayhunter at their request.
Mobile operators and security teams can reproduce realistic FBS scenarios in controlled testbeds and study network-side detection, correlation, and response mechanisms. We are conducting carrier-testbed experiments with Devilray in collaboration with SK Telecom (SKT).
Cellular security researchers can extend Devilray with new operational variants, dependency rules, or detection primitives and use a common baseline for comparative evaluation.
We encourage users to contribute newly identified behaviors, configurations, detector results, and experimental lessons so that Devilray can evolve as a community baseline for FBS detection research.
Devilray requires only one laptop and one or more USRPs (the demo uses B200s).
Demo Videos
Demo Videos
End-to-end demo #1) IMSI-catching
End-to-end demo #1) IMSI-catching
Devilray_Demo_1.mp4Devilray performs end-to-end IMSI catching while adapting its configuration to emulate a legitimate cell. The complete setup can be stored and reused as a YAML configuration profile. Sensitive network information is redacted.
End-to-end demo #2) Configuration profile reuse (IMSI-catching)
End-to-end demo #2) Configuration profile reuse (IMSI-catching)
Devilray_Demo_2.mp4Reusable configuration profiles allow Devilray to reproduce and modify adversarial instances across experiments.
End-to-end demo #3) 2G downgrade and SMS injection
End-to-end demo #3) 2G downgrade and SMS injection
Devilray_Demo_3.mp4Using a predefined configuration profile, Devilray demonstrates 2G redirection and SMS injection while emulating a legitimate cell. Sensitive network information is redacted.
Research Use and Artifact Access
Research Use and Artifact Access
Because Devilray is a dual-use research platform, the complete research artifacts are not available through unrestricted public download. Access may be provided to vetted researchers after confirming identity, affiliation, research purpose, and an appropriate experimental environment.
For research access, contact: devilray@kaist.ac.kr
Responsible Use Disclaimer
Responsible Use Disclaimer
Devilray is a dual-use research platform intended for legitimate security research, detector evaluation, and defensive testing. Active RF experiments should be conducted only in environments where transmission is legally authorized and appropriately isolated to prevent harmful interference or unintended interaction with third-party devices or networks.
Users are responsible for complying with applicable laws, regulations, institutional policies, privacy requirements, and experimental-safety procedures. Devilray should not be used for unauthorized surveillance, interception, disruption, or access to communications or devices.
Paper Information
Paper Information
Devilray: A Reconfigurable Adversarial Baseline for Revealing Blind Spots in Fake Base Station Detection, 2026 IEEE Annual Computer Security Applications Conference (ACSAC '26)
Authors:
Taekkyung Oh (KAIST) <ohtk@kaist.ac.kr>
Duckwoo Kim (KAIST) <0731kdw@kaist.ac.kr>
Hansung Bae (The Affiliated Institute of ETRI) <bhs1124@kaist.ac.kr>
Beomseok Oh (KAIST) <beomseoko@kaist.ac.kr>
CheolJun Park (Kyung Hee University) <cheoljunp@khu.ac.kr>
Tyler Tucker (University of Florida) <tylertucker1@ufl.edu>
Nathaniel Bennett (University of Florida) <bennett.n@ufl.edu>
Sangwook Bae (Cape) <sbae@cape.co>
Byeongdo Hong (The Affiliated Institute of ETRI) <byeongdo@nsr.re.kr>
Patrick Traynor (University of Florida) <traynor@ufl.edu>
Yongdae Kim (KAIST) <yongdaek@kaist.ac.kr>
Official ACSAC paper link: TBD
Pre-print version of paper: https://arxiv.org/pdf/2605.19232
Additional Technical Reference: Dependency Rules
Additional Technical Reference: Dependency Rules
The paper describes the dependency checker and representative rules, but intentionally refers readers to this website for the complete set of 21 dependency rules. The rules are grouped into:
Intra-phase dependencies: constraints among parameters within the same operational phase.
Inter-phase dependencies: constraints in which choices made in one phase restrict feasible choices in later phases.
The full table below serves as the technical reference accompanying Section 5.3 of the paper.
* For rule 20 (UE recovery), it is considered that the hijacked victim is in EMM-registered state and establishes NAS signalling connection with TAU Request or a Service Request
Page updated
Google Sites
Report abuse