Remotely Accessing Secure Kali Pi

kali@kalipi:~$ dmesg | grep wlan

kali@kalipi:~$

Since we were returned directly to the prompt, this means that “wlan” is not found in the dmesg output. As we mention in the Kali firmware for the Raspberry Pi devices, so lets try searching for that instead:

kali@kalipi:~$ dmesg | grep nexmon

[ 5.070542] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Oct 3 2021 18:14:30 version 7.45.206 (nexmon.org: 2.2.2-343-ge3c8-dirty-5) FWID 01-88ee44ea

As we can see in the output above, brcmfmac is the driver that is giving us the message. There is a handy command that comes from the which will give us information about any module that the kernel has.

Now we know that the wireless card on the Raspberry Pi uses the brcmfmac driver. So lets run modinfo brcmfmac and see what information it gives us:

kali@kalipi:~$ modinfo brcmfmac

filename: /lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko

license: Dual BSD/GPL

description: Broadcom 802.11 wireless LAN fullmac driver.

author: Broadcom Corporation

firmware: brcm/brcmfmac*-sdio.*.bin

firmware: brcm/brcmfmac*-sdio.*.txt

[...]

srcversion: 913634DB95F858E921F71C1

[...]

alias: sdio:c*v02D0dA887*

depends: brcmutil,cfg80211

intree: Y

name: brcmfmac

vermagic: 5.15.44-Re4son-v8l+ SMP preempt mod_unload modversions aarch64

parm: txglomsz:Maximum tx packet chain size [SDIO] (int)

parm: debug:Level of debug output (int)

parm: p2pon:Enable legacy p2p management functionality (int)

parm: feature_disable:Disable features (int)

parm: alternative_fw_path:Alternative firmware path (string)

parm: fcmode:Mode of firmware signalled flow control (int)

parm: roamoff:Do not use internal roaming engine (int)

parm: iapp:Enable partial support for the obsoleted Inter-Access Point Protocol (int)

parm: ignore_probe_fail:always succeed probe for debugging (int)

As you can see, there is quite a lot of information given there. A quick overview of it:

• Where the module file is (filename)


• The license


• The description


• The author


• The firmware files it can use


• Aliases used to figure out if this is the module to use when a device is found


• Any module dependencies (depends)


• Whether the module comes from in the kernel tree


• The name of the module


• The version magic


• Any parameters (params)

For what we need, the dependencies section is the key.

When we read the man page for is /lib/firmware/ so the full path to the above would be:

• /lib/firmware/brcmfmac*-sdio.*.bin


• /lib/firmware/brcmfmac*-sdio.*.txt

Notice the wildcards (*) in the firmware names. This means that it will match any of those files, so we will simply include all of the firmware that is in /lib/firmware/brcm, and this would allow for using wireless on not just our current Raspberry Pi 4, but if we were to plug our , or maybe even the package.

Additionally, we will want to check we are online in our script using the wpa_cli command, which will include that as well.

Change The Hostname

By default, Kali images for our Raspberry Pi images are set to the from the , we need to make changes to our system, using the information we gathered above, to boot the system, handle the Wi-Fi network, making the device accessible.

Client Mode

We already know what the wireless network(s) credentials are, and now we are going to join them.

First up is the initramfs hook for the Wi-Fi firmware.

We will create the file /etc/initramfs-tools/hooks/zz-brcm and add the following:

#!/bin/sh

set -e

PREREQ=""

prereqs()

{

echo "${PREREQ}"

}

case "${1}" in

prereqs)

prereqs

exit 0

;;

esac

. /usr/share/initramfs-tools/hook-functions

echo "Copying firmware files for brcm to initramfs"

cp -r /lib/firmware/brcm ${DESTDIR}/lib/firmware/

Next, we will do the hook for the modules and wpa_supplicant files we need.
We will use /etc/initramfs-tools/hooks/enable-wireless which contains:

#!/bin/sh

set -e

PREREQ=""

