Warcodes II - The Desko Case

by Ruben Santamarta

Six months ago we published a blog post describing ‘Warcodes’ a novel attack vector against industrial barcode readers. It included the following warning in the conclusion:

“Also, according to IOActive’s experience, it is likely that similar issues affect other barcode manufacturers.”

The same warning still applies at the time of writing this post, so I am afraid that we will have a 'Warcodes III' sooner rather than later. 

Also, I would like to clarify that, as opposed to previously published research on barcode readers, we are directly attacking the barcode reader device. This basically means that for our attacks to work we do not take the user terminal (a PC or any other device) connected to the target barcode reader into account.

In the previous blog post, we focused on industrial barcode readers used in the baggage handling systems deployed at a significant number of international airports. The context in this case does not change very much from the previous one, we are still analyzing threats to smart airports by looking for potential security risks in the devices that comprise the most critical systems within modern airport facilities. To identify those systems, we again used the ranking that appeared in this ENISA paper on securing smart airports.  

This time we targeted boarding gate readers used as part of the passenger boarding and flow control. 

DESKO

Please note that after 3 months DESKO stopped responding to our requests so unfortunately we are not aware of any  workaround.

DESKO products are found in most international airports around the world. For instance, while going through a security checkpoint you may have noticed that the TSA uses DESKO’s PENTA Scanner®. 

Unfortunately, I couldn’t find one of those devices publicly available so if anyone out there is willing to help me access a PENTA Scanner, just ping me.

However, I managed to buy a couple of BCR/BGR 504 pro devices, which are pretty common at boarding gates and security checkpoints at international airports such as Munich (Germany), San Francisco (US),  Heathrow (UK) or Mumbai (IN).

                                            BGR 504 at Mumbai Airport  (India) - Image from https://livefromalounge.com 

                                                    BGR 504 at Munich Airport (Germany)

Hardware Analysis

At first glance, it is obvious that the BGR 504 pro is a much more complex device than the BCR 504 pro; however, they both use the same imaging engine, an OEM barcode reading engine manufactured by Honeywell: the N56xx family.  

                      

According to the FCCID documents, the Desko Penta Scanner Cube  seems to be using the same n56XX module.

So let’s see what we can learn from the manual. 

According to the document we can “create and print programming bar codes” pretty much the same way as in the SICK scenario, so the EZConfig-Scanning software is certainly an interesting target to dig deeper into and explore all those functionalities.

Ok, there we go. This basically confirms that we can control the N5600 via custom programming barcodes, but there are some security settings that may prevent this from working. Unfortunately, those security settings are not publicly available, so it seems like reverse engineering is, once again, the only path we can take to satisfy our curiosity.

The N56xx module is basically comprised of a camera module and logic board.

The MCU of the logic board is an i.MX257

We have already seen that it is possible to configure the module with custom settings, but it is also possible to develop custom plugins for this module using the TotalFreedom SDK.  There is even a marketplace for commercial plugins. Taking this into account, the Winbond SPI flash memory  may hold interesting data; hopefully, the firmware as well. 

So instead of dumping the memory, I just sniffed the SPI bus during a regular boot using a SALEAE logic analyzer.

It was possible to grab the firmware from the captured data. I directly exported the CSV data from the SALEAE session and wrote the following program to extract the contents.

Firmware analysis

Right after the highlighted header, we find the code for a loader that decompresses the main application.

After the loader comes the application header, and then finally, the compressed application.

Honestly, I didn’t spend too much time trying to understand the decompression algorithm; it looks like some kind of RLE, but I moved directly to emulating it using the Unicorn engine.  There are just few requirements we need to comply with in order to emulate this function:

• We need to understand the context where the decompression function is executed and replicate it within our Unicorn-based emulator program. We need to set the context of the function as if we were the loader. The function is expecting four parameters: 
• R0 - Source (compressed data)
• R1 - Length (compressed length)
• R2 - Destination 
• R3 - Flag 

• We need to save the code for the ‘decompress’ function (732 bytes)
• In the Unicorn engine program, we have to create the memory mappings, load the code to be emulated (decompress.bin), and set the registers accordingly, before invoking the function to be emulated. C source code available here.

Back to those ‘confidential’ security settings, firmware analysis revealed the logic behind them.

