DEV Community: José Miguel Moreno

How To Disable Bluetooth on Android TV

José Miguel Moreno — Sun, 28 Jan 2024 10:04:53 +0000

Modern (and not-so-modern) Android TVs often come with built-in Bluetooth for connecting other smart devices, such as voice-enabled remotes. This is nice.

However, for reasons beyond my understanding, Google and most TV manufacturers decided to leave Bluetooth discoverability always enabled on the device with no option to turn it off, resulting in annoying neighbors spamming consent pairing dialogs on the TV whenever they want. This is not nice.

The sensible solution would be for manufacturers to add an option to disable Bluetooth in the TV settings, but unfortunately that's not how modern software development works.

Since this is not an isolated problem, other people have come up with alternative solutions that involve installing an app:

Of course, my Android TV does not support that app (thanks, market fragmentation!), so here's my solution to disable Bluetooth:

Enable USB Debugging on your TV just like any other Android device
Connect to the TV through the network: adb connect <tv-ip-address>
Run adb shell svc bluetooth disable

2025 Update

I came across another Reddit comment that suggests turning off Bluetooth altogether:

adb shell cmd package disable-user com.android.bluetooth

Strange as it may sound, it actually works.

CrowdNotifier explained: tracing COVID-19 contacts with privacy in mind

José Miguel Moreno — Sun, 21 Feb 2021 13:19:13 +0000

CrowdNotifier is a secure, decentralized system for notifiying individuals that have been in contact with SARS-CoV-2-positive people in public locations, such as bars, restaurants, venues and other places that can be considered potential sources of contagion.

This article aims to demistify this technology and explain how it works and how does it preserve the privacy of its users.

Overview

In summary, the CrowdNotifier presence-tracing system involves three parties:

Visitors 🧑: individuals that visit a location at a given point in time.
Locations 📍: the places visitors stop by.
Health Authority 🚑: typically, a single governmental agency that will be responsible for determining whether a person has the COVID-19 disease.

When visitors come into a location, they use an app implementing the CrowdNotifier system to scan a QR code provided by the location owner. When they leave, they check out tapping a notification left by the app on their phone.

Location owners can generate these QR codes using a web application.

If the Health Authority concludes the location has been visited by an infected person at a given point in time, other visitors who were there during the same overlapping timespan will be notified through the app.

The security, trust and privacy of the system rely on symmetric, asymmetric and IBE cryptography.

Now let's see how this process actually works!

IMPORTANT! This article oversimplifies IBE by omitting some encryption/decryption and key derivation aspects to make it easier to understand. Cryptographers be warned.

Step 1: QR codes generation

Location owners need to generate two different QR codes: one for the entry (which is public) and another for the trace (which is private).

The entry code is placed at the entrance (or entrances) of the location and is the one scanned by visitors when they come in.

Both codes are generated offline (this means on the client side, without any party except the location owner knowing any secret key-generation material).

The generation process is as follows:

Generate two sets of IBE master keys (one for the Location and another for the Health Authority). These sets are made of a Master Public Key (MPK) which is known and a Master Secret Key (MSK) that needs to remaing private.

$(mpk_L,\, msk_L) \newline (mpk_{HA},\, msk_{HA})$
MPKs are used to encrypt messages and MSKs can derive decryption keys. If you know the Master Secret Key, then you can decrypt any message (this is partly true, but for the moment just roll with it).
Generate the entry QR code. This one contains some public information about the location (i.e. name), both Master Public Keys and a random symmetric key (notifyKey) which is generated on-the-fly.
Generate the trace QR code. It must be kept secret for now as it contains both Master Secret Keys.

One important detail is the Health Authority's MSK is encrypted using public key cryptography with the HA's asymmetric public key, thus ensuring only the HA can decrypt it.

As you may have already guessed, we need to know the HA's public key in advance (pkHA).

Step 2: Record visited locations

This is the part when it starts to get interesting!

The history of visited locations is stored only on the phone of its corresponding visitor and it keeps track of the past 10 days.

Even if the visitor's phone gets hacked no one can know were he/she has been as this information is both hashed and encrypted 🤯. The most an attacker can do is know someone has been in contact with a SARS-CoV-2-positive.

When visitors enter a location they scan the entry QR code to get all the data it contains, and when they leave, the phone app stores a record for each hour interval they have been at the place.

For example, if a visitor enters at 6:36 pm and leaves at 8:01 pm, inmediately after tapping the "leave" button on their phone, the CrowdNotifier app will generate three messages (6pm, 7pm and 8pm) containing the same information but encrypted with a different key for each hour.

As you can see in the figure above, to generate a record we follow these steps:

Generate an ID needed for the IBE encryption process. This ID is the result of hashing the location info with the UNIX timestamp of the given hour.
"Derive" IBE encryption keys using mpkL, mpkHA and the previous ID (not exactly what happens, but close enough).

These Partial Secret Keys (PSK) are what CrowdNotifier calls "pre-tracing keys".
Create a message consisting of the arrival and departure times and the location's notifyKey. Then encrypt it with the material we obtained in the previous step.

