Mirror/rayhunter
1
0
Fork 0
mirror of https://github.com/EFForg/rayhunter.git synced 2026-04-26 23:49:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Minimal version of the LTE downgrade analyzer

Browse Source 
This also renames the lte_parser crate to telcom_parser, since it'll
handle any 2G or 3G parsing going forward.
This commit is contained in:
Will Greenberg
2024-02-08 15:38:36 -08:00
parent d570ad3cb1
commit 5d7caba1a6
19 changed files with 150 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
lib/src/analysis/analyzer.rs
View File

@@ -1,4 +1,6 @@
use crate::lte_rrc::Message as LteRrcMessage;
use std::borrow::Cow;
use super::information_element::InformationElement;
/// Qualitative measure of how severe a Warning event type is.
/// The levels should break down like this:
@@ -11,14 +13,14 @@ pub enum Severity {
High,
}
/// `QualitativeWarning` events will always be shown to the user in some manner,
/// [QualitativeWarning] events will always be shown to the user in some manner,
/// while `Informational` ones may be hidden based on user settings.
pub enum EventType {
Informational,
QualitativeWarning(Severity),
}
/// Events are user-facing signals that can be emitted by an `Analyzer` upon a
/// Events are user-facing signals that can be emitted by an [Analyzer] upon a
/// message being received. They can be used to signifiy an IC detection
/// warning, or just to display some relevant information to the user.
pub struct Event {
@@ -26,24 +28,26 @@ pub struct Event {
pub message: String,
}
/// An `Analyzer` represents one type of heuristic for detecting an IMSI Catcher
/// An [Analyzer] represents one type of heuristic for detecting an IMSI Catcher
/// (IC). While maintaining some amount of state is useful, be mindful of how
/// much memory your `Analyzer` uses at runtime, since rayhunter may run for
/// many hours at a time with dozens of `Analyzer`s working in parallel.
trait Analyzer {
/// much memory your [Analyzer] uses at runtime, since rayhunter may run for
/// many hours at a time with dozens of [Analyzers](Analyzer) working in parallel.
pub trait Analyzer {
/// Returns a user-friendly, concise name for your heuristic.
fn get_name(&self) -> String;
fn get_name(&self) -> Cow<str>;
/// Returns a user-friendly description of what your heuristic looks for,
/// the types of `Event`s it may return, as well as possible false-positive
/// conditions that may trigger an `Event`. If different `Event`s have
/// the types of [Events](Event) it may return, as well as possible false-positive
/// conditions that may trigger an [Event]. If different [Events](Event) have
/// different false-positive conditions, consider including them in its
/// `message` field.
fn get_description(&self) -> String;
fn get_description(&self) -> Cow<str>;
/// Processes a single `LteRrcMessage`, possibly returning an `Event` if your
/// Analyze a single [InformationElement], possibly returning an [Event] if your
/// heuristic deems it relevant. Again, be mindful of any state your
/// `Analyzer` updates per message, since it may be run over hundreds or
/// thousands of them alongside many other `Analyzer`s.
fn process_lte_rrc_message(&mut self, message: &LteRrcMessage) -> Option<Event>;
/// [Analyzer] updates per message, since it may be run over hundreds or
/// thousands of them alongside many other [Analyzers](Analyzer).
fn analyze_information_element(&mut self, ie: &InformationElement) -> Option<Event> {
None
}
}