The ‘MNUENA’ command is used to decide whether or not the N56xx module will accept programming barcodes. Basically, executing MNUENA0 disables menu commands through programming barcodes and executing MNUENA1 forces the device to start accepting them again.

However,  it appears that someone considered that once you deploy one of these modules, it is not a good idea to let just anyone send menu commands through programming barcodes.  By reverse engineering the firmware, I noticed that Honeywell implemented a single security boundary: a ‘PASSWORD’ field in the working config. It can be configured through 'PASWRD' command in order to require a password when attempting to enable menu commands with 'MNUENA1'.

‘validatePassword’ checks whether the password entered via the programming barcode is the same as the one that was configured, and ‘check_password’ checks whether the format of the password is acceptable when it is set.

Obviously, this approach may have a significant caveat: when configured, the value of that 'PASWRD' will probably be the same for all N56xx modules. Therefore, if you have physical access to one, for instance, by buying a decommissioned device (like I did), it is possible to access the password.

A further analysis revealed that you do not even need physical access to dump flash memory, as I also found undocumented commands that can be sent through specially crafted USB (or Serial when Desko VCOM is installed) requests. Their names are pretty self-explanatory but are summed up as follows:

• DUMPMEMORY: Allows dumping arbitrary chunks of memory

• PEEK: Allows reading memory contents from arbitrary addresses

• POKE: Allows writing attacker-controlled values to arbitrary addresses

You can use the following PoC to communicate with a N56xx module and send the aforementioned commands via USB.

In the DESKO case, the 'PASWRD' field has not been configured, so anyone presenting the following barcode to the device will enable menu commands through programming barcodes, allowing them to disrupt the normal functioning of the device.

 

Conclusion

The attack vector described in this blog post can be exploited in various ways across multiple industries, as the Honeywell N56xx family is an OEM device that is actively deployed in different sectors. These issues can be leveraged to backdoor and take control of these devices.

We recommend all barcode reader manufacturers take a proactive approach and assess the security posture of their products against this type of attack, as the trend we are observing is worrisome.

Disclosure Timeline

Following a responsible disclosure policy, IOActive notified DESKO about these issues. After approximately three months of telling us they were actively working to resolve the issues, DESKO stopped responding to our requests.

• 2020-08-12 - Initial contact through DESKO’s web support form.
• 2020-08-12 - Automatic reply from DESKO.
• 2020-08-17 - DESKO support staff asks for additional information about the issue.
• 2020-08-19 - IOActive shares the initial advisory describing the issue with DESKO.
• 2020-08-20 - DESKO support staff acknowledge the report and mention they will share it with their Research & Development team.
• 2020-09-23 - DESKO states they are in contact with the N5600 manufacturer in order to address the issue.
• 2020-10-26 - IOActive asks for a status update; no response
• 2020-11-23 - IOActive asks whether DESKO has any plans to share a statement about this security issue; no response.

Please note that after 3 months DESKO stopped responding to our requests so unfortunately we are not aware of any  workaround.

CVE-2020-16877: Exploiting Microsoft Store Games

by Donato Ferrante

TL;DR

This blog post describes a privilege escalation issue in Windows (CVE-2020-16877) I reported to Microsoft back in June, which was patched in October. This issue allows an attacker to exploit Windows via videogames by directly targeting how Windows handles Microsoft Store games. This issue could be exploited to elevate privileges from a standard user account to Local System on Windows 10.

---

Introduction

Back in June, a certain announcement caught my attention – Microsoft just added support for mods for various games as part of its gaming subsystem. My growing curiosity lead me to explore this new Windows feature and find an implementation flaw that could be abused to conduct privilege escalation attacks.

I have put together this blog post using the many Post-it notes left stuck around my monitors, detailing a long night spent playing around with this new Windows feature.

Before we start playing with this feature, let me provide you with some background on Windows apps and game mods. If you are familiar with these concepts, please feel free to skip over the next section.

---

Windows Gaming and Mods

If you are not too familiar with videogames, a mod (short for "modification") is an alteration made by players or fans of a videogame, that changes one or more aspects of a videogame, such as how it looks or behaves. Mods range from small changes and tweaks to complete overhauls, which can make a game more interesting to play.

In general, Microsoft Store games are Universal Windows Platform (UWP) apps deployed on Windows as Windows apps.

