> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/foodcore-sensors/technical/hardware-specs/dragino-sensors/internal-pentest.md).

# Internal Pentest

## Penetration Testing Report – Dragino LHT65S Sensor

**Device Tested:** Dragino LHT65S LoRaWAN Temperature & Humidity Sensor

**Test Date:** 20/10/2024

**Tested By:** MFC Safe

***

### Executive Summary

This report outlines the penetration testing results for the Dragino LHT65S sensor, focusing on physical access, firmware integrity, wireless security, and overall device resilience. The sensor demonstrated a strong security profile for a low-power LoRaWAN device, with no high-risk vulnerabilities identified.

| Test Category           | Result Summary                         | Risk Level |
| ----------------------- | -------------------------------------- | ---------- |
| Physical Access Ports   | UART port exposed without protection   | Low        |
| Firmware Security       | Flash memory protected, no read access | Low        |
| Wireless Communication  | AES-128 encryption validated           | Low        |
| Device Authentication   | No exposed login interfaces            | Low        |
| OTA Updates             | Manual update only, no remote override | Low        |
| Known Vulnerabilities   | None applicable to LHT65S              | Low        |
| Data Integrity & Replay | Retransmission and validation passed   | Low        |

***

### Test Details & Findings

#### 1. Physical Port Security

* **Finding:** UART debug pins are exposed on the board.
* **Impact:** Enables potential local manipulation if physical access is gained.
* **Recommendation:** Restrction of entry to premisis, epoxy or mask headers in production deployments.
* **Risk:** Low

#### 2. Firmware Protection

* **Finding:** Memory is encrypted and read-protected.
* **Result:** Firmware dumping attempts failed.
* **Risk:** Low

#### 3. LoRaWAN Security

* **Finding:** Communication uses LoRaWAN AES-128 encryption.
* **Result:** Payloads could not be interpreted without NwkSKey/AppSKey.
* **Risk:** Low

#### 4. Authentication Exposure

* **Finding:** Device does not expose a user-facing login or web portal.
* **Result:** No brute-force or bypass attacks applicable.
* **Risk:** Low

#### 5. OTA Firmware

* **Finding:** No over-the-air update mechanism is available.
* **Impact:** Firmware must be physically flashed, reducing remote attack surface.
* **Risk:** Low

#### 6. Known Vulnerabilities

* **Finding:** No CVEs found that apply to LHT65S model.
* **Risk:** Low

#### 7. Data Integrity and Replay Protection

* **Finding:** Data transmission follows confirmed uplinks with retries.
* **Result:** Transmission retry logic prevents data loss.
* **Risk:** Low

***

### Recommendations

* **Secure physical access** to sensors with tamper-evident enclosures.
* **Mask or epoxy UART ports** where unused.
* **Maintain firmware currency** via Dragino updates and notices.

***

### Conclusion

The Dragino LHT65S sensor passed all critical and major security tests with no exploitable high-risk vulnerabilities. Its physical security could be improved, but wireless communications, firmware protection, and operational design are suitable for deployment in secure environments.

***

*This report is intended for internal compliance and client submission purposes.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.didge.io/home/foodcore-sensors/technical/hardware-specs/dragino-sensors/internal-pentest.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.