# Gerbera UAV Forensic Report: MEC Encryption and Passphrase Delivery

Prepared: 2026-07-10  
Evidence roots: `img/` and `gb2/img/`  
Analysis mode: read-only; source evidence was not modified

## Executive summary

The literal passphrase was not recovered from the two dumps. However, reverse engineering and log correlation identify a substantially stronger recovery path than the system journal: **the unlock passphrase is delivered by the Honor/Huawei controller tablet in plaintext JSON over TCP port 8052**.

EPathfinder receives a JSON message with `messageType` 10, takes the `data` field as the passphrase, starts `/home/jetson/prepare_tg.sh`, and writes the value unchanged to the script's standard input. The same value is then used to unlock the LUKS2 `mec` container and decrypt `ThunderGaze.gpg`.

The highest-value evidence sources are therefore:

1. The Honor/Huawei controller tablet's storage and RAM.
2. A passive packet capture of TCP port 8052 during an unlock on an isolated forensic clone.
3. The administrative/build workstation at `192.168.110.107`.
4. External copies of the deployment archives or `ThunderGaze.gpg`.

## 1. Secret-delivery path

Reverse engineering `img/APP/home/jetson/EPathfinder_3794/EPathfinder` shows that `VehicleController::setCodeMessage` performs the equivalent of:

```text
cookie = json["cookie"]
secret = json["data"]

start("/home/jetson/prepare_tg.sh", no arguments)
waitForStarted(1000 ms)
write(secret.toUtf8())
closeWriteChannel()
```

The relevant application message is therefore effectively:

```json
{"messageType":10,"cookie":"…","data":"<exact passphrase>"}
```

Findings from the binary:

- `data` is the actual passphrase, not a hash or encoded derivative.
- The value is converted to UTF-8 and written unchanged to the script's stdin.
- No newline is required. Closing the write channel produces EOF, allowing `read -r pass` to retain the value.
- The protocol is plaintext JSON over TCP. No TLS, Base64 decoding, KDF, environment variable, or embedded passphrase is involved.
- The TCP parser uses `}` as the JSON-message boundary, so TCP-stream reassembly is important when examining captures.
- Message type 10 bypasses the generic full-JSON debug-logging path. This explains why the secret is absent from the surviving EPathfinder logs and system journal.
- This is the only EPathfinder `QProcess` stdin write found.

Binary identification:

```text
Path:   img/APP/home/jetson/EPathfinder_3794/EPathfinder
SHA256: f656cbf1bc7f8ee7d1d07cf8471f3a9733155c14f437d7aa432d9706aa3a6c2c
Symbol: VehicleController::setCodeMessage
VA:     0x000b5600
```

Relevant reverse-engineered call locations include the process start near `0xb58bc`, UTF-8 conversion near `0xb590c`, stdin write near `0xb599c`, and `closeWriteChannel` near `0xb59b8`.

The recovered script fragment independently confirms the receiving side:

```text
img/APP/recovery/mec_leads/smartStart_readpass_fragment_78121021440.sh
```

```bash
read -r pass
echo ${pass} | cryptsetup --readonly open /home/jetson/mec my_enc_mec
echo $pass | gpg --yes --batch --passphrase-fd 0 \
  --output /home/jetson/thunder_gaze/thunder_gaze_f1.tgz \
  --no-symkey-cache /home/jetson/ThunderGaze.gpg
```

An older recovered generation at `img/APP/recovery/mec_leads/tar_from_prepare_tg/prepare_tg.sh` accepted the same value in `argv[1]`. This indicates at least two launcher generations, but both use one passphrase for LUKS and GPG.

## 2. Controller and unlock correlation

EPathfinder listens on TCP port `8052`, configured at:

```text
img/APP/home/jetson/EPathfinder_3794/settings.json:111
```

The aircraft access point is `10.10.10.5/24`. Across events involving the current 60 GB container:

