## 3 System Architecture and Attack Surface  
The PHGL-COVID platform is a proof-of-concept mHealth system that facilitates secure, remote health monitoring using a multi-layered architecture comprising wearable devices, Android-based mobile clients, and a containerized backend server. The architecture of PHGL-COVID represents a real-life scenario, where physiological data (heart rate, oxygen saturation, and activity logs) are collected by wearable devices that upload to a smartphone over BLE, the smartphone securely transmits the data collected to the backend system via encrypted API requests. While the platform was primarily intended to allow for the rapid launch of digital health in a pandemic environment, it also embodies objectives such as scalability, mobile accessibility, and suitability for under-resourced healthcare systems [27, 28, 29]. At the edge of the system, a Samsung Galaxy Watch 7 running on Wear OS collects physiological data and transmits to a Samsung Galaxy A55 smartphone using BLE. The smartphone represents the gateway device, running the PHGL-COVID mobile application, aggregating the collected data, and sending it to the backend system user encrypted HTTPS RESTful API calls via Wi-Fi or LTE. Authentication is controlled in the mobile app via session tokens, and payloads are encrypted using AES before transmission, which is standard practice for mobile SDK [30, 31, 32]. The backend is running in a containerized environment using Docker to isolate key services such as API endpoints, authentication modules, and database components used for electronic health records (EHR). The container stack operates on a virtual Linux server accessible on the Internet. While the stack uses TLS to communicate with the client side of the stack securely, the backend was deployed with little hardening and has services exposed that include Universal Plug and Play (UPnP) and legacy administrative interfaces. These risky services open numerous attack vectors, such as outdated libraries, bad actors finding open ports, and poorly isolated services [33, 34, 35]. Once again, each component of the system has its own risk profile. The smartwatch has the potential for BLE sniffing, and exposed GATT characteristics, the smartphone may cache tokens even beyond the session has ended or execute an application with more privileges because of the permissive firmware, the backend may have insecure code injection or lateral privilege escalation, or the service boundaries are not strictly enforced, and it may divulge tenant data. Between each layer of the stack is communication that can be compromised through man-in-the-middle attack or payload reuse/modification [36, 37]. Figure 1 depicts the complete system architecture and data flow of the PHGL-COVID platform, displaying both communication pathways, trust boundaries and connections between the system components. As shown, each sub-system presents its own attack surfaces, a reminder not to evaluate the system in siloed layers. This layered audit framework attempts to remediate the growing complexity of mHealth systems by providing a method to analyze not only isolated vulnerabilities, but related vulnerabilities across the wearable, mobile and backend layers. Different methods would be applied to identify vulnerabilities including packet inspection, application decompilation, BLE profiles, and tracing privilege during runtime. The audit would evaluate the exposure of all components together as opposed to the layers independently. Each layer is evaluated in a live operational state, the smartwatch while it transmitted the sensor data, the smartphone while it acted as a session gateway between the smartwatch and the backend API, and the backend while it experienced simulated API load. The results demonstrate that risks do not solely exist within isolated components, but that they would be capable of cascading to all parts of the system yielding a compounded risk for exposure if the wrong risks aligned across weaknesses [31,38].