According to Microsoft's documentation, a UWP app is:

• Secure: UWP apps declare which device resources and data they access. The user must authorize that access. UWP apps use a manifest to specify the capabilities that are needed, such as access to the microphone, location, Webcam, USB devices, files, and so on.
• Able to use a common API on all devices that run Windows 10.
• Available from the Microsoft Store on all devices that run on Windows 10.
• Able to be installed and uninstalled without risk to the machine or incurring "machine rot".

One can think of a UWP app as a sandboxed application, which defines its capabilities (e.g. filesystem access, network access, and so on) in the Manifest part of the application package (Appx).

Appx is the file format used to distribute and install apps on Windows 10, Xbox One, HoloLens, and Windows 10 IoT Core. Unlike legacy desktop apps, Appx is the only installation system allowed for UWP apps.

Windows apps are stored in a special “hidden” directory ("C:\Program Files\WindowsApps") on the system that has strict access rules, preventing any sort of game mods or standard user interaction:

The following images shows the permissions for this directory:

In the past, given the lack of mod support for Microsoft Store games, players have been looking for workarounds to mod their favorite games (i.e. Minecraft – Microsoft Store edition). For example, in order to perform DLL injection on UWP apps, the ALL APPLICATION PACKAGES (S-1-15-2-1) group should have had R+X permissions on the DLL being injected into the Windows app.

Now that we have a basic idea of the Windows apps ecosystem and game mods, we are ready to jump into the fun part.

---

Game On!

Before installing the game on my system, I took a step back and considered how Microsoft might implement this feature and came up with two possible ways. My two guesses were:

• A new subdirectory within the WindowsApps directory that was accessible to standard users.
• A separate directory placed in a (standard) user-accessible directory.

So, I performed an additional step and did a simple search on my main drive for "*WindowsApps*" and got the following result:

It appears that in order to allow games to support mods, Windows created a new directory "C:\Program Files\ModifiableWindowsApps", which as the name suggests, should host Windows apps that could be modified. Interesting.

I wanted to check the permissions on this directory as well as its contents, but unfortunately, I didn't have any content in it yet. However, I could at least access it without an admin prompt, but couldn't do much in it...

Permissions on C:\Program Files\ModifiableWindowsApps:

I did a quick online search for references to this directory and found the following bits:

• References to the ModifiableWindowsApps directory could be found in the Microsoft documentation for desktop6:MutablePackageDirectory (dated 04/19/2019), which states this directory, "specifies a folder under the %ProgramFiles%\ModifiableWindowsApps path where the contents of your desktop application's install folder are projected so that users can modify the installation files (for example, to install mods)."
• The documentation for desktop6:MutablePackageDirectories (dated 04/19/2019) states this directory, "enables your desktop application to specify one or more folders where users can modify the installation files for your application (for example, to install mods)."
• And most importantly, "this element is currently intended to be used only by certain types of desktop PC games that are published by Microsoft and our partners. It requires the modifiableApp restricted capability".

This tells us that this feature is restricted to only certain games that need to be vetted and approved by Microsoft, in order for the game to be allowed to specify the modifiableApp capability in the manifest, and therefore allow mods.

---

Recap Time

Let's recap what we know so far:

• Windows is allowing a number of Microsoft Store games to be modifiable.
• This is achieved by allowing certain game developers to publish UWP games on the Store using a restricted capability (modifiableApp).
• Among other things, the modifiableApp capability allows Microsoft Store games to rely on the Windows mod support and a bunch of new APIs.
• These modifiable Windows apps can specify the directories where their modifiable data is stored via MutablePackageDirectory and MutablePackageDirectories.

---

Back To The Action

At this point, in order to proceed with my exploration, I had to find a list of games with mod support available on the Microsoft Store, and pick a game to play with. Luckily enough, the Microsoft article about mod support for Microsoft Store games had this list ready for me:

• DiRT Rally 2.0
• Farming Simulator 17
• FTL: Faster Than Light
• Into The Breach
• MudRunner

I decided to go for Faster Than Light:

To confirm my understanding of the Windows apps' modding approach, I took a quick peek at the game manifest to check and confirm the presence of the "special" capability (modifiableApp):

