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

[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]

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. 

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).

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.

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?

[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. 

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).

Fair enough, although the QingPing does that too:



I'm not affiliated with them in any way, just had one for ages and very happy with it, it's still actively supported and updated unlike a lot of the others.

[LooseJunkHater]

Fair enough, although the QingPing does that too:

I'm not affiliated with them in any way, just had one for ages and very happy with it, it's still actively supported and updated unlike a lot of the others.

I'm not really interested in purchasing another CO2 monitor when I have this device already. At worst, I simply connect the devices sensors to an ESP32, omitting the front LED display.

[LooseJunkHater]

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. 

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).

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.

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?

Last bump, just so that maybe someone smarter than me can answer some of these so I can learn a bit?

[kloetpatra]

First of all, I would recommend that you reverse engineer the interfaces to the LED display and the CO2 sensor. Connect your ESP32 and call it a day. If necessary, build yourself a board with an LED matrix. It's all easier than what you have in mind.

I'm sorry if I offend you, but even if you are good at acquiring knowledge, this seems a bit too big. Even someone who is experienced could need hundreds of hours for such a project. For someone inexperienced, it could take several thousand hours or simply be impossible.
Yes, SWD stands for “Serial Wire Debug”. You need a debug probe. It doesn't matter which one. You could use OpenOCD as software. The debug interface could be locked. In this case it will be much more challenging. Some STM32s are susceptible to voltage glitching attacks to bypass the lock. If the flash has read out protection, this is another hurdle.

If you have managed to read out the firmware, you will need to perform a static firmware analysis. Ghidra, IDA Pro or Radare2 are the tools for this. For these tools alone you need considerable experience. You need expertise in ARM assembly to be able to understand the code. These tools will not simply decompile all this into readable C code. You will have a bloat of mysterious functions and variables without a meaningful name. For register accesses, you need corresponding CMSIS SVDs to be able to interpret them. You need to be able to recognize and analyse what a function does based on its structures/flow. It could also be that the API key would only be set by the external server and is not already in memory. It could be encrypted. But that doesn't matter, because you could now change the firmware to your liking. Now repeat this serveral times, because you found out it was the wrong MCU and it just handles button presses.

[LooseJunkHater]

First of all, I would recommend that you reverse engineer the interfaces to the LED display and the CO2 sensor. Connect your ESP32 and call it a day. If necessary, build yourself a board with an LED matrix. It's all easier than what you have in mind.

For the LED display, do you even think it's worth trying to sniff the communication line to the second STM32F103 MCU, to try to figure out the communication used for driving the display? It's a 10p connector, but I do wonder whether some of those pins are being used for the temp/humidity sensor also located on the board? Or would trying to sniff the communication and decode it, be incredibly difficult? I don't even know how I'd determine whether it's using a standard communication protocol, that I could instead use a ESP32 to send to the second STM32F103 MCU.

I'm sorry if I offend you, but even if you are good at acquiring knowledge, this seems a bit too big. Even someone who is experienced could need hundreds of hours for such a project. For someone inexperienced, it could take several thousand hours or simply be impossible.
Yes, SWD stands for “Serial Wire Debug”. You need a debug probe. It doesn't matter which one. You could use OpenOCD as software. The debug interface could be locked. In this case it will be much more challenging. Some STM32s are susceptible to voltage glitching attacks to bypass the lock. If the flash has read out protection, this is another hurdle.

Absolutely no offence taken, I appreciate your realistic time-estimated response. It just means that I can instead focus on other projects instead, using my time wisely, and slowly building up my knowledge over time.   

If you have managed to read out the firmware, you will need to perform a static firmware analysis. Ghidra, IDA Pro or Radare2 are the tools for this. For these tools alone you need considerable experience. You need expertise in ARM assembly to be able to understand the code. These tools will not simply decompile all this into readable C code. You will have a bloat of mysterious functions and variables without a meaningful name. For register accesses, you need corresponding CMSIS SVDs to be able to interpret them. You need to be able to recognize and analyse what a function does based on its structures/flow. It could also be that the API key would only be set by the external server and is not already in memory. It could be encrypted. But that doesn't matter, because you could now change the firmware to your liking. Now repeat this serveral times, because you found out it was the wrong MCU and it just handles button presses.

Honestly thought that extracting the firmwares may just spit out human-readable code. I knew that it was unlikely but still a possibility, but I appreciate knowing that it's sadly not that easy. All of this goes way, way-above my current knowledge.

