Apple AirTags have speakers in them, and the speaker is not entirely under the owner’s control. [Shahram] shows how the speaker of an AirTag can be disabled while keeping the device watertight. Because AirTags are not intended to be opened or tampered with, doing so boils down to making a hole in just the right place, as the video demonstrates.
By making a hole in just the right place, the speaker can be disabled while leaving water resistance intact.
How does putting a hole in the enclosure not compromise water resistance? By ensuring the hole is made in an area that is already “inside” the seal. In an AirTag, that seal is integrated into the battery compartment.

Behind the battery, the enclosure has a small area of thinner plastic that sits right above the PCB, and in particular, right above the soldered wire of the speaker. Since this area is “inside” the watertight seal, a hole can be made here without affecting water resistance.

Disabling the speaker consists of melting through that thin plastic with a soldering iron then desoldering the (tiny) wire and using some solder wick to clean up. It’s not the prettiest operation, but there are no components nor any particularly heat-sensitive bits in that spot. The modification has no effect on water resistance, and isn’t even visible unless the battery is removed.

In the video below, [Shahram] uses a second generation AirTag to demonstrate the mod, then shows that the AirTag still works normally while now being permanently silenced.

Why would one want to permanently silence an AirTag, putting it into so-called “stealth mode”? That’s a good question. If you’re not familiar, one of the circumstances under which AirTags emit sound is if it is separated from its owner and has been moving with someone else for some period of time. Intended as an anti-stalking feature, [Shahram] points out that this behavior can also be a nuisance or straight up undesirable. For example, one may be using the tag on a pet collar, to track one’s luggage, or on a potential theft target like a bike. Modern phones in any case alert their owners if a tag they do not own appears to be moving with them, also as an anti-stalking measure.

In [Shahram]’s case, he has hidden an AirTag on his bike. He figures that if his bike should be stolen, a beeping AirTag would announce its existence to the thief and they would in all likelihood simply locate and discard the tracker. But if the tag is silent, the thief — still notified by their phone that a tracker is with them but unable to locate it on the bike — would be more likely to discard the bike instead, allowing it to be safely recovered.

Regardless, the process shows how a careful understanding of a device’s internals can allow for modifications that don’t require opening the whole thing, and the process is a bit reminiscent of drilling into a Stadia controller to permanently disable the mic.

youtube.com/embed/nO_Bg4vAuwM?…

hackaday.com/2026/02/17/airtag…

In April 2025, we reported on a then-new iteration of the Triada backdoor that had compromised the firmware of counterfeit Android devices sold across major marketplaces. The malware was deployed to the system partitions and hooked into Zygote – the parent process for all Android apps – to infect any app on the device. This allowed the Trojan to exfiltrate credentials from messaging apps and social media platforms, among other things.

This discovery prompted us to dive deeper, looking for other Android firmware-level threats. Our investigation uncovered a new backdoor, dubbed Keenadu, which mirrored Triada’s behavior by embedding itself into the firmware to compromise every app launched on the device. Keenadu proved to have a significant footprint; following its initial detection, we saw a surge in support requests from our users seeking further information about the threat. This report aims to address most of the questions and provide details on this new threat.

Our findings can be summarized as follows:

• We discovered a new backdoor, which we dubbed Keenadu, in the firmware of devices belonging to several brands. The infection occurred during the firmware build phase, where a malicious static library was linked with libandroid_runtime.so. Once active on the device, the malware injected itself into the Zygote process, similarly to Triada. In several instances, the compromised firmware was delivered with an OTA update.
• A copy of the backdoor is loaded into the address space of every app upon launch. The malware is a multi-stage loader granting its operators the unrestricted ability to control the victim’s device remotely.
• We successfully intercepted the payloads retrieved by Keenadu. Depending on the targeted app, these modules hijack the search engine in the browser, monetize new app installs, and stealthily interact with ad elements.
• One specific payload identified during our research was also found embedded in numerous standalone apps distributed via third-party repositories, as well as official storefronts like Google Play and Xiaomi GetApps.
• In certain firmware builds, Keenadu was integrated directly into critical system utilities, including the facial recognition service, the launcher app, and others.
• Our investigation established a link between some of the most prolific Android botnets: Triada, BADBOX, Vo1d, and Keenadu.

The complete Keenadu infection chain looks like this:

Full infection diagram

Kaspersky solutions detect the threats described below with the following verdicts:

HEUR:Backdoor.AndroidOS.Keenadu.*
HEUR:Trojan-Downloader.AndroidOS.Keenadu.*
HEUR:Trojan-Clicker.AndroidOS.Keenadu.*
HEUR:Trojan-Spy.AndroidOS.Keenadu.*
HEUR:Trojan.AndroidOS.Keenadu.*
HEUR:Trojan-Dropper.AndroidOS.Gegu.*

Malicious dropper in libandroid_runtime.so

At the very beginning of the investigation, our attention was drawn to suspicious libraries located at /system/lib/libandroid_runtime.so and /system/lib64/libandroid_runtime.so – we will use the shorthand /system/lib[64]/ to denote these two directories. The library exists in the original Android source. Specifically, it defines the println_native native method for the android.util.Log class. Apps utilize this method to write to the logcat system log. In the suspicious libraries, the implementation of println_native differed from the legitimate version by the call of a single function:

Call to the suspicious function

The suspicious function decrypted data from the library body using RC4 and wrote it to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The data represents a payload that is loaded via DexClassLoader. The entry point within it is the main method of the com.ak.test.Main class, where “ak” likely refers to the author’s internal name for the malware; this letter combination is also used in other locations throughout the code. In particular, the developers left behind a significant amount of code that writes error messages to the logcat log during the malware’s execution. These messages have the AK_CPP tag.

Payload decryption

The payload checks whether it is running within system apps belonging either to Google services or to Sprint or T-Mobile carriers. The latter apps are typically found in specialized device versions that carriers sell at a discount, provided the buyer signs a service contract. The malware aborts its execution if it finds that it’s running within these processes. It also implements a kill switch that terminates its execution if it finds files with specific names in system directories.

Next, the Trojan checks if it is running within the system_server process. This process controls the entire system and possesses maximum privileges; it is launched by the Zygote process when it starts. If the check returns positive, the Trojan creates an instance of the AKServer class; if the code is running in any other process, it creates an instance of the AKClient class instead. It then calls the new object’s virtual method, passing the app process name to it. The class names suggest that the Trojan is built upon a client-server architecture.

Launching system_server in Zygote

The system_server process creates and launches various system services with the help of the SystemServiceManager class. These services are based on a client-server architecture, and clients for them are requested within app code by calling the Context.getSystemService method. Communication with the server-side component uses the Android inter-process communication (IPC) primitive, binder. This approach offers numerous security and other benefits. These include, among other things, the ability to restrict certain apps from accessing various system services and their functionality, as well as the presence of abstractions that simplify the use of this access for developers while simultaneously protecting the system from potential vulnerabilities in apps.

The authors of Keenadu designed it in a similar fashion. The core logic is located in the AKServer class, which operates within the system_server process. AKServer essentially represents a malicious system service, while AKClient acts as the interface for accessing AKServer via binder. For convenience, we provide a diagram of the backdoor’s architecture below:

Keenadu backdoor execution flow

It is important to highlight Keenadu as yet another case where we find key Android security principles being compromised. First, because the malware is embedded in libandroid_runtime.so, it operates within the context of every app on the device, thereby gaining access to all their data and rendering the system’s intended app sandboxing meaningless. Second, it provides interfaces for bypassing permissions (discussed below) that are used to control app privileges within the system. Consequently, it represents a full-fledged backdoor that allows attackers to gain virtually unrestricted control over the victim’s device.

AKClient architecture

AKClient is relatively straightforward in its design. It is injected into every app launched on the device and retrieves an interface instance for server communication via a protected broadcast (com.action.SystemOptimizeService). Using binder, this interface sends an attach transaction to the malicious AKServer, passing an IPC wrapper that facilitates the loading of arbitrary DEX files within the context of the compromised app. This allows AKServer to execute custom malicious payloads tailored to the specific app it has targeted.

AKServer architecture

At the start of its execution, AKServer sends two protected broadcasts: com.action.SystemOptimizeService and com.action.SystemProtectService. As previously described, the first broadcast delivers an interface instance to other AKClient-infected processes for interacting with AKServer. Along with the com.action.SystemProtectService message, an instance of another interface for interacting with AKServer is transmitted. Malicious modules downloaded within the contexts of other apps can use this interface to:

• Grant any permission to an arbitrary app on the device.
• Revoke any permission from an arbitrary app on the device.
• Retrieve the device’s geolocation.
• Exfiltrate device information.

Malicious interface for permission management and device data collection

Once interaction between the server and client components is established, AKServer launches its primary malicious task, titled MainWorker. Upon its initial launch, MainWorker logs the current system time. Following this, the malware checks the device’s language settings and time zone. If the interface language is a Chinese dialect and the device is located within a Chinese time zone, the malware terminates. It also remains inactive if either the Google Play Store or Google Play Services are absent from the device. If the device passes these checks, the Trojan initiates the PluginTask task. At the start of its routine, PluginTask decrypts the command-and-control server addresses from the code as follows:

1. The encrypted address string is decoded using Base64.
2. The resulting data, a gzip-compressed buffer, is then decompressed.
3. The decompressed data is decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string "ota.host.ba60d29da7fd4794b5c5f732916f7d5c", and the initialization vector is the string "0102030405060708".

After decrypting the C2 server addresses, the Trojan collects victim device metadata, such as the model, IMEI, MAC address, and OS version, and encrypts it using the same method as the server addresses, but this time it utilizes the MD5 hash of the string "ota.api.bbf6e0a947a5f41d7f5226affcfd858c" as the AES key. The encrypted data is sent to the C2 server via a POST request to the path /ak/api/pts/v4. The request parameters include two values:

• m: the MD5 hash of the device IMEI
• n: the network connection type (“w” for Wi-Fi, and “m” for mobile data)

The response from the C2 server contains a code field, which may hold an error code returned by the server. If this field has a zero value, no error has occurred. In this case, the response will include a data field: a JSON object encrypted in the same manner as the request data and containing information about the payloads.

How Keenadu compromised libandroid_runtime.so

After analyzing the initial infection stages, we set out to determine exactly how the backdoor was being integrated into Android device firmware. Almost immediately, we discovered public reports from Alldocube tablet users regarding suspicious DNS queries originating from their devices. This vendor had previously acknowledged the presence of malware in one of its tablet models. However, the company’s statement contained no specifics regarding which malware had compromised the devices or how the breach occurred. We will attempt to answer these questions.

User complaints regarding suspicious DNS queries

The DNS queries described by the original complainant also appeared suspicious to us. According to our telemetry, the Keenadu C2 domains obtained at that time resolved to the IP addresses listed below:

• 67.198.232[.]4
• 67.198.232[.]187

The domains keepgo123[.]com and gsonx[.]com mentioned in the complaint resolved to these same addresses, which may indicate that the complainant’s tablet was also infected with Keenadu. However, matching IP addresses alone is insufficient for a definitive attribution. To test this hypothesis, it was necessary to examine the device itself. We considered purchasing the same tablet model, but this proved unnecessary: as it turns out, Alldocube publishes firmware archives for its devices publicly, allowing anyone to audit them for malware.

To analyze the firmware, one must first determine the storage format of its contents. Alldocube firmware packages are RAR archives containing various image files, other types of files, and a Windows-based flashing utility. From an analytical standpoint, the Android file system holds the most value. Its primary partitions, including the system partition, are contained within the image file super.img. This is an Android Sparse Image. For the sake of brevity, we will omit a technical breakdown of this format (which can be reconstructed from the libsparse code); it is sufficient to note that there are open-source utilities to extract partitions from these files in the form of standard file system images.

We extracted libandroid_runtime.so from the Alldocube iPlay 50 mini Pro (T811M) firmware dated August 18, 2023. Upon examining the library, we discovered the Keenadu backdoor. Furthermore, we decrypted the payload and extracted C2 server addresses hosted on the keepgo123[.]com and gsonx[.]com domains, confirming the user’s suspicions: their devices were indeed infected with this backdoor. Notably, all subsequent firmware versions for this model also proved to be infected, including those released after the vendor’s public statement.

Special attention should be paid to the firmware for the Alldocube iPlay 50 mini Pro NFE model. The “NFE” (Netflix Enabled) part of the name indicates that these devices include an additional DRM module to support high-quality streaming. To achieve this, they must meet the Widevine L1 standard under the Google Widevine DRM premium media protection system. Consequently, they process media within a TEE (Trusted Execution Environment), which mitigates the risk of untrusted code accessing content and thus prevents unauthorized media copying. While Widevine certification failed to protect these devices from infection, the initial Alldocube iPlay 50 mini Pro NFE firmware (released November 7, 2023) was clean – unlike other models’ initial firmware. However, every subsequent version, including the latest release from May 20, 2024, contained Keenadu.

During our analysis of the Alldocube device firmware, we discovered that all images carried valid digital signatures. This implies that simply compromising an OTA update server would have been insufficient for an attacker to inject the backdoor into libandroid_runtime.so. They would also need to gain possession of the private signing keys, which normally should not be accessible from an OTA server. Consequently, it is highly probable that the Trojan was integrated into the firmware during the build phase.

Furthermore, we have found a static library, libVndxUtils.a (MD5: ca98ae7ab25ce144927a46b7fee6bd21), containing the Keenadu code, which further supports our hypothesis. This malicious library is written in C++ and was compiled using the CMake build system. Interestingly, the library retained absolute file paths to the source code on the developer’s machine:

• D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_load.cpp: this file contains the dropper code.
• D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_data.cpp: this file contains the RC4-encrypted payload along with its size metadata.

The dropper’s entry point is the function __log_check_tag_count. The attacker inserted a call to this function directly into the implementation of the println_native method.

Code snippet where the attacker inserted the malicious call

According to our data, the malicious dependency was located within the firmware source code repository at the following paths:

• vendor/mediatek/proprietary/external/libutils/arm/libVndxUtils.a
• vendor/mediatek/proprietary/external/libutils/arm64/libVndxUtils.a

Interestingly, the Trojan within libandroid_runtime.so decrypts and writes the payload to disk at /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. The attacker most likely attempted to disguise the malicious libandroid_runtime.so dependency as a supposedly legitimate “vndx” component containing proprietary code from MediaTek. In reality, no such component exists in MediaTek products.

Finally, according to our telemetry, the Trojan is found not only in Alldocube devices but also in hardware from other manufacturers. In all instances, the backdoor is embedded within tablet firmware. We have notified these vendors about the compromise.

Based on the evidence presented above, we believe that Keenadu was integrated into Android device firmware as the result of a supply chain attack. One stage of the firmware supply chain was compromised, leading to the inclusion of a malicious dependency within the source code. Consequently, the vendors may have been unaware that their devices were infected prior to reaching the market.

Keenadu backdoor modules

As previously noted, the inherent architecture of Keenadu allows attackers to gain virtually unrestricted control over the victim’s device. To understand exactly how they leveraged this capability, we analyzed the payloads downloaded by the backdoor. To achieve this, we crafted a request to the C2 server, masquerading as an infected device. Initially, the C2 server did not deliver any files; instead, it returned a timestamp for the next check-in, scheduled 2.5 months after the initial request. Through black-box analysis of the C2 server, we determined that the request includes the backdoor’s activation time; if 2.5 months have not elapsed since that moment, the C2 will not serve any payloads. This is likely a technique designed to complicate analysis and minimize the probability of these payloads being detected. Once we modified the activation time in our request to a sufficiently distant date in the past, the C2 server returned the list of payloads for analysis.

The attacker’s server delivers information about the payloads as an object array. Each object contains a download link for the payload, its MD5 hash, target app package names, target process names, and other metadata. An example of such an object is provided below. Notably, the attackers chose Amazon AWS as their CDN provider.

Example of payload metadata

Files downloaded by Keenadu utilize a proprietary format to store the encrypted payload and its configuration. A pseudocode description of this format is presented below (struct KeenaduPayload):
struct KeenaduChunk {
uint32_t size;
uint8_t data[size];
} __packed;

