Customize the installation

[sport80]

Hi, I tried the project with a Raspberry PI 3A+ and it works very well.
However, I would like to customize some settings for security reasons. I would like to change the WiFi password, try to ask for the bluetooth pin and change the root password but I couldn't.
When I change the WiFi password from the pre-built sd card image, the smartphone no longer connects.
I also tried to recompile the image changing the parameters in the sources files configuration but it still doesn't work.
Is there a way to customize the installation?

Thanks

Best regards

[nisargjhaveri]

For wifi password:

1. You need to change /etc/hostapd.conf
2. If you're building from scratch, you need to change the password mentioned package/aawg/src/common.cpp. OR you can somehow set the AAWG_WIFI_PASSWORD environment variable for the aawgd process.

For bluetooth, you'd likely need to change the bt_agent settings, the entry point is /etc/init.d/90bt_agent.

For the root password, if you're building from scratch, you can update the BR2_TARGET_GENERIC_ROOT_PASSWD setting in respective defconfig file. Or you can ssh and change the password on first use.

We should make some changes to have unique wifi passwords for each device on first boot or something, and maybe lock down root somehow unless in debugging mode. Bluetooth, I believe is okay, since the device does not have any input/output, generic PIN method does not work well.

[sport80]

Hi, thank you very much for the reply. Changing root password is not a problem but I don't know if could be a problem for the installation for some dependencies. Changing the wifi password through the hostapd.conf does not work, the password was changed but the smatphone does not work. I try to change the common.cpp file. Thanks Il 24 Gennaio 2024 20:09:16 CET, Nisarg Jhaveri ***@***.***> ha scritto:

…

For wifi password: 1. You need to change /etc/hostapd.conf 2. If you're building from scratch, you need to change the password mentioned package/aawg/src/common.cpp. OR you can somehow set the `AAWG_WIFI_PASSWORD` environment variable for the aawgd process. For bluetooth, you'd likely need to change the bt_agent settings, the entry point is /etc/init.d/90bt_agent. For the root password, if you're building from scratch, you can update the `BR2_TARGET_GENERIC_ROOT_PASSWD` setting in respective defconfig file. Or you can ssh and change the password on first use. We should make some changes to have unique wifi passwords for each device on first boot or something, and maybe lock down root somehow unless in debugging mode. Bluetooth, I believe is okay, since the device does not have any input/output, generic PIN method does not work well. -- Reply to this email directly or view it on GitHub: #42 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[sport80]

Hi, changing the hostapd.conf and the common.cpp it works like a charm. I've also changed the root password and no issue about the functionality. Now, next step, I try to implement the bluetooth PIN. I don't have really understood if the bluetooth discovery turn off after the pairing, after the WiFi connection the bluetooth remain on and connected to the raspberry. If another device want to connect, even if the discovery was disabled, it can potentially find it and connect to the them, so, connect to the wifi and can access to more others data and this could be a security issue. Also the static PIN it's a low level protection, but with this it could be a limited and accettable security issue. What do you think about this?

Thank you very much

[hkfuertes]

