Reverse Engineering of a Not-So-Secure IoT Device

The Internet of Things is coming! It started out as overused marketing hype with no real use case (who needs internet-connected fridges? And who wants the internet-connected toilet paper?).

New ‘things’ start to pop up, whether useful or not: from smart bulbs (Philips Hue), thermostats (Nest), smart TVs (Samsung and others), to voice assistants (Alexa, Cortana, Google). You might even have installed one of these, right? What about temperature and humidity sensors? There is probably nothing wrong with that?

But what would you think if one morning you found a strange, unknown device installed under your working desk, connected to the cloud and Internet?

IoT device attached under a working desk

Preface

This article uses an example of an IoT monitoring/sensor device. The device had been deployed in shared rooms (e.g. meeting rooms) as well placed under the desk of individual employees. This article describes the investigation and analysis of that device, as well as the possible problems and proposed improvements.

The goal of this article is to learn from that case, not to blame the employer who installed the device or the company (a startup) who developed and produced the device. That’s why both names are not disclosed, and any references, logos, login data, or passwords are blurred/removed in this article.

Suggestions, ideas, or lessons-learned are marked like this in the article which can serve as a check list if you plan to deploy IoT devices.

While preparing this article, the company producing the device has been contacted and we discussed our findings with them, so they have an opportunity to provide feedback or take action. I would like to thank them for their openness and willingness to listen.

Note that this article describes and shows reverse engineering practices with a research and educational goal in mind. Doing reverse engineering for anything other than that might be prohibited by law or license agreements.

A Strange Monitoring Device?

So, what you would think if one morning, you found an unknown device under your desk?

Sensor under a desk

You probably should be concerned, especially if this is a surprise.

Planning for rolling out such a device in work areas, do not rely on intranet communication only, as this will not reach everyone. To avoid concerns, communicate directly with employees and groups (meetings, face-to-face communication, email). Put flyers/posters in areas where monitoring devices will be installed. Consult the law and the employee representation in advance. Think about what the perception (“internet device is spying on me!”), not the reality (“simple temperatur sensor”) of such a device might be.

The device was attached with magnets to the desks, so it was easy to remove it and have a closer look:

IoT device that had been placed in meeting rooms and under employee desks

The way the device is mounted makes it easy to move, to remove, or place somewhere else. If a device is supposed to monitor a specific location, as in this case, it should be mounted in a way that it cannot be moved/removed.

Open it Up

The device with a diameter of 64 mm has two magnets used to attach it to the bottom side of the desk. It is very easy to remove the metal part (no screws used):

Device  cover with magnets

The hole in the middle probably can be used with a screw or similar to attach it.

Metal cover inside

There is no physical protection to protect opening the device. Having physical access to a device makes it easy for an attacker. A device should have a tamper detection, and in case of a tamper, it should take appropriate actions, e.g. transmit a tamper notification and/or erase the secret keys. That would make attacking a device harder.

The device is using a lithium battery (only one installed):

According the vendor of the device, two batteries get installed if the device is supposed to run for a longer period of time. In this case, it was supposed to be installed for about 6 months.

Device battery compartment

The ‘+’ and ‘-‘ signs for the battery are rather hard to read, depending on the light conditions. It happened to me that I inserted the battery the wrong way.

A sticker inside the battery compartment has an ID number and QR code on it; the same code is on a sticker on the outside. There are also 7 small holes on the outside (breathing holes to allow air circulation or may be used for a microphone?).

Device ID sticker

The number of the stickers is the ID used for register/login the device (found out later). With such a sticker outside, a possible attacker does not even need to open up the device to get that ID.

The central part of the device is the PIR sensor:

Device inside top side

The PIR sensor is used to detect movement, something which is used to turn on a light or similar. There is also a Microchip wireless communication module on it with more electronics. The PIR sensor has a detachable (3D printed?) cover cape, which is used to limit the sensor range:

Detachable PIR cover