Therefore, I guess I'll simply go about desoldering all of the MCU's, finding out which MCU's each of the sensors connect to (CO2, temp/humidty, VOC's). I need to still determine the model of the temp/humidity sensor, but I don't think that'll be very difficult.

_____________________________________________________________________________________________

As a final question (in addition to the one above, about sniffing the second STM32F103 MCU's communication line), does anyone know what exactly the metal can is, labelled "heater", visible on page 3 of the FCCID page. I think it has 3 pins? I'm not familiar with that package design, and I don't recall seeing any labels/markings on the metal can.

Thanks!

[kloetpatra]

For the LED display, do you even think it's worth trying to sniff the communication line to the second STM32F103 MCU, to try to figure out the communication used for driving the display? It's a 10p connector, but I do wonder whether some of those pins are being used for the temp/humidity sensor also located on the board? Or would trying to sniff the communication and decode it, be incredibly difficult? I don't even know how I'd determine whether it's using a standard communication protocol, that I could instead use a ESP32 to send to the second STM32F103 MCU.

Probably not all pins are used. You can easily trace the connections with a multimeter. Hook up a logic analyzer and check for standard protocols. It's likely that they used SPI or I²C. Shouldn't be that hard to find out.

As a final question (in addition to the one above, about sniffing the second STM32F103 MCU's communication line), does anyone know what exactly the metal can is, labelled "heater", visible on page 3 of the FCCID page. I think it has 3 pins? I'm not familiar with that package design, and I don't recall seeing any labels/markings on the metal can.

It's a VOC sensor, probably SB-AQ1-06 or SP3S-AQ2-01. The marking should be on the side on the metal.
https://gvzcomp.it/products/gas-sensors/sb-aq1-06
https://gvzcomp.it/products/gas-sensors/sp3s-aq2-01

[LooseJunkHater]

Probably not all pins are used. You can easily trace the connections with a multimeter. Hook up a logic analyzer and check for standard protocols. It's likely that they used SPI or I²C. Shouldn't be that hard to find out.

I know a tiny bit about SPI and I2C, specifically about how many pins are normally involved and clock synchronization, but I've yet to measure or mess around with it. If it is SPI/I2C, will I require some sort of special driver/library, similar to how the super cheap SSD1306 OLED displays require a library to be communicated with? Is this something relatively simple to reverse engineer/determine? I know my Siglent 1204X-E oscilloscope can read some sort of communication and decode it (I think both SPI, I2C, CAN bus, and a few others), so would this be "good enough" to try to incorporate the original LED display (of the Awair device) with something like an ESP32?

It's a VOC sensor, probably SB-AQ1-06 or SP3S-AQ2-01. The marking should be on the side on the metal.
https://gvzcomp.it/products/gas-sensors/sb-aq1-06
https://gvzcomp.it/products/gas-sensors/sp3s-aq2-01

Oh wait, really? I thought the VOC sensor was the large black/silver box, shown on page 1 (silver box) and page 5 (black box, with a hole). I guess this is instead detecting particle sizes (ex. PM10), and not volatiles?

Thank you all, for all the help thus far!

[LooseJunkHater]

I decided to partially reverse-engineer that front LED display board as I really love it, and am kinda shocked that it's NOT A 2-LAYER BOARD, but instead likely a 4-layer (or more?) board. Sharing all of this information for anyone who may come across this thread in the future.

The temp/humidity sensor is an SHT30, being powered by the 3.3v line, and the SDA + SCL pins actually goes to the main-board, and is (likely) NOT sensed by the secondary STM32F103.

Attached is an image of the rough pinout of the connector. Sorry about the horrible colour choice + size; I wasn't expecting to share this initially, but think others may find it beneficial.

In the close-up image is another unknown IC, labelled "U3", which also connects to the SDA + SCL lines going to the main board. I don't think it's a programmable LED because when I power-up the PCB, it does not light-up (there's a different blue indicator LED on the PCB which lights up). Possibly for ambient light detection or IR signal transmit/receive? Not entirely sure, as there's no information on the product box about this function.

__________________________________________________________________________________________________________________________________________

My next goal is to try to sniff out those Pin 16 + 17 (USART2_TX , USART2_RX), and pin 42 + 43 (USART1_TX , USART1_RX) of this MCU and see what information I can find, if anything useful.

Looking through the datasheet, there is also "USART3" pins, as well as "UART4" + "UART5", but I'd imagine those were reassigned or simply not used. Won't bother looking at them.