If it helps (maybe I'm late), this is a little diff/patch file that I use when building my own images.

diff --git a/aa_wireless_dongle/board/common/rootfs_overlay/etc/hostapd.conf b/aa_wireless_dongle/board/common/rootfs_overlay/etc/hostapd.conf
index cddea29..b3a7ca5 100644
--- a/aa_wireless_dongle/board/common/rootfs_overlay/etc/hostapd.conf
+++ b/aa_wireless_dongle/board/common/rootfs_overlay/etc/hostapd.conf
@@ -1,4 +1,4 @@
-country_code=IN
+country_code=ES
 
 ctrl_interface=/var/run/hostapd
 interface=wlan0
@@ -12,5 +12,5 @@ wpa=2
 wpa_key_mgmt=WPA-PSK
 rsn_pairwise=CCMP
 
-ssid=AAWirelessDongle
-wpa_passphrase=ConnectAAWirelessDongle
+ssid=AndroidAuto_28a9a7
+wpa_passphrase=1234567890
diff --git a/aa_wireless_dongle/board/common/rootfs_overlay/etc/init.d/S92usb_gadget b/aa_wireless_dongle/board/common/rootfs_overlay/etc/init.d/S92usb_gadget
index 4ab6f5c..9a18e7b 100755
--- a/aa_wireless_dongle/board/common/rootfs_overlay/etc/init.d/S92usb_gadget
+++ b/aa_wireless_dongle/board/common/rootfs_overlay/etc/init.d/S92usb_gadget
@@ -3,9 +3,9 @@
 # Configure USB gadget interfaces
 #
 
-SERIAL_NUMBER="0123456"
-MANUFACTURER="My Own"
-PRODUCT="AA Wireless Dongle"
+SERIAL_NUMBER="1234567890"
+MANUFACTURER="Raspberry Pi"
+PRODUCT="Android Auto Wireless"
 
 ACCESSORY_GADGET_NAME="accessory"
 DEFAULT_GADGET_NAME="default"
diff --git a/aa_wireless_dongle/board/raspberrypi4/rootfs_overlay/etc/hostapd.conf b/aa_wireless_dongle/board/raspberrypi4/rootfs_overlay/etc/hostapd.conf
index 7ee0915..84670ce 100644
--- a/aa_wireless_dongle/board/raspberrypi4/rootfs_overlay/etc/hostapd.conf
+++ b/aa_wireless_dongle/board/raspberrypi4/rootfs_overlay/etc/hostapd.conf
@@ -1,4 +1,4 @@
-country_code=IN
+country_code=ES
 
 ctrl_interface=/var/run/hostapd
 interface=wlan0
@@ -13,5 +13,5 @@ wpa=2
 wpa_key_mgmt=WPA-PSK
 rsn_pairwise=CCMP
 
-ssid=AAWirelessDongle
-wpa_passphrase=ConnectAAWirelessDongle
+ssid=AndroidAuto_28a9a7
+wpa_passphrase=1234567890
diff --git a/aa_wireless_dongle/package/aawg/src/bluetoothHandler.cpp b/aa_wireless_dongle/package/aawg/src/bluetoothHandler.cpp
index 150e4a0..0384a97 100644
--- a/aa_wireless_dongle/package/aawg/src/bluetoothHandler.cpp
+++ b/aa_wireless_dongle/package/aawg/src/bluetoothHandler.cpp
@@ -4,7 +4,7 @@
 #include "bluetoothHandler.h"
 #include "bluetoothProfiles.h"
 
-static constexpr const char* ADAPTER_ALIAS = "AA Wireless Dongle";
+static constexpr const char* ADAPTER_ALIAS = "AndroidAuto_28a9a7";
 
 static constexpr const char* BLUEZ_BUS_NAME = "org.bluez";
 static constexpr const char* BLUEZ_ROOT_OBJECT_PATH = "/";
diff --git a/aa_wireless_dongle/package/aawg/src/common.cpp b/aa_wireless_dongle/package/aawg/src/common.cpp
index ae137cc..e2b4f35 100644
--- a/aa_wireless_dongle/package/aawg/src/common.cpp
+++ b/aa_wireless_dongle/package/aawg/src/common.cpp
@@ -39,8 +39,8 @@ std::string Config::getMacAddress(std::string interface) {
 
 WifiInfo Config::getWifiInfo() {
     return {
-        getenv("AAWG_WIFI_SSID", "AAWirelessDongle"),
-        getenv("AAWG_WIFI_PASSWORD", "ConnectAAWirelessDongle"),
+        "AndroidAuto_28a9a7",
+        "1234567890",
         getenv("AAWG_WIFI_BSSID", getMacAddress("wlan0")),
         SecurityMode::WPA2_PERSONAL,
         AccessPointType::DYNAMIC,

[dimo414]

maybe lock down root somehow unless in debugging mode

Any chance this is something that could be done soon? The fact that anyone who reads this project's README (or Google's the network name) can log in - as root - to any device running the released images seems like a significant exploit surface.

[nisargjhaveri]

Yes, we should really fix this. Would preventing ssh as root when not in debug mode help?

We can't easily lock down bluetooth, and wifi password we hand out to anyone who can connect via bluetooth anyway.

We can move /etc/aawg.env to /boot partition and have a option to enable ebug mode using sd card reader, since we won't be able to ssh after this change. Or we have to have a companion app with some additional security set on first use or something. Thoughts?

[dimo414]

The root password is definitely the biggest issue; if ssh is locked down then being on the wifi is far less useful. IMO it's still worth shuffling the wifi password just so it isn't google-able, but if it's hard it's not a huge deal.

Putting this stuff as persistent config on the sd card makes sense to me; it should still be easy to ssh, just not easy by default. Also I wonder if it's feasible to not let people log in as root at all, and create a sudoer-enabled non-root account instead?

[nisargjhaveri]

The root password is definitely the biggest issue; if ssh is locked down then being on the wifi is far less useful. IMO it's still worth shuffling the wifi password just so it isn't google-able, but if it's hard it's not a huge deal.

We won't be easily able to change the root password. What we can do is disable ssh and maybe change the wifi password as well when not in debug mode. In debug mode, we need to use either a user defined or pre-set wifi password to allow direct login.

Also I wonder if it's feasible to not let people log in as root at all, and create a sudoer-enabled non-root account instead?

Would this really make a difference?

[nisargjhaveri]

#200 makes the Wifi password randomly generated every time making it much more difficult to connect. It also adds a config for when you want a fixed wifi password for debugging etc.

[pbz]

Testing out #200 and not having much luck, and thinking that still might not offer that much security as password would still be advertised via bluetooth? Would it be possible to have a mode where the wifi password is set manually and NOT advertised, but entered manually on the phone? Not sure if this would work or not with the way AA handles these things... Might try to experiment with this later.

[nisargjhaveri]

Would it be possible to have a mode where the wifi password is set manually and NOT advertised, but entered manually on the phone? Not sure if this would work or not with the way AA handles these things...

This might be possible, but only with a companion app. https://github.com/nisargjhaveri/AAWirelessGateway has a custom connection mode which does something similar. But it will not be as seamless and I don't think it'd work without the companion app natively with AA.

[nisargjhaveri]

With 55f76f5, we're using a random wifi password, that makes it somewhat difficult (but not impossible as we still advertise the wifi password on bluetooth handshake) to connect.

With b538377, ssh is now disabled by default, unless specifically enable for debugging.

Both of these combined should provide considerably better protection compared to compared to earlier.