And to confirm the location of the game directory where the game data would be deployed, I checked the ModifiableWindowsApps directory after installing the game, and "FTL" would be the MutablePackageDirectory:

With this information, I decided to go ahead and install the game again as a standard user, and monitor the installation process with ProcMon:

ProcMon provided me with the following information about installing games with mod support from the Microsoft Store:

• There were two main processes doing the heavy lifting:
• svchost (running as NT AUTHORITY\SYSTEM), specifically:

• GamingServices (running as S-1-5-18)
• These processes performed interesting file actions without impersonating a low-privileged user.

At this point I was very intrigued by this installation mechanism and decided to spend a bit more time on this, but not before having yet another late-night espresso.

---

Houston, We Got A Problem

The ModifiableWindowsApps directory, storing Windows games, does not allow (by default) standard users to fiddle with the installation directory or its contents:

One of the reasons why Microsoft may want to restrict access to the game directory (and its parent directory) is to prevent standard users from hijacking the installation process and placing game data into an unwanted directory. How? For example, by relying on symbolic links.

Specifically, on Windows it is possible to create symbolic links via:

• Hard Links - A hard link is the filesystem representation of a file by which more than one path references a single file in the same volume.
• Junctions - A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer.
• Object Manager Symbolic Links - a filesystem-like structure, which is used to hold named resources, such as devices and events, that also supports symbolic links.

If you would like to know more about symbolic links, please refer to the amazing work from James Forshaw (@tiraniddo) on this topic (i.e. A Link To The Past).

If I were able to gain write access to the ModifiableWindowsApps directory, I could try to redirect the game installation to target an arbitrary directory on the system, including a directory a standard user would not have access to, since the installation process(es) run as a high-privileged user, as shown earlier.

Under the assumption I could create the initial junction (for the ModifiableWindowsApps directory itself), the following workflow shows a possible way to hijack the installer to an arbitrary directory (i.e. into "C:\Windows\ImmersiveControlPanel"), bypassing access restriction:

Permissions for C:\Windows\ImmersiveControlPanel:

Unfortunately, to be able to set up any symbolic link, a standard user would need to have write access to ModifiableWindowsApps or any of its subdirectories.

This was not possible since the ModifiableWindowsApps could not be replaced (as this was already part of the system) and there were strict access rules in place to protect this directory and its content (i.e. the game directory "FTL").

Is it game over? Well not just yet...

---

And Yet It Moves

All I needed to find was a way to "lift" the ModifiableWindowsApps directory and place it somewhere else on the system where I have access, at least until this relocation has completed.

Interestingly, Windows has a neat feature that lets you define where various data should be stored, which is accessible to standard users. This feature is accessible via Storage Settings.

This feature obviously works for Windows apps, and I wanted to confirm this would also work with modifiable Windows apps. So, I set the destination drive for new apps to a different drive on my system and tried the installation process again. Great news, the ModifiableWindowsApps directory and the game were both placed on the new drive.

Potentially, this could be a way to gain write access to the ModifiableWindowsApps directory when this is deployed on a different drive (rather than C:), and all I had to do was prepare the destination drive (i.e. any other drive on the system, even an empty USB stick) with a combination of junctions and bait the installer via Storage Settings.

---

Challenge Accepted

It was time for me to put all the pieces together and try to exploit this mechanism and see if the workflow I envisioned earlier, with a minor change (bouncing from one drive to another), would work and reveal an interesting implementation flaw:

First off, I set the junction to hijack the installer using the following commands (assume D: is any other available drive on the system - even a USB stick):

• md "D:\Program Files"
• mklink /J "D:\Program Files\ModifiableWindowsApps" "C:\Windows\ImmersiveControlPanel"

Then, I changed where the Windows apps should be stored via Storage Settings:

And installed the game:

While monitoring the installation via ProcMon:

To confirm the game data was actually written into my arbitrary directory:

At this point I knew a standard user could write data into any arbitrary directory on the system, but what about deleting files? The first approach that came to mind was trying to uninstall the game.

Unfortunately (or fortunately), the uninstall process only removes game files (stored in the actual game directory) and it didn't appear to touch any unrelated data.

But what if the game directory itself is a junction? What if we use a double junction to trick the installer into thinking that the game installation directory itself is another directory on the system?