struct KeenaduPayload {
int32_t version;
uint8_t padding[0x100];
uint8_t salt[0x20];
KeenaduChunk config;
KeenaduChunk payload;
KeenaduChunk signature;
} __packed;
After downloading, Keenadu verifies the file integrity using MD5. The Trojan’s creators also implemented a code-signing mechanism using the DSA algorithm. The signature is verified before the payload is decrypted and executed. This ensures that only an attacker in possession of the private key can generate malicious payloads. Upon successful verification, the configuration and the malicious module are decrypted using AES-128 in CFB mode. The decryption key is the MD5 hash of the string that is a concatenation of "37d9a33df833c0d6f11f1b8079aaa2dc" and a salt, while the initialization vector is the string "0102030405060708".

The configuration contains information regarding the module’s entry and exit points, its name, and its version. An example configuration for one of the modules is provided below.
{
"stopMethod": "stop",
"startMethod": "start",
"pluginId": "com.ak.p.wp",
"service": "1",
"cn": "com.ak.p.d.MainApi",
"m_uninit": "stop",
"version": "3117",
"clazzName": "com.ak.p.d.MainApi",
"m_init": "start"
}
Having outlined the backdoor’s algorithm for loading malicious modules, we will now proceed to their analysis.

Keenadu loader

This module (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) targets popular online storefronts with the following package names:

• com.amazon.mShop.android.shopping (Amazon)
• com.zzkko (SHEIN)
• com.einnovation.temu (Temu)

The entry point is the start method of the com.ak.p.d.MainApi class. This class initiates a malicious task named HsTask, which serves as a loader conceptually similar to AKServer. Upon execution, the loader collects victim device metadata (model, IMEI, MAC address, OS version, and so on) as well as information regarding the specific app within which it is running. The collected data is encoded using the same method as the AKServer requests sent to /ak/api/pts/v4. Once encoded, the loader exfiltrates the data via a POST request to the C2 server at /ota/api/tasks/v3.

Data collection via the plugin

In response, the attackers’ server returns a list of modules for download and execution, as well as a list of APK files to install on the victim’s device. Interestingly, in newer Android versions, the delivery of these APKs is implemented via installation sessions. This is likely an attempt by the malware to bypass restrictions introduced in recent OS versions, which prevent sideloaded apps from accessing sensitive permissions – specifically accessibility services.

Use of an installation session

Unfortunately, during our research, we were unable to obtain samples of the specific modules and APK files downloaded by this loader. However, users online have reported that infected tablets were adding items to marketplace shopping carts without the user’s knowledge.

User complaint on Reddit

Clicker loader

These modules (such as ad60f46e724d88af6bcacb8c269ac3c1) are injected into the following apps:

• Wallpaper (com.android.wallpaper)
• YouTube (com.google.android.youtube)
• Facebook (com.facebook.katana)
• Digital Wellbeing (com.google.android.apps.wellbeing)
• System launcher (com.android.launcher3)

Upon execution, the malicious module retrieves the device’s location and IP address using a GeoIP service deployed on the attackers’ C2 server. This data, along with the network connection type and OS version, is exfiltrated to the C2. In response, the server returns a specially formatted file containing an encrypted JSON object with payload information, as well as a XOR key for decryption. The structure of this file is described below using pseudocode:
struct Payload {
uint8_t magic[10]; // == "encrypttag"
uint8_t keyLen;
uint8_t xorKey[keyLen];
uint8_t payload[];
} __packed;
The decrypted JSON consists of an array of objects containing download links for the payloads and their respective entry points. An example of such an object is provided below. The payloads themselves are encrypted using the same logic as the JSON.

Example of payload metadata

In the course of our research, we obtained several payloads whose primary objective was to interact with advertising elements on various themed websites: gaming, recipes, and news. Each specific module interacts with one particular website whose address is hardcoded into its source.

Google Chrome module

This module (MD5: 912bc4f756f18049b241934f62bfb06c) targets the Google Chrome browser (com.android.chrome). At the start of its execution, it registers an Activity Lifecycle Callback handler. Whenever an activity is launched within the target app, this handler checks its name. If the name matches the string "ChromeTabbedActivity", the Trojan searches for a text input field (used for search queries and URLs) named url_bar.

Searching for the url_bar text element

If the element is found, the malware monitors text changes within it. All search queries entered by the user into the url_bar field are exfiltrated to the attackers’ server. Furthermore, once the user finishes typing a query, the Trojan can hijack the search request and redirect it to a different search engine, depending on the configuration received from the C2 server.

Search engine hijacking

It is worth noting that the hijacking attempt may fail if the user selects a query from the autocomplete suggestions; in this scenario, the user does not hit Enter or tap the search button in the url_bar, which would signal the malware to trigger the redirect. However, the attackers anticipated this too. The Trojan attempts to locate the omnibox_suggestions_dropdown element within the current activity, a ViewGroup containing the search suggestions. The malware monitors taps on these suggestions and proceeds to redirect the search engine regardless.

Search engine hijacking upon selecting a browser-suggested option

The Nova (Phantom) clicker

The initial version of this module (MD5: f0184f6955479d631ea4b1ea0f38a35d) was a clicker embedded within the system wallpaper picker (com.android.wallpaper). Researchers at Dr. Web discovered it concurrently with our investigation; however, their report did not mention the clicker’s distribution vector via the Keenadu backdoor. The module utilizes machine learning and WebRTC to interact with advertising elements. While our colleagues at Dr. Web named it Phantom, the C2 server refers to it as Nova. Furthermore, the task executed within the code is named NovaTask. Based on this, we believe the original name of the clicker is Nova.

Nova as the plugin name

It is also worth noting that shortly after the publication of the report on this clicker, the Keenadu C2 server began deleting it from infected devices. This is likely a strategic move by the attackers to evade further detection.

Request to unload the Nova module

Interestingly, in the unload request, the Nova module appeared under a slightly different name. We believe this new name disguises the latest version of the module, which functions as a loader capable of downloading the following components:

• The Nova clicker.
• A Spyware module which exfiltrates various types of victim device information to the attackers’ server.
• The Gegu SDK dropper. According to our data, this is a multi-stage dropper that launches two additional clickers.

Install monetization

A module with the MD5 hash 3dae1f297098fa9d9d4ee0335f0aeed3 is embedded into the system launcher (com.android.launcher3). Upon initialization, it runs an environment check for virtual machine artifacts. If none are detected, the malware registers an event handler for session-based app installations.

Handler registration

Simultaneously, the module requests a configuration file from the C2 server. An example of this configuration is provided below.

Example of a monetization module configuration

When an app installation is initiated on the device, the Trojan transmits data on this app to the C2 server. In response, the server provides information regarding the specific ad used to promote it.

App ad source information

For every successfully completed installation session, the Trojan executes GET requests to the URL provided in the tracking_link field in the response, as well as the first link within the click array. Based on the source code, the links in the click array serve as templates into which various advertising identifiers are injected. The attackers most likely use this method to monetize app installations. By simulating traffic from the victim’s device, the Trojan deceives advertising platforms into believing that the app was installed from a legitimate ad tap.

Google Play module

Even though AKClient shuts down if it is injected into Google Play process, the C2 server have provided us with a payload for it. This module (MD5: 529632abf8246dfe555153de6ae2a9df) retrieves the Google Ads advertising ID and stores it via a global instance of the Settings class under the key S_GA_ID3. Subsequently, other modules may utilize this value as a victim identifier.

Retrieving the advertising ID

Other Keenadu distribution vectors

During our investigation, we decided to look for alternative sources of Keenadu infections. We discovered that several of the modules described above appeared in attacks that were not linked to the compromise of libandroid_runtime.so. Below are the details of these alternative vectors.

System apps

According to our telemetry, the Keenadu loader was found within various system apps in the firmware of several devices. One such app (MD5: d840a70f2610b78493c41b1a344b6893) was a face recognition service with the package name com.aiworks.faceidservice. It contains a set of trained machine-learning models used for facial recognition – specifically for authorizing users via Face ID. To facilitate this, the app defines a service named com.aiworks.lock.face.service.FaceLockService, which the system UI (com.android.systemui) utilizes to unlock the device.

Using the face recognition service in the System UI

Within the onCreate method of the com.aiworks.lock.face.service.FaceLockService, triggered upon that service’s creation, three receivers are registered. These receivers monitor screen on/off events, the start of charging, and the availability of network access. Each of these receivers calls the startMars method whose primary purpose is to initialize the malicious loader by calling the init method of the com.hs.client.TEUtils class.

Malicious call