- GB1: 27 of 27 unlocks follow an `HONOR` or `HONOR-Pad-X9` DHCP join. Twenty-six occur within 60 seconds; one occurs within 197 seconds.
- GB2: 32 of 32 unlocks follow an Honor join. Thirty-one occur within 60 seconds; one occurs within 240 seconds.
- The dumps share a 12-event prefix because they were made from a cloned base image. After de-duplication, 47 of 47 independent unlocks follow an Honor join, with 45 of 47 occurring within 60 seconds.
- In the two cases where a desktop DHCP event was temporally nearer, an Honor device had still joined 11 or 16 seconds before the unlock.

### Final-boot sequence, GB1

```text
img/APP/var/log/syslog:2660417
Jan  1 00:00:51 DHCPACK 10.10.10.102 ... HONOR-Pad-X9

img/APP/home/videoview/EPathfinder_3794_logs/_log_.log:11
[01/01/1970 00:01:05.118] "new connection 10"

img/APP/var/log/syslog:2660427
Jan  1 00:01:13 loop1: detected capacity change ... 122880000 sectors

img/APP/var/log/syslog:2660430
Jan  1 00:01:16 EXT4-fs (dm-0): mounted filesystem
```

### Final-boot sequence, GB2

```text
gb2/img/APP/var/log/syslog:2857953
Jan  1 00:00:52 DHCPACK 10.10.10.128 ... HONOR-Pad-X9

gb2/img/APP/home/videoview/EPathfinder_3815_logs/_log_:47
[01/01/1970 00:00:55.732] "new connection 10"

gb2/img/APP/var/log/syslog:2857957
Jan  1 00:01:04 loop1: detected capacity change ... 122880000 sectors

gb2/img/APP/var/log/syslog:2857962
Jan  1 00:01:07 EXT4-fs (dm-0): mounted filesystem
```

The January 1970 values should be interpreted as boot-relative times because the real-time clock was unset.

Persistent lease evidence includes:

```text
img/APP/var/lib/NetworkManager/dnsmasq-wlP1p1s0.leases
  HONOR-Pad-X9
  HONOR
  HUAWEI_MatePad_T-a004f7cd

gb2/img/APP/var/lib/NetworkManager/dnsmasq-wlP1p1s0.leases
  HONOR-Pad-X9
```

The tablet MAC addresses are locally administered/randomized. Hostnames, app artifacts, and timing correlations are more reliable identifiers than MAC address alone.

### Aircraft access points

| Dump | SSID | Address | WPA PSK |
|---|---|---|---|
| GB1 | `jet-C1000-V2U-12702` | `10.10.10.5/24` | `12345678` |
| GB2 | `jet-C1000-V2U-12674` | `10.10.10.5/24` | `12345678` |

Configuration paths:

```text
img/APP/etc/NetworkManager/system-connections/jet-C1000-V2U-12702.nmconnection
gb2/img/APP/etc/NetworkManager/system-connections/jet-C1000-V2U-12674.nmconnection
```

The WPA PSK `12345678` was tested and is not the LUKS passphrase.

## 3. `mec` and `mec.crc`

`mec.crc` is plaintext, not encrypted. Both copies contain:

```text
123844de7ba12662c06205a22d04309d  ./mec_tgt_10.03.25
```

It is a stale MD5 sidecar for an earlier filename or version. Root history at `img/APP/root/.bash_history:37-40` records:

```bash
md5sum ./mec_tgt_10.03.25
mv ./mec_tgt_10.03.25 ./mec
mv ./mec_tgt_10.03.25.crc ./mec.crc
mv ./ThunderGaze_3285.gpg ./ThunderGaze.gpg
```

The current recovered GB1 container has a different MD5:

```text
133777b26e9530751c37c339f567b53e  /home/jetson/mec
```

Both `mec` files are 62,914,560,000-byte LUKS2 containers. Their complete 16 MiB header and keyslot areas are byte-identical:

```text
Header SHA256: 1db779bd32305252e979ed0ece9a10f5f77d577f1b4372eddbb05699a0ccb935
UUID:          e3e91452-59dd-41ec-ba8d-89f0950251ec
Cipher:        AES-XTS-plain64
Key size:      512 bits
Data offset:   16,777,216 bytes
Keyslots:      one, slot 0
PBKDF:         Argon2i
Time cost:     4
Memory:        937857 KiB
Threads:       4
AF stripes:    4000, SHA-256
```

