mirror of
https://github.com/EFForg/rayhunter.git
synced 2026-04-26 07:29:59 -07:00
Doc spelling and punctuation corrections:
- standardize on American English spellings (behavior, analyze) - consistent bullet line end punctuation. - wifi -> WiFi, usb -> USB where needed. - some comma and article edits.
This commit is contained in:
Hal Mueller
committed by
Markus Unterwaditzer
Markus Unterwaditzer
parent
0eebe890c1
commit
e416d6e311
@@ -10,14 +10,14 @@ Through web UI you can set:
|
||||
- *Subtle mode (colored line)*: Rayhunter shows green line if there are no warnings, red line if there are warnings (warnings could be checked through web UI) and white line if Rayhunter is not recording.
|
||||
- *Demo mode (orca gif)*, which shows image of orcas *and* colored line.
|
||||
- *EFF logo*, which shows EFF logo and *and* colored line.
|
||||
- **Device Input Mode**, which defines behaviour of built-in power button of the device. *Device Input Mode* could be:
|
||||
- *Disable button control*: built-in power button of the device is not used by Rayhunter;
|
||||
- *Double-tap power button to start/stop recording*: double clicking on a built-in power button of the device stops and immediately restarts the recording. This could be useful if Rayhunter's heuristichs is triggered and you get the red line, and you want to "reset" the past warnings. Normally you can do that through web UI, but sometimes it is easier to double tap on power button.
|
||||
- **Device Input Mode**, which defines behavior of built-in power button of the device. *Device Input Mode* could be:
|
||||
- *Disable button control*: built-in power button of the device is not used by Rayhunter.
|
||||
- *Double-tap power button to start/stop recording*: double clicking on a built-in power button of the device stops and immediately restarts the recording. This could be useful if Rayhunter's heuristics is triggered and you get the red line, and you want to "reset" the past warnings. Normally you can do that through web UI, but sometimes it is easier to double tap on power button.
|
||||
- **Colorblind Mode** enables color blind mode (blue line is shown instead of green line, red line remains red). Please note that this does not cover all types of color blindness, but switching green to blue should be about enough to differentiate the color change for most types of color blindness.
|
||||
- **ntfy URL**, which allows setting a [ntfy](https://ntfy.sh/) URL to which notifications of new detections will be sent. The topic should be unique to your device, e.g., `https://ntfy.sh/rayhunter_notifications_ba9di7ie` or `https://myserver.example.com/rayhunter_notifications_ba9di7ie`. The ntfy Android and iOS apps can then be used to receive notifications. More information can be found in the [ntfy docs](https://docs.ntfy.sh/).
|
||||
- **Enabled Notification Types** allows enabling or disabling the following types of notifications:
|
||||
- *Warnings*, which will alert when a heuristic is triggered. Alerts will be sent at most once every five minutes.
|
||||
- *Low Battery*, which will alert when the device's battery is low. Notifications may not be supported for all devices—you can check if your device is supported by looking at whether the battery level indicator is functioning on the System Information section of the Rayhunter UI.
|
||||
- With **Analyzer Heuristic Settings** you can switch on or off built-in [Rayhunter heuristics](heuristics.md). Some heuristics are experimental or can trigger a lot of false positive warnings in some networks (our tests have shown that some heuristics have different behaviour in US or European networks). In that case you can decide whether you would like to have the heuristics that trigger a lot of false positives on or off. Please note that we are constantly improving and adding new heuristics, so new release may reduce false positives in existing heuristics as well.
|
||||
- With **Analyzer Heuristic Settings** you can switch on or off built-in [Rayhunter heuristics](heuristics.md). Some heuristics are experimental or can trigger a lot of false positive warnings in some networks (our tests have shown that some heuristics have different behavior in US or European networks). In that case you can decide whether you would like to have the heuristics that trigger a lot of false positives on or off. Please note that we are constantly improving and adding new heuristics, so a new release may reduce false positives in existing heuristics as well.
|
||||
|
||||
If you prefer editing `config.toml` file, you need to obtain a shell on your [Orbic](./orbic.md#obtaining-a-shell) or [TP-Link](./tplink-m7350.md#obtaining-a-shell) device and edit the file manually. You can view the [default configuration file on a GitHub](https://github.com/EFForg/rayhunter/blob/main/dist/config.toml.in).
|
||||
If you prefer editing `config.toml` file, you need to obtain a shell on your [Orbic](./orbic.md#obtaining-a-shell) or [TP-Link](./tplink-m7350.md#obtaining-a-shell) device and edit the file manually. You can view the [default configuration file on GitHub](https://github.com/EFForg/rayhunter/blob/main/dist/config.toml.in).
|
||||
|
||||
@@ -6,7 +6,7 @@ Rayhunter includes several analyzers to detect potential IMSI catcher activity.
|
||||
|
||||
### IMSI Requested (v3)
|
||||
|
||||
This analyser tests whether the eNodeB sends an IMSI or IMEI Identity Request NAS message under suspicious .
|
||||
This analyzer tests whether the eNodeB sends an IMSI or IMEI Identity Request NAS message under suspicious .
|
||||
|
||||
Mobile networks primarily request IMSI or IMEI from a mobile device during initial network attachment or when the network cannot identify the mobile device by its temporary identification (TMSI - *Temporary Mobile Subscriber Identity* or GUTI - *Globally Unique Temporary Identifier* in 4G/5G terminology).
|
||||
|
||||
@@ -23,7 +23,7 @@ What we consider suspicious is the following chain of events:
|
||||
* Authentication does *NOT* happen.
|
||||
* Tower requests phone to disconnect.
|
||||
|
||||
Looking for this chain of events is much less prone to false positives than naively looking for any time the IMSI/IMEI is sent. We do still sometimes get false positives when users are in an airplane that is coming in for a landing however. This is likely do to having been disconnected for a while and then being over towers that are not able to route to your home network, but we are still researching.
|
||||
Looking for this chain of events is much less prone to false positives than naively looking for any time the IMSI/IMEI is sent. We do still sometimes get false positives when users are in an airplane that is coming in for a landing however. This is likely due to having been disconnected for a while and then being over towers that are not able to route to your home network, but we are still researching.
|
||||
|
||||
This is the attack used by commercial IMSI catchers used by law enforcement.
|
||||
|
||||
@@ -36,40 +36,40 @@ This heuristic will also issue a notification every time your identity is sent t
|
||||
|
||||
### Connection Release/Redirected Carrier 2G Downgrade
|
||||
|
||||
This analyser tests if a base station releases your device's connection and redirects your device to a 2G base station. This heuristic is useful, because some IMSI catchers may operate in a such way that they downgrade connection to 2G where they can intercept the communication (by performing man-in-the-middle attack).
|
||||
This analyzer tests if a base station releases your device's connection and redirects your device to a 2G base station. This heuristic is useful, because some IMSI catchers may operate in a such way that they downgrade connection to 2G where they can intercept the communication (by performing man-in-the-middle attack).
|
||||
|
||||
|
||||
### LTE SIB6/7 Downgrade
|
||||
|
||||
This analyser tests if LTE base station is broadcasting a SIB type 6 and 7 messages which include 2G/3G frequencies with higher priorities.
|
||||
This analyzer tests if LTE base station is broadcasting a SIB type 6 and 7 messages which include 2G/3G frequencies with higher priorities.
|
||||
|
||||
SIB (*System Information Block*) Type 6 and 7 are specific types of broadcast messages sent by the base station (eNodeB in 4G networks) to mobile devices. They contain essential radio-related configuration parameters to help mobile device perform cell reselection.
|
||||
|
||||
This attack exploits the fact that SIB broadcast messages are not encrypted or authenticated. This allows them to pretend to be a legitimate cell by broadcasting fake system information in order to force mobile devices to downgrade from more secure 4G (LTE) to less secure 2G (GSM) network and then steal IMSI and/or perform man-in-the-middle attack. That is why this is also called a downgrade attack.
|
||||
|
||||
SIB6 is used for cell reselecion to CDMA2000 systems which are not supported by many modern mobile phones, and SIB7 Provides the mobile device with information to perform cell reselection to GSM/EDGE networks. Therefore SIB6 messages are quite rare, while malformed SIB7 messages are much more frequent in practice.
|
||||
SIB6 is used for cell reselection to CDMA2000 systems which are not supported by many modern mobile phones, and SIB7 Provides the mobile device with information to perform cell reselection to GSM/EDGE networks. Therefore SIB6 messages are quite rare, while malformed SIB7 messages are much more frequent in practice.
|
||||
|
||||
This heuristic is the most useful in the United States or other countries where there are no more operating 2G base stations. See [Wikipedia page on past 2G networks](https://en.wikipedia.org/wiki/2G#Past_2G_networks) for information about your country. In countries where 2G is still in service (such as most of EU), this heuristics may trigger false positives. In that case you should consider disabling it. However this heuristics has been vastly improved to reduce false positive warnings and new tests in European networks show that false positives are vastly reduced.
|
||||
This heuristic is the most useful in the United States or other countries where there are no more operating 2G base stations. See [Wikipedia page on past 2G networks](https://en.wikipedia.org/wiki/2G#Past_2G_networks) for information about your country. In countries where 2G is still in service (such as most of EU), this heuristic may trigger false positives. In that case you should consider disabling it. However this heuristic has been vastly improved to reduce false positive warnings and new tests in European networks show that false positives are vastly reduced.
|
||||
|
||||
### Null Cipher
|
||||
|
||||
This analyser tests whether the cell suggests using a null cipher (EEA0) in the RRC layer. That means that encryption between your mobile device and base station is turned off.
|
||||
This analyzer tests whether the cell suggests using a null cipher (EEA0) in the RRC layer. That means that encryption between your mobile device and base station is turned off.
|
||||
|
||||
Normally this should never happen, because null cipher is used almost exclusively for testing and debugging in labs or in controlled environments. Sometimes null cipher is used if encryption negotiation fails or isn’t supported (however in most networks this should not be the case). Also, some regulations allow unencrypted communications in **specific** emergency cases.
|
||||
|
||||
The general rule is, that null cipher should never be used in commercial deployments, except in very controlled conditions (e.g., test labs) or in a very specific regulatory-approved use cases.
|
||||
The general rule is that null cipher should never be used in commercial deployments, except in very controlled conditions (e.g., test labs) or in a very specific regulatory-approved use cases.
|
||||
|
||||
On the other hand, IMSI catchers often use null cipher to avoid setting up secure contexts (because they lack valid keys) and/or to trick mobile device into using unencrypted links (which makes eavesdropping easier).
|
||||
|
||||
### NAS Null Cipher
|
||||
|
||||
This analyser tests whether the security mode command at the NAS layer suggests using a null cipher (EEA0). This would usually only happen after a mobile device has successfully authenticated with the MME (*Mobility Management Entity* - core network component that handles signaling and control) but still it shouldn't happen at all. This could be indicative of an attack though using SS7 (*Signaling System 7* - a set of telecommunication protocols used to set up and manage calls and other services) to get key material from the HLR (*Home Location Register* - a database in mobile telecommunications networks that stores subscriber information) of the mobile phone for a successful authentication.
|
||||
This analyzer tests whether the security mode command at the NAS layer suggests using a null cipher (EEA0). This would usually only happen after a mobile device has successfully authenticated with the MME (*Mobility Management Entity* - core network component that handles signaling and control) but still it shouldn't happen at all. This could be indicative of an attack though using SS7 (*Signaling System 7* - a set of telecommunication protocols used to set up and manage calls and other services) to get key material from the HLR (*Home Location Register* - a database in mobile telecommunications networks that stores subscriber information) of the mobile phone for a successful authentication.
|
||||
|
||||
It could also indicate an IMSI catcher which is connected to the mobile network MME and HLR through cooperation between government and telecom provider. Or it could be a false positive if the telecom provider is intending to use null ciphers (if encryption is illegal in some country, or they have some misconfiguration of the network), however this should be very rare case.
|
||||
|
||||
### Incomplete SIB
|
||||
|
||||
This analyser tests whether the SIB1 message contains a complete SIB chain (SIB3, SIB5, etc.). A legitimate SIB1 message should contain timing information for at least 2 additional SIBs (SIB3, 4, and 5 being the most common) but a fake base station will often not bother to send additional SIBs beyond 1 and 2 (i. e. some IMSI catchers send just SIB1 and *one additional* SIB).
|
||||
This analyzer tests whether the SIB1 message contains a complete SIB chain (SIB3, SIB5, etc.). A legitimate SIB1 message should contain timing information for at least 2 additional SIBs (SIB3, 4, and 5 being the most common) but a fake base station will often not bother to send additional SIBs beyond 1 and 2 (i. e. some IMSI catchers send just SIB1 and *one additional* SIB).
|
||||
|
||||
On its own this might just be a misconfigured base station (though we have only seen it in the wild under suspicious circumstances) but combined with other heuristics such as **IMSI Requested** detection it should be considered as a strong indicator of malicious activity.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ using the `rayhunter-check` CLI tool. That tool contains the same heuristics as
|
||||
Rayhunter and will also work on traffic data captured with other tools, such as
|
||||
QCSuper.
|
||||
|
||||
Since, 0.6.1, `rayhunter-check` is included in the release zipfile.
|
||||
Since 0.6.1, `rayhunter-check` is included in the release zipfile.
|
||||
|
||||
You can build `rayhunter-check` from source with the following command:
|
||||
`cargo build --bin rayhunter-check`
|
||||
@@ -42,4 +42,4 @@ Options:
|
||||
|
||||
`rayhunter-check -p ~/Downloads #Check all files in downloads`
|
||||
|
||||
`rayhunter-check -d -p ~/Downloads/myfile.qmdl #run in debug mode`
|
||||
`rayhunter-check -d -p ~/Downloads/myfile.qmdl #run in debug mode`
|
||||
|
||||
@@ -37,7 +37,7 @@ According to FCC ID 2APXW-TMOHS1 Test Report No. I20Z61602-WMD02 ([part 1](https
|
||||
| 71 | 600 MHz (USDD) |
|
||||
|
||||
## Installing
|
||||
Connect to the TMOHS1's network over wifi or usb tethering.
|
||||
Connect to the TMOHS1's network over WiFi or USB tethering.
|
||||
|
||||
The device will not accept web requests until after the default password is changed.
|
||||
If you have not previously logged in, log in using the default password printed under the battery and change the admin password.
|
||||
|
||||
@@ -33,8 +33,8 @@ When filing bug reports, particularly with the installer, please always specify
|
||||
You can get your TP-Link M7350 from:
|
||||
|
||||
* First check for used offers on local sites, sometimes it's much cheaper there.
|
||||
* [Geizhals price comparison](https://geizhals.eu/?fs=tp-link+m7350)
|
||||
* [Ebay](https://www.ebay.com/sch/i.html?_nkw=tp-link+m7350&_sacat=0&_from=R40&_trksid=p4432023.m570.l1313)
|
||||
* [Geizhals price comparison](https://geizhals.eu/?fs=tp-link+m7350).
|
||||
* [Ebay](https://www.ebay.com/sch/i.html?_nkw=tp-link+m7350&_sacat=0&_from=R40&_trksid=p4432023.m570.l1313).
|
||||
|
||||
## Installation & Usage
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ You can access this UI in one of two ways:
|
||||
network and visit <http://192.168.1.1:8080> (orbic)
|
||||
or <http://192.168.0.1:8080> (tplink).
|
||||
|
||||
Click past your browser warning you about the connection not being secure, Rayhunter doesn't have HTTPS yet.
|
||||
Click past your browser warning you about the connection not being secure; Rayhunter doesn't have HTTPS yet.
|
||||
|
||||
On the **Orbic**, you can find the WiFi network password by going to the Orbic's menu > 2.4 GHz WIFI Info > Enter > find the 8-character password next to the lock 🔒 icon.
|
||||
On the **TP-Link**, you can find the WiFi network password by going to the TP-Link's menu > Advanced > Wireless > Basic Settings.
|
||||
|
||||
@@ -28,7 +28,7 @@ The most frequent bands found on these devices are LTE bands 1/3/5/8/20. In the
|
||||
|
||||
## Installing
|
||||
|
||||
With the device fully booted (i.e. beaming a wifi network, blue LED, etc.) and plugged into the computer that is performing the installation, run:
|
||||
With the device fully booted (i.e. beaming a WiFi network, blue LED, etc.) and plugged into the computer that is performing the installation, run:
|
||||
|
||||
```sh
|
||||
./installer uz801
|
||||
|
||||
@@ -29,7 +29,7 @@ Wingtechs are abundant on ebay and can also be found on Amazon:
|
||||
- <https://www.amazon.com/AT-Turbo-Hotspot-256-Black/dp/B09YWLXVWT>
|
||||
|
||||
## Installing
|
||||
Connect to the Wingtech's network over wifi or usb tethering, then run the installer:
|
||||
Connect to the Wingtech's network over WiFi or USB tethering, then run the installer:
|
||||
|
||||
```sh
|
||||
./installer wingtech --admin-password 12345678 # replace with your own password
|
||||
@@ -101,4 +101,4 @@ Caused by:
|
||||
3: Network is unreachable (os error 101)
|
||||
```
|
||||
|
||||
Make sure your computer is connected to the hotspot's wifi network.
|
||||
Make sure your computer is connected to the hotspot's WiFi network.
|
||||
|
||||
Reference in New Issue
Block a user