Electronics > Microcontrollers

MCU API Keys Extraction, Decryption, or Replace with ESP32?

(1/3) > >>

LooseJunkHater:
FCC Page.
Internal Photos of the Awair device.

I recently got an old Awair "Smart Air Quality Monitor" (internet of things device) which has a NDIR CO2 monitor (T6703). The cloud servers for the device have been shut down for a few years and that was the only "official" way to obtain a local API key, for use with HomeAssistant. It seems that with the API key enabled, it simply opens an HTTP server on the Awair device. I'm wanting to hack this device and get it working (if possible/reasonable).

The device has multiple MCU's, all of which have the option for built-in flash memory:
- TI CC2540 (possibly only used for Bluetooth?)
- STM32F103 (ARM M3; ?main MCU?)
- STM32F103 (possibly only being used to multiplex-drive the front LED display?; image. Also visible on page6 of the internal photos)
- EMW3165 (Arm M4; possibly only used for WiFi?)
- C2369Z (unknown 8pin SMD I.C near the ?main MCU?, possibly flash?)

I'm wondering how feasible/easy it would be to extract the API key (IF it's even stored internally, which I have no idea), speak to the device via a Serial connection (or similar? There's many probe-points and jumpers on the PCB), or if I should instead just remove all of the MCU's and use a single ESP32 MCU. I know a tiny bit about logic analyzers but don't yet feel comfortable exploring that path, plus it just doesn't seem worth the time effort, when I can just get an ESP32 MCU to easily communicate with the NDIR CO2 sensor.

Thanks

hans:
I would replace it with an ESP32, personally.

I'm a bit shocked this device has 4-5 MCUs inside it. Sure, bluetooth, wifi, display and main MCU. But it still makes it harder to pick the right one which is taking care of the HTTP stack and API handling.

You can always take a gamble to see if they have read-protected these chips at all by hooking up a SWD probe, but I doubt it.
Afaik the STM32F103 is a vulnerable chip to various glitching attacks in order to extract the firmware. However, that part has fairly small FLASH, so I wouldn't rule it out that a large part of the HTTP handling is done on the EMW3165. I've no idea whether there are attacks for this chip. I guess you could try, but it probably goes a lot farther than probing things with a serial port or hooking up a LA.

For what it's worth: there is quite a common IKEA hack for the Vindriktning PM2.5 monitor (not the newer VINDSTYRKA).  I connected a ESP32 on the transmit pin of the air quality sensor, uploaded a Tasmota image that sniffs the sensor data traffic, and pushes it to a local MQTT server. The original electronics were left as is.

Perhaps there is a similar approach for this CO2 sensor as well. With a bit of luck you could see if this device is still requesting sensor data periodically even though its API is down or not set up. The CO2 sensor looks to be supported in Tasmota over I2C, but I don't know about the specifics whether its initiating readouts or can also act as a sniffer. If for the latter, that would be perhaps one of the lowest effort solution going forward.

Siwastaja:
Design your own around whatever ESP or Arduino + a CO2 sensor module. It is not unlikely that some existing example project can be found (or even generated by ChatGPT). It makes very little sense trying to reverse-engineer a seriously overengineered piece of IoT junk when what it really does is something so trivial.

5U4GB:
It depends whether the OPs main goal is to have an air quality monitor or to tinker with an IoS device and reverse-engineer it.  If the former then I'd go with the QingPing monitor which has MQTT support and integrates into HA through that.

One thing to note with AQMs is that they seem to be a cursed product type, virtually every one of them gets discontinued after a couple of years with the user left with no recourse: Air Mentor, BlueAir, FooBot, etc, all gone.  However the Awair Element at least still seems to be available.

LooseJunkHater:

--- Quote from: 5U4GB on January 20, 2025, 01:36:30 pm ---It depends whether the OPs main goal is to have an air quality monitor or to tinker with an IoS device and reverse-engineer it. 

--- End quote ---

The rationale for attempting to extract the API key is to be able to utilize the front LED display of the device and use it as an actual air quality monitor. I really like the aesthetic of the front LED display, especially if they can be set to display information (ex. constantly displaying the most up-to-date CO2 readout).


--- Quote from: hans on January 19, 2025, 05:20:55 pm ---You can always take a gamble to see if they have read-protected these chips at all by hooking up a SWD probe, but I doubt it.
Afaik the STM32F103 is a vulnerable chip to various glitching attacks in order to extract the firmware. However, that part has fairly small FLASH, so I wouldn't rule it out that a large part of the HTTP handling is done on the EMW3165. I've no idea whether there are attacks for this chip. I guess you could try, but it probably goes a lot farther than probing things with a serial port or hooking up a LA.

--- End quote ---

SWD probe I assume stands for "Serial Wire Debug (SWD)"? Would this be something like the CH340 or FTDI FT232?

I'm also aware that many of the sensors inside this device can likely be incorporated into ESPHome fairly easily, such as the T6703 CO2 sensor, which is partially why I'm leaning toward the ESP32 route. But that front-panel LED display is so pretty... Uh.

I guess an additional question, say I *could* extract the firmware for all the MCU's, the API key is stored internally in the firmware (what are the chances of the API key being stored internally?), how exactly would I determine what the API key is from the firmware dumps? I'd imagine this would be quite difficult to extract, as it likely wouldn't be human-readable?

Navigation

[0] Message Index

[#] Next page