The full metadata dump is at:

```text
img/APP/recovery/extracted_ext4/home/jetson/mec.luksDump.txt
```

Multiple sampled ciphertext regions also match. The payload was therefore cloned or closely copied between the two devices. A passphrase recovered for either dump should unlock both.

Argon2 requires about 938 MiB per guess, making blind brute force unattractive. Targeted candidates including the AP password, names, versions, identifiers, UUID, hashes, defaults, IP addresses, empty input, newline, and whitespace did not unlock it.

Successful past operation is proven by `img/APP/home/jetson/resultMapOpen`:

```text
Start mount map
Crypt result: 0
Mount result: 0
Map ready!
```

System logs also record `dm-0` mounting, GPG identifying AES256.CFB data encrypted with one passphrase, and the decrypted ThunderGaze archive being extracted. During shutdown, `blkdeactivate` explicitly unmounts `/home/jetson/map` and deactivates `my_enc_mec`.

## 4. Anti-forensics and residual recovery

The recovered cleanup fragment at:

```text
img/APP/recovery/mec_leads/clean_EPD_autokill_fragment_116238860288.sh
```

contains:

```bash
shred -u /home/jetson/ThunderGaze.gpg
shred -u /home/jetson/thunder_gaze_update.tgz
shred -u /home/jetson/close_mec.sh
shred -u /home/jetson/prepare_tg.sh
shred -u /home/jetson/smartStart.sh
shred -u /home/jetson/autoKill.sh
shred -u /home/videoview/top.log
shred -u /home/videoview/term.log
shred -u /home/jetson/clean_EPD.sh
fstrim /
```

The system logs record failed or partial shred attempts in both dumps, corroborating execution of the cleanup routine.

Deleted-inode metadata was recovered:

- GB1 `smartStart.sh`: inode 3145781, size 452 bytes, former block 19072514.
- GB1 `prepare_tg.sh`: inode 3145782, size 1956 bytes, former block 4126228.
- GB2 `smartStartVXU.sh`: inode 3145979, mode 0755, size 1124 bytes, former block 24165383.
- GB2 `prepare_tg.sh`: inode 3145980, mode 0755, size 1922 bytes, former block 24165384.

The original blocks are now free and contain high-entropy overwrite data consistent with `shred`, so the current script bodies are not recoverable from their original extents.

Both 512 MiB ext4 journals were scanned for:

```text
messageType
smartStartVXU
prepare_tg
ThunderGaze
thunder_gaze_update
update_ep.sh
cryptsetup
passphrase-fd
cookie
```

No `messageType` string or type-10 JSON fragment was present. `cookie` appeared only in unrelated library/system strings. Application TCP payload data was not journaled.

Historical `ThunderGaze.gpg` inode and extent maps survive, including copies of approximately 156 MB and 249 MB, but their mapped data blocks are free and begin with randomized overwrite data rather than OpenPGP headers. They cannot presently be used as passphrase-verification targets.

Other negative persistence findings:

- No disk-backed swap or hibernation image; swap was ZRAM only.
- `/var/lib/systemd/coredump` and `/var/crash` are empty.
- No relevant keyfile, `/etc/crypttab` entry, cron job, timer, udev rule, container secret, audit log, process accounting, or persistent systemd journal was found.
- GPG used `--no-symkey-cache`; `.gnupg` retained no useful secret material.
- EPathfinder connection logs do not retain message payloads.

Useful historical archive names retained in metadata are:

```text
ThunderGaze_3285_VNAV76_NX62_RELEASE.tgz
vfs2BK192ThunderGaze_3285.tgz
ThunderGaze_3285.gpg
thunder_gaze_update.tgz
mec_tgt_10.03.25
```

These names should be searched on controller devices, maintenance systems, removable media, and organizational backups.

## 5. Administrative and provenance leads