The loader is a slightly modified version of the Keenadu loader. This specific variant utilizes a native library libhshelper.so to load modules and facilitate APK installs. To accomplish this, the library defines corresponding native methods within the com.hs.helper.NativeMain class.

Native methods defined by the library

This specific attack vector – embedding a loader within system apps – is not inherently new. We have previously documented similar cases, such as the Dwphon loader, which was integrated into system apps responsible for OTA updates. However, this marks the first time we have encountered a Trojan embedded within a facial recognition service.

In addition to the face recognition service, we identified other system apps infected with the Keenadu loader. These included the launcher app on certain devices (MD5: 382764921919868d810a5cf0391ea193). A malicious service, com.pri.appcenter.service.RemoteService, was embedded into these apps to trigger the Trojan’s execution.

We also discovered the Keenadu loader within the app with package name com.tct.contentcenter (MD5: d07eb2db2621c425bda0f046b736e372). This app contains the advertising SDK fwtec, which retrieved its configuration via an HTTP GET request to hxxps://trends.search-hub[.]cn/vuGs8 with default redirection disabled. In response, the Trojan expected a 302 redirect code where the Location header provided an URL containing the SDK configuration within its parameters. One specific parameter, hsby_search_switch, controlled the activation of the Keenadu loader: if its value was set to 1, the loader would initialize within the app.

Retrieving the configuration from the C2

Loading via other backdoors

While analyzing our telemetry, we discovered an unusual version of the Keenadu loader (MD5: f53c6ee141df2083e0200a514ba19e32) located in the directories of various apps within external storage, specifically at paths following the pattern: /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. Based on the code analysis, this loader was designed to operate within a system where the system_server process had already been compromised. Notably, the binder interface names used in this version differed from those used by AKServer. The loader utilized the following interfaces:

• com.androidextlib.sloth.api.IPServiceM
• com.androidextlib.sloth.api.IPermissionsM

These same binder interfaces are defined by another backdoor that is structured similarly and was also discovered within libandroid_runtime.so. The execution of this other backdoor on infected devices proceeds as follows: libandroid_runtime.so imports a malicious function __android_log_check_loggable from the liblog.so library (MD5: 3d185f30b00270e7e30fc4e29a68237f). This function is called within the implementation of the println_native native method of the android.util.Log class. It decrypts a payload embedded in the library’s body using a single-byte XOR and executes it within the context of all apps on the device.

Payload decryption

The payload shares many similarities with BADBOX, a comprehensive malware platform first described by researchers at HUMAN Security. Specifically, the C2 server paths used for the Trojan’s HTTP requests are a match. This leads us to believe that this is a specific variant of BADBOX.

The path /terminal/client/register was previously documented in a HUMAN Security report

Within this backdoor, we also discovered the binder interfaces utilized by the aforementioned Keenadu loader. This suggests that those specific instances of Keenadu were deployed directly by BADBOX.

One of the binder interfaces used by Keenadu is defined in the payload

Modifications of popular apps

Unfortunately, even if your firmware does not contain Keenadu or another pre-installed backdoor, the Trojan still poses a threat to you. The Nova (Phantom) clicker was discovered by researchers at Dr. Web around the same time as we held our investigation. Their findings highlight a different distribution vector: modified versions of popular software distributed primarily through unofficial sources, as well as various apps found in the GetApps store.

Google Play

Infected apps have managed to infiltrate Google Play too. During our research, we identified trojanized software for smart cameras published on the official Android app store. Collectively, these apps had been downloaded more than 300,000 times.

Examples of infected apps in Google Play

Each of these apps contained an embedded service named com.arcsoft.closeli.service.KucopdInitService, which launched the aforementioned Nova clicker. We alerted Google to the presence of the infected apps in its store, and they removed the malware. Curiously, while the malicious service was present in all identified apps, it was configured to execute only in one specific package: com.taismart.global.

The malicious service was launched only under specific conditions

The Fantastic Four: how Triada, BADBOX, Vo1d, and Keenadu are connected

After discovering that BADBOX downloads one of the Keenadu modules, we decided to conduct further research to determine if there were any other signs of a connection between these Trojans. As a result, we found that BADBOX and Keenadu shared similarities in the payload code that was decrypted and executed by the malicious code in libandroid_runtime.so. We also identified similarities between the Keenadu loader and the BB2DOOR module of the BADBOX Trojan. Given that there are also distinct differences in the code, and considering that BADBOX was downloading the Keenadu loader, we believe these are separate botnets, and the developers of Keenadu likely found inspiration in the BADBOX source code. Furthermore, the authors of Keenadu appear to target Android tablets primarily.

In our recent report on the Triada backdoor, we mentioned that the C2 server for one of its downloaded modules was hosted on the same domain as one of the Vo1d botnet’s servers, which could suggest a link between those two Trojans. However, during the current investigation, we managed to uncover a connection between Triada and the BADBOX botnet as well. As it turns out, the directories where BADBOX downloaded the Keenadu loader also contained other payloads for various apps. Their description warrants a separate report; for the sake of brevity, we will not delve into the details here, limiting ourselves to the analysis of a payload for the Telegram and Instagram clients (MD5: 8900f5737e92a69712481d7a809fcfaa). The entry point for this payload is the com.extlib.apps.InsTGEnter class. The payload is designed to steal victims’ account credentials in the infected services. Interestingly, it also contains code for stealing credentials from the WhatsApp client, though it is currently not utilized.

BADBOX payload code used for stealing credentials from WhatsApp clients

The C2 server addresses used by the Trojan to exfiltrate device data are stored in the code in an encrypted format. They are first decoded using Base64 and then decrypted via a XOR operation with the string "xiwljfowkgs".

Decrypted payload C2 addresses

After decrypting the C2 addresses, we discovered the domain zcnewy[.]com, which we had previously identified in 2022 during our investigation of malicious WhatsApp mods containing Triada. At that time, we assumed that the code segment responsible for stealing WhatsApp credentials and the malicious dropper both belonged to Triada. However, since we have now established that zcnewy[.]com is linked to BADBOX, we believe that the infected WhatsApp modifications we described in 2022 actually contained two distinct Trojans: Triada and BADBOX. To verify this hypothesis, we re-examined one of those modifications (MD5: caa640824b0e216fab86402b14447953) and confirmed that it contained the code for both the Triada dropper and a BADBOX module functionally similar to the one described above. Although the Trojans were launched from the same entry point, they did not interact with each other and were structured in entirely different ways. Based on this, we conclude that what we observed in 2022 was a joint attack by the BADBOX and Triada operators.

BADBOX and Triada launched from the same entry point

These findings show that several of the largest Android botnets are interacting with one another. Currently, we have confirmed links between Triada, Vo1d, and BADBOX, as well as the connection between Keenadu and BADBOX. Researchers at HUMAN Security have also previously reported a connection between Vo1d and BADBOX. It is important to emphasize that these connections are not necessarily transitive. For example, the fact that both Triada and Keenadu are linked to BADBOX does not automatically imply that Triada and Keenadu are directly connected; such a claim would require separate evidence. However, given the current landscape, we would not be surprised if future reports provide the evidence needed to prove the transitivity of these relationships.

Victims

According to our telemetry, 13,715 users worldwide have encountered Keenadu or its modules. Our security solutions recorded the highest number of users attacked by the malware in Russia, Japan, Germany, Brazil and the Netherlands.

Recommendations

Our technical support team is often asked what steps should be taken if a security solution detects Keenadu on a device. In this section, we examine all possible scenarios for combating this Trojan.

If the libandroid_runtime.so library is infected

Modern versions of Android mount the system partition, which contains libandroid_runtime.so, as read-only. Even if one were to theoretically assume the possibility of editing this partition, the infected libandroid_runtime.so library cannot be removed without damaging the firmware: the device would simply cease to boot. Therefore, it is impossible to eliminate the threat using standard Android OS tools. Operating a device infected with the Keenadu backdoor can involve significant inconveniences. Reviews of infected devices complain about intrusive ads and various mysterious sounds whose source cannot be identified.

Review of an infected tablet complaining about noise

If you encounter the Keenadu backdoor, we recommend the following:

• Check for software updates. It is possible that a clean firmware version has already been released for your device. After updating, use a reliable security solution to verify that the issue has been resolved.
• If a clean firmware update from the manufacturer does not exist for your device, you can attempt to install a clean firmware yourself. However, it is important to remember that manually flashing a device can brick it.
• Until the firmware is replaced or updated, we recommend that you stop using the infected device.