prereqs()

{

echo "${PREREQ}"

}

case "${1}" in

prereqs)

prereqs

exit 0

;;

esac

. /usr/share/initramfs-tools/hook-functions

# Add Wi-Fi drivers

WIFI_DRIVERS="brcmfmac brcmutil cfg80211 rfkill"

for x in ${WIFI_DRIVERS}; do

manual_add_modules ${x}

done

copy_exec /sbin/wpa_supplicant

copy_exec /sbin/wpa_cli

copy_file config /etc/initramfs-tools/wpa_supplicant.conf /etc/wpa_supplicant.conf

So now that we have our hooks that copy the Wi-Fi firmware, modules, and wpa_suppliant files, we need to write a script to use them in the initramfs.

One important thing to note about scripts in an initramfs, is that there is no guarantee on the order, so we create it with the name a_enable_wireless so that alphabetically it should be the first script that gets run.

The file /etc/initramfs-tools/scripts/init-premount/a_enable_wireless looks like:

#!/bin/sh

set -e

PREREQ=""

prereqs()

{

echo "${PREREQ}"

}

case "${1}" in

prereqs)

prereqs

exit 0

;;

esac

. /scripts/functions

WIFI_INTERFACE="wlan0"

alias WPACLI="/sbin/wpa_cli -p/tmp/wpa_supplicant -i${WIFI_INTERFACE}"

log_begin_msg "Sleeping for 5 seconds to allow WLAN interface to become ready"

sleep 5

log_end_msg

log_begin_msg "Starting WLAN connection"

/sbin/wpa_supplicant -i${WIFI_INTERFACE} -c/etc/wpa_supplicant.conf -P/run/initram-wpa_supplicant.pid -B -f /tmp/wpa_supplicant.log

# Wait for AUTH_LIMIT seconds, then check the status

AUTH_LIMIT=60

echo -n "Waiting for connection (max ${AUTH_LIMIT} seconds)"

while [ $AUTH_LIMIT -ge 0 -a $(WPACLI status | grep wpa_state) != "wpa_state=COMPLETED" ]

do

sleep 1

echo -n "."

AUTH_LIMIT=$(expr $AUTH_LIMIT - 1)

done

echo ""

if [ $(WPACLI status | grep wpa_state) != "wpa_state=COMPLETED" ]; then

ONLINE=0

log_failure_msg "WLAN offline after timeout"

echo

panic

else

ONLINE=1

log_success_msg "WLAN online"

echo

fi

configure_networking

Additionally, we need to kill the networking once we are booted, so that the actual system can use the device and connect properly.

This script /etc/initramfs-tools/scripts/local-bottom/kill_wireless is made up with:

#!/bin/sh

set -e

PREREQ=""

prereqs()

{

echo "${PREREQ}"

}

case "$1" in

prereqs)

prereqs

exit 0

;;

esac

echo "Killing wpa_supplicant so the system takes over later"

kill $(cat /run/initram-wpa_supplicant.pid)

As a reminder, scripts need to be executable if you want them to run.
Additionally, if a hook is not marked as executable, initramfs-tools will skip that hook when running update-initramfs:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/zz-brcm

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/enable-wireless

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/a_enable_wireless

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/local-bottom/kill_wireless

Now we use the information that we have gathered ahead of time to create our wpa_supplciant.conf file to include the SSID & PSK, and any other possible options that the Wi-Fi network connection might need. You can read more information about the file by running man wpa_supplicant.conf.

A shortcut to generating one is to simply run wpa_passphrase SSID PASSWORD where SSID is the name of the wireless network, and PASSWORD is the passphrase (aka PSK) for the network.

In this example, we are going to be connecting our Raspberry Pi to the network kali wireless with a passphrase of secure kali wireless.

One thing to note here, when you use wpa_passphrase to generate the PSK, it includes the passphrase in plain text. Because of this, we will strip that line out of the file, just in case if anyone else happens to come across the device and knows how to look inside an initramfs file, we do not want them seeing the plain text password to the network! And because we are using tee rather than > to write the file, we will see the file’s contents as its written:

