Fix TLS verification, four out-of-bounds reads, and the firmware-update hang/silent-failure

[dc0sk]

Summary

Two groups of fixes, both found while auditing the codebase for a UI bug (see #29):

1. Five independent hardening fixes — concrete out-of-bounds reads or a disabled security control, not style nitpicks — details and failure scenarios below.
2. A completed fix for the firmware-update feature, which was effectively unusable: it hung indefinitely, and even when unstuck, silently reported a passing integrity check regardless of whether the device actually verified the write.

All are built and verified compiling. The HID read-path fixes and the firmware-update fix were verified against real hardware, not just compiled — see "Test plan" below.

Changes: security hardening

Enforce TLS certificate verification on all network requests.
Every QSslConfiguration built in this codebase (licenseagent.cpp's license/registration traffic, analyzer/updater/downloader.cpp's firmware info/file download) explicitly set QSslSocket::VerifyNone, disabling server certificate verification entirely. A network man-in-the-middle could forge the firmware INFO/VERSION/LINK response and the firmware image the app downloads and offers to flash to the connected analyzer, and could read the user's name/email sent during registration. Removed the overrides so requests use Qt's default (VerifyPeer).

Out-of-bounds stack read of device-supplied HID length.
hidRead() reads a device-supplied length byte (readBuff[1], 0-255) as the loop bound for copying out of a fixed 64-byte stack buffer, with no check against either the buffer size or how many bytes hid_read() actually returned. A device (or firmware bug) reporting a length over 62 causes an over-read of up to ~192 bytes of adjacent stack memory, appended straight into the parsed measurement stream. Clamped the copy length to both the buffer size and the actual read count, and zero-initialized the buffer. Same bug, same fix, in both hidanalyzer.cpp and its hid_analyzer.cpp twin (built on different platforms per AntScope.pro).

Reject BLE notifications shorter than a full packet before parsing.
dataReceived() passed every incoming BLE notification straight to checkCRC()/returnCRC(), both of which index data[BLE_PACKET_SIZE-1] (byte 19) with no length check. In a release build (QByteArray::at()'s bounds assert compiles out under QT_NO_DEBUG) a malformed or malicious BLE peripheral sending a notification shorter than 20 bytes causes an out-of-bounds read. Rejected short packets before they reach any parsing path.

Out-of-bounds read of a short firmware-info response (AA-230).
The probe loop reading the AA-230's firmware-info response gives up after 10 timeouts and falls through regardless of how many bytes actually arrived; only arr.isEmpty() was checked before memcpy'ing sizeof(FirmwareInfo) bytes out of it. A slow, short, or malicious response shorter than the struct causes an out-of-bounds heap read. Now checks the actual length.

One-byte out-of-bounds read in HID firmware-info parsing.
memcpy((char*)&info, &buff[6], 60) on a 65-byte buff reads buff[65], one byte past the end. Clamped the copy length to both the buffer size and the number of bytes actually received by hid_read_timeout().

Changes: firmware-update completion

HidAnalyzer::update() (the HID-based firmware-update path used by the Stick family and others) had three compounding defects that together made the feature both unusable and silently unsafe:

1. Infinite hang entering the bootloader. After sending the RESET command to reboot the device into its DFU bootloader, the app's normal hot-plug detection (searchAnalyzer()/m_devices) is gated behind g_usbOnly and only ever looks for the application-mode VID:PID anyway — it can never find the device in bootloader mode. Nothing else waited for or detected the re-enumeration, so the UI just hung. Added HidAnalyzer::waitForBootDevice(qint64 timeoutMs): a bounded poll of hid_enumerate(RE_BOOT_VID, RE_BOOT_PID), matched by USB serial number (verified to persist across the mode switch against a real capture), that reopens the device and sets m_bootMode.

2. Firmware verification silently always "passed". The write loop only ever read a response after the first chunk (BL_CMD_WRITE); every subsequent BL_CMD_DATA chunk's response was left unread. HIDAPI's background read thread queues unread reports, capped at 30, discarding the oldest — so by the time the final BL_CMD_CHECK was sent, the read queue held nothing but stale OK reports from recent chunks. The "verification" step was reading one of those, not the bootloader's real answer to CHECK, so it reported success unconditionally, and BL_CMD_START (boot the new image) was issued regardless of whether the flash actually verified. Fixed by reading and checking the response after every chunk, aborting immediately on BL_CMD_ERROR — this also fixes the stale-read issue as a direct consequence, since the queue no longer has a chance to accumulate unread entries.

3. hid_write() failing outright for the RESET report on Linux. analyzer/usbhid/hidapi/linux/hid.c's kernel-driver-detachment code is gated behind #ifdef DETACH_KERNEL_DRIVER, which AntScope.pro never defined. The kernel's usbhid driver auto-binds normal-mode HID interfaces on Linux; without detaching it first, libusb_claim_interface() can still nominally succeed, but a subsequent interrupt-OUT hid_write() — such as the RESET report needed to enter the bootloader — can fail outright. Defining DETACH_KERNEL_DRIVER resolved this, confirmed on real hardware.

A new unit test harness (tests/hid_update_mock/) drives the real, unmodified update() against a software-simulated bootloader modeling the real protocol (same command bytes, chunk size, and ACK value as a genuine captured update session), using a small ANTSCOPE2_UNIT_TEST-gated seam (setTestHidDevice()) that's inert in the shipped app. Four scenarios, 20 assertions, covering a clean update, a mid-stream device error, a failing integrity check (the exact defect (2) closes), and a firmware size that isn't a multiple of the 48-byte chunk size. The harness's own sensitivity was verified by deliberately reverting the fix and confirming the same test then correctly fails.

README update.
Windows still said Qt5 (the project moved to Qt6), and Linux said "to do" despite qmake6 building this cleanly and two AUR packages (antscope2, antscope2-git) existing and being actively maintained. Updated both, with real build instructions and links to the packages.

Test plan

• Builds clean (Qt 6.11, Linux)
• Connected a real RigExpert Stick 500 and ran a continuous sweep after the HID read-path fix, confirming normal measurement data is unaffected
• Firmware-update fix verified end-to-end on real hardware (a RigExpert Stick230): recovered a unit stuck in the DFU bootloader, and separately performed a full normal-mode firmware update (RESET → re-enumerate → write 226,448 bytes in 4,718 chunks → passing CHECK → START), both completing successfully with no BL_CMD_ERROR
• tests/hid_update_mock/: 4 scenarios, 20 assertions, all passing; sabotage-verified (reverting the fix makes the relevant assertion correctly fail)
• Firmware update / license-registration flows (the TLS fix) not re-tested against a live server from this environment — the change is a straight removal of an explicit VerifyNone override, restoring Qt's documented default behavior

🤖 Generated with Claude Code