One awesome thing about IBE cryptography is that mhour can only be decrypted if you have the generated ID and both mskL and mskHA, so cooperation between the location owner an the Health Authority is required.

Remember! Master Public Keys are used to encrypt and Master Secret Keys to decrypt.
Store the encrypted message in the visitor's phone.

Step 3: Notifying positives

When the Health Autority detects an infected person, it requests the Location owner the notifyKey, encrypted mskHA and the location PSKs for a given time interval, tipically from the arrival to the departure of the COVID-19 subject.

To obtain the requested information, the Location owner scans the trace QR code that has been kept private until this very moment and derives all location PSKs for the appropiate time interval using their MSK (mskL).

The Health Authority receives this information and verifies it. If it passes verification, a set of notification messages are generated and published to a public server (in most cases managed by the HA) where visitors' apps periodically connect to in order to check whether they have been in contact with an infected person.

These notification messages contain both Partial Secret Keys as the two are needed to decrypt the messages stored in the visitors' phones.

Also, the notifyKey is not sent but instead is used to encrypt a random plaintext that is added to the notification.

Step 4: Alerting visitors

This is the last step of the CrowdNotifier workflow.

After notification messages have been published to the public server, the smartphone app downloads them to check if the visitor has been in the same location at an overlapping time with a positive contact.

For every notification, the app extracts the PSKs and tries to decrypt every message stored in device that was previously recorded in Step 2.

If the time intervals overlap and the random value from the notification can be decrypted using the notifyKey obtained after decrypting the message, then an alert is shown to the user (visitor).

If the app cannot decrypt any stored message with any of the PSKs provided in the notification messages, then everything is fine: the user has not been in contact with an infected person.

And that's basically how CrowdNotifier works!

If you want to learn more or dig deeper into the cryptography behind this technology, check out the White Paper from their official Github repository.

Technical Analysis of All European Contact Tracing Apps (COVID-19)

José Miguel Moreno — Sat, 07 Nov 2020 12:30:52 +0000

This is an ongoing article. It is intended to serve as reference for researchers and may be subject to modifications.

TL;DR: If you're looking for the Google Sheets file containing all the European API endpoints, it's on this link.

As the COVID-19 global pandemic worsened, different countries began looking for ways to trace the spread of the infection in an effort to cut the transmission as soon as it was detected.

The result of this effort were Contact Tracing Apps, simple yet effective applications that broadcast and listen to specially crafted Bluetooth Low Energy (BLE) beacons to determine whether a person has been in close contact and for how low with someone infected.

Without a doubt, the universal specification for exchanging this BLE messages has been and still is GAEN (Google/Apple Exposure Notification), yet each country or region chooses a different approach for all the other aspects of the app, such as notifying COVID-19 positives and verifying exposures.

And so, here we are now. Almost every country in Europe has its own Contact Tracing App with its own respective backend servers that have their own different implementation and that, in the majority of cases, are not compatible with one another.

The purpose of this brief article is to put together all the technical information I've been collecting about these apps and to serve as documentation for other researchers.

App classification

At the time of writing, there are 21 European countries using Contact Tracing Apps (CTAs) in production.

They can be classified mainly by the license of their source code and the backend implementation they are using.

By source code license

Although the vast majority of CTAs are open-source, there are 3 (dis)honorable mentions of countries with no intention in publicly releasing the source code of their apps:

VirusRadar (Hungary): Not only is closed source, but it is also centralized and requires users to register with a phone number and other identification details to start using it.
Korona Stop LT (Lithuania): The latest app of this kind to have been released in Europe. It is based on Corona-Warn-App (provided under the Apache-2.0 License), so maybe they intent to release the source code soon, who knows.
Smittestop (Denmark): Built on Xamarin, is more difficult to decompile than other apps and also requires user registration.

By backend implementation

Most apps have their own implementation for their backend servers. Of the ones that are based on a common specification or library, DP-3T and CWA have an almost equal market share.

CTAs classified by backend implementation

DP-3T (short for Decentralized Privacy-Preserving Proximity Tracing) is developed mainly by the EPFL in Switzerland and has also had great influence in the GAEN protocol.
Apart from the one from its home country, the CTAs from Estonia, Malta, Portugal and Spain use this implementation too.

CWA gets its name from the German CTA (Corona-Warn-App). The source code of the entire infrastructure of this app is available on GitHub, as is the case with DP-3T. Belgium, Germany, Lithuania and Slovenia have chosen this implementation.

Despite not being an actual open-source implementation as with the previous cases, some Eastern countries use S3 buckets to host their TEKs (Temporary Exposure Keys) for app clients to download them.
These countries are Czechia, Latvia and Poland.

Other implementations

In the "other" category, it's worth mentioning the apps from Ireland and France (COVID Tracker and TousAntiCovid, respectively).

COVID Tracker is based on the COVID Green project from the LFPH (Linux Foundation Public Health). It does not require user registration, but enforced OAuth Bearer authentication in all requests to the backend.