If one of the system apps is infected

Unfortunately, as in the previous case, it is not possible to remove such an app from the device because it is located in the system partition. If you encounter the Keenadu loader in a system app, our recommendations are:

1. Find a replacement for the app, if applicable. For example, if the launcher app is infected, you can download any alternative that does not contain malware. If no alternatives exist for the app – for example, if the face recognition service is infected – we recommend avoiding the use of that specific functionality whenever possible.
2. Disable the infected app using ADB if an alternative has been found or you don’t really need it. This can be done with the command adb shell pm disable --user 0 %PACKAGE%.

If an infected app has been installed on the device

This is one of the simplest cases of infection. If a security solution has detected an app infected with Keenadu on your device, simply uninstall it following the instructions the solution provides.

Conclusion

Developers of pre-installed backdoors in Android device firmware have always stood out for their high level of expertise. This is still true for Keenadu: the creators of the malware have a deep understanding of the Android architecture, the app startup process, and the core security principles of the operating system. During the investigation, we were surprised by the scope of the Keenadu campaigns: beyond the primary backdoor in firmware, its modules were found in system apps and even in apps from Google Play. This places the Trojan on the same scale as threats like Triada or BADBOX. The emergence of a new pre-installed backdoor of this magnitude indicates that this category of malware is a distinct market with significant competition.

Keenadu is a large-scale, complex malware platform that provides attackers with unrestricted control over the victim’s device. Although we have currently shown that the backdoor is used primarily for various types of ad fraud, we do not rule out that in the future, the malware may follow in Triada’s footsteps and begin stealing credentials.

Indicators of compromise

Additional IoCs, technical details and a YARA rule for detecting Keenadu activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

Malicious libandroid_runtime.so libraries
bccd56a6b6c9496ff1acd40628edd25e
c4c0e65a5c56038034555ec4a09d3a37
cb9f86c02f756fb9afdb2fe1ad0184ee
f59ad0c8e47228b603efc0ff790d4a0c
f9b740dd08df6c66009b27c618f1e086
02c4c7209b82bbed19b962fb61ad2de3
185220652fbbc266d4fdf3e668c26e59
36db58957342024f9bc1cdecf2f163d6
4964743c742bb899527017b8d06d4eaa
58f282540ab1bd5ccfb632ef0d273654
59aee75ece46962c4eb09de78edaa3fa
8d493346cb84fbbfdb5187ae046ab8d3
9d16a10031cddd222d26fcb5aa88a009
a191b683a9307276f0fc68a2a9253da1
65f290dd99f9113592fba90ea10cb9b3
68990fbc668b3d2cfbefed874bb24711
6d93fb8897bf94b62a56aca31961756a

Keenadu payloads
2922df6713f865c9cba3de1fe56849d7
3dae1f297098fa9d9d4ee0335f0aeed3
462a23bc22d06e5662d379b9011d89ff
4c4ca7a2a25dbe15a4a39c11cfef2fb2
5048406d8d0affa80c18f8b1d6d76e21
529632abf8246dfe555153de6ae2a9df
7ceccea499cfd3f9f9981104fc05bcbd
912bc4f756f18049b241934f62bfb06c
98ff5a3b5f2cdf2e8f58f96d70db2875
aa5bf06f0cc5a8a3400e90570fb081b0
ad60f46e724d88af6bcacb8c269ac3c1
dc3d454a7edb683bec75a6a1e28a4877
f0184f6955479d631ea4b1ea0f38a35d

System applications infected with Keenadu loader
07546413bdcb0e28eadead4e2b0db59d
0c1f61eeebc4176d533b4fc0a36b9d61
10d8e8765adb1cbe485cb7d7f4df21e4
11eaf02f41b9c93e9b3189aa39059419
19df24591b3d76ad3d0a6f548e608a43
1bfb3edb394d7c018e06ed31c7eea937
1c52e14095f23132719145cf24a2f9dc
21846f602bcabccb00de35d994f153c9
2419583128d7c75e9f0627614c2aa73f
28e6936302f2d290c2fec63ca647f8a6
382764921919868d810a5cf0391ea193
45bf58973111e00e378ee9b7b43b7d2d
56036c2490e63a3e55df4558f7ecf893
64947d3a929e1bb860bf748a15dba57c
69225f41dcae6ddb78a6aa6a3caa82e1
6df8284a4acee337078a6a62a8b65210
6f6e14b4449c0518258beb5a40ad7203
7882796fdae0043153aa75576e5d0b35
7c3e70937da7721dd1243638b467cff1
9ddd621daab4c4bc811b7c1990d7e9ea
a0f775dd99108cb3b76953e25f5cdae4
b841debc5307afc8a4592ea60d64de14
c57de69b401eb58c0aad786531c02c28
ca59e49878bcf2c72b99d15c98323bcd
d07eb2db2621c425bda0f046b736e372
d4be9b2b73e565b1181118cb7f44a102
d9aecc9d4bf1d4b39aa551f3a1bcc6b7
e9bed47953986f90e814ed5ed25b010c

Applications infected with Nova clicker
0bc94bc4bc4d69705e4f08aaf0e976b3
1276480838340dcbc699d1f32f30a5e9
15fb99660dbd52d66f074eaa4cf1366d
2dca15e9e83bca37817f46b24b00d197
350313656502388947c7cbcd08dc5a95
3e36ffda0a946009cb9059b69c6a6f0d
5b0726d66422f76d8ba4fbb9765c68f6
68b64bf1dea3eb314ce273923b8df510
9195454da9e2cb22a3d58dbbf7982be8
a4a6ff86413b3b2a893627c4cff34399
b163fa76bde53cd80d727d88b7b1d94f
ba0a349f177ffb3e398f8c780d911580
bba23f4b66a0e07f837f2832a8cd3bd4
d6ebc5526e957866c02c938fc01349ee
ec7ab99beb846eec4ecee232ac0b3246
ef119626a3b07f46386e65de312cf151
fcaeadbee39fddc907a3ae0315d86178

Payload CDN
ubkt1x.oss-us-west-1.aliyuncs[.]com
m-file-us.oss-us-west-1.aliyuncs[.]com
pkg-czu.istaticfiles[.]com
pkgu.istaticfiles[.]com
app-download.cn-wlcb.ufileos[.]com

C2 servers
110.34.191[.]81
110.34.191[.]82
67.198.232[.]4
67.198.232[.]187
fbsimg[.]com
tmgstatic[.]com
gbugreport[.]com
aifacecloud[.]com
goaimb[.]com
proczone[.]com
gvvt1[.]com
dllpgd[.]click
fbgraph[.]com
newsroomlabss[.]com
sliidee[.]com
keepgo123[.]com
gsonx[.]com
gmsstatic[.]com
ytimg2[.]com
glogstatic[.]com
gstatic2[.]com
uscelluliar[.]com
playstations[.]click

securelist.com/keenadu-android…

Although off-the-shelf breadboards are plentiful and cheap, they almost always seem to use the same basic design. Although you can clumsily reassemble most of them by removing the voltage rail section and merging a few boards together, wouldn’t it be nice if you had a breadboard that you could stick e.g. one of those wide ESP32 development boards onto and still have plenty of holes to poke wires and component leads into? Cue [Ludwin]’s 3D printable breadboard design that adds a big hole where otherwise wasted contact holes would be.

The related Instructables article provides a visual overview of the rationale and the assembly process. Obviously only the plastic shell of the breadboard is printed, after which the standard metal contacts are inserted. These contacts can be ‘borrowed’ from commercial boards, or you can buy the contacts separately.

For the design files there is a GitHub repository, with breadboard designs that target the ESP32, Raspberry Pi Pico, and the Arduino Nano. An overview of the currently available board designs is found on the Hackaday.io project page, with the top image showing many of them. In addition to the single big space design there are also a few variations that seek to accommodate just about any component and usage, making it rather versatile.

hackaday.com/2026/02/17/using-…

il ruolo delle tecnologie cyber europee tra strategia e geopolitica

Con l’evoluzione del quadro normativo europeo in ambito cyber e data protection, il tema della Digital Repatriation è destinato a diventare sempre più centrale nel 2026.