kali@kalipi:~$ wpa_passphrase "kali wireless" "secure kali wireless" | grep -v \#psk | tee wpa_supplicant.conf

If you want to add multiple wireless networks to your wpa_supplicant.conf file, we can append the file rather than overwriting it:

kali@kalipi:~$ wpa_passphrase "kali wireless the second" "even more secure kali wireless" | grep -v \#psk | tee -a wpa_supplicant.conf

Now we copy the newly generated configuration into /etc/initramfs-tools/ as that is where our enable-wireless hook expects it to be:

kali@kalipi:~$ sudo cp -v wpa_supplicant.conf /etc/initramfs-tools/wpa_supplicant.conf

As a reminder, we covered which kernel version to use in our , we will continue to do so here, so our kernel version is 5.15.44-Re4son-v8l+

Now that we have all the parts that we need, we simply run mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+ to generate the initramfs file with our changes to add wireless networking.

We can also verify that our changes are in the initramfs by running lsinitramfs /boot/initramfs.gz and use grep to show the files we are looking for:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

kali@kalipi:~$

kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e wpa -e brcm

etc/wpa_supplicant.conf

usr/lib/firmware/brcm

usr/lib/firmware/brcm/BCM-0a5c-6410.hcd

usr/lib/firmware/brcm/BCM-0bb4-0306.hcd

usr/lib/firmware/brcm/BCM43430A1.hcd

usr/lib/firmware/brcm/BCM43430B0.hcd

usr/lib/firmware/brcm/BCM4345C0.hcd

usr/lib/firmware/brcm/BCM4345C5.hcd

usr/lib/firmware/brcm/brcmfmac43430-sdio.bin

usr/lib/firmware/brcm/brcmfmac43430-sdio.rpi.bin

usr/lib/firmware/brcm/brcmfmac43430-sdio.txt

usr/lib/firmware/brcm/brcmfmac43436-sdio.bin

usr/lib/firmware/brcm/brcmfmac43436-sdio.clm_blob

usr/lib/firmware/brcm/brcmfmac43436-sdio.txt

usr/lib/firmware/brcm/brcmfmac43436s-sdio.bin

usr/lib/firmware/brcm/brcmfmac43436s-sdio.txt

usr/lib/firmware/brcm/brcmfmac43455-sdio.bin

usr/lib/firmware/brcm/brcmfmac43455-sdio.clm_blob

usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_154.bin

usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_189.bin

usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_206.bin

usr/lib/firmware/brcm/brcmfmac43455-sdio.rpi.bin

usr/lib/firmware/brcm/brcmfmac43455-sdio.txt

usr/lib/firmware/brcm/brcmfmac43456-sdio.bin

usr/lib/firmware/brcm/brcmfmac43456-sdio.clm_blob

usr/lib/firmware/brcm/brcmfmac43456-sdio.txt

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/i2c/busses/i2c-brcmstb.ko

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil

usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko

usr/sbin/wpa_cli

usr/sbin/wpa_supplicant

As we can see from the output, our initramfs has our modules, firmware, and wpa_supplicant files for the Wi-Fi chip the Raspberry Pi 4 uses!

If you are only interested in using the Raspberry Pi as a Wi-Fi client, you can stop here, and unmount everything like we did in our .

The important thing is to set the options we need, and leave empty the ones we do not. The default cmdline.txt has the following in it:

kali@kalipi:~$ cat /boot/cmdline.txt

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

The cmdline.txt requires everything to be on one line, so if we want to set our IP address to 192.168.42.3, with a gateway of 192.168.42.1, our hostname to securekalipi, for the wlan0 device, our /boot/cmdline.txt file will look like:

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0 ip=192.168.42.3::192.168.42.1:255.255.255.0:securekalipi:wlan0