`img/APP/var/log/auth.log` contains repeated password-authenticated SSH sessions from `192.168.110.107`. At line 701, an SSH user installs the startup service from the upload directory:

```text
PWD=/home/jetson/upload/etc/init.d
COMMAND=/usr/bin/cp ./initEPF /etc/init.d/
```

This makes `192.168.110.107` the likely administrative/build workstation and a high-value acquisition target. It may retain the original upload package, launcher scripts, encrypted archives, shell history, transfer-client history, or operator documentation.

The same authentication log records password SSH sessions from `10.10.10.112` and `10.10.10.128`, followed by `sudo su`. DHCP evidence associates relevant clients with Huawei/Honor tablet devices. The controller tablet was therefore also used for system administration, further increasing its evidentiary value.

Both systems share the same machine ID and hostname, supporting the conclusion that they were cloned from a common base image. Operational identifiers distinguish them:

| Evidence set | Aircraft/plane ID | EPathfinder | ThunderGaze |
|---|---:|---:|---:|
| GB1 | 12702 | 3794 | 321 |
| GB2 | 12674 | 3815 | 327 |

Separate operational IOCs include:

```text
Telemetry endpoint: 45.134.254.160:5005
Aircraft AP:         10.10.10.5:8052/TCP
Installer service:   TCP 8053
SSID prefixes:       jet-C1000-V2U-
```

## 6. Recommended next actions

### 6.1 Acquire the Honor/Huawei controller

Prioritize a physical and logical acquisition of the identified Honor/Huawei tablet. If it remains live, avoid an unnecessary reboot and follow the appropriate mobile-device isolation and memory-preservation procedure.

Search APKs, decompiled code, `shared_prefs`, SQLite databases, application files, backups, logs, notifications, clipboard artifacts, keyboard artifacts, and RAM for:

```text
10.10.10.5
8052
messageType
"messageType":10
cookie
data
jet-C1000-V2U
prepare_tg
setCodeMessage
```

The controller application may store the code, obtain it from an operator, or include it as a resource. Even if persistent storage is clean, the value may remain in application memory.

### 6.2 Capture an unlock on an isolated forensic clone

Do not power a complete armed airframe. Use cloned storage and isolated bench hardware where possible.

Capture the controller session passively:

```bash
sudo tcpdump -i any -s 0 -w epathfinder-8052.pcap \
  'host 10.10.10.5 and tcp port 8052'
```

Preserve the original PCAP. In Wireshark, use **Follow TCP Stream** and search for `"messageType":10`. The associated `"data"` value should be the exact passphrase. Inspect the reassembled stream rather than individual packets because JSON messages can span TCP segments.

### 6.3 Acquire the administrative workstation

Acquire or search `192.168.110.107` for:

- `/home/jetson/upload` deployment trees or their source archives.
- SSH/SFTP/SCP client history.
- Terminal and shell history.
- Files matching the historical archive names above.
- References to aircraft IDs 12702 and 12674.
- `prepare_tg.sh`, `smartStart.sh`, `smartStartVXU.sh`, or `initEPF`.
- Password managers, operational notes, and controller-application packages.

### 6.4 Locate another encrypted-payload copy

Search backups and removable media for an intact `ThunderGaze.gpg` or earlier `mec` generation. The scripts reused the LUKS passphrase for GPG, so an intact GPG payload could provide an additional and potentially less expensive validation target.

## 7. Conclusion

The surviving local evidence does not contain the literal passphrase, and deliberate shredding plus trimming makes ordinary undelete unlikely to improve the result. The evidence does, however, establish the passphrase's delivery mechanism with high confidence:

```text
Honor/Huawei controller
    -> plaintext JSON over TCP 8052
    -> messageType 10, field "data"
    -> EPathfinder QProcess stdin
    -> /home/jetson/prepare_tg.sh
    -> cryptsetup and GPG
```

The best realistic recovery opportunity is a controller acquisition or passive capture of a normal unlock transaction. The admin workstation at `192.168.110.107` is the next strongest source. The cloned LUKS headers mean that a passphrase recovered through either route should apply to both dumps.