Per Digital Repatriation si intende il processo attraverso il quale dati, infrastrutture digitali e servizi critici vengono riportati sotto il controllo diretto di entità europee, garantendo maggiore sovranità, conformità normativa e riduzione dei rischi legati a dipendenze extra-UE.

Le nuove regolamentazioni europee – tra cui NIS2, DORA, Cyber Resilience Act e le normative sulla supply chain – spingono le organizzazioni a sapere:

• dove risiedono i dati
• chi li gestisce
• quali terze parti sono coinvolte
• e come rispondere in modo efficace a incidenti e attacchi cyber

In questo scenario, la Digital Repatriation non è solo una scelta tecnologica, ma una decisione strategica, legale e di business.

L’evento

Un incontro esclusivo organizzato da ESET & Cyberating, pensato per approfondire il tema della Digital Repatriation da tre prospettive complementari: legale, di gestione del rischio e tecnologica.

Dove: Hotel Gallia – Piazza Duca d’Aosta, 9 – Milan
Quando: 10 marzo
A che ora: 9:30 – 15:00

Agenda & Speaker
9:30 – 10:00 | Welcome coffee

Accoglienza e networking iniziale
10:00 – 10:25 | Benvenuto e apertura dei lavori

Fabio Buccigrossi – Country Manager ESET Italia e Stefano Fratepietro – CEO Cyberating
10:25 – 11:10 | L’illusione della neutralità tecnologica:
digital repatriation e potere geopolitico

­

Stefano Mele – Avvocato

L’intervento analizza la digital repatriation non come una mera scelta tecnica o di compliance, ma come una decisione geopolitica che incide su sovranità, sicurezza nazionale, autonomia strategica e posizionamento internazionale di Stati e imprese.

Rimpatriare dati, infrastrutture o capacità tecnologiche significa ridefinire dipendenze, alleanze e margini di manovra, soprattutto nel campo della cybersecurity, dove il controllo delle tecnologie coincide sempre più con il controllo del rischio.
11:10 – 11:55 | Controllo della Supply Chain:
Automazione, Sovranità Digitale e Third-Party Risk Management in Europa

Stefano Fratepietro – CEO Cyberating

Approfondimento sulla gestione dei fornitori e delle terze parti:
ruolo delle piattaforme di Third-Party Risk Management
valutazione e monitoraggio dei rischi lungo la supply chain
importanza della visibilità sui fornitori in un contesto normativo stringente
11:55 – 12:40 | Il punto di vista tecnologico: l’approccio ESET

Samuele Zaniboni – Sales Engineering Manager ESET Italia

Focus operativo su Digital Repatriation:
utilizzo della Threat Intelligence per anticipare rischi e minacce
ruolo dei servizi MDR di ESET nel supportare controllo, sovranità e resilienza
integrazione di sicurezza, compliance e risposta agli incidenti
12:40 – 14:00 | Light lunch & networking

Un momento informale per confrontarsi con i relatori e il team ESET & Cyberating.

Moderatore evento: Arturo Di Corinto

dicorinto.it/formazione/digita…

C'è una direttiva EU in arrivo, la Product Liability Directive (PLD2 per gli amici) che finalmente dice che il software è un prodotto. E che chi lo vende ne è responsabile. Tempi duri in arrivo per Big Tech e cialtroni assortiti...

spreaker.com/episode/dk-10x22-…

More molten plastic spacers between the bus bar and terminal. (Credit: Will Prowse)
Because size matters when it comes to statistics, [Will Prowse] decided to not just bank on his handful of failed Battle Born LFP batteries when it came to documenting their failure modes. Instead he got a whole gaggle of them from a viewer who had experienced failures with their Battle Born LFP batteries for an autopsy, adding a total of 15 samples to the data set.

Interestingly, the symptoms of these dead batteries are all over the place, from a refusal to charge, some have the overheating terminal, some do not show any sign of life, others have charged cells but a non-responsive BMS, etc. As [Will] notes, it’s important to test batteries with a load and a charger to determine whether they are functional not just whether you can measure a charge.

Although some of the batteries still showed enough signs of life to be put aside for some load testing, the remaining ones were cut open to check their insides. This revealed the typical molten plastic at the terminals, but also a lot of very loose connections for the internal wiring. Another battery showed signs of corrosion inside, which could be due to either moisture intrusion or a cell having leaked its electrolyte.

While the full results will hopefully be released soon, the worrying thing about this latest batch of Battle Born LFP batteries is that they span quite a few years, with one being from 2018. Although it’s comforting that not every one of these batteries is necessarily going to catch on fire within its approximate 8-year lifespan, a lot seems to depend on exactly how you load and charge them, as [Will] is trying to figure out with the upcoming load testing. With the unit that he recently purchased for testing it turned out that lower currents actually made the melting problem much worse.

Between this video and the much awaited follow-up, [Will] actually got his hands on a troubled 300A-rated industrial Battle Born battery. During testing that one actually failed violently with a cell venting and the loose BMS rattling around in the case.

youtube.com/embed/DUtbnbLpvFk?…

hackaday.com/2026/02/16/perfor…

With more and more sensors being crammed into the consumer devices that many of us wear every day, the question of where medical devices begin and end, and how they should be regulated become ever more pertinent. When a ‘watch’ no longer just shows the time, but can keep track of a dozen vital measurements, and the line between ‘earbud’ and ‘hearing aid’ is a rather fuzzy one, this necessitates that institutions like the US FDA update their medical device rules, as was done recently in its 2026 update.

This determines how exactly these devices are regulated, and in how far their data can be used for medical purposes. An important clarification made in the 2026 update is the distinction between ‘medical information’ and ‘signals/patterns’. Meaning that while a non-calibrated fitness tracker or smart watch does not provide medically valid information, it can be used to detect patterns and events that warrant a closer look, such as indications of arrhythmia or low blood oxygen saturation.

As detailed in the IEEE Spectrum article, these consumer devices are thus ‘general wellness’ devices, and should be marketed as such, without embellished claims. Least of all should they be sold as devices that can provide medical information.

Another major aspect with these general wellness devices is what happens to the data that they generate. While not medical information, it does provide health information about a person that e.g. a marketing company would kill for to obtain. This privacy issue is unresolved in the US market, while other countries prescribe strict requirements about such data handling.

Effectively, this leaves the designers of wearables relatively free to do whatever they want, as long as they do not claim that the medical data being produced from any sensors is medical information. How this data is being handled is strictly regulated in most markets, except for the US, which is quite worrying and something you should definitely be aware of.

As for other medical device purposes like hearing aids, the earbuds capable of this fortunately do not generally collect information. They do need to have local regulatory approval to enable the feature, however, even if you can bypass any geofencing with some creative hacking.

hackaday.com/2026/02/16/what-t…

[GreatScott] has recently been tinkering in the world of radio frequency emissions, going so far as to put their own designs in a proper test chamber to determine whether they meet contemporary standards for noise output. This led them to explore the concept of shielding, and how a bit of well-placed metal can make all the difference in this regard.

The video focuses on three common types of shielding—absorber sheets, shielding tapes, and shielding cabinets. A wide variety of electronic devices use one or more of these types of shielding. [GreatScott] shows off their basic effectiveness by putting various types of shielding in between a noise source and a near-field probe hooked up to a receiver. Just placing a bit of conductive material in between the two can cut down on noise significantly. Then, a software defined radio (SDR) was busted out for some more serious analysis. [GreatScott] shows how Faraday cages (or simple shielding cabinets] can be used to crush down spurious RF outputs to almost nothing, and how his noisy buck-boost designs can be quieted down with the use of the right absorber sheets that deal well with the problematic frequencies in question. The ultimate upshot of the tests is that higher frequencies respond best to conductive shielding that is well enclosed, while lower frequency noise benefits from more absorptive shielding materials with the right permeability for the job.

Shielding design can be a complex topic that you probably won’t master in a ten minute YouTube video, but this content is a great primer if you’re new to the topic. We’ve covered the topic before, too, particularly on how a bit of DIY shielding can really aid a cheap SDR’s performance. Video after the break.

youtube.com/embed/n5KC1TlKKwQ?…

hackaday.com/2026/02/16/a-basi…

For a long while, digital single-lens reflex (DSLR) cameras were the king of the castle for professional and amateur photography. They brought large sensors, interchangeable lenses, and professional-level viewfinders to the digital world at approachable prices, and then cemented their lead when they started being used to create video as well. They’re experiencing a bit of a decline now, though, as mirrorless cameras start to dominate, and with that comes some unique opportunities. To attach a lens meant for a DSLR to a mirrorless camera, an adapter housing must be used, and [Ancient] found a way to squeeze a computer and a programmable aperture into this tiny space.

