This commit is contained in:
2024-06-28 23:49:16 +02:00
commit 86f60da6ec
107 changed files with 25057 additions and 0 deletions

View File

@@ -0,0 +1,11 @@
### Completed:
- All Devices unpacked except [[xiaomi tv stick]].
- [[ledvance led strip]] wont enter pairing mode.
- [[echodot]] is setup and works.
- [[mi 360 home security camera]] needs microsd card.
## Plan for this week:
- Get microsd card
- MAINLY: Get AP working or find other way to capture traffic.
## Misc.:
Much time lost resetting router. [[ledvance led strip]] will only connect to 2.5GHz networks.
If laptop is connected to internet via ethernet, then I can make a AP, but iPhone wont connect to it. But IoT devices connect

View File

@@ -0,0 +1,4 @@
- Bought two USB Wifi Adapters (Completes [[TODO1]]):
- tp-link AC1300 Archer T3U (Mini Wireless MU-MIMO USB Adapter).
- tp-link AC1300 Archer T3U Plus (High Gain Wireless Dual Band USB Adapter)

View File

@@ -0,0 +1,12 @@
Plan: Setup wifi adapter to capture Amazon echodot.
Flow for setting up Access Point:
1. Setup Access Point
2. Configure Routing/Bridge or similar so IoT device can access internet.
Tried [linux-wifi-hotspot](https://github.com/lakinduakash/linux-wifi-hotspot) repo. Running it makes AP visible to iPhone, but issue is IP Address. Need to configure dhcp server or manually assign address.
Problem: Wifi Adapter In monitor mode sees nothing.
Neither Adapter has driver for modern macos
Archer T3U is using rtw_8822bu driver from kernel, this supports mac
Decide to go down hostapd route.

View File

@@ -0,0 +1,119 @@
Example [hostapd.conf](http://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf)
Simple article for basic setup [here](https://medium.com/p/3c18760e6f7e)
AP can be started an iPhone manages to connect. Now must 1:.ensure WPA2 or WPA3 and 2. enable ipmasquerading for internet connection. Then finally should be able to setup devices properly and start sniffing on traffic.
# 1st attempt AP setup
### Config files
File:`/etc/dnsmasq.d/dhcp-for-ap.conf`
Content:
```config
interface=wlp0s20f0u1
dhcp-range=10.0.0.3,10.0.0.20,12h
```
**BEWARE**: Must load above into `/etc/dnsmasq.conf` with a line that goes `conf-file=/etc/dnsmasq.d/dhcp-for-ap.conf` or `conf-dir=/etc/dnsmasq.d/,*.conf` see [here](https://wiki.archlinux.org/title/Dnsmasq#Configuration)
Other configs in `code/` directory.
## Used commands
See `code/` dir commit `devel@299912e` .
## Sanity Check
```bash
$ sudo hostapd ./hostapd.conf
# Output upon trying to connect with iPhone
wlp0s20f0u1: interface state UNINITIALIZED->ENABLED
wlp0s20f0u1: AP-ENABLED
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: associated (aid 1)
wlp0s20f0u1: AP-STA-CONNECTED f2:10:60:95:28:05
wlp0s20f0u1: STA f2:10:60:95:28:05 RADIUS: starting accounting session 9C7F40AA0385E2B2
wlp0s20f0u1: STA f2:10:60:95:28:05 WPA: pairwise key handshake completed (RSN)
wlp0s20f0u1: EAPOL-4WAY-HS-COMPLETED f2:10:60:95:28:05
```
Connection established but no internet as expected.
## Test
*Input*
```bash
sudo ./initSwAP wlp
```
*Output*
```
net.ipv4.ip_forward = 1
wlp0s20f0u1: interface state UNINITIALIZED->ENABLED
wlp0s20f0u1: AP-ENABLED
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: associated (aid 1)
wlp0s20f0u1: AP-STA-CONNECTED f2:10:60:95:28:05
wlp0s20f0u1: STA f2:10:60:95:28:05 RADIUS: starting accounting session C77A903F5D15F3B3
wlp0s20f0u1: STA f2:10:60:95:28:05 WPA: pairwise key handshake completed (RSN)
wlp0s20f0u1: EAPOL-4WAY-HS-COMPLETED f2:10:60:95:28:05
```
Unfortunatly still no internet connection.
## Analysis
Had forgot to import dhcp config file.
**Changes**: Add dnsmasq dhcp config and change wpa=3 to wpa=2 s.t. only WPA2 is used -> Now iPhone doesn't warn for security.
Unfortunatly still no internet connectino can be established.
## Todays 2nd attempt at Establishing an internet connection.
__Remarks/Observations:__
- iPhone connects to AP. Receieves IP Address `169.254.196.21` with subnet mask `255.255.0.0`. I
- P is a reserved non-routable for link-local ->Thus it seems that iPhone did not get an address from dhcp server.
- Could firewall be the problem? TODO -> iptables for dns and dhcp
- Maybe need to set static ip first etc as mentioned [here](https://woshub.com/create-wi-fi-access-point-hotspot-linux/)
```bash
# nano /etc/network/interfaces
auto wlp0s20f0u1
iface wlp0s20f0u1 inet static
address 10.10.0.1
netmask 255.255.255.0
```
- `/etc/network/interfaces` doesn't exist on my machine...
### Some configs to remember for later
dnsmasq:
```
#interface=wlp0s20f0u1
listen-address=10.0.0.2
dhcp-range=10.0.0.3,10.0.0.20,12h
dhcp-option=3,192.168.1.1
dhcp-option=6,192.168.1.1
domain-needed
bogus-priv
filterwin2k
server=1.1.1.1
no-hosts
```
Maybe need to enable ipv6 forwarding?
```
net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1
```
Flushing iptables: `iptables -F` flushes all tables. For more see [archwiki/iptables/Reset Rules](https://wiki.archlinux.org/title/Iptables#Resetting_rules)
- `sudo systemctl status iptables` says there is no such service unit!? -> Fedora uses [[firewalld]], which _is_ reported as running .........
#### Firewalld exploring
```bash
sudo firewall-cmd --get-active-zones
# Output:
# FedoraWorkstation (default)
# interfaces: wlp44s0
```
### Steps taken after restarting with [[firewalld]]
1. Followed steps in chapters 2.3.3 and 2.4 [here](https://wiki.archlinux.org/title/Internet_sharing#Enable_packet_forwarding). This should have enabled masquerading and have the ports ACCEPT for dns and dhcp.
2. Firewalld is not powerfull enough it seems
### nftables
* #TODO : What is the source of this info?!
Overview of a common configuration and packet flow
A host acting as a simple firewall and gateway may define only a small number of nft chains, each matching a kernel hook:
a prerouting chain, for all newly-arrived IP traffic
an input chain, for traffic addressed to the local host itself
an output chain, for traffic originating from the local host itself
a forward chain, for packets the host is asked to simply pass from one network to another
a postrouting chain for all IP traffic leaving the firewall
For configuration convenience and by convention, we group the input, output, and forward chains into a filter table. Most rules in setups like this attach to the forward chain.
If NAT is required, we follow the convention of creating a nat table to hold the prerouting and postrouting chains. Source-NAT rules (where we rewrite the packet source) attach to the postrouting chain, and destination-NAT rules (where we rewrite the packets destination) attach to the prerouting chain.
Packet flow is straightforward. Only one chain attaches to each hook. The first accept or drop rule a packet matches wins.

View File

View File

@@ -0,0 +1,10 @@
First success using mac mini.
Could record some data of amazon echo.
Setup gues network on router without any security, this enabled some capture since no keys had to be configured or handshakes captured (would be an issue without any channel controll)
Issue: Channalhopping -> missing a lot of traffic
To avoid channelhopping: Somehow fix the channel on router.
By leaving out any authentication/security config in hostapd.conf one can create an unsecured AP (on the usb wifi card) on my linux machine to. Having an open auth AP seems fine for this use case.
In the end this seems to be the way. For doing experiments we want to record all traffic. For this we cannot loose traffic just because we are not connected. This is why we'd want an access point we controll fully. We don't want to rely an some other router. But even then there would still be much manual config (channel, making an open access vlan or whatever).
Essentially we need to know the channel exaclty and don't want to deal with any more cryptography than we must. So, ideally we can create an AP on a laptop or local computer, using a low cost wifi adapter. (Since we are talking about testing IoT devices we must rely on wireless internet, since this is how virtually all of them work.) We should be able to configure that device to be an AP. Then we need to forward to whatever interface the experiment computer has internet access to.

View File

View File

@@ -0,0 +1,7 @@
New promising setup:
- Raspberry Pi 5
- Wired connection to router for internet
- Can very easily create wifi network and also connect to it (tested form iPhone 13)
- Can capture on the wifi card while still providing internet access to iPhone
- Sanity Test: Opening Youtube app on iPhone produces a large flow of QUIC packets, likely from the video that starts autoplaying.

View File

@@ -0,0 +1,177 @@
# Commands to remember + sample output
Used commands: [[nmcli]], [[iw]], [[grep]], [[sed]]
Resources: [Capturing Wireless LAN Packets in Monitor Mode with iw](https://sandilands.info/sgordon/capturing-wifi-in-monitor-mode-with-iw)
Foreign BSSIDs have been made anonymous by replacing with `XX:XX:XX:XX:XX:XX`.
## [[nmcli]]
Useful for getting channel needed to setup monitor mode properly.
### `nmcli dev wifi`
```
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 6 195 Mbit/s 75 ▂▄▆_ WPA2
* 4C:1B:86:D1:06:7B LenbrO Infra 100 540 Mbit/s 67 ▂▄▆_ WPA2
4C:1B:86:D1:06:7C LenbrO Infra 6 260 Mbit/s 64 ▂▄▆_ WPA2
B8:BE:F4:4D:48:17 LenbrO Infra 1 130 Mbit/s 62 ▂▄▆_ WPA
XX:XX:XX:XX:XX:XX -- Infra 6 260 Mbit/s 60 ▂▄▆_ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 60 405 Mbit/s 37 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box Fon WLAN 7360 BP Infra 1 130 Mbit/s 34 ▂▄__ WPA1 WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 6 195 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX Sunrise_Wi-Fi_09FB29 Infra 7 540 Mbit/s 34 ▂▄__ WPA2 WPA3
XX:XX:XX:XX:XX:XX Madchenband Infra 11 260 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX LenbrO Infra 36 270 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX FibreBox_X6-01EF47 Infra 1 260 Mbit/s 32 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX -- Infra 11 260 Mbit/s 32 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX EEG-04666 Infra 1 405 Mbit/s 30 ▂___ WPA2
XX:XX:XX:XX:XX:XX Salt_2GHz_8A9170 Infra 11 260 Mbit/s 29 ▂___ WPA2
XX:XX:XX:XX:XX:XX -- Infra 11 260 Mbit/s 24 ▂___ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 60 405 Mbit/s 19 ▂___ WPA2
```
### `nmcli -t dev wifi`
```
XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:6:195 Mbit/s:79:▂▄▆_:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:6:260 Mbit/s:75:▂▄▆_:WPA2
:4C\:1B\:86\:D1\:06\:7C:LenbrO:Infra:6:260 Mbit/s:74:▂▄▆_:WPA2
*:4C\:1B\:86\:D1\:06\:7B:LenbrO:Infra:100:540 Mbit/s:72:▂▄▆_:WPA2
:B8\:BE\:F4\:4D\:48\:17:LenbrO:Infra:1:130 Mbit/s:65:▂▄▆_:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Sunrise_Wi-Fi_09FB29:Infra:7:540 Mbit/s:52:▂▄__:WPA2 WPA3
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:60:405 Mbit/s:50:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box Fon WLAN 7360 BP:Infra:1:130 Mbit/s:47:▂▄__:WPA1 WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:6:195 Mbit/s:45:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Zentrum der Macht:Infra:1:195 Mbit/s:44:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FibreBox_X6-01EF47:Infra:1:260 Mbit/s:42:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Madchenband:Infra:11:260 Mbit/s:40:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:LenbrO:Infra:36:270 Mbit/s:37:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:11:260 Mbit/s:34:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:EEG-04666:Infra:1:405 Mbit/s:30:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Salt_2GHz_8A9170:Infra:11:260 Mbit/s:29:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:60:405 Mbit/s:27:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Madchenband2.0:Infra:100:540 Mbit/s:25:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:11:260 Mbit/s:24:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FibreBox_X6-01EF47:Infra:44:540 Mbit/s:20:▂___:WPA2
```
## [[iw]]
### `iw dev`
Useful to list interfaces and see which hardware they correspond to.
Can use that to create a monitor interface with an easier to remember name.
```
phy#1
Unnamed/non-netdev interface
wdev 0x100000002
addr 3c:21:9c:f2:e4:00
type P2P-device
Interface wlp44s0
ifindex 5
wdev 0x100000001
addr e6:bf:0c:3c:47:ba
ssid LenbrO
type managed
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
phy#0
Interface mon0
ifindex 7
wdev 0x2
addr a8:42:a1:8b:f4:e3
type monitor
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
Interface wlp0s20f0u6
ifindex 4
wdev 0x1
addr a8:42:a1:8b:f4:e3
type monitor
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
```
Here, `phy#1` is my laptops built-in WiFi card, and `phy#0` is a WiFi USB adapter.
### `iw [phy phy<index> | phy#<index>] info | grep -f monitor -B 10`
```
➜ iw phy phy0 info | fgrep monitor -B 10
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
--
* register_beacons
* start_p2p_device
* set_mcast_rate
* connect
* disconnect
* set_qos_map
* set_multicast_to_unicast
* set_sar_specs
software interface modes (can always be added):
* AP/VLAN
* monitor
```
Can do better
### `iw phy#0 info | grep monitor`
```
* monitor
* monitor
```
Concise but possible need more context to be sure?
### `iw phy phy0 info | sed -n '/software interface modes/,/monitor/p'`
More concise but with good context. Assuming only sw interfaces need to support monitor mode
```
software interface modes (can always be added):
* AP/VLAN
* monitor
```
### Getting a monitor interface
```
iw phy#0 interface add mon0 type monitor
```
Add a easy interface to wifi hw and make it a monitor. Can check again with 'iw dev' to make sure it is really in monitor mode. If there is an other interface it must be taken down or deleted e.g with
```
iw dev <phy#0 other interface> del # or
ip link set <phy#0 other interface> down
```
Then to enable `mon0` interface,
```
ip link set mon0 up
```
To effectively capture packets, we should set the interface to the correct frequency. For this we get the channel e.g. via the above mentioned `nmcli dev wifi`. We can see that, e.g. the BSSID I am connected to (marked with `*`) is on channel 100. We can also see that it there is also a BSSID belonging to the same SSID with the interface on channel 6. I.e., it is running one interface in 2.4 GHz (802.11b/g/n/ax/be) and one in 5 GHz (802.11a/h/n/ac/ax/be). We chose which which channel to tune our `mon0` interface to, then we can lookup what the center frequency is on [wikipedia(List of Wifi Channels)](https://en.wikipedia.org/wiki/List_of_WLAN_channels). E.g. for channel 6 (i.e. 2.4 GHz radio) we see that the center frequency is 2437. We set our interface to that frequency:
```
iw dev mon0 set freq 2437
```
Now double check that the interface is in monitor mode and tunedto the correct frequency:
```
iw dev mon0 info
```
Should give an output like
```
Interface mon0
ifindex 7
wdev 0x2
addr a8:42:a1:8b:f4:e3
type monitor
wiphy 0
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
```
This concludes preparing the wifi card for packet capture in monitor mode.
### [remarks]
- `sudo` is probably required for these commands
- These network tools are what is available on fedora 40, on $(uname -r)= 6.8.8 Linux Kernel. It might be that other OSs still use older tools, which are being phased out. But other operating systems might still be using older versions of these commands. For a table on how they match up, see [this](https://www.tecmint.com/deprecated-linux-networking-commands-and-their-replacements/) recent article (July 2023), according to which the old commands are even deprecated in recent Debian and Ubuntu releases.
- If smth is not working run `rfkill list` to check device is blocked. If it is, `rfkill unblock 0`, where `0` is the same index used above and represents `phy0` /`phy#0`.
- To ensure that [[NetworkManager]] not managing you card, `nmcli device set wlp0s20f0u6 managed no` if the interface is called `wlp0s20f0u6`. Check with `nmcli dev`, the STATE should be "unmanaged".
- See resources on how to put interface/wifi hardware back into managed mode, if you need the card for personal use.
# Important
Monitor mode is actually completely useless, unless we can observe the EAPOL handshake. That means the Wifi AP should be using WPA/WPA2 with psk. Also we need to know the SSID and passphrase. So it is still better if we can setup an environment where we can just do port mirroring from the wifi router, or setup ourselves in AP mode, but then we need to be able to bridge to the internet somehow, which I haven't managed reliably. Have done some testing on raspberry pi seemed to work. But raspberry pi sometimes goes to sleep so the AP goes down which means the IoT device loses connection.
If we happen to know the MAC address we need, then in wireshark we can filter `wlan.addr == [MAC]`. In tcpdump we can use the filter

View File

@@ -0,0 +1,14 @@
# `IOTTB_HOME`
I introduced the environment variable `IOTTB_HOME` into the code. It is used to configure where the root of a iottb database is. #TODO this means that some code needs refactoring. But, I think it will streamline the code. The path in `IOTTB_HOME` shall be used to define the database root. Then, all the code handling adding devices and running captures can rely on the fact that a canonical home exists. Unfortunately I've hard coded quite a bit of ad-hoc configuration to use `Path.cwd()`, i.e. the current working directory, by default. So there will be some refactoring involved in switching over to using `IOTTB_HOME`s value as the default path.
# Adding Functionality
## Quick and dirty capture
I want to have a mode which just takes a command and runs it directly with its arguments.
The question is weather to only allow a preconfigured list of commands or in principle allow any command to be passed and write the output. I tend toward providing a subcommand for each utility we want to support. The question is what to do about the syntax errors of those commands. Maybe the thing to do is only write a file into the db if the command runs successfully.
### Refactoring the tcpdump capture
With the above idea it would be possible to also refactor or rewrite how tcpdump is called completely. But, the command has a lot of options and maybe its better also offer some guidance to users via `-h`, e.g. to only input the needed and correct filters for example. Choosing the wrong filter could make the capture potentially useless and one might only see that after the capture has completed.
## Converting pcap to csv
I want an option such that one can automatically convert a captures resulting file into a csv. Probably will focus on tcpdump for now, since other tools like [[mitmproxy]] have different output files.
## Defining Experiment
I want a pair of commands that 1. provide a guided cli interface to define an experiment and 2. to run that experiment -> Here [Collective Knowledge Framework](https://github.com/mlcommons/ck) might actually come in handy. The already have tooling for setting up and defining aspects of experiments so that they become reproducible. So maybe one part of the `iottb` as a tool would be to write the correct json files into the directory which contain the informatin on how the command was run. Caveat: All all option values are the same, basically only, if it was used or not (flagging options) or that it was used (e.g. an ip address was used in the filter but the specific value of the ip is of no use for reproducing). Also, Collective Minds tooling relies very common ML algos/framework and static data. So maybe this only comes into play after a capture has been done. So maybe a feature extraction tool (see [[further considerations#Usage paths/ Workflows]]) should create the data and built the database separately.