As the , if we want to set it up as an access point to connect to, we need to add into the initramfs. Like last time, our Wi-Fi drivers, the firmware just this time, its different software and configurations.

The package you would use on Linux to set up an access point is - we run wpa_passphrase SecureKaliPi SecureKaliPiWiFi and then we copy the psk line that is not the plaintext password:

kali@kali:~$ wpa_passphrase SecureKaliPi SecureKaliPiWiFi

network={

ssid="SecureKaliPi"

#psk="SecureKaliPiWiFi"

psk=16270ab793c4420e0c3dd6bf46ede4f10bd71ffbe6a79998dc70ccd8dea18680

}

You can, and should, change the configuration to match your needs. If you would like to set it up to use 5GHz, you would need to change hw_mode=g to hw_mode=a, but keep in mind that if you are using 5GHz you need to change the channel. , we can see that this option is what will allow us to hide our SSID from being broadcast:

# Send empty SSID in beacons and ignore probe request frames that do not

# specify full SSID, i.e., require stations to know SSID.

# default: disabled (0)

# 1 = send empty (length=0) SSID in beacon and ignore probe request for

# broadcast SSID

# 2 = clear SSID (ASCII 0), but keep the original length (this may be required

# with some clients that do not support empty SSID) and ignore probe

# requests for broadcast SSID

ignore_broadcast_ssid=0

Now that we have written our hostapd.conf we can quickly test if it works by running:

kali@kalipi:~$ sudo /usr/sbin/hostapd /etc/hostapd/hostapd.conf

wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE

wlan0: interface state COUNTRY_UPDATE->ENABLED

wlan0: AP-ENABLED

If everything is set up correctly, you should see the above output. If you get any errors, you will need to correct those and re-run the command.

Now that hostapd is set up, and we have tested that it works, lets add it to our initramfs.

Because we need to add some binaries to the initramfs, we also need to include any dependencies that may be needed. So first we check which binary we need:

kali@kalipi:~$ dpkg -L hostapd | grep bin

/usr/sbin

/usr/sbin/hostapd

/usr/sbin/hostapd_cli

We need the hostapd binary, and to check its dependencies we will run to run a DHCP server, but since we have already got busybox which has a DHCP server applet enabled in the initramfs, we will just use that instead. We do not need a fully featured DHCP server just to unlock our Raspberry Pi and let it finish booting.

First we set up the configuration file for it /etc/udhcpd.conf with the following information:

start 192.168.42.2 # IP address range to give out

end 192.168.42.100 # Last IP address to give out

interface wlan0 # Device that the DHCP server listens on

remaining yes #

opt router 192.168.42.1 # The Raspberry Pi's IP address to use on wlan0

opt subnet 255.255.255.0 #

opt dns 8.8.8.8 4.2.2.2 # DNS servers to pass (not really required for our needs)

opt lease 600 # 10 minute DHCP lease

And we create our hook which copies in our DHCP config, /etc/initramfs-tools/hooks/udhcpd:

#!/bin/sh

set -e

PREREQ=""

prereqs()

{

echo "${PREREQ}"

}

case "${1}" in

prereqs)

prereqs

exit 0

;;

esac

. /usr/share/initramfs-tools/hook-functions

# Copy our hostapd.conf file

copy_file config /etc/udhcpd.conf /etc/udhcpd.conf

Like our previous hooks and scripts, we need to make sure the executable flag is set:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/hostapd

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/udhcpd

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/hostapd

And now that everything is in place for hostapd support, we need to build the initramfs so that it has our changes in there:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

kali@kalipi:~$

kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e hostapd -e udhcpd

etc/hostapd

etc/udhcpd.conf

scripts/init-premount/hostapd

usr/sbin/hostapd

usr/sbin/udhcpd

Once we see all the parts are there, we are able to reboot the Raspberry Pi and we should see our Wi-Fi network from another machine.

, and set the IP manually in the /boot/cmdline.txt file, which is what the Raspberry Pi uses for the kernel command line arguments.

