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

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

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

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, the possible problems along with 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 you find one morning such a unknown device under your 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 to have a closer look:

💡 The way the device is mounted makes easy to move it, to remove it or place it 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):

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

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

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

A sticker inside the battery compartment has ID number and 2D barcode on it, the same code is on a sticker on the outside. There are as well 7 small holes on the outside (breathing holes to allow air circulation or maybe used for a microphone?).

💡 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 even not need to open up the device to get that ID.

The central part of the device is PIR sensor:

The PIR sensor is used to detect movement, something which is used to turn on a light or similar. There is as well 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:

The analysis of the board component revealed 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.

💡 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 be used by the current firmware, as there is no I2C communication with it.

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.

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

💡 according to a reader (see comments sections), this sensor is a LIS3DH from STMicroelectronics

Who made it?

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

Google name/image search reveals the company behind this device. The examples on the web site shows that these devices are used for 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 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):

https://www.seco.admin.ch/seco/de/home/Arbeit/Arbeitsbedingungen/gesundheitsschutz-am-arbeitsplatz/Psychosoziale-Risiken-am-Arbeitsplatz/Ueberwachung.html

In short: any electronic surveillance of workplaces is not permitted. There is  special brochure (German) which 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 lead 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 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:

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

There is a ‘cust‘ for ‘customer in it. Looking at company web site there are the customer names listed. With a bit of social engineering it is possible 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).

💡 According to the company, that portal is supposed to be used by every employee of a customer. That would be actually 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:

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) (which we find 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:

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

This is the SysReset:

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

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 a snapshot of a data transmission to the transceiver which will build a LoRaWAN data packet:

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

The logic analyzer data shows that it initializes the HTU20 sensor, but not that accelerometer/magnetometer. And that after reading the 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 setup a ThingNetwork Device which gets all the traffic:

Below the activation frame data:

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

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:

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

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

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:

💡 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:

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

The pins are not to the ‘standard’ Tag-Connect connector we have on the tinyK22, so we had to patch the 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.

Obviously, the device is not secured and makes it easy to get all the firmware, so flash protection seems not 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.

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:

💡 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:

Debugging with GDB

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

With this I can connect to the microcontroller:

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

Debugging with Eclipse

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

That makes it very convenient to inspect the vector table and debug the 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:

During debugging, the Eclipse peripheral viewer is very helpful:

Stepping through pin initialization in main() revealed the pin assignments from 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 t 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:

Vector Table

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

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.

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

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:

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

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 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 revers engineer one such a IoT devices. A bit shoking is 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 for suggestions and want to work with their clients to make things better. 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 gagdet 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 person in such a room, and no sensor shows an activity, you know that none of the 4 person 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 was to ‘know how much rooms are used’. Considering that sensor (PIR which only can detect movement, but not presence) sounds like using the wrong sensor for that purpose? So, using the wrong sensor for getting an answer for which the sensor is not suitable will definitely generate wrong data for the facility management? What would be the sense of collecting data knowing that it will be wrong anyway?

The other point is about 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?

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

• If planning to deploy monitoring devices in work places, check the legal situations 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 no use a communication protocol which 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. https://www.nanolabtechnologies.com/wp-content/uploads/2018/04/pod-teardown.pdf is an excellent example 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 device: their help was crucial 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