The analysis of the board component is revealed in following components:

• Microchip RN2483 LoRa module with antenna
• STM32L031F6P6 ARM Cortex-M0+ microcontroller
• AMSYS HTU20 I2C humidity/temperature sensor
• RGB LED indicating connection status
• Unknown device 8743 (I2C), probably a magnetometer/accelerometer

To make it harder for a potential attacker or attempt of reverse engineering, remove the ID’s on the devices used.

Board overview

The AMSYS HTU20 temperature/humidity sensor on the board is not the version with a filter membrane. Because the enclosure of the device is not completely closed, it is possible that dust will cover the sensor. In such a device, the sensor with a filter membrane should be used:

Filter Membrane (Source: Amsys.de)

Further analysis showed that the 8743 device seems not to be used by the current firmware, as there is no I2C communication with it.

8743 IC (unknown purpose/device)

The fact that the PCB below the sensor has a keep-out area would support the magnetometer assumption?

If this would be an magnetometer, attaching strong magnets on the back of the device is not a good idea.

Bottom side of 8743

The company confirmed that this is a accelerometer/magnetometer sensor, and it is currently not used.

According to a reader, this sensor is a LIS3DH from STMicroelectronics.

Who Made It?

The metal cover has a name (company logo/name) on it:

Logo

Google name/image search reveals the company behind this device. The examples on the website shows that these devices are used for office space monitoring:

Office space monitoring

The marketing material on that website seems to indicate that it is possible to monitor an individual seat with a device.

The law in many countries is very strict if electronic devices are used to monitor a workplace. The information (or lack of information) what a device can and cannot do very likely will cause lots of employee concerns.

They show the use case as well as monitoring-free seats in a cafeteria or library.

Data Privacy and Legal Concerns

Data privacy and security of IoT devices should be a big concern, and it is even for shared workplaces or rooms. While a cafeteria or meeting rooms seem to be unproblematic, the law (at least in Switzerland) is very specific about this (article in German, French and Italian):

Unzulässige Überwachung am Arbeitsplatz

In short: Any electronic surveillance of workplaces is not permitted. There is a special brochure (German) that provides more details. In any case, it has to respect privacy and it has to be proportional to the goals. For example, it can be appropriate to monitor with cameras the customer area on a bank to prevent a robbery, but it won’t be OK to monitor the employee at the bank desk. If there special needs (safety, high-value assets), then the implementation has to be done in a way that it does not violate the law.

Consult the law of your country about what is permitted and what not. Openly inform and consult all affected employees in advance. Inform about what data gets collected, if and how this relates to a person or group, how the data is processed, where it is stored, and how long the data will be stored.

Interestingly, the company video leads us to believe that their solution is able to monitor audio (noise?) and ambient light level, beside of presence (PIR) and temperature/humidity (for which there is a sensor on the board). So, could this device even record audio and transmit to the Internet? We have to find out…

Marketing video

Marketing material might not reflect the reality. Actual implementation might not be the same originally planned (and what might be in the marketing collaterals). Frequently check your marketing collaterals and information if they could raise privacy concerns. Remove/change material which is not accurate.

At least for myself, I get seriously concerned if the device can record images or voice and is connected to the Internet. As soon data can be used to track a person without that person consent, this is (to my knowledge) illegal in many countries.

Demo Site

The sensor company web site offers a demo:

Demo site

Check that ‘demo’ URL; do you recognize something special?

There is a ‘cust‘ for ‘customer in it. Looking at the company website, there are customer names listed. With a bit of social engineering, it is possible to get a login token to the system, simply changing that URL: I have to know the email address (who most likely would use that system in that company?) and then be able to intercept that email (not easy, but certainly, for real hackers, possible).

Log In Through Social Engineering

According to the company, that portal is supposed to be used by every employee of a customer. That would actually be a good thing: transparency about what data is collected. But this was not the actual case, so something might have been configured wrongly.