Static IP

The default /boot/cmdline.txt is set to:

kali@kalipi:~$ cat /boot/cmdline.txt

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

The format of /boot/cmdline.txt should look similar to:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>

/boot/cmdline.txt requires everything to be on one line, so if we want to set our IP address to 192.168.42.3, with a gateway of 192.168.42.1, our hostname to securekalipi, for the eth0 device, our /boot/cmdline.txt file will look like:

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0 ip=192.168.42.3::192.168.42.1:255.255.255.0:securekalipi:eth0

As the , there is not going to be an upstream gateway configured. As a result, the VPN tunnel will not be able to connect to the internet. You will need to find another way to get online, by either using another mode ( shows us:

--auth-user-pass

Authenticate with server using username/password.

Valid syntaxes:

auth-user-pass

auth-user-pass up

If up is present, it must be a file containing username/password on 2 lines. If the password line is missing, OpenVPN will prompt for > one.

If up is omitted, username/password will be prompted from the console.

The option we want is --auth-user-pass up. So we will create a file called up with our username (dropboxuser) on the first line, and password (pass123) on the second line:

kali@kalipi:~$ echo dropboxuser | sudo tee /etc/openvpn/client/up

[...]

kali@kalipi:~$ echo pass123 | sudo tee -a /etc/openvpn/client/up

If your VPN connection does not require a username/password, you can remove the --auth-user-pass /etc/openvpn/up in the vpnflags variable below.

The script, which starts OpenVPN, /etc/initramfs-tools/scripts/init-premount/openvpn:

#!/bin/sh

set -e

PREREQ="udev networking"

prereqs() {

echo "$PREREQ"

}

case "$1" in

prereqs)

prereqs

exit 0

;;

esac

[ -x /sbin/openvpn ] || exit 0

run_openvpn() {

local vpnflags="--suppress-timestamps --nobind --config /etc/openvpn/client/openvpn.conf --auth-user-pass /etc/openvpn/client/up"

log_begin_msg "Starting OpenVPN"

exec /sbin/openvpn $vpnflags

ifconfig -a

}

. /scripts/functions

sleep 40

run_openvpn &

echo $! >/run/openvpn.pid

And like with the others, we make sure our hooks and scripts are executable:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/openvpn

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/openvpn

And now that everything is in place for connecting to OpenVPN, we need to build the initramfs so that it has our changes in there:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

kali@kalipi:~$

kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e openvpn

etc/openvpn

etc/openvpn/client

etc/openvpn/client/up

scripts/init-premount/openvpn

usr/sbin/openvpn

Now that the initramfs is updated, and we see that our changes are in there, we are able to reboot the Raspberry Pi. Once it starts booting, and once the network connection is available, it should connect to our OpenVPN server.

You will want to test this in your home lab, before you deploy it anywhere, to make sure it’s working:

kali@kali:~$ ssh [email protected]

The authenticity of host '172.16.20.2' can't be established.

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Warning: Permanently added '172.16.20.2' (ECDSA) to the list of known hosts.

[email protected]'s password:

Linux kali-raspberry-pi 5.15.44-Re4son-v8+ #1 SMP PREEMPT Debian kali-pi (2022-07-03) aarch64

The programs included with the Kali GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

┌──(kali㉿kali-raspberry-pi)-[~]

└─$

Summary

In this blog post, we have covered gathering information about our device, in this case it was a Raspberry Pi, but the information gathering holds true for any device running Kali that you might want to unlock remotely.

We also covered setting a static IP for both wired and Wi-Fi networks, setting up an access point, and using an OpenVPN connection, these are not specific to the Raspberry Pi, aside from the firmware and module for the Wi-Fi device.

We hope you found this blog post helpful, and if you have any questions or comments, please check out the ), ICMP (such as ), making it legit HTTPS data, rather than only using default port

We are sure you can also think outside of the box, and come up with additional ideas too. Please