The programmable aperture is based on an LCD screen from an old cell phone. LCD screens are generally transparent until their pixels are switched, and in most uses as displays a backer is put in place so someone can make out what is on the screen. [Ancient] is removing this backer, though, allowing the LCD to be completely transparent when switched off. The screen is placed inside this lens adapter housing in the middle of a PCB where a small computer is also placed. The computer controls the LCD via a set of buttons on the outside of the housing, allowing the photographer to use this screen as a programmable aperture.

The LCD-as-aperture has a number of interesting uses that would be impossible with a standard iris aperture. Not only can it function as a standard iris aperture, but it can do things like cycle through different areas of the image in sequence, open up arbitrary parts or close off others, and a number of other unique options. It’s worth checking out the video below, as [Ancient] demonstrates many of these effects towards the end. We’ve seen some of these effects before, although those were in lenses that were mechanically controlled instead.

youtube.com/embed/Kg_2MAgS_pE?…

Thanks to [kemfic] for the tip!

hackaday.com/2026/02/16/a-comp…

You may not remember [Mr. Wizard], but he was a staple of nerd kids over a few decades, teaching science to kids via the magic of television. The Computer History Archives Project has a partially restored film of [Mr. Wizard] showing off sounds and noise on a state-of-the-art (for 1963) Tektronix 504 oscilloscope. He talks about noise and also shows the famous IBM mainframe rendition of the song “Daisy Bell.” You can see the video along with some extras below.

You might recall that the movie “2001: A Space Odyssey” paid homage to the IBM computer’s singing debut by having HAL 9000 sing the same song as it is being deactivated. The idea that HAL was IBM “minus one” has been repeatedly denied, but we still remain convinced.

Can you imagine a TV show these days that would teach kids about signal-to-noise ratio or even show them an actual oscilloscope? We suppose that’s what YouTube is for.

At about the 17-minute mark, you can see some enormous walkie-talkies. A far cry from today’s cell phones. At the 27-minute mark, another film shows how engineers at Bell created the song using a mainframe.

We wish there were a modern version of [Mr. Wizard]. Then again, there’s no reason you can’t fill in. You might not be on TV, but you can always drop in on a few classrooms.

youtube.com/embed/l381_ho8KR8?…

hackaday.com/2026/02/16/retrot…

Isn’t this glorious? If you don’t recognize what this is right away (or from the post title), it’s an AlphaSmart NEO word processor, repackaged in a 3D-printed typewriter-esque shell, meticulously designed by the renowned [Un Kyu Lee] of Micro Journal fame.

Image by [Un Kyu Lee] via GitHubIf you don’t want to spend roughly 40 hours printing ~1 kg of filament in order to make your own, you can join the wait-list on Tindie like I did. Go here to figure out which color you want, and email [Un Kyu Lee] when you order. In the meantime, you can watch the assembly video and then check out this playlist that shows the available colors.

Assembly looks easy enough; there’s no soldering, but you do have to disconnect and reconnect the fiddly ribbon cables. After that, it’s just screws.

This design happened by accident. A friend named [Hook] who happens to manage the AlphaSmart Flickr community had given [Un Kyu Lee] a NEO2 to try out, but before he could, it fell from a shelf and the enclosure suffered a nasty hole near the screen. But the internals seemed fine, so he got the idea to design a new enclosure.

I don’t believe the knobs do anything, but they sure do look nice. There’s an area along the top where you can clip a light, since the NEO has no backlight. There are also two smaller slots on the sides if your light won’t clip to the top.

I’d really like to do this to one of my NEOs. I have two NEO regulars, but reviewers on Tindie report that it works just as well with those as the NEO2.

IBM 701c Butterfly Keyboard Flaps Its Wings Again

I feel like this wonderful laptop and its butterfly keyboard come up often enough, but for today’s lucky 10,000, the IBM 701C laptop has a sweet keyboard that automatically extends when the lid is opened, kind of like one of those special birthday cards.

Image by [LCLDIY] via Hackaday.IO[LCLDIY] found such a laptop at a junkyard with no screen, a damaged motherboard, and a shell that’s old and broken. He decided to try to save it with 3D printing, and well, it worked.

First, he obtained a replacement screen and motherboard, and set about modeling a new case. Be sure to watch the video below so you can catch the machine [LCLDIY] does his modeling on. Now, here’s a surprise: the filament is all hand-spun from plastic bottles he collected from the streets.

Once the case was done, he ran into a slight problem. Namely, the keyboard has a ribbon cable and not a USB interface, so he had to make a PCB to handle that and get it over to the motherboard. Really, [LCLDIY] did so much more than save a keyboard; he built an entire laptop around it. To that, I say kudos. Kudos from Kristina.

youtube.com/embed/DQmLzOEAn7E?…

The Centerfold: the Smurve80 Is a Thing You Could Buy

Image via reddit
What is this? A baby Model M? A Unicomp? Neither — it is the Smurve80 from Play Keyboard x Swagkeys. This 87-key TKL is heavily inspired by the Model M, however, down to the curved keyboard. And the name? It’s an amalgamation of ‘smile’ and ‘curve’, and this is reflected in the unfortunately Amazon-like logo in the upper left. I might get one anyway. I haven’t decided. If I do, you can bet I will probably be reviewing it.

Here’s the full info post, and here’s the post about the group buy, which is live now (NA link) through February 16th at 10PM ET. Not in North America? Check the group buy post for a list of vendors. For a mere $100, this baby can be yours in either Sandstone (pictured) or Graphite (semi-pictured), and that’s the fully assembled price. There’s also a bare-bones kit version. The best part, aside from the price, has to be the built-in solenoid. So you can get it with reds if you want, but it’s gonna be loud regardless. Just kidding; you can switch off the solenoid.

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: the Wellington

Are you familiar with Wellington Parker Kidder? His name is nearly as one with typewriter history as Christopher Latham Sholes (the guy responsible for QWERTY). I myself had not heard of Kidder, but his name is directly and indirectly associated with dozens of machines, including the Franklin, the Rochester, and the Noiseless, which was later bought by Remington. Then there’s all the clones of his work.
Image via The Antikey Chop
Kidder’s patents for the Wellington first appeared in 1892. The appeal of this machine is in the thrust-action type bars, which punch the platen rather than swinging to strike it. The design was well-received, and the Wellington was produced virtually unchanged from 1892 to 1924.

There were two models, No. 1 and No. 2. The former had square key tops, while the latter featured rounded key tops. Both models had a three-row keyboard with a double-shift mechanism, and used an extra-wide ribbon. They also both had that attractive cover on the type bars that reminds me of the fender skirts on, say, a 1950 Mercury.

And much like that 1950 Mercury, Wellingtons were well-built, but unfortunately the passage of time has proven them to be rust buckets. That’s really sad to me and I wish I could forget the fact.

The Wellington sold well enough in the States, but it really shone in Europe. Many typewriters are based on the either the overall design, or at least the type bar mechanism. Antikey Chop calls Kidder’s Wellington one of the most influential typewriters of all time, and I believe it.

Finally, the Zerowriter Is Shipping For Early Backers

In case you don’t have an AlphaSmart NEO and/or dislike the Freewrite for whatever reason, there’s also the Zerowriter, created by a one-man team out of Canada. You can pre-order it today for $279 and it’ll ship March 30th for free, worldwide.
Image via Good E-Reader
So, what is this thing? It’s a distraction-free writing tool with an e-ink screen and a low-profile mechanical keyboard. The battery is supposed to last a long time, and it’s cheaper than a Freewrite.

This thing has Kailh Choc Pro red switches, which are thankfully hot-swappable. Much like the NEO, it comes on and is instantly ready for typing. There’s no account to register, no login to memorize. Files are saved as .txt to a microSD card and can be transferred to a computer, though unlike the NEO, there’s a companion app standing between you and file transfer.

That said, this baby uses an ESP32 and was coded in Arduino, so do what you will. The battery is supposed to last for weeks of daily use on a single charge. It’s a user-replaceable LiPo pouch with USB-C charging. They actually encourage you to open her up, and I think that’s great.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

