Conversation

Notices

1. Embed this notice
   Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Monday, 02-Dec-2024 01:34:11 JST Ryan Castellucci :nonbinary_flag:

   I was able to emulate a held button on the ventilation system interface. Increasing the delay between messages to 20ms did it. Spamming zero bytes between messages does not work.

   It seems like the unit must expect alternating valid messages and empty serial receive buffers, and I hate it. Just. Why.

   • Embed this notice
     John Ripley (jripley@mastodon.social)'s status on Monday, 02-Dec-2024 03:33:26 JST John Ripley

     in reply to

     @ryanc Rule of thumb is the firmware in any large appliance was written by a hardware engineer, who generally stop at “it works now”.

     This reminded me of working on ID over HDMI, which uses I2C. Turns out for a large fraction of devices, if you spam I2C, e.g waiting for boot, their single work loop never gets around to doing anything other than I2C, including booting. You need to leave arbitrary gaps like you did there :(

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Monday, 02-Dec-2024 03:33:26 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • John Ripley

     @jripley What confuses me is that this must have been a tremendous pain for whoever wrote the firmware for the terminal I'm emulating, which is a first party accessory

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Monday, 02-Dec-2024 04:55:14 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • John Ripley

     @jripley thing is, the timing seems really tight. Too fast, and it doesn't recognize "button held". Too slow, and it thinks the button is being mashed repeatedly.

   • Embed this notice
     John Ripley (jripley@mastodon.social)'s status on Monday, 02-Dec-2024 04:55:15 JST John Ripley

     in reply to

     @ryanc I imagine it's like this (sadly) common setup:

     * Receiver is a for() loop, either pulling bytes out of a UART, or executing a command.
     * UART is either a 1 byte FIFO, or emulated GPIO.
     * While executing a command, UART is dropped.
     * Accessory, vice versa situation.
     * This all "works" because the protocol will have a "documented" AC timing spec: T_inter_command_gap>=20ms.

     There's nonsense like this common in devices everywhere, but to be fair it sure makes things cheaper.