This way, when the installer attempts to delete the game data, instead of deleting the content of the game directory (i.e. "FTL"), it will remove the content of an arbitrary directory on the system (i.e. the "Private" directory stored on the admin's desktop):

So, I prepared my attack environment again but with a little twist, I would use a double junction to wipe an arbitrary directory by pivoting the installer towards my target:

• md "D:\Program Files"
• md "D:\pivot"
• mklink /J "D:\Program Files\ModifiableWindowsApps" "D:\pivot"
• mklink /J "D:\pivot\FTL" "C:\Users\dnt-admin\Desktop\private"

After setting up the environment, I performed the same steps as described earlier for the arbitrary write scenario, with a little change when performing the installation step. In fact, to trigger the "delete", one would need to interrupt the installation (after the download completes) via the Microsoft Store or wait for the installer to throw an error:

And by doing so, all the data in the targeted directory was actually wiped.

As a final comment before we jump to the last section, please note that it is possible to achieve good control over where the game data is written to (or which files to delete) by the installer by using multiple combinations (and levels) of symbolic links.

---

Elevation Time

People usually say "pics or it didn't happen", so I shall leave a GIF(t) below of a standard user spawning a shell running as nt authority\system by exploiting this vulnerability:

Hope you enjoyed the reading! Game on and play safe!

---

A journey into defeating regulated electronic cigarette protections

By Ehab Hussein.

TL;DR: This blog post does not encourage smoking nor vaping. The main focus of this blog will be defeating the protections of a regulated electronic cigarette to assess the ability of it being weaponized via a remote attacker by modifying its firmware and delivering it through a malware which waits for electronic cigarettes to be connected over USB or discovered over Bluetooth.

The electronic cigarette market continues to grow. According to statistics presented by the market research company EuroMonitor, the number of people who vape will reach almost 55 million by 2021. In this blog post, we showcase different ways to weaponize electronic cigarettes or their components to cause fires and/or explosions, which can physically impact sectors such as the Aviation industry.

Vaping 101:

Prior to creating havoc, let’s do a quick walkthrough of the components that comprise a mod vape. There are two common types of mod vapes: regulated and unregulated.

Regulated (box) mods have built-in protections against overheating and continuous firing and regulate the power flow through the device. 

Regulated Mod 

• An 18650 battery is the most common type of battery used in box mods. They are lithium-ion cell, which are high-drain, rechargeable batteries.
• Two buttons on the box mod control the wattage and tell the mod how much power to deliver to the coils to make them hotter or cooler.
•  Box mods can hold one or more batteries. Once the fire button is pressed, the batteries discharge, making the coils heat up and causing the liquid to turn into vapor (hence the term: vape or vaporizer). The user inhales the vapor via the drip tip.

Mechanical mod

Unregulated (mechanical) mods have no circuitry and do not provide any protections. Mechanical mods provide direct power from the batteries to the coil (these are dangerous on their own). 

How vape firing looks like Fire button is pressed. Current is supplied to the coils which make them heat up. Liquid on the cotton wick evaporates.

1- The problem with vape batteries:

The majority of batteries are encased in steel and shrink-wrapped to ensure proper isolation of the positive and negative poles and prevent a short. A short could lead to an explosion or fire depending on the quality of the battery.

High-quality batteries come with safety valves and a protection board, which keeps the safety performance quite high. When a high-quality battery is shorted, the safety valve opens, releasing the pressure and preventing an explosion; but, the chemicals that are released can react with oxygen in the air and still possibly create a fire. Low-quality batteries offer almost no protections. Their safety valves cannot keep up with the fumes being released, thus pressurizing the container and probably exploding.

 So what would cause a battery to explode? Well, here are a few potential causes:

• Being stored in humid or high-temperature conditions (exceeding 65˚C).
• Over-charging, shorts, punctures, being exposed to fire.
• Overheating.
• Poor maintenance, such as damaging the shrink wrap.
• Use of non-authentic batteries (a.k.a. clones).
• Using batteries to power coils with inappropriate resistance ratings.

One major problem that vape users face is damage to their batteries’ shrink wrap. Due to repeated removal and insertion, the shrink wrap starts to peel off the battery. This exposes the negative and positive poles, which could allow shorting in certain conditions. 

Well maintained battery vs poorly maintained battery

The battery on the left is properly sealed with shrink wrap, while the battery on the right has had its shrink wrap peeled off due to excessive use (placing it into the charger and back into the mod).

The dangers of such batteries include the fact that they can be taken onboard planes with no restrictions. Using just a battery and a coin, you can create a fire or explosion, depending on the quality of the battery.

Battery with a damaged shrink wrap shorted with a coin

Battery with a damaged shrink wrap shorted with a coin

2- Disabling protections of a regulated mod:

To weaponize a regulated mod, we need to first set some goals in order to get the best results. Here's a list of things we need to do:

1. Acquire the the firmware. [✔️]
2. Find and patch the protections: [✔️]
1. Continuous fire protection. [✔️]
2. Disable Maximum temperature protection. [✔️]
3. Set its initial watt/temperature to the max.[✔️]
4. Trigger the firing mechanism without pressing the fire button.[✔️]
5. Disable other protections that are triggered along the way.[✔️]
3. Reprogram the mod and see if it accepts modified firmware.[✔️]

There are two ways to acquire the firmware: from the vendor's site (vendors usually have firmware in the support section of their websites where they provide software updates) or by dismantling the device (looking for debug pins (JTAG/SWD) and dumping the firmware).

To dump the firmware, we start by identifying the components in the box mod vape.

This regulated mod uses a Nuvoton NUC220LE3AN an ARM cortex-m0 microcontroller

Nuvoton NUC220LE3AN The following pins are exposed on the PCB: G: VSS (Ground) V: VCC (Power) D: DATA C: CLOCK R: RESET

Nu-Link Pro programmer/debugger Nu-Link Pro programmer/debugger

Hooking the Nu-link to the Box mod

We used the following steps to dump the firmware: Hook the NuLink-pro debugger to the Nuvoton chip using OpenOCD. Attach gdb-multiarch to remote target. (multiarch used for arm) & we'll debug later. Telnet to OpenOCD on localhost:4444 to dump firmware. Check the dumped image.

Once you’ve acquired the firmware, it’s time to take it to your favorite disassembler and load it.

ARM Cortex-M0 is little endian , ARMv6-M Architecture , Thumb instructions

ARM Cortex-M0 is little endian , ARMv6-M Architecture , Thumb instructions

• Then create the segments in accordance with the microcontrollers datasheet
• [TIP]: If you use IDA-PRO 7.5 or BinaryNinja you can use the SVD plugins to create your chip's peripherals by obtaining its SVD file and loading it via that plugin.
• An SVD file is a XML file which includes the descriptions and information for your chip's peripherals.
• You can get SVD files from: https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-search then load it via the SVD plugin in your disassembler to automatically create all your segments/peripherals. 

Create segment mapping by reading the datasheet for the chip

Create segment mapping by reading the datasheet for the chip

Or, you can write a small script and let it create the segments for you.

Segments created

• Align the interrupt vector table: (the interrupt vector table is 4-byte aligned)

• An interrupt vector table is a structure full of exception handlers; when an exception is triggered, a function is called and its instructions are executed. Each exception in the interrupt vector table points to a function. For instance, if you press a button on a device, it triggers an exception. The function associated with the exception is looked up in the interrupt vector table, and the instructions within that function are executed. 

• The interrupt vector table includes an exception named the reset vector. This address is the entry point where the first instructions that the microcontroller will execute after a reset/startup/boot are found (usually at offset 0x4 from the firmware's base address).

• The image below illustrates how the interrupt vector table is aligned.

https://developer.arm.com/documentation/dui0497/a/the-cortex-m0-processor/exception-model/vector-table?lang=en

Before Aligning the Interrupt Vector Table

Before Aligning the Interrupt Vector Table

After Aligning the Interrupt Vector Table

· The reset vector initially points to address 0xd5, which is actually one byte after the real reset vector address. The reason behind this is that before it branches to an address, the microcontroller checks to see if the LSB is set to 1 or 0. Depending on the value, it will branch to execute Thumb (1) or ARM (0) instructions. In our case, the LSB will be set to 1 as the ARM Cortex-M0 executes Thumb code. If the LSB is set to 0, it will raise a hard-fault exception since there are no ARM instructions supported here. To know what a branch will do, you can simply do a bitwise operation on the address. Once you get the address, go to the reset vector address, convert it into a function, and let the disassembler do its magic.

Now we’re all set for finding our protections and start our patching process.

Patch#1 Disable maximum temperature protection 

· This protection does not allow the vape to fire if the device temperature exceeds 75˚C (0x4b). This can be patched to 0xff (255˚C) or disabled altogether, meaning there is no max temperature check.

Device temperature check (75C)

Device temperature check (75C)

Patch#2: Set initial watt/temperature to max 

• These patches set the mod to deliver maximum power to the coils. Referring to the video below, you can hear the difference when the mod is fired at the same wattage (6.1) before and after patching the firmware.

Before (Left) and After (Right) Patching

Before (Left) and After (Right) Patching

Before (Left) and After (Right) Patching

Before (Left) and After (Right) Patching

Patch#3: Disable continuous fire protection 

• This can be accomplished by patching the firmware to never allow the GPIO's data output value to be reset to its original value, which in this chip was `0x0000FFFF` (see patch #4).

Patch#4: patch the firmware to trigger the firing mechanism without pressing the fire button

• The following video demonstrates what can happen if the device is programmed with malicious firmware that causes the vape to fire on its own. 

Enabling the fire button via software, no need to press the fire button

A reasonable threat scenario for this would be when a vape supports OTA (over-the-air) firmware updates (these vapes do exist). A malicious actor could reprogram a vape in someone's pocket over Bluetooth and bad things will happen.

Other Protections:

• I found a few other protections that needed to be patched, such as:
• OHM resistance checks for the coils.
• Battery checks.
• Max puffs.
• Atomizer checks. 
• Protection Abuse checks.

ME ABUSING PROTECTS!

ME ABUSING PROTECTS!

Based on what I learned about the inner workings of regulated vape devices, I do believe that in certain cases vapes can be weaponized. A malicious actor could wreak havoc by causing them to explode or start a fire remotely, since the firmware can be patched to make the vape or its components operate without any sort of protection in place, effectively turning it into a unregulated mechanical mod.

Threat scenarios:

• I don’t doubt that in the near future we will see malware (MalVape, vapeware) targeting users that charge their devices from a laptop or devices that support OTA updates via Bluetooth. Simply put, malware can listen on USB/Bluetooth for vape devices and then trigger a firmware update, reprogramming the vape to become weaponized.

• Vapes, high-drain batteries, and coins are allowed on airplanes. A malicious actor can cause a fire in an aircraft lavatory by throwing a battery attached to a coin into the waste bin where all the tissues are thrown. Same goes for the vape being triggered.
• Vapes can be maliciously programmed to suddenly fire at a set time and date, if they have time and date settings.

Recommendations:

• Vape firmware should be signed and encrypted:
• Firmware that is signed ensures that the firmware being reprogrammed to the device is indeed by the vendor not by a malicious actor. 
• Encrypting firmware makes it more difficult for attackers to reverse engineer it. Although this is security by obscurity, it would stop most attackers.
• Vapes can be dangerous if poorly maintained.
• Don't charge your vape from a laptop. Use authentic external battery chargers.
• Always ensure Bluetooth/wireless connectivity is switched off on your vape if it supports OTA firmware updates. In general, vapes shouldn't have wireless capabilities, as it expands the attack surface.
• Choose and buy authentic and well-known atomizers and mods. 
• Always ensure that you purchase Authentic batteries. Accidents happen when fake batteries are used.
• Always carry batteries in a battery case.

Battery Case

References:

• The Definitive Guide to ARM Cortex -M0 and Cortex-M0+ Processors 2nd Edition by Joseph Yiu (Joseph writes the best ARM books I recommend reading his books)
• https://www.amazon.com/Definitive-Guide-Cortex-Cortex-M0-Processors/dp/0128032774
• Cortex-M0 Devices Generic User Guide
• https://developer.arm.com/documentation/dui0497/a/DUI0497A_cortex_m0_r0p0_generic_ug.pdf
• NuMicro NUC200/220 Series Technical Reference Manual
• https://www.nuvoton.com/resource-files/TRM_NUC200_220(AN)_Series_EN_V1.02.pdf
• Customized OpenOCD for Nuvoton devices
• https://github.com/OpenNuvoton/OpenOCD-Nuvoton
• CMSIS Search:
• https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-search