hackaday.com/2026/02/16/keebin…

D-engine of the Claymills Pumping Station. (Credit: John M)
Although infrastructure like a 19th-century pumping station generally tends to be quietly decommissioned and demolished, sometimes you get enough people looking at such an object and wondering whether maybe it’d be worth preserving. Such was the case with the Claymills Pumping Station in Staffordshire, England. After starting operations in the late 19th century, the pumping station was in active use until 1971. In a recent documentary by the Claymills Pumping Station Trust, as the start of their YouTube channel, the derelict state of the station at the time is covered, as well as its long and arduous recovery since they acquired the site in 1993.

After its decommissioning, the station was eventually scheduled for demolition. Many parts had by that time been removed for display elsewhere, discarded, or outright stolen for the copper and brass. Of the four Woolf compounding rotative beam engines, units A and B had been shut down first and used for spare parts to keep the remaining units going. Along with groundwater intrusion and a decaying roof, it was in a sorry state after decades of neglect. Restoring it was a monumental task.

The inventor of the compounding beam engine, Arthur Woolf, was a Cornish engineer who had figured out how to make this more efficient steam engine work. While his engineering made pumping stations like these possible, the many workers and their families ensured that they kept working smoothly. Although firmly obsolete in the 21st century, pumping stations like these are excellent examples of all the engineering and ingenuity that got us to where we are today, and preserving them is the best way to retain all this knowledge and the memories associated with them.

For that reason, one can really congratulate the volunteers who turned this piece of history into a museum. It features a static display of the restored machinery. If you want to see it running, there are seven demonstrations of the station operating under steam every year, during which the six-story tall machinery can be observed in all its glory.

Top image: Claymills Pumping Station in 2010. (Credit: Ashley Dace)

youtube.com/embed/tYvqV27G4c8?…

hackaday.com/2026/02/16/how-vo…

Once upon a time, the cathode ray tube was pretty much the only type of display you’d find in a consumer television. As the analog broadcast world shifted to digital, we saw the rise of plasma displays and LCDs, which offered greater resolution and much slimmer packaging. Then there was the so-called LED TV, confusingly named—for it was merely an LCD display with an LED backlight. The LEDs were merely lamps, with the liquid crystal doing all the work of displaying an image.

Today, however, we are seeing the rise of true LED displays. Sadly, decades of confusing marketing messages have polluted the terminology, making it a confusing space for the modern television enthusiast. Today, we’ll explore how these displays work and disambiguate what they’re being called in the marketplace.

The Rise Of Emissive Displays

When it comes to our computer monitors and televisions, most of us have got used to the concept of backlit LCD displays. These use a bright white backlight to actually emit light, which is then filtered by the liquid crystal array into all the different colored pixels that make up the image. It’s an effective way to build a display, with a serious limitation on contrast ratio because the LCD is only so good at blocking out light coming from behind. Over time, these displays have become more sophisticated, with manufacturers ditching cold-cathode tube backlights for LEDs, before then innovating with technologies that would vary the brightness of parts of the LED backlight to improve contrast somewhat. Some companies even started using arrays of colored LEDs in their backlights for further control, with the technology often referred to as “RGB mini LED” or “micro RGB.” This still involves an LCD panel in front of the backlight, limiting contrast ratios and response times.

The holy grail, though, would be to ditch the liquid crystal entirely, and just have a display fully made of individually addressable LEDs making up the red, green, and blue subpixels. That is finally coming to pass, with manufacturers launching new television lines under the “Micro LED” name. These are true “emissive” displays, where the individual red, blue, and green subpixels are themselves emitting light, not just filtering it from a backlight source behind them.
The challenge behind making pure LED TVs was figuring out how to get the LEDs small enough and to put them in scalable arrays. Credit: Samsung
These displays promise greater contrast than backlit LCDs, because individual pixels can be turned completely off to create blacker blacks. Response times are also fast because LEDs switch on and off much more quickly than liquid crystals can react. They’re also relatively power efficient, as there’s no need to supply electrons to pixels that are off. Contrast this to LCDs, which are always spending power on turning some pixels black in front of a glowing backlight which is also drawing power. Viewing angles of emissive displays are also top-notch. Inorganic LEDs also have long lifetimes, which makes them far more desirable than OLED displays (discussed further below). Their high brightness also makes them ideal for us in bright conditions, particularly where sunlight is concerned.

Given the many boons of this technology, you might question why it’s taken true LED displays this long to hit the market. The ultimate answer comes down to cost and manufacturability. If you’ve ever built your own LED array, you’ve probably noted the engineering challenges in reducing pixel size and increasing resolution. When it comes to producing a 4K display, you’re talking about laying down 8,294,400 individual RGB LEDs, all of which need to work flawlessly and be small enough to not show up as individually visible pixels from typical viewing ranges. Other technologies like LCDs and OLEDs have the benefit that they can be easily produced with lithographic techniques in great sizes, but the technology to produce pure LED displays on this scale is only just coming into fruition.
There are very few Micro LED TVs on the market right now. The price is why. Credit: Best Buy via screenshot
You can purchase an all-LED TV today, if you so desire. Just note that you’ll pay through the nose for it. Few models are on the market, but Best Buy will sell you a 114″ Micro LED set from Samsung for the charming price of $149,999.99. If that’s a bit big for your house, condo, or apartment, you might consider the 89″ model for a more acceptable $109,999.99. Meanwhile, LG has demonstrated a 136″ model of a micro LED TV, but there have been no concrete plans to bring it to market. Expect it to land somewhere firmly in the six-figure range, too.

If you’re not feeling so flush, you can get a lesser “Micro RGB” TV if you like, which combines a fancy RGB matrix backlight with LCD technology as discussed above. Even then, a Samsung R95 television with Micro RGB technology will set you back $29,999.99 at Best Buy, or you can purchase it on a payment plan for $1,250 a month. In fact, with the launch of these comparatively affordable TVs, Samsung has gone somewhat quiet on its Micro LED line since initially crowing about it in 2024. Still, whichever way you go, these fancy TVs don’t come cheap.

But What About OLED?

OLEDs have many benefits as an emissive display technology, however the organic materials used come with limits to brightness and lifespan. Fabrication cost is, however, far cheaper than pure inorganic LED displays. Credit: author
It’s true that emissive LED displays have existed in the market for some time, but not using traditional light-emitting diodes. These are the popular “OLED” displays, with the acronym standing for “organic light emitting diode.” Unlike standard LEDs, which use inorganic semiconductor crystals to emit light, OLEDs instead use special organic compounds in a substrate between electrodes, which emit light when electricity is applied. They can readily be fabricated in large arrays to create displays, which are used in everything from tiny smartwatches to full-sized televisions.

You might question why the advent of “proper” LED displays is noteworthy given that OLED technology has been around for some time. The problem is that OLEDs are somewhat limited in their performance versus traditional inorganic LEDs. The main area in which they suffer is longevity, as the organic compounds are susceptible to degradation over time. The brightness of individual pixels in an OLED display tends to drop off very quickly compared to inorganic LEDs. A display can diminish to half of its original brightness in just a few years of moderate to heavy use. In particular, blue OLED subpixels tend to degrade faster than red or green subpixels, forcing manufacturers to take measures to account for this over the lifetime of a display. Peak brightness is also somewhat limited, which can make OLED displays less attractive for use in bright rooms with lots of natural light. Dark spots and burn in are also possible, at rates greater than those seen in contemporary LCD displays.

The limitations of OLED displays have not stopped them gaining a strong position in the TV marketplace. However, the technology will be unlikely to beat true LED displays in terms of outright image quality, brightness, and performance. Cost will still be a factor, and OLEDs (and LCDs) will still be relevant for a long time to come. However, for now at least, the pure LED display promises to become the prime choice for those looking for a premium viewing experience at any cost.

Featured image: “Micro LED” displays. Credit: Samsung

hackaday.com/2026/02/16/real-l…

IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I won't be in New Delhi for India's AI Impact Summit this week. For those of you who are, here's the official agenda. God speed navigating the endless side events.

— This week's AI conference in India pits different visions of the emerging technology against each other. You should be wary of all of them.

— The global rush to ban kids from using social media is a prime example of the lack of quantifiable evidence used to make digital rules.

— The Global Majority is missing from the worldwide data center boom.

Let's get started.

digitalpolitics.co/newsletter0…