Tests showed that it was possible to request such a login token knowing an email address (e.g. facility team member, not every email address worked).

Depending on the data, it might not be a good idea to provide such a login site. Depending on the back-end implementation, several types of attacks are possible (denial-of-service or stealing possibly the data itself).

Device Connecting to the LoRaWAN

After it was clear that the device is using the LoRaWAN network, the next step was to check if a gateway can pick up traffic. And indeed, this is the case:

Device Connecting to LoRaWAN with app eui and dev eui

The dev eui (Device EUI) used matches the ID, which we have seen on the sticker on the outside and inside the battery compartment. The app eui (Application EUI) is visible during the connection phase. What is missing is the application password (App Key)? We will find this out later.

Everone can setup a LoRaWAN gateway and intercept traffic (see “Contributing an IoT LoRaWAN Raspberry Pi RAK831 Gateway to The Things Network"). Knowing the device eui allows capture that network traffic when listening while the device is registering to the network. With that information, the attacker cannot decrypt the payload, but he sees the activity of the device. Better not to make the device EUI accessible to an attacker.

UART

The UART Tx and Rx lines between the microcontroller and LoRa transceiver are easily accessible:

Rx and Tx lines

Connection settings are 57600 baud, 1 stop bit and no parity. Setting up the Saleae Logic:

Analyzer settings

This is the SysReset:

SysReset

The interesting part is where the deveui, appeui, and finally, the appkey gets transmitted: all in clear text:

Setting deveui appeui and appkey

The complete initialization sequence is listed below:

sys reset
mac pause
mac set ch dcycle 0 900
mac set ch drrange 0 4 4
mac set ch status 0 on
mac set ch dcycle 1 900
mac set ch drrange 1 4 4
mac set ch status 1 on
mac set ch dcycle 2 900
mac set ch drrange 2 4 4
mac set ch status 2 on
mac set ch freq 3 867100000
mac set ch dcycle 3 900
mac set ch drrange 3 4 4
mac set ch status 3 on
mac set ch freq 4 867300000
mac set ch dcycle 4 900
mac set ch drrange 4 4 4
mac set ch status 4 on
mac set ch freq 5 867500000
mac set ch dcycle 5 900
mac set ch drrange 5 4 4
mac set ch status 5 on
mac set ch freq 6 867700000
mac set ch dcycle 6 900
mac set ch drrange 6 4 4
mac set ch status 6 on
mac set ch freq 7 867900000
mac set ch dcycle 7 900
mac set ch drrange 7 4 4
mac set ch status 7 on
radio set sf sf8
radio set cr 4/7
mac set retx 5
mac set deveui 0000XXXXXXXX566C
mac set appeui 70B3XXXXXXXX063C
mac set appkey 71803107XXXXXXXXXXXXXXXX7ed71a9f
mac save
mac resume
sys reset
mac pause
mac set ch dcycle 0 900
mac set ch drrange 0 4 4
mac set ch status 0 on
mac set ch dcycle 1 900
mac set ch drrange 1 4 4
mac set ch status 1 on
mac set ch dcycle 2 900
mac set ch drrange 2 4 4
mac set ch status 2 on
mac set ch freq 3 867100000
mac set ch dcycle 3 900
mac set ch drrange 3 4 4
mac set ch status 3 on
mac set ch freq 4 867300000
mac set ch dcycle 4 900
mac set ch drrange 4 4 4
mac set ch status 4 on
mac set ch freq 5 867500000
mac set ch dcycle 5 900
mac set ch drrange 5 4 4
mac set ch status 5 on
mac set ch freq 6 867700000
mac set ch dcycle 6 900
mac set ch drrange 6 4 4
mac set ch status 6 on
mac set ch freq 7 867900000
mac set ch dcycle 7 900
mac set ch drrange 7 4 4
mac set ch status 7 on
radio set sf sf8
radio set cr 4/7
mac set retx 5
mac resume
mac join otaa

There was the concern that the allowed LoRaWAN and TheThingsNetwork allowed duty cycle was overused. The data showed that (unlike other LoRaWAN devices) this one is clean and a good example using shared network bandwidth.

Below is a snapshot of data transmission to the transceiver, which will build a LoRaWAN data packet:

Data transmission

Using an external transceiver like this one from Microchip is problematic, as all the access information (app eui, device eui and application password) are transmitted in clear text. Having physical access to the device and UART lines provides an easy attack vector. Better use a different transceiver with encryption, or mechanically protect the UART lines.

I2C Communication

The I2C communication to the temperature/humidity sensor is easy to capture with a logic analyzer.

Probing with Saleae Logic

The logic analyzer data shows that it initializes the HTU20 sensor, but not that accelerometer/magnetometer. And after reading that sensor data, it sends a payload to the LoRaWAN.

Intercepting and Decrypting Messages

With knowing the Device EUI, the Application EUI, and the (not so secret) App Key, it was easy to set up a ThingNetwork Device that gets all the traffic:

Spoofed TheThingsNetwork Device

Below the activation frame data:

Device activation frame

The next step is to create a new fake application in TheThingsNetwork:

Adding application

In the new application, use the App EUI we have retrieved from the device. For this, we delete the automatically generated one and add the one from the device:

Changing App EUI

Then, register the new device with the retrieved Device EUI and App Key:

Register new device

I can do this for several devices. And voilà: I’m getting the payload data and it is now encrypted on the application side:

Device data

As seen above, the devices send a 14-byte payload right after connecting to the network, followed by a 21-byte payload. Further payload packets are (mostly) 5-bytes long. To save battery time, the sensor sends data when it detects a PIR movement.

LoRaWAN Gateway

When looking at the decoded LoRaWAN payload, it showed that it was picked up by multiple gateways. Knowing that the employer had its own LoRaWAN gateway, wondering why it was picked up by that many gateways?

It turned out that with the installation of the sensor nodes, multiple extra gateways were installed, even if not necessary because the site already had a multi-channel gateway available. The extra gateways were installed on different floors in different buildings:

Installed extra LoRaWan Gateway

If installing and deploying IoT devices, carefully check/measure the installed infrastructure to avoid duplication of access points. Facility management might not be aware of all infrastructure available. For TheThingsNetwork, consult the public network access point map.

Debug

On the bottom side, there is a DFU (Device Firmware Update) connector to update the firmware of the Microchip RN2483A module:

DFU Connector

More interesting is the other connector near the temperature/humidity sensor, which connects to the STM32:

Bottom side with MCU Debug Connector

The pins are not to the ‘standard’ Tag-Connect connector we have on the tinyK22, so we had to patch the pins:

JTAG Header Pins

With this knowledge, a debug connection can be established!

Don’t make the debug pins obvious and don’t use standard connectors. Completely disable debug access in the final firmware. It is still possible to make firmware upgrades with a secret and secure firmware upload.

Reading the Firmware

The next step: Reading out the full device with the SEGGER J-Link and store it in a file. For this, a SEGGER J-Link Flasher has been used, but any other J-Link would do it too.

J-Link to read out the firmware

Obviously, the device is not secured and makes it easy to get all the firmware, so flash protection seems not to be enabled.

If a device like this has not enabled the ‘read-out-protection’ (see “Preventing Reverse Engineering: Enabling Flash Security“), it allows an attacker to read out the firmware. Not only this: it can clone/copy the firmware and clone the device, for example sell it as a pirate product. The used STM32 device offers three different readout protections (RDP (Read Out Protection), PcROP (Proprietary Code Read-Out Protection) and protection against unwanted write/erase operations). Check your device for similar protection features: every serious product should use it.

Reading the Flash of the STM32L031F6

Connection and read-out have to be done right after power-up, as the application seems to re-mux the JTAG/SWD pins after connecting to the network.

Connecting ...
 - Connecting via USB to J-Link device 0
 - J-Link firmware: J-Link ARM / Flasher ARM V4 compiled Apr 18 2019 16:17:53
 - Device "STM32L031F6" selected.
 - Target interface speed: 4000 kHz (Fixed)
 - VTarget = 2.927V
 - Found SW-DP with ID 0x0BC11477
 - STM32 (connect): Can not attach to CPU. Trying connect under reset.
 - Found SW-DP with ID 0x0BC11477
 - Found SW-DP with ID 0x0BC11477
 - Scanning AP map to find all available APs
 - AP[1]: Stopped AP scan as end of AP map has been reached
 - AP[0]: AHB-AP (IDR: 0x04770031)
 - Iterating through AP map to find AHB-AP to use
 - AP[0]: Core found
 - AP[0]: AHB-AP ROM base: 0xF0000000
 - CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
 - Found Cortex-M0 r0p1, Little endian.
 - FPUnit: 4 code (BP) slots and 0 literal slots
 - CoreSight components:
 - ROMTbl[0] @ F0000000
 - ROMTbl[0][0]: E00FF000, CID: B105100D, PID: 000BB4C0 ROM Table
 - ROMTbl[1] @ E00FF000
 - ROMTbl[1][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
 - ROMTbl[1][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
 - ROMTbl[1][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
 - Executing init sequence ...
    - Initialized successfully
 - Target interface speed: 4000 kHz (Fixed)
 - J-Link found 1 JTAG device. Core ID: 0x0BC11477 (None)
 - Connected successfully
Reading entire flash chip ...
 - 258 sectors, 2 ranges, 0x8000000 - 0x8007FFF, 0x8080000 - 0x80803FF
 - Start of preparing flash programming
 - End of preparing flash programming
 - Blank checking 0x08000000 - 0x08007FFF
 - Blank checking 0x08080000 - 0x080803FF
 - Start of restoring
 - End of restoring
 - Target memory read successfully. (33792 bytes, 2 ranges) - Completed after 0.308 sec

After inspecting the image: the device EUI, the app EUI, and the application key are stored in plain text at the end of the image:

EUI and Keys in binary

It is always a bad idea to store account/access information/password as clear string text in a binary. Just don’t do that.

That binary can be stored as S19 (S-Record file) or plain bin file. The S19 file has been used to analyze the memory map (where is data/code in the address map).

The SRecord utility has been used to convert the files and to map out address ranges, or to convert the S19 into a binary file:

srec_cat readout.s19 -o s19tobin.bin -binary

Vector Table

The binary file can be disassembled:

And it provides very useful information about the application entry point and the vector table:

Vector Table with Disassembly

Debugging With GDB

Debugging works with running the JlinkGDBServer.exe and connecting to the STM32L031F6 target CPU:

J-Link GDB Server Settings

With this, I can connect to the microcontroller:

GDB Server waiting for connection

To debug it, I can use the ARM gdb connecting to the microcontroller. I’m successfully using the following version:

C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin\arm-none-eabi-gdb.exe

From gdb, connect to the target:

(gdb) target remote localhost:2331

With that connection, I can halt the processor, inspect the memory, and registers:

(gdb) monitor regs

Haltet Target Showing Registers

Debugging With Eclipse

It works very similar and even easier with Eclipse. These are my settings in Eclipse:

Eclipse Debug Configuration

Eclipse Launch Configuration Startup Settings

That makes it very convenient to inspect the vector table and debug the startup code:

Debugging Startup Code

Reverse Engineering the Firmware

The next step is to understand how the firmware works. With the GNU objcopy, it is possible to transform a binary file into a standard ELF/Dwarf file (see Converting a Raw Binary File into an ELF/Dwarf File for Loading and Debugging), which then can be processed by other tools to disassemble or to debug:

"arm-none-eabi-objcopy" -v --input-target=binary --output-target=elf32-littlearm s19tobin.bin output.elf

The STMCube tools were used to track the STM32 pin muxing:

Completing the Pin Muxing

During debugging, the Eclipse peripheral viewer is very helpful:

pin muxing

Stepping through pin initialization in main() revealed the pin assignments from the above picture, e.g. for GPIOA and GPIOB pins:

• PA1: MODER=1 muxed as output: RED RGB LED
• PA5: MODER=1 muxed as output
• PA6: MODER=1 muxed as output: LED RGB GREEN
• PA7: output
• PTB1: This pin is connected to the BLUE RGB LED, but not muxed (oversight/not used in the firmware?)

Assembly File

Having the .bin file, the following command line is used to generate the assembly file:

arm-none-eabi-objdump.exe -D -bbinary -marm node.bin -Mforce-thumb > disassembly.s

Comparing it with a standard example from ST, it is easy to understand the startup code and initialization code:

Disassembly Code compared with STM Example code

Vector Table

Same for the vector table: the default vector table of STM32 completes the picture:

Vector table

Knowing the vector and ISR addresses, I can set breakpoints, e.g. for every UART transfer or for when the PIR sensor is raising an interrupt.

Generating C Code

Having the disassembly code is great. Another interesting attack vector is to translate the assembly code back into C code.

Avast has published RetDec (https://retdec.com/), which is a retargetable machine-code decompiler based on LLVM.

Retargetable Decompiler

There is even a web interface available on http://retdec.hostbin.org/

RetDec Online Interface

A more powerful way is to install the tools locally and use it with the following commands to generate C source code:

./decompile.sh FILE --mode raw --arch x86 --endian little --raw-entry-point ADDR --raw-section-vma ADDR
python c:\temp\retdec-v3.3-windows-64b\retdec\bin\retdec-decompiler.py node.bin --mode raw --arch thumb --endian little --raw-entry-point 0x8005ed0 --raw-section-vma 0x8000000

Below running RetDec in a console:

RetDec output

The source code is pretty raw and full of goto’s, but makes it much easier to understand the code flow:

Created source code from Assembly

Using that source code, it makes it easy to search for variable addresses. For example, knowing that PORTB is at 0x50000’0400, I can easily find where the code is using it:

Using PORTB

Using that C code, it was possible to understand the most important aspects of the firmware, setting breakpoints in the send/receive routines, and step through the C/assembly code.

Summary

Putting a sensor device under employees’ desk is an interesting topic: both from the employee perception, legal consideration, and as well from the technical side.

It has been surprisingly easy and simple to hack and reverse engineer such an IoT device. It is a bit shocking the fact that it is possible to enter a duplicate/fake device to TheThingsNetwork. Talking with the startup company, it was clear that their intention was a good one, and they are very open to suggestions and want to work with their clients to make things better. At the same time, the thinking is that hackers would use some other/easier ways to get to their goal, so not much security has to be built into the device anyway. While one could think that such a device (“it is only a PIR, a temperature and humidity sensor”) is not of interest of hackers: think twice! Depending on the target, depending on the interest, even simple presence, humidity, and temperature data can be of interest: you want to know if the CEO of a company or another person is in its office? Data can be used to compromise someone. I hear very often that ‘Facebook, your Smartphone, or Google collects more data’ or ‘my data is not of interest of anyone.’ I think that’s not the point: if we are not protecting data, someone will misuse it sooner or later. As a company, if you are creating such devices, think about the possible headline in the newspaper if such ‘not valuable data’ leaks out or get hacked?

Clearly, that startup company had a good idea (monitoring usage of rooms), which is a great gadget for facility managers. And if it is done and deployed correctly with security and data privacy in mind, I think this can be a good idea (e.g. knowing if currently there are free seats in the cafeteria, or should I postpone lunch for 15 minutes?). But if such devices monitor work desks, this can be very problematic. I have been assured that the company/employer only knows which sets of sensor numbers are in a room, but not which one is assigned to which person in that room. That still makes it possible to track data down to a person: if 4 sensors are for 4 people in such a room, and no sensor shows activity, you know that none of the 4 people are in the room, so you have assigned data to a person (“he is not in the office”). Same for the case if all 4 are in the room. This might be a gray zone, but for sure, this could be some data, which can get misused.

One point to think about: the idea of that employer wants to ‘know how much rooms are used.’ Considering that sensor (PIR which only can detect movement, but not presence), it sounds like we are using the wrong sensor for that purpose? So, using the wrong sensor when getting an answer on which sensor is not suitable will definitely generate the wrong data for the facility management. What is the sense of collecting data knowing that it will be wrong anyway?

The other point is the law (which can be different in each country). Especially in Europe, the lawmakers are catching up after all the scandals in the past, mostly from the big companies we all know about. But with all the IoT devices, there are more (and diverse) hacking targets around all of us, and who knows what might come.

And while facility management wants to get some information as below, there can be hackers interested in that information too, or not?

Workspace monitoring (Source: web article about the startup company)

As a reminder, this is not a complete list of points to consider for such IoT devices:

• If planning to deploy monitoring devices in workplaces, check the legal obligations and do every possible effort to consult, inform, and discuss with employees in advance about the needs and why this is necessary.
• While we all produce data, every possible effort has to be made to protect personal information. If data can be linked to a person, this is most likely very problematic: make sure upfront that data is already anonymized at the device level and not on the server level.
• Check any cloud/web-based infrastructure about vulnerabilities. Do make it possible to guess from customer names to login data information. Social engineering needs efforts, but if the target is worth it, it will be done.
• Do not put device login data information on the device itself (e.g. no stickers with full or part of the login information).
• The LoRaWAN protocol over the air is secure and encrypted. But with having the device ID and App EUI and application password, it is possible to hijack a device. There can be vulnerabilities outside of your control.
• Do not use a communication protocol that transmits login information in clear text. Sending passwords over a serial line is a bad thing, because, with physical access to the lines, you can read it.
• To make reverse engineering more difficult, make sure the device names/purpose is not visible. Prevent FLASH readout (I wrote about this in “Preventing Reverse Engineering: Enabling Flash Security“)
• You never will be able to prevent reverse engineering, especially if someone has physical access to the hardware. This post: https://www.nanolabtechnologies.com/wp-content/uploads/2018/04/pod-teardown.pdf is an excellent example of how far this can go.

So, what do you think? Do we need to protect ‘useless’ data more? Have you seen similar devices in your workspace? What do you think about it?

Happy securing!

I would like to thank Ch. and others who helped me investigating these IoT devices. Their help was crucial at times when I was stuck. Thank you all!
And I would like to thank A. from that startup company for the insights and good discussions: may the future world more secure!

LINKS

• AMSYS HTU20 Sensor: https://www.amsys.de/produkte/feuchtigkeitssensoren/htu20d-digitaler-feuchte-und-temperatursensor/
• Command-Line Debugging with GDB: https://mcuoneclipse.com/2015/03/25/command-line-programming-and-debugging-with-gdb/
• Reverse Compiler: https://retdec.com/
• RetDec Online Interface: http://retdec.hostbin.org/index.html
• RetDec presentation: https://retdec.com/static/publications/retdec-slides-botconf-2017.pdf
• Ghidra: https://www.nsa.gov/resources/everyone/ghidra/
• Microchop RN2483 Module: https://www.microchip.com/wwwproducts/en/RN2483
• STM32L031F6P6 microcontroller: https://www.st.com/en/microcontrollers-microprocessors/stm32l031f6.html
• Reverse Engineering an Insulin Pump: https://hackaday.com/2019/04/29/reverse-engineering-an-insulin-pump-with-an-sdr-and-decapping/
• Insulin Pump Teardown: https://www.nanolabtechnologies.com/wp-content/uploads/2018/04/pod-teardown.pdf