## 3 System Architecture and Attack Surface
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Layer** & **Tool/Technique** & **Purpose** & **Output Type** \\ \hline \multirow{2}{*}{Backend} & Trivy, OpenVAS, Nikto & Container and web vulnerability scanning & CVEs, misconfigurations, open ports \\ \hline \multirow{4}{*}{Mobile (A55)} & \multirow{2}{*}{ADB, dumpsys, pm list} & Compliance auditing and Docker hardening & \multirow{2}{*}{Package list, permission mapping} \\  & & Device inspection, app enumeration & \\ \hline \multirow{4}{*}{Frida, MobSF} & \multirow{2}{*}{Hoking, reverse engineering, APK static analysis} & API calls, behavior flows, weaknesses \\ \cline{2-4}  & & & \\ \cline{1-1} \cline{2-4}  & \multirow{2}{*}{Wireshark} & Network and BLE capture from mobile device & \multirow{2}{*}{PCAPs, session metadata} \\ \cline{1-1} \cline{2-4}  & & BLE profile inspection, sniffing, replay attempts & \\ \hline \multirow{4}{*}{Wearable} & \multirow{2}{*}{btmon, BLEAH, GATT Tool} & Manual inspection of characteristics & \multirow{2}{*}{GATT table, cleartext payloads} \\  & & & \\ \cline{1-1} \cline{2-4}  & & & \\ \cline{1-1} \cline{2-4}  & & & \\ \hline \end{tabular}
\end{table} 
Table 2: Tools and Techniques Used in PHGL-COVID Audit. The overall conclusions of the audit suggest that even consumer smartphones in the middle-range of the market could compromise the integrity of mHealth platforms if the firmware is non-official and/or subject to being unpatched. The wearable audit focused on the configuration and exposure to BLE with the Galaxy Watch 7. As a member of the Bluetooth SIG, the Galaxy Watch 7 is expected to adhere to Bluetooth specification. The btmon and heitool commands, both indicate that there was an unencrypted GATT endpoint and advertising frame. There was also a feasible way to use nRF Connect, and read health-related characteristics like heart rate, temperature and energy expenditure without any authentication whatsoever [45; 46]. Runtime inspection via ADB Shell Dumpsys Bluetooth_Manager and Dumpsys Activity revealed constant background services that maintain the BLE connection and push data to the phone approximately every 45 s. These services operate without the user's knowledge and are not restricted to health-specific processes. This creates an expanded attack surface if a rogue mobile client gains pairing status [47]. Although there were not any rooting or bootloader unlocking detected during the audit of the device. The device reported a \"green\" verified boot state, indicating secure boot, but the potentially problematic permissive SELinux mode (common in Wear OS devices for performance and vendor compatibility reasons), does provide some risk to privilege escalation. And as our audit has shown, even if there is not an explicit compromise, the wearable presents real vulnerabilities into the mHealth ecosystem, particularly when BLE is exposed or unencrypted. The attack surface has expanded beyond mobile, and backend components to the wearable firmware and transitory layers of communication. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**UUID** & **Characteristic** & **Access Level** & **Risk Summary** \\ \hline
0x180D & Heart Rate Measurement & Readable & Unencrypted heart data exposed via BLE \\ \hline
0x2A53 & Step Count & Readable & Physical activity profile externally visible \\ \hline
0x2A6E & Temperature & Readable & Allow passive monitoring of environment \\ \hline
0x2A37 & Energy Expenditure & Readable & Could be used for profiling behavior \\ \hline
0x2902 & Client Config Descriptor & Writable & Susceptible to spoofed notification triggers \\ \hline \hline \end{tabular}
\end{table} 
Table 4: BLE GATT Characteristics Exposed During Watch–Phone Pairing.