Espilon

Why another serial monitor? screen, minicom, picocom all do the same thing: open a port, show bytes, let you type. That works fine for a quick debug session. It breaks the moment you want to automate anything. No scripting. No pattern detection. No structured output. One port at a time. No exit code based on what the device prints. emon is built around the idea that serial output is structured data, not just text. If your device speaks UART (ESP32, STM32, Arduino, Raspberry Pi, a custom FPGA board, an industrial PLC, a GSM modem), emon works with it out of the box. It watches for patterns, fires hooks, streams JSON, and integrates directly into CI pipelines. ...

Some bugs hide behind clever exploitation. This one is a memcpy with no length check, reachable before authentication, from any BLE radio in range. TL;DR CVE-2026-47773 (GHSA-77v6-cw9f-9whg). A missing bounds check in ArduinoBLE’s ATT write-request handler. When a client writes to a characteristic that requires encryption (the BLEEncryption permission) but the link is not yet AES-encrypted, ArduinoBLE stashes the pending write into a fixed 64-byte writeBuffer inside the global ATTClass object, to replay it once encryption is up. It copies the attacker-supplied value into that buffer with no length check. ...