TousAntiCovid (previously known as StopCovid) is based on ROBust and privacy-presERving proximity Tracing or ROBERT for short because the French Government cannot help itself when naming things using fake acronyms.
This is one of the most concering Contact Tracing implementations, as it is fully centralized (the server is the one that verifies exposures, not the clients) and it even enforces user registration.

Conclusions

Although there is clearly fragmentation in the European Contact Tracing App ecosystem, it is not that big of a deal as all countries except from France and Hungary have taken a decentralized approach that works by hosting TEK batches in their backends and letting clients download them to verify exposures.

As these TEKs are in the GAEN protocol format, it means all decentralized apps should hypothetically be able to exchange their batches. This looks like the next reasonable step forward and hopefully it becomes a reality with the EU Federation Gateway Service initiative that some CTAs are already using.

References

Found a misspell, have a correction or additional information? Let me known and I'll be glad to fix it! 🙂

From Ubuntu to Debian without any external storage device

José Miguel Moreno — Fri, 27 Mar 2020 14:02:01 +0000

Say you have a machine, probably a virtualized one, running Ubuntu or any other similar GNU/Linux distribution. The thing is, you don't want to run Ubuntu anymore on that particular machine and you decide to nuke the entire disk and install Debian 10.

But, and here's the catch, you're not able to plug any bootable USB stick or mount a CD/DVD! Also, your BIOS/UEFI doesn't support network booting (because of course not) and you're running extremely low on storage space.

You may be asking: "How the f$%&! did you manage to get into such troublesome situation?" and "Is it really possible to overwrite the OS at this point?". Well, as you might have probably guessed by the title of this post, it is!

My current (hypothetical) situation

So, let's recap. I have a virtual machine that...

Has no working USB ports
Has no CD/DVD drive
Has a limited BIOS with no support for network booting
Has less than 100 MB of disk space left

This means that:

I cannot burn the Debian Installer to a USB drive
I cannot mount the Debian Installer ISO
I cannot use the Debian Installer via Network Boot
I cannot create a partition to copy the Debian Installer to and boot from there

The (surprisingly easy) solution

Believe or not, there's still a way to install Debian on this crappy machine. You just need three things: "mini.iso", GRUB2 and at least 100 MB of RAM. And that's all.

First of all, you need to download the "mini.iso" file from the Debian Network Installer. This ISO is a 40 MB, minimal bootable system that can install Debian providing you have a working Internet connection.

You can download the latest version of this file from the official Debian Project page using this link.

Now copy that file to /boot:

~$ sudo cp debian.iso /boot/debian.iso

We'll use GRUB to dump that ISO to RAM and then boot to it. In order to achieve it, modify the /etc/grub.d/40_custom configuration file to add the following menu entry:

menuentry "debian-installer" {
  set isofile='/boot/debian.iso'
  loopback loop $isofile
  linux (loop)/linux priority=low toram vga=788 ---
  initrd (loop)/initrd.gz
}

You may also need to modify the /etc/default/grub file to display the entry selection menu at boot:

#GRUB_HIDDEN_TIMEOUT=0 # <--- Make sure this is commented
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

Lastly, call update-grub to apply the changes you've just made:

~$ sudo update-grub

At this point, you should be able to reboot the VM and get the following screen:

The only thing left to do is boot to "debian-installer" and follow the steps until you finish installing Debian.

Docker + VMware on Windows: the easy way

José Miguel Moreno — Sun, 17 Nov 2019 12:54:39 +0000

August 2020 Update: now that VMware Workstation can run with Hyper-V installed, there's a better alternative to running Docker on Windows 10. Check out this guide for more information.

Docker is one of the most useful tools for a developer nowadays, but setting it up on a Windows machine can be really painful, specially if you don't want to enable Hyper-V and prefer to use another hypervisor such as VMware Workstation.

Fortunately, there's an "easy" way to do exactly that with Chocolatey, the self-proclaimed package manager for Windows. Let's get started!

First of all, we need to open a Powershell window with administrative privileges and run the following command to install the Docker CLI and the VMware Docker machine driver:

PS> choco install docker-cli docker-machine-vmware

As Docker is runtime-agnostic, we can create a custom Docker machine running inside a VMware VM instead of using Hyper-V and then connect that instance to the Docker CLI. Let's create the Docker machine:

PS> docker-machine create --driver=vmware default

This command will take a few minutes. After it's done, make sure it was successful by listing the available Docker machines:

PS> docker-machine ls

NAME      ACTIVE   DRIVER   STATE     URL                          SWARM   DOCKER     ERRORS
default   -        vmware   Running   tcp://192.168.142.136:2376           v19.03.5

Great, we're almost done! The final step is to tell the CLI to use this machine for any Docker-related commands:

PS> docker-machine env | Invoke-Expression

And that's it! Docker running on Windows using VMware Workstation instead of Hyper-V. Keep in mind you'll need to start the Docker machine and connect it to Docker CLI every time you boot your device:

PS> docker-machine start default; docker-machine env | Invoke-Expression

Last but not least, here are some relevant URLs you can visit to learn more: